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 03:04:16 -0600
"Jan Beulich" <JBeulich@xxxxxxxx> wrote:

>>>> On 22.03.18 at 01:31, <x1917x@xxxxxxxxx> wrote:  
>> 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.  
>
>I think you want to view this the other way around: No physical
>device would ever get to see MMCFG accesses (or CF8/CFC port
>ones). This same layering is what we should have in the
>virtualized case.

We have purely virtual layout of the PCI bus along with virtual,
emulated and completely unrelated to host's MMCONFIG -- so what's
exposed? This emulated MMCONFIG simply a supplement to virtual PCI bus
and its layout correspond to the virtual PCI bus guest/QEMU see.

It's QEMU who controls chipset-specific PCIEXBAR emulation and knows
about MMCONFIG position and size. QEMU informs Xen about where it is,
in order to receive events about R/W accesses to this emulated area --
so, why he should receive these events in a form of PCI conf BDF/reg and
not simply as MMCONFIG offset directly if it is basically the same
thing?

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