From: Will Deacon <will.deacon@arm.com>
To: Varun Sethi <Varun.Sethi@freescale.com>
Cc: "iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"tech@virtualopensystems.com" <tech@virtualopensystems.com>,
Baptiste Reynal <b.reynal@virtualopensystems.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC 0/6] vSMMU initialization
Date: Tue, 14 Jul 2015 12:04:16 +0100 [thread overview]
Message-ID: <20150714110416.GD16213@arm.com> (raw)
In-Reply-To: <BN1PR0301MB06274ACB3A193799F40BE9F4EA9B0@BN1PR0301MB0627.namprd03.prod.outlook.com>
On Tue, Jul 14, 2015 at 03:21:03AM +0100, Varun Sethi wrote:
> Hi Will,
Hi Varun,
> > On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote:
> > > The ARM SMMU has support for 2-stages address translations, allowing a
> > > virtual address to be translated at two levels:
> > > - Stage 1 translates a virtual address (VA) into an intermediate
> > > physical address (IPA)
> > > - Stage 2 translates an IPA into a physical address (PA)
> > >
> > > Will Deacon introduced a virtual SMMU interface for KVM, which gives a
> > > virtual machine the possibility to use an IOMMU with native drivers.
> > > While the VM will program the first stage of translation (stage 1),
> > > the interface will program the second (stage 2) on the physical SMMU.
> >
> > Please note that I have no plans to merge the kernel-side of this at the
> > moment. It was merely an exploratory tool to see what a non-PV vSMMU
> > implementation might look like and certainly not intended to be used in
> > anger.
> How do you see the context fault reporting work for the PV interface?
We could have an interrupt, for the PV IOMMU and have the hypervisor
inject that, no?
> Currently the vSMMU interface does seem quiet restrictive and it may
> simplify things by having PV iommu interface. But, do you see this even
> true in case of SMMUv3?
I think SMMUv3 is *far* more amenable to the vSMMU approach, largely
because it moves many of the data structures into memory, but also because
it has support for things like ATS and PRI, so sharing page tables with
the CPU becomes a real possibility (and is something that doesn't work
well with a PV model).
> Just wondering if we can give more control with respect memory transaction
> attributes to the guest. Also, would it make sense to give guest control
> of the fault handling attributes i.e. fault/terminate model.
I'd like to see the basics prototyped before we start trying to design
for these more advanced use-cases. I'm confident there are plenty of things
we haven't even considered at the moment.
Will
next prev parent reply other threads:[~2015-07-14 11:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 14:20 [Qemu-devel] [RFC 0/6] vSMMU initialization Baptiste Reynal
2015-06-12 14:20 ` [Qemu-devel] [RFC 1/6] headers sync Baptiste Reynal
2015-06-12 14:20 ` [Qemu-devel] [RFC 2/6] hw/core/platform-bus: initialization notifier Baptiste Reynal
2015-06-12 14:20 ` [Qemu-devel] [RFC 3/6] hw/core/platform-bus: add base_address field Baptiste Reynal
2015-06-12 14:20 ` [Qemu-devel] [RFC 4/6] hw/vfio: vsmmu device Baptiste Reynal
2015-06-12 14:20 ` [Qemu-devel] [RFC 5/6] hw/arm/sysbus-fdt: enable vsmmu dynamic instantiation Baptiste Reynal
2015-06-12 14:20 ` [Qemu-devel] [RFC 6/6] hw/arm/sysbus-fdt: add smmu masters in device tree Baptiste Reynal
2015-06-12 14:23 ` [Qemu-devel] [RFC 0/6] vSMMU initialization Will Deacon
2015-07-14 2:21 ` Varun Sethi
2015-07-14 11:04 ` Will Deacon [this message]
2015-07-15 13:38 ` Baptiste Reynal
2015-07-15 13:42 ` Will Deacon
2015-07-15 16:41 ` Varun Sethi
2015-07-15 17:28 ` Varun Sethi
2015-07-15 17:37 ` Will Deacon
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=20150714110416.GD16213@arm.com \
--to=will.deacon@arm.com \
--cc=Varun.Sethi@freescale.com \
--cc=b.reynal@virtualopensystems.com \
--cc=iommu@lists.linux-foundation.org \
--cc=qemu-devel@nongnu.org \
--cc=tech@virtualopensystems.com \
/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).