All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Andre Przywara <andre.przywara@arm.com>
Cc: kernel-team@android.com, kvm@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH][kvmtool] virtio/pci: Correctly handle MSI-X masking while MSI-X is disabled
Date: Tue, 24 Aug 2021 15:32:53 +0100	[thread overview]
Message-ID: <87tujeq5ey.wl-maz@kernel.org> (raw)
In-Reply-To: <20210823174833.05adee5d@slackpad.fritz.box>

Hi Andre,

On Mon, 23 Aug 2021 17:48:33 +0100,
Andre Przywara <andre.przywara@arm.com> wrote:
> 
> On Sat, 21 Aug 2021 13:07:42 +0100
> Marc Zyngier <maz@kernel.org> wrote:
> 
> Hi Marc,
> 
> > Since Linux commit 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X
> > entries"), kvmtool segfaults when the guest boots and tries to
> > disable all the MSI-X entries of a virtio device while MSI-X itself
> > is disabled.
> > 
> > What Linux does is seems perfectly correct. However, kvmtool uses
> > a different decoding depending on whether MSI-X is enabled for
> > this device or not. Which seems pretty wrong.
> 
> While I really wish this would be wrong, I think this is
> indeed how this is supposed to work: The Virtio legacy spec makes the
> existence of those two virtio config fields dependent on the
> (dynamic!) enablement status of MSI-X. This is reflected in:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/virtio_pci.h#n72
> and explicitly mentioned as a footnote in the virtio 0.9.5 spec[1]:
> "3) ie. once you enable MSI-X on the device, the other fields move. If
> you turn it off again, they move back!"

Madness! What was Rusty on at the time? I really hope the bitcoin
thing is buying him better stuff...

> I agree that this looks like a bad idea, but I am afraid we are stuck
> with this. It looks like the Linux driver is at fault here, it should
> not issue the config access when MSIs are disabled. Something like this
> (untested):
> 
> --- a/drivers/virtio/virtio_pci_legacy.c
> +++ b/drivers/virtio/virtio_pci_legacy.c
> @@ -103,6 +103,9 @@ static void vp_reset(struct virtio_device *vdev)
>  
>  static u16 vp_config_vector(struct virtio_pci_device *vp_dev, u16 vector)
>  {
> +       if (!vp_dev->msix_enabled)
> +               return VIRTIO_MSI_NO_VECTOR;
> +
>         /* Setup the vector used for configuration events */
>         iowrite16(vector, vp_dev->ioaddr + VIRTIO_MSI_CONFIG_VECTOR);
>         /* Verify we had enough resources to assign the vector */
> 
> This is just my first idea after looking at this, happy to stand
> corrected or hear about a better solution.

I don't think this works. It instead completely disables MSI-X, which
is a total bore. I think the only way to deal with it is to quirk it
to prevent the bulk masking to take effect before MSI-X is enabled.

Gawd, more crap. Just what we need...

	M.

-- 
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Andre Przywara <andre.przywara@arm.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	kernel-team@android.com,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH][kvmtool] virtio/pci: Correctly handle MSI-X masking while MSI-X is disabled
Date: Tue, 24 Aug 2021 15:32:53 +0100	[thread overview]
Message-ID: <87tujeq5ey.wl-maz@kernel.org> (raw)
In-Reply-To: <20210823174833.05adee5d@slackpad.fritz.box>

Hi Andre,

On Mon, 23 Aug 2021 17:48:33 +0100,
Andre Przywara <andre.przywara@arm.com> wrote:
> 
> On Sat, 21 Aug 2021 13:07:42 +0100
> Marc Zyngier <maz@kernel.org> wrote:
> 
> Hi Marc,
> 
> > Since Linux commit 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X
> > entries"), kvmtool segfaults when the guest boots and tries to
> > disable all the MSI-X entries of a virtio device while MSI-X itself
> > is disabled.
> > 
> > What Linux does is seems perfectly correct. However, kvmtool uses
> > a different decoding depending on whether MSI-X is enabled for
> > this device or not. Which seems pretty wrong.
> 
> While I really wish this would be wrong, I think this is
> indeed how this is supposed to work: The Virtio legacy spec makes the
> existence of those two virtio config fields dependent on the
> (dynamic!) enablement status of MSI-X. This is reflected in:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/virtio_pci.h#n72
> and explicitly mentioned as a footnote in the virtio 0.9.5 spec[1]:
> "3) ie. once you enable MSI-X on the device, the other fields move. If
> you turn it off again, they move back!"

Madness! What was Rusty on at the time? I really hope the bitcoin
thing is buying him better stuff...

> I agree that this looks like a bad idea, but I am afraid we are stuck
> with this. It looks like the Linux driver is at fault here, it should
> not issue the config access when MSIs are disabled. Something like this
> (untested):
> 
> --- a/drivers/virtio/virtio_pci_legacy.c
> +++ b/drivers/virtio/virtio_pci_legacy.c
> @@ -103,6 +103,9 @@ static void vp_reset(struct virtio_device *vdev)
>  
>  static u16 vp_config_vector(struct virtio_pci_device *vp_dev, u16 vector)
>  {
> +       if (!vp_dev->msix_enabled)
> +               return VIRTIO_MSI_NO_VECTOR;
> +
>         /* Setup the vector used for configuration events */
>         iowrite16(vector, vp_dev->ioaddr + VIRTIO_MSI_CONFIG_VECTOR);
>         /* Verify we had enough resources to assign the vector */
> 
> This is just my first idea after looking at this, happy to stand
> corrected or hear about a better solution.

I don't think this works. It instead completely disables MSI-X, which
is a total bore. I think the only way to deal with it is to quirk it
to prevent the bulk masking to take effect before MSI-X is enabled.

Gawd, more crap. Just what we need...

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2021-08-24 14:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-21 12:07 [PATCH][kvmtool] virtio/pci: Correctly handle MSI-X masking while MSI-X is disabled Marc Zyngier
2021-08-21 12:07 ` Marc Zyngier
2021-08-23 16:48 ` Andre Przywara
2021-08-23 16:48   ` Andre Przywara
2021-08-24 14:32   ` Marc Zyngier [this message]
2021-08-24 14:32     ` Marc Zyngier
2021-08-25 15:33     ` Marc Zyngier
2021-08-25 15:33       ` Marc Zyngier
2021-08-25 17:44       ` Marc Zyngier
2021-08-25 17:44         ` Marc Zyngier
2021-08-26 17:07         ` Andre Przywara
2021-08-26 17:07           ` Andre Przywara
2021-08-26 17:50           ` Marc Zyngier
2021-08-26 17:50             ` Marc Zyngier

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=87tujeq5ey.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /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
Be 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.