[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Limitation in HVM physmap



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?

> 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

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

Wei.

> Ian.
> 

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.