Re: [PATCH v1 2/2] virtio-mmio: add features for virtio-mmio specification version 3
From: Michael S. Tsirkin
Date: Thu Jan 09 2020 - 11:47:39 EST
On Fri, Jan 10, 2020 at 12:06:06AM +0800, Liu, Jiang wrote:
> On Jan 5, 2020, at 6:42 PM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:
> >
> > On Thu, Dec 26, 2019 at 09:16:19PM +0800, Liu, Jiang wrote:
> >>> 2) The mask and unmask control is missed
> >>>
> >>>
> >>>> but the extension doesnât support 3) because
> >>>> we noticed that the Linux virtio subsystem doesnât really make use of interrupt masking/unmasking.
> >
> > Linux uses masking/unmasking in order to migrate interrupts between
> > CPUs.
> This is a limitation of the PCI MSI/MSIx spec.
> To update the MSI/MSIx vector configuration, we need to write to msg_high/msg_low/msg_data registers.
> Because write to three 32-bit registers is not an atomic operation on PCI bus, so it may cause incorrect interrupt delivery if interrupt happens after writing 1 or 2 registers.
> When Intel remapping is enabled on x86 platforms, we donât need to mask/unmask PCI MSI/MSIx interrupts when setting affinity.
> For MMIO MSI extension, we have special design to solve this race window. The flow to update MMIO MSI vector configuration is:
> 1) write msg_high
> 2) write msg_low
> 3) write msg_data
> 4) write the command register to update the vector configuration.
> During step 1-3, the hardware/device backend driver only caches the value written. And update the vector configuration in step 4, so itâs an atomic operation now.
> So mask/unmask becomes optional for MMIO MSI interrupts.
Oh I see. That needs some documentation I guess.
One question though: how do you block VQ from generating interrupts?
There's value in doing that for performance since then device can avoid
re-checking interrupt enable/event idx values in memory.
> >
> > --
> > MST