On 18/12/2024 3:54 pm, Andrew Cooper wrote:
> On 02/12/2024 9:49 am, Teddy Astie wrote:
>> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h
>> b/xen/arch/x86/include/asm/hvm/hvm.h
>> index 02de18c7d4..dbc37e8b75 100644
>> --- a/xen/arch/x86/include/asm/hvm/hvm.h
>> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
>> @@ -26,6 +26,12 @@ extern bool opt_hvm_fep;
>> #define opt_hvm_fep 0
>> #endif
>>
>> +#define X86_MODE_REAL 0
>> +#define X86_MODE_VM86 1
>> +#define X86_MODE_16BIT 2
>> +#define X86_MODE_32BIT 4
>> +#define X86_MODE_64BIT 8
>> +
>> /* Interrupt acknowledgement sources. */
>> enum hvm_intsrc {
>> hvm_intsrc_none,
> We discussed this in the x86 meeting. These want to live next to
> hvm_guest_x86_mode() with a comment stating that they're not
> architectural modes.
>
> During your work, you seem to have only looked at the the VMX side of
> things.
>
> There are several callers of hvm_guest_x86_mode() and
> svm_guest_x86_mode() missed. Also an unnecessary include, and a couple
> of overly long lines.
>
> https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=commitdiff;h=4f8f63d49776d69ed9a978b6601c13c54c579a98
> is the incremental fix on top of this patch.
>
> Does this look reasonable?
>
>
> I've just realised that the check in nvmx_handle_vmx_insn() is an
> incredibly complicated way of expressing guest_cr[0].PE, and we've got
> the same opencoded elsewhere, so I'll also prepare a patch prerequisite
> patch to sort that out, then rebase this over it.
No. It's subtly not (only) a PE check, so lets leave it as is for now.
I'll update the comment to say that some users rely on the order of
constants.
~Andrew
