Hi Andrew,
On 03/12/2025 18:49, Andrew Cooper wrote:
On 03/12/2025 6:23 pm, Julien Grall wrote:
Hi Andrew,
On 03/12/2025 17:16, Andrew Cooper wrote:
to keep it working, but there was apparently no use of ThumbEE
outside of demo
code, so simply drop it.
I am in favor of dropping support for ThumbEE for guest. But I am not
sure I understand this comment.
There's no production use of ThumbEE known to ARM.
Interesting. The Arm Arm is less assertive and in fact confusing, the
latest spec released in 2018 (ARM DDI 0406C.d) has the following:
"
From the publication of issue C.a of this manual, ARM deprecates any
use of the ThumbEE instruction set.
[...]
ThumbEE is both the name of the instruction set and the name of the
extension that provides support for that
instruction set. The ThumbEE Extension is:
• Required in implementations of the ARMv7-A profile.
"
I have also checked the TRM of the Cortex-A15 (one of the Armv7 CPU we
used to have in the CI before gitlab) and it supports ThumbEE. So I
think we need to additional diff you sent in this patch.
Are you saying there are no processors supporting ThumbEE where Xen
would run? Asking because below, you are removing code to context
switch the ThumbEE registers. But I don't see any code that would
ensure the registers are trapping (i.e. HSTR.TEE is set). So wouldn't
this result to a cross-VM leak on those processors?
If we really don't want to support CPU where ThumbEE is available,
then we should check that "cpu_has_thumbee" is 0.
The registers exist in ARM v7 only. They do not exist in ARM v8.
I suppose yes this change would result in a cross-VM leak on hardware
supporting ThumbEE.
Can HSTR.TTEE be set unilaterally, or does it need gating on
cpu_has_thumbee?
From my understanding of the Armv7 specification, the bit doesn't need
to be gated. The Armv8 specification suggest it is RES0 so in theory it
could be used in the future. So the diff you sent is correct.
Is setting HSTR.TTEE sufficient to cause an undefined instruction
exception to be thrown back at a guest which goes poking? (I guess this
is really "will the default do the right thing")
I believe so. The default behavior in Xen is to inject an undefined
exception if it can't handle a trap.
I'll freely admit that I'm out of my depth here, but the build failure
does need fixing.
I agree. Do we need to include the fix in 4.19 (I think Jan asked to cut
it tomorrow)? Thanks for sending the patch!
Cheers,
--
Julien Grall
