So not only must we not wrap around to 0x00000000, we must also not
assign memory ranges to PCI devices that are used by other components
like for example the IOAPIC (0xFEC00000)? I don't know anything about
ACPI but in dstd.asl it looks like up to 0xF4FFFFFF is being reserved
for PCI devices...so is 0xF4FFFFFF the upper limit that should be
used?
Also, can someone explain how this all works on 64-bit?
Thanks,
Dave
On Jan 8, 2008 3:19 AM, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
> 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