On Wed, Jan 20, 2016 at 03:55:33PM +0100, Gerd Hoffmann wrote: > Hi, > > > > + * qemu -M pc,max-ram-below-4g=2G -m 4G -> 2048M low, 2048M > > > high > > > I assume max-ram-below-4g > 3.5G was unsupported before, and we > > are breaking compatibility intentionally. > > max-ram-below-4g did only reduce memory, so max-ram-below-4g > 3.5G (or > max-ram-below-4g > 3G with gigabyte align) had no effect and therefore > is something pretty pointless.
I see. So, if max-ram-below-4g > 3G with gigabyte align was unsupported too, my example below is also not relevant regarding compatibility. > > I'd expect the one case quoted above to be the only case relevant in > practice (i.e. move split from 3G to 2G for more PCI I/O space), > especially given that the option was added after gigabyte alignment > support. > > > Because this patch also > > changes the resulting memory layout when > > 3G < max_ram_below_4g < ram_size < 3.5G > > e.g.: > > qemu -M pc,max-ram-below-4g=3200M -m 3328M > > Ah, I see. With the patch applied the gigabyte align option is weighed > higher, so qemu wouldn't give you 3200M lowmem. I would be highly > surprised to see such a configuration in the wild ... The new behavior looks OK, considering that the option is just "_max_ RAM below 4G", not "split lowmem at this exact address". But it is inconsistent with the behavior when max-ram-below-4g < 3G (where gigabyte_align is ignored), and something we will need to keep compatibility for a long time. Considering that we never supported gigabyte_align && max_ram_below_4g > 3G || max_ram_below_4g > 3.5G before, we could simply remove the MachineClass::gigabyte_align field from pc_piix, and just do the following: * pc > 1.7: max_ram_below_4g = 3G (equivalent to gigabyte_align=true) * pc <= 1.7: max_ram_below_4g = 3.5G (equivalent to gigabyte_align=false) -- Eduardo
