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

[Andrea Arcangeli <aarcange@redhat.com>]

On Wed, Jun 22, 2016 at 04:48:50PM +0200, Paolo Bonzini wrote:
> KVM encodes other information in the sPTE when it sets the reserved bit
> (a generation count).  Instead of using all bits up to 51, KVM could
> well use bit MAXPHYADDR+1 as a marker and add bits MAXPHYADDR+2...51 to
> the generation count.

It could but it doesn't, doesn't it?

> You cannot really rely on what the guest does, no matter how crazy it seems.

I agree, but then to support such guest with full safety, we should
disable live migration if host phys bits change, which we clearly
aren't doing (at least by default), nor planning to do as it's way too
restrictive and it'd be a nuisance for a purely theoretical issue.

Considering the unfixable issues there are in live migration if a
guest uses the phys bits to calculate the first must be zero bit in
the pagetables, I don't think any OS will start to do that, nor
KVM in nested virt.

host phys bits < "soft" guest phys bits is more material issue the
guest cannot prevent in software, it already broke the mtrr in fact
(which thankfully can be fixed in the emulation layer with David's
patch).

This is why I think a "soft" guest phys bits would provide a peace of
mind for a 100% reliable live migration in the future.

Starting with the production solution (plus the mtrr fix that as
expected only matters for live migration) sounds fine to me, how far
we go with the "soft" guest phys bits, then depends on the complexity
of calculating the highest possible physical address with pci/memory
hotplug.

The only thing I'm not in full agreement with, is that the concern of
"soft" guest phys bits < host phys bits should be considered a
material concern, that to me sounds purely theoretical and in any case
it's fixable by changing the guest source code to provide full
reliability if "soft" guest phys bits < host phys.

With "soft" guest phys bits > host phys bits there's nothing the guest
software can do to avoid running into troubles instead.

If we introduce later a "soft" guest phys bits set to the lowest
possible value that can fit the highest possible physical address of
the guest, we should still then have a -cpu=force_host_phys_bits flag
to handle the extreme case of proprietary OS which would depend on the
must zero bits pagetable violations, but I don't think anybody would
ever need to use such flag.

Thanks,
Andrea