Re: [Qemu-devel] Default for phys-addr-bits? (was Re: [PATCH 4/5] x86: Allow physical address bits to be set)

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 22, 2016 at 02:41:22PM +0200, Paolo Bonzini wrote:
> 
> 
> On 21/06/2016 21:44, Eduardo Habkost wrote:
> > The consequences of migrating (or having migration blocked) to a
> > host with smaller phys-addr-bits sound worse to me than the
> > consequences of just having guest's phys-addr-bits smaller than
> > the host's.
> 
> There is no correct answer.  We've been using host phys-addr-bits in
> RHEL for 6 years and no one has ever reported a bug.
> 
> Most data centers (the ones that actually use migration) will all have
> Xeon E5s and above, and pretty much all of them have 46-bits physical
> address bits since at least Sandy Bridge.  That probably helps.
> Save/restore is usually done on the same machine, which also helps
> because host phys-addr-bits doesn't change.
> 
> >From a semantics point of view, using a smaller phys-addr-bits than the
> host is the worst, because you tell the guest that some bits are
> must-be-zero, when they're not.  Using a larger phys-addr-bits cannot
> cause malfunctioning, only crashes (and as Gerd said, if you cross your
> fingers and hope the guest doesn't put anything so high in memory,
> chances are you'll succeed), and this makes it "safer".  I'm not sure
> which one is more likely to happen.
> 
> So there's no correct answer,


Wait a second:

1. Use CPUID to tell guest it can address 46 bits
2. use e820 to tell guest RAM has addresses below e.g. 39 bits
3. _CRS to tell guest not to put anything above e.g. 39 bits

will result in guest never using any addresses above 39 bits but
also always setting bits 39 to 46 to zero.

No crashes, no corruptions.

Where's a problem then?



> and that's why I think the lesser evil is
> to go with the time-tested alternative and use host phys-addr-bits as
> the default, even if it causes weird behavior on migration.  If a fixed
> phys-addr-bits is specified on the destination, it should match the
> value that was used on the source though.
> 
> Paolo


I agree, but I don't see a need to use host bits at all.
So I think that all we need is a way to let libvirt control
the _CRS range. Teach it that _CRS must fit within what
host can support. Also check and fail kvm init if _CRS exceeds
what host can support.

Hmm?

-- 
MST