From: Paolo Bonzini <pbonzini@redhat.com>
To: Phil Dennis-Jordan <lists@philjordan.eu>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH] target/i386/hvf: hide MPX states from XCR0
Date: Wed, 30 Oct 2024 14:35:40 +0100 [thread overview]
Message-ID: <5eedaf78-78f5-40c1-a240-942b55a2450e@redhat.com> (raw)
In-Reply-To: <CAGCz3vtb9Afiq0JbthJQrn=hkXJ=X6cEKywuCs++bAqsf_+HMg@mail.gmail.com>
On 10/30/24 13:30, Phil Dennis-Jordan wrote:
> On Tue, 29 Oct 2024 at 14:05, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> QEMU does not show availability of MPX in CPUID when running under
>> Hypervisor.framework. Therefore, in the unlikely chance that the host
>> has MPX enabled, hide those bits from leaf 0xD as well.
>
> To clarify: is there some kind of issue with MPX in Qemu in general?
> Or is this a consistency effort - normal Macs don't expose this
> feature, so we have no idea if it were to work if someone did manage
> to hack up some frankensteinian host system that somehow does have
> those bits set?
That, and also that real hardware will only show XSTATE_BNDREGS_MASK and
XSTATE_BNDCSR_MASK if the MPX bit is set in CPUID; which it isn't in
hvf_get_supported_cpuid().
In fact, for completeness it should also go the other way: if
XSTATE_YMM_MASK is not set in the result of XGETBV, AVX should be
hidden. And if any of OPMASK, ZMM_Hi256 and Hi16_ZMM are not set in the
result of XGETBV, AVX512F (and AVX10 eventually) should be hidden in
hvf_get_supported_cpuid().
By the way, could you check if Macs set the PKRU bit of XCR0 (bit 9)
and/or the OSPKE bit in CPUID (that's bit 4 of CPUID[EAX=7, ECX=0].ECX)?
Thanks,
Paolo
>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> ---
>> target/i386/hvf/x86_cpuid.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/target/i386/hvf/x86_cpuid.c b/target/i386/hvf/x86_cpuid.c
>> index e56cd8411ba..4b184767f4a 100644
>> --- a/target/i386/hvf/x86_cpuid.c
>> +++ b/target/i386/hvf/x86_cpuid.c
>> @@ -110,9 +110,9 @@ uint32_t hvf_get_supported_cpuid(uint32_t func, uint32_t idx,
>> if (idx == 0) {
>> uint64_t host_xcr0;
>> if (xgetbv(ecx, 0, &host_xcr0)) {
>> + /* Only show xcr0 bits corresponding to usable features. */
>> uint64_t supp_xcr0 = host_xcr0 & (XSTATE_FP_MASK |
>> XSTATE_SSE_MASK | XSTATE_YMM_MASK |
>> - XSTATE_BNDREGS_MASK | XSTATE_BNDCSR_MASK |
>> XSTATE_OPMASK_MASK | XSTATE_ZMM_Hi256_MASK |
>> XSTATE_Hi16_ZMM_MASK);
>> eax &= supp_xcr0;
>> --
>> 2.47.0
>>
>>
>
>
next prev parent reply other threads:[~2024-10-30 13:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 13:04 [PATCH] target/i386/hvf: hide MPX states from XCR0 Paolo Bonzini
2024-10-30 12:30 ` Phil Dennis-Jordan
2024-10-30 13:35 ` Paolo Bonzini [this message]
2024-10-30 15:24 ` Phil Dennis-Jordan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5eedaf78-78f5-40c1-a240-942b55a2450e@redhat.com \
--to=pbonzini@redhat.com \
--cc=lists@philjordan.eu \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).