[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: David Stone <unclestoner@xxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Mon, 21 Jan 2008 14:59:35 +0000
  • Cc: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 21 Jan 2008 07:01:25 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AchcPjxVetW/SsgxEdyNvQAX8io7RQ==
  • Thread-topic: [Xen-devel] [Patch] Make memory hole for PCI Express bigger and prevent roll-over

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?


> 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.