Re: [Xen-devel] Limitation in HVM physmap

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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