Re: [Xen-devel] [Patch] Make memory hole for PCI Express bigger and prevent roll-over

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 21/1/08 13:41, "David Stone" <unclestoner@xxxxxxxxx> wrote:

> OK fair enough.  As I said I have some code that dynamically modifies
> the DSDT's AML.  I'll try to finish it up and submit it.

Actually that's a bad way to do it. I've just checked in a patch which
modifies the DSDT to fetch the PCI hole parameters from a memory location
which is initialised by hvmloader.

> But in the meantime, will you take a patch (a subset of the patch I
> just submitted) that keeps the hole as it is (starting at 0xF0000000)
> but ensures it doesn't roll over to 0x00000000 in the Xen HVM BIOS?

Yes.

> Also should the hole used by the Xen HVM BIOS be limited to
> 0xF0000000-0xF4FFFFFF rather than 0xF00000000-0xFFFFFFFF?  Because:
>   - The current DSDT specifies 0xF0000000-0xF4FFFFFF.

I think this is because it was "big enough" for the Intel engineer who first
did the Xen ACPI work. There's no reason not to go up to, say, FC000000. We
can't go all the way to 4GB because there a couple of things up there (at
least LAPIC and IOAPIC mappings).

>   - My understanding is that various other systems/components use
> certain addresses at the top of 32-bit physical address space (like
> maybe MSIs?).  So it would be bad to assign those physical addresses
> to random PCI devices.

If we leave 64MB it should be plenty.

> My only hesitation is that 0xF0000000-0xF4FFFFFF = 80Mb is smallish,
> especially considering the wasteful algorithm the Xen HVM BIOS
> currently uses to assign addresses (it can waste a lot of space).

How is it wasteful? We could only do better if we assigned PCI resources in
descending order of size (and hence alignment requirement). Which we *could*
do, I suppose. Certainly the resource assignment code is going to get rather
more exciting anyway, to fully support the dynamic PCI hole.

 -- Keir



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