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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-06-17 at 13:11 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 17/06/15 11:08, 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.
> 
> By default, the OS doesn't setup the BARs, it expects the firmware to do
> it.

_By_default_, yes. But it can decide to rewrite the BARs if it wants,
Linux for example has command line options to do so.

Maybe we have the option to exclude this possibility. It would certainly
simplify things. (Which makes most of the rest of your reply moot).

Ian.


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