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

["Zulauf, John" <john.zulauf@xxxxxxxxx>]

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