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 07:20:00 -0600
"Jan Beulich" <JBeulich@xxxxxxxx> wrote:

>>>> On 22.03.18 at 14:05, <x1917x@xxxxxxxxx> wrote:  
>> On Thu, 22 Mar 2018 06:09:44 -0600
>> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>   
>>>>>> On 22.03.18 at 12:56, <x1917x@xxxxxxxxx> wrote:    
>>>> I really don't understand why some people have that fear of
>>>> emulated MMCONFIG -- it's really the same thing as any other MMIO
>>>> range QEMU already emulates via map_io_range_to_ioreq_server(). No
>>>> sensitive information exposed. It is related only to emulated PCI
>>>> conf space which QEMU already knows about and use, providing
>>>> emulated PCI devices for it.    
>>>
>>>You continue to ignore the routing requirement multiple ioreq
>>>servers impose.  
>> 
>> If the emulated MMCONFIG approach will be modified to become
>> fully compatible with multiple ioreq servers (whatever they used
>> for), I assume there will be no objections that emulated MMCONFIG
>> can't be used?
>> I just want to clarify this moment -- why people think that
>> a completely emulated MMIO range, not related in any
>> way to host's MMCONFIG may compromise something.  
>
>Compromise? All that was said so far - afair - was that this is the
>wrong way round design wise.

I assume it's all about emulating some real system for HVM, for other
goals PV/PVH are available. What is a proper, design-wise way to
emulate the MMIO-based MMCONFIG range Q35 provides you think of?

Here is what I've heard so far in this thread:

1. Add a completely new dmop/hypercall so that QEMU can tell Xen where
emulated MMCONFIG MMIO area is located and in the same time map it for
MMIO trapping to intercept accesses. Latter action is the same what
map_io_range_to_ioreq_server() does, but let's ignore it for now
because there was opinion that we need to stick to a distinct hypercall.

2. Upon trapping accesses to this emulated range, Xen will pretend that
QEMU didn't just told him about MMCONFIG location and size and instead
convert MMIO access into PCI conf one and send the ioreq to QEMU or
some other DM.

3. If there will be a PCIEXBAR relocation (OVMF does it currently for
MMCONFIG usage, but we must later teach him non-QEMU manners), QEMU must
immediately inform Xen about any changes in MMCONFIG location/status.

4. QEMU receives PCI conf access while expecting the MMIO address, so
xen-hvm.c has to deal with it somehow, either obtaining MMCONFIG base
and recreating emulated MMIO access from BDF/reg or doing the dirty work
of finding PCIBus/PCIDevice target itself as it cannot use emulated
CF8/CFC ports due to legacy PCI conf size limitation.

Please confirm that it is a preferable solution or if something missing.

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