On 10/07/18 09:04, Wei Liu wrote: > On Mon, Jul 09, 2018 at 05:54:44PM +0100, Andrew Cooper wrote: >> Hello, >> >> (I feel as if I've sent this email before, but I can't find any record >> of it). >> >> The parameter was introduced in e661d66f51 (2006) and used in Xen, but >> removed from the hypervisor in c/s 5f14a87ce (2008) when CPUID >> calculations where moved from the hypervisor into libxc. >> >> However, the field has always been propagated in the migration stream. >> AFAICT, the only use for the HVM_PARAM is as a function parameter to >> xc_cpuid_apply_policy(), which is a very very expensive way of passing a >> function parameter! >> >> Another curiosity is that HVM and PVH guests treat the toplevel xl.cfg >> pae boolean differently. HVM honour the request, while PVH blindly >> ignores it and sets it to true. There is nothing wrong (in principle) >> with a PVH non-PAE guest, so the boolean should be honoured IMO. > Yes I think it should be honoured in PVH. > >> A separate usability niggle is that there is no interlink between the >> toplevel pae boolean and passing some custom cpuid= configuration. The >> latter appears to take priority but only due to the order in which libxl >> processes the data. >> > I think we either make them interact properly or document which one > takes precedence.
Actually, I'd opt for formally deprecating the toplevel boolean. We will have to leave it working, but we should discourage its use. In the past, it was used to hide PSE36 from 32bit HVM guests, as the shadow code doesn't support PSE36 (This questionable use has since been fixed differently). It is also my understanding that shadowing 2-on-3 was easier than shadowing 3-on-3 back in the days of the 32bit hypervisor build, so hiding the PAE bit was a legitimate performance tradeoff. However, PAE is a direct prerequisite for NX and 64bit support, so I don't expect anyone has used this option in the past 10 years. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
