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

Re: [Xen-devel] [PATCH] [HVM] [RFC] Moving the e820 table creation into hvmloader




Keir Fraser <keir@xxxxxxxxxxxxx> wrote on 11/08/2006 11:49:20 AM:

> On 8/11/06 16:26, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:

> That base address needs to be the same value as the static ACPI
> tables were built for. Unfortunately the tables are address-
> dependent. So they really should use the same #define...
> I intend to link the relocation code into hvmloader, rather than
> running it at build time. So the base address can be dynamic at load time.

>
> > and poking the length. This seems a reasonable split of duties to
> > me, and can be done with a small patch.
> >
> > I presume your immediate problem is simply that currently the e820
> > entry specifies 4kB for the ACPI region, but you need more if you
> > append the TPM SSDT?
>
> Yes, it's this SSDT that needs some more memory. Also that other
> spec that I'd like to support requires a space of 64kb for logs. I
> can live with less than that, for example 10kb.

>
> Is that to be marked as ACPI too? So we can just tack it on the end
> of a big ACPI region at, say, 0xE0000? Frankly, for now, we can just


Yes, it has to be marked such that it's not claimed by an OS. Probably it's the best to mark it as ACPI and put it into the same memory chunk as the rest of ACPI.

   Stefan

> say that all of 0xE0000-0xF0000 is ACPI. We never mark any of that
> region as E820_RAM, so the memory is not currently usable by the
> guest anyway. So it’s not like we’re wasting any extra memory by doing this.
>
>  -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

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