blob: 66a1b795d6e0010349af08b1271d363ccad5ada5 (
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
|
kernel: 0.938
device: 0.834
virtual: 0.766
boot: 0.718
peripherals: 0.709
ppc: 0.657
semantic: 0.652
vnc: 0.623
socket: 0.586
graphic: 0.586
KVM: 0.574
PID: 0.537
network: 0.507
risc-v: 0.491
hypervisor: 0.446
performance: 0.440
architecture: 0.415
register: 0.343
arm: 0.339
x86: 0.332
i386: 0.322
mistranslation: 0.299
TCG: 0.290
files: 0.255
permissions: 0.254
debug: 0.244
VMM: 0.241
user-level: 0.181
assembly: 0.156
Resizable BAR (ReBAR) support on VFIO
Additional information:
Currently `vfio_add_ext_cap()` doesn't pass ReBAR support option to VFIO.
There was a report that removing the line you see below makes it boot, but the system is not stable.
Needs investigation.
[https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089](https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089)
``` switch (cap_id) {
case 0: /* kernel masked capability */
case PCI_EXT_CAP_ID_SRIOV: /* Read-only VF BARs confuse OVMF */
case PCI_EXT_CAP_ID_ARI: /* XXX Needs next function virtualization */
case PCI_EXT_CAP_ID_REBAR: /* Can't expose read-only */
trace_vfio_add_ext_cap_dropped(vdev->vbasedev.name, cap_id, next);
```
[Discussion link](https://forum.level1techs.com/t/smart-access-memory-vs-qemu-kvm/169447)
|