Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-09-02 at 08:52 -0600, Jan Beulich wrote:
> > 
> > > > On 02.09.15 at 16:45, <ian.campbell@xxxxxxxxxx> wrote:
> > On Fri, 2015-08-14 at 08:34 -0600, Jan Beulich wrote:
> > > > > > On 14.08.15 at 16:03, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > > > On Fri, 14 Aug 2015, Jan Beulich wrote:
> > > > > > > > On 14.08.15 at 15:21, <stefano.stabellini@xxxxxxxxxxxxx> 
> > > > > > > > wrote:
> > > > > > On Fri, 14 Aug 2015, Jan Beulich wrote:
> > > > > > > it's even less clear how you'd expect to suppress this in 
> > > > > > > other 
> > > > > > > guest
> > > > > > > OSes (Windows - afaik - being able to run on ARM certainly 
> > > > > > > makes 
> > > > > > > it
> > > > > > > a candidate guest, even if maybe this doesn't work today), 
> > > > > > > namely
> > > > > > > such not having any pcifront. And I hope this design 
> > > > > > > discussion 
> > > > > > > isn't
> > > > > > > limiting itself to Linux guests.
> > > > > > 
> > > > > > We'll write down in the ABI documentation that BARs 
> > > > > > reassignments 
> > > > > > are
> > > > > > not supported.
> > > > > 
> > > > > I.e. guests doing so Will Not Work (TM), with users (usually not 
> > > > > reading
> > > > > ABI docs) learning it the hard way. Not nice, but a way to handle 
> > > > > it.
> > > > 
> > > > The target of the ABI docs is not users, but kernel developers, who
> > > > should most definitely read them and fix their kernels.
> > > 
> > > ??? (We're talking of unmodified, closed source OSes here.)
> > 
> > On x86 such unmodified OSes would not use pciif.h/pcifront/back, 
> > instead
> > they would be an HVM guest and get an HVM PCI bus emulated by the 
> > device
> > model, which would (I suppose) support remapping BARs etc, since as you 
> > say
> > unmodified OSes may require that.
> > 
> > AFAIK pcifront/back doesn't work for x86/HVM guests today, or at least 
> > not
> > in general for "unmodified, closed source OSes".
> > 
> > AIUI it is the case today (and has always been the case) that x86/PV 
> > guests
> > using pcifront/pciback cannot rewrite BARS, except to either all 1's or
> > their original value (this is needed to probe the size or something 
> > AIUI).
> > This is my reading of linux/drivers/xen/xen
> > -pciback/conf_space_header.c:bar_write at least, which says:
> >     /* For the BARs, only allow writes which write ~0 or
> >      * the correct resource information
> >      * (Needed for when the driver probes the resource usage)
> >      */
> > 
> > ARM here is following the x86/PV model for PCI, not the x86/HVM 
> > emulated
> > one.
> 
> I understood it that way, but my point is - how are you ever going to
> support e.g. Windows guests on ARM? Are you really making yourself
> dependent upon MS adding a Xen PCI frontend to it?

Supporting completely unmodified/unaware (so not even PVHVM) OSes on ARM
would require adding the concept of a device model, much like for x86/HVM.
The DM would have to provide the emulated style PCI bus alongside all the
other emulated hardware such a Windows guest would certainly require.

Maybe we can do that as an extension to the existing ARM guest, rather than
adding a second guest type like x86 has (and is moving away from with the
PVH stuff).

Ian.

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