[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 3/5] x86: fill high bits of mtrr mask
Date: Fri, 17 Jun 2016 09:46:41 -0300
User-agent: Mutt/1.6.1 (2016-04-27)

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]