Re: [Xen-devel] Limitation in HVM physmap

[Fabio Fantoni <fabio.fantoni@xxxxxxx>]

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@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.
> Right.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> 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.

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