Re: [Xen-devel] Limitation in HVM physmap

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-11-01 at 12:21 +0000, Wei Liu wrote:
> On Fri, Oct 18, 2013 at 03:20:12PM +0100, Wei Liu wrote:
> > Hi Jan, Tim and Keir
> > 
> > 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?
> > 
> > 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?
> > 
> 
> FWIW I tested this on real hardware, a Dell R710 server.
> 
> dmesg:
> [   39.394807] efifb: probing for efifb
> [   39.437552] efifb: framebuffer at 0xd5800000, mapped to 
> 0xffffc90013f00000, using 1216k, total 1216k
> [   39.546549] efifb: mode is 640x480x32, linelength=2560, pages=1
> [   39.617140] efifb: scrolling: redraw
> [   39.659709] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> 
> lspci -vvv:
> 0b:03.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200eW 
> WPCM450 (rev 0a) (prog-if 00 [VGA controller])
>         Subsystem: Dell PowerEdge R710 MGA G200eW WPCM450
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 64 (4000ns min, 8000ns max), Cache Line Size: 64 bytes
>         Interrupt: pin A routed to IRQ 10
>         Region 0: Memory at d5800000 (32-bit, prefetchable) [size=8M]
>         Region 1: Memory at de7fc000 (32-bit, non-prefetchable) [size=16K]
>         Region 2: Memory at de800000 (32-bit, non-prefetchable) [size=8M]
>         [virtual] Expansion ROM at de000000 [disabled] [size=64K]
>         Capabilities: [dc] Power Management version 1
>                 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> 
> So I think the behavior of OVMF is consistent with real hardware.

I'm not sure you can draw too many conclusions wrt the behaviour on the
emulated cirrus though.

This devices seems to have three memory bars? Whereas the Cirrus card
has only 2.

The original problem was that the Cirrus card was being accessed at two
distinct locations, where is that happening here? I can only see
0xd5800000 being used.

The cirrus card also differs in that the address reported by efifb
(0x80000000) does not match either of the BARS configured on the Cirrus
card (0xf000000 and 0xf3xxxx). Whereas here efifb is using the first
memory BAR of the matrox card, which is logical.

So where does the discrepancy between the efifb view and the Cirrus
device's view come from? Does OVMF contain a cirrus driver or is it
using a generic (e.g. stdvga driver)? Where does it get this address
0x80000000 from and why does it think it maps to the Cirrus device?

Looking back at an earlier mail:

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

This seems to show that 0x80000000 is a bar on the PCI root bridge, not
the Cirrus device. Could that be the root (no pun intended) of the
confusion?

The rest of that mail also had this:

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

There seems to be a disconnect between what the efifb is discovering and
how the actual hardware is configured.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel