* [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
@ 2020-03-10 16:53 Liran Alon
2020-03-10 16:53 ` [PATCH v2 01/16] hw/i386/vmport: Add device properties Liran Alon
` (17 more replies)
0 siblings, 18 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: nikita.leshchenko, mst, ehabkost, rth
Hi,
This series aims to fix several bugs in VMPort and improve it by supporting
more VMPort commands and make command results more configurable to
user via QEMU command-line.
This functionality was proven to be useful to run various VMware VMs
when attempting to run them as-is on top of QEMU/KVM.
For more details, see commit messages.
Regards,
-Liran
v1->v2:
* Fix coding convention [Patchew Bot & MST].
* Create new header file for vmport.h [MST].
* Move KVM_APIC_BUS_FREQUENCY from linux-headers/asm-x86/kvm.h
auto-generated header [MST]
* Elaborate more that vmx-version refers to the VMware userspace
VMM in commit message. [MST]
* Use le32_to_cpu() on BIOS_UUID vmport command. [MST]
* Introduce VMPort compatability version property to maintain migration
compatibility. [MST]
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 01/16] hw/i386/vmport: Add device properties
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 02/16] hw/i386/vmport: Add compatability version field Liran Alon
` (16 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
No functional change.
This is done as a preparation for the following patches that will
introduce several device properties.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 1f31e27c8aa4..8d7513e2a23c 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -25,6 +25,7 @@
#include "hw/isa/isa.h"
#include "hw/i386/pc.h"
#include "hw/input/i8042.h"
+#include "hw/qdev-properties.h"
#include "sysemu/hw_accel.h"
#include "qemu/log.h"
#include "trace.h"
@@ -154,6 +155,10 @@ static void vmport_realizefn(DeviceState *dev, Error **errp)
vmport_register(VMPORT_CMD_GETRAMSIZE, vmport_cmd_ram_size, NULL);
}
+static Property vmport_properties[] = {
+ DEFINE_PROP_END_OF_LIST(),
+};
+
static void vmport_class_initfn(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
@@ -161,6 +166,7 @@ static void vmport_class_initfn(ObjectClass *klass, void *data)
dc->realize = vmport_realizefn;
/* Reason: realize sets global port_state */
dc->user_creatable = false;
+ device_class_set_props(dc, vmport_properties);
}
static const TypeInfo vmport_info = {
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 02/16] hw/i386/vmport: Add compatability version field
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
2020-03-10 16:53 ` [PATCH v2 01/16] hw/i386/vmport: Add device properties Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 03/16] hw/i386/vmport: Propagate IOPort read to vCPU EAX register Liran Alon
` (15 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
No functional change.
This is done as a preparation for the following patches which will change
guest-visible behavior. Adding this version field will allow us to
maintain migration compatability from new QEMU version to old QEMU
version (Given machine-type is the compatabile).
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 8d7513e2a23c..ca4d95fc017f 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -44,6 +44,8 @@ typedef struct VMPortState {
MemoryRegion io;
VMPortReadFunc *func[VMPORT_ENTRIES];
void *opaque[VMPORT_ENTRIES];
+
+ uint8_t version;
} VMPortState;
static VMPortState *port_state;
@@ -156,6 +158,12 @@ static void vmport_realizefn(DeviceState *dev, Error **errp)
}
static Property vmport_properties[] = {
+ /*
+ * Used to enforce compatibility for migration.
+ * On every guest-visible change, should make changes conditioned on
+ * version and define proper version for previous machine-types.
+ */
+ DEFINE_PROP_UINT8("version", VMPortState, version, 1),
DEFINE_PROP_END_OF_LIST(),
};
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 03/16] hw/i386/vmport: Propagate IOPort read to vCPU EAX register
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
2020-03-10 16:53 ` [PATCH v2 01/16] hw/i386/vmport: Add device properties Liran Alon
2020-03-10 16:53 ` [PATCH v2 02/16] hw/i386/vmport: Add compatability version field Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 04/16] hw/i386/vmport: Set EAX to -1 on failed and unsupported commands Liran Alon
` (14 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
vmport_ioport_read() returns the value that should propagate to vCPU EAX
register when guest reads VMPort IOPort (i.e. By x86 IN instruction).
However, because vmport_ioport_read() calls cpu_synchronize_state(), the
returned value gets overridden by the value in QEMU vCPU EAX register.
i.e. cpu->env.regs[R_EAX].
To fix this issue, change vmport_ioport_read() to explicitly override
cpu->env.regs[R_EAX] with the value it wish to propagate to vCPU EAX
register.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/core/machine.c | 1 +
hw/i386/vmport.c | 24 ++++++++++++++++++++----
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 9e8c06036faf..b9da40460d52 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -39,6 +39,7 @@ GlobalProperty hw_compat_4_2[] = {
{ "usb-redir", "suppress-remote-wake", "off" },
{ "qxl", "revision", "4" },
{ "qxl-vga", "revision", "4" },
+ { "vmport", "version", "1" },
};
const size_t hw_compat_4_2_len = G_N_ELEMENTS(hw_compat_4_2);
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index ca4d95fc017f..736d78263889 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -75,17 +75,33 @@ static uint64_t vmport_ioport_read(void *opaque, hwaddr addr,
eax = env->regs[R_EAX];
if (eax != VMPORT_MAGIC) {
- return eax;
+ goto out;
}
command = env->regs[R_ECX];
trace_vmport_command(command);
if (command >= VMPORT_ENTRIES || !s->func[command]) {
qemu_log_mask(LOG_UNIMP, "vmport: unknown command %x\n", command);
- return eax;
+ goto out;
}
- return s->func[command](s->opaque[command], addr);
+ eax = s->func[command](s->opaque[command], addr);
+
+out:
+ /*
+ * The call above to cpu_synchronize_state() gets vCPU registers values
+ * to QEMU but also cause QEMU to write QEMU vCPU registers values to
+ * vCPU implementation (e.g. Accelerator such as KVM) just before
+ * resuming guest.
+ *
+ * Therefore, in order to make IOPort return value propagate to
+ * guest EAX, we need to explicitly update QEMU EAX register value.
+ */
+ if (s->version > 1) {
+ cpu->env.regs[R_EAX] = eax;
+ }
+
+ return eax;
}
static void vmport_ioport_write(void *opaque, hwaddr addr,
@@ -163,7 +179,7 @@ static Property vmport_properties[] = {
* On every guest-visible change, should make changes conditioned on
* version and define proper version for previous machine-types.
*/
- DEFINE_PROP_UINT8("version", VMPortState, version, 1),
+ DEFINE_PROP_UINT8("version", VMPortState, version, 2),
DEFINE_PROP_END_OF_LIST(),
};
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 04/16] hw/i386/vmport: Set EAX to -1 on failed and unsupported commands
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (2 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 03/16] hw/i386/vmport: Propagate IOPort read to vCPU EAX register Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 05/16] hw/i386/vmport: Introduce vmx-version property Liran Alon
` (13 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
This is used as a signal for VMware Tools to know if a command it
attempted to invoke, failed or is unsupported. As a result, VMware Tools
will either report failure to user or fallback to another backdoor command
in attempt to perform some operation.
A few examples:
* open-vm-tools TimeSyncReadHost() function fallbacks to
CMD_GETTIMEFULL command when CMD_GETTIMEFULL_WITH_LAG
fails/unsupported.
* open-vm-tools Hostinfo_NestingSupported() function verifies
EAX != -1 to check for success.
* open-vm-tools Hostinfo_VCPUInfoBackdoor() functions checks
if reserved-bit is set to indicate command is unimplemented.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 736d78263889..8115852720c8 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -75,17 +75,23 @@ static uint64_t vmport_ioport_read(void *opaque, hwaddr addr,
eax = env->regs[R_EAX];
if (eax != VMPORT_MAGIC) {
- goto out;
+ goto err;
}
command = env->regs[R_ECX];
trace_vmport_command(command);
if (command >= VMPORT_ENTRIES || !s->func[command]) {
qemu_log_mask(LOG_UNIMP, "vmport: unknown command %x\n", command);
- goto out;
+ goto err;
}
eax = s->func[command](s->opaque[command], addr);
+ goto out;
+
+err:
+ if (s->version > 1) {
+ eax = UINT32_MAX;
+ }
out:
/*
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 05/16] hw/i386/vmport: Introduce vmx-version property
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (3 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 04/16] hw/i386/vmport: Set EAX to -1 on failed and unsupported commands Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 06/16] hw/i386/vmport: Report VMX type in CMD_GETVERSION Liran Alon
` (12 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
In VMware terminology, VMX is the name of VMware VMM. Short for Virtual
Machine eXecutable. (Do not confuse with Intel VT-x which is also often
named VMX).
vmx-version is a number returned from CMD_GETVERSION which specifies to
guest VMware Tools the the host VMX version. If the host reports a number
that is different than what the guest VMware Tools expects, it may force
guest to upgrade VMware Tools. (See comment above VERSION_MAGIC and
VmCheck_IsVirtualWorld() function in open-vm-tools open-source code).
For better readability and allow maintaining compatability for guests
which may expect different vmx-version, make vmx-version a VMPort object
property. This would allow user to control it's value via
"-global vmport.vmx-version=X".
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 8115852720c8..0d3f19b0bb71 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -45,6 +45,8 @@ typedef struct VMPortState {
VMPortReadFunc *func[VMPORT_ENTRIES];
void *opaque[VMPORT_ENTRIES];
+ uint32_t vmx_version;
+
uint8_t version;
} VMPortState;
@@ -123,7 +125,7 @@ static uint32_t vmport_cmd_get_version(void *opaque, uint32_t addr)
X86CPU *cpu = X86_CPU(current_cpu);
cpu->env.regs[R_EBX] = VMPORT_MAGIC;
- return 6;
+ return port_state->vmx_version;
}
static uint32_t vmport_cmd_ram_size(void *opaque, uint32_t addr)
@@ -186,6 +188,10 @@ static Property vmport_properties[] = {
* version and define proper version for previous machine-types.
*/
DEFINE_PROP_UINT8("version", VMPortState, version, 2),
+
+ /* Default value taken from open-vm-tools code VERSION_MAGIC definition */
+ DEFINE_PROP_UINT32("vmx-version", VMPortState, vmx_version, 6),
+
DEFINE_PROP_END_OF_LIST(),
};
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 06/16] hw/i386/vmport: Report VMX type in CMD_GETVERSION
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (4 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 05/16] hw/i386/vmport: Introduce vmx-version property Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 07/16] hw/i386/vmport: Introduce vmport.h Liran Alon
` (11 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
As can be seen from VmCheck_GetVersion() in open-vm-tools code,
CMD_GETVERSION should return VMX type in ECX register.
Default is to fake host as VMware ESX server. But user can control
this value by "-global vmport.vmx-type=X".
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 0d3f19b0bb71..973f3f6448e9 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -36,6 +36,16 @@
#define VMPORT_ENTRIES 0x2c
#define VMPORT_MAGIC 0x564D5868
+/* Enum taken from open-vm-tools lib/include/vm_vmx_type.h */
+typedef enum {
+ VMX_TYPE_UNSET = 0,
+ VMX_TYPE_EXPRESS, /* Deprecated type used for VMware Express */
+ VMX_TYPE_SCALABLE_SERVER, /* VMware ESX server */
+ VMX_TYPE_WGS, /* Deprecated type used for VMware Server */
+ VMX_TYPE_WORKSTATION,
+ VMX_TYPE_WORKSTATION_ENTERPRISE /* Deprecated type used for ACE 1.x */
+} VMXType;
+
#define VMPORT(obj) OBJECT_CHECK(VMPortState, (obj), TYPE_VMPORT)
typedef struct VMPortState {
@@ -46,6 +56,7 @@ typedef struct VMPortState {
void *opaque[VMPORT_ENTRIES];
uint32_t vmx_version;
+ uint8_t vmx_type;
uint8_t version;
} VMPortState;
@@ -125,6 +136,9 @@ static uint32_t vmport_cmd_get_version(void *opaque, uint32_t addr)
X86CPU *cpu = X86_CPU(current_cpu);
cpu->env.regs[R_EBX] = VMPORT_MAGIC;
+ if (port_state->version > 1) {
+ cpu->env.regs[R_ECX] = port_state->vmx_type;
+ }
return port_state->vmx_version;
}
@@ -191,6 +205,8 @@ static Property vmport_properties[] = {
/* Default value taken from open-vm-tools code VERSION_MAGIC definition */
DEFINE_PROP_UINT32("vmx-version", VMPortState, vmx_version, 6),
+ DEFINE_PROP_UINT8("vmx-type", VMPortState, vmx_type,
+ VMX_TYPE_SCALABLE_SERVER),
DEFINE_PROP_END_OF_LIST(),
};
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 07/16] hw/i386/vmport: Introduce vmport.h
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (5 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 06/16] hw/i386/vmport: Report VMX type in CMD_GETVERSION Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 08/16] hw/i386/vmport: Define enum for all commands Liran Alon
` (10 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
No functional change. This is mere refactoring.
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/pc.c | 1 +
hw/i386/vmmouse.c | 1 +
hw/i386/vmport.c | 1 +
include/hw/i386/pc.h | 13 -------------
include/hw/i386/vmport.h | 16 ++++++++++++++++
5 files changed, 19 insertions(+), 13 deletions(-)
create mode 100644 include/hw/i386/vmport.h
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 6ab4acb0c62e..6ac71e1af32b 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -31,6 +31,7 @@
#include "hw/i386/apic.h"
#include "hw/i386/topology.h"
#include "hw/i386/fw_cfg.h"
+#include "hw/i386/vmport.h"
#include "sysemu/cpus.h"
#include "hw/block/fdc.h"
#include "hw/ide.h"
diff --git a/hw/i386/vmmouse.c b/hw/i386/vmmouse.c
index e8e62bd96b8c..49a546fd3bb6 100644
--- a/hw/i386/vmmouse.c
+++ b/hw/i386/vmmouse.c
@@ -26,6 +26,7 @@
#include "qapi/error.h"
#include "ui/console.h"
#include "hw/i386/pc.h"
+#include "hw/i386/vmport.h"
#include "hw/input/i8042.h"
#include "hw/qdev-properties.h"
#include "migration/vmstate.h"
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 973f3f6448e9..7723d37a0657 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -24,6 +24,7 @@
#include "qemu/osdep.h"
#include "hw/isa/isa.h"
#include "hw/i386/pc.h"
+#include "hw/i386/vmport.h"
#include "hw/input/i8042.h"
#include "hw/qdev-properties.h"
#include "sysemu/hw_accel.h"
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index d5ac76d54e1f..60c988c4a5aa 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -134,19 +134,6 @@ typedef struct PCMachineClass {
GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
-/* vmport.c */
-#define TYPE_VMPORT "vmport"
-typedef uint32_t (VMPortReadFunc)(void *opaque, uint32_t address);
-
-static inline void vmport_init(ISABus *bus)
-{
- isa_create_simple(bus, TYPE_VMPORT);
-}
-
-void vmport_register(unsigned char command, VMPortReadFunc *func, void *opaque);
-void vmmouse_get_data(uint32_t *data);
-void vmmouse_set_data(const uint32_t *data);
-
/* pc.c */
extern int fd_bootchk;
diff --git a/include/hw/i386/vmport.h b/include/hw/i386/vmport.h
new file mode 100644
index 000000000000..f0c1e985ca08
--- /dev/null
+++ b/include/hw/i386/vmport.h
@@ -0,0 +1,16 @@
+#ifndef HW_VMPORT_H
+#define HW_VMPORT_H
+
+#define TYPE_VMPORT "vmport"
+typedef uint32_t (VMPortReadFunc)(void *opaque, uint32_t address);
+
+static inline void vmport_init(ISABus *bus)
+{
+ isa_create_simple(bus, TYPE_VMPORT);
+}
+
+void vmport_register(unsigned char command, VMPortReadFunc *func, void *opaque);
+void vmmouse_get_data(uint32_t *data);
+void vmmouse_set_data(const uint32_t *data);
+
+#endif
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 08/16] hw/i386/vmport: Define enum for all commands
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (6 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 07/16] hw/i386/vmport: Introduce vmport.h Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 09/16] hw/i386/vmport: Add support for CMD_GETBIOSUUID Liran Alon
` (9 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
No functional change.
Defining an enum for all VMPort commands have the following advantages:
* It gets rid of the error-prone requirement to update VMPORT_ENTRIES
when new VMPort commands are added to QEMU.
* It makes it clear to know by looking at one place at the source, what
are all the VMPort commands supported by QEMU.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmmouse.c | 18 ++++++------------
hw/i386/vmport.c | 11 ++---------
include/hw/i386/vmport.h | 11 ++++++++++-
3 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/hw/i386/vmmouse.c b/hw/i386/vmmouse.c
index 49a546fd3bb6..afb8e9e09a30 100644
--- a/hw/i386/vmmouse.c
+++ b/hw/i386/vmmouse.c
@@ -34,12 +34,6 @@
/* debug only vmmouse */
//#define DEBUG_VMMOUSE
-/* VMMouse Commands */
-#define VMMOUSE_GETVERSION 10
-#define VMMOUSE_DATA 39
-#define VMMOUSE_STATUS 40
-#define VMMOUSE_COMMAND 41
-
#define VMMOUSE_READ_ID 0x45414552
#define VMMOUSE_DISABLE 0x000000f5
#define VMMOUSE_REQUEST_RELATIVE 0x4c455252
@@ -197,10 +191,10 @@ static uint32_t vmmouse_ioport_read(void *opaque, uint32_t addr)
command = data[2] & 0xFFFF;
switch (command) {
- case VMMOUSE_STATUS:
+ case VMPORT_CMD_VMMOUSE_STATUS:
data[0] = vmmouse_get_status(s);
break;
- case VMMOUSE_COMMAND:
+ case VMPORT_CMD_VMMOUSE_COMMAND:
switch (data[1]) {
case VMMOUSE_DISABLE:
vmmouse_disable(s);
@@ -219,7 +213,7 @@ static uint32_t vmmouse_ioport_read(void *opaque, uint32_t addr)
break;
}
break;
- case VMMOUSE_DATA:
+ case VMPORT_CMD_VMMOUSE_DATA:
vmmouse_data(s, data, data[1]);
break;
default:
@@ -276,9 +270,9 @@ static void vmmouse_realizefn(DeviceState *dev, Error **errp)
return;
}
- vmport_register(VMMOUSE_STATUS, vmmouse_ioport_read, s);
- vmport_register(VMMOUSE_COMMAND, vmmouse_ioport_read, s);
- vmport_register(VMMOUSE_DATA, vmmouse_ioport_read, s);
+ vmport_register(VMPORT_CMD_VMMOUSE_STATUS, vmmouse_ioport_read, s);
+ vmport_register(VMPORT_CMD_VMMOUSE_COMMAND, vmmouse_ioport_read, s);
+ vmport_register(VMPORT_CMD_VMMOUSE_DATA, vmmouse_ioport_read, s);
}
static Property vmmouse_properties[] = {
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 7723d37a0657..0ea5e5f4dd14 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -31,10 +31,6 @@
#include "qemu/log.h"
#include "trace.h"
-#define VMPORT_CMD_GETVERSION 0x0a
-#define VMPORT_CMD_GETRAMSIZE 0x14
-
-#define VMPORT_ENTRIES 0x2c
#define VMPORT_MAGIC 0x564D5868
/* Enum taken from open-vm-tools lib/include/vm_vmx_type.h */
@@ -64,12 +60,9 @@ typedef struct VMPortState {
static VMPortState *port_state;
-void vmport_register(unsigned char command, VMPortReadFunc *func, void *opaque)
+void vmport_register(VMPortCommand command, VMPortReadFunc *func, void *opaque)
{
- if (command >= VMPORT_ENTRIES) {
- return;
- }
-
+ assert(command < VMPORT_ENTRIES);
trace_vmport_register(command, func, opaque);
port_state->func[command] = func;
port_state->opaque[command] = opaque;
diff --git a/include/hw/i386/vmport.h b/include/hw/i386/vmport.h
index f0c1e985ca08..0501ccac6ddf 100644
--- a/include/hw/i386/vmport.h
+++ b/include/hw/i386/vmport.h
@@ -4,12 +4,21 @@
#define TYPE_VMPORT "vmport"
typedef uint32_t (VMPortReadFunc)(void *opaque, uint32_t address);
+typedef enum {
+ VMPORT_CMD_GETVERSION = 10,
+ VMPORT_CMD_GETRAMSIZE = 20,
+ VMPORT_CMD_VMMOUSE_DATA = 39,
+ VMPORT_CMD_VMMOUSE_STATUS = 40,
+ VMPORT_CMD_VMMOUSE_COMMAND = 41,
+ VMPORT_ENTRIES
+} VMPortCommand;
+
static inline void vmport_init(ISABus *bus)
{
isa_create_simple(bus, TYPE_VMPORT);
}
-void vmport_register(unsigned char command, VMPortReadFunc *func, void *opaque);
+void vmport_register(VMPortCommand command, VMPortReadFunc *func, void *opaque);
void vmmouse_get_data(uint32_t *data);
void vmmouse_set_data(const uint32_t *data);
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 09/16] hw/i386/vmport: Add support for CMD_GETBIOSUUID
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (7 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 08/16] hw/i386/vmport: Define enum for all commands Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 10/16] hw/i386/vmport: Add support for CMD_GETTIME Liran Alon
` (8 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
This is VMware documented functionallity that some guests rely on.
Returns the BIOS UUID of the current virtual machine.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 17 +++++++++++++++++
include/hw/i386/vmport.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 0ea5e5f4dd14..ef94f4fe78c6 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -27,6 +27,7 @@
#include "hw/i386/vmport.h"
#include "hw/input/i8042.h"
#include "hw/qdev-properties.h"
+#include "sysemu/sysemu.h"
#include "sysemu/hw_accel.h"
#include "qemu/log.h"
#include "trace.h"
@@ -136,6 +137,18 @@ static uint32_t vmport_cmd_get_version(void *opaque, uint32_t addr)
return port_state->vmx_version;
}
+static uint32_t vmport_cmd_get_bios_uuid(void *opaque, uint32_t addr)
+{
+ X86CPU *cpu = X86_CPU(current_cpu);
+ uint32_t *uuid_parts = (uint32_t *)(qemu_uuid.data);
+
+ cpu->env.regs[R_EAX] = le32_to_cpu(uuid_parts[0]);
+ cpu->env.regs[R_EBX] = le32_to_cpu(uuid_parts[1]);
+ cpu->env.regs[R_ECX] = le32_to_cpu(uuid_parts[2]);
+ cpu->env.regs[R_EDX] = le32_to_cpu(uuid_parts[3]);
+ return cpu->env.regs[R_EAX];
+}
+
static uint32_t vmport_cmd_ram_size(void *opaque, uint32_t addr)
{
X86CPU *cpu = X86_CPU(current_cpu);
@@ -184,9 +197,13 @@ static void vmport_realizefn(DeviceState *dev, Error **errp)
isa_register_ioport(isadev, &s->io, 0x5658);
port_state = s;
+
/* Register some generic port commands */
vmport_register(VMPORT_CMD_GETVERSION, vmport_cmd_get_version, NULL);
vmport_register(VMPORT_CMD_GETRAMSIZE, vmport_cmd_ram_size, NULL);
+ if (s->version > 1) {
+ vmport_register(VMPORT_CMD_GETBIOSUUID, vmport_cmd_get_bios_uuid, NULL);
+ }
}
static Property vmport_properties[] = {
diff --git a/include/hw/i386/vmport.h b/include/hw/i386/vmport.h
index 0501ccac6ddf..7f33512ca6f0 100644
--- a/include/hw/i386/vmport.h
+++ b/include/hw/i386/vmport.h
@@ -6,6 +6,7 @@ typedef uint32_t (VMPortReadFunc)(void *opaque, uint32_t address);
typedef enum {
VMPORT_CMD_GETVERSION = 10,
+ VMPORT_CMD_GETBIOSUUID = 19,
VMPORT_CMD_GETRAMSIZE = 20,
VMPORT_CMD_VMMOUSE_DATA = 39,
VMPORT_CMD_VMMOUSE_STATUS = 40,
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 10/16] hw/i386/vmport: Add support for CMD_GETTIME
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (8 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 09/16] hw/i386/vmport: Add support for CMD_GETBIOSUUID Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 11/16] hw/i386/vmport: Add support for CMD_GETTIMEFULL Liran Alon
` (7 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
This command is used by guest to gettimeofday() from host.
See usage example in open-vm-tools TimeSyncReadHost() function.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 21 +++++++++++++++++++++
include/hw/i386/vmport.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index ef94f4fe78c6..15632c579199 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -55,6 +55,7 @@ typedef struct VMPortState {
uint32_t vmx_version;
uint8_t vmx_type;
+ uint32_t max_time_lag_us;
uint8_t version;
} VMPortState;
@@ -157,6 +158,20 @@ static uint32_t vmport_cmd_ram_size(void *opaque, uint32_t addr)
return ram_size;
}
+static uint32_t vmport_cmd_time(void *opaque, uint32_t addr)
+{
+ X86CPU *cpu = X86_CPU(current_cpu);
+ qemu_timeval tv;
+
+ if (qemu_gettimeofday(&tv) < 0) {
+ return UINT32_MAX;
+ }
+
+ cpu->env.regs[R_EBX] = (uint32_t)tv.tv_usec;
+ cpu->env.regs[R_ECX] = port_state->max_time_lag_us;
+ return (uint32_t)tv.tv_sec;
+}
+
/* vmmouse helpers */
void vmmouse_get_data(uint32_t *data)
{
@@ -203,6 +218,7 @@ static void vmport_realizefn(DeviceState *dev, Error **errp)
vmport_register(VMPORT_CMD_GETRAMSIZE, vmport_cmd_ram_size, NULL);
if (s->version > 1) {
vmport_register(VMPORT_CMD_GETBIOSUUID, vmport_cmd_get_bios_uuid, NULL);
+ vmport_register(VMPORT_CMD_GETTIME, vmport_cmd_time, NULL);
}
}
@@ -218,6 +234,11 @@ static Property vmport_properties[] = {
DEFINE_PROP_UINT32("vmx-version", VMPortState, vmx_version, 6),
DEFINE_PROP_UINT8("vmx-type", VMPortState, vmx_type,
VMX_TYPE_SCALABLE_SERVER),
+ /*
+ * Max amount of time lag that can go uncorrected.
+ * Value taken from VMware Workstation 5.5.
+ **/
+ DEFINE_PROP_UINT32("max-time-lag", VMPortState, max_time_lag_us, 1000000),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/include/hw/i386/vmport.h b/include/hw/i386/vmport.h
index 7f33512ca6f0..50416c8c8f3e 100644
--- a/include/hw/i386/vmport.h
+++ b/include/hw/i386/vmport.h
@@ -8,6 +8,7 @@ typedef enum {
VMPORT_CMD_GETVERSION = 10,
VMPORT_CMD_GETBIOSUUID = 19,
VMPORT_CMD_GETRAMSIZE = 20,
+ VMPORT_CMD_GETTIME = 23,
VMPORT_CMD_VMMOUSE_DATA = 39,
VMPORT_CMD_VMMOUSE_STATUS = 40,
VMPORT_CMD_VMMOUSE_COMMAND = 41,
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 11/16] hw/i386/vmport: Add support for CMD_GETTIMEFULL
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (9 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 10/16] hw/i386/vmport: Add support for CMD_GETTIME Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 12/16] hw/i386/vmport: Add support for CMD_GET_VCPU_INFO Liran Alon
` (6 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
Similar to CMD_GETTIME but lacks the 136-year overflow issue,
by returning full 64-bit of host uSeconds.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 17 +++++++++++++++++
include/hw/i386/vmport.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 15632c579199..445104c71c2b 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -172,6 +172,22 @@ static uint32_t vmport_cmd_time(void *opaque, uint32_t addr)
return (uint32_t)tv.tv_sec;
}
+static uint32_t vmport_cmd_time_full(void *opaque, uint32_t addr)
+{
+ X86CPU *cpu = X86_CPU(current_cpu);
+ qemu_timeval tv;
+
+ if (qemu_gettimeofday(&tv) < 0) {
+ return UINT32_MAX;
+ }
+
+ cpu->env.regs[R_ESI] = (uint32_t)((uint64_t)tv.tv_sec >> 32);
+ cpu->env.regs[R_EDX] = (uint32_t)tv.tv_sec;
+ cpu->env.regs[R_EBX] = (uint32_t)tv.tv_usec;
+ cpu->env.regs[R_ECX] = port_state->max_time_lag_us;
+ return VMPORT_MAGIC;
+}
+
/* vmmouse helpers */
void vmmouse_get_data(uint32_t *data)
{
@@ -219,6 +235,7 @@ static void vmport_realizefn(DeviceState *dev, Error **errp)
if (s->version > 1) {
vmport_register(VMPORT_CMD_GETBIOSUUID, vmport_cmd_get_bios_uuid, NULL);
vmport_register(VMPORT_CMD_GETTIME, vmport_cmd_time, NULL);
+ vmport_register(VMPORT_CMD_GETTIMEFULL, vmport_cmd_time_full, NULL);
}
}
diff --git a/include/hw/i386/vmport.h b/include/hw/i386/vmport.h
index 50416c8c8f3e..5d19963ed417 100644
--- a/include/hw/i386/vmport.h
+++ b/include/hw/i386/vmport.h
@@ -12,6 +12,7 @@ typedef enum {
VMPORT_CMD_VMMOUSE_DATA = 39,
VMPORT_CMD_VMMOUSE_STATUS = 40,
VMPORT_CMD_VMMOUSE_COMMAND = 41,
+ VMPORT_CMD_GETTIMEFULL = 46,
VMPORT_ENTRIES
} VMPortCommand;
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 12/16] hw/i386/vmport: Add support for CMD_GET_VCPU_INFO
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (10 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 11/16] hw/i386/vmport: Add support for CMD_GETTIMEFULL Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 13/16] hw/i386/vmport: Allow x2apic without IR Liran Alon
` (5 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
Command currently returns that it is unimplemented by setting
the reserved-bit in it's return value.
Following patches will return various useful vCPU information
to guest.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 14 ++++++++++++++
include/hw/i386/vmport.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 445104c71c2b..30641d3ffb20 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -44,6 +44,13 @@ typedef enum {
VMX_TYPE_WORKSTATION_ENTERPRISE /* Deprecated type used for ACE 1.x */
} VMXType;
+/* vCPU features reported by CMD_GET_VCPU_INFO */
+#define VCPU_INFO_SLC64_BIT 0
+#define VCPU_INFO_SYNC_VTSCS_BIT 1
+#define VCPU_INFO_HV_REPLAY_OK_BIT 2
+#define VCPU_INFO_LEGACY_X2APIC_BIT 3
+#define VCPU_INFO_RESERVED_BIT 31
+
#define VMPORT(obj) OBJECT_CHECK(VMPortState, (obj), TYPE_VMPORT)
typedef struct VMPortState {
@@ -188,6 +195,11 @@ static uint32_t vmport_cmd_time_full(void *opaque, uint32_t addr)
return VMPORT_MAGIC;
}
+static uint32_t vmport_cmd_get_vcpu_info(void *opaque, uint32_t addr)
+{
+ return 1 << VCPU_INFO_RESERVED_BIT;
+}
+
/* vmmouse helpers */
void vmmouse_get_data(uint32_t *data)
{
@@ -236,6 +248,8 @@ static void vmport_realizefn(DeviceState *dev, Error **errp)
vmport_register(VMPORT_CMD_GETBIOSUUID, vmport_cmd_get_bios_uuid, NULL);
vmport_register(VMPORT_CMD_GETTIME, vmport_cmd_time, NULL);
vmport_register(VMPORT_CMD_GETTIMEFULL, vmport_cmd_time_full, NULL);
+ vmport_register(VMPORT_CMD_GET_VCPU_INFO, vmport_cmd_get_vcpu_info,
+ NULL);
}
}
diff --git a/include/hw/i386/vmport.h b/include/hw/i386/vmport.h
index 5d19963ed417..34cc050b1ffa 100644
--- a/include/hw/i386/vmport.h
+++ b/include/hw/i386/vmport.h
@@ -13,6 +13,7 @@ typedef enum {
VMPORT_CMD_VMMOUSE_STATUS = 40,
VMPORT_CMD_VMMOUSE_COMMAND = 41,
VMPORT_CMD_GETTIMEFULL = 46,
+ VMPORT_CMD_GET_VCPU_INFO = 68,
VMPORT_ENTRIES
} VMPortCommand;
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 13/16] hw/i386/vmport: Allow x2apic without IR
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (11 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 12/16] hw/i386/vmport: Add support for CMD_GET_VCPU_INFO Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 14/16] i386/cpu: Store LAPIC bus frequency in CPU structure Liran Alon
` (4 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
Signal to guest that hypervisor supports x2apic without VT-d/IOMMU
Interrupt-Remapping support. This allows guest to use x2apic in
case all APIC IDs fits in 8-bit (i.e. Max APIC ID < 255).
See Linux kernel commit 4cca6ea04d31 ("x86/apic: Allow x2apic
without IR on VMware platform") and Linux try_to_enable_x2apic()
function.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 30641d3ffb20..6ca03273066e 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -197,7 +197,14 @@ static uint32_t vmport_cmd_time_full(void *opaque, uint32_t addr)
static uint32_t vmport_cmd_get_vcpu_info(void *opaque, uint32_t addr)
{
- return 1 << VCPU_INFO_RESERVED_BIT;
+ X86CPU *cpu = X86_CPU(current_cpu);
+ uint32_t ret = 0;
+
+ if (cpu->env.features[FEAT_1_ECX] & CPUID_EXT_X2APIC) {
+ ret |= 1 << VCPU_INFO_LEGACY_X2APIC_BIT;
+ }
+
+ return ret;
}
/* vmmouse helpers */
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 14/16] i386/cpu: Store LAPIC bus frequency in CPU structure
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (12 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 13/16] hw/i386/vmport: Allow x2apic without IR Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 15/16] hw/i386/vmport: Add support for CMD_GETHZ Liran Alon
` (3 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
No functional change.
This information will be used by following patches.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
target/i386/cpu.h | 1 +
target/i386/kvm.c | 10 +++++++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 576f309bbfc8..9c7cd7cde107 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1580,6 +1580,7 @@ typedef struct CPUX86State {
bool tsc_valid;
int64_t tsc_khz;
int64_t user_tsc_khz; /* for sanity check only */
+ uint64_t apic_bus_freq;
#if defined(CONFIG_KVM) || defined(CONFIG_HVF)
void *xsave_buf;
#endif
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 69eb43d796e6..8534ca9760d7 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -60,6 +60,10 @@
do { } while (0)
#endif
+/* From arch/x86/kvm/lapic.h */
+#define KVM_APIC_BUS_CYCLE_NS 1
+#define KVM_APIC_BUS_FREQUENCY (1000000000ULL / KVM_APIC_BUS_CYCLE_NS)
+
#define MSR_KVM_WALL_CLOCK 0x11
#define MSR_KVM_SYSTEM_TIME 0x12
@@ -1496,6 +1500,8 @@ int kvm_arch_init_vcpu(CPUState *cs)
}
}
+ env->apic_bus_freq = KVM_APIC_BUS_FREQUENCY;
+
/* Paravirtualization CPUIDs */
r = hyperv_handle_properties(cs, cpuid_data.entries);
if (r < 0) {
@@ -1800,9 +1806,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
c = &cpuid_data.entries[cpuid_i++];
c->function = KVM_CPUID_SIGNATURE | 0x10;
c->eax = env->tsc_khz;
- /* LAPIC resolution of 1ns (freq: 1GHz) is hardcoded in KVM's
- * APIC_BUS_CYCLE_NS */
- c->ebx = 1000000;
+ c->ebx = env->apic_bus_freq / 1000; /* Hz to KHz */
c->ecx = c->edx = 0;
c = cpuid_find_entry(&cpuid_data.cpuid, kvm_base, 0);
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 15/16] hw/i386/vmport: Add support for CMD_GETHZ
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (13 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 14/16] i386/cpu: Store LAPIC bus frequency in CPU structure Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 16:53 ` [PATCH v2 16/16] hw/i386/vmport: Assert vmport initialized before registering commands Liran Alon
` (2 subsequent siblings)
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
This command returns to guest information on LAPIC bus frequency and TSC
frequency.
One can see how this interface is used by Linux vmware_platform_setup()
introduced in Linux commit 88b094fb8d4f ("x86: Hypervisor detection and
get tsc_freq from hypervisor").
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 19 +++++++++++++++++++
include/hw/i386/vmport.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 6ca03273066e..76fd49c52058 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -165,6 +165,24 @@ static uint32_t vmport_cmd_ram_size(void *opaque, uint32_t addr)
return ram_size;
}
+static uint32_t vmport_cmd_get_hz(void *opaque, uint32_t addr)
+{
+ X86CPU *cpu = X86_CPU(current_cpu);
+
+ if (cpu->env.tsc_khz && cpu->env.apic_bus_freq) {
+ uint64_t tsc_freq = (uint64_t)cpu->env.tsc_khz * 1000;
+
+ cpu->env.regs[R_ECX] = cpu->env.apic_bus_freq;
+ cpu->env.regs[R_EBX] = (uint32_t)(tsc_freq >> 32);
+ cpu->env.regs[R_EAX] = (uint32_t)tsc_freq;
+ } else {
+ /* Signal cmd as not supported */
+ cpu->env.regs[R_EBX] = UINT32_MAX;
+ }
+
+ return cpu->env.regs[R_EAX];
+}
+
static uint32_t vmport_cmd_time(void *opaque, uint32_t addr)
{
X86CPU *cpu = X86_CPU(current_cpu);
@@ -254,6 +272,7 @@ static void vmport_realizefn(DeviceState *dev, Error **errp)
if (s->version > 1) {
vmport_register(VMPORT_CMD_GETBIOSUUID, vmport_cmd_get_bios_uuid, NULL);
vmport_register(VMPORT_CMD_GETTIME, vmport_cmd_time, NULL);
+ vmport_register(VMPORT_CMD_GETHZ, vmport_cmd_get_hz, NULL);
vmport_register(VMPORT_CMD_GETTIMEFULL, vmport_cmd_time_full, NULL);
vmport_register(VMPORT_CMD_GET_VCPU_INFO, vmport_cmd_get_vcpu_info,
NULL);
diff --git a/include/hw/i386/vmport.h b/include/hw/i386/vmport.h
index 34cc050b1ffa..aee809521aa0 100644
--- a/include/hw/i386/vmport.h
+++ b/include/hw/i386/vmport.h
@@ -12,6 +12,7 @@ typedef enum {
VMPORT_CMD_VMMOUSE_DATA = 39,
VMPORT_CMD_VMMOUSE_STATUS = 40,
VMPORT_CMD_VMMOUSE_COMMAND = 41,
+ VMPORT_CMD_GETHZ = 45,
VMPORT_CMD_GETTIMEFULL = 46,
VMPORT_CMD_GET_VCPU_INFO = 68,
VMPORT_ENTRIES
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 16/16] hw/i386/vmport: Assert vmport initialized before registering commands
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (14 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 15/16] hw/i386/vmport: Add support for CMD_GETHZ Liran Alon
@ 2020-03-10 16:53 ` Liran Alon
2020-03-10 17:44 ` [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Michael S. Tsirkin
2020-03-10 19:12 ` no-reply
17 siblings, 0 replies; 27+ messages in thread
From: Liran Alon @ 2020-03-10 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: ehabkost, mst, Liran Alon, nikita.leshchenko, rth
vmport_register() is also called from other modules such as vmmouse.
Therefore, these modules rely that vmport is realized before those call
sites. If this is violated, vmport_register() will NULL-deref.
To make such issues easier to debug, assert in vmport_register() that
vmport is already realized.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
---
hw/i386/vmport.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 76fd49c52058..8d3d268bfd7e 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -72,6 +72,8 @@ static VMPortState *port_state;
void vmport_register(VMPortCommand command, VMPortReadFunc *func, void *opaque)
{
assert(command < VMPORT_ENTRIES);
+ assert(port_state);
+
trace_vmport_register(command, func, opaque);
port_state->func[command] = func;
port_state->opaque[command] = opaque;
--
2.20.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (15 preceding siblings ...)
2020-03-10 16:53 ` [PATCH v2 16/16] hw/i386/vmport: Assert vmport initialized before registering commands Liran Alon
@ 2020-03-10 17:44 ` Michael S. Tsirkin
2020-03-10 18:09 ` Liran Alon
2020-03-10 19:12 ` no-reply
17 siblings, 1 reply; 27+ messages in thread
From: Michael S. Tsirkin @ 2020-03-10 17:44 UTC (permalink / raw)
To: Liran Alon; +Cc: nikita.leshchenko, ehabkost, qemu-devel, rth
On Tue, Mar 10, 2020 at 06:53:16PM +0200, Liran Alon wrote:
> Hi,
>
> This series aims to fix several bugs in VMPort and improve it by supporting
> more VMPort commands and make command results more configurable to
> user via QEMU command-line.
>
> This functionality was proven to be useful to run various VMware VMs
> when attempting to run them as-is on top of QEMU/KVM.
>
> For more details, see commit messages.
Well two versions in one day and some review comments weren't addressed.
Some people do this, try to wear the maintainers out by sheer volume.
It works sometimes but it's not a nice tactic. I personally think it's
worth taking the time to think harder about ways to address all
comments, not try to dismiss them.
Thanks!
> Regards,
> -Liran
>
> v1->v2:
> * Fix coding convention [Patchew Bot & MST].
> * Create new header file for vmport.h [MST].
> * Move KVM_APIC_BUS_FREQUENCY from linux-headers/asm-x86/kvm.h
> auto-generated header [MST]
> * Elaborate more that vmx-version refers to the VMware userspace
> VMM in commit message. [MST]
> * Use le32_to_cpu() on BIOS_UUID vmport command. [MST]
> * Introduce VMPort compatability version property to maintain migration
> compatibility. [MST]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
2020-03-10 17:44 ` [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Michael S. Tsirkin
@ 2020-03-10 18:09 ` Liran Alon
2020-03-10 20:56 ` Michael S. Tsirkin
0 siblings, 1 reply; 27+ messages in thread
From: Liran Alon @ 2020-03-10 18:09 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: nikita.leshchenko, ehabkost, qemu-devel, rth
On 10/03/2020 19:44, Michael S. Tsirkin wrote:
> On Tue, Mar 10, 2020 at 06:53:16PM +0200, Liran Alon wrote:
>> Hi,
>>
>> This series aims to fix several bugs in VMPort and improve it by supporting
>> more VMPort commands and make command results more configurable to
>> user via QEMU command-line.
>>
>> This functionality was proven to be useful to run various VMware VMs
>> when attempting to run them as-is on top of QEMU/KVM.
>>
>> For more details, see commit messages.
> Well two versions in one day and some review comments weren't addressed.
There is a single review comment that wasn't addressed which is
replacing an enum with a comment. And I explicitly mentioned that it's
because I want additional opinion on this.
I don't see why such a small thing should block review for 15 patches...
All the rest of the comments (Which were great) have been addressed.
Unless I have mistakenly missed something, which please point it out if
I did.
> Some people do this, try to wear the maintainers out by sheer volume.
> It works sometimes but it's not a nice tactic. I personally think it's
> worth taking the time to think harder about ways to address all
> comments, not try to dismiss them.
That's not what I tried to do. I carefully fixed all comments I saw in
the review discussion and run tests.
The only thing which wasn't addressed is removing an enum and replacing
it with a comment.
The hint that I try to manipulate maintainers is disrespectful. I assume
that this isn't your intention, as we all just want to collaborate
together here. No need to make this a personal discussion.
If you think that replacing the enum with a comment is a blocker for v2
patch-series, I will go ahead and submit v3 with that change.
Is there any other comment you made on v1 patch-series you think I missed?
Thanks,
-Liran
>
> Thanks!
>
>> Regards,
>> -Liran
>>
>> v1->v2:
>> * Fix coding convention [Patchew Bot & MST].
>> * Create new header file for vmport.h [MST].
>> * Move KVM_APIC_BUS_FREQUENCY from linux-headers/asm-x86/kvm.h
>> auto-generated header [MST]
>> * Elaborate more that vmx-version refers to the VMware userspace
>> VMM in commit message. [MST]
>> * Use le32_to_cpu() on BIOS_UUID vmport command. [MST]
>> * Introduce VMPort compatability version property to maintain migration
>> compatibility. [MST]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
` (16 preceding siblings ...)
2020-03-10 17:44 ` [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Michael S. Tsirkin
@ 2020-03-10 19:12 ` no-reply
17 siblings, 0 replies; 27+ messages in thread
From: no-reply @ 2020-03-10 19:12 UTC (permalink / raw)
To: liran.alon; +Cc: rth, mst, qemu-devel, ehabkost, nikita.leshchenko
Patchew URL: https://patchew.org/QEMU/20200310165332.140774-1-liran.alon@oracle.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===
PASS 32 test-opts-visitor /visitor/opts/range/beyond
PASS 33 test-opts-visitor /visitor/opts/dict/unvisited
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-coroutine -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-coroutine"
==6415==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-coroutine /basic/no-dangling-access
PASS 2 test-coroutine /basic/lifecycle
PASS 3 test-coroutine /basic/yield
==6415==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffd80047000; bottom 0x7f8d591b3000; size: 0x007026e94000 (481689157632)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 4 test-coroutine /basic/nesting
---
PASS 1 fdc-test /x86_64/fdc/cmos
PASS 2 fdc-test /x86_64/fdc/no_media_on_start
PASS 3 fdc-test /x86_64/fdc/read_without_media
==6426==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 4 fdc-test /x86_64/fdc/media_change
PASS 5 fdc-test /x86_64/fdc/sense_interrupt
PASS 6 fdc-test /x86_64/fdc/relative_seek
---
PASS 12 test-aio /aio/event/flush
PASS 13 test-aio /aio/event/wait/no-flush-cb
PASS 14 test-aio /aio/timer/schedule
==6440==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 15 test-aio /aio/coroutine/queue-chaining
PASS 16 test-aio /aio-gsource/flush
PASS 17 test-aio /aio-gsource/bh/schedule
---
PASS 11 fdc-test /x86_64/fdc/read_no_dma_18
PASS 28 test-aio /aio-gsource/timer/schedule
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-aio-multithread -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-aio-multithread"
==6445==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-aio-multithread /aio/multi/lifecycle
PASS 2 test-aio-multithread /aio/multi/schedule
PASS 3 test-aio-multithread /aio/multi/mutex/contended
PASS 12 fdc-test /x86_64/fdc/read_no_dma_19
PASS 13 fdc-test /x86_64/fdc/fuzz-registers
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img tests/qtest/ide-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="ide-test"
==6472==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 ide-test /x86_64/ide/identify
==6478==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 4 test-aio-multithread /aio/multi/mutex/handoff
PASS 2 ide-test /x86_64/ide/flush
PASS 5 test-aio-multithread /aio/multi/mutex/mcs
==6489==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 3 ide-test /x86_64/ide/bmdma/simple_rw
PASS 6 test-aio-multithread /aio/multi/mutex/pthread
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-throttle -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-throttle"
==6506==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-throttle /throttle/leak_bucket
PASS 2 test-throttle /throttle/compute_wait
PASS 3 test-throttle /throttle/init
---
PASS 14 test-throttle /throttle/config/max
PASS 15 test-throttle /throttle/config/iops_size
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-thread-pool -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-thread-pool"
==6500==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==6510==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-thread-pool /thread-pool/submit
PASS 2 test-thread-pool /thread-pool/submit-aio
PASS 3 test-thread-pool /thread-pool/submit-co
PASS 4 test-thread-pool /thread-pool/submit-many
PASS 4 ide-test /x86_64/ide/bmdma/trim
==6564==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 5 test-thread-pool /thread-pool/cancel
PASS 6 test-thread-pool /thread-pool/cancel-async
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-hbitmap -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-hbitmap"
---
PASS 15 test-hbitmap /hbitmap/set/overlap
PASS 16 test-hbitmap /hbitmap/reset/empty
PASS 17 test-hbitmap /hbitmap/reset/general
==6588==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 18 test-hbitmap /hbitmap/reset/all
PASS 19 test-hbitmap /hbitmap/truncate/nop
PASS 20 test-hbitmap /hbitmap/truncate/grow/negligible
---
PASS 28 test-hbitmap /hbitmap/truncate/shrink/medium
PASS 29 test-hbitmap /hbitmap/truncate/shrink/large
PASS 30 test-hbitmap /hbitmap/meta/zero
==6594==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 31 test-hbitmap /hbitmap/meta/one
PASS 32 test-hbitmap /hbitmap/meta/byte
PASS 33 test-hbitmap /hbitmap/meta/word
---
PASS 44 test-hbitmap /hbitmap/next_dirty_area/next_dirty_area_4
PASS 45 test-hbitmap /hbitmap/next_dirty_area/next_dirty_area_after_truncate
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-bdrv-drain -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-bdrv-drain"
==6601==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-bdrv-drain /bdrv-drain/nested
PASS 2 test-bdrv-drain /bdrv-drain/multiparent
PASS 3 test-bdrv-drain /bdrv-drain/set_aio_context
---
PASS 41 test-bdrv-drain /bdrv-drain/bdrv_drop_intermediate/poll
PASS 42 test-bdrv-drain /bdrv-drain/replace_child/mid-drain
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-bdrv-graph-mod -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-bdrv-graph-mod"
==6640==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-bdrv-graph-mod /bdrv-graph-mod/update-perm-tree
PASS 2 test-bdrv-graph-mod /bdrv-graph-mod/should-update-child
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-blockjob -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-blockjob"
==6644==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-blockjob /blockjob/ids
PASS 2 test-blockjob /blockjob/cancel/created
PASS 3 test-blockjob /blockjob/cancel/running
---
PASS 7 test-blockjob /blockjob/cancel/pending
PASS 8 test-blockjob /blockjob/cancel/concluded
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-blockjob-txn -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-blockjob-txn"
==6648==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-blockjob-txn /single/success
PASS 2 test-blockjob-txn /single/failure
PASS 3 test-blockjob-txn /single/cancel
---
PASS 6 test-blockjob-txn /pair/cancel
PASS 7 test-blockjob-txn /pair/fail-cancel-race
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-block-backend -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-block-backend"
==6654==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-block-backend /block-backend/drain_aio_error
PASS 2 test-block-backend /block-backend/drain_all_aio_error
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-block-iothread -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-block-iothread"
==6658==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-block-iothread /sync-op/pread
PASS 2 test-block-iothread /sync-op/pwrite
PASS 3 test-block-iothread /sync-op/load_vmstate
---
PASS 15 test-block-iothread /propagate/diamond
PASS 16 test-block-iothread /propagate/mirror
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-image-locking -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-image-locking"
==6650==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==6681==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-image-locking /image-locking/basic
PASS 2 test-image-locking /image-locking/set-perm-abort
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-x86-cpuid -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-x86-cpuid"
---
PASS 1 rcutorture /rcu/torture/1reader
PASS 2 rcutorture /rcu/torture/10readers
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-rcu-list -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-rcu-list"
==6740==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-rcu-list /rcu/qlist/single-threaded
PASS 2 test-rcu-list /rcu/qlist/short-few
PASS 3 test-rcu-list /rcu/qlist/long-many
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-rcu-simpleq -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-rcu-simpleq"
PASS 1 test-rcu-simpleq /rcu/qsimpleq/single-threaded
PASS 2 test-rcu-simpleq /rcu/qsimpleq/short-few
==6806==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 3 test-rcu-simpleq /rcu/qsimpleq/long-many
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-rcu-tailq -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-rcu-tailq"
PASS 1 test-rcu-tailq /rcu/qtailq/single-threaded
PASS 2 test-rcu-tailq /rcu/qtailq/short-few
==6845==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 3 test-rcu-tailq /rcu/qtailq/long-many
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-rcu-slist -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-rcu-slist"
PASS 1 test-rcu-slist /rcu/qslist/single-threaded
---
PASS 7 test-qdist /qdist/binning/expand
PASS 8 test-qdist /qdist/binning/shrink
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-qht -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-qht"
==6891==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==6897==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 5 ide-test /x86_64/ide/bmdma/various_prdts
==6903==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==6903==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffe2c103000; bottom 0x7f0636126000; size: 0x00f7f5fdd000 (1064983973888)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 6 ide-test /x86_64/ide/bmdma/no_busmaster
---
PASS 7 ide-test /x86_64/ide/flush/nodev
PASS 2 test-qht /qht/mode/resize
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-qht-par -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-qht-par"
==6914==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 8 ide-test /x86_64/ide/flush/empty_drive
==6928==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 9 ide-test /x86_64/ide/flush/retry_pci
PASS 1 test-qht-par /qht/parallel/2threads-0%updates-1s
==6934==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 10 ide-test /x86_64/ide/flush/retry_isa
PASS 2 test-qht-par /qht/parallel/2threads-20%updates-1s
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-bitops -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-bitops"
---
PASS 3 test-bitcnt /bitcnt/ctpop32
PASS 4 test-bitcnt /bitcnt/ctpop64
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-qdev-global-props -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-qdev-global-props"
==6946==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-qdev-global-props /qdev/properties/static/default
PASS 2 test-qdev-global-props /qdev/properties/static/global
PASS 3 test-qdev-global-props /qdev/properties/dynamic/global
---
PASS 8 check-qom-proplist /qom/proplist/delchild
PASS 9 check-qom-proplist /qom/resolve/partial
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-qemu-opts -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-qemu-opts"
==6976==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-qemu-opts /qemu-opts/find_unknown_opts
PASS 2 test-qemu-opts /qemu-opts/find_opts
PASS 3 test-qemu-opts /qemu-opts/opts_create
---
PASS 15 test-crypto-secret /crypto/secret/crypt/missingiv
PASS 16 test-crypto-secret /crypto/secret/crypt/badiv
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-crypto-tlscredsx509 -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-crypto-tlscredsx509"
==7013==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 13 ide-test /x86_64/ide/cdrom/dma
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img tests/qtest/ahci-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="ahci-test"
==7032==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 ahci-test /x86_64/ahci/sanity
PASS 1 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/perfectserver
PASS 2 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/perfectclient
==7038==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 2 ahci-test /x86_64/ahci/pci_spec
PASS 3 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodca1
PASS 4 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodca2
==7044==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 3 ahci-test /x86_64/ahci/pci_enable
PASS 5 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodca3
PASS 6 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/badca1
PASS 7 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/badca2
PASS 8 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/badca3
==7050==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 9 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver1
PASS 4 ahci-test /x86_64/ahci/hba_spec
PASS 10 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver2
PASS 11 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver3
==7056==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 5 ahci-test /x86_64/ahci/hba_enable
==7062==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 6 ahci-test /x86_64/ahci/identify
PASS 12 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver4
PASS 13 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver5
==7068==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 7 ahci-test /x86_64/ahci/max
PASS 14 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver6
==7074==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 15 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver7
PASS 16 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/badserver1
PASS 17 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/badserver2
---
PASS 33 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/inactive2
PASS 34 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/inactive3
PASS 8 ahci-test /x86_64/ahci/reset
==7080==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7080==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffe0f455000; bottom 0x7f4860ffe000; size: 0x00b5ae457000 (780312866816)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 35 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/chain1
---
PASS 39 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/missingclient
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-crypto-tlssession -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-crypto-tlssession"
PASS 9 ahci-test /x86_64/ahci/io/pio/lba28/simple/zero
==7090==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7090==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffc1f65d000; bottom 0x7fae6cffe000; size: 0x004db265f000 (333705506816)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 10 ahci-test /x86_64/ahci/io/pio/lba28/simple/low
PASS 1 test-crypto-tlssession /qcrypto/tlssession/psk
==7096==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 2 test-crypto-tlssession /qcrypto/tlssession/basicca
==7096==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fffe6f0c000; bottom 0x7fd8b2bfe000; size: 0x00273430e000 (168379342848)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 3 test-crypto-tlssession /qcrypto/tlssession/differentca
PASS 11 ahci-test /x86_64/ahci/io/pio/lba28/simple/high
==7102==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7102==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffc3c960000; bottom 0x7f48799fe000; size: 0x00b3c2f62000 (772070055936)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 4 test-crypto-tlssession /qcrypto/tlssession/altname1
PASS 12 ahci-test /x86_64/ahci/io/pio/lba28/double/zero
PASS 5 test-crypto-tlssession /qcrypto/tlssession/altname2
==7108==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7108==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffff1b4a000; bottom 0x7feb3b1fe000; size: 0x0014b694c000 (88962547712)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 13 ahci-test /x86_64/ahci/io/pio/lba28/double/low
==7114==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7114==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffde1579000; bottom 0x7fce125fe000; size: 0x002fcef7b000 (205335801856)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 14 ahci-test /x86_64/ahci/io/pio/lba28/double/high
PASS 6 test-crypto-tlssession /qcrypto/tlssession/altname3
==7120==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7120==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffd918ce000; bottom 0x7ff4f557c000; size: 0x00089c352000 (36980465664)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 15 ahci-test /x86_64/ahci/io/pio/lba28/long/zero
==7126==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 7 test-crypto-tlssession /qcrypto/tlssession/altname4
==7126==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fff419c0000; bottom 0x7f61c65fe000; size: 0x009d7b3c2000 (676377403392)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 16 ahci-test /x86_64/ahci/io/pio/lba28/long/low
PASS 8 test-crypto-tlssession /qcrypto/tlssession/altname5
PASS 9 test-crypto-tlssession /qcrypto/tlssession/altname6
==7132==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7132==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffd9a2dc000; bottom 0x7fc2ce324000; size: 0x003acbfb8000 (252530360320)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 10 test-crypto-tlssession /qcrypto/tlssession/wildcard1
PASS 17 ahci-test /x86_64/ahci/io/pio/lba28/long/high
PASS 11 test-crypto-tlssession /qcrypto/tlssession/wildcard2
==7138==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 18 ahci-test /x86_64/ahci/io/pio/lba28/short/zero
==7144==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 12 test-crypto-tlssession /qcrypto/tlssession/wildcard3
PASS 19 ahci-test /x86_64/ahci/io/pio/lba28/short/low
==7150==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 20 ahci-test /x86_64/ahci/io/pio/lba28/short/high
PASS 13 test-crypto-tlssession /qcrypto/tlssession/wildcard4
==7156==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 14 test-crypto-tlssession /qcrypto/tlssession/wildcard5
==7156==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffe0bada000; bottom 0x7f63419fe000; size: 0x009aca0dc000 (664814862336)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 21 ahci-test /x86_64/ahci/io/pio/lba48/simple/zero
PASS 15 test-crypto-tlssession /qcrypto/tlssession/wildcard6
==7162==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7162==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffdfb406000; bottom 0x7fccccbfe000; size: 0x00312e808000 (211233570816)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 22 ahci-test /x86_64/ahci/io/pio/lba48/simple/low
PASS 16 test-crypto-tlssession /qcrypto/tlssession/cachain
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-qga -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-qga"
==7168==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7168==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffc7f590000; bottom 0x7f67647fe000; size: 0x00951ad92000 (640400564224)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 23 ahci-test /x86_64/ahci/io/pio/lba48/simple/high
---
PASS 8 test-qga /qga/get-memory-block-info
PASS 9 test-qga /qga/get-memory-blocks
PASS 10 test-qga /qga/file-ops
==7182==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 11 test-qga /qga/file-write-read
PASS 12 test-qga /qga/get-time
PASS 13 test-qga /qga/id
---
PASS 15 test-qga /qga/invalid-cmd
PASS 16 test-qga /qga/invalid-args
PASS 17 test-qga /qga/fsfreeze-status
==7182==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffef0b02000; bottom 0x7f9513bfe000; size: 0x0069dcf04000 (454678298624)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 24 ahci-test /x86_64/ahci/io/pio/lba48/double/zero
PASS 18 test-qga /qga/blacklist
PASS 19 test-qga /qga/config
PASS 20 test-qga /qga/guest-exec
==7191==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 21 test-qga /qga/guest-exec-invalid
==7191==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffc02ee6000; bottom 0x7fb53ddfe000; size: 0x0046c50e8000 (303953772544)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 25 ahci-test /x86_64/ahci/io/pio/lba48/double/low
==7209==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 22 test-qga /qga/guest-get-osinfo
PASS 23 test-qga /qga/guest-get-host-name
PASS 24 test-qga /qga/guest-get-timezone
PASS 25 test-qga /qga/guest-get-users
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-timed-average -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-timed-average"
==7209==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffd01a46000; bottom 0x7fbcf65fe000; size: 0x00400b448000 (275066945536)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-timed-average /timed-average/average
---
PASS 7 test-util-sockets /socket/fd-pass/num/bad
PASS 8 test-util-sockets /socket/fd-pass/num/nocli
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-authz-simple -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-authz-simple"
==7225==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-authz-simple /authz/simple
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-authz-list -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-authz-list"
PASS 1 test-authz-list /auth/list/complex
---
PASS 5 test-authz-list /auth/list/explicit/deny
PASS 6 test-authz-list /auth/list/explicit/allow
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-authz-listfile -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-authz-listfile"
==7225==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffd64491000; bottom 0x7f057d724000; size: 0x00f7e6d6d000 (1064729759744)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-authz-listfile /auth/list/complex
---
PASS 8 test-io-channel-socket /io/channel/socket/unix-fd-pass
PASS 9 test-io-channel-socket /io/channel/socket/unix-listen-cleanup
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-io-channel-file -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-io-channel-file"
==7256==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-io-channel-file /io/channel/file
PASS 2 test-io-channel-file /io/channel/file/rdwr
PASS 3 test-io-channel-file /io/channel/file/fd
PASS 4 test-io-channel-file /io/channel/pipe/sync
PASS 5 test-io-channel-file /io/channel/pipe/async
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-io-channel-tls -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-io-channel-tls"
==7256==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffd866c7000; bottom 0x7f0bff5fe000; size: 0x00f1870c9000 (1037352865792)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-io-channel-tls /qio/channel/tls/basic
---
PASS 17 test-crypto-pbkdf /crypto/pbkdf/nonrfc/sha384/iter1200
PASS 18 test-crypto-pbkdf /crypto/pbkdf/nonrfc/ripemd160/iter1200
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-crypto-ivgen -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-crypto-ivgen"
==7319==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-crypto-ivgen /crypto/ivgen/plain/1
PASS 2 test-crypto-ivgen /crypto/ivgen/plain/1f2e3d4c
PASS 3 test-crypto-ivgen /crypto/ivgen/plain/1f2e3d4c5b6a7988
---
PASS 3 test-crypto-afsplit /crypto/afsplit/sha256/big
PASS 4 test-crypto-afsplit /crypto/afsplit/sha1/1000
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-crypto-xts -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-crypto-xts"
==7319==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fff4d3c5000; bottom 0x7f763d3fe000; size: 0x00890ffc7000 (588678721536)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-crypto-xts /crypto/xts/t-1-key-32-ptx-32/basic
---
PASS 3 test-logging /logging/logfile_write_path
PASS 4 test-logging /logging/logfile_lock_path
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-replication -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-replication"
==7359==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7352==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-replication /replication/primary/read
PASS 30 ahci-test /x86_64/ahci/io/pio/lba48/short/zero
PASS 2 test-replication /replication/primary/write
==7367==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 31 ahci-test /x86_64/ahci/io/pio/lba48/short/low
PASS 3 test-replication /replication/primary/start
PASS 4 test-replication /replication/primary/stop
PASS 5 test-replication /replication/primary/do_checkpoint
PASS 6 test-replication /replication/primary/get_error_all
==7373==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 7 test-replication /replication/secondary/read
PASS 32 ahci-test /x86_64/ahci/io/pio/lba48/short/high
==7379==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 8 test-replication /replication/secondary/write
PASS 33 ahci-test /x86_64/ahci/io/dma/lba28/fragmented
==7385==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 34 ahci-test /x86_64/ahci/io/dma/lba28/retry
==7391==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 35 ahci-test /x86_64/ahci/io/dma/lba28/simple/zero
==7359==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fff37f5b000; bottom 0x7ffa0b9bd000; size: 0x00052c59e000 (22218924032)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
==7409==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 9 test-replication /replication/secondary/start
PASS 36 ahci-test /x86_64/ahci/io/dma/lba28/simple/low
==7421==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 37 ahci-test /x86_64/ahci/io/dma/lba28/simple/high
==7427==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 38 ahci-test /x86_64/ahci/io/dma/lba28/double/zero
==7433==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 39 ahci-test /x86_64/ahci/io/dma/lba28/double/low
PASS 10 test-replication /replication/secondary/stop
==7439==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 40 ahci-test /x86_64/ahci/io/dma/lba28/double/high
==7445==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7445==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffc4e206000; bottom 0x7f6d31523000; size: 0x008f1cce3000 (614663598080)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 41 ahci-test /x86_64/ahci/io/dma/lba28/long/zero
==7452==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7452==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffc106d3000; bottom 0x7f8dcc9fd000; size: 0x006e43cd6000 (473583935488)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 11 test-replication /replication/secondary/continuous_replication
PASS 42 ahci-test /x86_64/ahci/io/dma/lba28/long/low
==7459==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7459==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffda91e3000; bottom 0x7fa4597fd000; size: 0x00594f9e6000 (383587868672)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 43 ahci-test /x86_64/ahci/io/dma/lba28/long/high
==7466==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 44 ahci-test /x86_64/ahci/io/dma/lba28/short/zero
==7472==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 12 test-replication /replication/secondary/do_checkpoint
PASS 45 ahci-test /x86_64/ahci/io/dma/lba28/short/low
==7478==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 13 test-replication /replication/secondary/get_error_all
PASS 46 ahci-test /x86_64/ahci/io/dma/lba28/short/high
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-bufferiszero -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-bufferiszero"
==7484==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 47 ahci-test /x86_64/ahci/io/dma/lba48/simple/zero
==7493==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 48 ahci-test /x86_64/ahci/io/dma/lba48/simple/low
==7499==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 49 ahci-test /x86_64/ahci/io/dma/lba48/simple/high
==7505==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 50 ahci-test /x86_64/ahci/io/dma/lba48/double/zero
==7511==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 51 ahci-test /x86_64/ahci/io/dma/lba48/double/low
==7517==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 52 ahci-test /x86_64/ahci/io/dma/lba48/double/high
==7523==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7523==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fff910b6000; bottom 0x7fa0e6bfd000; size: 0x005eaa4b9000 (406584004608)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 53 ahci-test /x86_64/ahci/io/dma/lba48/long/zero
==7530==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7530==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffe59690000; bottom 0x7fe027923000; size: 0x001e31d6d000 (129685180416)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 54 ahci-test /x86_64/ahci/io/dma/lba48/long/low
==7537==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7537==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fff5334b000; bottom 0x7f3634b23000; size: 0x00c91e828000 (863800295424)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 55 ahci-test /x86_64/ahci/io/dma/lba48/long/high
==7544==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 56 ahci-test /x86_64/ahci/io/dma/lba48/short/zero
==7550==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 57 ahci-test /x86_64/ahci/io/dma/lba48/short/low
==7556==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 58 ahci-test /x86_64/ahci/io/dma/lba48/short/high
==7562==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 59 ahci-test /x86_64/ahci/io/ncq/simple
==7568==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 60 ahci-test /x86_64/ahci/io/ncq/retry
==7574==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 61 ahci-test /x86_64/ahci/flush/simple
==7580==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 62 ahci-test /x86_64/ahci/flush/retry
==7586==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7592==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 63 ahci-test /x86_64/ahci/flush/migrate
==7600==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7606==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 64 ahci-test /x86_64/ahci/migrate/sanity
==7614==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7620==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 65 ahci-test /x86_64/ahci/migrate/dma/simple
==7628==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7634==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-bufferiszero /cutils/bufferiszero
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} tests/test-uuid -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-uuid"
PASS 1 test-uuid /uuid/is_null
---
PASS 21 test-qgraph /qgraph/test_two_test_same_interface
PASS 22 test-qgraph /qgraph/test_test_in_path
PASS 23 test-qgraph /qgraph/test_double_edge
==7655==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7661==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 67 ahci-test /x86_64/ahci/migrate/ncq/simple
==7669==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7675==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 68 ahci-test /x86_64/ahci/migrate/ncq/halted
==7683==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 69 ahci-test /x86_64/ahci/cdrom/eject
==7688==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 70 ahci-test /x86_64/ahci/cdrom/dma/single
==7694==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 71 ahci-test /x86_64/ahci/cdrom/dma/multi
==7700==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 72 ahci-test /x86_64/ahci/cdrom/pio/single
==7706==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7706==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fff8b193000; bottom 0x7f95291fe000; size: 0x006a61f95000 (456910262272)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 73 ahci-test /x86_64/ahci/cdrom/pio/multi
==7712==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 74 ahci-test /x86_64/ahci/cdrom/pio/bcl
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img tests/qtest/hd-geo-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="hd-geo-test"
PASS 1 hd-geo-test /x86_64/hd-geo/ide/none
==7726==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 2 hd-geo-test /x86_64/hd-geo/ide/drive/cd_0
==7732==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 3 hd-geo-test /x86_64/hd-geo/ide/drive/mbr/blank
==7738==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 4 hd-geo-test /x86_64/hd-geo/ide/drive/mbr/lba
==7744==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 5 hd-geo-test /x86_64/hd-geo/ide/drive/mbr/chs
==7750==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 6 hd-geo-test /x86_64/hd-geo/ide/device/mbr/blank
==7756==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 7 hd-geo-test /x86_64/hd-geo/ide/device/mbr/lba
==7762==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 8 hd-geo-test /x86_64/hd-geo/ide/device/mbr/chs
==7768==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 9 hd-geo-test /x86_64/hd-geo/ide/device/user/chs
==7773==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 10 hd-geo-test /x86_64/hd-geo/ide/device/user/chst
==7779==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7783==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7787==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7791==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7795==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7799==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7803==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7807==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7810==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 11 hd-geo-test /x86_64/hd-geo/override/ide
==7817==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7821==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7825==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7829==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7833==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7837==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7841==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7845==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7848==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 12 hd-geo-test /x86_64/hd-geo/override/scsi
==7855==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7859==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7863==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7867==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7871==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7875==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7879==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7883==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7886==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 13 hd-geo-test /x86_64/hd-geo/override/scsi_2_controllers
==7893==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7897==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7901==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7905==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7908==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 14 hd-geo-test /x86_64/hd-geo/override/virtio_blk
==7915==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7919==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7922==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 15 hd-geo-test /x86_64/hd-geo/override/zero_chs
==7929==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7933==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7937==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7941==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7944==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 16 hd-geo-test /x86_64/hd-geo/override/scsi_hot_unplug
==7951==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7955==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7959==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7963==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==7966==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 17 hd-geo-test /x86_64/hd-geo/override/virtio_hot_unplug
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img tests/qtest/boot-order-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="boot-order-test"
PASS 1 boot-order-test /x86_64/boot-order/pc
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8035==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/pc/FACP'
Using expected file 'tests/data/acpi/pc/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8041==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/q35/FACP'
Using expected file 'tests/data/acpi/q35/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8047==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/pc/FACP.bridge'
Looking for expected file 'tests/data/acpi/pc/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8053==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/pc/FACP.ipmikcs'
Looking for expected file 'tests/data/acpi/pc/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8059==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/pc/FACP.cphp'
Looking for expected file 'tests/data/acpi/pc/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8066==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/pc/FACP.memhp'
Looking for expected file 'tests/data/acpi/pc/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8072==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/pc/FACP.numamem'
Looking for expected file 'tests/data/acpi/pc/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8078==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/pc/FACP.dimmpxm'
Looking for expected file 'tests/data/acpi/pc/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8087==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/pc/FACP.acpihmat'
Looking for expected file 'tests/data/acpi/pc/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8094==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/q35/FACP.bridge'
Looking for expected file 'tests/data/acpi/q35/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8100==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/q35/FACP.mmio64'
Looking for expected file 'tests/data/acpi/q35/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8106==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/q35/FACP.ipmibt'
Looking for expected file 'tests/data/acpi/q35/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8112==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/q35/FACP.cphp'
Looking for expected file 'tests/data/acpi/q35/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8119==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/q35/FACP.memhp'
Looking for expected file 'tests/data/acpi/q35/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8125==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/q35/FACP.numamem'
Looking for expected file 'tests/data/acpi/q35/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8131==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/q35/FACP.dimmpxm'
Looking for expected file 'tests/data/acpi/q35/FACP'
---
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
qemu-system-x86_64: falling back to tcg
==8140==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Looking for expected file 'tests/data/acpi/q35/FACP.acpihmat'
Looking for expected file 'tests/data/acpi/q35/FACP'
---
PASS 1 i440fx-test /x86_64/i440fx/defaults
PASS 2 i440fx-test /x86_64/i440fx/pam
PASS 3 i440fx-test /x86_64/i440fx/firmware/bios
==8232==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 4 i440fx-test /x86_64/i440fx/firmware/pflash
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img tests/qtest/fw_cfg-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="fw_cfg-test"
PASS 1 fw_cfg-test /x86_64/fw_cfg/signature
---
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img tests/qtest/drive_del-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="drive_del-test"
PASS 1 drive_del-test /x86_64/drive_del/without-dev
PASS 2 drive_del-test /x86_64/drive_del/after_failed_device_add
==8325==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 3 drive_del-test /x86_64/blockdev/drive_del_device_del
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img tests/qtest/wdt_ib700-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="wdt_ib700-test"
PASS 1 wdt_ib700-test /x86_64/wdt_ib700/pause
---
dbus-daemon[8495]: Could not get password database information for UID of current process: User "???" unknown or no memory to allocate password entry
**
ERROR:/tmp/qemu-test/src/tests/qtest/dbus-vmstate-test.c:114:get_connection: assertion failed (err == NULL): The connection is closed (g-io-error-quark, 18)
ERROR - Bail out! ERROR:/tmp/qemu-test/src/tests/qtest/dbus-vmstate-test.c:114:get_connection: assertion failed (err == NULL): The connection is closed (g-io-error-quark, 18)
cleaning up pid 8495
make: *** [/tmp/qemu-test/src/tests/Makefile.include:632: check-qtest-x86_64] Error 1
make: *** Waiting for unfinished jobs....
Traceback (most recent call last):
File "./tests/docker/docker.py", line 664, in <module>
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=a0f24511df5642f59a3097aa05a1968d', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=x86_64-softmmu', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-bqkyqbus/src/docker-src.2020-03-10-14.44.05.16164:/var/tmp/qemu:z,ro', 'qemu:fedora', '/var/tmp/qemu/run', 'test-debug']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=a0f24511df5642f59a3097aa05a1968d
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-bqkyqbus/src'
make: *** [docker-run-test-debug@fedora] Error 2
real 27m58.009s
user 0m8.482s
The full log is available at
http://patchew.org/logs/20200310165332.140774-1-liran.alon@oracle.com/testing.asan/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
2020-03-10 18:09 ` Liran Alon
@ 2020-03-10 20:56 ` Michael S. Tsirkin
2020-03-10 21:29 ` Liran Alon
0 siblings, 1 reply; 27+ messages in thread
From: Michael S. Tsirkin @ 2020-03-10 20:56 UTC (permalink / raw)
To: Liran Alon; +Cc: nikita.leshchenko, ehabkost, qemu-devel, rth
On Tue, Mar 10, 2020 at 08:09:09PM +0200, Liran Alon wrote:
>
> On 10/03/2020 19:44, Michael S. Tsirkin wrote:
> > On Tue, Mar 10, 2020 at 06:53:16PM +0200, Liran Alon wrote:
> > > Hi,
> > >
> > > This series aims to fix several bugs in VMPort and improve it by supporting
> > > more VMPort commands and make command results more configurable to
> > > user via QEMU command-line.
> > >
> > > This functionality was proven to be useful to run various VMware VMs
> > > when attempting to run them as-is on top of QEMU/KVM.
> > >
> > > For more details, see commit messages.
> > Well two versions in one day and some review comments weren't addressed.
> There is a single review comment that wasn't addressed which is replacing an
> enum with a comment. And I explicitly mentioned that it's because I want
> additional opinion on this.
> I don't see why such a small thing should block review for 15 patches...
> All the rest of the comments (Which were great) have been addressed. Unless
> I have mistakenly missed something, which please point it out if I did.
OK I just took a quick peek, two things quickly jumped out at me.
version property really should be a boolean and have some documentation
saying what functionality enables.
userspace properties should use the non-abbreviated
vm-executable since vmx is easy to confuse with vm extensions.
That's just a quick look.
> > Some people do this, try to wear the maintainers out by sheer volume.
> > It works sometimes but it's not a nice tactic. I personally think it's
> > worth taking the time to think harder about ways to address all
> > comments, not try to dismiss them.
> That's not what I tried to do. I carefully fixed all comments I saw in the
> review discussion and run tests.
> The only thing which wasn't addressed is removing an enum and replacing it
> with a comment.
> The hint that I try to manipulate maintainers is disrespectful. I assume
> that this isn't your intention, as we all just want to collaborate together
> here. No need to make this a personal discussion.
>
> If you think that replacing the enum with a comment is a blocker for v2
> patch-series, I will go ahead and submit v3 with that change.
Yes IMHO it needs to be fixed but please go over the comments and try to
address them all as best you can, instead of looking for an explanation
why the comments were irrelevant and can be dismissed. Sure someone
might propose you introduce a bug, and that can't just be addressed, but
that's not the case here. Also please do not send multiple revisions of
a large patchset in a day. People need time for review.
> Is there any other comment you made on v1 patch-series you think I missed?
>
> Thanks,
> -Liran
>
> >
> > Thanks!
> >
> > > Regards,
> > > -Liran
> > >
> > > v1->v2:
> > > * Fix coding convention [Patchew Bot & MST].
> > > * Create new header file for vmport.h [MST].
> > > * Move KVM_APIC_BUS_FREQUENCY from linux-headers/asm-x86/kvm.h
> > > auto-generated header [MST]
> > > * Elaborate more that vmx-version refers to the VMware userspace
> > > VMM in commit message. [MST]
> > > * Use le32_to_cpu() on BIOS_UUID vmport command. [MST]
> > > * Introduce VMPort compatability version property to maintain migration
> > > compatibility. [MST]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
2020-03-10 20:56 ` Michael S. Tsirkin
@ 2020-03-10 21:29 ` Liran Alon
2020-03-10 21:44 ` Michael S. Tsirkin
0 siblings, 1 reply; 27+ messages in thread
From: Liran Alon @ 2020-03-10 21:29 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: nikita.leshchenko, ehabkost, qemu-devel, rth
On 10/03/2020 22:56, Michael S. Tsirkin wrote:
> On Tue, Mar 10, 2020 at 08:09:09PM +0200, Liran Alon wrote:
>> On 10/03/2020 19:44, Michael S. Tsirkin wrote:
>>> On Tue, Mar 10, 2020 at 06:53:16PM +0200, Liran Alon wrote:
>>>> Hi,
>>>>
>>>> This series aims to fix several bugs in VMPort and improve it by supporting
>>>> more VMPort commands and make command results more configurable to
>>>> user via QEMU command-line.
>>>>
>>>> This functionality was proven to be useful to run various VMware VMs
>>>> when attempting to run them as-is on top of QEMU/KVM.
>>>>
>>>> For more details, see commit messages.
>>> Well two versions in one day and some review comments weren't addressed.
>> There is a single review comment that wasn't addressed which is replacing an
>> enum with a comment. And I explicitly mentioned that it's because I want
>> additional opinion on this.
>> I don't see why such a small thing should block review for 15 patches...
>> All the rest of the comments (Which were great) have been addressed. Unless
>> I have mistakenly missed something, which please point it out if I did.
> OK I just took a quick peek, two things quickly jumped out at me.
Thanks for having a look.
>
> version property really should be a boolean and have some documentation
> saying what functionality enables.
I thought that having a version number approach is more generic and easy
to maintain going forward.
If I understand correctly, this is also the approach taken by qxl & qxl-vga.
The more elaborate alternative could have been introducing compat_flags
(As PVSCSI does) but it seems like it will pollute the property space
with a lot of useless VMPort properties.
(E.g. x-read-eax-bug, x-no-report-unsupported-cmd, x-no-report-vmx-type
and etc.).
What is the advantage of having a boolean such as "x-vmport-v2" instead
of having a single "version" property?
Will it suffice if I would just add documentation above "version"
property on what is was the functionality in "version==1"?
(Though, it's just easy to scan the vmport.c code for if's involving
">version"... "version" is more of an internal field for machine-type
compatibility and not really meant to be used by user)
Which approach do you prefer?
> userspace properties should use the non-abbreviated
> vm-executable since vmx is easy to confuse with vm extensions.
I really wish you would reconsider this. VMX is a really common term in
VMware terminology.
It is found in binary names, ".vmx" file, ".vmx" file properties, VMware
Tools prints, open-vm-tools source code and etc.
In contrast, even though I have dealt for many years with VMware
technologies, I have never known that VMX==vm-executable.
I still think it will introduce much confusion. On the other hard, I
don't see much confusing with this use of VMX with Intel VT-x
because it is only used inside vmport.c and in vmport properties names.
And the properties names match the names of the guest
code that interface with vmport in open-vm-tools source code.
If you still have a strong opinion on this, I will change it as you say
in v3... But please consider above arguments.
>
> That's just a quick look.
>
>
>>> Some people do this, try to wear the maintainers out by sheer volume.
>>> It works sometimes but it's not a nice tactic. I personally think it's
>>> worth taking the time to think harder about ways to address all
>>> comments, not try to dismiss them.
>> That's not what I tried to do. I carefully fixed all comments I saw in the
>> review discussion and run tests.
>> The only thing which wasn't addressed is removing an enum and replacing it
>> with a comment.
>> The hint that I try to manipulate maintainers is disrespectful. I assume
>> that this isn't your intention, as we all just want to collaborate together
>> here. No need to make this a personal discussion.
>>
>> If you think that replacing the enum with a comment is a blocker for v2
>> patch-series, I will go ahead and submit v3 with that change.
> Yes IMHO it needs to be fixed but please go over the comments and try to
> address them all as best you can, instead of looking for an explanation
> why the comments were irrelevant and can be dismissed.
I'm not trying to finding explanation on why the comments are irrelevant
and can be dismissed... It's not my first time contributing code to
QEMU/KVM...
> Sure someone
> might propose you introduce a bug, and that can't just be addressed, but
> that's not the case here. Also please do not send multiple revisions of
> a large patchset in a day. People need time for review.
OK. I will make note of that for next time.
I would have thought maintainers prefer to always have ability to pick
up the latest version that is ready to avoid reviewing old code that was
already discussed. Assuming all previous comments were addressed.
Thanks,
-Liran
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
2020-03-10 21:29 ` Liran Alon
@ 2020-03-10 21:44 ` Michael S. Tsirkin
2020-03-10 21:57 ` Liran Alon
0 siblings, 1 reply; 27+ messages in thread
From: Michael S. Tsirkin @ 2020-03-10 21:44 UTC (permalink / raw)
To: Liran Alon; +Cc: nikita.leshchenko, ehabkost, qemu-devel, rth
On Tue, Mar 10, 2020 at 02:29:42PM -0700, Liran Alon wrote:
>
> On 10/03/2020 22:56, Michael S. Tsirkin wrote:
> > On Tue, Mar 10, 2020 at 08:09:09PM +0200, Liran Alon wrote:
> > > On 10/03/2020 19:44, Michael S. Tsirkin wrote:
> > > > On Tue, Mar 10, 2020 at 06:53:16PM +0200, Liran Alon wrote:
> > > > > Hi,
> > > > >
> > > > > This series aims to fix several bugs in VMPort and improve it by supporting
> > > > > more VMPort commands and make command results more configurable to
> > > > > user via QEMU command-line.
> > > > >
> > > > > This functionality was proven to be useful to run various VMware VMs
> > > > > when attempting to run them as-is on top of QEMU/KVM.
> > > > >
> > > > > For more details, see commit messages.
> > > > Well two versions in one day and some review comments weren't addressed.
> > > There is a single review comment that wasn't addressed which is replacing an
> > > enum with a comment. And I explicitly mentioned that it's because I want
> > > additional opinion on this.
> > > I don't see why such a small thing should block review for 15 patches...
> > > All the rest of the comments (Which were great) have been addressed. Unless
> > > I have mistakenly missed something, which please point it out if I did.
> > OK I just took a quick peek, two things quickly jumped out at me.
> Thanks for having a look.
> >
> > version property really should be a boolean and have some documentation
> > saying what functionality enables.
> I thought that having a version number approach is more generic and easy to
> maintain going forward.
> If I understand correctly, this is also the approach taken by qxl & qxl-vga.
>
> The more elaborate alternative could have been introducing compat_flags (As
> PVSCSI does) but it seems like it will pollute the property space with a lot
> of useless VMPort properties.
> (E.g. x-read-eax-bug, x-no-report-unsupported-cmd, x-no-report-vmx-type and
> etc.).
>
> What is the advantage of having a boolean such as "x-vmport-v2" instead of
> having a single "version" property?
It's not clear what should happen going forward. Let's say version is
incremented again. This then becomes challenging for downstreams to
backport.
> Will it suffice if I would just add documentation above "version" property
> on what is was the functionality in "version==1"?
> (Though, it's just easy to scan the vmport.c code for if's involving
> ">version"... "version" is more of an internal field for machine-type
> compatibility and not really meant to be used by user)
>
> Which approach do you prefer?
I just dislike versions, they are hard to maintain.
Individual ones is cleanest imho. Self-documenting.
But if not, I'd do something like "x-vmport-fixes" and
set bits there for each bugfix.
> > userspace properties should use the non-abbreviated
> > vm-executable since vmx is easy to confuse with vm extensions.
> I really wish you would reconsider this. VMX is a really common term in
> VMware terminology.
> It is found in binary names, ".vmx" file, ".vmx" file properties, VMware
> Tools prints, open-vm-tools source code and etc.
Well that at least is easy to google.
.vmx
<vmname>.vmx
This is the primary configuration file, which stores settings
chosen in the New Virtual Machine Wizard or virtual machine settings
editor. If you created the virtual machine under an earlier version of
VMware Workstation on a Linux host, this file may have a .cfg extension
so .vmx as used here has nothing to do with VM Executable version or
type. Looks like it's just a source of confusion on the vmware
side too :)
>
> In contrast, even though I have dealt for many years with VMware
> technologies, I have never known that VMX==vm-executable.
Well you said that's what it stands for. I have no idea. From what you
say now maybe vmx basically is being used as a prefix for all things
vmware. In that case vmport-version and vmport-type or even
vmware-version and vmware-type will do just as well.
> I still think it will introduce much confusion. On the other hard, I don't
> see much confusing with this use of VMX with Intel VT-x
> because it is only used inside vmport.c and in vmport properties names. And
> the properties names match the names of the guest
> code that interface with vmport in open-vm-tools source code.
>
> If you still have a strong opinion on this, I will change it as you say in
> v3... But please consider above arguments.
I'm just saying don't use vmx. It's too late to try to give
it a different meaning. Figure out what it's supposed to
stand for and write it out in full.
> >
> > That's just a quick look.
> >
> >
> > > > Some people do this, try to wear the maintainers out by sheer volume.
> > > > It works sometimes but it's not a nice tactic. I personally think it's
> > > > worth taking the time to think harder about ways to address all
> > > > comments, not try to dismiss them.
> > > That's not what I tried to do. I carefully fixed all comments I saw in the
> > > review discussion and run tests.
> > > The only thing which wasn't addressed is removing an enum and replacing it
> > > with a comment.
> > > The hint that I try to manipulate maintainers is disrespectful. I assume
> > > that this isn't your intention, as we all just want to collaborate together
> > > here. No need to make this a personal discussion.
> > >
> > > If you think that replacing the enum with a comment is a blocker for v2
> > > patch-series, I will go ahead and submit v3 with that change.
> > Yes IMHO it needs to be fixed but please go over the comments and try to
> > address them all as best you can, instead of looking for an explanation
> > why the comments were irrelevant and can be dismissed.
>
> I'm not trying to finding explanation on why the comments are irrelevant and
> can be dismissed... It's not my first time contributing code to QEMU/KVM...
>
> > Sure someone
> > might propose you introduce a bug, and that can't just be addressed, but
> > that's not the case here. Also please do not send multiple revisions of
> > a large patchset in a day. People need time for review.
> OK. I will make note of that for next time.
> I would have thought maintainers prefer to always have ability to pick up
> the latest version that is ready to avoid reviewing old code that was
> already discussed. Assuming all previous comments were addressed.
>
> Thanks,
> -Liran
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
2020-03-10 21:44 ` Michael S. Tsirkin
@ 2020-03-10 21:57 ` Liran Alon
2020-03-10 22:00 ` Michael S. Tsirkin
0 siblings, 1 reply; 27+ messages in thread
From: Liran Alon @ 2020-03-10 21:57 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: nikita.leshchenko, ehabkost, qemu-devel, rth
On 10/03/2020 23:44, Michael S. Tsirkin wrote:
> On Tue, Mar 10, 2020 at 02:29:42PM -0700, Liran Alon wrote:
>> On 10/03/2020 22:56, Michael S. Tsirkin wrote:
>>> On Tue, Mar 10, 2020 at 08:09:09PM +0200, Liran Alon wrote:
>>>> On 10/03/2020 19:44, Michael S. Tsirkin wrote:
>>>>> On Tue, Mar 10, 2020 at 06:53:16PM +0200, Liran Alon wrote:
>>>>>> Hi,
>>>>>>
>>>>>> This series aims to fix several bugs in VMPort and improve it by supporting
>>>>>> more VMPort commands and make command results more configurable to
>>>>>> user via QEMU command-line.
>>>>>>
>>>>>> This functionality was proven to be useful to run various VMware VMs
>>>>>> when attempting to run them as-is on top of QEMU/KVM.
>>>>>>
>>>>>> For more details, see commit messages.
>>>>> Well two versions in one day and some review comments weren't addressed.
>>>> There is a single review comment that wasn't addressed which is replacing an
>>>> enum with a comment. And I explicitly mentioned that it's because I want
>>>> additional opinion on this.
>>>> I don't see why such a small thing should block review for 15 patches...
>>>> All the rest of the comments (Which were great) have been addressed. Unless
>>>> I have mistakenly missed something, which please point it out if I did.
>>> OK I just took a quick peek, two things quickly jumped out at me.
>> Thanks for having a look.
>>> version property really should be a boolean and have some documentation
>>> saying what functionality enables.
>> I thought that having a version number approach is more generic and easy to
>> maintain going forward.
>> If I understand correctly, this is also the approach taken by qxl & qxl-vga.
>>
>> The more elaborate alternative could have been introducing compat_flags (As
>> PVSCSI does) but it seems like it will pollute the property space with a lot
>> of useless VMPort properties.
>> (E.g. x-read-eax-bug, x-no-report-unsupported-cmd, x-no-report-vmx-type and
>> etc.).
>>
>> What is the advantage of having a boolean such as "x-vmport-v2" instead of
>> having a single "version" property?
> It's not clear what should happen going forward. Let's say version is
> incremented again. This then becomes challenging for downstreams to
> backport.
As all conditions are in the form of "if (s->version > X)" then
incrementing version from 1 to 2 doesn't break any condition of "if
(s->version > 1)".
What is the challenge of backporting I'm missing?
>
>> Will it suffice if I would just add documentation above "version" property
>> on what is was the functionality in "version==1"?
>> (Though, it's just easy to scan the vmport.c code for if's involving
>> ">version"... "version" is more of an internal field for machine-type
>> compatibility and not really meant to be used by user)
>>
>> Which approach do you prefer?
> I just dislike versions, they are hard to maintain.
>
> Individual ones is cleanest imho. Self-documenting.
I agree. That's the PVSCSI approach of compat_flags. Have many
properties but each define bit in a compat_flags that specifies behavior.
The disadvantage it have is that it over-complicates code and introduce
many properties that will never be used as it's just for internal
binding to machine-type.
> But if not, I'd do something like "x-vmport-fixes" and
> set bits there for each bugfix.
Hmm this could a nice and simple approach.
Will it be OK then in this case to define "x-vmport-fixes" value in
hw_compat_4_2[] to a hard-coded value (e.g. "20") without directly
encoding each individual bit via vmport.h constants?
I will note though that it seems this "x-vmport-fixes" bitmap seems to
be the first of it's kind. But I'm OK with this approach.
>
>
>>> userspace properties should use the non-abbreviated
>>> vm-executable since vmx is easy to confuse with vm extensions.
>> I really wish you would reconsider this. VMX is a really common term in
>> VMware terminology.
>> It is found in binary names, ".vmx" file, ".vmx" file properties, VMware
>> Tools prints, open-vm-tools source code and etc.
> Well that at least is easy to google.
>
> .vmx
>
> <vmname>.vmx
>
> This is the primary configuration file, which stores settings
> chosen in the New Virtual Machine Wizard or virtual machine settings
> editor. If you created the virtual machine under an earlier version of
> VMware Workstation on a Linux host, this file may have a .cfg extension
>
> so .vmx as used here has nothing to do with VM Executable version or
> type. Looks like it's just a source of confusion on the vmware
> side too :)
Well, the ".vmx" file is the configuration file for the VM given to VMX.
But I agree VMware terminology is weird. :)
>> In contrast, even though I have dealt for many years with VMware
>> technologies, I have never known that VMX==vm-executable.
> Well you said that's what it stands for. I have no idea. From what you
> say now maybe vmx basically is being used as a prefix for all things
> vmware.
No. It's just use to specify things related to VMX. i.e. The host VMM.
> In that case vmport-version and vmport-type or even
> vmware-version and vmware-type will do just as well.
vmware-version is also confusing. As one could confuse it with the
product version number.
VMware called this field "vmx-version" and "vmx-type". I don't know if
they have another field that maybe is called "vmware-version"...
>> I still think it will introduce much confusion. On the other hard, I don't
>> see much confusing with this use of VMX with Intel VT-x
>> because it is only used inside vmport.c and in vmport properties names. And
>> the properties names match the names of the guest
>> code that interface with vmport in open-vm-tools source code.
>>
>> If you still have a strong opinion on this, I will change it as you say in
>> v3... But please consider above arguments.
> I'm just saying don't use vmx. It's too late to try to give
> it a different meaning.
We are giving it here the same meaning VMware gave it. In the context of
VMware VMPort.
> Figure out what it's supposed to
> stand for and write it out in full.
VMX stands for the host VMM. But I don't see why I need to be in the
position explaining the reason behind VMware terminology.
I'm just suggesting to use it as-is to avoid confusion.
It seems you are still not convinced by above arguments, so I will
change this in v3 to what you preferred "vm-exec-version" & "vm-exec-type".
I think this is a mistake but you have the final call as the maintainer
and I accept that.
-Liran
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
2020-03-10 21:57 ` Liran Alon
@ 2020-03-10 22:00 ` Michael S. Tsirkin
2020-03-10 22:19 ` Liran Alon
0 siblings, 1 reply; 27+ messages in thread
From: Michael S. Tsirkin @ 2020-03-10 22:00 UTC (permalink / raw)
To: Liran Alon; +Cc: nikita.leshchenko, ehabkost, qemu-devel, rth
On Tue, Mar 10, 2020 at 11:57:49PM +0200, Liran Alon wrote:
>
> On 10/03/2020 23:44, Michael S. Tsirkin wrote:
> > On Tue, Mar 10, 2020 at 02:29:42PM -0700, Liran Alon wrote:
> > > On 10/03/2020 22:56, Michael S. Tsirkin wrote:
> > > > On Tue, Mar 10, 2020 at 08:09:09PM +0200, Liran Alon wrote:
> > > > > On 10/03/2020 19:44, Michael S. Tsirkin wrote:
> > > > > > On Tue, Mar 10, 2020 at 06:53:16PM +0200, Liran Alon wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > This series aims to fix several bugs in VMPort and improve it by supporting
> > > > > > > more VMPort commands and make command results more configurable to
> > > > > > > user via QEMU command-line.
> > > > > > >
> > > > > > > This functionality was proven to be useful to run various VMware VMs
> > > > > > > when attempting to run them as-is on top of QEMU/KVM.
> > > > > > >
> > > > > > > For more details, see commit messages.
> > > > > > Well two versions in one day and some review comments weren't addressed.
> > > > > There is a single review comment that wasn't addressed which is replacing an
> > > > > enum with a comment. And I explicitly mentioned that it's because I want
> > > > > additional opinion on this.
> > > > > I don't see why such a small thing should block review for 15 patches...
> > > > > All the rest of the comments (Which were great) have been addressed. Unless
> > > > > I have mistakenly missed something, which please point it out if I did.
> > > > OK I just took a quick peek, two things quickly jumped out at me.
> > > Thanks for having a look.
> > > > version property really should be a boolean and have some documentation
> > > > saying what functionality enables.
> > > I thought that having a version number approach is more generic and easy to
> > > maintain going forward.
> > > If I understand correctly, this is also the approach taken by qxl & qxl-vga.
> > >
> > > The more elaborate alternative could have been introducing compat_flags (As
> > > PVSCSI does) but it seems like it will pollute the property space with a lot
> > > of useless VMPort properties.
> > > (E.g. x-read-eax-bug, x-no-report-unsupported-cmd, x-no-report-vmx-type and
> > > etc.).
> > >
> > > What is the advantage of having a boolean such as "x-vmport-v2" instead of
> > > having a single "version" property?
> > It's not clear what should happen going forward. Let's say version is
> > incremented again. This then becomes challenging for downstreams to
> > backport.
> As all conditions are in the form of "if (s->version > X)" then incrementing
> version from 1 to 2 doesn't break any condition of "if (s->version > 1)".
> What is the challenge of backporting I'm missing?
the challenge is figuring out which parts does version apply to.
It might be easy if there's just code, harder if there's
also data, etc.
> >
> > > Will it suffice if I would just add documentation above "version" property
> > > on what is was the functionality in "version==1"?
> > > (Though, it's just easy to scan the vmport.c code for if's involving
> > > ">version"... "version" is more of an internal field for machine-type
> > > compatibility and not really meant to be used by user)
> > >
> > > Which approach do you prefer?
> > I just dislike versions, they are hard to maintain.
> >
> > Individual ones is cleanest imho. Self-documenting.
> I agree. That's the PVSCSI approach of compat_flags. Have many properties
> but each define bit in a compat_flags that specifies behavior.
> The disadvantage it have is that it over-complicates code and introduce many
> properties that will never be used as it's just for internal binding to
> machine-type.
> > But if not, I'd do something like "x-vmport-fixes" and
> > set bits there for each bugfix.
> Hmm this could a nice and simple approach.
> Will it be OK then in this case to define "x-vmport-fixes" value in
> hw_compat_4_2[] to a hard-coded value (e.g. "20") without directly encoding
> each individual bit via vmport.h constants?
Well how are you going to check a specific flag then?
> I will note though that it seems this "x-vmport-fixes" bitmap seems to be
> the first of it's kind. But I'm OK with this approach.
> >
> >
> > > > userspace properties should use the non-abbreviated
> > > > vm-executable since vmx is easy to confuse with vm extensions.
> > > I really wish you would reconsider this. VMX is a really common term in
> > > VMware terminology.
> > > It is found in binary names, ".vmx" file, ".vmx" file properties, VMware
> > > Tools prints, open-vm-tools source code and etc.
> > Well that at least is easy to google.
> >
> > .vmx
> >
> > <vmname>.vmx
> >
> > This is the primary configuration file, which stores settings
> > chosen in the New Virtual Machine Wizard or virtual machine settings
> > editor. If you created the virtual machine under an earlier version of
> > VMware Workstation on a Linux host, this file may have a .cfg extension
> >
> > so .vmx as used here has nothing to do with VM Executable version or
> > type. Looks like it's just a source of confusion on the vmware
> > side too :)
> Well, the ".vmx" file is the configuration file for the VM given to VMX. But
> I agree VMware terminology is weird. :)
> > > In contrast, even though I have dealt for many years with VMware
> > > technologies, I have never known that VMX==vm-executable.
> > Well you said that's what it stands for. I have no idea. From what you
> > say now maybe vmx basically is being used as a prefix for all things
> > vmware.
> No. It's just use to specify things related to VMX. i.e. The host VMM.
> > In that case vmport-version and vmport-type or even
> > vmware-version and vmware-type will do just as well.
> vmware-version is also confusing. As one could confuse it with the product
> version number.
> VMware called this field "vmx-version" and "vmx-type". I don't know if they
> have another field that maybe is called "vmware-version"...
> > > I still think it will introduce much confusion. On the other hard, I don't
> > > see much confusing with this use of VMX with Intel VT-x
> > > because it is only used inside vmport.c and in vmport properties names. And
> > > the properties names match the names of the guest
> > > code that interface with vmport in open-vm-tools source code.
> > >
> > > If you still have a strong opinion on this, I will change it as you say in
> > > v3... But please consider above arguments.
> > I'm just saying don't use vmx. It's too late to try to give
> > it a different meaning.
> We are giving it here the same meaning VMware gave it. In the context of
> VMware VMPort.
> > Figure out what it's supposed to
> > stand for and write it out in full.
> VMX stands for the host VMM. But I don't see why I need to be in the
> position explaining the reason behind VMware terminology.
> I'm just suggesting to use it as-is to avoid confusion.
>
> It seems you are still not convinced by above arguments, so I will change
> this in v3 to what you preferred "vm-exec-version" & "vm-exec-type".
> I think this is a mistake but you have the final call as the maintainer and
> I accept that.
>
> -Liran
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
2020-03-10 22:00 ` Michael S. Tsirkin
@ 2020-03-10 22:19 ` Liran Alon
2020-03-11 6:29 ` Michael S. Tsirkin
0 siblings, 1 reply; 27+ messages in thread
From: Liran Alon @ 2020-03-10 22:19 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: nikita.leshchenko, ehabkost, qemu-devel, rth
On 11/03/2020 0:00, Michael S. Tsirkin wrote:
> On Tue, Mar 10, 2020 at 11:57:49PM +0200, Liran Alon wrote:
>> On 10/03/2020 23:44, Michael S. Tsirkin wrote:
>>> On Tue, Mar 10, 2020 at 02:29:42PM -0700, Liran Alon wrote:
>>>> On 10/03/2020 22:56, Michael S. Tsirkin wrote:
>>>>> On Tue, Mar 10, 2020 at 08:09:09PM +0200, Liran Alon wrote:
>>>>>> On 10/03/2020 19:44, Michael S. Tsirkin wrote:
>>>>>>> On Tue, Mar 10, 2020 at 06:53:16PM +0200, Liran Alon wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> This series aims to fix several bugs in VMPort and improve it by supporting
>>>>>>>> more VMPort commands and make command results more configurable to
>>>>>>>> user via QEMU command-line.
>>>>>>>>
>>>>>>>> This functionality was proven to be useful to run various VMware VMs
>>>>>>>> when attempting to run them as-is on top of QEMU/KVM.
>>>>>>>>
>>>>>>>> For more details, see commit messages.
>>>>>>> Well two versions in one day and some review comments weren't addressed.
>>>>>> There is a single review comment that wasn't addressed which is replacing an
>>>>>> enum with a comment. And I explicitly mentioned that it's because I want
>>>>>> additional opinion on this.
>>>>>> I don't see why such a small thing should block review for 15 patches...
>>>>>> All the rest of the comments (Which were great) have been addressed. Unless
>>>>>> I have mistakenly missed something, which please point it out if I did.
>>>>> OK I just took a quick peek, two things quickly jumped out at me.
>>>> Thanks for having a look.
>>>>> version property really should be a boolean and have some documentation
>>>>> saying what functionality enables.
>>>> I thought that having a version number approach is more generic and easy to
>>>> maintain going forward.
>>>> If I understand correctly, this is also the approach taken by qxl & qxl-vga.
>>>>
>>>> The more elaborate alternative could have been introducing compat_flags (As
>>>> PVSCSI does) but it seems like it will pollute the property space with a lot
>>>> of useless VMPort properties.
>>>> (E.g. x-read-eax-bug, x-no-report-unsupported-cmd, x-no-report-vmx-type and
>>>> etc.).
>>>>
>>>> What is the advantage of having a boolean such as "x-vmport-v2" instead of
>>>> having a single "version" property?
>>> It's not clear what should happen going forward. Let's say version is
>>> incremented again. This then becomes challenging for downstreams to
>>> backport.
>> As all conditions are in the form of "if (s->version > X)" then incrementing
>> version from 1 to 2 doesn't break any condition of "if (s->version > 1)".
>> What is the challenge of backporting I'm missing?
> the challenge is figuring out which parts does version apply to.
> It might be easy if there's just code, harder if there's
> also data, etc.
You mean things such as the following?
s->some_field = (s->version > X) ? A : B;
True that it could be a bit more difficult to spot.
>>>> Will it suffice if I would just add documentation above "version" property
>>>> on what is was the functionality in "version==1"?
>>>> (Though, it's just easy to scan the vmport.c code for if's involving
>>>> ">version"... "version" is more of an internal field for machine-type
>>>> compatibility and not really meant to be used by user)
>>>>
>>>> Which approach do you prefer?
>>> I just dislike versions, they are hard to maintain.
>>>
>>> Individual ones is cleanest imho. Self-documenting.
>> I agree. That's the PVSCSI approach of compat_flags. Have many properties
>> but each define bit in a compat_flags that specifies behavior.
>> The disadvantage it have is that it over-complicates code and introduce many
>> properties that will never be used as it's just for internal binding to
>> machine-type.
>>> But if not, I'd do something like "x-vmport-fixes" and
>>> set bits there for each bugfix.
>> Hmm this could a nice and simple approach.
>> Will it be OK then in this case to define "x-vmport-fixes" value in
>> hw_compat_4_2[] to a hard-coded value (e.g. "20") without directly encoding
>> each individual bit via vmport.h constants?
> Well how are you going to check a specific flag then?
In the code itself I will have constants of course.
I meant just in hw_compat_4_2[] machine-type compat entry because the
bitmask value there should be specified as a string value.
>
>> I will note though that it seems this "x-vmport-fixes" bitmap seems to be
>> the first of it's kind. But I'm OK with this approach.
So just to be clear before implementing your suggesting approach, this
doesn't bother you right?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
2020-03-10 22:19 ` Liran Alon
@ 2020-03-11 6:29 ` Michael S. Tsirkin
0 siblings, 0 replies; 27+ messages in thread
From: Michael S. Tsirkin @ 2020-03-11 6:29 UTC (permalink / raw)
To: Liran Alon; +Cc: nikita.leshchenko, ehabkost, qemu-devel, rth
On Wed, Mar 11, 2020 at 12:19:59AM +0200, Liran Alon wrote:
>
> On 11/03/2020 0:00, Michael S. Tsirkin wrote:
> > On Tue, Mar 10, 2020 at 11:57:49PM +0200, Liran Alon wrote:
> > > On 10/03/2020 23:44, Michael S. Tsirkin wrote:
> > > > On Tue, Mar 10, 2020 at 02:29:42PM -0700, Liran Alon wrote:
> > > > > On 10/03/2020 22:56, Michael S. Tsirkin wrote:
> > > > > > On Tue, Mar 10, 2020 at 08:09:09PM +0200, Liran Alon wrote:
> > > > > > > On 10/03/2020 19:44, Michael S. Tsirkin wrote:
> > > > > > > > On Tue, Mar 10, 2020 at 06:53:16PM +0200, Liran Alon wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > This series aims to fix several bugs in VMPort and improve it by supporting
> > > > > > > > > more VMPort commands and make command results more configurable to
> > > > > > > > > user via QEMU command-line.
> > > > > > > > >
> > > > > > > > > This functionality was proven to be useful to run various VMware VMs
> > > > > > > > > when attempting to run them as-is on top of QEMU/KVM.
> > > > > > > > >
> > > > > > > > > For more details, see commit messages.
> > > > > > > > Well two versions in one day and some review comments weren't addressed.
> > > > > > > There is a single review comment that wasn't addressed which is replacing an
> > > > > > > enum with a comment. And I explicitly mentioned that it's because I want
> > > > > > > additional opinion on this.
> > > > > > > I don't see why such a small thing should block review for 15 patches...
> > > > > > > All the rest of the comments (Which were great) have been addressed. Unless
> > > > > > > I have mistakenly missed something, which please point it out if I did.
> > > > > > OK I just took a quick peek, two things quickly jumped out at me.
> > > > > Thanks for having a look.
> > > > > > version property really should be a boolean and have some documentation
> > > > > > saying what functionality enables.
> > > > > I thought that having a version number approach is more generic and easy to
> > > > > maintain going forward.
> > > > > If I understand correctly, this is also the approach taken by qxl & qxl-vga.
> > > > >
> > > > > The more elaborate alternative could have been introducing compat_flags (As
> > > > > PVSCSI does) but it seems like it will pollute the property space with a lot
> > > > > of useless VMPort properties.
> > > > > (E.g. x-read-eax-bug, x-no-report-unsupported-cmd, x-no-report-vmx-type and
> > > > > etc.).
> > > > >
> > > > > What is the advantage of having a boolean such as "x-vmport-v2" instead of
> > > > > having a single "version" property?
> > > > It's not clear what should happen going forward. Let's say version is
> > > > incremented again. This then becomes challenging for downstreams to
> > > > backport.
> > > As all conditions are in the form of "if (s->version > X)" then incrementing
> > > version from 1 to 2 doesn't break any condition of "if (s->version > 1)".
> > > What is the challenge of backporting I'm missing?
> > the challenge is figuring out which parts does version apply to.
> > It might be easy if there's just code, harder if there's
> > also data, etc.
> You mean things such as the following?
> s->some_field = (s->version > X) ? A : B;
>
> True that it could be a bit more difficult to spot.
>
> > > > > Will it suffice if I would just add documentation above "version" property
> > > > > on what is was the functionality in "version==1"?
> > > > > (Though, it's just easy to scan the vmport.c code for if's involving
> > > > > ">version"... "version" is more of an internal field for machine-type
> > > > > compatibility and not really meant to be used by user)
> > > > >
> > > > > Which approach do you prefer?
> > > > I just dislike versions, they are hard to maintain.
> > > >
> > > > Individual ones is cleanest imho. Self-documenting.
> > > I agree. That's the PVSCSI approach of compat_flags. Have many properties
> > > but each define bit in a compat_flags that specifies behavior.
> > > The disadvantage it have is that it over-complicates code and introduce many
> > > properties that will never be used as it's just for internal binding to
> > > machine-type.
> > > > But if not, I'd do something like "x-vmport-fixes" and
> > > > set bits there for each bugfix.
> > > Hmm this could a nice and simple approach.
> > > Will it be OK then in this case to define "x-vmport-fixes" value in
> > > hw_compat_4_2[] to a hard-coded value (e.g. "20") without directly encoding
> > > each individual bit via vmport.h constants?
> > Well how are you going to check a specific flag then?
> In the code itself I will have constants of course.
> I meant just in hw_compat_4_2[] machine-type compat entry because the
> bitmask value there should be specified as a string value.
> >
> > > I will note though that it seems this "x-vmport-fixes" bitmap seems to be
> > > the first of it's kind. But I'm OK with this approach.
> So just to be clear before implementing your suggesting approach, this
> doesn't bother you right?
So it would be like this:
{
"x-vmport-fixes" : "0x7" /* VMPORT_FOO | VMPORT_BAR */
}
I prefer DEFINE_PROP_BIT myself. But this version is not too terrible I
think.
--
MST
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2020-03-11 6:31 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
2020-03-10 16:53 ` [PATCH v2 01/16] hw/i386/vmport: Add device properties Liran Alon
2020-03-10 16:53 ` [PATCH v2 02/16] hw/i386/vmport: Add compatability version field Liran Alon
2020-03-10 16:53 ` [PATCH v2 03/16] hw/i386/vmport: Propagate IOPort read to vCPU EAX register Liran Alon
2020-03-10 16:53 ` [PATCH v2 04/16] hw/i386/vmport: Set EAX to -1 on failed and unsupported commands Liran Alon
2020-03-10 16:53 ` [PATCH v2 05/16] hw/i386/vmport: Introduce vmx-version property Liran Alon
2020-03-10 16:53 ` [PATCH v2 06/16] hw/i386/vmport: Report VMX type in CMD_GETVERSION Liran Alon
2020-03-10 16:53 ` [PATCH v2 07/16] hw/i386/vmport: Introduce vmport.h Liran Alon
2020-03-10 16:53 ` [PATCH v2 08/16] hw/i386/vmport: Define enum for all commands Liran Alon
2020-03-10 16:53 ` [PATCH v2 09/16] hw/i386/vmport: Add support for CMD_GETBIOSUUID Liran Alon
2020-03-10 16:53 ` [PATCH v2 10/16] hw/i386/vmport: Add support for CMD_GETTIME Liran Alon
2020-03-10 16:53 ` [PATCH v2 11/16] hw/i386/vmport: Add support for CMD_GETTIMEFULL Liran Alon
2020-03-10 16:53 ` [PATCH v2 12/16] hw/i386/vmport: Add support for CMD_GET_VCPU_INFO Liran Alon
2020-03-10 16:53 ` [PATCH v2 13/16] hw/i386/vmport: Allow x2apic without IR Liran Alon
2020-03-10 16:53 ` [PATCH v2 14/16] i386/cpu: Store LAPIC bus frequency in CPU structure Liran Alon
2020-03-10 16:53 ` [PATCH v2 15/16] hw/i386/vmport: Add support for CMD_GETHZ Liran Alon
2020-03-10 16:53 ` [PATCH v2 16/16] hw/i386/vmport: Assert vmport initialized before registering commands Liran Alon
2020-03-10 17:44 ` [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Michael S. Tsirkin
2020-03-10 18:09 ` Liran Alon
2020-03-10 20:56 ` Michael S. Tsirkin
2020-03-10 21:29 ` Liran Alon
2020-03-10 21:44 ` Michael S. Tsirkin
2020-03-10 21:57 ` Liran Alon
2020-03-10 22:00 ` Michael S. Tsirkin
2020-03-10 22:19 ` Liran Alon
2020-03-11 6:29 ` Michael S. Tsirkin
2020-03-10 19:12 ` no-reply
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.