RE: [PATCH] hvmloader: probe memory below 4G before allocation for OVMF

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Igor 
> Druzhinin
> Sent: 03 April 2020 16:36
> To: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; roger.pau@xxxxxxxxxx; 
> ian.jackson@xxxxxxxxxxxxx;
> wl@xxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx
> 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