Xen devel - Nov 2006 - [PATCH] [HVM] [RFC] Moving the e820 table creation into hvmloader

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>



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

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>



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

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

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

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

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