I was reviewing my own changes for this and you might also need to
change the value of
HVM_BELOW_4G_RAM_END to 0xC000000 (or whatever match the ACPI values) in
xen/include/public/hvm/e820.h
As for 64 bit, as far as I can tell hvmloader allocates everything below
4G for 64 bit guests as well.
John Zulauf
*** Opinions expressed are only those of the author and do not
necessarily reflect the views of his employer.
-----Original Message-----
From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
Sent: Tuesday, January 08, 2008 12:19 AM
To: Zulauf, John; David Stone
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Philip Kufeldt; Samuel Thibault
Subject: Re: [Xen-devel] Source of guest-physical address in PCI BAR for
HVMdomain?
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
|
Home