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

   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