From: Alex Williamson <alex.williamson@redhat.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH qemu] vfio_pci: Allow disabling quirks
Date: Sun, 19 Jul 2015 11:15:26 -0600 [thread overview]
Message-ID: <1437326126.1391.710.camel@redhat.com> (raw)
In-Reply-To: <1437310218.1391.660.camel@redhat.com>
On Sun, 2015-07-19 at 06:50 -0600, Alex Williamson wrote:
> On Sun, 2015-07-19 at 18:19 +1000, Alexey Kardashevskiy wrote:
> > The existing quirks aim config space and MSIX BAR accesses interception.
> > These are not always needed, for example, on pseries machines,
> > config space and MSI/MSIX configuration are handled by hypervisor.
> >
> > This adds a "quirks" property to control whether to enable quirks or not;
> > the property is set to "true" by default.
> >
> > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > ---
> >
> > Helps to get
> > VGA compatible controller: NVIDIA Corporation GM107GL [Quadro K2200] (rev a2)
> > (which does not need the quirk anyway) working on POWER8 system.
BTW, as I was working on the rtl quirk last week, I re-realized
something; page size doesn't matter for quirks. If we want to carve a
4k hole for a PCI extended config space window, we can do that
regardless of the host page size. The rtl quirk only carves out an 8
byte window. It's the Memory API's problem to figure out the extent of
the region that needs to fault into QEMU and which parts go through the
quirk vs the slow backing of the BAR. That's why we create the slow
backing across the entire BAR. So if this quirk isn't working for you,
page size is probably not the reason. That said, there are some
gratuitous uses of target page size in the quirk code. Part of it is
just a convenience factor for packing data structures, part of it is
completely unnecessary, like the TARGET_PAGE_ALIGN setting up the quirk
in question here. Thanks,
Alex
> > ---
> > hw/vfio/pci.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> > index 2ed877f..ba47301 100644
> > --- a/hw/vfio/pci.c
> > +++ b/hw/vfio/pci.c
> > @@ -168,6 +168,7 @@ typedef struct VFIOPCIDevice {
> > bool has_flr;
> > bool has_pm_reset;
> > bool rom_read_failed;
> > + bool allow_quirks;
> > } VFIOPCIDevice;
> >
> > typedef struct VFIORomBlacklistEntry {
> > @@ -2442,7 +2443,9 @@ static void vfio_map_bar(VFIOPCIDevice *vdev, int nr)
> > }
> > }
> >
> > - vfio_bar_quirk_setup(vdev, nr);
> > + if (vdev->allow_quirks) {
> > + vfio_bar_quirk_setup(vdev, nr);
> > + }
> > }
> >
> > static void vfio_map_bars(VFIOPCIDevice *vdev)
> > @@ -3753,6 +3756,7 @@ static Property vfio_pci_dev_properties[] = {
> > VFIO_FEATURE_ENABLE_REQ_BIT, true),
> > DEFINE_PROP_INT32("bootindex", VFIOPCIDevice, bootindex, -1),
> > DEFINE_PROP_BOOL("x-mmap", VFIOPCIDevice, vbasedev.allow_mmap, true),
> > + DEFINE_PROP_BOOL("quirks", VFIOPCIDevice, allow_quirks, true),
> > /*
> > * TODO - support passed fds... is this necessary?
> > * DEFINE_PROP_STRING("vfiofd", VFIOPCIDevice, vfiofd_name),
>
>
> NAK, if you don't need it for power then make it automatically disabled
> for power. Otherwise you're just pushing the burden onto the
> user/libvirt to know when to use this option. Thanks,
>
> Alex
>
>
next prev parent reply other threads:[~2015-07-19 17:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-19 8:19 [Qemu-devel] [PATCH qemu] vfio_pci: Allow disabling quirks Alexey Kardashevskiy
2015-07-19 12:50 ` Alex Williamson
2015-07-19 17:15 ` Alex Williamson [this message]
2015-07-20 2:40 ` Alexey Kardashevskiy
2015-09-09 7:17 ` Alexey Kardashevskiy
2015-09-09 18:34 ` Alex Williamson
2015-10-02 7:58 ` Alexey Kardashevskiy
2015-10-02 14:20 ` Alex Williamson
2015-10-03 10:15 ` Alexey Kardashevskiy
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=1437326126.1391.710.camel@redhat.com \
--to=alex.williamson@redhat.com \
--cc=aik@ozlabs.ru \
--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).