>>> On 06.11.18 at 16:52, <andrew.coop...@citrix.com> wrote: > On 06/11/18 15:38, Jan Beulich wrote: >>>>> On 05.11.18 at 12:21, <andrew.coop...@citrix.com> wrote: >>> They are identical, so provide a single x86emul_cpuid() instead. >>> >>> As x86_emulate() now only uses the ->cpuid() hook for real CPUID > instructions, >>> the hook can be omitted from all special-purpose emulation ops. >> So I was expecting the hook to go away altogether, but I >> now realize that it can't because of some of the customization >> that's needed. That, in turn, means that the removal of the >> hook specification as per above will get us into problems the >> moment we need to check a feature that can't be taken >> straight from the policy object. I'm therefore unconvinced we >> actually want to go this far. It'll require enough care already >> to not blindly clone a new vcpu_has_...() wrongly from the >> many pre-existing examples in such a case. Thoughts? > > All dynamic bits in CPUID are derived from other control state. e.g. we > check CR4.OSXSAVE, not CPUID.OSXSAVE. The other dynamic bits are APIC, > which comes from MSR_APIC_BASE, and OSPKE which also comes from CR4. > > In the emulator itself, I think it would be a bug if we ever had > vcpu_has_osxsave etc, because that isn't how pipelines actually behave. > The feature checks here are semantically equivalent to "do the > instruction decode and execution units have silicon to cope with these > instructions".
I agree that vcpu_has_os* makes no sense, but the APIC bit for example isn't really pipeline / decoder related. However, one issue already might be that in order for bits in a (sub)leaf above (guest) limits to come out all clear, it is guest_cpuid() which cuts things off. Neither cpuid_featureset_to_policy() nor its inverse nor sanitise_featureset() look to zap fields above limits, in case they've been previously set to non-zero values. Am I overlooking something? Furthermore I wouldn't exclude that we may need to look at a hypervisor or Viridian leaf at some point. The dynamic vPMU adjustments also look potentially problematic, if we were to emulate RDPMC (albeit they're DS-related only right now). And then there's the dynamic exposing of MONITOR for PV; granted I don't expect us to ever emulate this for PV, but it shows the general issue. Plus there's SYSCALL, the insn emulation of which currently doesn't check the (dynamically adjusted) CPUID bit. And finally LWP, which again we can only hope we'll never have to emulate. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
