Xen devel - Nov 2013 - [PATCH] hvmloader: write extra memory in CMOS

Some firmware, such as OVMF relies on this value to get the size of
extra memory above 4GB.

Seabios in Xen doesn''t need this as it gets e820 directly from Xen.
Rombios doesn''t read this value.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/firmware/hvmloader/hvmloader.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/tools/firmware/hvmloader/hvmloader.c
b/tools/firmware/hvmloader/hvmloader.c
index 1cc8cf2..327dffd 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -146,6 +146,7 @@ static void init_hypercalls(void)
 static void cmos_write_memory_size(void)
 {
     uint32_t base_mem = 640, ext_mem, alt_mem;
+    uint64_t extra_mem = 0;
 
     alt_mem = ext_mem = hvm_info->low_mem_pgend << PAGE_SHIFT;
     ext_mem = (ext_mem > 0x0100000) ? (ext_mem - 0x0100000) >> 10 : 0;
@@ -153,6 +154,15 @@ static void cmos_write_memory_size(void)
         ext_mem = 0xffff;
     alt_mem = (alt_mem > 0x1000000) ? (alt_mem - 0x1000000) >> 16 : 0;
 
+    /* According to hvm_info:
+     *  0x100000000 to page_to_phys(high_mem_pgend)-1:
+     *   RAM above 4GB
+     * extra_mem written to CMOS is represented as 64kb chunks
+     */
+    extra_mem = hvm_info->high_mem_pgend;
+    extra_mem = (extra_mem > 0x100000) ?
+        (((extra_mem - 0x100000) << PAGE_SHIFT) >> 16) : 0;
+
     /* All BIOSes: conventional memory (CMOS *always* reports 640kB). */
     cmos_outb(0x15, (uint8_t)(base_mem >> 0));
     cmos_outb(0x16, (uint8_t)(base_mem >> 8));
@@ -166,6 +176,11 @@ static void cmos_write_memory_size(void)
     /* Some BIOSes: alternative extended memory (64kB chunks above 16MB). */
     cmos_outb(0x34, (uint8_t)( alt_mem >> 0));
     cmos_outb(0x35, (uint8_t)( alt_mem >> 8));
+
+    /* Some BIOSes: extra memory (64kB chunks above 4GB) */
+    cmos_outb(0x5d, (uint8_t)( extra_mem >> 16));
+    cmos_outb(0x5c, (uint8_t)( extra_mem >> 8));
+    cmos_outb(0x5b, (uint8_t)( extra_mem >> 0));
 }
 
 /*
-- 
1.7.10.4

Wei Liu <wei.liu2@citrix.com> wrote:
>Some firmware, such as OVMF relies on this value to get the size of
>extra memory above 4GB.
>
>Seabios in Xen doesn''t need this as it gets e820 directly from Xen.
>Rombios doesn''t read this value.
I was looking at this some time ago for the GPU. I think a better way is to take
advantage that the e820 can be retrieved from the hypervisor (used to be only
for PV - but with thr PVH patches it works on HVM too). There is code from
Gordan that also takes advantage of e820_hole.

Anyhow why don''t we plumb in the libxl the standard memory layout and
query for that?

Or use xenstore?
>
>Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>---
> tools/firmware/hvmloader/hvmloader.c |   15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
>diff --git a/tools/firmware/hvmloader/hvmloader.c
>b/tools/firmware/hvmloader/hvmloader.c
>index 1cc8cf2..327dffd 100644
>--- a/tools/firmware/hvmloader/hvmloader.c
>+++ b/tools/firmware/hvmloader/hvmloader.c
>@@ -146,6 +146,7 @@ static void init_hypercalls(void)
> static void cmos_write_memory_size(void)
> {
>     uint32_t base_mem = 640, ext_mem, alt_mem;
>+    uint64_t extra_mem = 0;
> 
>     alt_mem = ext_mem = hvm_info->low_mem_pgend << PAGE_SHIFT;
>     ext_mem = (ext_mem > 0x0100000) ? (ext_mem - 0x0100000) >> 10
: 0;
>@@ -153,6 +154,15 @@ static void cmos_write_memory_size(void)
>         ext_mem = 0xffff;
>     alt_mem = (alt_mem > 0x1000000) ? (alt_mem - 0x1000000) >> 16
: 0;
> 
>+    /* According to hvm_info:
>+     *  0x100000000 to page_to_phys(high_mem_pgend)-1:
>+     *   RAM above 4GB
>+     * extra_mem written to CMOS is represented as 64kb chunks
>+     */
>+    extra_mem = hvm_info->high_mem_pgend;
>+    extra_mem = (extra_mem > 0x100000) ?
>+        (((extra_mem - 0x100000) << PAGE_SHIFT) >> 16) : 0;
>+
>   /* All BIOSes: conventional memory (CMOS *always* reports 640kB). */
>     cmos_outb(0x15, (uint8_t)(base_mem >> 0));
>     cmos_outb(0x16, (uint8_t)(base_mem >> 8));
>@@ -166,6 +176,11 @@ static void cmos_write_memory_size(void)
>/* Some BIOSes: alternative extended memory (64kB chunks above 16MB).
>*/
>     cmos_outb(0x34, (uint8_t)( alt_mem >> 0));
>     cmos_outb(0x35, (uint8_t)( alt_mem >> 8));
>+
>+    /* Some BIOSes: extra memory (64kB chunks above 4GB) */
>+    cmos_outb(0x5d, (uint8_t)( extra_mem >> 16));
>+    cmos_outb(0x5c, (uint8_t)( extra_mem >> 8));
>+    cmos_outb(0x5b, (uint8_t)( extra_mem >> 0));
> }
> 
> /*

On Tue, 2013-11-12 at 06:52 -0500, Konrad Rzeszutek Wilk
wrote:
> Wei Liu <wei.liu2@citrix.com> wrote:
> >Some firmware, such as OVMF relies on this value to get the size of
> >extra memory above 4GB.
> >
> >Seabios in Xen doesn''t need this as it gets e820 directly from
Xen.
> >Rombios doesn''t read this value.
> 
> I was looking at this some time ago for the GPU. I think a better way
> is to take advantage that the e820 can be retrieved from the
> hypervisor (used to be only for PV - but with thr PVH patches it works
> on HVM too). There is code from Gordan that also takes advantage of
> e820_hole.
I think that is orthogonal to Wei''s fix here. 

As it stands for HVM guests the e820 map is determined by hvmloader, so
it makes sense for it to populate standard CMOS locations with the
values they should have.
> Anyhow why don''t we plumb in the libxl the standard memory layout
and
> query for that?
What standard memory layout do you mean?
> Or use xenstore?
That would put a burden on the BIOS to have a xenstore client.

Ian.

On Tue, Nov 12, 2013 at 06:52:59AM -0500, Konrad Rzeszutek Wilk
wrote:
> Wei Liu <wei.liu2@citrix.com> wrote:
> >Some firmware, such as OVMF relies on this value to get the size of
> >extra memory above 4GB.
> >
> >Seabios in Xen doesn''t need this as it gets e820 directly from
Xen.
> >Rombios doesn''t read this value.
> 
> I was looking at this some time ago for the GPU. I think a better way
> is to take advantage that the e820 can be retrieved from the
> hypervisor (used to be only for PV - but with thr PVH patches it works
> on HVM too). There is code from Gordan that also takes advantage of
> e820_hole.
> 
> Anyhow why don''t we plumb in the libxl the standard memory layout
and
> query for that?
> 
> Or use xenstore?
I''m hacking a prototype to plumb through necessary information to OVMF.
It takes much longer to properly upstream the new protocol.

In any case this patch is something nice to have. We can never know when
firmware decides to consult this value.


Wei.

Ian Campbell <Ian.Campbell@citrix.com> wrote:
>On Tue, 2013-11-12 at 06:52 -0500, Konrad Rzeszutek Wilk wrote:
>> Wei Liu <wei.liu2@citrix.com> wrote:
>> >Some firmware, such as OVMF relies on this value to get the size of
>> >extra memory above 4GB.
>> >
>> >Seabios in Xen doesn''t need this as it gets e820 directly
from Xen.
>> >Rombios doesn''t read this value.
>> 
>> I was looking at this some time ago for the GPU. I think a better way
>> is to take advantage that the e820 can be retrieved from the
>> hypervisor (used to be only for PV - but with thr PVH patches it
>works
>> on HVM too). There is code from Gordan that also takes advantage of
>> e820_hole.
>
>I think that is orthogonal to Wei''s fix here. 
>
>As it stands for HVM guests the e820 map is determined by hvmloader, so
>it makes sense for it to populate standard CMOS locations with the
>values they should have.
CMOS has memory values? That is standard PC spec? Yikes!
>
>> Anyhow why don''t we plumb in the libxl the standard memory
layout and
>> query for that?
>
>What standard memory layout do you mean?
The E820.
>
>> Or use xenstore?
>
>That would put a burden on the BIOS to have a xenstore client.
Hvmloader already uses xenstore.

But I missed the part about this actually being an implementation of a bare
metal ''feature''.
>
>Ian.

>>> On 12.11.13 at 13:11, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>As it stands for HVM guests the e820 map is determined by hvmloader, so
>>it makes sense for it to populate standard CMOS locations with the
>>values they should have.
> 
> CMOS has memory values? That is standard PC spec? Yikes!
That''s the first time I hear about this - there are a couple of more
or less standard locations in CMOS where some of the memory
gets reported, but all are at most two bytes wide and (having at
best 64k granularity) don''t allow expressing memory beyond 4Gb.

Now, if there is a standard for the locations used here, fine with
me (but it should be referenced in the commit message then). But
if this is custom, then I wonder (a) how compatible such an
extension is going to be and (b) why it needs to be restricted to
3 bytes (allowing to cover only up to 1Tb).

Jan

On Tue, Nov 12, 2013 at 12:30:52PM +0000, Jan Beulich
wrote:
> >>> On 12.11.13 at 13:11, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>As it stands for HVM guests the e820 map is determined by
hvmloader, so
> >>it makes sense for it to populate standard CMOS locations with the
> >>values they should have.
> > 
> > CMOS has memory values? That is standard PC spec? Yikes!
> 
> That''s the first time I hear about this - there are a couple of
more
> or less standard locations in CMOS where some of the memory
> gets reported, but all are at most two bytes wide and (having at
> best 64k granularity) don''t allow expressing memory beyond 4Gb.
> 
> Now, if there is a standard for the locations used here, fine with
> me (but it should be referenced in the commit message then). But
> if this is custom, then I wonder (a) how compatible such an
> extension is going to be and (b) why it needs to be restricted to
> 3 bytes (allowing to cover only up to 1Tb).
> 
It''s not custom.

AFAICT Boches reads this, seabios reads this (when not running on Xen)
and OVMF reads this as well.

http://bochs.sourceforge.net/doc/docbook/development/cmos-map.html

However in some CMOS maps I found those bytes are marked as reserved.
That''s why I say "Some BIOSes" in comment.

http://www.bioscentral.com/misc/cmosmap.htm

Wei.
> Jan

>>> On 12.11.13 at 13:37, Wei Liu <wei.liu2@citrix.com> wrote:
> On Tue, Nov 12, 2013 at 12:30:52PM +0000, Jan Beulich wrote:
>> >>> On 12.11.13 at 13:11, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >>As it stands for HVM guests the e820 map is determined by
hvmloader, so
>> >>it makes sense for it to populate standard CMOS locations with
the
>> >>values they should have.
>> > 
>> > CMOS has memory values? That is standard PC spec? Yikes!
>> 
>> That''s the first time I hear about this - there are a couple
of more
>> or less standard locations in CMOS where some of the memory
>> gets reported, but all are at most two bytes wide and (having at
>> best 64k granularity) don''t allow expressing memory beyond
4Gb.
>> 
>> Now, if there is a standard for the locations used here, fine with
>> me (but it should be referenced in the commit message then). But
>> if this is custom, then I wonder (a) how compatible such an
>> extension is going to be and (b) why it needs to be restricted to
>> 3 bytes (allowing to cover only up to 1Tb).
>> 
> 
> It''s not custom.
> 
> AFAICT Boches reads this, seabios reads this (when not running on Xen)
> and OVMF reads this as well.
These are all non-traditional BIOSes, and a reasonably reliable
documentation aspect can''t be taken from their sources or
accompanying documentation.
> However in some CMOS maps I found those bytes are marked as reserved.
Exactly. The question is whether some _other_ BIOSes then use
these register for other purposes...

Jan

On Tue, Nov 12, 2013 at 01:21:36PM +0000, Jan Beulich
wrote:
> >>> On 12.11.13 at 13:37, Wei Liu <wei.liu2@citrix.com>
wrote:
> > On Tue, Nov 12, 2013 at 12:30:52PM +0000, Jan Beulich wrote:
> >> >>> On 12.11.13 at 13:11, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> >> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >>As it stands for HVM guests the e820 map is determined by
hvmloader, so
> >> >>it makes sense for it to populate standard CMOS locations
with the
> >> >>values they should have.
> >> > 
> >> > CMOS has memory values? That is standard PC spec? Yikes!
> >> 
> >> That''s the first time I hear about this - there are a
couple of more
> >> or less standard locations in CMOS where some of the memory
> >> gets reported, but all are at most two bytes wide and (having at
> >> best 64k granularity) don''t allow expressing memory
beyond 4Gb.
> >> 
> >> Now, if there is a standard for the locations used here, fine with
> >> me (but it should be referenced in the commit message then). But
> >> if this is custom, then I wonder (a) how compatible such an
> >> extension is going to be and (b) why it needs to be restricted to
> >> 3 bytes (allowing to cover only up to 1Tb).
> >> 
> > 
> > It''s not custom.
> > 
> > AFAICT Boches reads this, seabios reads this (when not running on Xen)
> > and OVMF reads this as well.
> 
> These are all non-traditional BIOSes, and a reasonably reliable
> documentation aspect can''t be taken from their sources or
> accompanying documentation.
> 
> > However in some CMOS maps I found those bytes are marked as reserved.
> 
> Exactly. The question is whether some _other_ BIOSes then use
> these register for other purposes...
> 
So I think now the solution is to make this code OVMF only, are you fine
with this?

Wei.
> Jan

>>> On 12.11.13 at 14:39, Wei Liu <wei.liu2@citrix.com> wrote:
> On Tue, Nov 12, 2013 at 01:21:36PM +0000, Jan Beulich wrote:
>> >>> On 12.11.13 at 13:37, Wei Liu <wei.liu2@citrix.com>
wrote:
>> > However in some CMOS maps I found those bytes are marked as
reserved.
>> 
>> Exactly. The question is whether some _other_ BIOSes then use
>> these register for other purposes...
>> 
> 
> So I think now the solution is to make this code OVMF only, are you fine
> with this?
Yes, provided you widen the location to at least 4 bytes.

Jan

On Tue, 2013-11-12 at 13:21 +0000, Jan Beulich wrote:
> >>> On 12.11.13 at 13:37, Wei Liu <wei.liu2@citrix.com>
wrote:
> > On Tue, Nov 12, 2013 at 12:30:52PM +0000, Jan Beulich wrote:
> >> >>> On 12.11.13 at 13:11, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> >> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >>As it stands for HVM guests the e820 map is determined by
hvmloader, so
> >> >>it makes sense for it to populate standard CMOS locations
with the
> >> >>values they should have.
> >> > 
> >> > CMOS has memory values? That is standard PC spec? Yikes!
> >> 
> >> That''s the first time I hear about this - there are a
couple of more
> >> or less standard locations in CMOS where some of the memory
> >> gets reported, but all are at most two bytes wide and (having at
> >> best 64k granularity) don''t allow expressing memory
beyond 4Gb.
> >> 
> >> Now, if there is a standard for the locations used here, fine with
> >> me (but it should be referenced in the commit message then). But
> >> if this is custom, then I wonder (a) how compatible such an
> >> extension is going to be and (b) why it needs to be restricted to
> >> 3 bytes (allowing to cover only up to 1Tb).
> >> 
> > 
> > It''s not custom.
> > 
> > AFAICT Boches reads this, seabios reads this (when not running on Xen)
> > and OVMF reads this as well.
> 
> These are all non-traditional BIOSes, and a reasonably reliable
> documentation aspect can''t be taken from their sources or
> accompanying documentation.
> 
> > However in some CMOS maps I found those bytes are marked as reserved.
> 
> Exactly. The question is whether some _other_ BIOSes then use
> these register for other purposes...
Why do we care about any BIOS other than ROMBIOS, SeaBIOS and OVMF?

Ian.

On Tue, 2013-11-12 at 07:11 -0500, Konrad Rzeszutek Wilk
wrote:
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >On Tue, 2013-11-12 at 06:52 -0500, Konrad Rzeszutek Wilk wrote:
> >> Wei Liu <wei.liu2@citrix.com> wrote:
> >> >Some firmware, such as OVMF relies on this value to get the
size of
> >> >extra memory above 4GB.
> >> >
> >> >Seabios in Xen doesn''t need this as it gets e820
directly from Xen.
> >> >Rombios doesn''t read this value.
> >> 
> >> I was looking at this some time ago for the GPU. I think a better
way
> >> is to take advantage that the e820 can be retrieved from the
> >> hypervisor (used to be only for PV - but with thr PVH patches it
> >works
> >> on HVM too). There is code from Gordan that also takes advantage
of
> >> e820_hole.
> >
> >I think that is orthogonal to Wei''s fix here. 
> >
> >As it stands for HVM guests the e820 map is determined by hvmloader, so
> >it makes sense for it to populate standard CMOS locations with the
> >values they should have.
> 
> CMOS has memory values? That is standard PC spec? Yikes!
At least somewhat customary I think.
> >> Anyhow why don''t we plumb in the libxl the standard
memory layout and
> >> query for that?
> >
> >What standard memory layout do you mean?
> 
> The E820.
libxl for HVM guests doesn''t have anything to do with the e820 AFAIK.
That is all fabricated by hvmloader.
> >
> >> Or use xenstore?
> >
> >That would put a burden on the BIOS to have a xenstore client.
> 
> Hvmloader already uses xenstore.
The burden would be on OVMF et al to have a client to read it back out.

Ian.

On Tue, Nov 12, 2013 at 01:56:02PM +0000, Jan Beulich
wrote:
> >>> On 12.11.13 at 14:39, Wei Liu <wei.liu2@citrix.com>
wrote:
> > On Tue, Nov 12, 2013 at 01:21:36PM +0000, Jan Beulich wrote:
> >> >>> On 12.11.13 at 13:37, Wei Liu
<wei.liu2@citrix.com> wrote:
> >> > However in some CMOS maps I found those bytes are marked as
reserved.
> >> 
> >> Exactly. The question is whether some _other_ BIOSes then use
> >> these register for other purposes...
> >> 
> > 
> > So I think now the solution is to make this code OVMF only, are you
fine
> > with this?
> 
> Yes, provided you widen the location to at least 4 bytes.
> 
I''m afraid I cannot widen the location (not for technical reason).
It''s
a conventional protocol used by these non traditional BIOSes. It
doesn''t
make sense to change Xen only, right?

Wei.
> Jan

>>> On 12.11.13 at 14:57, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> On Tue, 2013-11-12 at 13:21 +0000, Jan Beulich wrote:
>> >>> On 12.11.13 at 13:37, Wei Liu <wei.liu2@citrix.com>
wrote:
>> > On Tue, Nov 12, 2013 at 12:30:52PM +0000, Jan Beulich wrote:
>> >> >>> On 12.11.13 at 13:11, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> >> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> >>As it stands for HVM guests the e820 map is determined
by hvmloader, so
>> >> >>it makes sense for it to populate standard CMOS
locations with the
>> >> >>values they should have.
>> >> > 
>> >> > CMOS has memory values? That is standard PC spec? Yikes!
>> >> 
>> >> That''s the first time I hear about this - there are a
couple of more
>> >> or less standard locations in CMOS where some of the memory
>> >> gets reported, but all are at most two bytes wide and (having
at
>> >> best 64k granularity) don''t allow expressing memory
beyond 4Gb.
>> >> 
>> >> Now, if there is a standard for the locations used here, fine
with
>> >> me (but it should be referenced in the commit message then).
But
>> >> if this is custom, then I wonder (a) how compatible such an
>> >> extension is going to be and (b) why it needs to be restricted
to
>> >> 3 bytes (allowing to cover only up to 1Tb).
>> >> 
>> > 
>> > It''s not custom.
>> > 
>> > AFAICT Boches reads this, seabios reads this (when not running on
Xen)
>> > and OVMF reads this as well.
>> 
>> These are all non-traditional BIOSes, and a reasonably reliable
>> documentation aspect can''t be taken from their sources or
>> accompanying documentation.
>> 
>> > However in some CMOS maps I found those bytes are marked as
reserved.
>> 
>> Exactly. The question is whether some _other_ BIOSes then use
>> these register for other purposes...
> 
> Why do we care about any BIOS other than ROMBIOS, SeaBIOS and OVMF?
Because OSes may make assumptions (whether such assumptions
are universally valid is another thing of course).

Jan

>>> On 12.11.13 at 15:00, Wei Liu <wei.liu2@citrix.com> wrote:
> On Tue, Nov 12, 2013 at 01:56:02PM +0000, Jan Beulich wrote:
>> >>> On 12.11.13 at 14:39, Wei Liu <wei.liu2@citrix.com>
wrote:
>> > On Tue, Nov 12, 2013 at 01:21:36PM +0000, Jan Beulich wrote:
>> >> >>> On 12.11.13 at 13:37, Wei Liu
<wei.liu2@citrix.com> wrote:
>> >> > However in some CMOS maps I found those bytes are marked
as reserved.
>> >> 
>> >> Exactly. The question is whether some _other_ BIOSes then use
>> >> these register for other purposes...
>> >> 
>> > 
>> > So I think now the solution is to make this code OVMF only, are
you fine
>> > with this?
>> 
>> Yes, provided you widen the location to at least 4 bytes.
>> 
> 
> I''m afraid I cannot widen the location (not for technical reason).
It''s
> a conventional protocol used by these non traditional BIOSes. It
doesn''t
> make sense to change Xen only, right?
Maybe, maybe not. But those other BIOSes must have some
understanding of how to support >1Tb systems?

Jan

On Tue, Nov 12, 2013 at 02:13:26PM +0000, Jan Beulich
wrote:
> >>> On 12.11.13 at 15:00, Wei Liu <wei.liu2@citrix.com>
wrote:
> > On Tue, Nov 12, 2013 at 01:56:02PM +0000, Jan Beulich wrote:
> >> >>> On 12.11.13 at 14:39, Wei Liu
<wei.liu2@citrix.com> wrote:
> >> > On Tue, Nov 12, 2013 at 01:21:36PM +0000, Jan Beulich wrote:
> >> >> >>> On 12.11.13 at 13:37, Wei Liu
<wei.liu2@citrix.com> wrote:
> >> >> > However in some CMOS maps I found those bytes are
marked as reserved.
> >> >> 
> >> >> Exactly. The question is whether some _other_ BIOSes then
use
> >> >> these register for other purposes...
> >> >> 
> >> > 
> >> > So I think now the solution is to make this code OVMF only,
are you fine
> >> > with this?
> >> 
> >> Yes, provided you widen the location to at least 4 bytes.
> >> 
> > 
> > I''m afraid I cannot widen the location (not for technical
reason). It''s
> > a conventional protocol used by these non traditional BIOSes. It
doesn''t
> > make sense to change Xen only, right?
> 
> Maybe, maybe not. But those other BIOSes must have some
> understanding of how to support >1Tb systems?
> 
Presumably yes. But that''s another topic.

My point is widening this field to 4 bytes would not make them support
more than 1TB of RAM, at least not in canonical way.

Wei.
> Jan

On Tue, 2013-11-12 at 14:12 +0000, Jan Beulich wrote:
> >>> On 12.11.13 at 14:57, Ian Campbell
<Ian.Campbell@citrix.com> wrote:
> > On Tue, 2013-11-12 at 13:21 +0000, Jan Beulich wrote:
> >> >>> On 12.11.13 at 13:37, Wei Liu
<wei.liu2@citrix.com> wrote:
> >> > On Tue, Nov 12, 2013 at 12:30:52PM +0000, Jan Beulich wrote:
> >> >> >>> On 12.11.13 at 13:11, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> >> >> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >> >>As it stands for HVM guests the e820 map is
determined by hvmloader, so
> >> >> >>it makes sense for it to populate standard CMOS
locations with the
> >> >> >>values they should have.
> >> >> > 
> >> >> > CMOS has memory values? That is standard PC spec?
Yikes!
> >> >> 
> >> >> That''s the first time I hear about this - there
are a couple of more
> >> >> or less standard locations in CMOS where some of the
memory
> >> >> gets reported, but all are at most two bytes wide and
(having at
> >> >> best 64k granularity) don''t allow expressing
memory beyond 4Gb.
> >> >> 
> >> >> Now, if there is a standard for the locations used here,
fine with
> >> >> me (but it should be referenced in the commit message
then). But
> >> >> if this is custom, then I wonder (a) how compatible such
an
> >> >> extension is going to be and (b) why it needs to be
restricted to
> >> >> 3 bytes (allowing to cover only up to 1Tb).
> >> >> 
> >> > 
> >> > It''s not custom.
> >> > 
> >> > AFAICT Boches reads this, seabios reads this (when not
running on Xen)
> >> > and OVMF reads this as well.
> >> 
> >> These are all non-traditional BIOSes, and a reasonably reliable
> >> documentation aspect can''t be taken from their sources or
> >> accompanying documentation.
> >> 
> >> > However in some CMOS maps I found those bytes are marked as
reserved.
> >> 
> >> Exactly. The question is whether some _other_ BIOSes then use
> >> these register for other purposes...
> > 
> > Why do we care about any BIOS other than ROMBIOS, SeaBIOS and OVMF?
> 
> Because OSes may make assumptions (whether such assumptions
> are universally valid is another thing of course).
It seems like the use of these CMOS values is a qemu-ism, perhaps
inherited from bochs or somewhere like that, from whence some of the
early virtual BIOSes came. See hw/i386/pc.c:pc_cmos_init().

I think given that it is used in this preexisting way under other virt
platforms there''s no cause to worry unduly about what OSes might do.

Ian.