Re: [Xen-devel] Limitation in HVM physmap

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-11-01 at 12:45 +0000, Wei Liu wrote:
> On Fri, Nov 01, 2013 at 12:33:28PM +0000, Ian Campbell wrote:
> [...]
> > > 
> > > 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.
> > 
> 
> Good catch. I only noticed that efifb is probably using the mapped
> location.
> 
> > 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
> 
> Yes, it has a cirrus driver.
> 
> > 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?
> > 
> 
> Snippet from the full log:
[...]
> (d1) PciBus: Discovered PCI @ [00|02|00]
> (d1)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length = 0x2000000;   
>   Offset = 0
> (d1) x10
> (d1)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x1000;      
>   Offset = 0x14

This is the cirrus device, I think?

I don't see any mention of either 0xf0000000 or 0x80000000 here.

> (d1) PciBus: HostBridge->SubmitResources() - Success
> (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) - Success
> [  403.936062] xenbr0: port 3(vif1.0-emu) entered forwarding state
> (d1) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> (d1) Type =   Io16; Base = 0xC000;      Length = 0x1000;        Alignment = 
> 0xFFF
> (d1)  Base = 0xC000;    Length = 0x100; Alignment = 0xFF;       Owner = PCI  
> [00|04|00:10]
> (d1)  Base = 0xC100;    Length = 0x100; Alignment = 0xFF;       Owner = PCI  
> [00|03|00:10]
> (d1)  Base = 0xC200;    Length = 0x10;  Alignment = 0xF;        Owner = PCI  
> [00|01|01:20]
> (d1) Type =  Mem32; Base = 0x80000000;  Length = 0x3100000;     Alignment = 
> 0x1FFFFFF
> (d1)  Base = 0x80000000;        Length = 0x2000000;     Alignment = 
> 0x1FFFFFF;  Owner = PCI  [00
> (d1) |02|00:10]
> (d1)  Base = 0x82000000;        Length = 0x1000000;     Alignment = 0xFFFFFF; 
>   Owner = PCI  [00|
> (d1) 03|00:14]
> (d1)  Base = 0x83000000;        Length = 0x100; Alignment = 0xFFF;      Owner 
> = PCI  [00|04|00:1
> (d1) 4]
> (d1)  Base = 0x83001000;        Length = 0x1000;        Alignment = 0xFFF;    
>   Owner = PCI  [00|02|00:
> (d1) 14]
> 
> 
> Looks like OVMF does something tricky and doesn't propogate the change to Xen?

I'm not sure what you were trying to illustrate with that log, what
tricky thing are you thinking of?

Is OVMF trying to do MMIO reassignment? I think we do this in hvmloader
so you could try turning that behaviour off, if possible.

"propogate changes to Xen" would mean writing various BAR registers,
which are emulated (by qemu I suppose), I wouldn't expect OVMF to be
propagating things to Xen directly. We could be getting the emulation of
those updates wrong I guess, but surely we'd have noticed it elsewhere
before now?

Ian.


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