[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Limitation in HVM physmap
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- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M] Region 1: Memory at f3010000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at f3000000 [disabled] [size=64K] > 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |