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

[Alexey G <x1917x@xxxxxxxxx>]

On Thu, 22 Mar 2018 10:09:16 +0000
Paul Durrant <Paul.Durrant@xxxxxxxxxx> wrote:
[...]
>> > 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.  

I guess QEMU guys will tell that it will actually improve. :)
One of the very first observation I made while learning Xen/QEMU was
that Xen and QEMU behave sort of like stepmother and stepdaughter --
dislike each other but have to live together in one house for now.
I think a better interaction will benefit both.

There are some architectural issues (MMIO hole control for passthrough
needs is one of them) which can be solved by actually improving
coordination with QEMU, while not sacrificing the security in any way.

>> > 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.  

Emulated PCIe Switch (PCI-PCI bridge basically) can be considered a
discrete peripheral device which can function alone?

If we should emulate the whole PCIe bus, where will be the dividing
line between chipset emulation and PCIe hierarchy emulation?

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