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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Alexey G [mailto:x1917x@xxxxxxxxx]
> Sent: 22 March 2018 15:09
> 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>; StefanoStabellini
> <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 08:42:09 -0600
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
> >>>> 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.
> 
> Few related thoughts:
> 
> 1. MMCONFIG address is chipset-specific. On Q35 it's a PCIEXBAR, on
> other x86 systems it may be HECBASE or else. So we can assume it is
> bound to the emulated machine
> 

Xen emulates the machine so it should be emulating PCIEXBAR. 

> 2. We rely on QEMU to emulate different machines for us.
> 

We should not be. It's a historical artefact that we rely on QEMU for any part 
of machine emulation.

> 3. There are users which touch chipset-specific PCIEXBAR directly if
> they see a Q35 system (OVMF so far)
> 

And we should squash such accesses. The toolstack should be sole control of the 
guest memory map. It should be the only building MCFG so it should decide where 
the MMCONFIG regions go, not the firmware running in guest context.

> Seems like we're pretty limited in freedom of choice in this
> conditions, I'm afraid.

I don't think so. We're only limited if we use QEMU's Q35 emulation and what 
I'm saying is that we should not be doing that (nor should be we be using it to 
emulate any part of the PIIX today).

  Paul

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