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