Re: [Xen-devel] Limitation in HVM physmap

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.10.13 at 17:01, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> 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.

Then I'd suppose there is where you would be looking for how
to fix it.

Jan


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