From: Jason Wang <firstname.lastname@example.org> To: "Liu, Jing2" <email@example.com>, Zha Bin <firstname.lastname@example.org>, email@example.com Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [virtio-dev] Re: [PATCH v2 4/5] virtio-mmio: add MSI interrupt feature support Date: Tue, 11 Feb 2020 15:40:23 +0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On 2020/2/11 下午2:02, Liu, Jing2 wrote: > > > On 2/11/2020 12:02 PM, Jason Wang wrote: >> >> On 2020/2/11 上午11:35, Liu, Jing2 wrote: >>> >>> On 2/11/2020 11:17 AM, Jason Wang wrote: >>>> >>>> On 2020/2/10 下午5:05, Zha Bin wrote: >>>>> From: Liu Jiang<firstname.lastname@example.org> >>>>> >>>>> Userspace VMMs (e.g. Qemu microvm, Firecracker) take advantage of >>>>> using >>>>> virtio over mmio devices as a lightweight machine model for modern >>>>> cloud. The standard virtio over MMIO transport layer only supports >>>>> one >>>>> legacy interrupt, which is much heavier than virtio over PCI >>>>> transport >>>>> layer using MSI. Legacy interrupt has long work path and causes >>>>> specific >>>>> VMExits in following cases, which would considerably slow down the >>>>> performance: >>>>> >>>>> 1) read interrupt status register >>>>> 2) update interrupt status register >>>>> 3) write IOAPIC EOI register >>>>> >>>>> We proposed to add MSI support for virtio over MMIO via new feature >>>>> bit VIRTIO_F_MMIO_MSI which increases the interrupt performance. >>>>> >>>>> With the VIRTIO_F_MMIO_MSI feature bit supported, the virtio-mmio MSI >>>>> uses msi_sharing to indicate the event and vector mapping. >>>>> Bit 1 is 0: device uses non-sharing and fixed vector per event >>>>> mapping. >>>>> Bit 1 is 1: device uses sharing mode and dynamic mapping. >>>> >>>> >>>> I believe dynamic mapping should cover the case of fixed vector? >>>> >>> Actually this bit *aims* for msi sharing or msi non-sharing. >>> >>> It means, when msi sharing bit is 1, device doesn't want vector per >>> queue >>> >>> (it wants msi vector sharing as name) and doesn't want a high >>> interrupt rate. >>> >>> So driver turns to !per_vq_vectors and has to do dynamical mapping. >>> >>> So they are opposite not superset. >>> >>> Thanks! >>> >>> Jing >> >> >> I think you need add more comments on the command. >> >> E.g if I want to map vector 0 to queue 1, how do I need to do? >> >> write(1, queue_sel); >> write(0, vector_sel); > > That's true. Besides, two commands are used for msi sharing mode, > > VIRTIO_MMIO_MSI_CMD_MAP_CONFIG and VIRTIO_MMIO_MSI_CMD_MAP_QUEUE. > > "To set up the event and vector mapping for MSI sharing mode, driver > SHOULD write a valid MsiVecSel followed by > VIRTIO_MMIO_MSI_CMD_MAP_CONFIG/VIRTIO_MMIO_MSI_CMD_MAP_QUEUE command > to map the configuration change/selected queue events respectively. " > (See spec patch 5/5) > > So if driver detects the msi sharing mode, when it does setup vq, > writes the queue_sel (this already exists in setup vq), vector sel and > then MAP_QUEUE command to do the queue event mapping. > So actually the per vq msix could be done through this. I don't get why you need to introduce MSI_SHARING_MASK which is the charge of driver instead of device. The interrupt rate should have no direct relationship with whether it has been shared or not. Btw, you introduce mask/unmask without pending, how to deal with the lost interrupt during the masking then? > For msi non-sharing mode, no special action is needed because we make > the rule of per_vq_vector and fixed relationship. > > Correct me if this is not that clear for spec/code comments. > The ABI is not as straightforward as PCI did. Why not just reuse the PCI layout? E.g having queue_sel queue_msix_vector msix_config for configuring map between msi vector and queues/config Then vector_sel address data pending mask unmask for configuring msi table? Thanks > Thanks! > > Jing > > >> >> ? >> >> Thanks >> >> >>> >>> >>>> Thanks >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: email@example.com >>>> For additional commands, e-mail: firstname.lastname@example.org >>>> >>> >>
next prev parent reply other threads:[~2020-02-11 7:40 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-10 9:05 [PATCH v2 0/5] virtio mmio specification enhancement Zha Bin 2020-02-10 9:05 ` [PATCH v2 1/5] virtio-mmio: add notify feature for per-queue Zha Bin 2020-02-11 10:50 ` Michael S. Tsirkin 2020-02-11 11:33 ` Michael S. Tsirkin 2020-02-12 3:39 ` Jason Wang 2020-02-12 8:18 ` Michael S. Tsirkin 2020-02-12 8:53 ` Jason Wang 2020-02-12 9:33 ` Jason Wang 2020-02-12 9:55 ` Michael S. Tsirkin 2020-02-13 3:38 ` Jason Wang 2020-02-10 9:05 ` [PATCH v2 2/5] virtio-mmio: refactor common functionality Zha Bin 2020-02-11 11:19 ` Michael S. Tsirkin 2020-02-12 2:58 ` [virtio-dev] " Liu, Jing2 2020-02-12 7:29 ` Michael S. Tsirkin 2020-02-10 9:05 ` [PATCH v2 3/5] virtio-mmio: create a generic MSI irq domain Zha Bin 2020-02-11 11:16 ` Michael S. Tsirkin 2020-02-12 7:40 ` Michael S. Tsirkin 2020-02-10 9:05 ` [PATCH v2 4/5] virtio-mmio: add MSI interrupt feature support Zha Bin 2020-02-11 3:17 ` Jason Wang 2020-02-11 3:35 ` [virtio-dev] " Liu, Jing2 2020-02-11 4:02 ` Jason Wang [not found] ` <email@example.com> 2020-02-11 7:40 ` Jason Wang [this message] 2020-02-11 11:58 ` Michael S. Tsirkin 2020-02-11 12:04 ` Jason Wang 2020-02-11 12:08 ` Michael S. Tsirkin 2020-02-11 12:18 ` Jason Wang 2020-02-11 14:00 ` Michael S. Tsirkin 2020-02-12 9:03 ` Jason Wang 2020-02-12 9:15 ` Michael S. Tsirkin [not found] ` <firstname.lastname@example.org> 2020-02-12 7:33 ` Michael S. Tsirkin 2020-02-12 9:06 ` Jason Wang 2020-02-12 9:16 ` Michael S. Tsirkin 2020-02-13 3:40 ` Jason Wang 2020-02-11 11:21 ` Michael S. Tsirkin 2020-02-11 11:11 ` Michael S. Tsirkin 2020-02-10 9:05 ` [PATCH v2 5/5] x86: virtio-mmio: support virtio-mmio with MSI for x86 Zha Bin 2020-02-11 11:14 ` Michael S. Tsirkin 2020-02-10 11:44 ` [PATCH v2 0/5] virtio mmio specification enhancement Michael S. Tsirkin 2020-02-11 16:05 ` Chao Peng 2020-02-11 10:57 ` Michael S. Tsirkin
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [virtio-dev] Re: [PATCH v2 4/5] virtio-mmio: add MSI interrupt feature support' \ /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: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).