On 8/1/2024 6:25 PM, Igor Mammedov wrote:
On Thu, 1 Aug 2024 15:36:10 +0530
Manish <manish.mis...@nutanix.com> wrote:
On 31/07/24 9:01 pm, Xiaoyao Li wrote:
!-------------------------------------------------------------------|
CAUTION: External Email
|-------------------------------------------------------------------!
On 7/31/2024 4:49 PM, John Levon wrote:
On Wed, Jul 31, 2024 at 03:02:15PM +0800, Xiaoyao Li wrote:
Windows does not expect 0x1f to be present for any CPU model. But
if it
is exposed to the guest, it expects non-zero values.
Please fix Windows!
A ticket has been filed with MSFT, we are aware this is a guest bug.
But that doesn't really help anybody trying to use Windows right now.
For existing buggy Windows, we can still introduce
"cpuid-0x1f-enforce" but not make it default on.
People want to boot the buggy Windows needs to opt-in it themselves
via "-cpu xxx,cpuid-0x1f-enforce=on". This way, we don't have live
migration issue and it doesn't affect anything.
Yes, that makes sense, I will send a updated patch by tomorrow if no one
has any objection with this.
I'd rename it to
x-have-cpuid-0x1f-leaf
(x-) to reflect that it's not stable/maintained and subject
to be dropped in future
Also please clearly spell out that it's a temporary workaround for ...
in commit message.
I have a patch at hand, to introduce enable_cpuid_0x1f similar as
enable_cpuid_0xb, for TDX:
https://github.com/intel-staging/qemu-tdx/commit/de08fd30926bc9d7997af6bd12cfff1b998da8b7
It is not a temporary solution. So I would suggest to drop (x-).
If no objection, I think Manish can start from my patch and it only
misses a property definition for windows case:
DEFINE_PROP_BOOL("cpuid-0x1f", X86CPU, enable_cpuid_0x1f, false);
regards
john
Thanks
Manish Mishra
