On Fri, Jun 17, 2016 at 05:29:21PM +0200, Paolo Bonzini wrote: > > > On 17/06/2016 17:27, Eduardo Habkost wrote: > > On Fri, Jun 17, 2016 at 04:25:57PM +0200, Paolo Bonzini wrote: > >> > >> > >> On 17/06/2016 15:41, Eduardo Habkost wrote: > >>> In theory, we should never initialize anything on the machine > >>> based on the host we are running. In practice we sometimes do > >>> that, and we know it's unsafe. Sending the value on the migration > >>> stream is a solution to detect when this breaks something. We did > >>> that before, for TSC frequency. > >>> > >>> I prefer to add a little extra code, than to waste time debugging > >>> when that stuff breaks. > >> > >> Fair enough (but still let's add and strip the 1s in pre_save and > >> post_load). It is a good justification for sending configuration over > >> the wire, that we initialize things based on the host we're running. > >> > >> But we shouldn't initialize more things based on the host (e.g. new > >> booleans should be "enforce"-style). > > > > Strongly agreed. > > > >> Also I don't really like > >> introducing sanity checks for those that aren't based on the host (as in > >> the LMCE thread). This code will never trigger in practice, so it's > >> just extra cost for no benefit. > > > > Our experience with guest ABI and compatibility code tells me > > otherwise. Keeping guest ABI is hard, so I would always support > > adding extra code to help us catch mistakes (either in QEMU, > > management software, or user mistakes). > > I agree, but I think the "enforce"-style properties are enough (and > count as extra code :)).
I agree they are enough when bits have an easy 1-1 correspondence to command-line options. I was thinking about things like CPUID bits, that depend on complex CPU model + accelerator + machine-type interactions. -- Eduardo
