Re: Limitation in HVM physmap

[Wei Liu <wei.liu2@citrix.com>]

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.