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

[Andrea Arcangeli]

On Thu, Jun 23, 2016 at 01:44:06AM +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 22, 2016 at 04:24:14PM +0200, Andrea Arcangeli wrote:
> > > 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.
> > 
> > But the crash with guest phys bits > host phys bits is material, linux
> > will definitely crash in such condition.
> 
> Why would it? Most GPA addresses are not guest controllable.
> Don't give guest addresses that host can't access, you will not get
> a crash.
> 
> The only exception I know of is PCI BARs but we can limit
> these to a safe addressable range using _CRS method in ACPI.
> 
> Could you explain please?

Well the crash of guest phys bits > host phys bits, should be easy to
reproduce by booting a 65GB guest on a 64GB RAM + 2GB swap host with
36 host phys bits using the upstream qemu that forces the guest phys
bits to 40.

Likely the guest won't boot properly regardless if the PCI bars are at
the end, but it may have a chance to print something meaningful on the
console while trying instead of failing in some unexpected way.

Now the production patch fixes it 100% by using the host bits instead
of value 40. However you'd run into the instability if you migrate the
same guest to the aformentioned host.

No amount of guest changes can fix the above. So then we can avoid any
risk of breakages also during live migration introducing a "soft"
guest phys bits set as low as possible. And live migration restore can
check it against the host phys bits.

The other case (guest phys bits < host phys bits) instead requires a
guest doing something strange, definitely never going to be a problem
with linux as guest at least.