2022-12-03 20:51:13 +03:00
|
|
|
/*
|
|
|
|
|
* Xen HVM emulation support in KVM
|
|
|
|
|
*
|
|
|
|
|
* Copyright © 2019 Oracle and/or its affiliates. All rights reserved.
|
|
|
|
|
* Copyright © 2022 Amazon.com, Inc. or its affiliates. All Rights Reserved.
|
|
|
|
|
*
|
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
|
* See the COPYING file in the top-level directory.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef QEMU_SYSEMU_KVM_XEN_H
|
|
|
|
|
#define QEMU_SYSEMU_KVM_XEN_H
|
|
|
|
|
|
2022-12-07 12:19:31 +03:00
|
|
|
/* The KVM API uses these to indicate "no GPA" or "no GFN" */
|
|
|
|
|
#define INVALID_GPA UINT64_MAX
|
|
|
|
|
#define INVALID_GFN UINT64_MAX
|
|
|
|
|
|
|
|
|
|
/* QEMU plays the rôle of dom0 for "interdomain" communication. */
|
|
|
|
|
#define DOMID_QEMU 0
|
|
|
|
|
|
2018-07-20 22:19:05 +03:00
|
|
|
int kvm_xen_soft_reset(void);
|
2022-12-03 20:51:13 +03:00
|
|
|
uint32_t kvm_xen_get_caps(void);
|
2022-12-16 17:32:25 +03:00
|
|
|
void *kvm_xen_get_vcpu_info_hva(uint32_t vcpu_id);
|
2023-10-12 02:06:26 +03:00
|
|
|
bool kvm_xen_has_vcpu_callback_vector(void);
|
2022-12-16 17:32:25 +03:00
|
|
|
void kvm_xen_inject_vcpu_callback_vector(uint32_t vcpu_id, int type);
|
hw/xen: Support HVM_PARAM_CALLBACK_TYPE_GSI callback
The GSI callback (and later PCI_INTX) is a level triggered interrupt. It
is asserted when an event channel is delivered to vCPU0, and is supposed
to be cleared when the vcpu_info->evtchn_upcall_pending field for vCPU0
is cleared again.
Thankfully, Xen does *not* assert the GSI if the guest sets its own
evtchn_upcall_pending field; we only need to assert the GSI when we
have delivered an event for ourselves. So that's the easy part, kind of.
There's a slight complexity in that we need to hold the BQL before we
can call qemu_set_irq(), and we definitely can't do that while holding
our own port_lock (because we'll need to take that from the qemu-side
functions that the PV backend drivers will call). So if we end up
wanting to set the IRQ in a context where we *don't* already hold the
BQL, defer to a BH.
However, we *do* need to poll for the evtchn_upcall_pending flag being
cleared. In an ideal world we would poll that when the EOI happens on
the PIC/IOAPIC. That's how it works in the kernel with the VFIO eventfd
pairs — one is used to trigger the interrupt, and the other works in the
other direction to 'resample' on EOI, and trigger the first eventfd
again if the line is still active.
However, QEMU doesn't seem to do that. Even VFIO level interrupts seem
to be supported by temporarily unmapping the device's BARs from the
guest when an interrupt happens, then trapping *all* MMIO to the device
and sending the 'resample' event on *every* MMIO access until the IRQ
is cleared! Maybe in future we'll plumb the 'resample' concept through
QEMU's irq framework but for now we'll do what Xen itself does: just
check the flag on every vmexit if the upcall GSI is known to be
asserted.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
2022-12-15 23:35:24 +03:00
|
|
|
void kvm_xen_set_callback_asserted(void);
|
2022-12-14 01:40:56 +03:00
|
|
|
int kvm_xen_set_vcpu_virq(uint32_t vcpu_id, uint16_t virq, uint16_t port);
|
2022-12-16 19:27:00 +03:00
|
|
|
uint16_t kvm_xen_get_gnttab_max_frames(void);
|
2023-01-18 17:36:23 +03:00
|
|
|
uint16_t kvm_xen_get_evtchn_max_pirq(void);
|
2022-12-03 20:51:13 +03:00
|
|
|
|
|
|
|
|
#define kvm_xen_has_cap(cap) (!!(kvm_xen_get_caps() & \
|
|
|
|
|
KVM_XEN_HVM_CONFIG_ ## cap))
|
|
|
|
|
|
2022-12-27 22:02:23 +03:00
|
|
|
#define XEN_SPECIAL_AREA_ADDR 0xfeff8000UL
|
|
|
|
|
#define XEN_SPECIAL_AREA_SIZE 0x4000UL
|
|
|
|
|
|
|
|
|
|
#define XEN_SPECIALPAGE_CONSOLE 0
|
|
|
|
|
#define XEN_SPECIALPAGE_XENSTORE 1
|
|
|
|
|
|
|
|
|
|
#define XEN_SPECIAL_PFN(x) ((XEN_SPECIAL_AREA_ADDR >> TARGET_PAGE_BITS) + \
|
|
|
|
|
XEN_SPECIALPAGE_##x)
|
|
|
|
|
|
2022-12-03 20:51:13 +03:00
|
|
|
#endif /* QEMU_SYSEMU_KVM_XEN_H */
|