Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: <[email protected]>
VMware has started using "vmcall" / "vmmcall" instead of an inl instruction
for the "backdoor" interface. This series detects support for those
instructions.
Outside of the platform code we use the "ALTERNATIVES" self-patching
mechanism similarly to how this is done with KVM.
Unfortunately we need two new x86 CPU feature flags for this, since we need
the default instruction to be "inl". IIRC the vmmouse driver is used by
other virtualization solutions than VMware, and those might break if
they encounter any of the other instructions.
v2:
- Address various style review comments
- Use mnemonics instead of bytecode in the ALTERNATIVE_2 macros
- Use vmcall / vmmcall also for the High-Bandwidth port calls
- Change the %edx argument to what vmcall / vmmcall expect (flags instead of
port number). The port number is added in the default ALTERNATIVE_2 path.
- Ack to merge the vmmouse patch from Dmitry.
- Drop license update for now. Will get back with a freestanding patch.
v3:
- Address more style review comments
- Improve on documentation
- Remove an unnecessarily added include
- Ack to merge the vmwgfx patch from Dave.
From: Thomas Hellstrom <[email protected]>
Vmware has historically used an "inl" instruction for this, but recent
hardware versions support using VMCALL/VMMCALL instead, so use this method
if supported at platform detection time. Explicitly code separate macro
versions since the alternatives self-patching has not been performed at
platform detection time.
Also put tighter constraints on the assembly input parameters.
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: <[email protected]>
Co-developed-by: Doug Covelli <[email protected]>
Signed-off-by: Doug Covelli <[email protected]>
Signed-off-by: Thomas Hellstrom <[email protected]>
Reviewed-by: Doug Covelli <[email protected]>
---
arch/x86/kernel/cpu/vmware.c | 88 +++++++++++++++++++++++++++++-------
1 file changed, 71 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 3c648476d4fb..757dded223af 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -34,30 +34,65 @@
#undef pr_fmt
#define pr_fmt(fmt) "vmware: " fmt
-#define CPUID_VMWARE_INFO_LEAF 0x40000000
+#define CPUID_VMWARE_INFO_LEAF 0x40000000
+#define CPUID_VMWARE_FEATURES_LEAF 0x40000010
+#define CPUID_VMWARE_FEATURES_ECX_VMMCALL BIT(0)
+#define CPUID_VMWARE_FEATURES_ECX_VMCALL BIT(1)
+
#define VMWARE_HYPERVISOR_MAGIC 0x564D5868
#define VMWARE_HYPERVISOR_PORT 0x5658
-#define VMWARE_PORT_CMD_GETVERSION 10
-#define VMWARE_PORT_CMD_GETHZ 45
-#define VMWARE_PORT_CMD_GETVCPU_INFO 68
-#define VMWARE_PORT_CMD_LEGACY_X2APIC 3
-#define VMWARE_PORT_CMD_VCPU_RESERVED 31
+#define VMWARE_CMD_GETVERSION 10
+#define VMWARE_CMD_GETHZ 45
+#define VMWARE_CMD_GETVCPU_INFO 68
+#define VMWARE_CMD_LEGACY_X2APIC 3
+#define VMWARE_CMD_VCPU_RESERVED 31
#define VMWARE_PORT(cmd, eax, ebx, ecx, edx) \
__asm__("inl (%%dx)" : \
- "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) : \
- "0"(VMWARE_HYPERVISOR_MAGIC), \
- "1"(VMWARE_PORT_CMD_##cmd), \
- "2"(VMWARE_HYPERVISOR_PORT), "3"(UINT_MAX) : \
- "memory");
+ "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) : \
+ "a"(VMWARE_HYPERVISOR_MAGIC), \
+ "c"(VMWARE_CMD_##cmd), \
+ "d"(VMWARE_HYPERVISOR_PORT), "b"(UINT_MAX) : \
+ "memory")
+
+#define VMWARE_VMCALL(cmd, eax, ebx, ecx, edx) \
+ __asm__("vmcall" : \
+ "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) : \
+ "a"(VMWARE_HYPERVISOR_MAGIC), \
+ "c"(VMWARE_CMD_##cmd), \
+ "d"(0), "b"(UINT_MAX) : \
+ "memory")
+
+#define VMWARE_VMMCALL(cmd, eax, ebx, ecx, edx) \
+ __asm__("vmmcall" : \
+ "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) : \
+ "a"(VMWARE_HYPERVISOR_MAGIC), \
+ "c"(VMWARE_CMD_##cmd), \
+ "d"(0), "b"(UINT_MAX) : \
+ "memory")
+
+#define VMWARE_CMD(cmd, eax, ebx, ecx, edx) do { \
+ switch (vmware_hypercall_mode) { \
+ case CPUID_VMWARE_FEATURES_ECX_VMCALL: \
+ VMWARE_VMCALL(cmd, eax, ebx, ecx, edx); \
+ break; \
+ case CPUID_VMWARE_FEATURES_ECX_VMMCALL: \
+ VMWARE_VMMCALL(cmd, eax, ebx, ecx, edx); \
+ break; \
+ default: \
+ VMWARE_PORT(cmd, eax, ebx, ecx, edx); \
+ break; \
+ } \
+ } while (0)
static unsigned long vmware_tsc_khz __ro_after_init;
+static u8 vmware_hypercall_mode __ro_after_init;
static inline int __vmware_platform(void)
{
uint32_t eax, ebx, ecx, edx;
- VMWARE_PORT(GETVERSION, eax, ebx, ecx, edx);
+ VMWARE_CMD(GETVERSION, eax, ebx, ecx, edx);
return eax != (uint32_t)-1 && ebx == VMWARE_HYPERVISOR_MAGIC;
}
@@ -136,7 +171,7 @@ static void __init vmware_platform_setup(void)
uint32_t eax, ebx, ecx, edx;
uint64_t lpj, tsc_khz;
- VMWARE_PORT(GETHZ, eax, ebx, ecx, edx);
+ VMWARE_CMD(GETHZ, eax, ebx, ecx, edx);
if (ebx != UINT_MAX) {
lpj = tsc_khz = eax | (((uint64_t)ebx) << 32);
@@ -174,10 +209,21 @@ static void __init vmware_platform_setup(void)
vmware_set_capabilities();
}
+static u8 vmware_select_hypercall(void)
+{
+ int eax, ebx, ecx, edx;
+
+ cpuid(CPUID_VMWARE_FEATURES_LEAF, &eax, &ebx, &ecx, &edx);
+ return (ecx & (CPUID_VMWARE_FEATURES_ECX_VMMCALL |
+ CPUID_VMWARE_FEATURES_ECX_VMCALL));
+}
+
/*
* While checking the dmi string information, just checking the product
* serial key should be enough, as this will always have a VMware
* specific string when running under VMware hypervisor.
+ * If !boot_cpu_has(X86_FEATURE_HYPERVISOR), vmware_hypercall_mode
+ * intentionally defaults to 0.
*/
static uint32_t __init vmware_platform(void)
{
@@ -187,8 +233,16 @@ static uint32_t __init vmware_platform(void)
cpuid(CPUID_VMWARE_INFO_LEAF, &eax, &hyper_vendor_id[0],
&hyper_vendor_id[1], &hyper_vendor_id[2]);
- if (!memcmp(hyper_vendor_id, "VMwareVMware", 12))
+ if (!memcmp(hyper_vendor_id, "VMwareVMware", 12)) {
+ if (eax >= CPUID_VMWARE_FEATURES_LEAF)
+ vmware_hypercall_mode =
+ vmware_select_hypercall();
+
+ pr_info("hypercall mode: 0x%02x\n",
+ (unsigned int) vmware_hypercall_mode);
+
return CPUID_VMWARE_INFO_LEAF;
+ }
} else if (dmi_available && dmi_name_in_serial("VMware") &&
__vmware_platform())
return 1;
@@ -200,9 +254,9 @@ static uint32_t __init vmware_platform(void)
static bool __init vmware_legacy_x2apic_available(void)
{
uint32_t eax, ebx, ecx, edx;
- VMWARE_PORT(GETVCPU_INFO, eax, ebx, ecx, edx);
- return (eax & (1 << VMWARE_PORT_CMD_VCPU_RESERVED)) == 0 &&
- (eax & (1 << VMWARE_PORT_CMD_LEGACY_X2APIC)) != 0;
+ VMWARE_CMD(GETVCPU_INFO, eax, ebx, ecx, edx);
+ return (eax & (1 << VMWARE_CMD_VCPU_RESERVED)) == 0 &&
+ (eax & (1 << VMWARE_CMD_LEGACY_X2APIC)) != 0;
}
const __initconst struct hypervisor_x86 x86_hyper_vmware = {
--
2.20.1
From: Thomas Hellstrom <[email protected]>
Use the definition provided by include/asm/vmware.h
CC: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: <[email protected]>
Signed-off-by: Thomas Hellstrom <[email protected]>
Reviewed-by: Doug Covelli <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
---
drivers/input/mouse/vmmouse.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index 871e5b5ab129..148245c69be7 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -16,12 +16,12 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <asm/hypervisor.h>
+#include <asm/vmware.h>
#include "psmouse.h"
#include "vmmouse.h"
#define VMMOUSE_PROTO_MAGIC 0x564D5868U
-#define VMMOUSE_PROTO_PORT 0x5658
/*
* Main commands supported by the vmmouse hypervisor port.
@@ -84,7 +84,7 @@ struct vmmouse_data {
#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
({ \
unsigned long __dummy1, __dummy2; \
- __asm__ __volatile__ ("inl %%dx" : \
+ __asm__ __volatile__ (VMWARE_HYPERCALL : \
"=a"(out1), \
"=b"(out2), \
"=c"(out3), \
@@ -94,7 +94,7 @@ struct vmmouse_data {
"a"(VMMOUSE_PROTO_MAGIC), \
"b"(in1), \
"c"(VMMOUSE_PROTO_CMD_##cmd), \
- "d"(VMMOUSE_PROTO_PORT) : \
+ "d"(0) : \
"memory"); \
})
--
2.20.1
The following commit has been merged into the x86/vmware branch of tip:
Commit-ID: f7b15c74cffd760ec9959078982d8268a38456c4
Gitweb: https://git.kernel.org/tip/f7b15c74cffd760ec9959078982d8268a38456c4
Author: Thomas Hellstrom <[email protected]>
AuthorDate: Wed, 28 Aug 2019 10:03:53 +02:00
Committer: Borislav Petkov <[email protected]>
CommitterDate: Wed, 28 Aug 2019 13:43:01 +02:00
input/vmmouse: Update the backdoor call with support for new instructions
Use the definition provided by include/asm/vmware.h.
Signed-off-by: Thomas Hellstrom <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Doug Covelli <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: [email protected]
Cc: Thomas Gleixner <[email protected]>
Cc: VMware Graphics <[email protected]>
Cc: <[email protected]>
Cc: x86-ml <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
---
drivers/input/mouse/vmmouse.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index 871e5b5..148245c 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -16,12 +16,12 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <asm/hypervisor.h>
+#include <asm/vmware.h>
#include "psmouse.h"
#include "vmmouse.h"
#define VMMOUSE_PROTO_MAGIC 0x564D5868U
-#define VMMOUSE_PROTO_PORT 0x5658
/*
* Main commands supported by the vmmouse hypervisor port.
@@ -84,7 +84,7 @@ struct vmmouse_data {
#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
({ \
unsigned long __dummy1, __dummy2; \
- __asm__ __volatile__ ("inl %%dx" : \
+ __asm__ __volatile__ (VMWARE_HYPERCALL : \
"=a"(out1), \
"=b"(out2), \
"=c"(out3), \
@@ -94,7 +94,7 @@ struct vmmouse_data {
"a"(VMMOUSE_PROTO_MAGIC), \
"b"(in1), \
"c"(VMMOUSE_PROTO_CMD_##cmd), \
- "d"(VMMOUSE_PROTO_PORT) : \
+ "d"(0) : \
"memory"); \
})
The following commit has been merged into the x86/vmware branch of tip:
Commit-ID: bac7b4e843232a3a49a042410cf743341eb0887e
Gitweb: https://git.kernel.org/tip/bac7b4e843232a3a49a042410cf743341eb0887e
Author: Thomas Hellstrom <[email protected]>
AuthorDate: Wed, 28 Aug 2019 10:03:50 +02:00
Committer: Borislav Petkov <[email protected]>
CommitterDate: Wed, 28 Aug 2019 10:48:30 +02:00
x86/vmware: Update platform detection code for VMCALL/VMMCALL hypercalls
Vmware has historically used an INL instruction for this, but recent
hardware versions support using VMCALL/VMMCALL instead, so use this
method if supported at platform detection time. Explicitly code separate
macro versions since the alternatives self-patching has not been
performed at platform detection time.
Also put tighter constraints on the assembly input parameters.
Co-developed-by: Doug Covelli <[email protected]>
Signed-off-by: Doug Covelli <[email protected]>
Signed-off-by: Thomas Hellstrom <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Doug Covelli <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: [email protected]
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: <[email protected]>
Cc: x86-ml <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
---
arch/x86/kernel/cpu/vmware.c | 88 ++++++++++++++++++++++++++++-------
1 file changed, 71 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 3c64847..757dded 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -34,30 +34,65 @@
#undef pr_fmt
#define pr_fmt(fmt) "vmware: " fmt
-#define CPUID_VMWARE_INFO_LEAF 0x40000000
+#define CPUID_VMWARE_INFO_LEAF 0x40000000
+#define CPUID_VMWARE_FEATURES_LEAF 0x40000010
+#define CPUID_VMWARE_FEATURES_ECX_VMMCALL BIT(0)
+#define CPUID_VMWARE_FEATURES_ECX_VMCALL BIT(1)
+
#define VMWARE_HYPERVISOR_MAGIC 0x564D5868
#define VMWARE_HYPERVISOR_PORT 0x5658
-#define VMWARE_PORT_CMD_GETVERSION 10
-#define VMWARE_PORT_CMD_GETHZ 45
-#define VMWARE_PORT_CMD_GETVCPU_INFO 68
-#define VMWARE_PORT_CMD_LEGACY_X2APIC 3
-#define VMWARE_PORT_CMD_VCPU_RESERVED 31
+#define VMWARE_CMD_GETVERSION 10
+#define VMWARE_CMD_GETHZ 45
+#define VMWARE_CMD_GETVCPU_INFO 68
+#define VMWARE_CMD_LEGACY_X2APIC 3
+#define VMWARE_CMD_VCPU_RESERVED 31
#define VMWARE_PORT(cmd, eax, ebx, ecx, edx) \
__asm__("inl (%%dx)" : \
- "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) : \
- "0"(VMWARE_HYPERVISOR_MAGIC), \
- "1"(VMWARE_PORT_CMD_##cmd), \
- "2"(VMWARE_HYPERVISOR_PORT), "3"(UINT_MAX) : \
- "memory");
+ "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) : \
+ "a"(VMWARE_HYPERVISOR_MAGIC), \
+ "c"(VMWARE_CMD_##cmd), \
+ "d"(VMWARE_HYPERVISOR_PORT), "b"(UINT_MAX) : \
+ "memory")
+
+#define VMWARE_VMCALL(cmd, eax, ebx, ecx, edx) \
+ __asm__("vmcall" : \
+ "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) : \
+ "a"(VMWARE_HYPERVISOR_MAGIC), \
+ "c"(VMWARE_CMD_##cmd), \
+ "d"(0), "b"(UINT_MAX) : \
+ "memory")
+
+#define VMWARE_VMMCALL(cmd, eax, ebx, ecx, edx) \
+ __asm__("vmmcall" : \
+ "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) : \
+ "a"(VMWARE_HYPERVISOR_MAGIC), \
+ "c"(VMWARE_CMD_##cmd), \
+ "d"(0), "b"(UINT_MAX) : \
+ "memory")
+
+#define VMWARE_CMD(cmd, eax, ebx, ecx, edx) do { \
+ switch (vmware_hypercall_mode) { \
+ case CPUID_VMWARE_FEATURES_ECX_VMCALL: \
+ VMWARE_VMCALL(cmd, eax, ebx, ecx, edx); \
+ break; \
+ case CPUID_VMWARE_FEATURES_ECX_VMMCALL: \
+ VMWARE_VMMCALL(cmd, eax, ebx, ecx, edx); \
+ break; \
+ default: \
+ VMWARE_PORT(cmd, eax, ebx, ecx, edx); \
+ break; \
+ } \
+ } while (0)
static unsigned long vmware_tsc_khz __ro_after_init;
+static u8 vmware_hypercall_mode __ro_after_init;
static inline int __vmware_platform(void)
{
uint32_t eax, ebx, ecx, edx;
- VMWARE_PORT(GETVERSION, eax, ebx, ecx, edx);
+ VMWARE_CMD(GETVERSION, eax, ebx, ecx, edx);
return eax != (uint32_t)-1 && ebx == VMWARE_HYPERVISOR_MAGIC;
}
@@ -136,7 +171,7 @@ static void __init vmware_platform_setup(void)
uint32_t eax, ebx, ecx, edx;
uint64_t lpj, tsc_khz;
- VMWARE_PORT(GETHZ, eax, ebx, ecx, edx);
+ VMWARE_CMD(GETHZ, eax, ebx, ecx, edx);
if (ebx != UINT_MAX) {
lpj = tsc_khz = eax | (((uint64_t)ebx) << 32);
@@ -174,10 +209,21 @@ static void __init vmware_platform_setup(void)
vmware_set_capabilities();
}
+static u8 vmware_select_hypercall(void)
+{
+ int eax, ebx, ecx, edx;
+
+ cpuid(CPUID_VMWARE_FEATURES_LEAF, &eax, &ebx, &ecx, &edx);
+ return (ecx & (CPUID_VMWARE_FEATURES_ECX_VMMCALL |
+ CPUID_VMWARE_FEATURES_ECX_VMCALL));
+}
+
/*
* While checking the dmi string information, just checking the product
* serial key should be enough, as this will always have a VMware
* specific string when running under VMware hypervisor.
+ * If !boot_cpu_has(X86_FEATURE_HYPERVISOR), vmware_hypercall_mode
+ * intentionally defaults to 0.
*/
static uint32_t __init vmware_platform(void)
{
@@ -187,8 +233,16 @@ static uint32_t __init vmware_platform(void)
cpuid(CPUID_VMWARE_INFO_LEAF, &eax, &hyper_vendor_id[0],
&hyper_vendor_id[1], &hyper_vendor_id[2]);
- if (!memcmp(hyper_vendor_id, "VMwareVMware", 12))
+ if (!memcmp(hyper_vendor_id, "VMwareVMware", 12)) {
+ if (eax >= CPUID_VMWARE_FEATURES_LEAF)
+ vmware_hypercall_mode =
+ vmware_select_hypercall();
+
+ pr_info("hypercall mode: 0x%02x\n",
+ (unsigned int) vmware_hypercall_mode);
+
return CPUID_VMWARE_INFO_LEAF;
+ }
} else if (dmi_available && dmi_name_in_serial("VMware") &&
__vmware_platform())
return 1;
@@ -200,9 +254,9 @@ static uint32_t __init vmware_platform(void)
static bool __init vmware_legacy_x2apic_available(void)
{
uint32_t eax, ebx, ecx, edx;
- VMWARE_PORT(GETVCPU_INFO, eax, ebx, ecx, edx);
- return (eax & (1 << VMWARE_PORT_CMD_VCPU_RESERVED)) == 0 &&
- (eax & (1 << VMWARE_PORT_CMD_LEGACY_X2APIC)) != 0;
+ VMWARE_CMD(GETVCPU_INFO, eax, ebx, ecx, edx);
+ return (eax & (1 << VMWARE_CMD_VCPU_RESERVED)) == 0 &&
+ (eax & (1 << VMWARE_CMD_LEGACY_X2APIC)) != 0;
}
const __initconst struct hypervisor_x86 x86_hyper_vmware = {
Hi tip-bot2,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc6 next-20190829]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/tip-bot2-for-Thomas-Hellstrom/input-vmmouse-Update-the-backdoor-call-with-support-for-new-instructions/20190829-205315
config: x86_64-randconfig-s0-08291619 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.2-10+deb8u1) 4.9.2
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <[email protected]>
All errors (new ones prefixed by >>):
>> drivers/input/mouse/vmmouse.c:19:24: fatal error: asm/vmware.h: No such file or directory
#include <asm/vmware.h>
^
compilation terminated.
vim +19 drivers/input/mouse/vmmouse.c
> 19 #include <asm/vmware.h>
20
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On Fri, Aug 30, 2019 at 12:01:48AM +0800, kbuild test robot wrote:
> Hi tip-bot2,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3-rc6 next-20190829]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
Yes, it looks like it.
> url: https://github.com/0day-ci/linux/commits/tip-bot2-for-Thomas-Hellstrom/input-vmmouse-Update-the-backdoor-call-with-support-for-new-instructions/20190829-205315
This patch is part of a series which are here:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/vmware
so you need the patches before it.
I don't know what you guys are doing to track patches but if you really
wanna test trees, I'd suggest simply testing TIP's tip/master branch
which gets redone on a daily basis instead of testing patches in the
tip-bot{,2} notification mails.
Thx.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 247165, AG München
On Thu, Aug 29, 2019 at 06:33:53PM +0200, Borislav Petkov wrote:
> On Fri, Aug 30, 2019 at 12:01:48AM +0800, kbuild test robot wrote:
> > Hi tip-bot2,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on linus/master]
> > [cannot apply to v5.3-rc6 next-20190829]
> > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> Yes, it looks like it.
>
> > url: https://github.com/0day-ci/linux/commits/tip-bot2-for-Thomas-Hellstrom/input-vmmouse-Update-the-backdoor-call-with-support-for-new-instructions/20190829-205315
>
> This patch is part of a series which are here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/vmware
>
> so you need the patches before it.
>
> I don't know what you guys are doing to track patches but if you really
> wanna test trees, I'd suggest simply testing TIP's tip/master branch
> which gets redone on a daily basis instead of testing patches in the
> tip-bot{,2} notification mails.
Thanks Boris for the input. Besides the repo monitoring, we also check the patches
in mailing lists, and try to apply patch to a suitable base. Do you think we can
skip the mailing list of tip-bot{,2}?
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Software Solutions Germany GmbH, GF: Felix Imend?rffer, HRB 247165, AG M?nchen
> _______________________________________________
> kbuild-all mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/kbuild-all
Philip,
On Fri, 30 Aug 2019, Philip Li wrote:
> > wanna test trees, I'd suggest simply testing TIP's tip/master branch
> > which gets redone on a daily basis instead of testing patches in the
> > tip-bot{,2} notification mails.
>
> Thanks Boris for the input. Besides the repo monitoring, we also check the patches
> in mailing lists, and try to apply patch to a suitable base. Do you think we can
> skip the mailing list of tip-bot{,2}?
As I just explained in a reply to another random build failure caused by this.
tip-bot2 is a notification mechanism to let people know that a particular
patch has been merged into one of the tip tree branches. These mails are
also properly threaded most of the time and reply to the patch which was
sent to the mailing list.
So yes, randomly picking patches from tip-bot2 is not useful at all. The
mails contain the information to which tip branch the patch has been
applied, so the only useful information for your bot is to select the
branch which got the new patches and start testing on that one.
Thanks,
tglx
On Fri, Aug 30, 2019 at 08:06:27AM +0200, Thomas Gleixner wrote:
> Philip,
>
> On Fri, 30 Aug 2019, Philip Li wrote:
>
> > > wanna test trees, I'd suggest simply testing TIP's tip/master branch
> > > which gets redone on a daily basis instead of testing patches in the
> > > tip-bot{,2} notification mails.
> >
> > Thanks Boris for the input. Besides the repo monitoring, we also check the patches
> > in mailing lists, and try to apply patch to a suitable base. Do you think we can
> > skip the mailing list of tip-bot{,2}?
>
> As I just explained in a reply to another random build failure caused by this.
>
> tip-bot2 is a notification mechanism to let people know that a particular
> patch has been merged into one of the tip tree branches. These mails are
> also properly threaded most of the time and reply to the patch which was
> sent to the mailing list.
>
> So yes, randomly picking patches from tip-bot2 is not useful at all. The
> mails contain the information to which tip branch the patch has been
> applied, so the only useful information for your bot is to select the
> branch which got the new patches and start testing on that one.
thanks for your patience. I just realize we actually block tip-bot, but
not tip-bot2. I will update the logic to avoid this issue, and we will
keep monitor for a while to fix new issue if any.
>
> Thanks,
>
> tglx
On Fri, Aug 30, 2019 at 02:20:53PM +0800, Philip Li wrote:
> On Fri, Aug 30, 2019 at 08:06:27AM +0200, Thomas Gleixner wrote:
> > Philip,
> >
> > On Fri, 30 Aug 2019, Philip Li wrote:
> >
> > > > wanna test trees, I'd suggest simply testing TIP's tip/master branch
> > > > which gets redone on a daily basis instead of testing patches in the
> > > > tip-bot{,2} notification mails.
> > >
> > > Thanks Boris for the input. Besides the repo monitoring, we also check the patches
> > > in mailing lists, and try to apply patch to a suitable base. Do you think we can
> > > skip the mailing list of tip-bot{,2}?
> >
> > As I just explained in a reply to another random build failure caused by this.
> >
> > tip-bot2 is a notification mechanism to let people know that a particular
> > patch has been merged into one of the tip tree branches. These mails are
> > also properly threaded most of the time and reply to the patch which was
> > sent to the mailing list.
> >
> > So yes, randomly picking patches from tip-bot2 is not useful at all. The
> > mails contain the information to which tip branch the patch has been
> > applied, so the only useful information for your bot is to select the
> > branch which got the new patches and start testing on that one.
> thanks for your patience. I just realize we actually block tip-bot, but
> not tip-bot2. I will update the logic to avoid this issue, and we will
> keep monitor for a while to fix new issue if any.
BTW: the related service need some time to be upgraded after code change,
some already fetched patches will continue sending out noisy mails until
they are consumed. Sorry about this.
>
> >
> > Thanks,
> >
> > tglx
On Fri, 30 Aug 2019, Philip Li wrote:
> On Fri, Aug 30, 2019 at 02:20:53PM +0800, Philip Li wrote:
> > thanks for your patience. I just realize we actually block tip-bot, but
> > not tip-bot2. I will update the logic to avoid this issue, and we will
> > keep monitor for a while to fix new issue if any.
>
> BTW: the related service need some time to be upgraded after code change,
> some already fetched patches will continue sending out noisy mails until
> they are consumed. Sorry about this.
All good. I'll just redirect them to /dev/null.
Thanks,
tglx
On Fri, Aug 30, 2019 at 02:20:53PM +0800, Philip Li wrote:
> thanks for your patience. I just realize we actually block tip-bot, but
> not tip-bot2. I will update the logic to avoid this issue, and we will
> keep monitor for a while to fix new issue if any.
... and just to reiterate: it would be a *lot-lot* more useful if you
guys tested the single tip branches or the combined tip/master on a
daily basis as that is the x86 queue that goes to Linus eventually. That
is, if you do not test it already. But we don't get any "we tested this
branch" email so I'm thinking you don't...
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 10:06:50AM +0200, Borislav Petkov wrote:
> On Fri, Aug 30, 2019 at 02:20:53PM +0800, Philip Li wrote:
> > thanks for your patience. I just realize we actually block tip-bot, but
> > not tip-bot2. I will update the logic to avoid this issue, and we will
> > keep monitor for a while to fix new issue if any.
>
> ... and just to reiterate: it would be a *lot-lot* more useful if you
> guys tested the single tip branches or the combined tip/master on a
> daily basis as that is the x86 queue that goes to Linus eventually. That
yes, we monitor the repo pub/scm/linux/kernel/git/tip/tip.git, and will
send build status of head (like BUILD SUCCESS or REGRESSION), also provide
bisect report of unique error for first bad commit.
> is, if you do not test it already. But we don't get any "we tested this
> branch" email so I'm thinking you don't...
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 10:36:45PM +0800, Philip Li wrote:
> yes, we monitor the repo pub/scm/linux/kernel/git/tip/tip.git, and will
> send build status of head
... and what you call "head" is the "master" branch on that repo, right?
Just making sure you got that right.
> (like BUILD SUCCESS or REGRESSION), also provide bisect report of
> unique error for first bad commit.
Perfect!
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 04:46:28PM +0200, Borislav Petkov wrote:
> On Fri, Aug 30, 2019 at 10:36:45PM +0800, Philip Li wrote:
> > yes, we monitor the repo pub/scm/linux/kernel/git/tip/tip.git, and will
> > send build status of head
>
> ... and what you call "head" is the "master" branch on that repo, right?
Hi Boris, you are right. It is the head of monitored branch, here master branch is
one of the branches on this repo that we monitor.
Early on, there's requirement to blacklist a few branches, which is configured
as below
blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus
Except the blacklist branches, we will monitor all other branches. We also
support pull request to update the configuration or email us to update.
Refer to https://github.com/intel/lkp-tests/blob/master/repo/linux/tip.
Thanks
> Just making sure you got that right.
>
> > (like BUILD SUCCESS or REGRESSION), also provide bisect report of
> > unique error for first bad commit.
>
> Perfect!
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 11:00:02PM +0800, Philip Li wrote:
> On Fri, Aug 30, 2019 at 04:46:28PM +0200, Borislav Petkov wrote:
> > On Fri, Aug 30, 2019 at 10:36:45PM +0800, Philip Li wrote:
> > > yes, we monitor the repo pub/scm/linux/kernel/git/tip/tip.git, and will
> > > send build status of head
> >
> > ... and what you call "head" is the "master" branch on that repo, right?
> Hi Boris, you are right. It is the head of monitored branch, here master branch is
> one of the branches on this repo that we monitor.
>
> Early on, there's requirement to blacklist a few branches, which is configured
> as below
> blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus
>
> Except the blacklist branches, we will monitor all other branches. We also
> support pull request to update the configuration or email us to update.
> Refer to https://github.com/intel/lkp-tests/blob/master/repo/linux/tip.
>
> Thanks
>
> > Just making sure you got that right.
> >
> > > (like BUILD SUCCESS or REGRESSION), also provide bisect report of
> > > unique error for first bad commit.
> >
> > Perfect!
hi Boris, for the build status notification, we currently send to below
address, is it still valid? If not, can you suggest one for us?
tip build status <[email protected]>
> >
> > Thx.
> >
> > --
> > Regards/Gruss,
> > Boris.
> >
> > Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 11:00:02PM +0800, Philip Li wrote:
> Early on, there's requirement to blacklist a few branches, which is configured
> as below
> blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus
Looks about right.
> Except the blacklist branches, we will monitor all other branches.
Ok, good to know. Just as an optimization to your workflow, in case
you're interested: the tip/master branch merges all tip branches so if
you're trying to prioritize which branches to test first due to resource
constraints, I'd go with tip/master first and then, when I have free
cycles, I'd do the topic branches.
Just as an idea...
> We also support pull request to update the
> configuration or email us to update. Refer to
> https://github.com/intel/lkp-tests/blob/master/repo/linux/tip.
Ok, cool. I'll talk to tglx about it and might even send you a pull
request.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 05:06:53PM +0200, Borislav Petkov wrote:
> On Fri, Aug 30, 2019 at 11:00:02PM +0800, Philip Li wrote:
> > Early on, there's requirement to blacklist a few branches, which is configured
> > as below
> > blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus
>
> Looks about right.
>
> > Except the blacklist branches, we will monitor all other branches.
>
> Ok, good to know. Just as an optimization to your workflow, in case
> you're interested: the tip/master branch merges all tip branches so if
> you're trying to prioritize which branches to test first due to resource
> constraints, I'd go with tip/master first and then, when I have free
> cycles, I'd do the topic branches.
thanks a lot for the advice. Meanwhile, the internal logic merges branches
to test once to speed up, most of time, more branches will not increase the
build testing workload. Of course, for the non merged branches, we need
test individually, and we will take this information into consideration
to add to our TODO.
>
> Just as an idea...
>
> > We also support pull request to update the
> > configuration or email us to update. Refer to
> > https://github.com/intel/lkp-tests/blob/master/repo/linux/tip.
>
> Ok, cool. I'll talk to tglx about it and might even send you a pull
> request.
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 11:08:56PM +0800, Philip Li wrote:
> hi Boris, for the build status notification, we currently send to below
> address, is it still valid? If not, can you suggest one for us?
Sure, here's an update patch ontop of your master branch:
---
From: Borislav Petkov <[email protected]>
Date: Fri, 30 Aug 2019 21:33:29 +0200
Subject: [PATCH] repo/linux/tip: Update tip tree contact information
Replace hpa with Borislav and change contact mail address.
Signed-off-by: Borislav Petkov <[email protected]>
---
repo/linux/tip | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/repo/linux/tip b/repo/linux/tip
index 4fc5d88176fd..96a7dec66f97 100644
--- a/repo/linux/tip
+++ b/repo/linux/tip
@@ -2,11 +2,11 @@ url: https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip/tip.git
integration_testing_branches: auto-latest
mail_cc:
- [email protected]
-- [email protected]
+- [email protected]
owner:
- Ingo Molnar <[email protected]>
-- H. Peter Anvin <[email protected]>
- Thomas Gleixner <[email protected]>
+- Borislav Petkov <[email protected]>
subsystems:
- x86
- fpu
@@ -16,4 +16,4 @@ subsystems:
- locking
blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus
notify_build_success_branch: .*
-build_success_mail_to: tip build status <[email protected]>
+build_success_mail_to: x86-ml <[email protected]>
--
2.21.0
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 09:35:57PM +0200, Borislav Petkov wrote:
> On Fri, Aug 30, 2019 at 11:08:56PM +0800, Philip Li wrote:
> > hi Boris, for the build status notification, we currently send to below
> > address, is it still valid? If not, can you suggest one for us?
>
> Sure, here's an update patch ontop of your master branch:
Thanks Boris, it is applied, and will take effect soon.
>
> ---
> From: Borislav Petkov <[email protected]>
> Date: Fri, 30 Aug 2019 21:33:29 +0200
> Subject: [PATCH] repo/linux/tip: Update tip tree contact information
>
> Replace hpa with Borislav and change contact mail address.
>
> Signed-off-by: Borislav Petkov <[email protected]>
> ---
> repo/linux/tip | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/repo/linux/tip b/repo/linux/tip
> index 4fc5d88176fd..96a7dec66f97 100644
> --- a/repo/linux/tip
> +++ b/repo/linux/tip
> @@ -2,11 +2,11 @@ url: https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip/tip.git
> integration_testing_branches: auto-latest
> mail_cc:
> - [email protected]
> -- [email protected]
> +- [email protected]
> owner:
> - Ingo Molnar <[email protected]>
> -- H. Peter Anvin <[email protected]>
> - Thomas Gleixner <[email protected]>
> +- Borislav Petkov <[email protected]>
> subsystems:
> - x86
> - fpu
> @@ -16,4 +16,4 @@ subsystems:
> - locking
> blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus
> notify_build_success_branch: .*
> -build_success_mail_to: tip build status <[email protected]>
> +build_success_mail_to: x86-ml <[email protected]>
> --
> 2.21.0
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Sep 02, 2019 at 09:13:42AM +0800, Philip Li wrote:
> Thanks Boris, it is applied, and will take effect soon.
Seems to has taken effect. I got the first build report.
Thx!
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Sep 02, 2019 at 11:36:51AM +0200, Borislav Petkov wrote:
> On Mon, Sep 02, 2019 at 09:13:42AM +0800, Philip Li wrote:
> > Thanks Boris, it is applied, and will take effect soon.
>
> Seems to has taken effect. I got the first build report.
thanks for the info, Boris, glad to know this.
>
> Thx!
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.