Re: [Xen-devel] Limitation in HVM physmap

[Tim Deegan <tim@xxxxxxx>]

Hi,

At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
> 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?

1. For simplicity.  That code is hard wnough to work with already. :)

2. It helps avoid worrying about inconsistent cache settings if the
   HAP tables only have one entry for each MFN. 

3. Xen maintains a single mapping from MFN back to PFN, and any code
   that uses it would have to be able to deal with getting multiple
   answers.  That's already been partly changed by the mem_sharing
   code (which obviously _can_ have multiple P2M entries pointing to
   the same MFN but is a bit complex as a result).

> 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?

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.

Cheers,

Tim.

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