Re: [Question] Can I start qemu-system-aarch64 with a vmlinux(ELF format)?
Hi Peter， On 2024/2/29 17:44, Peter Maydell wrote: On Thu, 29 Feb 2024 at 03:01, Kunkun Jiang wrote: Hi Peter, On 2024/2/27 23:28, Peter Maydell wrote: On Tue, 27 Feb 2024 at 14:42, Kunkun Jiang via wrote: Hi everybody, I want to start qemu-system-aarch64 with a vmlinux, which is an ELF format file. The arm_load_elf() is implemented in arm_setup_direct_kernel_boot(). So I thought it was supporting the ELF format file. No, you can't do this. The hw/arm/boot.c code assumes that ELF files are "bare metal" binaries, whereas uImage format, AArch64 Image format, and raw binary files are Linux kernels. Only the last three kinds of files will be started with the boot protocol the Linux kernel expects. For AArch64, pass the -kernel option the path to the Image file, not the vmlinux file. Yes, it works fine using Image files. I would also like to ask again, is it because AArch64 does not support vmlinux, or is it because qemu does not implement this capability? As I said, it is because QEMU assumes that ELF files are bare metal images, not Linux kernel images. Sorry to bother you again. I still have a few questions. 1. What does "bare metal images" mean? Are they used in tcg mode? 2. How QEMU assumes an ELF file is a bare metal image? Can you post the corresponding code? 3. How can I make the hw/arm/boot.c code assumes the ELF files are Linux kernels? Looking forward to your reply. Thanks, Kunkun Jiang
Re: [Question] Can I start qemu-system-aarch64 with a vmlinux(ELF format)?
Hi Peter, On 2024/2/27 23:28, Peter Maydell wrote: On Tue, 27 Feb 2024 at 14:42, Kunkun Jiang via wrote: Hi everybody, I want to start qemu-system-aarch64 with a vmlinux, which is an ELF format file. The arm_load_elf() is implemented in arm_setup_direct_kernel_boot(). So I thought it was supporting the ELF format file. No, you can't do this. The hw/arm/boot.c code assumes that ELF files are "bare metal" binaries, whereas uImage format, AArch64 Image format, and raw binary files are Linux kernels. Only the last three kinds of files will be started with the boot protocol the Linux kernel expects. For AArch64, pass the -kernel option the path to the Image file, not the vmlinux file. Yes, it works fine using Image files. I would also like to ask again, is it because AArch64 does not support vmlinux, or is it because qemu does not implement this capability? Thanks, Kunkun Jiang
[Question] Can I start qemu-system-aarch64 with a vmlinux(ELF format)?
Hi everybody, I want to start qemu-system-aarch64 with a vmlinux, which is an ELF format file. The arm_load_elf() is implemented in arm_setup_direct_kernel_boot(). So I thought it was supporting the ELF format file. But there's no output. Here is my command line: qemu-system-aarch64 -machine virt,gic-version=3 -enable-kvm -smp 4 -m 1G -cpu host -kernel vmlinux -initrd fs -append "xxx" Am I using it the wrong way? Looking forward to your reply. Thanks, Kunkun Jiang
Re: [PATCH V9 32/46] vfio-pci: cpr part 2 (msi)
Hi Steve,
On 2023/7/10 23:43, Steven Sistare wrote:
On 7/5/2023 4:56 AM, Kunkun Jiang wrote:
Hi Steve,
I have a few questions about the msi part of the vfio device.
In the reboot mode, you mentioned "The guest drivers' suspend methods
flush outstanding requests and re-initialize the devices". This means,
during the downtime,the vfio device dose not generate interrupts. So
no special processing is required for the msi interrupt of the vfio
device. Am I right?
Correct.
In the cpr-exec mode, will the vfio device be "stopped"? If the vfio device
is running all the time,it is possible to generate interrrupts during the
downtime. How to deal with these interrupts?
The vfio device is not stopped, but its connection to the kvm instance is
severed.
Interrupts are pended in the vfio kernel state, and that state is preserved
across
exec, by preserving the vfio descriptors. After exec, qemu creates a new kvm
instance,
attaches vfio to it, and the interrupts are delivered.
In addition, ARM GICv4 provides support for the direct injection of vLPIs.
Interrupts are more difficult to handle. In this case, what should be done?
I have not studied this feature or tried it.
Have you analyzed the VT-D post-interrupt feature? It is similar to the
direct
injection of vLPI. They all implement the interrupt injecting channel by
executing
irq_bypass_register_consumer.
According to the current kernel code, it need to first cancel the
connection between
vfio producer and kvm consumer, then establishes the connection between
vfio producer
and the new kvm consumer. During the unbinding process, both ARM and x86
will execute
the callback of *_set_vcpu_affinity to modify the interrupt reporting
channel. For x86,
in the process of stop posting interrupts, back to remapping mode,
cmpxchg_double is
used in the code. Does this guarantee that interrupts will not be lost?
For ARM, it will first send a DISCARD command to ITS and then establish
the interrupt
reporting channel for GICv3. The DISCARD will remove the pending
interrupt. Interrupts
that come before channel re-establishment are silently discarded.
Do you guys have any good ideas?
Look forward to your reply.
Kunkun Jiang
- Steve
Look forward to your reply.
Kunkun Jiang
On 2022/7/27 0:10, Steve Sistare wrote:
Finish cpr for vfio-pci MSI/MSI-X devices by preserving eventfd's and
vector state.
Signed-off-by: Steve Sistare
---
hw/vfio/pci.c | 119
+-
1 file changed, 118 insertions(+), 1 deletion(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index b5fd2ec..1d0e8db 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -54,17 +54,47 @@ static void vfio_disable_interrupts(VFIOPCIDevice *vdev);
static void vfio_mmap_set_enabled(VFIOPCIDevice *vdev, bool enabled);
static void vfio_msi_disable_common(VFIOPCIDevice *vdev);
+#define EVENT_FD_NAME(vdev, name) \
+ g_strdup_printf("%s_%s", (vdev)->vbasedev.name, (name))
+
+static void save_event_fd(VFIOPCIDevice *vdev, const char *name, int nr,
+ EventNotifier *ev)
+{
+ int fd = event_notifier_get_fd(ev);
+
+ if (fd >= 0) {
+ g_autofree char *fdname = EVENT_FD_NAME(vdev, name);
+
+ cpr_resave_fd(fdname, nr, fd);
+ }
+}
+
+static int load_event_fd(VFIOPCIDevice *vdev, const char *name, int nr)
+{
+ g_autofree char *fdname = EVENT_FD_NAME(vdev, name);
+ return cpr_find_fd(fdname, nr);
+}
+
+static void delete_event_fd(VFIOPCIDevice *vdev, const char *name, int nr)
+{
+ g_autofree char *fdname = EVENT_FD_NAME(vdev, name);
+ cpr_delete_fd(fdname, nr);
+}
+
/* Create new or reuse existing eventfd */
static int vfio_notifier_init(VFIOPCIDevice *vdev, EventNotifier *e,
const char *name, int nr)
{
- int fd = -1; /* placeholder until a subsequent patch */
int ret = 0;
+ int fd = load_event_fd(vdev, name, nr);
if (fd >= 0) {
event_notifier_init_fd(e, fd);
} else {
ret = event_notifier_init(e, 0);
+ if (!ret) {
+ save_event_fd(vdev, name, nr, e);
+ }
}
return ret;
}
@@ -72,6 +102,7 @@ static int vfio_notifier_init(VFIOPCIDevice *vdev,
EventNotifier *e,
static void vfio_notifier_cleanup(VFIOPCIDevice *vdev, EventNotifier *e,
const char *name, int nr)
{
+ delete_event_fd(vdev, name, nr);
event_notifier_cleanup(e);
}
@@ -512,6 +543,15 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev,
unsigned int nr,
VFIOMSIVector *vector;
int ret;
+ /*
+ * Ignore the callback from msix_set_vector_notifiers during resume.
+ * The necessary subset of these actions is called from vfio_claim_vectors
+ * during post load.
+ */
+ if (vdev->vbasedev.reused) {
+ return 0;
+ }
+
trace_vfio_msix_vector_do_use(vdev->vbasedev.name, nr);
vector =
Re: [PATCH V9 32/46] vfio-pci: cpr part 2 (msi)
Hi Steve,
I have a few questions about the msi part of the vfio device.
In the reboot mode, you mentioned "The guest drivers' suspend methods
flush outstanding requests and re-initialize the devices". This means,
during the downtime,the vfio device dose not generate interrupts. So
no special processing is required for the msi interrupt of the vfio
device. Am I right?
In the cpr-exec mode, will the vfio device be "stopped"? If the vfio device
is running all the time,it is possible to generate interrrupts during the
downtime. How to deal with these interrupts?
In addition, ARM GICv4 provides support for the direct injection of vLPIs.
Interrupts are more difficult to handle. In this case, what should be done?
Look forward to your reply.
Kunkun Jiang
On 2022/7/27 0:10, Steve Sistare wrote:
Finish cpr for vfio-pci MSI/MSI-X devices by preserving eventfd's and
vector state.
Signed-off-by: Steve Sistare
---
hw/vfio/pci.c | 119 +-
1 file changed, 118 insertions(+), 1 deletion(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index b5fd2ec..1d0e8db 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -54,17 +54,47 @@ static void vfio_disable_interrupts(VFIOPCIDevice *vdev);
static void vfio_mmap_set_enabled(VFIOPCIDevice *vdev, bool enabled);
static void vfio_msi_disable_common(VFIOPCIDevice *vdev);
+#define EVENT_FD_NAME(vdev, name) \
+g_strdup_printf("%s_%s", (vdev)->vbasedev.name, (name))
+
+static void save_event_fd(VFIOPCIDevice *vdev, const char *name, int nr,
+ EventNotifier *ev)
+{
+int fd = event_notifier_get_fd(ev);
+
+if (fd >= 0) {
+g_autofree char *fdname = EVENT_FD_NAME(vdev, name);
+
+cpr_resave_fd(fdname, nr, fd);
+}
+}
+
+static int load_event_fd(VFIOPCIDevice *vdev, const char *name, int nr)
+{
+g_autofree char *fdname = EVENT_FD_NAME(vdev, name);
+return cpr_find_fd(fdname, nr);
+}
+
+static void delete_event_fd(VFIOPCIDevice *vdev, const char *name, int nr)
+{
+g_autofree char *fdname = EVENT_FD_NAME(vdev, name);
+cpr_delete_fd(fdname, nr);
+}
+
/* Create new or reuse existing eventfd */
static int vfio_notifier_init(VFIOPCIDevice *vdev, EventNotifier *e,
const char *name, int nr)
{
-int fd = -1; /* placeholder until a subsequent patch */
int ret = 0;
+int fd = load_event_fd(vdev, name, nr);
if (fd >= 0) {
event_notifier_init_fd(e, fd);
} else {
ret = event_notifier_init(e, 0);
+if (!ret) {
+save_event_fd(vdev, name, nr, e);
+}
}
return ret;
}
@@ -72,6 +102,7 @@ static int vfio_notifier_init(VFIOPCIDevice *vdev,
EventNotifier *e,
static void vfio_notifier_cleanup(VFIOPCIDevice *vdev, EventNotifier *e,
const char *name, int nr)
{
+delete_event_fd(vdev, name, nr);
event_notifier_cleanup(e);
}
@@ -512,6 +543,15 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
VFIOMSIVector *vector;
int ret;
+/*
+ * Ignore the callback from msix_set_vector_notifiers during resume.
+ * The necessary subset of these actions is called from vfio_claim_vectors
+ * during post load.
+ */
+if (vdev->vbasedev.reused) {
+return 0;
+}
+
trace_vfio_msix_vector_do_use(vdev->vbasedev.name, nr);
vector = >msi_vectors[nr];
@@ -2784,6 +2824,11 @@ static void vfio_register_err_notifier(VFIOPCIDevice
*vdev)
fd = event_notifier_get_fd(>err_notifier);
qemu_set_fd_handler(fd, vfio_err_notifier_handler, NULL, vdev);
+/* Do not alter irq_signaling during vfio_realize for cpr */
+if (vdev->vbasedev.reused) {
+return;
+}
+
if (vfio_set_irq_signaling(>vbasedev, VFIO_PCI_ERR_IRQ_INDEX, 0,
VFIO_IRQ_SET_ACTION_TRIGGER, fd, )) {
error_reportf_err(err, VFIO_MSG_PREFIX, vdev->vbasedev.name);
@@ -2849,6 +2894,12 @@ static void vfio_register_req_notifier(VFIOPCIDevice
*vdev)
fd = event_notifier_get_fd(>req_notifier);
qemu_set_fd_handler(fd, vfio_req_notifier_handler, NULL, vdev);
+/* Do not alter irq_signaling during vfio_realize for cpr */
+if (vdev->vbasedev.reused) {
+vdev->req_enabled = true;
+return;
+}
+
if (vfio_set_irq_signaling(>vbasedev, VFIO_PCI_REQ_IRQ_INDEX, 0,
VFIO_IRQ_SET_ACTION_TRIGGER, fd, )) {
error_reportf_err(err, VFIO_MSG_PREFIX, vdev->vbasedev.name);
@@ -3357,6 +3408,46 @@ static Property vfio_pci_dev_properties[] = {
DEFINE_PROP_END_OF_LIST(),
};
+static void vfio_claim_vectors(VFIOPCIDevice *vdev, int nr_vectors, bool msix)
+{
+int i, fd;
+bool pending = false;
+PCIDevice *pdev = >pdev;
+
+vdev->nr_vectors = nr_vectors;
+vdev->msi_vectors = g_new0(VFIOMSIVector, nr_vectors);
+vdev->interrupt = msix
[PATCH] qmp: Add error proofing for query-acpi-ospm-status
The ACPI device may not implement the ospm_status callback. Executing
qmp "query-acpi-ospm-status" will cause segmentation fault. Add error
proofing add log to avoid such serious consequences.
Signed-off-by: Kunkun Jiang
---
monitor/qmp-cmds.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/monitor/qmp-cmds.c b/monitor/qmp-cmds.c
index bf22a8c5a6..7652613635 100644
--- a/monitor/qmp-cmds.c
+++ b/monitor/qmp-cmds.c
@@ -229,7 +229,12 @@ ACPIOSTInfoList *qmp_query_acpi_ospm_status(Error **errp)
AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_GET_CLASS(obj);
AcpiDeviceIf *adev = ACPI_DEVICE_IF(obj);
-adevc->ospm_status(adev, );
+if (adevc->ospm_status) {
+adevc->ospm_status(adev, );
+} else {
+error_setg(errp, "command is not supported, "
+ "ACPI device missing ospm_status callback");
+}
} else {
error_setg(errp, "command is not supported, missing ACPI device");
}
--
2.33.0
[PATCH] vfio/migration: Fix incorrect initialization value for parameters in VFIOMigration
The structure VFIOMigration of a VFIODevice is allocated and initialized in vfio_migration_init(). "device_state" and "vm_running" are initialized to 0, indicating that VFIO device is_STOP and VM is not-running. The initialization value is incorrect. According to the agreement, default state of VFIO device is _RUNNING. And if a VFIO device is hot-plugged while the VM is running, "vm_running" should be 1. This patch fixes it. Fixes: 02a7e71b1e5 (vfio: Add VM state change handler to know state of VM) Signed-off-by: Kunkun Jiang --- hw/vfio/migration.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c index a6ad1f8945..3de4252111 100644 --- a/hw/vfio/migration.c +++ b/hw/vfio/migration.c @@ -806,6 +806,8 @@ static int vfio_migration_init(VFIODevice *vbasedev, } vbasedev->migration = g_new0(VFIOMigration, 1); +vbasedev->migration->device_state = VFIO_DEVICE_STATE_RUNNING; +vbasedev->migration->vm_running = runstate_is_running(); ret = vfio_region_setup(obj, vbasedev, >migration->region, info->index, "migration"); -- 2.27.0
