qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Default for phys-addr-bits? (was Re: [PATCH 4/5] x86: A


From: Paolo Bonzini
Subject: Re: [Qemu-devel] Default for phys-addr-bits? (was Re: [PATCH 4/5] x86: Allow physical address bits to be set)
Date: Wed, 22 Jun 2016 14:41:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1


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, 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



reply via email to

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