Re: [Xen-devel] Limitation in HVM physmap

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxx] On Behalf Of George Dunlap
> Sent: 18 October 2013 15:26
> To: Wei Liu; Jan Beulich; Tim (Xen.org); Keir (Xen.org)
> Cc: Stefano Stabellini; Ian Campbell; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Limitation in HVM physmap
> 
> On 18/10/13 15:20, Wei Liu wrote:
> > Hi Jan, Tim and Keir
> >
> > I currently run into the limitation of HVM's physmap: one MFN can only
> > be mapped into one guest physical frame. Why is it designed like that?
> >
> > The scenario is that: when QEMU boots with OVMF (UEFI firmware), OVMF
> > will first map the framebuffer to 0x80000000, resulting the framebuffer
> > MFNs added to corresponding slots in physmap. A few moments later
> when
> > Linux kernel loads, it tries to map framebuffer MFNs to 0xf00000000,
> > which fails because those MFNs have already been mapped in other
> > locations. Is there a way to fix this?
> 
> If I understood our f2f conversation correctly, not only this, but after
> Linux has remapped it to 0xf, it makes calls into EFI which then access
> it again at 0x8.  So there is a period of time when it is accessed from
> both places.
> 
> (Correct me if I misunderstood something...)
> 

This doesn't sound that unusual. The std-vga device model in QEMU moves the 
vram around when the PCI bar is set up. The VRAM starts at 0xff000000 and is 
mapped for access by the emulated aperture from a0000-bffff and then when the 
PCI bar is set up it gets moved to wherever the firmware puts it.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel