| Message ID | 20100915171528.GO5981@random.random |
|---|---|
| State | New |
| Headers | show |
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 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 >
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
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);