Re: Limitation in HVM physmap

[Fabio Fantoni <fabio.fantoni@m2r.biz>]

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.