lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <46806720-1D1C-40C3-BEE2-EDB0D4DA39BF@linux.alibaba.com>
Date:   Fri, 3 Jan 2020 14:14:20 +0800
From:   "Liu, Jiang" <gerry@...ux.alibaba.com>
To:     Jason Wang <jasowang@...hat.com>
Cc:     "Liu, Jing2" <jing2.liu@...ux.intel.com>,
        Zha Bin <zhabin@...ux.alibaba.com>,
        linux-kernel@...r.kernel.org, mst@...hat.com, slp@...hat.com,
        virtio-dev@...ts.oasis-open.org, jing2.liu@...el.com,
        chao.p.peng@...el.com
Subject: Re: [virtio-dev] Re: [PATCH v1 2/2] virtio-mmio: add features for
 virtio-mmio specification version 3



> On Jan 3, 2020, at 11:24 AM, Jason Wang <jasowang@...hat.com> wrote:
> 
> 
> On 2020/1/2 下午5:13, Liu, Jing2 wrote:
>> [...]
>> 
>>>>> 
>>>>>> +
>>>>>> +/* RO: MSI feature enabled mask */
>>>>>> +#define VIRTIO_MMIO_MSI_ENABLE_MASK    0x8000
>>>>>> +/* RO: Maximum queue size available */
>>>>>> +#define VIRTIO_MMIO_MSI_STATUS_QMASK    0x07ff
>>>>>> +/* Reserved */
>>>>>> +#define VIRTIO_MMIO_MSI_STATUS_RESERVED    0x7800
>>>>>> +
>>>>>> +#define VIRTIO_MMIO_MSI_CMD_UPDATE    0x1
>>>>> 
>>>>> 
>>>>> I believe we need a command to read the number of vectors supported by the device, or 2048 is assumed to be a fixed size here?
>>>> 
>>>> For not bringing much complexity, we proposed vector per queue and fixed relationship between events and vectors.
>>> 
>>> 
>>> It's a about the number of MSIs not the mapping between queues to MSIs.And it looks to me it won't bring obvious complexity, just need a register to read the #MSIs. Device implementation may stick to a fixed size.
>> 
>> Based on that assumption, the device supports #MSIs = #queues + #config. Then driver need not read the register.
>> 
>> We're trying to make such kind of agreement on spec level.
> 
> 
> Ok, I get you now.
> 
> But still, having fixed number of MSIs is less flexible. E.g:
> 
> - for x86, processor can only deal with about 250 interrupt vectors.
> - driver may choose to share MSI vectors [1] (which is not merged but we will for sure need it)
Thanks for the info:)
X86 systems roughly have NCPU * 200 vectors available for device interrupts.
The proposed patch tries to map multiple event sources to an interrupt vector, to avoid running out of x86 CPU vectors.
Many virtio mmio devices may have several or tens of event sources, and it’s rare to have hundreds of event sources.
So could we treat the dynamic mapping between event sources and interrupt vectors as an advanced optional feature?

> 
> [1] https://lkml.org/lkml/2014/12/25/169
> 
> 
>> 
>>> 
>>> Having few pages for a device that only have one queue is kind of a waste.
>> 
>> Could I ask what's the meaning of few pages here? BTW, we didn't define MSIx-like tables for virtio-mmio.
> 
> 
> I thought you're using a fixed size (2048) for each device. But looks not :)
> 
> Thanks
> 
> 
>> 
>> Thanks,
>> 
>> Jing
>> 
>>> 
>>> Thanks
>>> 
>>> 
>>>> 
>>>> 
>>>> So the number of vectors supported by device is equal to the total number of vqs and config.
>>>> 
>>>> We will try to explicitly highlight this point in spec for later version.
>>>> 
>>>> 
>>>> Thanks!
>>>> 
>>>> Jing
>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: virtio-dev-unsubscribe@...ts.oasis-open.org
>>>>> For additional commands, e-mail: virtio-dev-help@...ts.oasis-open.org
>>>>> 
>>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: virtio-dev-unsubscribe@...ts.oasis-open.org
>> For additional commands, e-mail: virtio-dev-help@...ts.oasis-open.org

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ