All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: "Derrick, Jonathan" <jonathan.derrick@intel.com>
Cc: "hch@lst.de" <hch@lst.de>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"helgaas@kernel.org" <helgaas@kernel.org>,
	"virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"andrzej.jakowski@linux.intel.com"
	<andrzej.jakowski@linux.intel.com>
Subject: Re: [PATCH for QEMU v2] hw/vfio: Add VMD Passthrough Quirk
Date: Wed, 13 May 2020 13:55:08 -0600	[thread overview]
Message-ID: <20200513135508.162809da@x1.home> (raw)
In-Reply-To: <bd733dccd9cf67c50e757845332e6f8b95719776.camel@intel.com>

On Wed, 13 May 2020 19:26:34 +0000
"Derrick, Jonathan" <jonathan.derrick@intel.com> wrote:

> On Wed, 2020-05-13 at 11:55 -0600, Alex Williamson wrote:
> > On Wed, 13 May 2020 00:35:47 +0000
> > "Derrick, Jonathan" <jonathan.derrick@intel.com> wrote:
> >   
> > > Hi Alex,
> > > 
> > >   
> [snip]
> 
> > 
> > Thanks for the confirmation.  The approach seems ok, but a subtle
> > side-effect of MemoryRegion quirks is that we're going to trap the
> > entire PAGE_SIZE range overlapping the quirk out to QEMU on guest
> > access.  The two registers at 0x2000 might be reserved for this
> > purpose, but is there anything else that could be performance sensitive
> > anywhere in that page?  If so, it might be less transparent, but more
> > efficient to invent a new quirk making use of config space (ex. adding
> > an emulated vendor capability somewhere known to be unused on the
> > device).  Thanks,
> > 
> > Alex  
> 
> Seems like that could be a problem if we're running with huge pages and
> overlapping msix tables.

FWIW, MSI-X tables are already getting trapped into QEMU for emulation.
We have a mechanism via x-msix-relocation=<OffAutoPCIBAR> in QEMU to
deal with that when it becomes a problem by emulating the MSI-X
structures in MMIO space that doesn't overlap with the actual device
(ie. virtually resizing or adding BARs).  The issue is what else can be
in that 4K page or will this device be supported on archs where the
system page size is >4K more so than huge pages (as in hugetlbfs or
transparent huge pages).  Thanks,

Alex


WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: "Derrick, Jonathan" <jonathan.derrick@intel.com>
Cc: "lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"andrzej.jakowski@linux.intel.com"
	<andrzej.jakowski@linux.intel.com>,
	"helgaas@kernel.org" <helgaas@kernel.org>,
	"hch@lst.de" <hch@lst.de>
Subject: Re: [PATCH for QEMU v2] hw/vfio: Add VMD Passthrough Quirk
Date: Wed, 13 May 2020 13:55:08 -0600	[thread overview]
Message-ID: <20200513135508.162809da@x1.home> (raw)
In-Reply-To: <bd733dccd9cf67c50e757845332e6f8b95719776.camel@intel.com>

On Wed, 13 May 2020 19:26:34 +0000
"Derrick, Jonathan" <jonathan.derrick@intel.com> wrote:

> On Wed, 2020-05-13 at 11:55 -0600, Alex Williamson wrote:
> > On Wed, 13 May 2020 00:35:47 +0000
> > "Derrick, Jonathan" <jonathan.derrick@intel.com> wrote:
> >   
> > > Hi Alex,
> > > 
> > >   
> [snip]
> 
> > 
> > Thanks for the confirmation.  The approach seems ok, but a subtle
> > side-effect of MemoryRegion quirks is that we're going to trap the
> > entire PAGE_SIZE range overlapping the quirk out to QEMU on guest
> > access.  The two registers at 0x2000 might be reserved for this
> > purpose, but is there anything else that could be performance sensitive
> > anywhere in that page?  If so, it might be less transparent, but more
> > efficient to invent a new quirk making use of config space (ex. adding
> > an emulated vendor capability somewhere known to be unused on the
> > device).  Thanks,
> > 
> > Alex  
> 
> Seems like that could be a problem if we're running with huge pages and
> overlapping msix tables.

FWIW, MSI-X tables are already getting trapped into QEMU for emulation.
We have a mechanism via x-msix-relocation=<OffAutoPCIBAR> in QEMU to
deal with that when it becomes a problem by emulating the MSI-X
structures in MMIO space that doesn't overlap with the actual device
(ie. virtually resizing or adding BARs).  The issue is what else can be
in that 4K page or will this device be supported on archs where the
system page size is >4K more so than huge pages (as in hugetlbfs or
transparent huge pages).  Thanks,

Alex



  reply	other threads:[~2020-05-13 19:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11 19:01 [PATCH v2 0/2] VMD endpoint passthrough support Jon Derrick
2020-05-11 19:01 ` Jon Derrick
2020-05-11 19:01 ` Jon Derrick
2020-05-11 19:01 ` [PATCH for QEMU v2] hw/vfio: Add VMD Passthrough Quirk Jon Derrick
2020-05-11 19:01   ` Jon Derrick
2020-05-11 19:01   ` Jon Derrick
2020-05-11 22:59   ` Alex Williamson
2020-05-11 22:59     ` Alex Williamson
2020-05-11 22:59     ` Alex Williamson
2020-05-13  0:35     ` Derrick, Jonathan
2020-05-13  0:35       ` Derrick, Jonathan
2020-05-13 17:55       ` Alex Williamson
2020-05-13 17:55         ` Alex Williamson
2020-05-13 17:55         ` Alex Williamson
2020-05-13 19:26         ` Derrick, Jonathan
2020-05-13 19:26           ` Derrick, Jonathan
2020-05-13 19:55           ` Alex Williamson [this message]
2020-05-13 19:55             ` Alex Williamson
2020-05-13 19:55             ` Alex Williamson
2020-05-11 19:01 ` [PATCH v2 1/2] PCI: vmd: Filter resource type bits from shadow register Jon Derrick
2020-05-11 19:01   ` Jon Derrick
2020-05-11 19:01   ` Jon Derrick
2020-05-11 19:01 ` [PATCH v2 2/2] PCI: vmd: Use Shadow MEMBAR registers for QEMU/KVM guests Jon Derrick
2020-05-11 19:01   ` Jon Derrick
2020-05-11 19:01   ` Jon Derrick

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=20200513135508.162809da@x1.home \
    --to=alex.williamson@redhat.com \
    --cc=andrzej.jakowski@linux.intel.com \
    --cc=hch@lst.de \
    --cc=helgaas@kernel.org \
    --cc=jonathan.derrick@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=virtualization@lists.linux-foundation.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.