Check the e820 entries we get from qemu for ram entries and handle them accordingly:
(1) Entries overlapping with the lowmem range will be ignored. At least initially qemu will not send such entries for compatibility reasons. That may change in the future though if qemu needs a more recent seabios versions anyway for some reason. So better be prepared. (2) Adjust RamSizeOver4G variable if we find it being too small. Needed for guests with more that 1TB (this is the max amount of memory the three-byte cmmos interface can represent).
Signed-off-by: Gerd Hoffmann kraxel@redhat.com --- src/fw/paravirt.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index c118480..c1469ae 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -285,6 +285,15 @@ qemu_cfg_legacy(void) int i; for (i = 0; i < count32; i++) { qemu_cfg_read(&entry, sizeof(entry)); + if (entry.type == E820_RAM) { + if (entry.address < RamSize) + // ignore, we got it from cmos already and + // adding this again would ruin any reservations + // done so far + continue; + if (0x100000000LL + RamSizeOver4G < entry.address + entry.length) + RamSizeOver4G = entry.address + entry.length - 0x100000000LL; + } add_e820(entry.address, entry.length, entry.type); } } else if (runningOnKVM()) {
On Mo, 2013-10-14 at 10:28 +0200, Gerd Hoffmann wrote:
Check the e820 entries we get from qemu for ram entries and handle them accordingly:
(1) Entries overlapping with the lowmem range will be ignored. At least initially qemu will not send such entries for compatibility reasons. That may change in the future though if qemu needs a more recent seabios versions anyway for some reason. So better be prepared. (2) Adjust RamSizeOver4G variable if we find it being too small. Needed for guests with more that 1TB (this is the max amount of memory the three-byte cmmos interface can represent).
Qemu patch for this: http://patchwork.ozlabs.org/patch/282253/
cheers, Gerd
On Mon, 14 Oct 2013 10:28:08 +0200 Gerd Hoffmann kraxel@redhat.com wrote:
Check the e820 entries we get from qemu for ram entries and handle them accordingly:
(1) Entries overlapping with the lowmem range will be ignored. At least initially qemu will not send such entries for compatibility reasons. That may change in the future though if qemu needs a more recent seabios versions anyway for some reason. So better be prepared. (2) Adjust RamSizeOver4G variable if we find it being too small. Needed for guests with more that 1TB (this is the max amount of memory the three-byte cmmos interface can represent).
Signed-off-by: Gerd Hoffmann kraxel@redhat.com
src/fw/paravirt.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index c118480..c1469ae 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -285,6 +285,15 @@ qemu_cfg_legacy(void) int i; for (i = 0; i < count32; i++) { qemu_cfg_read(&entry, sizeof(entry));
if (entry.type == E820_RAM) {if (entry.address < RamSize)// ignore, we got it from cmos already and// adding this again would ruin any reservations// done so farcontinue;if (0x100000000LL + RamSizeOver4G < entry.address + entry.length)RamSizeOver4G = entry.address + entry.length - 0x100000000LL;
it's all based on assumption that there is only one highmem entry, why don't take just entry.length then?
} add_e820(entry.address, entry.length, entry.type); }
Hi,
if (0x100000000LL + RamSizeOver4G < entry.address + entry.length)RamSizeOver4G = entry.address + entry.length - 0x100000000LL;it's all based on assumption that there is only one highmem entry, why don't take just entry.length then?
Would work today as entry.address will be 0x100000000LL at this point no matter what. But if that ever changes -- say due to qemu gaining support for non-contigous memory -- things will break. So we better should do the math to be on the safe side for the future.
cheers, Gerd
On Mon, 14 Oct 2013 14:22:15 +0200 Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
if (0x100000000LL + RamSizeOver4G < entry.address + entry.length)RamSizeOver4G = entry.address + entry.length - 0x100000000LL;it's all based on assumption that there is only one highmem entry, why don't take just entry.length then?
Would work today as entry.address will be 0x100000000LL at this point no matter what. But if that ever changes -- say due to qemu gaining support for non-contigous memory -- things will break. So we better should do the math to be on the safe side for the future.
providing we won't use RamSizeOver4G for 64-bit PCI window placement, the only dependency on it left is SMBIOS which will silently break if non-contigous memory are to be used regardless of how we count RamSizeOver4G.
There might be fair chance of that happening if system is rebooted after memory hotplug. We don't have to update e820 table with a hotplugged regions since they are described as ACPI devices but a real hardware does so since not every OS supports onlinig ACPI memory devices on startup (I'd say it's OS's bug though).
cheers, Gerd
On Mo, 2013-10-14 at 15:24 +0200, Igor Mammedov wrote:
On Mon, 14 Oct 2013 14:22:15 +0200 Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
if (0x100000000LL + RamSizeOver4G < entry.address + entry.length)RamSizeOver4G = entry.address + entry.length - 0x100000000LL;it's all based on assumption that there is only one highmem entry, why don't take just entry.length then?
Would work today as entry.address will be 0x100000000LL at this point no matter what. But if that ever changes -- say due to qemu gaining support for non-contigous memory -- things will break. So we better should do the math to be on the safe side for the future.
providing we won't use RamSizeOver4G for 64-bit PCI window placement, the only dependency on it left is SMBIOS which will silently break if non-contigous memory are to be used regardless of how we count RamSizeOver4G.
Long-term RamSizeOver4G will probably go away. For now we will continue to need it for qemu versions not supporting etc/pcimem64-start.
smbios dependency can be removed by either making smbios look at the e820 table instead or by qemu providing smbios tables too. One of these two has to happen for non-contignous memory support.
cheers, Gerd
On Mon, 14 Oct 2013 10:28:08 +0200 Gerd Hoffmann kraxel@redhat.com wrote:
Check the e820 entries we get from qemu for ram entries and handle them accordingly:
(1) Entries overlapping with the lowmem range will be ignored. At least initially qemu will not send such entries for compatibility reasons. That may change in the future though if qemu needs a more recent seabios versions anyway for some reason. So better be prepared. (2) Adjust RamSizeOver4G variable if we find it being too small. Needed for guests with more that 1TB (this is the max amount of memory the three-byte cmmos interface can represent).
Signed-off-by: Gerd Hoffmann kraxel@redhat.com
Reviewed-By: Igor Mammedov imammedo@redhat.com
src/fw/paravirt.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index c118480..c1469ae 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -285,6 +285,15 @@ qemu_cfg_legacy(void) int i; for (i = 0; i < count32; i++) { qemu_cfg_read(&entry, sizeof(entry));
if (entry.type == E820_RAM) {if (entry.address < RamSize)// ignore, we got it from cmos already and// adding this again would ruin any reservations// done so farcontinue;if (0x100000000LL + RamSizeOver4G < entry.address + entry.length)RamSizeOver4G = entry.address + entry.length - 0x100000000LL;} add_e820(entry.address, entry.length, entry.type); }
-
Gerd Hoffmann -
Igor Mammedov