Re: [Xen-devel] Limitation in HVM physmap

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-11-01 at 14:55 +0000, Wei Liu wrote:
> On Fri, Nov 01, 2013 at 02:31:03PM +0000, Ian Campbell wrote:
> > On Fri, 2013-11-01 at 14:19 +0000, Wei Liu wrote:
> > > On Fri, Nov 01, 2013 at 02:12:32PM +0000, Ian Campbell wrote:
> > > > On Fri, 2013-11-01 at 14:08 +0000, Wei Liu wrote:
> > > > > 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.
> > > > 
> > > > OK, so even OVMF thinks the Cirrus memory range is at 0xf0000000, so
> > > > where did efifb get 0x80000000 from?
> > > > 
> > > 
> > > A few lines later in log
> > > 
> > >  (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) - Success
> > 
> > Hrm, I was confused because this line obviously doesn't say 0x8000000
> > (or much of anything) anywhere, but you meant it as a reference to the
> > first line of a block, which I'll quote in full for clarity:
> 
> Oh, what I meant is there is a procedure to allocate resource.
> 
> > > > (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) - Success
> > > > (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|02|00:10]
> > > > (d1)  Base = 0x82000000;        Length = 0x1000000;     Alignment = 
> > > > 0xFFFFFF;   Owner = PCI  [00|03|00:14]
> > > > (d1)  Base = 0x83000000;        Length = 0x100; Alignment = 0xFFF;      
> > > > Owner = PCI  [00|04|00:14]
> > > > (d1)  Base = 0x83001000;        Length = 0x1000;        Alignment = 
> > > > 0xFFF;      Owner = PCI  [00|02|00:14]
> > 
> > (I've undamaged the whitespace a bit too). I suppose the interesting line 
> > is:
> > 
> > > > (d1)  Base = 0x80000000;        Length = 0x2000000;     Alignment = 
> > > > 0x1FFFFFF;  Owner = PCI  [00|02|00:10]
> > 
> > Is this report based on what EDK2 wanted to set or is it based on what
> > it actually does set? How come this is not reflected in the device BAR
> > by the time Linux has a look?
> > 
> 
> ... And this is the result of allocation.
> 
> I can see 0x80000000 in QEMU's log, but that's as far as I can go
> because I was sure QEMU was behaving correctly at that point. I can see
> that the memory region of FB was updated in log, but some steps to
> untrack the previous memory region seemed to be missing.  Probably a bug
> in code updating the BAR in QEMU?

It certainly seems like something isn't "sticking" at least. I'd have
throught the PCI bar emulation in qemu would be pretty well established,
might be some hook missing on our end?

> > Do you know what the ":10" in "00|02|00:10" is? Does it indicate BAR[0]
> > which is a memory BAR somehow or something else?
> > 
> 
> "10" is the offset, nothing special. B|D|F:OFFSET

Ah, 0x10 is the offset of BAR[0] within the PCI CFG space, OK, makes
sense.

> > The log in <20131018153009.GH20185@xxxxxxxxxxxxxxxxxxxxx> has:
> > [    1.556292] pci 0000:00:02.0: no compatible bridge window for [mem 
> > 0x80000000-0x81ffffff pref]
> > [    1.560024] pci 0000:00:02.0: no compatible bridge window for [mem 
> > 0x83001000-0x83001fff]
> > [    1.564118] pci 0000:00:03.0: no compatible bridge window for [mem 
> > 0x82000000-0x82ffffff pref]
> > 
> > could be the reason Linux is trying to rewrite things again itself?
> > 
> 
> There seems to be something wrong with that. My speculation is that this
> is caused by other errors early on, but I'm not sure.

Right.



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