WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Source of guest-physical address in PCI BAR for HVMdomai

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "David Stone" <unclestoner@xxxxxxxxx>
Subject: RE: [Xen-devel] Source of guest-physical address in PCI BAR for HVMdomain?
From: "Zulauf, John" <john.zulauf@xxxxxxxxx>
Date: Thu, 10 Jan 2008 14:46:00 -0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Philip Kufeldt <pak@xxxxxxxxxxxxx>, Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Delivery-date: Thu, 10 Jan 2008 14:47:09 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3A8E27C.11D97%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BD262A443AD428499D90AF8368C4528DD4F7F7@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C3A8E27C.11D97%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchRdhACF10STlBDQjSYDf5sNRc+MAADvQLgABKH7TQAgp27kA==
Thread-topic: [Xen-devel] Source of guest-physical address in PCI BAR for HVMdomain?
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