[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Unshared IOMMU issues

Hi Jan,

On 17/02/17 07:43, Jan Beulich wrote:
Well, in the end it's your call, but I don't think this is an acceptable
model in the general case. Quite often - see the Viridian support in
x86 Xen for a very good example - distros (XenServer in this case)
enable functionality even if a guest (Linux in the case here) would
never really want to make use of it. Also you need to keep in mind
that for an admin it is better to not have to take care of all
eventualities before first starting a (perhaps long running) guest.
Granted we have a number of other limitations of that same kind,
but if such can be avoided, I'd always prefer to do so.

To be fair, in server side, the SBSA [1] mandates the IOMMU to be compatible with ARM SMMU spec. This is allowing us to share page table by default with the SMMU. Today the driver does not support unsharing and I don't know yet any use case requiring to unshare them.

For embedded side, I would be surprised if they use PCI hotplug. So populate IOMMU page table from domain creating is not a big concern.

As this would be an interface between Xen and the toolstack, we could revisit later if we have platform where page table are not shared and hotplug is been used.

2. The d->page_list seems only contains domain RAM (not 100% sure).
Where can I get other regions (mmios, etc)?

These necessarily are being tracked for the domain, so you need to
take them from wherever they're stored on ARM.

Is there any reason why you don't seem to have such code on x86? AFAICT
only RAM is currently mapped.

Well, no-one care so far, I would guess. Even runtime mappings of
MMIO space were mad work properly only very recently (by Roger).

Regarding ARM, we know whether a domain is allowed to access a certain
range of MMIO, but, similarly to above, we don't have the conversion MFN
-> GFN for them. However in this case, we would not be able to use an
M2P as a same MFN may be mapped in multiple domain.

Mapped by multiple domains? If one DomU and Dom0, I can see
this as possible, but not a requirement. If multiple DomU-s I have
to raise the question of security.

The interrupt controller GICv2 supports virtualization and allow the
guest to manage interrupt as it was running on baremetal. There is a
per-CPU interface that is mapped on every domain. Obviously, the state
is saved/restored during vCPU context switch.

Now that looks like a very special case, which the code doing the
mapping could (and should) be aware of. Quite likely this area
even gets mapped at a predetermined GFN (range) for guests
(in which case no lookup is necessary at all)?

Yes we can in this case.


[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html

Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.