> -----Original Message----- > From: Alexey G [mailto:x19...@gmail.com] > Sent: 22 March 2018 09:55 > To: Jan Beulich <jbeul...@suse.com> > Cc: Andrew Cooper <andrew.coop...@citrix.com>; Anthony Perard > <anthony.per...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>; Paul > Durrant <paul.durr...@citrix.com>; Roger Pau Monne > <roger....@citrix.com>; Wei Liu <wei.l...@citrix.com>; Stefano Stabellini > <sstabell...@kernel.org>; xen-devel@lists.xenproject.org > 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" <jbeul...@suse.com> wrote: > > >>>> On 22.03.18 at 01:31, <x19...@gmail.com> wrote: > >> On Wed, 21 Mar 2018 17:06:28 +0000 > >> Paul Durrant <paul.durr...@citrix.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
