Re: Xen virtual IOMMU high level design doc

From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: Lan Tianyu <tianyu.lan@intel.com>
Cc: "yang.zhang.wz@gmail.com" <yang.zhang.wz@gmail.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xuquan8@huawei.com" <xuquan8@huawei.com>,
	Julien Grall <julien.grall@arm.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"anthony.perard@citrix.com" <anthony.perard@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: Xen virtual IOMMU high level design doc
Date: Thu, 24 Nov 2016 14:37:49 +0100	[thread overview]
Message-ID: <20161124133749.GC9606@toto> (raw)
In-Reply-To: <f1f5ffa6-d047-fd20-8bd5-1d5f7aee444e@intel.com>

On Thu, Nov 24, 2016 at 02:49:41PM +0800, Lan Tianyu wrote:
> On 2016年11月24日 12:09, Edgar E. Iglesias wrote:
> >>>> Hi,
> >>>> > > >
> >>>> > > > I have a few questions.
> >>>> > > >
> >>>> > > > If I understand correctly, you'll be emulating an Intel IOMMU in Xen.
> >>>> > > > So guests will essentially create intel iommu style page-tables.
> >>>> > > >
> >>>> > > > If we were to use this on Xen/ARM, we would likely be modelling an ARM
> >>>> > > > SMMU as a vIOMMU. Since Xen on ARM does not use QEMU for emulation, the
> >>>> > > > hypervisor OPs for QEMUs xen dummy IOMMU queries would not really be used.
> >>>> > > > Do I understand this correctly?
> >>> > > 
> >>> > > I think they could be called from the toolstack. This is why I was
> >>> > > saying in the other thread that the hypercalls should be general enough
> >>> > > that QEMU is not the only caller.
> >>> > > 
> >>> > > For PVH and ARM guests, the toolstack should be able to setup the vIOMMU
> >>> > > on behalf of the guest without QEMU intervention.
> > OK, I see. Or, I think I understand, not sure :-)
> > 
> > In QEMU when someone changes mappings in an IOMMU there will be a notifier
> > to tell caches upstream that mappings have changed. I think we will need to
> > prepare for that. I.e when TCG CPUs sit behind an IOMMU.
> 
> For Xen side, we may notify pIOMMU driver about mapping change via
> calling pIOMMU driver's API in vIOMMU.

I was refering to the other way around. When a guest modifies the mappings
for a vIOMMU, the driver domain with QEMU and vDevices needs to be notified.

I couldn't find any mention of this in the document...

> 
> > 
> > Another area that may need change is that on ARM we need the map-query to return
> > the memory attributes for the given mapping. Today QEMU or any emulator 
> > doesn't use it much but in the future things may change.

What about the mem attributes?
It's very likely we'll add support for memory attributes for IOMMU's in QEMU
at some point.
Emulated IOMMU's will thus have the ability to modify attributes (i.e SourceID's,
cacheability, etc). Perhaps we could allocate or reserve an uint64_t
for attributes TBD later in the query struct.

> > 
> > For SVM, whe will also need to deal with page-table faults by the IOMMU.
> > So I think there will need to be a channel from Xen to Guesrt to report these.
> 
> Yes, vIOMMU should forward the page-fault event to guest. For VTD side,
> we will trigger VTD's interrupt to notify guest about the event.

OK, Cool.

Perhaps you should document how this (and the map/unmap notifiers) will work?

I also think it would be a good idea to add a little more introduction so that
some of the questions we've been asking regarding the general design are easier
to grasp.

Best regards,
Edgar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel