On Fri, Jun 17, 2016 at 09:47:27AM +0200, Paolo Bonzini wrote: > On 16/06/2016 22:14, Eduardo Habkost wrote: > > This is necessary only when phys_bits is higher on the > > destination, right? > > > > Should we really default this to true? I would like to enable > > this hack only when really necessary. Except when using host's > > phys_bits (phys-bits=0), is there any valid reason to expect > > higher phys-bits on the destination? > > It would need a property even if you did it only for phys-bits==0, and > then it's simpler to just do it always. > > The bits are reserved anyway, so we can do whatever we want with them. > In fact I think it's weird for the architecture to make them > must-be-zero, it might even make more sense to make them must-be-one... > It's a mask after all, and there's no way to access out-of-range > physical addresses.
If we always fill the bits on the source, the destination can't differentiate between a 40-bit source that set the MTRR to 0xffffffffff from a 36-bit source that set the MTRR to 0xfffffffff. I really want to print a warning if the MTRR value or the phys-bits value is being changed during migration, just in case this has unintended consequences in the future. We can send the current phys_bits value in the migration stream, so the destination can decide how to handle it (and which warnings to print). -- Eduardo
