From: Alex Williamson <alex.williamson@redhat.com>
To: Stuart Yoder <b08248@gmail.com>
Cc: chrisw@sous-sol.org, Alexey Kardashevskiy <aik@au1.ibm.com>,
kvm@vger.kernel.org, pmac@au1.ibm.com, joerg.roedel@amd.com,
konrad.wilk@oracle.com, qemu-devel@nongnu.org, agraf@suse.de,
aafabbri@cisco.com, B08248@freescale.com,
iommu@lists.linux-foundation.org, avi@redhat.com,
linux-pci@vger.kernel.org, dwg@au1.ibm.com, B07421@freescale.com,
benve@cisco.com
Subject: Re: [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework
Date: Tue, 29 Nov 2011 16:44:33 -0700 [thread overview]
Message-ID: <1322610273.19120.209.camel@bling.home> (raw)
In-Reply-To: <CALRxmdDEGwA787gEgC3d_yU99TqOZOtWeDJ9N-QCQ3gxV8yyMw@mail.gmail.com>
On Tue, 2011-11-29 at 17:20 -0600, Stuart Yoder wrote:
> >
> > BTW, github now has updated trees:
> >
> > git://github.com/awilliam/linux-vfio.git vfio-next-20111129
> > git://github.com/awilliam/qemu-vfio.git vfio-ng
>
> Hi Alex,
>
> Have been looking at vfio a bit. A few observations and things
> we'll need to figure out as it relates to the Freescale iommu.
>
> __vfio_dma_map() assumes that mappings are broken into
> 4KB pages. That will not be true for us. We normally will be mapping
> much larger physically contiguous chunks for our guests. Guests will
> get hugetlbfs backed memory with very large pages (e.g. 16MB,
> 64MB) or very large chunks allocated by some proprietary
> means.
Hi Stuart,
I think practically everyone has commented on the 4k mappings ;) There
are a few problems around this. The first is that iommu drivers don't
necessarily support sub-region unmapping, so if we map 1GB and later
want to unmap 4k, we can't do it atomically. 4k gives us the most
flexibility for supporting fine granularities. Another problem is that
we're using get_user_pages to pin memory. It's been suggested that we
should use mlock for this, but I can't find anything that prevents a
user from later munlock'ing the memory and then getting access to memory
they shouldn't have. Those kind of limit us, but I don't see it being
an API problem for VFIO, just implementation.
> Also, mappings will have additional Freescale-specific attributes
> that need to get passed through to dma_map somehow. For
> example, the iommu can stash directly into a CPU's cache
> and we have iommu mapping properties like the cache stash
> target id and an operation mapping attribute.
>
> How do you envision handling proprietary attributes
> in struct vfio_dma_map?
Let me turn the question around, how do you plan to support proprietary
attributes in the IOMMU API? Is the user level the appropriate place to
specify them, or are they an intrinsic feature of the domain? We've
designed struct vfio_dma_map for extension, so depending on how many
bits you need, we can make a conduit using the flags directly or setting
a new flag to indicate presence of an arch specific attributes field.
Thanks,
Alex
next prev parent reply other threads:[~2011-11-29 23:53 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-03 20:12 [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework Alex Williamson
2011-11-09 4:17 ` Aaron Fabbri
2011-11-09 4:41 ` Alex Williamson
2011-11-09 8:11 ` Christian Benvenuti (benve)
2011-11-09 18:02 ` Alex Williamson
2011-11-09 21:08 ` Christian Benvenuti (benve)
2011-11-09 23:40 ` Alex Williamson
2011-11-10 0:57 ` Christian Benvenuti (benve)
2011-11-11 18:04 ` Alex Williamson
2011-11-11 22:22 ` Christian Benvenuti (benve)
2011-11-14 22:59 ` Alex Williamson
2011-11-15 0:05 ` David Gibson
2011-11-15 0:49 ` Benjamin Herrenschmidt
2011-11-11 17:51 ` Konrad Rzeszutek Wilk
2011-11-11 22:10 ` Alex Williamson
2011-11-15 0:00 ` David Gibson
2011-11-16 16:52 ` Konrad Rzeszutek Wilk
2011-11-17 20:22 ` Alex Williamson
2011-11-17 20:56 ` Scott Wood
2011-11-16 17:47 ` Scott Wood
2011-11-17 20:52 ` Alex Williamson
2011-11-12 0:14 ` Scott Wood
2011-11-14 20:54 ` Alex Williamson
2011-11-14 21:46 ` Alex Williamson
2011-11-14 22:26 ` Scott Wood
2011-11-14 22:48 ` Alexander Graf
2011-11-15 2:29 ` Alex Williamson
2011-11-15 6:34 ` David Gibson
2011-11-15 18:01 ` Alex Williamson
2011-11-17 0:02 ` David Gibson
2011-11-18 20:32 ` Alex Williamson
2011-11-18 21:09 ` Scott Wood
2011-11-22 19:16 ` Alex Williamson
2011-11-22 20:00 ` Scott Wood
2011-11-22 21:28 ` Alex Williamson
2011-11-21 2:47 ` David Gibson
2011-11-22 18:22 ` Alex Williamson
2011-11-15 20:10 ` Scott Wood
2011-11-15 21:40 ` Aaron Fabbri
2011-11-15 22:29 ` Scott Wood
2011-11-16 23:34 ` Alex Williamson
2011-11-29 1:52 ` Alexey Kardashevskiy
2011-11-29 2:01 ` Alexey Kardashevskiy
2011-11-29 2:11 ` Alexey Kardashevskiy
2011-11-29 3:54 ` Alex Williamson
2011-11-29 19:26 ` Alex Williamson
2011-11-29 23:20 ` Stuart Yoder
2011-11-29 23:44 ` Alex Williamson [this message]
2011-11-30 15:41 ` Stuart Yoder
2011-11-30 16:58 ` Alex Williamson
2011-12-01 20:58 ` Stuart Yoder
2011-12-01 21:25 ` Alex Williamson
2011-12-02 14:40 ` Stuart Yoder
2011-12-02 18:11 ` Bhushan Bharat-R65777
2011-12-02 18:27 ` Scott Wood
2011-12-02 18:35 ` Bhushan Bharat-R65777
2011-12-02 18:45 ` Bhushan Bharat-R65777
2011-12-02 18:52 ` Scott Wood
2011-12-02 18:21 ` Scott Wood
2011-11-29 3:46 ` Alex Williamson
2011-11-29 4:34 ` Alexey Kardashevskiy
2011-11-29 5:48 ` Alex Williamson
2011-12-02 5:06 ` 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=1322610273.19120.209.camel@bling.home \
--to=alex.williamson@redhat.com \
--cc=B07421@freescale.com \
--cc=B08248@freescale.com \
--cc=aafabbri@cisco.com \
--cc=agraf@suse.de \
--cc=aik@au1.ibm.com \
--cc=avi@redhat.com \
--cc=b08248@gmail.com \
--cc=benve@cisco.com \
--cc=chrisw@sous-sol.org \
--cc=dwg@au1.ibm.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joerg.roedel@amd.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=pmac@au1.ibm.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).