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
next prev parent 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).