Re: [Xen-devel] Source of guest-physical address in PCI BAR for HVMdomain?

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

Ah, I forgot the io hole is also coded into the DSDT. That's a pain. Either
that range specifier needs to be dynamically generated by hvmloader into a
SSDT, or we need two statically generated SSDTs to hand (0xc0000000- and
0xf0000000-) that hvmloader picks between dependent on size of PCI resources
to be mapped, or we just make all guests have a 1GB hole.

As for hvmloader not configuring bridges, without pci passthru there are
never any bridges to be configured. It's a job for whoever is working on
passthru of devices behind bridges to fix that.

 -- Keir

On 7/1/08 23:46, "Zulauf, John" <john.zulauf@xxxxxxxxx> wrote:

> You can change that starting address to from 0xF000000 to something more
> sensible for large BAR devices (like 0xC0000000) in
> tools/firmware/acpi/dsdt.asl at line 123, and the change 0x05000000 to
> 0x3500000 on 126 (that's a size), and recompiling the asl file.
> 
> You need large regions for large bars as bars are aligned at their size
> (that 256MB BAR will be aligned on a 256MB boundary)
> 
> Now of course you've limited memory < 4GB to 3GB, so YMMV.  I haven't
> experiment as to whether the Xen BIOS recovers the PCI "hole" memory
> above 4GB.
> 
> Also, beware that hvmloader doesn't allocate resources behind bridges.
> (It doesn't even configure bridge bars correctly.)
> 
> It is interesting to note that Linux behaves differently that Windows in
> this regard.  Windows pays attention to the ASL limits and will not
> exceed them even if less RAM is allocated to the domain.  Linux (at
> least as of my last test of this) will reallocate BARs anywhere
> unclaimed.
> 
> John Zulauf
> 
> *** Opinions expressed are only those of the author and do not
> necessarily reflect the views of his employer.
> 
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of David Stone
> Sent: Monday, January 07, 2008 1:39 PM
> To: Keir Fraser
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Philip Kufeldt; Samuel Thibault
> Subject: Re: [Xen-devel] Source of guest-physical address in PCI BAR for
> HVMdomain?
> 
> Thanks for the pointer...I believe I see the problem.  The code in
> pci_setup starts granting guest-physical address space to PCI devices
> at 0xF0000000.  The problem in my case is, my PCI-XP graphics card
> wants 256MB of guest-phyical address space for its video RAM.  That
> wraps around to 0x00000000.  It doesn't look like the code handles
> this, so it just merrily wraps around and ends up assigning memory
> ranges that are already in use for system RAM!
> 
> I'll have a look at improving this...
> 
> Dave
> 
> On Jan 6, 2008 6:15 PM, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
>> I see there's been a small email thread on this topic now, but I want
> to
>> point out that the code that configures the PCI BARs initially is not
> in the
>> rombios code but is in the hvmloader code. See
>> tools/formware/hvmloader/hvmloader.c:pci_setup().
>> 
>>  -- Keir
>> 
>> 
>> On 4/1/08 16:35, "David Stone" <unclestoner@xxxxxxxxx> wrote:
>> 
>>> I understand that eventually it would be the HVM guest OS that would
>>> write to the PCI configuration IO port which would get caught be Xen
>>> and passed along to qemu.  But, this is happending early in the boot
>>> process before the guest OS proper is even running.  My
> understanding
>>> of how PCI systems work is that the BIOS first configures (a subset
>>> of) the PCI devices, and then the once the real OS is initializing
> it
>>> can re-configure any PCI devices it wants to.  Can someone tell me
> if
>>> this is correct?
>>> 
>>> If so, shouldn't the early PCI configuration from the BIOS be coming
>>> from qemu itself?  My understanding is that qemu emulates a BIOS for
>>> HVM domains.
>> 
>> 
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel