On 04.10.2025 00:53, Andrew Cooper wrote:
> ERETU, unlike IRET, requires the sticky-1 bit (bit 2) be set, and reserved
> bits to be clear. Notably this means that dom0_construct() must set
> X86_EFLAGS_MBS it in order for a PV dom0 to start.
Nit: Seemingly stray "it".
> Xen has been overly lax with reserved bit handling. Adjust
> arch_set_info_guest*() and hypercall_iret() which consume flags to clamp the
> reserved bits for all guest types.
>
> This is a minor ABI change, but by the same argument as commit
> 9f892f84c279 ("x86/domctl: Stop using XLAT_cpu_user_regs()"), the reserved
> bits would get clamped naturally by hardware when the vCPU is run.
>
> This allows PV guests to start when Xen is using FRED mode.
>
> Signed-off-by: Andrew Cooper <[email protected]>
> ---
> CC: Jan Beulich <[email protected]>
> CC: Roger Pau Monné <[email protected]>
>
> v3:
> * Rewrite the commit message.
> v2:
> * New
>
> The handling of VM is complicated.
>
> It turns out that it's simply ignored by IRET in Long Mode (i.e. clearing it
> commit 0e47f92b0725 ("x86: force EFLAGS.IF on when exiting to PV guests")
> wasn't actually necessary) but ERETU does care.
>
> But, it's unclear how to handle this in in arch_set_info(). We must preserve
> it for HVM guests (which can use vm86 mode). PV32 has special handling but
> only in hypercall_iret(), not in arch_set_info().
And what's wrong with adding special handling? (Apart from this the patch looks
good to me.)
Jan
