From: "Liu, Jing2" <jing2.liu@linux.intel.com> To: Jason Wang <jasowang@redhat.com>, Zha Bin <zhabin@linux.alibaba.com>, linux-kernel@vger.kernel.org Cc: mst@redhat.com, slp@redhat.com, virtio-dev@lists.oasis-open.org, gerry@linux.alibaba.com, jing2.liu@intel.com, chao.p.peng@intel.com Subject: Re: [virtio-dev] Re: [PATCH v1 2/2] virtio-mmio: add features for virtio-mmio specification version 3 Date: Thu, 2 Jan 2020 17:13:28 +0800 [thread overview] Message-ID: <42346d41-b758-967a-30b7-95aa0d383beb@linux.intel.com> (raw) In-Reply-To: <683cac51-853d-c8c8-24c6-b01886978ca4@redhat.com> [...] >>> >>>> + >>>> +/* 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. > > 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. 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@lists.oasis-open.org >>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org >>> >> >
WARNING: multiple messages have this Message-ID (diff)
From: "Liu, Jing2" <jing2.liu@linux.intel.com> To: Jason Wang <jasowang@redhat.com>, Zha Bin <zhabin@linux.alibaba.com>, linux-kernel@vger.kernel.org Cc: mst@redhat.com, slp@redhat.com, virtio-dev@lists.oasis-open.org, gerry@linux.alibaba.com, jing2.liu@intel.com, chao.p.peng@intel.com Subject: Re: [virtio-dev] Re: [PATCH v1 2/2] virtio-mmio: add features for virtio-mmio specification version 3 Date: Thu, 2 Jan 2020 17:13:28 +0800 [thread overview] Message-ID: <42346d41-b758-967a-30b7-95aa0d383beb@linux.intel.com> (raw) In-Reply-To: <683cac51-853d-c8c8-24c6-b01886978ca4@redhat.com> [...] >>> >>>> + >>>> +/* 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. > > 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. 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@lists.oasis-open.org >>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2020-01-02 9:13 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-25 2:50 [PATCH v1 0/2] support virtio mmio specification Version 3 Zha Bin 2019-12-25 2:50 ` [PATCH v1 1/2] x86/msi: Enhance x86 to support platform_msi Zha Bin 2019-12-26 8:21 ` Jason Wang 2019-12-26 8:21 ` [virtio-dev] " Jason Wang 2020-01-17 13:58 ` Thomas Gleixner 2020-01-17 14:06 ` Liu, Jiang 2020-01-19 2:27 ` Liu, Jing2 2020-01-19 2:27 ` [virtio-dev] " Liu, Jing2 2020-01-19 14:57 ` Thomas Gleixner 2019-12-25 2:50 ` [PATCH v1 2/2] virtio-mmio: add features for virtio-mmio specification version 3 Zha Bin 2019-12-25 10:20 ` Jason Wang 2019-12-25 10:20 ` [virtio-dev] " Jason Wang 2019-12-25 15:20 ` Liu, Jiang 2019-12-26 8:09 ` Jason Wang 2019-12-26 8:09 ` [virtio-dev] " Jason Wang 2019-12-26 12:35 ` Liu, Jiang 2019-12-26 13:16 ` Liu, Jiang 2020-01-02 6:28 ` Jason Wang 2020-01-02 6:28 ` [virtio-dev] " Jason Wang 2020-01-03 6:50 ` Liu, Jiang 2020-01-05 10:42 ` Michael S. Tsirkin 2020-01-05 10:42 ` [virtio-dev] " Michael S. Tsirkin 2020-01-06 7:24 ` Liu, Jing2 2020-01-06 7:24 ` [virtio-dev] " Liu, Jing2 2020-01-09 16:06 ` Liu, Jiang 2020-01-09 16:47 ` Michael S. Tsirkin 2020-01-09 16:47 ` [virtio-dev] " Michael S. Tsirkin 2019-12-25 22:28 ` kbuild test robot 2019-12-25 22:28 ` kbuild test robot 2019-12-26 1:44 ` kbuild test robot 2019-12-26 1:44 ` kbuild test robot 2019-12-26 8:40 ` Jason Wang 2019-12-26 8:40 ` [virtio-dev] " Jason Wang 2019-12-27 9:37 ` Liu, Jing2 2019-12-27 9:37 ` Liu, Jing2 2020-01-02 6:33 ` Jason Wang 2020-01-02 6:33 ` Jason Wang 2020-01-02 9:13 ` Liu, Jing2 [this message] 2020-01-02 9:13 ` Liu, Jing2 2020-01-03 3:24 ` Jason Wang 2020-01-03 3:24 ` Jason Wang 2020-01-03 6:14 ` Liu, Jiang 2020-01-03 9:12 ` Jason Wang 2020-01-03 9:12 ` Jason Wang 2020-01-05 11:25 ` Michael S. Tsirkin 2020-01-05 11:25 ` Michael S. Tsirkin 2020-01-06 2:51 ` Jason Wang 2020-01-06 2:51 ` Jason Wang 2020-01-05 11:04 ` Michael S. Tsirkin 2020-01-05 11:04 ` [virtio-dev] " Michael S. Tsirkin 2020-01-09 6:15 ` Liu, Jing2 2020-01-09 6:15 ` [virtio-dev] " Liu, Jing2 2020-01-09 13:26 ` Michael S. Tsirkin 2020-01-09 13:26 ` [virtio-dev] " Michael S. Tsirkin 2020-01-15 7:06 ` Liu, Jing2 2020-01-15 7:06 ` [virtio-dev] " Liu, Jing2 2020-01-21 5:03 ` Liu, Jing2 2020-01-21 5:03 ` Liu, Jing2 2020-01-02 6:55 ` [PATCH v1 0/2] support virtio mmio specification Version 3 Jason Wang 2020-01-02 6:55 ` [virtio-dev] " Jason Wang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=42346d41-b758-967a-30b7-95aa0d383beb@linux.intel.com \ --to=jing2.liu@linux.intel.com \ --cc=chao.p.peng@intel.com \ --cc=gerry@linux.alibaba.com \ --cc=jasowang@redhat.com \ --cc=jing2.liu@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mst@redhat.com \ --cc=slp@redhat.com \ --cc=virtio-dev@lists.oasis-open.org \ --cc=zhabin@linux.alibaba.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.