Re: [Xen-devel] Xen virtual IOMMU high level design doc

["Xuquan (Quan Xu)" <xuquan8@xxxxxxxxxx>]

On November 24, 2016 9:38 PM, <edgar.iglesias@xxxxxxxxx>
>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...
>
>

Edgar,
As mentioned it supports VFIO-based user space driver (e.g. DPDK) in the guest.
I am afraid all of guest memory is pinned.. Lan, right?

Quan


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