blob: 00295498e33333a92465ec2d5431f5d1bda37d5f (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
kernel: 0.917
x86: 0.916
architecture: 0.851
device: 0.790
graphic: 0.737
performance: 0.731
mistranslation: 0.722
vnc: 0.678
socket: 0.655
network: 0.641
ppc: 0.636
PID: 0.583
semantic: 0.561
peripherals: 0.560
boot: 0.533
VMM: 0.531
register: 0.516
files: 0.507
hypervisor: 0.506
KVM: 0.489
permissions: 0.486
virtual: 0.465
i386: 0.465
risc-v: 0.463
debug: 0.424
arm: 0.410
TCG: 0.385
user-level: 0.321
assembly: 0.277
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.
|