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

[Alexey G <x1917x@xxxxxxxxx>]

On Wed, 21 Mar 2018 17:06:28 +0000
Paul Durrant <Paul.Durrant@xxxxxxxxxx> wrote:
[...]
>> Well, this might work actually. Although the overall scenario will be
>> overcomplicated a bit for _PCI_CONFIG ioreqs. Here is how it will
>> look:
>> 
>> QEMU receives PCIEXBAR update -> calls the new dmop to tell Xen new
>> MMCONFIG address/size -> Xen (re)maps MMIO trapping area -> someone
>> is
>> accessing this area -> Xen intercepts this MMIO access
>> 
>> But here's what happens next:
>> 
>> Xen translates MMIO access into PCI_CONFIG and sends it to DM ->
>> DM receives _PCI_CONFIG ioreq -> DM translates BDF/addr info back to
>> the offset in emulated MMCONFIG range -> DM calls
>> address_space_read/write to trigger MMIO emulation
>>   
>
>That would only be true of a dm that cannot handle PCI config ioreqs
>directly.

It's just a bit problematic for xen-hvm.c (Xen ioreq processor in QEMU).

It receives these PCI conf ioreqs out of any context. To workaround
this, existing code issues I/O to emulated CF8h/CFCh ports in order to
allow QEMU to find their target. But we can't use the same method for
MMCONFIG accesses -- this works for basic PCI conf space only.

We need to either locate PCIBus/PCIDevice manually via object lookups
and then proceed to something like pci_host_config_read_common(), or to
convert the PCI conf access into the emulated MMIO access... again, a
required piece of information is missing -- we need to somehow learn the
current MMCONFIG address to recreate the memory address to be emulated.

Let's put it simply -- the goal to make PCI conf ioreqs to reach their
MMCONFIG targets in xen-hvm.c is easily achievable but it will look like
a hack. MMIO ioreqs are preferable for MMCONFIG -- no extra logic
needed for them, we can directly pass them for emulation in a way
somewhat reminiscent of CF8h/CFCh replay, except for memory.

Ideally it would be PCI conf ioreq translation for supplemental device
emulators while skipping this translation for QEMU. QEMU expects PCI
config ioreqs only for CF8/CFC accesses. I assume it's DEMU/VGPU which
of primary concern here, not experimental users like XenGT.

>  Paul
>
>> I tnink some parts of this equation can be collapsed, isn't it?
>> 
>> Above scenario makes it obvious that at least for QEMU the MMIO->PCI
>> conf translation is a redundant step. Why not to allow specifying
>> for DM whether it prefers to receive MMCONFIG accesses as native
>> (MMIO ones) or as translated PCI conf ioreqs? We can still route
>> either ioreq type to multiple device emulators accordingly.
>> 
>> This will be the most universal and consistent approach -- either
>> _COPY or _PCI_CONFIG-type ioreqs can be sent to DM, whatever it
>> likes more. 
>> >> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel