Re: [Xen-devel] PCI Passthrough ARM Design : Draft1

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 17 Jun 2015, Ian Campbell wrote:
> On Tue, 2015-06-16 at 18:16 +0100, Stefano Stabellini wrote:
> > I wrote this before reading the rest of the thread with your alternative
> > suggestion.  Both approaches can work, maybe it is true that having the
> > guest requesting mappings is better. And we should certainly do the same
> > thing for PVH and ARM guests.
> > 
> > If we have the guest requesting the mapping, obviously the hypercall
> > implementation should check whether mapping the memory region has been
> > previously allowed by the toolstack, that should still call
> > xc_domain_iomem_permission.
> 
> Whoever makes the initial decision/setup we still need to decide what to
> do about reads and writes to the device's BAR registers. Who deals with
> these and how, and if writes are allowed and if so how is this then
> reflected in the guest p2m.
> 
> I would very much prefer ARM and x86 PVH to use the same approach to
> this.
> 
> For x86 HVM I believe QEMU takes care of this, by emulating the
> reads/writes to CFG space and making hypercalls (domctls?) to update the
> p2m. There is no QEMU to do this in the ARM or x86 PVH cases.
> 
> For x86 PV I believe pciback deals with the register reads/writes but it
> doesn't need to do anything wrt the p2m because that is a guest internal
> construct. This obviously doesn't apply to ARM or x86 PVH either since
> the p2m is managed by Xen in both those cases.
> 
> So it seems that neither of the existing solutions are a good match for
> either ARM or x86 PVH.
> 
> _If_ it were permissible to implement all BAR registers as r/o then this
> might simplify things, however I suspect this is not something we can
> get away with in the general case (i.e. a driver for a given PCI device
> _knows_ that BAR<N> is writeable...).
> 
> So I think we do need to allow guest writes to the BAR registers. I
> think it would be a bit strange (or even open potentially subtle
> (security?) issues) to require the guest to write the BAR register and
> to update the p2m to match as well.

Why would it be a security risk? I don't think it is important that the
interface between pcifront and pciback refrects the hardware interface.
But it is important that the interface is documented and complies to the
expected behaviour.

I think that if we go with XENMEM_add_to_physmap_range, it would be OK
for pcifront to both write to the vBAR (actually writing to the ring to
pciback), then call XENMEM_add_to_physmap_range.

On the other hand, if we go with XEN_DOMCTL_memory_mapping, I would make
the virtual BAR read-only, that is less preferable but still acceptable,
as long as we document it.


> So I think updates to the BAR need to be reflected in the p2m too by
> whichever entity is emulating those reads/writes.

I wouldn't make this a requirement.


> QEMU (or another daemon) is not really an option IMHO.

I agree!


> Which leaves us with either Xen doing trap and emulate or pciback
> dealing with this via the pciif.h cfg space access stuff. I've a slight
> preference for the latter since I think both ARM and x86 PVH are
> planning to use pcifront/pciback already.

I also agree that between these two options, pciback is better. But
XENMEM_add_to_physmap_range is still the simplest.


> Which leaves us with a requirement for the backend to be able to update
> the p2m, which in turn leads to a need for an interface available to the
> dom0 kernel (which the existing domctl is not).
> 
> There will also need to be a mechanism to expose a suitable MMIO hole to
> pcifront. On x86 this would be via the machine memory map, I think, but
> on ARM we may need something else, perhaps a xenstore key associated
> with the pci bus entry in xenstore?

Can't we just let the guest kernel find an address range large enough
that is not normal memory?


> That's for guests, for dom0 Xen also need to be aware of changes to the
> BAR registers of the real physical devices since it needs to know the
> real hardware values in order to point guest p2m mappings at them.

I think that in the Dom0 case, we want to map them 1:1.

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