Patchwork add 40-48 bit RAM range to seabios

login
register
mail settings
Submitter Andrea Arcangeli
Date Sept. 15, 2010, 5:15 p.m.
Message ID <20100915171528.GO5981@random.random>
Download mbox | patch
Permalink /patch/64857/
State New
Headers show

Comments

Andrea Arcangeli - Sept. 15, 2010, 5:15 p.m.
Subject: add 40-48 bit RAM range to seabios

From: Andrea Arcangeli <aarcange@redhat.com>

Needed to show >1TB RAM to guests.

This uses a new cmos port at 0x5e that shall read zero to be backwards
compatible.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
Kevin O'Connor - Sept. 17, 2010, 1:47 a.m.
On Wed, Sep 15, 2010 at 07:15:28PM +0200, Andrea Arcangeli wrote:
> Subject: add 40-48 bit RAM range to seabios
> 
> From: Andrea Arcangeli <aarcange@redhat.com>
> 
> Needed to show >1TB RAM to guests.
> 
> This uses a new cmos port at 0x5e that shall read zero to be backwards
> compatible.
> 
> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>

It looks okay to me.  Can you provide an Acked-by from one of the qemu
or kvm maintainers?

-Kevin
Anthony Liguori - Sept. 17, 2010, 12:53 p.m.
On 09/16/2010 08:47 PM, Kevin O'Connor wrote:
> On Wed, Sep 15, 2010 at 07:15:28PM +0200, Andrea Arcangeli wrote:
>    
>> Subject: add 40-48 bit RAM range to seabios
>>
>> From: Andrea Arcangeli<aarcange@redhat.com>
>>
>> Needed to show>1TB RAM to guests.
>>
>> This uses a new cmos port at 0x5e that shall read zero to be backwards
>> compatible.
>>
>> Signed-off-by: Andrea Arcangeli<aarcange@redhat.com>
>>      
> It looks okay to me.  Can you provide an Acked-by from one of the qemu
> or kvm maintainers?
>    

Is CMOS the best place to communicate this (as opposed to fw_cfg)?

I know we currently expose memory size via CMOS but perhaps it's better 
to switch to a 64-bit fw_cfg value.

Regards,

Anthony Liguori

> -Kevin
>
Kevin O'Connor - Sept. 17, 2010, 1:11 p.m.
On Fri, Sep 17, 2010 at 07:53:12AM -0500, Anthony Liguori wrote:
> On 09/16/2010 08:47 PM, Kevin O'Connor wrote:
> >On Wed, Sep 15, 2010 at 07:15:28PM +0200, Andrea Arcangeli wrote:
> >>This uses a new cmos port at 0x5e that shall read zero to be backwards
> >>compatible.
> >It looks okay to me.  Can you provide an Acked-by from one of the qemu
> >or kvm maintainers?
> 
> Is CMOS the best place to communicate this (as opposed to fw_cfg)?
> 
> I know we currently expose memory size via CMOS but perhaps it's
> better to switch to a 64-bit fw_cfg value.

I'd personally prefer fw_cfg.

Also, another possibility would be to stop sending an absolute max and
to instead send a map of memory.  The latter would allow for
non-contiguous memory.

-Kevin
H. Peter Anvin - Sept. 17, 2010, 6:49 p.m.
On 09/17/2010 06:11 AM, Kevin O'Connor wrote:
> On Fri, Sep 17, 2010 at 07:53:12AM -0500, Anthony Liguori wrote:
>> On 09/16/2010 08:47 PM, Kevin O'Connor wrote:
>>> On Wed, Sep 15, 2010 at 07:15:28PM +0200, Andrea Arcangeli wrote:
>>>> This uses a new cmos port at 0x5e that shall read zero to be backwards
>>>> compatible.
>>> It looks okay to me.  Can you provide an Acked-by from one of the qemu
>>> or kvm maintainers?
>>
>> Is CMOS the best place to communicate this (as opposed to fw_cfg)?
>>
>> I know we currently expose memory size via CMOS but perhaps it's
>> better to switch to a 64-bit fw_cfg value.
> 
> I'd personally prefer fw_cfg.
> 
> Also, another possibility would be to stop sending an absolute max and
> to instead send a map of memory.  The latter would allow for
> non-contiguous memory.
> 

That would be highly useful for testing purposes.

	-hpa

Patch

diff --git a/src/cmos.h b/src/cmos.h
index e4b6462..e810534 100644
--- a/src/cmos.h
+++ b/src/cmos.h
@@ -36,9 +36,10 @@ 
 #define CMOS_BIOS_BOOTFLAG1      0x38
 #define CMOS_BIOS_DISKTRANSFLAG  0x39
 #define CMOS_BIOS_BOOTFLAG2      0x3d
-#define CMOS_MEM_HIGHMEM_LOW     0x5b
-#define CMOS_MEM_HIGHMEM_MID     0x5c
-#define CMOS_MEM_HIGHMEM_HIGH    0x5d
+#define CMOS_MEM_HIGHMEM_16      0x5b
+#define CMOS_MEM_HIGHMEM_24      0x5c
+#define CMOS_MEM_HIGHMEM_32      0x5d
+#define CMOS_MEM_HIGHMEM_40      0x5e
 #define CMOS_BIOS_SMP_COUNT      0x5f
 
 // CMOS_FLOPPY_DRIVE_TYPE bitdefs
diff --git a/src/post.c b/src/post.c
index 5d0e2cb..3628ff5 100644
--- a/src/post.c
+++ b/src/post.c
@@ -106,9 +106,10 @@  ram_probe(void)
         add_e820(0, rs, E820_RAM);
 
         // Check for memory over 4Gig
-        u64 high = ((inb_cmos(CMOS_MEM_HIGHMEM_LOW) << 16)
-                    | ((u32)inb_cmos(CMOS_MEM_HIGHMEM_MID) << 24)
-                    | ((u64)inb_cmos(CMOS_MEM_HIGHMEM_HIGH) << 32));
+        u64 high = ((inb_cmos(CMOS_MEM_HIGHMEM_16) << 16)
+                    | ((u32)inb_cmos(CMOS_MEM_HIGHMEM_24) << 24)
+                    | ((u64)inb_cmos(CMOS_MEM_HIGHMEM_32) << 32)
+		    | ((u64)inb_cmos(CMOS_MEM_HIGHMEM_40) << 40));
         RamSizeOver4G = high;
         add_e820(0x100000000ull, high, E820_RAM);