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". ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
