[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Limitation in HVM physmap
On Fri, 2013-10-18 at 16:01 +0100, Wei Liu 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. Does all of this get logged to the xen debug console? Can you post a full log perhaps to clarify things for us? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |