[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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. > 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. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |