Re: Limitation in HVM physmap

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

On Fri, Nov 01, 2013 at 12:49:12PM +0000, Ian Campbell wrote:
> 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.
> 

Yes. You can tell from the BDF.

It didn't print out base address by default. I added my own debug patch
and confirmed that base address was set correctly by hvmloader.

(d9) PciBus: Discovered PCI @ [00|02|00]
(d9)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length = 0x2000000;     Offset = 0x10        BaseAddress = 0xF0000000
(d9)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x1000; Offset = 0x14   BaseAddress = 0xF3020000

Sorry about the confusion.

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

I will see what I can do. My impression was that reassignment process is
mandatory in UEFI but I could be wrong. Real hardware doesn't behave
like that anyway.

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

Yes, it's indeed caught by QEMU. And I think QEMU gets the right value.
I'm just not very sure about certain QEMU-specific behavior. I will
investigate that.

Wei.

> Ian.