Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Roger Pau Monne
> Sent: 22 March 2018 10:06
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: 'Alexey G' <x1917x@xxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx;
> Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Ian Jackson
> <Ian.Jackson@xxxxxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>; Wei Liu
> <wei.liu2@xxxxxxxxxx>; Anthony Perard <anthony.perard@xxxxxxxxxx>;
> Stefano Stabellini <sstabellini@xxxxxxxxxx>
> Subject: Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG
> area in the MMIO hole + minor code refactoring
> 
> On Thu, Mar 22, 2018 at 09:29:44AM +0000, Paul Durrant wrote:
> > > The more I think about it, the more I like the existing
> > > map_io_range_to_ioreq_server() approach. :( It works without doing
> > > anything, no hacks, no new interfaces, both MMCONFIG and CF8/CFC are
> > > working as expected. There is a problem to make it compatible with
> > > the specific multiple ioreq servers feature, but providing a new
> > > dmop/hypercall (which you suggest is a must have thing to trap
> MMCONFIG
> > > MMIO to give QEMU only the freedom to tell where it is located) allows
> > > to solve this problem in any possible way, either MMIO -> PCI conf
> > > translation or anything else.
> > >
> >
> > I don't think we even want QEMU to have the freedom to say where the
> > MMCONFIG areas are located, do we?
> 
> Sadly this how the chipset works. The PCIEXBAR register contains the
> position of the MCFG area. And this is emulated by QEMU.

So we should be emulating that in Xen, not handing it off to QEMU. Our 
integration with QEMU is already terrible and using QEMU to emulate the PCIe 
chipset will only make it worse.

> 
> > QEMU is not in charge of the
> > guest memory map and it is not responsible for the building the MCFG
> > table, Xen is.
> 
> Well, the one that builds the MCFG table is hvmloader actually, which
> is the one that initially sets the value of PCIEXBAR and thus the
> initial position of the MCFG.
> 
> > So it should be Xen that decides where the MMCONFIG
> > area goes for each registered PCI device and it should be Xen that
> > adds that to the MCFG table. It should be Xen that handles the
> > MMCONFIG MMIO accesses and these should be forwarded to QEMU as
> PCI
> > config IOREQs.  Now, it may be that we need to introduce a Xen
> > specific mechanism into QEMU to then route those config space
> > transactions to the device models but that would be an improvement
> > over the current cf8/cfc hackery anyway.
> 
> I think we need a way for QEMU to tell Xen the position of the MCFG
> area, and any changes to it.
> 
> I don't think we want to emulate the PCIEXBAR register inside of Xen,
> if we do that then we would likely have to emulate the full Express
> Chipset inside of Xen.
> 

No, that's *exactly* what we should be doing. We should only be using QEMU for 
emulation of discrete peripheral devices.

  Paul

> Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel