[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |