[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 22.03.18 at 15:34, <x1917x@xxxxxxxxx> wrote:
> 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.

I'm afraid this is only part of the picture, as you've been told by
others before. We first of all need to settle on who emulates
the core chipset registers. Depending on that will be how Xen
would learn about the MCFG location inside the guest.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.