aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorDavid Woodhouse <dwmw@amazon.co.uk>2022-12-16 00:03:21 +0000
committerDavid Woodhouse <dwmw@amazon.co.uk>2023-03-01 09:07:50 +0000
commit2aff696b10d16ef09dc5a2c953ceccbf6d38f744 (patch)
tree2d200966bddd1452fd91438db24ca1cee2fb289d /include
parentddf0fd9ae1fd1ff95489763b37a483adb3cd5907 (diff)
downloadqemu-2aff696b10d16ef09dc5a2c953ceccbf6d38f744.zip
qemu-2aff696b10d16ef09dc5a2c953ceccbf6d38f744.tar.gz
qemu-2aff696b10d16ef09dc5a2c953ceccbf6d38f744.tar.bz2
hw/xen: Support HVM_PARAM_CALLBACK_TYPE_PCI_INTX callback
The guest is permitted to specify an arbitrary domain/bus/device/function and INTX pin from which the callback IRQ shall appear to have come. In QEMU we can only easily do this for devices that actually exist, and even that requires us "knowing" that it's a PCMachine in order to find the PCI root bus — although that's OK really because it's always true. We also don't get to get notified of INTX routing changes, because we can't do that as a passive observer; if we try to register a notifier it will overwrite any existing notifier callback on the device. But in practice, guests using PCI_INTX will only ever use pin A on the Xen platform device, and won't swizzle the INTX routing after they set it up. So this is just fine. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions