Re: [Xen-devel] Limitation in HVM physmap

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-10-18 at 15:56 +0100, Wei Liu wrote:
> 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:

What hardware is backing the framebuffer at 0x80000000? It doesn't
appear to be this cirrus device.

Does this VM have two graphics cards and therefore two drivers (efifb
and cirrusfb/vesafb/etc)?

If there are two gfx cards then there should be two framebuffers and
therefore no mfn sharing in the p2m, although you would probably be
better off arranging for their to only one gfx card...

> 
> 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