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

Re: [Xen-devel] Limitation in HVM physmap



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:
> > (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?

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?

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?

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