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 ---
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);
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
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 Arcangeliaarcange@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 Arcangeliaarcange@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
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
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
-
Andrea Arcangeli -
Anthony Liguori -
H. Peter Anvin -
Kevin O'Connor