Re: [Xen-devel] [PATCH 6/6] x86/emul: dedup hvmemul_cpuid() and pv_emul_cpuid()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.11.18 at 16:52, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 06/11/18 15:38, Jan Beulich wrote:
>>>>> On 05.11.18 at 12:21, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel