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

From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Alexey G <x1917x@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring
Date: Wed, 21 Mar 2018 15:20:17 +0000	[thread overview]
Message-ID: <20180321152017.bv32mt4bpxaa7zfr@MacBook-Pro-de-Roger.local> (raw)
In-Reply-To: <20180322002540.000032f1@gmail.com>

On Thu, Mar 22, 2018 at 12:25:40AM +1000, Alexey G wrote:
> Roger, Paul,
> 
> Here is what you suggest, just to clarify:
> 
> 1. Add to Xen a new hypercall (+corresponding dmop) so QEMU can tell
> Xen where QEMU emulates machine's MMCONFIG (chipset-specific emulation
> of PCIEXBAR/HECBASE/etc mmcfg relocation). Xen will rely on this
> information to know to which PCI device the address within MMCONFIG
> belong.
> 
> 2. Xen will trap this area + remap its trapping to other address if QEMU
> will inform Xen about emulated PCIEXBAR value change
> 
> 3. Every MMIO access to the current MMCONFIG range will be converted
> into BDF first (by offset within this range, knowing where the range is)
> 
> 4. Target device model is selected using calculated BDF
> 
> 5. MMIO read/write accesses are converted into PCI config space ioreqs
> (like it was a CF8/CFCh operation instead of MMIO access). At this
> point ioreq structure allows to specify extended PCI conf offset
> (12-bit), so it will fit into PCI conf ioreq. For now let's assume that
> eg. a 64-bit memory operation is either aborted or workarounded by
> splitting this operation into multiple PCI conf ioreqs.

Why can't you just set size = 8 in that case in the ioreq?

QEMU should then reject those if the chipset doesn't support 64bit
accesses. I cannot find in the spec any mention of whether this
chipset supports 64bit MCFG accesses, and according to the PCIe spec
64bit accesses to MCFG should not be used unless the chipset is known
to handle them correctly.

> 6. PCI conf read/write ioreqs are sent to the chosen device model
> 
> 7. QEMU receive MMCONFIG memory reads/writes as PCI conf reads/writes
> 
> 8. As these MMCONFIG PCI conf reads occur out of context (just
> address/len/data without any emulated device attached to it), xen-hvm.c
> should employ special logic to make it QEMU-friendly -- eg. right now
> it sends received PCI conf access into (emulated by QEMU) CF8h/CFCh
> ports.
> There is a real problem to embed these "naked" accesses into QEMU
> infrastructure, workarounds are required. BTW, find_primary_bus() was
> dropped from QEMU code -- it could've been useful here. Let's assume
> some workaround is employed (like storing a required object pointers in
> global variables for later use in xen-hvm.c)

That seems like a minor nit, but why not just use
address_space_{read/write} to replay the MCFG accesses as memory
read/writes?

> 
> 9. Existing MMCONFIG-handling code in QEMU will be unused in this
> scenario

If you replay the read/write I don't think so. In any case this is
irrelevant. QEMU CPU emulation code is also unused when running under
Xen.

> 10. All this needed primarily to make the specific "Multiple device
> emulators" feature to work (XenGT was mentioned as its user) on Q35
> with MMCONFIG.
> 
> Anything wrong/missing here?

I think that's correct.

Thanks, Roger.

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