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
