blob: 337d0d63d0ee313d2797969cf82657ddbe773ec2 (
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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
x86: 0.847
device: 0.815
files: 0.783
mistranslation: 0.679
ppc: 0.676
graphic: 0.669
architecture: 0.648
semantic: 0.592
network: 0.583
PID: 0.566
performance: 0.558
TCG: 0.529
socket: 0.523
permissions: 0.517
vnc: 0.503
VMM: 0.487
debug: 0.486
risc-v: 0.466
register: 0.436
hypervisor: 0.432
kernel: 0.403
boot: 0.377
arm: 0.348
virtual: 0.341
user-level: 0.301
peripherals: 0.287
KVM: 0.195
assembly: 0.160
i386: 0.113
do_guest_openat /proc interposition doesn't work for openat
Description of problem:
For instance, trying with hppa emulated on top of x86:
```
$ hppa-linux-gnu-gcc test.c -o test
$ qemu-hppa-static ./test
```
One gets the host cpu information:
```
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
[...]
```
while we would want to see the guest cpu information, like the test program does when `#if 0` is turned into `#if 1`:
```
processor : 0
cpu family : PA-RISC 1.1e
cpu : PA7300LC (PCX-L2)
capabilities : os32
model : 9000/778/B160L - Merlin L2 160 QEMU (9000/778/B160L)
```
This is because `do_guest_openat` only checks for the path, and does not look at `dirfd`, so it doesn't recognize that `openat(dirfd, "cpuinfo", O_RDONLY)` is actually opening a file in `/proc`.
We could probably, when `dirfd` is not `AT_FDCWD`, try to `fstat()` it, open `/proc` with `O_DIRECTORY` and `fstat()` that too, and compare their `st_dev` and `st_ino`?
|