From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: Limitation in HVM physmap Date: Fri, 18 Oct 2013 15:56:11 +0100 Message-ID: <20131018145611.GD20185@zion.uk.xensource.com> References: <20131018142012.GB20185@zion.uk.xensource.com> <20131018142824.GA33100@deinos.phlegethon.org> <20131018143640.GC20185@zion.uk.xensource.com> <20131018144149.GB33100@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20131018144149.GB33100@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: keir@xen.org, Ian Campbell , Stefano Stabellini , George Dunlap , xen-devel@lists.xen.org, Jan Beulich , Wei Liu List-Id: xen-devel@lists.xenproject.org On Fri, Oct 18, 2013 at 04:41:49PM +0200, Tim Deegan wrote: > At 15:36 +0100 on 18 Oct (1382107000), Wei Liu wrote: > > On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote: > > > 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). > > > > > > > I see. > > > > > > 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. > > > > > > > In fact, this is not the case in OVMF. EFIFB driver in Linux will always > > use the EFIFB region (0x80000000) provided by OVMF. > > So what's mapping it at 0xf00000000? Is linux running two drivers > against the same graphics card at the same time? That sounds like > trouble! > During OVMF initialization: (d28) PciBus: Resource Map for Root Bridge PciRoot(0x0) (d28) Type = Io16; Base = 0xC000; Length = 0x1000; Alignment = 0xFFF (d28) Base = 0xC000; Length = 0x100; Alignment = 0xFF; Owner = PCI [00|04| (d28) Base = 0xC100; Length = 0x100; Alignment = 0xFF; Owner = PCI [00|03| (d28) Base = 0xC200; Length = 0x10; Alignment = 0xF; Owner = PCI [00|01| (d28) Type = Mem32; Base = 0x80000000; Length = 0x3100000; Alignment = 0x1FFFFF (d28) Base = 0x80000000; Length = 0x2000000; Alignment = 0x1FFFFFF; Owne (d28) |02|00:10] Later when Linux loads EFIFB driver: [ 2.628264] efifb: framebuffer at 0x80000000, mapped to 0xffffc90000100000, using 1876k, total 1875k [ 2.646827] efifb: mode is 800x600x32, linelength=3200, pages=1 [ 2.658833] efifb: scrolling: redraw [ 2.666342] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 0xf0000000 is mapped by: 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA controller]) Subsystem: Red Hat, Inc Device 1100 Physical Slot: 2 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- And how would this work with a real graphics card? Isn't there only > one BAR that controls where the framebuffer presents itself? > No idea. Maybe I'm missing something? TBH I've never had any EFI-capable hardware. Wei. > Tim.