summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/none/1899733
blob: 81515a8f01c55a55276b4dc32728f720862beab3 (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
graphic: 0.777
mistranslation: 0.761
user-level: 0.615
peripherals: 0.587
performance: 0.583
device: 0.537
architecture: 0.534
semantic: 0.494
permissions: 0.397
ppc: 0.316
kernel: 0.309
register: 0.300
PID: 0.295
virtual: 0.276
hypervisor: 0.274
socket: 0.264
risc-v: 0.250
debug: 0.241
vnc: 0.226
files: 0.223
network: 0.205
VMM: 0.192
arm: 0.183
boot: 0.177
assembly: 0.160
TCG: 0.145
i386: 0.100
x86: 0.090
KVM: 0.057

Qemu 5.1.0-1 GPU passthrough - MacOS vm starts only if hdmi is attached

Hi,
I have a macOS 10.15.7 vm with GPU passthrough (NVIDIA GTX Titan Black), libvirt xml has path to vbios too.
Qemu 5.1.0-1 with libvirt 6.5.0-2 are installed in manjaro architect 20.1.1 (two kernels tried: 5.4.67 LTS and 5.8.11 stable, no difference).
I have two monitors, one with hdmi and one with vga inputs.
Usually the gpu is connected to one monitor with hdmi, the other one with DVI (on gpu)-->vga adapter, so:
1st monitor: hdmi-->hdmi
2nd monitor: DVI-->vga adapter-->vga

With this setup, launching "virsh start Catalina" has no problem.

If I detach the hdmi cable from monitor 1, I cannot start qemu anymore: the 2nd monitor turns black, it doesn't seem it has "no-signal", but only a black screen with the power led blinking (usually a window on the monitor floats around with "no signal" displayed when there is no signal to monitor).
I say "qemu doesn't start" because in /var/log/libvirt/qemu/Catalina.log there's no trace.

Detaching hdmi works with qemu 4.2 and libvirt 5.10, so this could be related to qemu update.

Apologize, I know there aren't much information here, if someone can guide me to test the issue I would be grateful.

Thanks for your attention

Sorry, this is invalid, not related to qemu, the root of the issue is with OVMF_CODE.fd and OVMF_VARS.fd from v. 202005 or v. 202008 stable.