From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabio Fantoni Subject: Re: Limitation in HVM physmap Date: Mon, 04 Nov 2013 10:28:57 +0100 Message-ID: <527768D9.7040309@m2r.biz> References: <20131018142012.GB20185@zion.uk.xensource.com> <20131101122142.GD4966@zion.uk.xensource.com> <1383309208.672.56.camel@kazak.uk.xensource.com> <20131101124512.GE4966@zion.uk.xensource.com> <1383310152.672.60.camel@kazak.uk.xensource.com> <20131101140809.GF4966@zion.uk.xensource.com> <1383315152.672.82.camel@kazak.uk.xensource.com> <20131101141900.GG4966@zion.uk.xensource.com> <1383316263.672.91.camel@kazak.uk.xensource.com> <20131101145552.GH4966@zion.uk.xensource.com> <1383318252.672.94.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1383318252.672.94.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Wei Liu Cc: keir@xen.org, Stefano Stabellini , George Dunlap , tim@xen.org, xen-devel@lists.xen.org, Jan Beulich List-Id: xen-devel@lists.xenproject.org Il 01/11/2013 16:04, Ian Campbell ha scritto: > 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@zion.uk.xensource.com> 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@lists.xen.org > http://lists.xen.org/xen-devel Could be a similar problem on qxl too? On latest debug about qxl time ago I found this error on domU's log: > ioremap error for 0xfc001000-0xfc002000, requested 0x10, got 0x0 For details see the full post: http://lists.xen.org/archives/html/xen-devel/2013-10/msg00016.html If you need more informations and/or tests tell me and I'll post them. Thanks for any reply.