From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: PCI Pass-through in Xen ARM: Draft 4 Date: Wed, 2 Sep 2015 16:07:59 +0100 Message-ID: <1441206479.26292.242.camel@citrix.com> References: <55CC668F.80104@caviumnetworks.com> <55CCD3F1020000780009AC34@prv-mh.provo.novell.com> <1439485284.23981.129.camel@citrix.com> <55CDD04F020000780009AEDC@prv-mh.provo.novell.com> <55CE103D020000780009B132@prv-mh.provo.novell.com> <55CE189A020000780009B1C3@prv-mh.provo.novell.com> <1441205107.26292.225.camel@citrix.com> <55E72944020000780009F14B@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55E72944020000780009F14B@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: "Prasun.kapoor@cavium.com" , stefano.stabellini@eu.citrix.com, Manish Jaggi , Vijaya Kumar , JulienGrall , Xen Devel List-Id: xen-devel@lists.xenproject.org On Wed, 2015-09-02 at 08:52 -0600, Jan Beulich wrote: > > > > > > On 02.09.15 at 16:45, wrote: > > On Fri, 2015-08-14 at 08:34 -0600, Jan Beulich wrote: > > > > > > On 14.08.15 at 16:03, wrote: > > > > On Fri, 14 Aug 2015, Jan Beulich wrote: > > > > > > > > On 14.08.15 at 15:21, > > > > > > > > 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.