> -----Original Message----- > From: Xen-devel <xen-devel-boun...@lists.xenproject.org> On Behalf Of Igor > Druzhinin > Sent: 03 April 2020 16:36 > To: Jan Beulich <jbeul...@suse.com> > Cc: Andrew Cooper <andrew.coop...@citrix.com>; roger....@citrix.com; > ian.jack...@eu.citrix.com; > w...@xen.org; xen-devel@lists.xenproject.org > Subject: Re: [PATCH] hvmloader: probe memory below 4G before allocation for > OVMF > > On 03/04/2020 16:28, Jan Beulich wrote: > > On 03.04.2020 17:17, Igor Druzhinin wrote: > >> On 03/04/2020 16:05, Jan Beulich wrote: > >>> On 03.04.2020 16:47, Igor Druzhinin wrote: > >>>> There multiple technical complications that caused this mess. > >>>> One of them is that there is no unfortunately a better place for the > >>>> framebuffer to be located initially. Second, SR-IOV device > >>>> is real and adding a virtual BAR to it is also complicated (due to > >>>> compatibility reasons) and NVIDIA decided to avoid that. > >>> > >>> In which case I wonder - aren't you ending up with the MMIO case > >>> that I had mentioned, and that you said is difficult to deal with? > >> > >> No, it's VRAM area (normal RAM pages) - not MMIO. > > > > Well, VRAM is still MMIO from the CPU's perspective, just without > > any side effects. But if it was another device that was passed > > through, couldn't its MMIO similarly end up in that area? > > As Andrew said, Xen VRAM is just normal RAM. It's originally > populated in this area for the lack of a better place (at least now). > It's special and has nothing to do with the device passed through > using conventional PCI mechanisms which BARs will only occupy MMIO hole. >
I assume Jan's point is that the guest doesn't access it as if it is normal RAM. It's only accessed directly if it is present in a PCI BAR, otherwise it is accessed indirectly (via QEMU) in response to accesses to the VGA aperture. Paul
