summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/none/714629
blob: f98c0ecaa11540bbd2984c5394449de16947c003 (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
device: 0.755
network: 0.747
virtual: 0.717
register: 0.665
risc-v: 0.658
kernel: 0.642
vnc: 0.635
socket: 0.629
architecture: 0.626
mistranslation: 0.619
semantic: 0.591
debug: 0.589
files: 0.573
VMM: 0.546
ppc: 0.539
performance: 0.515
boot: 0.505
PID: 0.500
i386: 0.437
permissions: 0.429
arm: 0.418
peripherals: 0.386
graphic: 0.379
TCG: 0.378
x86: 0.328
assembly: 0.307
hypervisor: 0.283
KVM: 0.253
user-level: 0.228

BIOS doesn't load when read() returns less than the full ROM length

When qemu is running over a 9p filesystem (e.g. when running underneath -virtfs of another qemu), and probably some other network filesystems, it fails to read its BIOS image.  This is because it uses a single low-level read() call on the bios.bin, asking for the full file.  However read() may return less than the full length, and it's the caller's responsibility to call it repeatedly if necessary.  When read does come up short, qemu doesn't repeat the call, and reports an error instead.  The attached patch fixes the one problem I saw, but I haven't tried to cover the general case (e.g. extension ROMs).



This seems to have been fixed by commit 1f40547f5ce0c135faa7d14f066b97002fd8c204.

Fix included in QEMU v4.0.0.