Re: [Qemu-devel] [PATCH 3/5] x86: fill high bits of mtrr mask

[Eduardo Habkost]

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