On 21/08/2018 16:51, Jan Beulich wrote: >>>> On 21.08.18 at 17:28, <yu.c.zh...@intel.com> wrote: >> Thanks Lars for the summary, and sorry for the late update. >> >> My question is about the cpuid policy for MAXPHYSADDR in Xen. >> >> It seems Xen is exposing the host MAXPHYSADDR value to HVM as the default >> choice. And I am wondering, what if a VM is created on a hardware platform >> with address width A, and later migrated to another platform with address >> width B? Should this be allowed in Xen? > Andrew's further leveling work is, afaiu, going to include leveling of > that field as well.
I certainly planned to, but as it turns out, that it is rather more complicated than I'd hoped. There is a corner case where, if maxphyaddr is levelled lower than the current hardware, and the guest is relying on #PF[RSVD] tricks, if the only reserved bit(s) they set were in the difference between the real and virtualised maxphyaddr, and the pagewalk takes an access violation rather than a terminal fault, Xen has no way of faking up the RSVD property because the access won't elicit an EPT-based VMExit. Given that migration has been working well enough thus far (with the CPUID view of maxphyaddr changing under the guests feet), this may be of little concern, but it still has me somewhat worried. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
