Mailing List Archive

Missing patch included this time.

This patch moves the creation of the e820 tables from libxc into the
hvmloader. I have implemented some functions around the e820 tables for
adding and reserving memory areas. I am using these to build the tables
and reserve memory for BIOS and ACPI data. ACPI memory area is only
reserved if ACPI is enabled for the domain.

Signed-off-by: Stefan Berger <stefanb@us.ibm.com>

On 7/11/06 18:22, "Stefan Berger" <stefanb@us.ibm.com> wrote:

> This patch moves the creation of the e820 tables from libxc into the
> hvmloader. I have implemented some functions around the e820 tables for
> adding and reserving memory areas. I am using these to build the tables
> and reserve memory for BIOS and ACPI data. ACPI memory area is only
> reserved if ACPI is enabled for the domain.

We can just make the ACPI range statically a page bigger. It's no big loss
(consider that we squander >100kB of memory between 0xC0000 and 0xF0000
right now), and at some point in the near future we'll get rid of the acpi
option and always produce ACPI tables. There are just a few interrupt issues
to sort out first.

The printk patch could be useful, however, since hvmloader is going to get
more complicated in other ways and we'll want to get tracing out of it.

-- Keir



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

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote on 11/07/2006 01:51:50 PM:

> On 7/11/06 18:22, "Stefan Berger" <stefanb@us.ibm.com> wrote:
>
> > This patch moves the creation of the e820 tables from libxc into the
> > hvmloader. I have implemented some functions around the e820 tables
for
> > adding and reserving memory areas. I am using these to build the
tables
> > and reserve memory for BIOS and ACPI data. ACPI memory area is only
> > reserved if ACPI is enabled for the domain.
>
> We can just make the ACPI range statically a page bigger. It's no big
loss
> (consider that we squander >100kB of memory between 0xC0000 and 0xF0000
> right now), and at some point in the near future we'll get rid of the
acpi
> option and always produce ACPI tables. There are just a few interrupt
issues
> to sort out first.

So I suppose you are not going to take the patch.

>
> The printk patch could be useful, however, since hvmloader is going to
get
> more complicated in other ways and we'll want to get tracing out of it.

Which printk patch? Are you going to disable debugging there altogther?

Stefan

>
> -- Keir
>
>

Keir Fraser <keir@xensource.com> wrote on 11/08/2006 09:41:24 AM:

> On 8/11/06 14:17, "Stefan Berger" <stefanb@us.ibm.com> wrote:

> > We can just make the ACPI range statically a page bigger. It's no big
loss
> > (consider that we squander >100kB of memory between 0xC0000 and
0xF0000
> > right now), and at some point in the near future we'll get rid of the
acpi
> > option and always produce ACPI tables. There are just a few interrupt
issues
> > to sort out first.
>
> So I suppose you are not going to take the patch.

> Correct. A bunch of complexity there for negligible benefit that I can
see.

In that case libxc should #include the acpi2_0.h and get its
ACPI_PHYSICAL_BASE & ACPI_TABLE_SIZE parameters from there.

>
> >
> > The printk patch could be useful, however, since hvmloader is going to
get
> > more complicated in other ways and we'll want to get tracing out of
it.
>
> Which printk patch? Are you going to disable debugging there altogther?
>
> The printk stuff that is in the patch you sent, which you took from
vmxassist.

I will let you apply that part then.


Stefan
>
> -- Keir

Keir Fraser <keir@xensource.com> wrote on 11/08/2006 10:57:33 AM:

> On 8/11/06 15:06, "Stefan Berger" <stefanb@us.ibm.com> wrote:

> > Correct. A bunch of complexity there for negligible benefit that I can
see.
>
> In that case libxc should #include the acpi2_0.h and get its
> ACPI_PHYSICAL_BASE & ACPI_TABLE_SIZE parameters from there.
>
> Or hvmloader can grok the e820 enough to find where it ought to
> place the ACPI tables. That can be done with much less code than is
> required to arbitrarily insert/delete entries in the e820 (which is
> what I think we can do without). In fact hvmloader can also easily
> change the size of an existing ACPI e820 entry. So we?d end up with
> libxc selecting the ACPI base address, and hvmloader picking that up

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...

> 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.

Stefan

>
> -- Keir

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

> On 8/11/06 16:26, "Stefan Berger" <stefanb@us.ibm.com> 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

Keir Fraser <keir@xensource.com> wrote on 11/08/2006 06:08:03 PM:

>
>
>
> On 8/11/06 10:35 pm, "Stefan Berger" <stefanb@us.ibm.com> wrote:

> > 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.
>
> I believe regions marked ACPI are allowed to be reclaimed by the OS
> after it has parsed the ACPI tables. So perhaps the log memory needs
> to be marked reserved, or not covered by an e820 region at all.

Probably then 'reserved', although when I put it into the ACPI area it
worked. The driver that accesses that log will try to map it every time
one opens a sysfs file.

http://www.linux-m32r.org/lxr/http/source/drivers/char/tpm/tpm_bios.c?v=2.6.18#L386

Stefan
>
> -- Keir