On Thu, Jan 21, 2016 at 08:48:53AM +0100, Gerd Hoffmann wrote: > On Mi, 2016-01-20 at 19:25 +0200, Michael S. Tsirkin wrote: > > On Wed, Jan 20, 2016 at 03:15:04PM -0200, Eduardo Habkost wrote: > > > On Wed, Jan 20, 2016 at 01:34:29PM -0200, Eduardo Habkost wrote: > > > [...] > > > > 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) > > > > > > Ignore the suggestion above. I forgot that gigabyte_align applies > > > only if ram_size > 3.5GB (so setting max_ram_below_4g = 3G on > > > pc > 1.7 wouldn't work). So, unless somebody has a suggestion > > > that makes this logic simpler: > > > > I wonder whether we should just bite the bullet and ask management to > > maintain the physical memory map for us, instead of trying to give us > > hints. > > I doubt this simplified things, given the backward compatibility > constrains we have. > > cheers, > Gerd
That's exactly what would become simple. For backwards compatibility we would leave things alone if the new flags for the memory map aren't specified. This would allow people to e.g. allocate phy address ranges for things like nvdimm which has been problematic in the past. The issue as I see it is not compatibility, but rather creating a way for both management and command line users to figure out valid address ranges. And, it all might just be too complex for users. -- MST
