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 10:06:09 +0000
Paul Durrant <Paul.Durrant@xxxxxxxxxx> wrote:

>> -----Original Message-----
>> From: Alexey G [mailto:x1917x@xxxxxxxxx]
>> Sent: 22 March 2018 09:55
>> To: Jan Beulich <JBeulich@xxxxxxxx>
>> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Anthony Perard
>> <anthony.perard@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>;
>> Paul Durrant <Paul.Durrant@xxxxxxxxxx>; Roger Pau Monne
>> <roger.pau@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; Stefano
>> Stabellini <sstabellini@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate
>> MMCONFIG area in the MMIO hole + minor code refactoring
>> 
>> 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.  
>
>...and I think that it the wrong solution for Xen. We only use QEMU as
>an emulator for peripheral devices; we should not be using it for this
>kind of emulation... that should be brought into the hypervisor.
>
>> QEMU informs Xen about where it is,  
>
>No. Xen should not care where QEMU wants to put it because the MMIO
>emulations should not even read QEMU.

QEMU does a lot of MMIO emulation, what's so special in the emulated
MMCONFIG? It has absolutely nothing to do with host's MMCONFIG, neither
in address/size or the internal layout. None of the host
MMCONFIG-related facilities touched in any way. It is purely virtual
thing.

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.

>   Paul
>
>> 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