qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stuart Yoder <b08248@gmail.com>, "agraf@suse.de" <agraf@suse.de>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Yoder Stuart-B08248 <B08248@freescale.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	Bhushan Bharat-R65777 <R65777@freescale.com>
Subject: Re: [Qemu-devel] RFC: vfio API changes needed for powerpc
Date: Tue, 2 Apr 2013 17:13:48 -0500	[thread overview]
Message-ID: <1364940828.24520.26@snotra> (raw)
In-Reply-To: <1364937371.2882.166.camel@bling.home> (from alex.williamson@redhat.com on Tue Apr  2 16:16:11 2013)

On 04/02/2013 04:16:11 PM, Alex Williamson wrote:
> On Tue, 2013-04-02 at 15:54 -0500, Stuart Yoder wrote:
> > The number of windows is always power of 2 (and max is 256).  And  
> to reduce
> > PAMU cache pressure you want to use the fewest number of windows
> > you can.    So, I don't see practically how we could transparently
> > steal entries to
> > add the MSIs.     Either user space knows to leave empty windows for
> > MSIs and by convention the kernel knows which windows those are (as
> > in option #A) or explicitly tell the kernel which windows (as in  
> option #B).
> 
> Ok, apparently I don't understand the API.  Is it something like
> userspace calls GET_ATTR and finds out that there are 256 available
> windows, userspace determines that it needs 8 for RAM and then it has  
> an
> MSI device, so it needs to call SET_ATTR and ask for 16?  That seems
> prone to exploitation by the first userspace to allocate it's  
> aperture,

What exploitation?

It's not as if there is a pool of 256 global windows that users  
allocate from.  The subwindow count is just how finely divided the  
aperture is.  The only way one user will affect another is through  
cache contention (which is why we want the minimum number of subwindows  
that we can get away with).

> but I'm also not sure why userspace could specify the (non-power of 2)
> number of windows it needs for RAM, then VFIO would see that the  
> devices
> attached have MSI and add those windows and align to a power of 2.

If you double the subwindow count without userspace knowing, you have  
to double the aperture as well (and you may need to grow up or down  
depending on alignment).  This means you also need to halve the maximum  
aperture that userspace can request.  And you need to expose a  
different number of maximum subwindows in the IOMMU API based on  
whether we might have MSIs of this type.  It's ugly and awkward, and  
removes the possibility for userspace to place the MSIs in some unused  
slot in the middle, or not use MSIs at all.

-Scott

  reply	other threads:[~2013-04-02 22:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-02 17:32 [Qemu-devel] RFC: vfio API changes needed for powerpc Yoder Stuart-B08248
2013-04-02 19:39 ` Scott Wood
2013-04-02 20:38   ` Stuart Yoder
2013-04-02 20:47     ` Scott Wood
2013-04-02 20:58       ` Stuart Yoder
2013-04-02 20:32 ` Alex Williamson
2013-04-02 20:54   ` Stuart Yoder
2013-04-02 21:16     ` Alex Williamson
2013-04-02 22:13       ` Scott Wood [this message]
2013-04-03  2:54         ` Alex Williamson
2013-04-02 20:57   ` Scott Wood
2013-04-02 21:08     ` Stuart Yoder
2013-04-02 21:38       ` Alex Williamson
2013-04-02 22:50         ` Scott Wood
2013-04-03  3:37           ` Alex Williamson
2013-04-03 19:09             ` Stuart Yoder
2013-04-03 19:18               ` Scott Wood
2013-04-03 19:43                 ` Stuart Yoder
2013-04-03 20:00                   ` Scott Wood
2013-04-03 19:23               ` Alex Williamson
2013-04-03 19:26               ` Scott Wood
2013-04-03 21:19             ` Scott Wood
2013-04-03 18:32           ` Stuart Yoder
2013-04-03 18:39             ` Scott Wood
2013-04-02 21:55       ` Scott Wood
2013-04-02 21:32     ` Alex Williamson
2013-04-02 22:44       ` Scott Wood
2013-04-03  3:12         ` Alex Williamson
2013-04-03 18:25           ` Stuart Yoder
2013-04-03 21:25           ` Scott Wood

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=1364940828.24520.26@snotra \
    --to=scottwood@freescale.com \
    --cc=B07421@freescale.com \
    --cc=B08248@freescale.com \
    --cc=R65777@freescale.com \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=b08248@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kvm@vger.kernel.org \
    --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).