Re: [Xen-devel] Limitation in HVM physmap

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Oct 18, 2013 at 03:47:25PM +0100, Jan Beulich wrote:
> >>> On 18.10.13 at 16:36, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> > On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote:
> >> At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
> >> > 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?
> 
> Since when does the Linux kernel have control over the physical
> address where the frame buffer sits (other than by writing PCI
> devices' BARs, which implies the address range to change rather
> than a second instance to be created)?
> 

I don't think Linux changes things -- 0xf0000000 is what it gets from
Xen and it honors that. It's OVMF that plays with things. There is a
procedure in OVMF that remaps PCI resources.

> >> Qemu could remember where it put the framebuffer last time and unmap
> >> it.  AIUI that's how real hardware would behave if you changed the
> >> framebuffer base address -- the framebuffer wouldn't still be mapped at
> >> the old location as well.
> >> 
> > 
> > In fact, this is not the case in OVMF. EFIFB driver in Linux will always
> > use the EFIFB region (0x80000000) provided by OVMF. 
> > 
> > Unmapping the first region (0x80000000) 1) makes the guest not able to
> > refresh its framebuffer, 2) causes lots of traps in QEMU (because guest
> > is still accessing first region) which makes QEMU busy-looping all the
> > time.
> 
> How does that behavior map to real hardware behavior?
> 
> Jan

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