diff options
Diffstat (limited to 'results/classifier/deepseek-r1:14b/output/hypervisor/664')
| -rw-r--r-- | results/classifier/deepseek-r1:14b/output/hypervisor/664 | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/results/classifier/deepseek-r1:14b/output/hypervisor/664 b/results/classifier/deepseek-r1:14b/output/hypervisor/664 new file mode 100644 index 000000000..dcb67192d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/hypervisor/664 @@ -0,0 +1,15 @@ + +hvf-accelerated x86_64 incorrectly reports virtual address bit width via CPUID +Description of problem: +When running qemu-system-x86_64 with hvf acceleration enabled the maximum extended cpuid function (available via EAX=0x80000000) is reported to be 0x80000001, which means that physical address and virtual address bit width (which is supposed to be reported via EAX=0x80000008) is not available. As per the intel IA32/64 manual: `Processors that do not support CPUID function 80000008H, support a linear-address width of 32.`, while in actuality qemu-system-x86_64 with hvf acceleration supports virtual addresses of up to 48 bit in width, like most modern x86_64 processors. +Steps to reproduce: +This can be observed when running SerenityOS on x86_64 qemu with hvf acceleration based on the following dmesg lines: +``` +[Kernel]: CPU[0]: Physical address bit width: 36 +[Kernel]: CPU[0]: Virtual address bit width: 32 +``` +But can also be reproduced by running the CPUID instruction with EAX set to 0x80000000 and observing that the returned value is 0x80000001. +Additional information: +The best way to resolve this as far as I can tell is to expose the 0x80000008 CPUID function and report the real values. + +NOTE: This is a report of the underlying bug that was found during the investigation of an issue raised in the SerenityOS repository, see https://github.com/SerenityOS/serenity/issues/10382 for more information. |