From: Alex Williamson <alex.williamson@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: marcel.apfelbaum@gmail.com, qemu-devel@nongnu.org, clg@redhat.com
Subject: Re: [PATCH] pci: Add option to disable device level INTx masking
Date: Fri, 8 Mar 2024 10:24:14 -0700 [thread overview]
Message-ID: <20240308102414.1826786c.alex.williamson@redhat.com> (raw)
In-Reply-To: <20240308115643-mutt-send-email-mst@kernel.org>
On Fri, 8 Mar 2024 11:57:38 -0500
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Mar 07, 2024 at 11:46:42AM -0700, Alex Williamson wrote:
> > The PCI 2.3 spec added definitions of the INTx disable and status bits,
> > in the command and status registers respectively. The command register
> > bit, commonly known as DisINTx in lspci, controls whether the device
> > can assert the INTx signal.
> >
> > Operating systems will often write to this bit to test whether a device
> > supports this style of legacy interrupt masking. When using device
> > assignment, such as with vfio-pci, the result of this test dictates
> > whether the device can use a shared or exclusive interrupt (ie. generic
> > INTx masking at the device via DisINTx or IRQ controller level INTx
> > masking).
> >
> > Add an experimental option to the base set of properties for PCI
> > devices which allows the DisINTx bit to be excluded from wmask, making
> > it read-only to the guest for testing purposes related to INTx masking.
> >
>
> Could you clarify the use a bit more? It's unstable - do you
> expect to experiment with it and then make it permanent down
> the road?
No, my aspirations end at providing an experimental option.
Technically all devices should support and honor this bit, so I don't
think we should provide a supported method of providing broken behavior,
but there do exist physical devices where this feature is broken or
unsupported. Rather than implementing emulation of one of these broken
devices, with bug for bug compatibility, it's much easier to be able to
trigger broken DisINTx behavior on an arbitrary device, in an
unsupported fashion. Thanks,
Alex
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > ---
> > hw/pci/pci.c | 14 ++++++++++----
> > include/hw/pci/pci.h | 2 ++
> > 2 files changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index 6496d027ca61..8c78326ad67f 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -85,6 +85,8 @@ static Property pci_props[] = {
> > QEMU_PCIE_ERR_UNC_MASK_BITNR, true),
> > DEFINE_PROP_BIT("x-pcie-ari-nextfn-1", PCIDevice, cap_present,
> > QEMU_PCIE_ARI_NEXTFN_1_BITNR, false),
> > + DEFINE_PROP_BIT("x-pci-disintx", PCIDevice, cap_present,
> > + QEMU_PCI_DISINTX_BITNR, true),
> > DEFINE_PROP_END_OF_LIST()
> > };
> >
> > @@ -861,13 +863,17 @@ static void pci_init_cmask(PCIDevice *dev)
> > static void pci_init_wmask(PCIDevice *dev)
> > {
> > int config_size = pci_config_size(dev);
> > + uint16_t cmd_wmask = PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
> > + PCI_COMMAND_MASTER | PCI_COMMAND_SERR;
> >
> > dev->wmask[PCI_CACHE_LINE_SIZE] = 0xff;
> > dev->wmask[PCI_INTERRUPT_LINE] = 0xff;
> > - pci_set_word(dev->wmask + PCI_COMMAND,
> > - PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER |
> > - PCI_COMMAND_INTX_DISABLE);
> > - pci_word_test_and_set_mask(dev->wmask + PCI_COMMAND, PCI_COMMAND_SERR);
> > +
> > + if (dev->cap_present & QEMU_PCI_DISINTX) {
> > + cmd_wmask |= PCI_COMMAND_INTX_DISABLE;
> > + }
> > +
> > + pci_set_word(dev->wmask + PCI_COMMAND, cmd_wmask);
> >
> > memset(dev->wmask + PCI_CONFIG_HEADER_SIZE, 0xff,
> > config_size - PCI_CONFIG_HEADER_SIZE);
> > diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> > index eaa3fc99d884..45f0fac435cc 100644
> > --- a/include/hw/pci/pci.h
> > +++ b/include/hw/pci/pci.h
> > @@ -212,6 +212,8 @@ enum {
> > QEMU_PCIE_ERR_UNC_MASK = (1 << QEMU_PCIE_ERR_UNC_MASK_BITNR),
> > #define QEMU_PCIE_ARI_NEXTFN_1_BITNR 12
> > QEMU_PCIE_ARI_NEXTFN_1 = (1 << QEMU_PCIE_ARI_NEXTFN_1_BITNR),
> > +#define QEMU_PCI_DISINTX_BITNR 13
> > + QEMU_PCI_DISINTX = (1 << QEMU_PCI_DISINTX_BITNR),
> > };
> >
> > typedef struct PCIINTxRoute {
> > --
> > 2.44.0
>
next prev parent reply other threads:[~2024-03-08 17:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-07 18:46 [PATCH] pci: Add option to disable device level INTx masking Alex Williamson
2024-03-08 16:47 ` Cédric Le Goater
2024-03-08 16:57 ` Michael S. Tsirkin
2024-03-08 17:24 ` Alex Williamson [this message]
2024-03-08 19:37 ` Michael S. Tsirkin
2024-03-08 20:02 ` Alex Williamson
2024-03-08 20:05 ` 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 \
--in-reply-to=20240308102414.1826786c.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=clg@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.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 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).