[Xen-devel] [ovmf test] 141054: all pass - PUSHED
flight 141054 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/141054/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8a1305a11f3bda2d6c1ab758e4aea79ee021dd1c baseline version: ovmf adb59b633c12eae334540295092da94736bffa33 Last test of basis 141000 2019-09-04 08:59:22 Z1 days Failing since141026 2019-09-04 23:39:00 Z1 days2 attempts Testing same since 141054 2019-09-05 13:58:24 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Chasel Chiu Liming Gao Ray Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git adb59b633c..8a1305a11f 8a1305a11f3bda2d6c1ab758e4aea79ee021dd1c -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.19 test] 141040: regressions - FAIL
flight 141040 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141040/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 129313 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 Tests which are failing intermittently (not blocking): test-arm64-arm64-examine 11 examine-serial/bootloader fail pass in 140976 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linux97ab07e11fbf55c86c3758e07ab295028bf17f94 baseline version: linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d Last test of basis 129313 2018-11-02 05:39:08 Z 307 days Failing since129412 2018-11-04 14:10:15 Z 305 days 223 attempts Testing same since 140801 2019-08-29 15:55:36 Z7 days9 attempts 2499 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64
[Xen-devel] [xen-unstable-smoke test] 141068: tolerable all pass - PUSHED
flight 141068 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141068/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen d2a95f1c3ef96f47840ab172278293e55c4fc430 baseline version: xen 9676360b7ae3dc59ce0e0080769fbd6a1121d1be Last test of basis 141049 2019-09-05 13:02:28 Z0 days Testing same since 141063 2019-09-05 19:03:42 Z0 days2 attempts People who touched revisions under test: Andrew Cooper Jan Beulich jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 9676360b7a..d2a95f1c3e d2a95f1c3ef96f47840ab172278293e55c4fc430 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH -tip v3 2/2] x86: kprobes: Prohibit probing on instruction which has emulate prefix
Prohibit probing on instruction which has XEN_EMULATE_PREFIX or KVM's emulate prefix. Since that prefix is a marker for Xen and KVM, if we modify the marker by kprobe's int3, that doesn't work as expected. Signed-off-by: Masami Hiramatsu --- arch/x86/kernel/kprobes/core.c |4 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c index 43fc13c831af..4f13af7cbcdb 100644 --- a/arch/x86/kernel/kprobes/core.c +++ b/arch/x86/kernel/kprobes/core.c @@ -351,6 +351,10 @@ int __copy_instruction(u8 *dest, u8 *src, u8 *real, struct insn *insn) kernel_insn_init(insn, dest, MAX_INSN_SIZE); insn_get_length(insn); + /* We can not probe force emulate prefixed instruction */ + if (insn_has_emulate_prefix(insn)) + return 0; + /* Another subsystem puts a breakpoint, failed to recover */ if (insn->opcode.bytes[0] == BREAKPOINT_INSTRUCTION) return 0; ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH -tip v3 1/2] x86: xen: insn: Decode Xen and KVM emulate-prefix signature
Decode Xen and KVM's emulate-prefix signature by x86 insn decoder.
It is called "prefix" but actually not x86 instruction prefix, so
this adds insn.emulate_prefix_size field instead of reusing
insn.prefixes.
If x86 decoder finds a special sequence of instructions of
XEN_EMULATE_PREFIX and 'ud2a; .ascii "kvm"', it just counts the
length, set insn.emulate_prefix_size and fold it with the next
instruction. In other words, the signature and the next instruction
is treated as a single instruction.
Reported-by: Josh Poimboeuf
Signed-off-by: Masami Hiramatsu
Acked-by: Josh Poimboeuf
---
Changes in v3:
- Fix perf's check script too.
Changes in v2:
- Generalize the emulate-prefix handling not only for Xen but KVM.
- Introduce insn.emulate_prefix_size instead of using insn.prefixes.
---
arch/x86/include/asm/insn.h |6 +
arch/x86/include/asm/xen/interface.h|7 --
arch/x86/include/asm/xen/prefix.h | 10 +
arch/x86/lib/insn.c | 36 +++
tools/arch/x86/include/asm/insn.h |6 +
tools/arch/x86/include/asm/xen/prefix.h | 10 +
tools/arch/x86/lib/insn.c | 36 +++
tools/objtool/sync-check.sh |3 ++-
tools/perf/check-headers.sh |2 +-
9 files changed, 112 insertions(+), 4 deletions(-)
create mode 100644 arch/x86/include/asm/xen/prefix.h
create mode 100644 tools/arch/x86/include/asm/xen/prefix.h
diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
index 154f27be8bfc..5c1ae3eff9d4 100644
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -45,6 +45,7 @@ struct insn {
struct insn_field immediate2; /* for 64bit imm or seg16 */
};
+ int emulate_prefix_size;
insn_attr_t attr;
unsigned char opnd_bytes;
unsigned char addr_bytes;
@@ -128,6 +129,11 @@ static inline int insn_is_evex(struct insn *insn)
return (insn->vex_prefix.nbytes == 4);
}
+static inline int insn_has_emulate_prefix(struct insn *insn)
+{
+ return !!insn->emulate_prefix_size;
+}
+
/* Ensure this instruction is decoded completely */
static inline int insn_complete(struct insn *insn)
{
diff --git a/arch/x86/include/asm/xen/interface.h
b/arch/x86/include/asm/xen/interface.h
index 62ca03ef5c65..fe33a9798708 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -379,12 +379,15 @@ struct xen_pmu_arch {
* Prefix forces emulation of some non-trapping instructions.
* Currently only CPUID.
*/
+#include
+
#ifdef __ASSEMBLY__
-#define XEN_EMULATE_PREFIX .byte 0x0f,0x0b,0x78,0x65,0x6e ;
+#define XEN_EMULATE_PREFIX .byte __XEN_EMULATE_PREFIX ;
#define XEN_CPUID XEN_EMULATE_PREFIX cpuid
#else
-#define XEN_EMULATE_PREFIX ".byte 0x0f,0x0b,0x78,0x65,0x6e ; "
+#define XEN_EMULATE_PREFIX ".byte " __XEN_EMULATE_PREFIX_STR " ; "
#define XEN_CPUID XEN_EMULATE_PREFIX "cpuid"
+
#endif
#endif /* _ASM_X86_XEN_INTERFACE_H */
diff --git a/arch/x86/include/asm/xen/prefix.h
b/arch/x86/include/asm/xen/prefix.h
new file mode 100644
index ..f901be0d7a95
--- /dev/null
+++ b/arch/x86/include/asm/xen/prefix.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _TOOLS_ASM_X86_XEN_PREFIX_H
+#define _TOOLS_ASM_X86_XEN_PREFIX_H
+
+#include
+
+#define __XEN_EMULATE_PREFIX 0x0f,0x0b,0x78,0x65,0x6e
+#define __XEN_EMULATE_PREFIX_STR __stringify(__XEN_EMULATE_PREFIX)
+
+#endif
diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
index 0b5862ba6a75..b7eb50187db9 100644
--- a/arch/x86/lib/insn.c
+++ b/arch/x86/lib/insn.c
@@ -13,6 +13,9 @@
#include
#include
+/* For special Xen prefix */
+#include
+
/* Verify next sizeof(t) bytes can be on the same instruction */
#define validate_next(t, insn, n) \
((insn)->next_byte + sizeof(t) + n <= (insn)->end_kaddr)
@@ -58,6 +61,37 @@ void insn_init(struct insn *insn, const void *kaddr, int
buf_len, int x86_64)
insn->addr_bytes = 4;
}
+static const insn_byte_t xen_prefix[] = { __XEN_EMULATE_PREFIX };
+/* See handle_ud()@arch/x86/kvm/x86.c */
+static const insn_byte_t kvm_prefix[] = "\xf\xbkvm";
+
+static int __insn_get_emulate_prefix(struct insn *insn,
+const insn_byte_t *prefix, size_t len)
+{
+ size_t i;
+
+ for (i = 0; i < len; i++) {
+ if (peek_nbyte_next(insn_byte_t, insn, i) != prefix[i])
+ goto err_out;
+ }
+
+ insn->emulate_prefix_size = len;
+ insn->next_byte += len;
+
+ return 1;
+
+err_out:
+ return 0;
+}
+
+static void insn_get_emulate_prefix(struct insn *insn)
+{
+ if (__insn_get_emulate_prefix(insn, xen_prefix, sizeof(xen_prefix)))
+ return;
+
+ __insn_get_emulate_prefix(insn, kvm_prefix, sizeof(kvm_prefix));
+}
+
/**
* insn_get_prefixes - scan x86
[Xen-devel] [PATCH -tip v3 0/2] x86: kprobes: Prohibit kprobes on Xen/KVM emulate prefixes
Hi, Here is the 3rd version of patches to handle Xen/KVM emulate prefix by x86 instruction decoder. These patches allow x86 instruction decoder to decode Xen and KVM emulate prefix correctly, and prohibit kprobes to probe on it. Josh reported that the objtool can not decode such special prefixed instructions, and I found that we also have to prohibit kprobes to probe on such instruction. This series can be applied on -tip master branch which has merged Josh's objtool/perf sharing common x86 insn decoder series. In the 2nd version, I added KVM emulate prefix support and generalized the interface. (insn_has_xen_prefix -> insn_has_emulate_prefix) Also, I added insn.emulate_prefix_size for those prefixes because that prefix is NOT an x86 instruction prefix, and the next instruction of those emulate prefixes can have x86 instruction prefix. So we can not use insn.prefix for it. In this 3rd version, I just fixed tools/perf/check-headers.sh so that it can ignore the difference of xen/prefix header path. Thank you, --- Masami Hiramatsu (2): x86: xen: insn: Decode Xen and KVM emulate-prefix signature x86: kprobes: Prohibit probing on instruction which has emulate prefix arch/x86/include/asm/insn.h |6 + arch/x86/include/asm/xen/interface.h|7 -- arch/x86/include/asm/xen/prefix.h | 10 + arch/x86/kernel/kprobes/core.c |4 +++ arch/x86/lib/insn.c | 36 +++ tools/arch/x86/include/asm/insn.h |6 + tools/arch/x86/include/asm/xen/prefix.h | 10 + tools/arch/x86/lib/insn.c | 36 +++ tools/objtool/sync-check.sh |3 ++- tools/perf/check-headers.sh |2 +- 10 files changed, 116 insertions(+), 4 deletions(-) create mode 100644 arch/x86/include/asm/xen/prefix.h create mode 100644 tools/arch/x86/include/asm/xen/prefix.h -- Masami Hiramatsu (Linaro) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH -tip v2 1/2] x86: xen: insn: Decode Xen and KVM emulate-prefix signature
On Thu, 5 Sep 2019 20:13:50 -0500 Josh Poimboeuf wrote: > On Fri, Sep 06, 2019 at 09:50:19AM +0900, Masami Hiramatsu wrote: > > --- a/tools/objtool/sync-check.sh > > +++ b/tools/objtool/sync-check.sh > > @@ -4,6 +4,7 @@ > > FILES=' > > arch/x86/include/asm/inat_types.h > > arch/x86/include/asm/orc_types.h > > +arch/x86/include/asm/xen/prefix.h > > arch/x86/lib/x86-opcode-map.txt > > arch/x86/tools/gen-insn-attr-x86.awk > > ' > > @@ -46,6 +47,6 @@ done > > check arch/x86/include/asm/inat.h '-I "^#include > > [\"<]\(asm/\)*inat_types.h[\">]"' > > check arch/x86/include/asm/insn.h '-I "^#include > > [\"<]\(asm/\)*inat.h[\">]"' > > check arch/x86/lib/inat.c '-I "^#include > > [\"<]\(../include/\)*asm/insn.h[\">]"' > > -check arch/x86/lib/insn.c '-I "^#include > > [\"<]\(../include/\)*asm/in\(at\|sn\).h[\">]"' > > +check arch/x86/lib/insn.c '-I "^#include > > [\"<]\(../include/\)*asm/in\(at\|sn\).h[\">]" -I "^#include > > [\"<]\(../include/\)*asm/xen/prefix.h[\">]"' > > Unfortunately perf also has a similar sync check script: > tools/perf/check-headers.sh. So you'll also need to add the above > changes there. Oops, I thought it was integrated... OK, I'll update this patch. > > Otherwise > > Acked-by: Josh Poimboeuf Thanks! > > -- > Josh -- Masami Hiramatsu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 141036: regressions - FAIL
flight 141036 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/141036/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-examine 8 reboot fail REGR. vs. 133580 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 133580 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580 build-armhf-pvops 6 kernel-build fail REGR. vs. 133580 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13
Re: [Xen-devel] [PATCH -tip v2 1/2] x86: xen: insn: Decode Xen and KVM emulate-prefix signature
On Fri, Sep 06, 2019 at 09:50:19AM +0900, Masami Hiramatsu wrote: > --- a/tools/objtool/sync-check.sh > +++ b/tools/objtool/sync-check.sh > @@ -4,6 +4,7 @@ > FILES=' > arch/x86/include/asm/inat_types.h > arch/x86/include/asm/orc_types.h > +arch/x86/include/asm/xen/prefix.h > arch/x86/lib/x86-opcode-map.txt > arch/x86/tools/gen-insn-attr-x86.awk > ' > @@ -46,6 +47,6 @@ done > check arch/x86/include/asm/inat.h '-I "^#include > [\"<]\(asm/\)*inat_types.h[\">]"' > check arch/x86/include/asm/insn.h '-I "^#include > [\"<]\(asm/\)*inat.h[\">]"' > check arch/x86/lib/inat.c '-I "^#include > [\"<]\(../include/\)*asm/insn.h[\">]"' > -check arch/x86/lib/insn.c '-I "^#include > [\"<]\(../include/\)*asm/in\(at\|sn\).h[\">]"' > +check arch/x86/lib/insn.c '-I "^#include > [\"<]\(../include/\)*asm/in\(at\|sn\).h[\">]" -I "^#include > [\"<]\(../include/\)*asm/xen/prefix.h[\">]"' Unfortunately perf also has a similar sync check script: tools/perf/check-headers.sh. So you'll also need to add the above changes there. Otherwise Acked-by: Josh Poimboeuf -- Josh ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH -tip v2 2/2] x86: kprobes: Prohibit probing on instruction which has emulate prefix
Prohibit probing on instruction which has XEN_EMULATE_PREFIX or KVM's emulate prefix. Since that prefix is a marker for Xen and KVM, if we modify the marker by kprobe's int3, that doesn't work as expected. Signed-off-by: Masami Hiramatsu --- arch/x86/kernel/kprobes/core.c |4 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c index 43fc13c831af..4f13af7cbcdb 100644 --- a/arch/x86/kernel/kprobes/core.c +++ b/arch/x86/kernel/kprobes/core.c @@ -351,6 +351,10 @@ int __copy_instruction(u8 *dest, u8 *src, u8 *real, struct insn *insn) kernel_insn_init(insn, dest, MAX_INSN_SIZE); insn_get_length(insn); + /* We can not probe force emulate prefixed instruction */ + if (insn_has_emulate_prefix(insn)) + return 0; + /* Another subsystem puts a breakpoint, failed to recover */ if (insn->opcode.bytes[0] == BREAKPOINT_INSTRUCTION) return 0; ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH -tip v2 1/2] x86: xen: insn: Decode Xen and KVM emulate-prefix signature
Decode Xen and KVM's emulate-prefix signature by x86 insn decoder.
It is called "prefix" but actually not x86 instruction prefix, so
this adds insn.emulate_prefix_size field instead of reusing
insn.prefixes.
If x86 decoder finds a special sequence of instructions of
XEN_EMULATE_PREFIX and 'ud2a; .ascii "kvm"', it just counts the
length, set insn.emulate_prefix_size and fold it with the next
instruction. In other words, the signature and the next instruction
is treated as a single instruction.
Reported-by: Josh Poimboeuf
Signed-off-by: Masami Hiramatsu
---
Changes in v2:
- Generalize the emulate-prefix handling not only for Xen but KVM.
- Introduce insn.emulate_prefix_size instead of using insn.prefixes.
---
arch/x86/include/asm/insn.h |6 +
arch/x86/include/asm/xen/interface.h|7 --
arch/x86/include/asm/xen/prefix.h | 10 +
arch/x86/lib/insn.c | 36 +++
tools/arch/x86/include/asm/insn.h |6 +
tools/arch/x86/include/asm/xen/prefix.h | 10 +
tools/arch/x86/lib/insn.c | 36 +++
tools/objtool/sync-check.sh |3 ++-
8 files changed, 111 insertions(+), 3 deletions(-)
create mode 100644 arch/x86/include/asm/xen/prefix.h
create mode 100644 tools/arch/x86/include/asm/xen/prefix.h
diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
index 154f27be8bfc..5c1ae3eff9d4 100644
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -45,6 +45,7 @@ struct insn {
struct insn_field immediate2; /* for 64bit imm or seg16 */
};
+ int emulate_prefix_size;
insn_attr_t attr;
unsigned char opnd_bytes;
unsigned char addr_bytes;
@@ -128,6 +129,11 @@ static inline int insn_is_evex(struct insn *insn)
return (insn->vex_prefix.nbytes == 4);
}
+static inline int insn_has_emulate_prefix(struct insn *insn)
+{
+ return !!insn->emulate_prefix_size;
+}
+
/* Ensure this instruction is decoded completely */
static inline int insn_complete(struct insn *insn)
{
diff --git a/arch/x86/include/asm/xen/interface.h
b/arch/x86/include/asm/xen/interface.h
index 62ca03ef5c65..fe33a9798708 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -379,12 +379,15 @@ struct xen_pmu_arch {
* Prefix forces emulation of some non-trapping instructions.
* Currently only CPUID.
*/
+#include
+
#ifdef __ASSEMBLY__
-#define XEN_EMULATE_PREFIX .byte 0x0f,0x0b,0x78,0x65,0x6e ;
+#define XEN_EMULATE_PREFIX .byte __XEN_EMULATE_PREFIX ;
#define XEN_CPUID XEN_EMULATE_PREFIX cpuid
#else
-#define XEN_EMULATE_PREFIX ".byte 0x0f,0x0b,0x78,0x65,0x6e ; "
+#define XEN_EMULATE_PREFIX ".byte " __XEN_EMULATE_PREFIX_STR " ; "
#define XEN_CPUID XEN_EMULATE_PREFIX "cpuid"
+
#endif
#endif /* _ASM_X86_XEN_INTERFACE_H */
diff --git a/arch/x86/include/asm/xen/prefix.h
b/arch/x86/include/asm/xen/prefix.h
new file mode 100644
index ..f901be0d7a95
--- /dev/null
+++ b/arch/x86/include/asm/xen/prefix.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _TOOLS_ASM_X86_XEN_PREFIX_H
+#define _TOOLS_ASM_X86_XEN_PREFIX_H
+
+#include
+
+#define __XEN_EMULATE_PREFIX 0x0f,0x0b,0x78,0x65,0x6e
+#define __XEN_EMULATE_PREFIX_STR __stringify(__XEN_EMULATE_PREFIX)
+
+#endif
diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
index 0b5862ba6a75..b7eb50187db9 100644
--- a/arch/x86/lib/insn.c
+++ b/arch/x86/lib/insn.c
@@ -13,6 +13,9 @@
#include
#include
+/* For special Xen prefix */
+#include
+
/* Verify next sizeof(t) bytes can be on the same instruction */
#define validate_next(t, insn, n) \
((insn)->next_byte + sizeof(t) + n <= (insn)->end_kaddr)
@@ -58,6 +61,37 @@ void insn_init(struct insn *insn, const void *kaddr, int
buf_len, int x86_64)
insn->addr_bytes = 4;
}
+static const insn_byte_t xen_prefix[] = { __XEN_EMULATE_PREFIX };
+/* See handle_ud()@arch/x86/kvm/x86.c */
+static const insn_byte_t kvm_prefix[] = "\xf\xbkvm";
+
+static int __insn_get_emulate_prefix(struct insn *insn,
+const insn_byte_t *prefix, size_t len)
+{
+ size_t i;
+
+ for (i = 0; i < len; i++) {
+ if (peek_nbyte_next(insn_byte_t, insn, i) != prefix[i])
+ goto err_out;
+ }
+
+ insn->emulate_prefix_size = len;
+ insn->next_byte += len;
+
+ return 1;
+
+err_out:
+ return 0;
+}
+
+static void insn_get_emulate_prefix(struct insn *insn)
+{
+ if (__insn_get_emulate_prefix(insn, xen_prefix, sizeof(xen_prefix)))
+ return;
+
+ __insn_get_emulate_prefix(insn, kvm_prefix, sizeof(kvm_prefix));
+}
+
/**
* insn_get_prefixes - scan x86 instruction prefix bytes
* @insn: insn containing instruction
@@ -76,6 +110,8 @@ void insn_get_prefixes(struct insn
[Xen-devel] [PATCH -tip v2 0/2] x86: kprobes: Prohibit kprobes on Xen/KVM emulate prefixes
Hi, Here is the 2nd version of patches to handle Xen/KVM emulate prefix by x86 instruction decoder. These patches allow x86 instruction decoder to decode Xen and KVM emulate prefix correctly, and prohibit kprobes to probe on it. Josh reported that the objtool can not decode such special prefixed instructions, and I found that we also have to prohibit kprobes to probe on such instruction. This series can be applied on -tip master branch which has merged Josh's objtool/perf sharing common x86 insn decoder series. In this version, I added KVM emulate prefix support and generalized the interface. (insn_has_xen_prefix -> insn_has_emulate_prefix) Also, I added insn.emulate_prefix_size for those prefixes because that prefix is NOT an x86 instruction prefix, and the next instruction of those emulate prefixes can have x86 instruction prefix. So we can not use insn.prefix for it. Thank you, --- Masami Hiramatsu (2): x86: xen: insn: Decode Xen and KVM emulate-prefix signature x86: kprobes: Prohibit probing on instruction which has emulate prefix arch/x86/include/asm/insn.h |6 + arch/x86/include/asm/xen/interface.h|7 -- arch/x86/include/asm/xen/prefix.h | 10 + arch/x86/kernel/kprobes/core.c |4 +++ arch/x86/lib/insn.c | 36 +++ tools/arch/x86/include/asm/insn.h |6 + tools/arch/x86/include/asm/xen/prefix.h | 10 + tools/arch/x86/lib/insn.c | 36 +++ tools/objtool/sync-check.sh |3 ++- 9 files changed, 115 insertions(+), 3 deletions(-) create mode 100644 arch/x86/include/asm/xen/prefix.h create mode 100644 tools/arch/x86/include/asm/xen/prefix.h -- Masami Hiramatsu (Linaro) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 141045: regressions - FAIL
flight 141045 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141045/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 139910 build-amd64 6 xen-buildfail REGR. vs. 139910 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1)
[Xen-devel] Looking for Semester long Project
Hi, We (a group of 2 students) are interested in doing a hypervisor related project for the next 10-12 weeks as part of one of our courses this semester. We have taken a look at this year's GSoC project list ( https://wiki.xenproject.org/wiki/Outreach_Program_Projects). We were interested in learning more about the "KDD (Windows Debugger Stub) enhancements" project and Xen on ARM based projects. Yet, on irc we were told that this list is outdated. If there are any other project suggestions or list, we would be interesting in learning more about them. Andrew Cooper suggested on irc the following project: Context Switching with CR0.TS in HVM Guest. We would like to possible know more about this project in terms of difficulty, potential estimate on time required. Andrew also mentioned a slighter bigger xen/linux project and we would like to know more detail about this one as well. Thanks, Julian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 141063: regressions - FAIL
flight 141063 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141063/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 141049
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
version targeted for testing:
xen d2a95f1c3ef96f47840ab172278293e55c4fc430
baseline version:
xen 9676360b7ae3dc59ce0e0080769fbd6a1121d1be
Last test of basis 141049 2019-09-05 13:02:28 Z0 days
Testing same since 141063 2019-09-05 19:03:42 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
jobs:
build-arm64-xsm pass
build-amd64 fail
build-armhf pass
build-amd64-libvirt blocked
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit d2a95f1c3ef96f47840ab172278293e55c4fc430
Author: Andrew Cooper
Date: Thu Dec 27 15:14:01 2018 +
x86/AMD: Fix handling of x87 exception pointers on Fam17h hardware
AMD Pre-Fam17h CPUs "optimise" {F,}X{SAVE,RSTOR} by not saving/restoring
FOP/FIP/FDP if an x87 exception isn't pending. This causes an information
leak, CVE-2006-1056, and worked around by several OSes, including Xen. AMD
Fam17h CPUs no longer have this leak, and advertise so in a CPUID bit.
Introduce the RSTR_FP_ERR_PTRS feature, as specified by AMD, and expose to
all
guests by default. While adjusting libxl's cpuid table, add CLZERO which
looks to have been omitted previously.
Also introduce an X86_BUG bit to trigger the (F)XRSTOR workaround, and set
it
on AMD hardware where RSTR_FP_ERR_PTRS is not advertised. Optimise the
conditions for the workaround paths.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
commit 6408ae3f80287e194cd66218f28edcec939b6fca
Author: Andrew Cooper
Date: Thu Dec 27 15:13:55 2018 +
x86/feature: Generalise synth and introduce a bug word
Future changes are going to want to use cpu_bug_* in a mannor similar to
Linux. Introduce one bug word, and generalise the calculation of
NCAPINTS.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 6/6] introduce a 'passthrough' configuration option to xl.cfg...
Hi, On 9/2/19 3:50 PM, Paul Durrant wrote: ...and hence the ability to disable IOMMU mappings, and control EPT sharing. This patch introduces a new 'libxl_passthrough' enumeration into libxl_domain_create_info. The value will be set by xl either when it parses a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough hardware specified for the domain. If the value of the passthrough configuration option is 'disabled' then the XEN_DOMCTL_CDF_iommu flag will be clear in the xen_domctl_createdomain flags, thus allowing the toolstack to control whether the domain gets IOMMU mappings or not (where previously they were globally set). If the value of the passthrough configuration option is 'sync_pt' then a new 'iommu_opts' field in xen_domctl_createdomain will be set with the value XEN_DOMCTL_IOMMU_no_sharept. This will override the global default set in iommu_hap_pt_share, thus allowing the toolstack to control whether EPT sharing is used for the domain. NOTE: The 'iommu_memkb' overhead in libxl_domain_build_info will only be set to zero if passthrough is 'disabled'. It is not safe to set the overhead to zero in the 'share_pt' case because the toolstack has no means of knowing whether the hardware actually supports IOMMU page table sharing. Signed-off-by: Paul Durrant Reviewed-by: Jan Beulich --- Cc: Ian Jackson Cc: Wei Liu Cc: Andrew Cooper Cc: George Dunlap Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Anthony PERARD Cc: Christian Lindig Cc: David Scott Cc: Volodymyr Babchuk Cc: "Roger Pau Monné" Previously part of series https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html v7: - Added missing breaks - Added missing ocaml binding changes v6: - Remove the libxl_physinfo() call since it's usefulness is limited to x86 v5: - Expand xen_domctl_createdomain flags field and hence bump interface version - Fix spelling mistakes in context line --- docs/man/xl.cfg.5.pod.in| 52 +++ tools/libxl/libxl.h | 5 + tools/libxl/libxl_create.c | 9 ++ tools/libxl/libxl_types.idl | 7 ++ tools/ocaml/libs/xc/xenctrl.ml | 4 + tools/ocaml/libs/xc/xenctrl.mli | 4 + tools/ocaml/libs/xc/xenctrl_stubs.c | 15 ++- tools/xl/xl_parse.c | 140 ++-- xen/arch/arm/domain.c | 10 +- xen/arch/x86/domain.c | 2 +- xen/common/domain.c | 7 ++ xen/common/domctl.c | 13 --- xen/drivers/passthrough/iommu.c | 13 ++- xen/include/public/domctl.h | 6 +- xen/include/xen/iommu.h | 19 ++-- 15 files changed, 229 insertions(+), 77 deletions(-) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index c99d40307e..fd35685e9e 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -605,6 +605,58 @@ option should only be used with a trusted device tree. Note that the partial device tree should avoid using the phandle 65000 which is reserved by the toolstack. +=item B + +Specify whether IOMMU mappings are enabled for the domain and hence whether +it will be enabled for passthrough hardware. Valid values for this option +are: + +=over 4 + +=item B + +IOMMU mappings are disabled for the domain and so hardware may not be +passed through. + +This option is the default if no passthrough hardware is specified +in the domain's configuration. + +=item B + +This option means that IOMMU mappings will be synchronized with the +domain's P2M table as follows: + +For a PV domain, all writable pages assigned to the domain are identity +mapped by MFN in the IOMMU page table. Thus a device driver running in the +domain may program passthrough hardware for DMA using MFN values +(i.e. host/machine frame numbers) looked up in its P2M. + +For an HVM domain, all non-foreign RAM pages present in its P2M will be +mapped by GFN in the IOMMU page table. Thus a device driver running in the +domain may program passthrough hardware using GFN values (i.e. guest +physical frame numbers) without any further translation. + +This option is the default if the domain is PV and passthrough hardware +is specified in the configuration. + +This option is not available on Arm. I don't particularly like the idea to allow the user (or any external toolstack) to rely on passthrough=share_pt for Arm. This may put us in a corner if we ever support IOMMU that can't use the CPU PT (I know a few of them). It feels to me we want a "default" that can let the toolstack (or the hypervisor) to select what ever is the most suitable for the preferred way. For now default, could be aliased to share_pt for Arm in the toolstack. The point here is any toolstack built on top of libxl will not rely on passthrough=share_pt. Cheers, -- Julien Grall ___
Re: [Xen-devel] [PATCH v8 4/6] remove late (on-demand) construction of IOMMU page tables
Hi,
On 9/2/19 3:50 PM, Paul Durrant wrote:
diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
index 448a2af8fd..fd6f33312e 100644
--- a/tools/libxl/libxl_mem.c
+++ b/tools/libxl/libxl_mem.c
@@ -461,15 +461,17 @@ int libxl_domain_need_memory(libxl_ctx *ctx,
if (rc) goto out;
*need_memkb = b_info->target_memkb;
+*need_memkb += b_info->shadow_memkb + b_info->iommu_memkb;
AFAICT, iommu_memkb will be non-0 even when the IOMMU share the
page-table with the CPUs. If so, why is this required for that case?
+
switch (b_info->type) {
case LIBXL_DOMAIN_TYPE_PVH:
case LIBXL_DOMAIN_TYPE_HVM:
-*need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
+*need_memkb += LIBXL_HVM_EXTRA_MEMORY;
if (libxl_defbool_val(b_info->device_model_stubdomain))
*need_memkb += 32 * 1024;
break;
case LIBXL_DOMAIN_TYPE_PV:
-*need_memkb += b_info->shadow_memkb + LIBXL_PV_EXTRA_MEMORY;
+*need_memkb += LIBXL_PV_EXTRA_MEMORY;
break;
default:
rc = ERROR_INVAL;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index b61399ce36..d94b7453cb 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -486,6 +486,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("target_memkb",MemKB),
("video_memkb", MemKB),
("shadow_memkb",MemKB),
+("iommu_memkb", MemKB),
I think you want a corresponding LIBXL_HAVE in libxl.h to tell external
toolstack whether the field exist.
("rtc_timeoffset", uint32),
("exec_ssidref",uint32),
("exec_ssid_label", string),
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 1/6] x86/domain: remove the 'oos_off' flag
Hi Jan, On 9/2/19 4:08 PM, Jan Beulich wrote: On 02.09.2019 16:50, Paul Durrant wrote: The flag is not needed since the domain 'options' can now be tested directly. Signed-off-by: Paul Durrant In principle Reviewed-by: Jan Beulich but Julien, Stefano, I'd like to to ask for an explicit opinion of at least one of you regarding the behavior on Arm. During v7 review I did suggest that the flag being set should get rejected there. The current code is actually rejecting any combination of flags but CDF_hvm_guest | CDF_hap. So the flag is effectively rejected for Arm. However, it occurred to me that patch #2 will break domain creation on Arm as setting CDF_iommu will be prevented. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 2/6] domain: introduce XEN_DOMCTL_CDF_iommu flag
Hi,
On 9/2/19 3:50 PM, Paul Durrant wrote:
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e9d2c613e0..7dfb257c50 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -301,7 +301,8 @@ static int sanitise_domain_config(struct
xen_domctl_createdomain *config)
XEN_DOMCTL_CDF_hap |
XEN_DOMCTL_CDF_s3_integrity |
XEN_DOMCTL_CDF_oos_off |
- XEN_DOMCTL_CDF_xs_domain) )
+ XEN_DOMCTL_CDF_xs_domain |
+ XEN_DOMCTL_CDF_iommu) )
{
dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
return -EINVAL;
@@ -320,6 +321,12 @@ static int sanitise_domain_config(struct
xen_domctl_createdomain *config)
return -EINVAL;
}
+if ( (config->flags & XEN_DOMCTL_CDF_iommu) && !iommu_enabled )
+{
+dprintk(XENLOG_INFO, "IOMMU is not enabled\n");
+return -EINVAL;
+}
+
Looking at this patch again, the implementation of
arch_sanitise_domain_config() for Arm will only accepts config->flags to
be equal to CDF_hvm_guest | CDF_hap.
So after this patch, it will not be possible to create any domain when
CDF_iommu is set.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 6/6] introduce a 'passthrough' configuration option to xl.cfg...
Hi,
On 9/2/19 3:50 PM, Paul Durrant wrote:
@@ -263,9 +263,17 @@ struct domain_iommu {
DECLARE_BITMAP(features, IOMMU_FEAT_count);
/*
- * Does the guest reqire mappings to be synchonized, to maintain
- * the default dfn == pfn map. (See comment on dfn at the top of
- * include/xen/mm.h).
+ * Does the guest share HAP mapping with the IOMMU? This is always
+ * true for ARM systems and may be true for x86 systems where the
+ * the hardware is capable.
+ */
I am worried that such comment may rot over the time. For instance, if
we either add a new architecture or decide to stop sharing PT on Arm.
I vaguely recall some potential issues with the MSI doorbells that would
require us to unshare the PT when they will be supported in guest.
I would suggest to either refers to the implementation of
iommu_use_hap_pt() or drop completely the second sentence.
+bool hap_pt_share;
+
+/*
+ * Does the guest require mappings to be synchronized, to maintain
+ * the default dfn == pfn map? (See comment on dfn at the top of
+ * include/xen/mm.h). Note that hap_pt_share == false does not
+ * necessarily imply this is true.
*/
bool need_sync;
};
@@ -275,8 +283,7 @@ struct domain_iommu {
#define iommu_clear_feature(d, f) clear_bit(f, dom_iommu(d)->features)
/* Are we using the domain P2M table as its IOMMU pagetable? */
-#define iommu_use_hap_pt(d) \
-(hap_enabled(d) && is_iommu_enabled(d) && iommu_hap_pt_share)
+#define iommu_use_hap_pt(d) (dom_iommu(d)->hap_pt_share)
/* Does the IOMMU pagetable need to be kept synchronized with the P2M */
#ifdef CONFIG_HAS_PASSTHROUGH
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] x86/cpuid: Extend the cpuid= option to support all named features
For gen-cpuid.py, fix a comment describing self.names, and generate the
reverse mapping in self.values. Write out INIT_FEATURE_NAMES which maps a
string name to a bit position.
For parse_cpuid(), use cmdline_strcmp() and perform a binary search over
INIT_FEATURE_NAMES. A tweak to cmdline_strcmp() is needed to break at equals
signs as well.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v2:
* Rebase over cmdline_strcmp()
---
xen/arch/x86/cpuid.c | 75 +++---
xen/common/kernel.c| 6 ++--
xen/include/xen/lib.h | 4 +--
xen/tools/gen-cpuid.py | 22 +--
4 files changed, 71 insertions(+), 36 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index ab1a48ff90..040c087689 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -21,45 +21,62 @@ static const uint32_t deep_features[] = INIT_DEEP_FEATURES;
static int __init parse_xen_cpuid(const char *s)
{
+static const struct feature {
+const char *name;
+unsigned int bit;
+} features[] __initconst = INIT_FEATURE_NAMES, *lhs, *mid, *rhs;
const char *ss;
int val, rc = 0;
do {
+const char *feat;
+
ss = strchr(s, ',');
if ( !ss )
ss = strchr(s, '\0');
-if ( (val = parse_boolean("md-clear", s, ss)) >= 0 )
-{
-if ( !val )
-setup_clear_cpu_cap(X86_FEATURE_MD_CLEAR);
-}
-else if ( (val = parse_boolean("ibpb", s, ss)) >= 0 )
-{
-if ( !val )
-setup_clear_cpu_cap(X86_FEATURE_IBPB);
-}
-else if ( (val = parse_boolean("ibrsb", s, ss)) >= 0 )
-{
-if ( !val )
-setup_clear_cpu_cap(X86_FEATURE_IBRSB);
-}
-else if ( (val = parse_boolean("stibp", s, ss)) >= 0 )
-{
-if ( !val )
-setup_clear_cpu_cap(X86_FEATURE_STIBP);
-}
-else if ( (val = parse_boolean("l1d-flush", s, ss)) >= 0 )
-{
-if ( !val )
-setup_clear_cpu_cap(X86_FEATURE_L1D_FLUSH);
-}
-else if ( (val = parse_boolean("ssbd", s, ss)) >= 0 )
+/* Skip the 'no-' prefix for name comparisons. */
+feat = s;
+if ( strncmp(s, "no-", 3) == 0 )
+feat += 3;
+
+/* (Re)initalise lhs and rhs for binary search. */
+lhs = features;
+rhs = features + ARRAY_SIZE(features);
+
+while ( lhs < rhs )
{
-if ( !val )
-setup_clear_cpu_cap(X86_FEATURE_SSBD);
+int res;
+
+mid = lhs + (rhs - lhs) / 2;
+res = cmdline_strcmp(feat, mid->name);
+
+if ( res < 0 )
+{
+rhs = mid;
+continue;
+}
+if ( res > 0 )
+{
+lhs = mid + 1;
+continue;
+}
+
+if ( (val = parse_boolean(mid->name, s, ss)) >= 0 )
+{
+if ( !val )
+setup_clear_cpu_cap(mid->bit);
+mid = NULL;
+}
+
+break;
}
-else
+
+/*
+ * Mid being NULL means that the name and boolean were successfully
+ * identified. Everything else is an error.
+ */
+if ( mid )
rc = -EINVAL;
s = ss + 1;
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index f7628d73ce..760917dab5 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -309,10 +309,10 @@ int cmdline_strcmp(const char *frag, const char *name)
if ( res || n == '\0' )
{
/*
- * NUL in 'name' matching a comma, colon or semicolon in 'frag'
- * implies success.
+ * NUL in 'name' matching a comma, colon, semicolon or equals in
+ * 'frag' implies success.
*/
-if ( n == '\0' && (f == ',' || f == ':' || f == ';') )
+if ( n == '\0' && (f == ',' || f == ':' || f == ';' || f == '=') )
res = 0;
return res;
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index ce231c5f4f..8fbe84032d 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -85,8 +85,8 @@ int parse_boolean(const char *name, const char *s, const char
*e);
/**
* Very similar to strcmp(), but will declare a match if the NUL in 'name'
- * lines up with comma, colon or semicolon in 'frag'. Designed for picking
- * exact string matches out of a delimited command line list.
+ * lines up with comma, colon, semicolon or equals in 'frag'. Designed for
+ * picking exact string matches out of a delimited command line list.
*/
int cmdline_strcmp(const char *frag, const char *name);
diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
index 836b010751..f76e80d690 100755
--- a/xen/tools/gen-cpuid.py
Re: [Xen-devel] [PATCH v8 5/6] iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros
Hi Paul,
On 9/2/19 3:50 PM, Paul Durrant wrote:
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu options should really
be hard error on ARM (as opposed to just being ignored), so define
'iommu_hap_pt_share' to be true for ARM then then gate parsing the
command line option on '#ifndef iommu_hap_pt_share'.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Cc: Volodymyr Babchuk
Cc: "Roger Pau Monné"
Previously part of
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html
v7:
- Re-work the ARM handling of 'sharept' as suggested by Jan
- Make sure that need_iommu_pt_sync() always evaluates its argument
---
xen/drivers/passthrough/iommu.c | 8 +++-
xen/include/asm-arm/iommu.h | 3 ---
xen/include/asm-x86/iommu.h | 4
xen/include/xen/iommu.h | 19 ++-
xen/include/xen/sched.h | 6 --
5 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 4f71db95ea..aaf3b9fac0 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -49,7 +49,11 @@ int8_t __hwdom_initdata iommu_hwdom_reserved = -1;
* default until we find a good solution to resolve it.
*/
bool_t __read_mostly iommu_intpost;
-bool_t __read_mostly iommu_hap_pt_share = 1;
+
+#ifndef iommu_hap_pt_share
+bool __read_mostly iommu_hap_pt_share = true;
+#endif
+
bool_t __read_mostly iommu_debug;
bool_t __read_mostly amd_iommu_perdev_intremap = 1;
@@ -102,8 +106,10 @@ static int __init parse_iommu_param(const char *s)
iommu_hwdom_passthrough = val;
else if ( (val = parse_boolean("dom0-strict", s, ss)) >= 0 )
iommu_hwdom_strict = val;
+#ifndef iommu_hap_pt_share
else if ( (val = parse_boolean("sharept", s, ss)) >= 0 )
iommu_hap_pt_share = val;
+#endif
else
rc = -EINVAL;
diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
index 1577e83d2b..77a94b29eb 100644
--- a/xen/include/asm-arm/iommu.h
+++ b/xen/include/asm-arm/iommu.h
@@ -20,9 +20,6 @@ struct arch_iommu
void *priv;
};
-/* Always share P2M Table between the CPU and the IOMMU */
-#define iommu_use_hap_pt(d) is_iommu_enabled(d)
-
const struct iommu_ops *iommu_get_ops(void);
void iommu_set_ops(const struct iommu_ops *ops);
diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index 5071afd6a5..85741f7c96 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -86,10 +86,6 @@ struct iommu_init_ops {
extern const struct iommu_init_ops *iommu_init_ops;
-/* Are we using the domain P2M table as its IOMMU pagetable? */
-#define iommu_use_hap_pt(d) \
-(hap_enabled(d) && is_iommu_enabled(d) && iommu_hap_pt_share)
-
void iommu_update_ire_from_apic(unsigned int apic, unsigned int reg, unsigned
int value);
unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int reg);
int iommu_setup_hpet_msi(struct msi_desc *);
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 4b6871936c..87f9129b99 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -55,7 +55,13 @@ static inline bool_t dfn_eq(dfn_t x, dfn_t y)
extern bool_t iommu_enable, iommu_enabled;
extern bool_t force_iommu, iommu_verbose, iommu_igfx;
extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost;
-extern bool_t iommu_hap_pt_share;
+
+#ifdef CONFIG_ARM
+#define iommu_hap_pt_share true
+#else
+extern bool iommu_hap_pt_share;
+#endif
I don't particularly like #ifdef CONFIG_ in common header. How
about other arch? I can see two solutions:
1) Move the define in asm/iommu.h. This would require to move the
declaration a bit later and then protect as you did in iommu.c
2) Replace CONFIG_ARM with a new Kconfig selected by Arm only so far.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 3/6] use is_iommu_enabled() where appropriate...
Hi Paul, On 9/2/19 3:50 PM, Paul Durrant wrote: ...rather than testing the global iommu_enabled flag and ops pointer. Now that there is a per-domain flag indicating whether the domain is permitted to use the IOMMU (which determines whether the ops pointer will be set), many tests of the global iommu_enabled flag and ops pointer can be translated into tests of the per-domain flag. Some of the other tests of purely the global iommu_enabled flag can also be translated into tests of the per-domain flag. NOTE: The comment in iommu_share_p2m_table() is also fixed; need_iommu() disappeared some time ago. Also, whilst the style of the 'if' in flask_iommu_resource_use_perm() is fixed, I have not translated any instances of u32 into uint32_t to keep consistency. IMO such a translation would be better done globally for the source module in a separate patch. The change to the definition of iommu_call() is to keep the PV shim build happy. Without this change it will fail to compile with errors of the form: iommu.c:361:32: error: unused variable ‘hd’ [-Werror=unused-variable] const struct domain_iommu *hd = dom_iommu(d); ^~ Signed-off-by: Paul Durrant Reviewed-by: "Roger Pau Monné" Reviewed-by: Kevin Tian Acked-by: Daniel De Graaf Reviewed-by: Jan Beulich Acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 2/6] domain: introduce XEN_DOMCTL_CDF_iommu flag
Hi Paul, Apologies for the late answer. A couple of comments below. On 9/2/19 3:50 PM, Paul Durrant wrote: This patch introduces a common domain creation flag to determine whether the domain is permitted to make use of the IOMMU. Currently the flag is always set (for both dom0 and domU) if the IOMMU is globally enabled (i.e. iommu_enabled == 1). sanitise_domain_config() is modified to reject the flag if !iommu_enabled. This is not entirely correct for Arm, the flag will not be set for domU created by Xen directly (i.e dom0less). Device passthrough is not yet supported for dom0less so this is not much a concern. However, there are a series to add support for platform device passthrough (see [1]). So there are two possibilities: 1) If your series goes first, then we should at least document it in the commit message that IOMMU will be disabled for domain (other than dom0) created by Xen. 2) If your series goes second, then you (or Stefano) would have to ensure this does not break [1]. I haven't yet had the chance to review the latest version of Stefano and this patch looks in good shape. So 1) seems more suitable. Stefano would have to ensure the flags is set when doing device assignment. A new helper function, is_iommu_enabled(), is added to test the flag and iommu_domain_init() will return immediately if !is_iommu_enabled(). This is slightly different to the previous behaviour based on !iommu_enabled where the call to arch_iommu_domain_init() was made regardless, however it appears that this call was only necessary to initialize the dt_devices list for ARM such that iommu_release_dt_devices() can be called unconditionally by domain_relinquish_resources(). Adding a simple check of is_iommu_enabled() into iommu_release_dt_devices() keeps this unconditional call working. No functional change should be observed with this patch applied. Subsequent patches will allow the toolstack to control whether use of the IOMMU is enabled for a domain. NOTE: The introduction of the is_iommu_enabled() helper function might seem excessive but its use is expected to increase with subsequent patches. Also, having iommu_domain_init() bail before calling arch_iommu_domain_init() is not strictly necessary, but I think the consequent addition of the call to is_iommu_enabled() in iommu_release_dt_devices() makes the code clearer. Signed-off-by: Paul Durrant Reviewed-by: "Roger Pau Monné" Acked-by: Jan Beulich --- Cc: Christian Lindig Cc: David Scott Cc: Ian Jackson Cc: Wei Liu Cc: Andrew Cooper Cc: George Dunlap Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Volodymyr Babchuk Previously part of series https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html v7: - Add a check to verify that the toolstack has not set XEN_DOMCTL_CDF_iommu - Add missing ocaml binding changes v6: - Remove the toolstack parts as there's no nice method of testing whether the IOMMU is enabled in an architecture-neutral way v5: - Move is_iommu_enabled() check into iommu_domain_init() - Reject XEN_DOMCTL_CDF_iommu in sanitise_domain_config() if !iommu_enabled - Use evaluate_nospec() in defintion of is_iommu_enabled() --- tools/ocaml/libs/xc/xenctrl.ml| 8 +++- tools/ocaml/libs/xc/xenctrl.mli | 8 +++- xen/arch/arm/setup.c | 3 +++ xen/arch/x86/setup.c | 3 +++ xen/common/domain.c | 9 - xen/common/domctl.c | 13 + xen/drivers/passthrough/device_tree.c | 3 +++ xen/drivers/passthrough/iommu.c | 6 +++--- xen/include/public/domctl.h | 4 xen/include/xen/sched.h | 5 + 10 files changed, 56 insertions(+), 6 deletions(-) diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml index 35958b94d5..bdf3f2e395 100644 --- a/tools/ocaml/libs/xc/xenctrl.ml +++ b/tools/ocaml/libs/xc/xenctrl.ml @@ -56,7 +56,13 @@ type arch_domainconfig = | ARM of xen_arm_arch_domainconfig | X86 of xen_x86_arch_domainconfig -type domain_create_flag = CDF_HVM | CDF_HAP +type domain_create_flag = + | CDF_HVM + | CDF_HAP + | CDF_S3_INTEGRITY + | CDF_OOS_OFF + | CDF_XS_DOMAIN + | CDF_IOMMU This patch is only adding the last flag, but you are adding more here. I understand that you are just re-syncing the type with Xen. IHMO, this should belong in a separate patch as we may want to backport it. If backporting is not necessary, then the change should at least be mentioned in the commit message as this seems a bit off-topic. Cheers, [1] https://lists.xen.org/archives/html/xen-devel/2019-08/msg01974.html -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 141033: tolerable all pass - PUSHED
flight 141033 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/141033/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140964 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 140964 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt 267699a03cc38810dcd40f4ddbf864bd0dc29d4e baseline version: libvirt 147dc33b8bff09e5812a3cc396c60ab61252dec3 Last test of basis 140964 2019-09-03 04:18:49 Z2 days Failing since140996 2019-09-04 04:19:53 Z1 days2 attempts Testing same since 141033 2019-09-05 04:22:27 Z0 days1 attempts People who touched revisions under test: Cole Robinson Daniel P. Berrangé Daniel Veillard Jim Fehlig Michal Privoznik Peter Krempa jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git 147dc33b8b..267699a03c 267699a03cc38810dcd40f4ddbf864bd0dc29d4e -> xen-tested-master
Re: [Xen-devel] [PATCH v2 00/12] livepatch: new features and fixes
On Tue, Aug 27, 2019 at 08:46:12AM +, Pawel Wieczorkiewicz wrote: > This series introduces new features to the livepatch functionality as > briefly discussed during Xen Developer Summit 2019: [a] and [b]. > It also provides a few fixes and some small improvements. > > Main changes in v2: > - added new features to livepatch documentation > - added livepatch tests > - enabled Arm support for [5] > - make .modinfo optional for [11] > - fixed typos I took your patches, redid them per what I had responded on these patches (and squashed your fix for xen_expectations) and stuck them in my branch: http://xenbits.xen.org/gitweb/?p=people/konradwilk/xen.git;a=shortlog;h=refs/heads/livepatch.aws.v3 There are three extra patches that were needed for me to test on ARM32 - those are known issues and they don't block your patches. I will post them independent of your patches. From my perspective, your patches are good to go. But I believe I need: - the tools folks Ack on the libxc code changes, - and also an Ack from the REST on sysctl.h, - and Julian OK on the ARM32/ARM64 code changes which are tiny, but nonethless are his. Pawel, If I don't get to send them out by the end of the next week - feel free to grab them from my branch tree and repost them as v3. Thank you! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/boot: Don't explicitly map the VGA region as UC-
All 64-bit capable processors use PAT, and with PAT, it is explicitly permitted to have mappings with a cacheability different to MTRRs. On a native system with a real legacy VGA region, MTRRs will cause the region to be UC-. When booting virtualised, this range may be RAM and not a legacy VGA region, at which point it wants to be WB. Use WB mapping in the pagetables, such that in systems without a legacy VGA region, the RAM between 0xa and 0xc doesn't become unnecesserily UC-. However, we still must use small pages to avoid the undefined behaviour caused by superpages crossing MTRRs of different cacheability. While adjusting the pagetable construction, switch from pfn to idx for consistency with all the other construction logic. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné As a future optimisation, Xen could rewrite l2_identmap with a superpage if it finds that MTRRs are disabled. However, this probably needs to wait until Xen no longer unconditionally assumes a legacy VGA region to be present in the e820 if it finds something other than a hole --- xen/arch/x86/boot/x86_64.S | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S index 5ab24d73fc..1ca986f882 100644 --- a/xen/arch/x86/boot/x86_64.S +++ b/xen/arch/x86/boot/x86_64.S @@ -51,19 +51,13 @@ GLOBAL(stack_start) /* * Mapping of first 2 megabytes of memory. This is mapped with 4kB mappings * to avoid type conflicts with fixed-range MTRRs covering the lowest megabyte - * of physical memory. In any case the VGA hole should be mapped with type UC. - * Uses 1x 4k page. + * of physical memory. Uses 1x 4k page. */ l1_identmap: -pfn = 0 +idx = 0 .rept L1_PAGETABLE_ENTRIES -/* VGA hole (0xa-0xc) should be mapped UC-. */ -.if pfn >= 0xa0 && pfn < 0xc0 -.quad (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR_UCMINUS | MAP_SMALL_PAGES -.else -.quad (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR | MAP_SMALL_PAGES -.endif -pfn = pfn + 1 +.quad (idx << PAGE_SHIFT) | PAGE_HYPERVISOR | MAP_SMALL_PAGES +idx = idx + 1 .endr .size l1_identmap, . - l1_identmap -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.4 test] 141023: regressions - FAIL
flight 141023 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141023/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140955 REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 8 host-ping-check-xen fail in 140955 pass in 141023 test-armhf-armhf-libvirt 19 leak-check/check fail in 140955 pass in 141023 test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 140991 pass in 140955 test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 140991 pass in 141023 test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail pass in 140991 test-amd64-amd64-xl-pvshim 12 guest-startfail pass in 140991 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 140991 never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-arm64-arm64-xl-credit1 7 xen-boot fail never pass test-arm64-arm64-xl 7 xen-boot fail never pass test-arm64-arm64-xl-seattle 7 xen-boot fail never pass test-arm64-arm64-xl-xsm 7 xen-boot fail never pass test-arm64-arm64-examine 8 reboot fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 7 xen-boot fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 7 xen-boot fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-credit2 7 xen-boot fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install
Re: [Xen-devel] [PATCH v2 08/12] livepatch: Add support for inline asm hotpatching expectations
> diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
> index 6ab7f4c2d2..92a424e918 100644
> --- a/docs/misc/livepatch.pandoc
> +++ b/docs/misc/livepatch.pandoc
> @@ -300,6 +300,7 @@ which describe the functions to be patched:
> /* Added to livepatch payload version 2: */
> uint8_t applied;
> uint8_t _pad[7];
> +livepatch_expectation_t expect;
> };
>
> The size of the structure is 64 bytes on 64-bit hypervisors. It will be
^^
I also updated this to be 104 and 92 (for 32-bit).
And added:
> @@ -336,6 +337,26 @@ The version 2 of the payload adds the following fields
> to the structure:
>* `applied` tracks function's applied/reverted state. It has a boolean type
> either LIVEPATCH_FUNC_NOT_APPLIED or LIVEPATCH_FUNC_APPLIED.
>* `_pad[7]` adds padding to align to 8 bytes.
> + * `expect` is an optional structure containing expected to-be-replaced data
> +(mostly for inline asm patching). The `expect` structure format is:
> +
> +struct livepatch_expectation {
> +uint8_t enabled : 1;
> +uint8_t len : 5;
uint8_t rsv : 2;
To make it clear what the extra two bits in the bit-field should have.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 141049: tolerable all pass - PUSHED
flight 141049 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141049/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen 9676360b7ae3dc59ce0e0080769fbd6a1121d1be baseline version: xen fa8f9792befc6ca4982d191b8b1e32f70087ee9d Last test of basis 141042 2019-09-05 09:01:45 Z0 days Testing same since 141049 2019-09-05 13:02:28 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Kevin Tian jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git fa8f9792be..9676360b7a 9676360b7ae3dc59ce0e0080769fbd6a1121d1be -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [ANNOUNCE] Call for agenda items for September 5th Community Call @ 15:00 UTC
On Sep 5, 2019, at 12:12, Lars Kurth wrote: > > > We can defer the xenstoreless name service topic to the October monthly > > call. > > > > For today's call, can we discuss the previously posted high-level design > > for unification of the domB RFC with dom0less, as "domB mode" for > > disaggregation of Xen's dom0? > > > > - domB mode for dom0less (July 2019): https://lists.gt.net/xen/devel/557782 > > - domB RFC (June 2018): https://lists.gt.net/xen/devel/519367 > > I had seen this too late. Apologies > Lars Since we did cover the xenstoreless name service today, we can cover "domB mode for dom0less" in the October call. Rich___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [ANNOUNCE] Call for agenda items for September 5th Community Call @ 15:00 UTC
> We can defer the xenstoreless name service topic to the October monthly call. > > For today's call, can we discuss the previously posted high-level design for > unification of the domB RFC with dom0less, as "domB mode" for > disaggregation of Xen's dom0? > > - domB mode for dom0less (July 2019): https://lists.gt.net/xen/devel/557782 > - domB RFC (June 2018): https://lists.gt.net/xen/devel/519367 I had seen this too late. Apologies Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH -tip 0/2] x86: Prohibit kprobes on XEN_EMULATE_PREFIX
On Thu, 5 Sep 2019 14:31:56 +0100 Andrew Cooper wrote: > >>> The KVM version was added in c/s 6c86eedc206dd1f9d37a2796faa8e6f2278215d2 > > Hmm, I think I might misunderstand what the "emulate prefix"... that is not > > a prefix which replace actual prefix, but just works like an escape > > sequence. > > Thus the next instruction can have any x86 prefix, correct? > > There is a bit of history here :) > > Originally, 13 years ago, Xen invented the "Force Emulate Prefix", which > was the sequence: > > ud2a; .ascii 'xen'; cpuid > > which hit the #UD handler and was recognised as a request for > virtualised CPUID information. This was for ring-deprivileged > virtualisation, and is needed because the CPUID instruction itself > doesn't trap to the hypervisor. > > Following some security issues in our instruction emulator, I reused > this prefix with VT-x/SVM guests for testing purposes. It behaves in a > similar manner - when enabled, it is recognised in #UD exception > intercept, and causes Xen to add 5 to the instruction pointer, then > emulate the instruction starting there. > > Then various folk thought that having the same kind of ability to test > KVM's instruction emulator would be a good idea, so they borrowed the idea. > > From a behaviour point of view, it is an opaque 5 bytes which means > "break into the hypervisor, then emulate the following instruction". > > The name "prefix" is unfortunate. It was named thusly because from the > programmers point of view, it was something you put before the CPUID > instruction which wanted to be emulated. It is not related to x86 > instruction concept of a prefix. OK, then we should not use the insn->prefixes for those escape sequences. Thank you, -- Masami Hiramatsu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 141015: regressions - FAIL
flight 141015 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/141015/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail REGR. vs. 140282 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 140282 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140282 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 140282 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 140282 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 140282 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: qemuua8b5ad8e1faef0d1bb3e550530328e8ec76fe87c baseline version: qemuuafd760539308a5524accf964107cdb1d54a059e3 Last test of basis 140282 2019-08-18 05:36:51 Z 18 days Failing since140361 2019-08-19 11:36:26 Z 17 days 20 attempts Testing same since 141015 2019-09-04 17:28:44 Z0 days1 attempts People who touched revisions under test: Alberto Garcia Aleksandar Markovic Alex Bennée Alexey Kardashevskiy Andrew Jeffery Andrey Shinkevich Anthony PERARD Aurelien Jarno BALATON Zoltan Bandan Das Bastian Koppelmann Carlo Marcelo
[Xen-devel] [PATCH v2] xstate: make use_xsave non-init
LLVM code generation can attempt to load from a variable in the next
condition of an expression under certain circumstances, thus
attempting to load use_xsave regardless of the value of the bsp
variable, which leads to a page fault when the init section has
already been unmapped.
Fix this by making use_xsave non-init, thus preventing the page fault.
The LLVM bug with the discussion about this issue can be found at:
https://bugs.llvm.org/show_bug.cgi?id=39707
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/xstate.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 3293ef834f..1a2818 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -577,7 +577,11 @@ unsigned int xstate_ctxt_size(u64 xcr0)
/* Collect the information of processor's extended state */
void xstate_init(struct cpuinfo_x86 *c)
{
-static bool __initdata use_xsave = true;
+/*
+ * NB: use_xsave cannot live in initdata because llvm might optimize
+ * reading it, see: https://bugs.llvm.org/show_bug.cgi?id=39707
+ */
+static bool use_xsave = true;
boolean_param("xsave", use_xsave);
bool bsp = c == _cpu_data;
--
2.22.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 3/4] build: allow picking the env values for compiler variables
Don't force the usage of the hardcoded compiler values if those are
already set on the environment. This allows the Xen build system to
correctly pick CC/CXX values present on the environment, and fixes the
usage of those by the Gitlab CI test system.
Note that without this fix the Xen build system will completely ignore
any CC or CXX values set on the environment, and the only way to pass
a different CC or CXX is to overwrite it on the make command line.
Due to this change, Travis CI needs to be updated in order to pass a
CC and CXX that also contains the CROSS_COMPILE path, since Xen will
no longer overwrite the CC or CXX value if those are set on the
environment.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
config/StdGNU.mk | 35 +++
scripts/travis-build | 8
2 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 7a6159021b..b3072f5b13 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -1,28 +1,31 @@
# Use Clang/LLVM instead of GCC?
clang ?= n
-# If we are not cross-compiling, default HOSTC{C/XX} to C{C/XX}
-ifeq ($(XEN_TARGET_ARCH), $(XEN_COMPILE_ARCH))
-HOSTCC?= $(CC)
-HOSTCXX ?= $(CXX)
-endif
-
AS = $(CROSS_COMPILE)as
LD = $(CROSS_COMPILE)ld
ifeq ($(clang),y)
gcc := n
-CC = $(CROSS_COMPILE)clang
-CXX= $(CROSS_COMPILE)clang++
-LD_LTO = $(CROSS_COMPILE)llvm-ld
-HOSTCC?= clang
-HOSTCXX ?= clang++
+DEF_CC = clang
+DEF_CXX= clang++
+LD_LTO?= $(CROSS_COMPILE)llvm-ld
else
gcc := y
-CC = $(CROSS_COMPILE)gcc
-CXX= $(CROSS_COMPILE)g++
-LD_LTO = $(CROSS_COMPILE)ld
-HOSTCC?= gcc
-HOSTCXX ?= g++
+DEF_CC = gcc
+DEF_CXX= g++
+LD_LTO?= $(CROSS_COMPILE)ld
+endif
+
+CC?= $(CROSS_COMPILE)$(DEF_CC)
+CXX ?= $(CROSS_COMPILE)$(DEF_CXX)
+
+# If we are not cross-compiling, default HOSTC{C/XX} to C{C/XX}
+# else use the default values if unset
+ifeq ($(XEN_TARGET_ARCH), $(XEN_COMPILE_ARCH))
+HOSTCC?= $(CC)
+HOSTCXX ?= $(CXX)
+else
+HOSTCC?= $(DEF_CC)
+HOSTCXX ?= $(DEF_CXX)
endif
CPP= $(CC) -E
diff --git a/scripts/travis-build b/scripts/travis-build
index 0cb15a89e4..a264e286b2 100755
--- a/scripts/travis-build
+++ b/scripts/travis-build
@@ -1,6 +1,14 @@
#!/bin/bash -ex
+# Set HOST{CC/CXX} in case we are cross building
+export HOSTCC=${CC}
+export HOSTCXX=${CXX}
+# Prefix environment CC/CXX with CROSS_COMPILE if present
+export CC=${CROSS_COMPILE}${CC}
+export CXX=${CROSS_COMPILE}${CXX}
+
$CC --version
+[[ "${CC}" != "${HOSTCC}" ]] && $HOSTCC --version
# random config or default config
if [[ "${RANDCONFIG}" == "y" ]]; then
--
2.22.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/4] kconfig: include default toolchain values
Include config/$(OS).mk which contains the default values for the
toolchain variables. This removes the need to pass HOST{CC/CXX} as
parameters from the high level make target or to default them to
gcc/g++ if unset.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Cc: Doug Goldstein
---
xen/Makefile | 6 +++---
xen/tools/kconfig/Makefile.kconfig | 7 +++
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index c80914c31d..e9f700f9e7 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -267,14 +267,14 @@ kconfig := silentoldconfig oldconfig config menuconfig
defconfig \
randconfig $(notdir $(wildcard arch/$(SRCARCH)/configs/*_defconfig))
.PHONY: $(kconfig)
$(kconfig):
- $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH)
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
+ $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH)
SRCARCH=$(SRCARCH) $@
include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
- $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH)
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" silentoldconfig
+ $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH)
SRCARCH=$(SRCARCH) silentoldconfig
# Allow people to just run `make` as before and not force them to configure
$(KCONFIG_CONFIG):
- $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH)
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" defconfig
+ $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH)
SRCARCH=$(SRCARCH) defconfig
# Break the dependency chain for the first run
include/config/auto.conf.cmd: ;
diff --git a/xen/tools/kconfig/Makefile.kconfig
b/xen/tools/kconfig/Makefile.kconfig
index dbd8912015..138bf3f1b7 100644
--- a/xen/tools/kconfig/Makefile.kconfig
+++ b/xen/tools/kconfig/Makefile.kconfig
@@ -35,15 +35,14 @@ KBUILD_DEFCONFIG := $(ARCH)_defconfig
# provide our shell
CONFIG_SHELL := $(SHELL)
-# provide the host compiler
-HOSTCC ?= gcc
-HOSTCXX ?= g++
-
# force target
PHONY += FORCE
FORCE:
+# Sets toolchain binaries to use
+include $(XEN_ROOT)/config/$(shell uname -s).mk
+
# include the original Makefile and Makefile.host from Linux
include $(src)/Makefile
include $(src)/Makefile.host
--
2.22.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 4/4] build: allow picking the env values for toolchain utilities
Don't force the usage of the hardcoded toolchain values if those are already set on the environment. Note that as part of the change the definition of AS and LD is moved after the setting of compiler related variables. Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- config/StdGNU.mk | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/config/StdGNU.mk b/config/StdGNU.mk index b3072f5b13..cab7369f12 100644 --- a/config/StdGNU.mk +++ b/config/StdGNU.mk @@ -1,8 +1,6 @@ # Use Clang/LLVM instead of GCC? clang ?= n -AS = $(CROSS_COMPILE)as -LD = $(CROSS_COMPILE)ld ifeq ($(clang),y) gcc := n DEF_CC = clang @@ -28,19 +26,21 @@ HOSTCC?= $(DEF_CC) HOSTCXX ?= $(DEF_CXX) endif -CPP= $(CC) -E -AR = $(CROSS_COMPILE)ar -RANLIB = $(CROSS_COMPILE)ranlib -NM = $(CROSS_COMPILE)nm -STRIP = $(CROSS_COMPILE)strip -OBJCOPY= $(CROSS_COMPILE)objcopy -OBJDUMP= $(CROSS_COMPILE)objdump -SIZEUTIL = $(CROSS_COMPILE)size +AS?= $(CROSS_COMPILE)as +LD?= $(CROSS_COMPILE)ld +CPP ?= $(CC) -E +AR?= $(CROSS_COMPILE)ar +RANLIB?= $(CROSS_COMPILE)ranlib +NM?= $(CROSS_COMPILE)nm +STRIP ?= $(CROSS_COMPILE)strip +OBJCOPY ?= $(CROSS_COMPILE)objcopy +OBJDUMP ?= $(CROSS_COMPILE)objdump +SIZEUTIL ?= $(CROSS_COMPILE)size # Allow git to be wrappered in the environment GIT?= git -INSTALL = install +INSTALL ?= install INSTALL_DIR = $(INSTALL) -d -m0755 -p INSTALL_DATA = $(INSTALL) -m0644 -p INSTALL_PROG = $(INSTALL) -m0755 -p -- 2.22.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 1/4] build: set HOST{CC/CXX}, clang and gcc in StdGNU.mk
This is a preparatory change for simplifying the setting of
HOST{CC/CXX} and allowing the Xen build system to pick the toolchain
variables from the environment.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
Config.mk| 18 --
config/StdGNU.mk | 16
2 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/Config.mk b/Config.mk
index 0fa4591379..57a6c934b3 100644
--- a/Config.mk
+++ b/Config.mk
@@ -39,24 +39,6 @@ DESTDIR ?= /
# Allow phony attribute to be listed as dependency rather than fake target
.PHONY: .phony
-# If we are not cross-compiling, default HOSTC{C/XX} to C{C/XX}
-ifeq ($(XEN_TARGET_ARCH), $(XEN_COMPILE_ARCH))
-HOSTCC ?= $(CC)
-HOSTCXX ?= $(CXX)
-endif
-
-# Use Clang/LLVM instead of GCC?
-clang ?= n
-ifeq ($(clang),n)
-gcc := y
-HOSTCC ?= gcc
-HOSTCXX ?= g++
-else
-gcc := n
-HOSTCC ?= clang
-HOSTCXX ?= clang++
-endif
-
DEPS_INCLUDE = $(addsuffix .d2, $(basename $(wildcard $(DEPS
DEPS_RM = $(DEPS) $(DEPS_INCLUDE)
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 039274ea61..7a6159021b 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -1,14 +1,30 @@
+# Use Clang/LLVM instead of GCC?
+clang ?= n
+
+# If we are not cross-compiling, default HOSTC{C/XX} to C{C/XX}
+ifeq ($(XEN_TARGET_ARCH), $(XEN_COMPILE_ARCH))
+HOSTCC?= $(CC)
+HOSTCXX ?= $(CXX)
+endif
+
AS = $(CROSS_COMPILE)as
LD = $(CROSS_COMPILE)ld
ifeq ($(clang),y)
+gcc := n
CC = $(CROSS_COMPILE)clang
CXX= $(CROSS_COMPILE)clang++
LD_LTO = $(CROSS_COMPILE)llvm-ld
+HOSTCC?= clang
+HOSTCXX ?= clang++
else
+gcc := y
CC = $(CROSS_COMPILE)gcc
CXX= $(CROSS_COMPILE)g++
LD_LTO = $(CROSS_COMPILE)ld
+HOSTCC?= gcc
+HOSTCXX ?= g++
endif
+
CPP= $(CC) -E
AR = $(CROSS_COMPILE)ar
RANLIB = $(CROSS_COMPILE)ranlib
--
2.22.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/4] build: honor toolchain related environment vars
Hello,
Current Xen build system will ignore any toolchain related variables on
the environment when building (ie: CC, LD, CXX...), and the only way to
set those is to assign them directly on the make command line (ie: make
CC=foo CXX=bar ...).
The following series attempts to fix this, by removing the hardcoding of
the toolchain variables previously done in StdGNU.mk.
Note that this has the side effect that the build system will no longer
prepend CROSS_COMPILE to the toolchain variables if those are already
set. So if you are building Xen and setting CROSS_COMPILE make sure
toolchain variables are unset, or if set they should contain
CROSS_COMPILE. The Travis CI script is updated in patch 3/4 in order to
comply with the above.
This is v2 because v1 was missing the first patch, rendering the whole
series useless. Apart from that there are no changes from v1.
The series can be found at:
git://xenbits.xen.org/people/royger/xen.git env_tools
Results from Travis and gitlab CI loops are at:
https://travis-ci.org/royger/xen/builds/581139388
https://gitlab.com/xen-project/people/royger/xen/pipelines/80440648
Thanks, Roger.
Roger Pau Monne (4):
build: set HOST{CC/CXX}, clang and gcc in StdGNU.mk
kconfig: include default toolchain values
build: allow picking the env values for compiler variables
build: allow picking the env values for toolchain utilities
Config.mk | 18 --
config/StdGNU.mk | 53 --
scripts/travis-build | 8 +
xen/Makefile | 6 ++--
xen/tools/kconfig/Makefile.kconfig | 7 ++--
5 files changed, 50 insertions(+), 42 deletions(-)
--
2.22.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [ANNOUNCE] Call for agenda items for September 5th Community Call @ 15:00 UTC
> On Sep 5, 2019, at 04:36, Lars Kurth wrote: > > On 05/09/2019, 09:33, "Juergen Gross" wrote: > >>On 05.09.19 10:14, Andrew Cooper wrote: >>> On 05/09/2019 08:49, Lars Kurth wrote: On 05/09/2019, 08:41, "Rich Persaud" wrote: On Sep 5, 2019, at 03:19, Jan Beulich wrote: Forgive me asking, but why is this put up as an agenda item here? IMO this is the kind of thing where you would send a proposal and request feedback by email first, and put it up as an agenda item here only if it got stalled there. (Apologies if I've overlooked such a stalled thread.) >>> >>> If Xen community call topics are limited to escalations of xen-devel >>> threads, then a new thread can be created for this topic. Xen community >>> calls have also provided real-time, interactive feedback on candidate >>> proposals, along with guidance on areas which need documentation before a >>> formal proposal is made to xen-devel. Such agenda items are typically >>> covered after all series and priority topics have been addressed. >>> >>> I don't mind having items such these on the agenda and to be fair have >>> added similar items onto the agenda in the past. >>> Clearly, they are forward looking [like an RFC], for which reason I tend to >>> add them to the end of an agenda if there is a busy schedule >>> >>> Personally, on this specific item, it is not really clear what the >>> questions are. In other words: is this about UUIDS/domain ids only, or is >>> there something else. >> >> Requiring something to be blocked on xen-devel before we discuss it on >> the call is monumentally short sighted, and off-putting for contributors. >> >> In this case, it is very definitely not the first time this problem has >> been raised, as it is an XSA shaped elephant in the room. Its no secret >> that id wraps cause problems, and while our security policy doesn't >> comment on the matter, it also doesn't say "warning - stuff *will* break >> in weird, wonderful, and security-relevant ways when domid's wrap". >> >> The order of the agenda is important, and I don't think this should be >> at the top, but even if we only end up with 2 minutes to discuss it, >> then so be it. (2 minutes of talking can still be far more valuable >> than a weeks worth of emailing.) >> >> What is not acceptable is suggesting that it should be veto'd simply >> because it is perceived to be a very fresh idea/query. > >I still think it would help if a short high level design would be posted >on xen-devel first. > > I think that is a valid point and I agree. In the past when we had similar > discussions often the outcome was not that clear and due to the nature of > the calls the discussions were also not well reflected in the notes. > > So, there is an argument, that discussions typically are more productive when > there is the possibility for some preparation or an e-mail thread to refer to. We can defer the xenstoreless name service topic to the October monthly call. For today's call, can we discuss the previously posted high-level design for unification of the domB RFC with dom0less, as "domB mode" for disaggregation of Xen's dom0? - domB mode for dom0less (July 2019): https://lists.gt.net/xen/devel/557782 - domB RFC (June 2018): https://lists.gt.net/xen/devel/519367 Rich___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.2019 16:36, Juergen Gross wrote:
> On 05.09.19 14:46, Juergen Gross wrote:
>> On 05.09.19 14:37, Jan Beulich wrote:
>>> On 05.09.2019 14:27, Juergen Gross wrote:
On 05.09.19 14:22, Jan Beulich wrote:
> On 05.09.2019 14:12, Juergen Gross wrote:
>> On 05.09.19 14:01, Jan Beulich wrote:
>>> On 05.09.2019 13:39, Juergen Gross wrote:
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer. In order not to limit buffer size
switch the related fields from unsigned int to unsigned long, as on
huge machines with RAM in the TB range it might be interesting to
support buffers >4GB.
>>>
>>> Just as a further remark in this regard:
>>>
void debugtrace_printk(const char *fmt, ...)
{
static char buf[DEBUG_TRACE_ENTRY_SIZE];
- static unsigned int count, last_count, last_prd;
+ static unsigned int count, last_count;
>>>
>>> How long do we think will it take until their wrapping will become
>>> an issue with such huge buffers?
>>
>> Count wrapping will not result in any misbehavior of tracing. With
>> per-cpu buffers it might result in ambiguity regarding sorting the
>> entries, but I guess chances are rather low this being a real issue.
>>
>> BTW: wrapping of count is not related to buffer size, but to the
>> amount of trace data written.
>
> Sure, but the chance of ambiguity increases with larger buffer sizes.
Well, better safe than sorry. Switching to unsigned long will rarely
hurt, so I'm going to do just that. The only downside will be some waste
of buffer space for very long running traces with huge amounts of
entries.
>>>
>>> Hmm, true. Maybe we could get someone else's opinion on this - anyone?
>>
>> TBH, I wouldn't be concerned about the buffer space. In case there are
>> really billions of entries, the difference between a 10-digit count
>> value and maybe a 15 digit one (and that is already a massive amount)
>> isn't that large. The average printed size of count with about
>> 4 billion entries is 9.75 digits (and not just 5 :-) ).
>
> Another option would be to let count wrap at e.g. 4 billion (or even 1
> million) and add a wrap count. Each buffer struct would contain the
> wrap count of the last entry, and when hitting a higher wrap count a
> new entry like ("wrap %u->%u", old_wrap, new_wrap) would be printed.
> This saves buffer space without loosing information.
This sounds quite neat.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.19 14:46, Juergen Gross wrote:
On 05.09.19 14:37, Jan Beulich wrote:
On 05.09.2019 14:27, Juergen Gross wrote:
On 05.09.19 14:22, Jan Beulich wrote:
On 05.09.2019 14:12, Juergen Gross wrote:
On 05.09.19 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer. In order not to limit buffer size
switch the related fields from unsigned int to unsigned long, as on
huge machines with RAM in the TB range it might be interesting to
support buffers >4GB.
Just as a further remark in this regard:
void debugtrace_printk(const char *fmt, ...)
{
static char buf[DEBUG_TRACE_ENTRY_SIZE];
- static unsigned int count, last_count, last_prd;
+ static unsigned int count, last_count;
How long do we think will it take until their wrapping will become
an issue with such huge buffers?
Count wrapping will not result in any misbehavior of tracing. With
per-cpu buffers it might result in ambiguity regarding sorting the
entries, but I guess chances are rather low this being a real issue.
BTW: wrapping of count is not related to buffer size, but to the
amount of trace data written.
Sure, but the chance of ambiguity increases with larger buffer sizes.
Well, better safe than sorry. Switching to unsigned long will rarely
hurt, so I'm going to do just that. The only downside will be some waste
of buffer space for very long running traces with huge amounts of
entries.
Hmm, true. Maybe we could get someone else's opinion on this - anyone?
TBH, I wouldn't be concerned about the buffer space. In case there are
really billions of entries, the difference between a 10-digit count
value and maybe a 15 digit one (and that is already a massive amount)
isn't that large. The average printed size of count with about
4 billion entries is 9.75 digits (and not just 5 :-) ).
Another option would be to let count wrap at e.g. 4 billion (or even 1
million) and add a wrap count. Each buffer struct would contain the
wrap count of the last entry, and when hitting a higher wrap count a
new entry like ("wrap %u->%u", old_wrap, new_wrap) would be printed.
This saves buffer space without loosing information.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 4/6] remove late (on-demand) construction of IOMMU page tables
> -Original Message- > From: Jan Beulich > Sent: 05 September 2019 15:30 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Julien Grall ; > Alexandru Isaila > ; PetrePircalabu ; > Razvan Cojocaru > ; Andrew Cooper ; Roger > Pau Monne > ; Volodymyr Babchuk ; > George Dunlap > ; Ian Jackson ; Stefano > Stabellini > ; Konrad Rzeszutek Wilk ; > Tamas K Lengyel > ; Tim (Xen.org) ; Wei Liu > Subject: Re: [PATCH v8 4/6] remove late (on-demand) construction of IOMMU > page tables > > On 02.09.2019 16:50, Paul Durrant wrote: > > Now that there is a per-domain IOMMU-enable flag, which should be set if > > any device is going to be passed through, stop deferring page table > > construction until the assignment is done. Also don't tear down the tables > > again when the last device is de-assigned; defer that task until domain > > destruction. > > > > This allows the has_iommu_pt() helper and iommu_status enumeration to be > > removed. Calls to has_iommu_pt() are simply replaced by calls to > > is_iommu_enabled(). Remaining open-coded tests of iommu_hap_pt_share can > > also be replaced by calls to iommu_use_hap_pt(). > > The arch_iommu_populate_page_table() and iommu_construct() functions become > > redundant, as does the 'strict mode' dom0 page_list mapping code in > > iommu_hwdom_init(), and iommu_teardown() can be made static is its only > > remaining caller, iommu_domain_destroy(), is within the same source > > module. > > > > All in all, about 220 lines of code are removed from the hypervisor. > > > > NOTE: This patch will cause a small amount of extra resource to be used > > to accommodate IOMMU page tables that may never be used, since the > > per-domain IOMMU-enable flag is currently set to the value of the > > global iommu_enable flag. A subsequent patch will add an option to > > the toolstack to allow it to be turned off if there is no intention > > to assign passthrough hardware to the domain. > > To account for the extra resource, 'iommu_memkb' has been added to > > domain_build_info. This patch sets it unconditionally to a value > > calculated based on the domain's maximum memory but, when the > > toolstack option mentioned above is added, it can be set to zero > > if the per-domain IOMMU-enable flag is turned off. > > > > Signed-off-by: Paul Durrant > > I've just stumbled across our earlier discussion on the still not > sufficiently "x86/HVM: p2m_ram_ro is incompatible with device > pass-through" of mine, and I wonder whether the implication from > the change here is that people wanting p2m_ram_ro used on a guest > would then need to force the IOMMU off for that guest (which aiui > isn't possible until patch 6). You wouldn't be able to force IOMMU off on a per-domain basis until patch #6 but it could still be done globally. Paul > > Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 4/6] remove late (on-demand) construction of IOMMU page tables
On 02.09.2019 16:50, Paul Durrant wrote: > Now that there is a per-domain IOMMU-enable flag, which should be set if > any device is going to be passed through, stop deferring page table > construction until the assignment is done. Also don't tear down the tables > again when the last device is de-assigned; defer that task until domain > destruction. > > This allows the has_iommu_pt() helper and iommu_status enumeration to be > removed. Calls to has_iommu_pt() are simply replaced by calls to > is_iommu_enabled(). Remaining open-coded tests of iommu_hap_pt_share can > also be replaced by calls to iommu_use_hap_pt(). > The arch_iommu_populate_page_table() and iommu_construct() functions become > redundant, as does the 'strict mode' dom0 page_list mapping code in > iommu_hwdom_init(), and iommu_teardown() can be made static is its only > remaining caller, iommu_domain_destroy(), is within the same source > module. > > All in all, about 220 lines of code are removed from the hypervisor. > > NOTE: This patch will cause a small amount of extra resource to be used > to accommodate IOMMU page tables that may never be used, since the > per-domain IOMMU-enable flag is currently set to the value of the > global iommu_enable flag. A subsequent patch will add an option to > the toolstack to allow it to be turned off if there is no intention > to assign passthrough hardware to the domain. > To account for the extra resource, 'iommu_memkb' has been added to > domain_build_info. This patch sets it unconditionally to a value > calculated based on the domain's maximum memory but, when the > toolstack option mentioned above is added, it can be set to zero > if the per-domain IOMMU-enable flag is turned off. > > Signed-off-by: Paul Durrant I've just stumbled across our earlier discussion on the still not sufficiently "x86/HVM: p2m_ram_ro is incompatible with device pass-through" of mine, and I wonder whether the implication from the change here is that people wanting p2m_ram_ro used on a guest would then need to force the IOMMU off for that guest (which aiui isn't possible until patch 6). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3] x86emul: fix test harness and fuzzer build dependencies
Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
userspace test harnesses") didn't account for the dependencies of
cpuid-autogen.h to potentially change between incremental builds. In
particular the harness has a "run" goal which is supposed to be usable
independently of the rest of the tools sub-tree building, and both the
harness and the fuzzer code are also supposed to be buildable
independently. Therefore a re-build of the generated header needs to be
triggered first, which is achieved by introducing a new top-level target
pattern (for just the "run" part for now).
Further cpuid.o did not have any dependencies added for it.
Finally, while at it, add a "run" target to the cpu-policy test harness.
Signed-off-by: Jan Beulich
---
TBD: Something similar would be nice for building both tools/tests/*/
and tools/fuzz/*/, but I'm uncertain whether respective top level
targets build-tests-% and build-fuzz-% would be welcome.
---
v3: Introduce top level run-tests-% target.
v2.1: Split controversial parts from (hopefully) non-controversial ones.
v2: Guard $(MAKE) invocations by $(MAKELEVEL) checks.
--- a/Makefile
+++ b/Makefile
@@ -80,6 +80,9 @@ build-docs:
test:
$(MAKE) -C tools/python test
+run-tests-%: build-tools-public-headers tools/tests/%/
+ $(MAKE) -C tools/tests/$* run
+
# For most targets here,
# make COMPONENT-TARGET
# is implemented, more or less, by
--- a/tools/fuzz/x86_instruction_emulator/Makefile
+++ b/tools/fuzz/x86_instruction_emulator/Makefile
@@ -26,13 +26,15 @@ GCOV_FLAGS := --coverage
$(CC) -c $(CFLAGS) $(GCOV_FLAGS) $< -o $@
x86.h := $(addprefix $(XEN_ROOT)/tools/include/xen/asm/,\
- x86-vendors.h x86-defns.h msr-index.h)
+ x86-vendors.h x86-defns.h msr-index.h) \
+ $(addprefix $(XEN_ROOT)/tools/include/xen/lib/x86/, \
+ cpuid.h cpuid-autogen.h)
x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
# x86-emulate.c will be implicit for both
x86-emulate.o x86-emulate-cov.o: x86_emulate/x86_emulate.c $(x86_emulate.h)
-fuzz-emul.o fuzz-emulate-cov.o wrappers.o: $(x86_emulate.h)
+fuzz-emul.o fuzz-emulate-cov.o cpuid.o wrappers.o: $(x86_emulate.h)
x86-insn-fuzzer.a: fuzz-emul.o x86-emulate.o cpuid.o
$(AR) rc $@ $^
--- a/tools/tests/cpu-policy/Makefile
+++ b/tools/tests/cpu-policy/Makefile
@@ -17,6 +17,10 @@ endif
.PHONY: all
all: $(TARGET-y)
+.PHONY: run
+run: $(TARGET-y)
+ ./$(TARGET-y)
+
.PHONY: clean
clean:
$(RM) -f -- *.o .*.d .*.d2 test-cpu-policy
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -280,10 +280,12 @@ $(call cc-option-add,HOSTCFLAGS-x86_64,H
HOSTCFLAGS += $(CFLAGS_xeninclude) -I. $(HOSTCFLAGS-$(XEN_COMPILE_ARCH))
x86.h := $(addprefix $(XEN_ROOT)/tools/include/xen/asm/,\
- x86-vendors.h x86-defns.h msr-index.h)
+ x86-vendors.h x86-defns.h msr-index.h) \
+ $(addprefix $(XEN_ROOT)/tools/include/xen/lib/x86/, \
+ cpuid.h cpuid-autogen.h)
x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
-x86-emulate.o test_x86_emulator.o evex-disp8.o wrappers.o: %.o: %.c
$(x86_emulate.h)
+x86-emulate.o cpuid.o test_x86_emulator.o evex-disp8.o wrappers.o: %.o: %.c
$(x86_emulate.h)
$(HOSTCC) $(HOSTCFLAGS) -c -g -o $@ $<
x86-emulate.o: x86_emulate/x86_emulate.c
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RFC] x86/HVM: use single (atomic) MOV for aligned emulated writes
Using memcpy() may result in multiple individual byte accesses
(dependening how memcpy() is implemented and how the resulting insns,
e.g. REP MOVSB, get carried out in hardware), which isn't what we
want/need for carrying out guest insns as correctly as possible. Fall
back to memcpy() only for misaligned accesses as well as ones not 2, 4,
or 8 bytes in size.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
RFC: Besides wanting to hear if this is considered acceptable and
sufficient (or whether it is thought that the linear_write() path
also needs playing with), the question is whether we'd want to
extend this to reads as well. linear_{read,write}() currently don't
use hvmemul_map_linear_addr(), i.e. in both cases I'd need to also
fiddle with __hvm_copy() (perhaps by making the construct below a
helper function).
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1352,7 +1352,14 @@ static int hvmemul_write(
if ( !mapping )
return linear_write(addr, bytes, p_data, pfec, hvmemul_ctxt);
-memcpy(mapping, p_data, bytes);
+/* For aligned accesses use single (and hence atomic) MOV insns. */
+switch ( bytes | ((unsigned long)mapping & (bytes - 1)) )
+{
+case 2: write_u16_atomic(mapping, *(uint16_t *)p_data); break;
+case 4: write_u32_atomic(mapping, *(uint32_t *)p_data); break;
+case 8: write_u64_atomic(mapping, *(uint64_t *)p_data); break;
+default: memcpy(mapping, p_data, bytes);break;
+}
hvmemul_unmap_linear_addr(mapping, addr, bytes, hvmemul_ctxt);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 141026: regressions - FAIL
flight 141026 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/141026/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 141000 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 7bf525599713703a60c4f300bd82787545a74a52 baseline version: ovmf adb59b633c12eae334540295092da94736bffa33 Last test of basis 141000 2019-09-04 08:59:22 Z1 days Testing same since 141026 2019-09-04 23:39:00 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Liming Gao Ray Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 fail build-i386 pass build-amd64-libvirt blocked build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 7bf525599713703a60c4f300bd82787545a74a52 Author: Ray Ni Date: Wed Aug 28 06:58:45 2019 +0800 IntelFsp2WrapperPkg: Remove unneeded MdeModulePkg dependency Signed-off-by: Ray Ni Reviewed-by: Chasel Chiu Cc: Nate DeSimone Reviewed-by: Star Zeng commit d1da2ab93a0e1518bc01d7c38505730462278e45 Author: Ray Ni Date: Wed Aug 28 06:40:06 2019 +0800 IntelFsp2Pkg/FspSecCore: Remove unneeded MdeModulePkg dependency Signed-off-by: Ray Ni Reviewed-by: Chasel Chiu Reviewed-by: Nate DeSimone Reviewed-by: Star Zeng commit d2687f23c909475d80cef32cdf9a5d121f0a9ae6 Author: Ard Biesheuvel Date: Tue Sep 3 20:58:18 2019 -0700 BaseTools/GenFw AARCH64: fix up GOT based relative relocations We take great care to avoid GOT based relocations in EDK2 executables, primarily because they are pointless - we don't care about things like the CoW footprint or relocations that target read-only sections, and so GOT entries only bloat the binary. However, in some cases (e.g., when building the relocatable PrePi SEC module in ArmVirtPkg with the CLANG38 toolchain), we may end up with some GOT based relocations nonetheless, which break the build since GenFw does not know how to deal with them. The relocations emitted in this case are ADRP/LDR instruction pairs that are annotated as GOT based, which means that it is the linker's job to emit the GOT entry and tag it with an appropriate dynamic relocation that ensures that the correct absolute value is stored into the GOT entry when the executable is loaded. This dynamic relocation is not visible to GenFw, and so populating the PE/COFF relocation section for these entries is non-trivial. Since each ADRP/LDR pair refers to a single symbol that is local to the binary (given that shared libraries are not supported), we can actually convert the ADRP/LDR pair into an ADRP/ADD pair that produces the symbol address directly rather than loading it from memory. This leaves the GOT entry in the binary, but since it is now unused, it is no longer necessary to emit a PE/COFF relocation entry for it. Acked-by: Liming Gao Reviewed-by: Leif Lindholm Signed-off-by: Ard Biesheuvel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] sysctl/libxl: choose a sane default for HAP
On 05.09.2019 15:52, Paul Durrant wrote:
>> From: Roger Pau Monne
>> Sent: 05 September 2019 14:27
>>
>> Current libxl code will always enable Hardware Assisted Paging (HAP),
>> expecting that the hypervisor will fallback to shadow if HAP is not
>> available. With the changes to the domain builder that's not the case
>> any longer, and the hypervisor will raise an error if HAP is not
>> available instead of silently falling back to shadow.
>>
>> In order to keep the previous functionality report whether HAP is
>> available or not in XEN_SYSCTL_physinfo, so that the toolstack can
>> select a sane default if there's no explicit user selection of whether
>> HAP should be used.
>>
>> Note that on ARM hardware HAP capability is always reported since it's
>> a required feature in order to run Xen.
>>
>> Fixes: d0c0ba7d3de ('x86/hvm/domain: remove the 'hap_enabled' flag')
>> Signed-off-by: Roger Pau Monné
>
> LGTM
>
> Reviewed-by: Paul Durrant
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] sysctl: report existing physcaps on ARM
On 05.09.2019 15:53, Paul Durrant wrote: >> From: Xen-devel On Behalf Of Roger >> Pau Monne >> Sent: 05 September 2019 14:27 >> >> Current physcaps in XEN_SYSCTL_physinfo are only used by x86, albeit >> the capabilities themselves are not x86 specific. >> >> This patch adds support for also reporting the current capabilities on >> ARM hardware. Note that on ARM PHYSCAP_hvm is always reported, and >> setting PHYSCAP_directio has been moved to common code since the same >> logic to set it is used by x86 and ARM. >> >> Signed-off-by: Roger Pau Monné > > Reviewed-by: Paul Durrant Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] sysctl: report existing physcaps on ARM
> -Original Message-
> From: Xen-devel On Behalf Of Roger
> Pau Monne
> Sent: 05 September 2019 14:27
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu ;
> Konrad Rzeszutek Wilk
> ; George Dunlap ; Andrew
> Cooper
> ; Ian Jackson ; Tim
> (Xen.org) ; Julien
> Grall ; Jan Beulich ; Volodymyr
> Babchuk
> ; Roger Pau Monne
> Subject: [Xen-devel] [PATCH v2 1/2] sysctl: report existing physcaps on ARM
>
> Current physcaps in XEN_SYSCTL_physinfo are only used by x86, albeit
> the capabilities themselves are not x86 specific.
>
> This patch adds support for also reporting the current capabilities on
> ARM hardware. Note that on ARM PHYSCAP_hvm is always reported, and
> setting PHYSCAP_directio has been moved to common code since the same
> logic to set it is used by x86 and ARM.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
> ---
> Changes since v1:
> - New in this version.
> ---
> xen/arch/arm/sysctl.c | 5 -
> xen/arch/x86/sysctl.c | 2 --
> xen/common/sysctl.c | 2 ++
> xen/include/public/sysctl.h | 6 +++---
> 4 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
> index fbfdb44eff..92ac99c928 100644
> --- a/xen/arch/arm/sysctl.c
> +++ b/xen/arch/arm/sysctl.c
> @@ -12,7 +12,10 @@
> #include
> #include
>
> -void arch_do_physinfo(struct xen_sysctl_physinfo *pi) { }
> +void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> +{
> +pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
> +}
>
> long arch_do_sysctl(struct xen_sysctl *sysctl,
> XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
> diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
> index c50d910a1c..7ec6174e6b 100644
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -163,8 +163,6 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
> if ( IS_ENABLED(CONFIG_PV) )
> pi->capabilities |= XEN_SYSCTL_PHYSCAP_pv;
> -if ( iommu_enabled )
> -pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
> }
>
> long arch_do_sysctl(
> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> index fcf2d2fd7c..92b4ea0d21 100644
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -267,6 +267,8 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
> u_sysctl)
> pi->cpu_khz = cpu_khz;
> pi->max_mfn = get_upper_mfn_bound();
> arch_do_physinfo(pi);
> +if ( iommu_enabled )
> +pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
>
> if ( copy_to_guest(u_sysctl, op, 1) )
> ret = -EFAULT;
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index 91c48dcae0..36b3f8c429 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -81,13 +81,13 @@ struct xen_sysctl_tbuf_op {
> * Get physical information about the host machine
> */
> /* XEN_SYSCTL_physinfo */
> - /* (x86) The platform supports HVM guests. */
> + /* The platform supports HVM guests. */
> #define _XEN_SYSCTL_PHYSCAP_hvm 0
> #define XEN_SYSCTL_PHYSCAP_hvm (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
> - /* (x86) The platform supports PV guests. */
> + /* The platform supports PV guests. */
> #define _XEN_SYSCTL_PHYSCAP_pv 1
> #define XEN_SYSCTL_PHYSCAP_pv(1u<<_XEN_SYSCTL_PHYSCAP_pv)
> - /* (x86) The platform supports direct access to I/O devices with IOMMU. */
> + /* The platform supports direct access to I/O devices with IOMMU. */
> #define _XEN_SYSCTL_PHYSCAP_directio 2
> #define XEN_SYSCTL_PHYSCAP_directio (1u<<_XEN_SYSCTL_PHYSCAP_directio)
> struct xen_sysctl_physinfo {
> --
> 2.22.0
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] sysctl/libxl: choose a sane default for HAP
> -Original Message-
> From: Roger Pau Monne
> Sent: 05 September 2019 14:27
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Ian Jackson
> ; Wei Liu
> ; Anthony Perard ; Andrew Cooper
> ;
> George Dunlap ; Jan Beulich ;
> Julien Grall
> ; Konrad Rzeszutek Wilk ;
> Stefano Stabellini
> ; Tim (Xen.org) ; Volodymyr Babchuk
> ;
> Paul Durrant
> Subject: [PATCH v2 2/2] sysctl/libxl: choose a sane default for HAP
>
> Current libxl code will always enable Hardware Assisted Paging (HAP),
> expecting that the hypervisor will fallback to shadow if HAP is not
> available. With the changes to the domain builder that's not the case
> any longer, and the hypervisor will raise an error if HAP is not
> available instead of silently falling back to shadow.
>
> In order to keep the previous functionality report whether HAP is
> available or not in XEN_SYSCTL_physinfo, so that the toolstack can
> select a sane default if there's no explicit user selection of whether
> HAP should be used.
>
> Note that on ARM hardware HAP capability is always reported since it's
> a required feature in order to run Xen.
>
> Fixes: d0c0ba7d3de ('x86/hvm/domain: remove the 'hap_enabled' flag')
> Signed-off-by: Roger Pau Monné
LGTM
Reviewed-by: Paul Durrant
> ---
> Cc: Paul Durrant
> ---
> Changes since v1:
> - Also report HAP capability for ARM.
> - Print hap capability in xl info.
> ---
> tools/libxl/libxl.c | 1 +
> tools/libxl/libxl_create.c | 8 +++-
> tools/libxl/libxl_types.idl | 1 +
> tools/xl/xl_info.c | 5 +++--
> xen/arch/arm/sysctl.c | 2 +-
> xen/arch/x86/sysctl.c | 2 ++
> xen/include/public/sysctl.h | 4
> 7 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index ec71574e99..5c0fcf320e 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -399,6 +399,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo
> *physinfo)
> physinfo->cap_pv = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_pv);
> physinfo->cap_hvm_directio =
> !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_directio);
> +physinfo->cap_hap = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hap);
>
> GC_FREE;
> return 0;
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 03ce166f4f..6a556dea8f 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -38,7 +38,13 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
> libxl__arch_domain_create_info_setdefault(gc, c_info);
>
> if (c_info->type != LIBXL_DOMAIN_TYPE_PV) {
> -libxl_defbool_setdefault(_info->hap, true);
> +libxl_physinfo info;
> +int rc = libxl_get_physinfo(CTX, );
> +
> +if (rc)
> +return rc;
> +
> +libxl_defbool_setdefault(_info->hap, info.cap_hap);
> libxl_defbool_setdefault(_info->oos, true);
> }
>
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index b61399ce36..9e1f8515d3 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -1025,6 +1025,7 @@ libxl_physinfo = Struct("physinfo", [
> ("cap_hvm", bool),
> ("cap_pv", bool),
> ("cap_hvm_directio", bool), # No longer HVM specific
> +("cap_hap", bool),
> ], dir=DIR_OUT)
>
> libxl_connectorinfo = Struct("connectorinfo", [
> diff --git a/tools/xl/xl_info.c b/tools/xl/xl_info.c
> index 46d9c9f712..aa6724bc7f 100644
> --- a/tools/xl/xl_info.c
> +++ b/tools/xl/xl_info.c
> @@ -210,11 +210,12 @@ static void output_physinfo(void)
> info.hw_cap[4], info.hw_cap[5], info.hw_cap[6], info.hw_cap[7]
> );
>
> -maybe_printf("virt_caps :%s%s%s%s\n",
> +maybe_printf("virt_caps :%s%s%s%s%s\n",
> info.cap_pv ? " pv" : "",
> info.cap_hvm ? " hvm" : "",
> info.cap_hvm && info.cap_hvm_directio ? " hvm_directio" : "",
> - info.cap_pv && info.cap_hvm_directio ? " pv_directio" : ""
> + info.cap_pv && info.cap_hvm_directio ? " pv_directio" : "",
> + info.cap_hap ? " hap" : ""
> );
>
> vinfo = libxl_get_version_info(ctx);
> diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
> index 92ac99c928..f87944e847 100644
> --- a/xen/arch/arm/sysctl.c
> +++ b/xen/arch/arm/sysctl.c
> @@ -14,7 +14,7 @@
>
> void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> {
> -pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
> +pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm | XEN_SYSCTL_PHYSCAP_hap;
> }
>
> long arch_do_sysctl(struct xen_sysctl *sysctl,
> diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
> index 7ec6174e6b..5777a05ffc 100644
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -163,6 +163,8 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
> if ( IS_ENABLED(CONFIG_PV) )
[Xen-devel] [xen-unstable test] 141013: regressions - FAIL
flight 141013 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/141013/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 139876 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 139876 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 139876 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139876 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 139876 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 139876 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 139876 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139876 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 139876 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 139876 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 139876 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 139876 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen
Re: [Xen-devel] [PATCH -tip 0/2] x86: Prohibit kprobes on XEN_EMULATE_PREFIX
On 05/09/2019 14:09, Masami Hiramatsu wrote: > On Thu, 5 Sep 2019 20:32:24 +0900 > Masami Hiramatsu wrote: > >> On Thu, 5 Sep 2019 08:54:17 +0100 >> Andrew Cooper wrote: >> >>> On 05/09/2019 02:49, Masami Hiramatsu wrote: On Wed, 4 Sep 2019 12:54:55 +0100 Andrew Cooper wrote: > On 04/09/2019 12:45, Masami Hiramatsu wrote: >> Hi, >> >> These patches allow x86 instruction decoder to decode >> xen-cpuid which has XEN_EMULATE_PREFIX, and prohibit >> kprobes to probe on it. >> >> Josh reported that the objtool can not decode such special >> prefixed instructions, and I found that we also have to >> prohibit kprobes to probe on such instruction. >> >> This series can be applied on -tip master branch which >> has merged Josh's objtool/perf sharing common x86 insn >> decoder series. > The paravirtualised xen-cpuid is were you'll see it most in a regular > kernel, but be aware that it is also used for testing purposes in other > circumstances, and there is an equivalent KVM prefix which is used for > KVM testing. Good catch! I didn't notice that. Is that really same sequance or KVM uses another sequence of instructions for KVM prefix? >>> I don't know if you've spotted, but the prefix is a ud2a instruction >>> followed by 'xen' in ascii. >>> >>> The KVM version was added in c/s 6c86eedc206dd1f9d37a2796faa8e6f2278215d2 > Hmm, I think I might misunderstand what the "emulate prefix"... that is not > a prefix which replace actual prefix, but just works like an escape sequence. > Thus the next instruction can have any x86 prefix, correct? There is a bit of history here :) Originally, 13 years ago, Xen invented the "Force Emulate Prefix", which was the sequence: ud2a; .ascii 'xen'; cpuid which hit the #UD handler and was recognised as a request for virtualised CPUID information. This was for ring-deprivileged virtualisation, and is needed because the CPUID instruction itself doesn't trap to the hypervisor. Following some security issues in our instruction emulator, I reused this prefix with VT-x/SVM guests for testing purposes. It behaves in a similar manner - when enabled, it is recognised in #UD exception intercept, and causes Xen to add 5 to the instruction pointer, then emulate the instruction starting there. Then various folk thought that having the same kind of ability to test KVM's instruction emulator would be a good idea, so they borrowed the idea. From a behaviour point of view, it is an opaque 5 bytes which means "break into the hypervisor, then emulate the following instruction". The name "prefix" is unfortunate. It was named thusly because from the programmers point of view, it was something you put before the CPUID instruction which wanted to be emulated. It is not related to x86 instruction concept of a prefix. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 1/2] sysctl: report existing physcaps on ARM
Current physcaps in XEN_SYSCTL_physinfo are only used by x86, albeit
the capabilities themselves are not x86 specific.
This patch adds support for also reporting the current capabilities on
ARM hardware. Note that on ARM PHYSCAP_hvm is always reported, and
setting PHYSCAP_directio has been moved to common code since the same
logic to set it is used by x86 and ARM.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
xen/arch/arm/sysctl.c | 5 -
xen/arch/x86/sysctl.c | 2 --
xen/common/sysctl.c | 2 ++
xen/include/public/sysctl.h | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index fbfdb44eff..92ac99c928 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -12,7 +12,10 @@
#include
#include
-void arch_do_physinfo(struct xen_sysctl_physinfo *pi) { }
+void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
+{
+pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
+}
long arch_do_sysctl(struct xen_sysctl *sysctl,
XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index c50d910a1c..7ec6174e6b 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -163,8 +163,6 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
if ( IS_ENABLED(CONFIG_PV) )
pi->capabilities |= XEN_SYSCTL_PHYSCAP_pv;
-if ( iommu_enabled )
-pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
}
long arch_do_sysctl(
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index fcf2d2fd7c..92b4ea0d21 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -267,6 +267,8 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
pi->cpu_khz = cpu_khz;
pi->max_mfn = get_upper_mfn_bound();
arch_do_physinfo(pi);
+if ( iommu_enabled )
+pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
if ( copy_to_guest(u_sysctl, op, 1) )
ret = -EFAULT;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 91c48dcae0..36b3f8c429 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -81,13 +81,13 @@ struct xen_sysctl_tbuf_op {
* Get physical information about the host machine
*/
/* XEN_SYSCTL_physinfo */
- /* (x86) The platform supports HVM guests. */
+ /* The platform supports HVM guests. */
#define _XEN_SYSCTL_PHYSCAP_hvm 0
#define XEN_SYSCTL_PHYSCAP_hvm (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
- /* (x86) The platform supports PV guests. */
+ /* The platform supports PV guests. */
#define _XEN_SYSCTL_PHYSCAP_pv 1
#define XEN_SYSCTL_PHYSCAP_pv(1u<<_XEN_SYSCTL_PHYSCAP_pv)
- /* (x86) The platform supports direct access to I/O devices with IOMMU. */
+ /* The platform supports direct access to I/O devices with IOMMU. */
#define _XEN_SYSCTL_PHYSCAP_directio 2
#define XEN_SYSCTL_PHYSCAP_directio (1u<<_XEN_SYSCTL_PHYSCAP_directio)
struct xen_sysctl_physinfo {
--
2.22.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/2] libxl: choose a sane default for HAP
Hello, First patch is a preparatory change to also make use of the physcaps on ARM, second patch introduces a new physcap (HAP) in order for the toolstack to decide whether to use HAP if the user hasn't made a selection. The series can also be found at: git://xenbits.xen.org/people/royger/xen.git hap_info_v2 Thanks, Roger. Roger Pau Monne (2): sysctl: report existing physcaps on ARM sysctl/libxl: choose a sane default for HAP tools/libxl/libxl.c | 1 + tools/libxl/libxl_create.c | 8 +++- tools/libxl/libxl_types.idl | 1 + tools/xl/xl_info.c | 5 +++-- xen/arch/arm/sysctl.c | 5 - xen/arch/x86/sysctl.c | 4 ++-- xen/common/sysctl.c | 2 ++ xen/include/public/sysctl.h | 10 +++--- 8 files changed, 27 insertions(+), 9 deletions(-) -- 2.22.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/2] sysctl/libxl: choose a sane default for HAP
Current libxl code will always enable Hardware Assisted Paging (HAP),
expecting that the hypervisor will fallback to shadow if HAP is not
available. With the changes to the domain builder that's not the case
any longer, and the hypervisor will raise an error if HAP is not
available instead of silently falling back to shadow.
In order to keep the previous functionality report whether HAP is
available or not in XEN_SYSCTL_physinfo, so that the toolstack can
select a sane default if there's no explicit user selection of whether
HAP should be used.
Note that on ARM hardware HAP capability is always reported since it's
a required feature in order to run Xen.
Fixes: d0c0ba7d3de ('x86/hvm/domain: remove the 'hap_enabled' flag')
Signed-off-by: Roger Pau Monné
---
Cc: Paul Durrant
---
Changes since v1:
- Also report HAP capability for ARM.
- Print hap capability in xl info.
---
tools/libxl/libxl.c | 1 +
tools/libxl/libxl_create.c | 8 +++-
tools/libxl/libxl_types.idl | 1 +
tools/xl/xl_info.c | 5 +++--
xen/arch/arm/sysctl.c | 2 +-
xen/arch/x86/sysctl.c | 2 ++
xen/include/public/sysctl.h | 4
7 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ec71574e99..5c0fcf320e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -399,6 +399,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo
*physinfo)
physinfo->cap_pv = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_pv);
physinfo->cap_hvm_directio =
!!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_directio);
+physinfo->cap_hap = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hap);
GC_FREE;
return 0;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 03ce166f4f..6a556dea8f 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -38,7 +38,13 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
libxl__arch_domain_create_info_setdefault(gc, c_info);
if (c_info->type != LIBXL_DOMAIN_TYPE_PV) {
-libxl_defbool_setdefault(_info->hap, true);
+libxl_physinfo info;
+int rc = libxl_get_physinfo(CTX, );
+
+if (rc)
+return rc;
+
+libxl_defbool_setdefault(_info->hap, info.cap_hap);
libxl_defbool_setdefault(_info->oos, true);
}
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index b61399ce36..9e1f8515d3 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -1025,6 +1025,7 @@ libxl_physinfo = Struct("physinfo", [
("cap_hvm", bool),
("cap_pv", bool),
("cap_hvm_directio", bool), # No longer HVM specific
+("cap_hap", bool),
], dir=DIR_OUT)
libxl_connectorinfo = Struct("connectorinfo", [
diff --git a/tools/xl/xl_info.c b/tools/xl/xl_info.c
index 46d9c9f712..aa6724bc7f 100644
--- a/tools/xl/xl_info.c
+++ b/tools/xl/xl_info.c
@@ -210,11 +210,12 @@ static void output_physinfo(void)
info.hw_cap[4], info.hw_cap[5], info.hw_cap[6], info.hw_cap[7]
);
-maybe_printf("virt_caps :%s%s%s%s\n",
+maybe_printf("virt_caps :%s%s%s%s%s\n",
info.cap_pv ? " pv" : "",
info.cap_hvm ? " hvm" : "",
info.cap_hvm && info.cap_hvm_directio ? " hvm_directio" : "",
- info.cap_pv && info.cap_hvm_directio ? " pv_directio" : ""
+ info.cap_pv && info.cap_hvm_directio ? " pv_directio" : "",
+ info.cap_hap ? " hap" : ""
);
vinfo = libxl_get_version_info(ctx);
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index 92ac99c928..f87944e847 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -14,7 +14,7 @@
void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
{
-pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
+pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm | XEN_SYSCTL_PHYSCAP_hap;
}
long arch_do_sysctl(struct xen_sysctl *sysctl,
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 7ec6174e6b..5777a05ffc 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -163,6 +163,8 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
if ( IS_ENABLED(CONFIG_PV) )
pi->capabilities |= XEN_SYSCTL_PHYSCAP_pv;
+if ( hvm_hap_supported() )
+pi->capabilities |= XEN_SYSCTL_PHYSCAP_hap;
}
long arch_do_sysctl(
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 36b3f8c429..e02d7ce4c6 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -90,6 +90,10 @@ struct xen_sysctl_tbuf_op {
/* The platform supports direct access to I/O devices with IOMMU. */
#define _XEN_SYSCTL_PHYSCAP_directio 2
#define XEN_SYSCTL_PHYSCAP_directio (1u<<_XEN_SYSCTL_PHYSCAP_directio)
+/* The platform supports Hardware Assisted Paging. */
+#define _XEN_SYSCTL_PHYSCAP_hap 3
+#define
Re: [Xen-devel] [PATCH -tip 0/2] x86: Prohibit kprobes on XEN_EMULATE_PREFIX
On Thu, 5 Sep 2019 20:32:24 +0900 Masami Hiramatsu wrote: > On Thu, 5 Sep 2019 08:54:17 +0100 > Andrew Cooper wrote: > > > On 05/09/2019 02:49, Masami Hiramatsu wrote: > > > On Wed, 4 Sep 2019 12:54:55 +0100 > > > Andrew Cooper wrote: > > > > > >> On 04/09/2019 12:45, Masami Hiramatsu wrote: > > >>> Hi, > > >>> > > >>> These patches allow x86 instruction decoder to decode > > >>> xen-cpuid which has XEN_EMULATE_PREFIX, and prohibit > > >>> kprobes to probe on it. > > >>> > > >>> Josh reported that the objtool can not decode such special > > >>> prefixed instructions, and I found that we also have to > > >>> prohibit kprobes to probe on such instruction. > > >>> > > >>> This series can be applied on -tip master branch which > > >>> has merged Josh's objtool/perf sharing common x86 insn > > >>> decoder series. > > >> The paravirtualised xen-cpuid is were you'll see it most in a regular > > >> kernel, but be aware that it is also used for testing purposes in other > > >> circumstances, and there is an equivalent KVM prefix which is used for > > >> KVM testing. > > > Good catch! I didn't notice that. Is that really same sequance or KVM uses > > > another sequence of instructions for KVM prefix? > > > > I don't know if you've spotted, but the prefix is a ud2a instruction > > followed by 'xen' in ascii. > > > > The KVM version was added in c/s 6c86eedc206dd1f9d37a2796faa8e6f2278215d2 Hmm, I think I might misunderstand what the "emulate prefix"... that is not a prefix which replace actual prefix, but just works like an escape sequence. Thus the next instruction can have any x86 prefix, correct? If so, this patch doesn't work. I have to add a new field in struct insn like "insn.emulate_prefix_size" so that we can keep a room for the prefixes for real instruction. Thank you, -- Masami Hiramatsu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OT] Re: [PATCH -tip 0/2] x86: Prohibit kprobes on XEN_EMULATE_PREFIX
On Thu, 5 Sep 2019 09:53:32 +0100 Andrew Cooper wrote: > On 05/09/2019 09:26, Peter Zijlstra wrote: > > On Thu, Sep 05, 2019 at 08:54:17AM +0100, Andrew Cooper wrote: > > > >> I don't know if you've spotted, but the prefix is a ud2a instruction > >> followed by 'xen' in ascii. > >> > >> The KVM version was added in c/s 6c86eedc206dd1f9d37a2796faa8e6f2278215d2 > > While the Xen one disassebles to valid instructions, that KVM one does > > not: > > > > .text > > xen: > > ud2; .ascii "xen" > > kvm: > > ud2; .ascii "kvm" > > > > disassembles like: > > > > : > >0: 0f 0b ud2 > >2: 78 65 js 69 > >4: 6e outsb %ds:(%rsi),(%dx) > > 0005 : > >5: 0f 0b ud2 > >7: 6b .byte 0x6b > >8: 76 6d jbe77 > > > > Which is a bit unfortunate I suppose. At least they don't appear to > > consume further bytes. > > It does when you give objdump one extra byte to look at. > > 0005 : > 5: 0f 0b ud2 > 7: 6b 76 6d 00 imul $0x0,0x6d(%rsi),%esi > Hmm, that consumes the first byte of the next instruction. For example, .text xen: ud2; .ascii "xen"; cpuid kvm: ud2; .ascii "kvm"; cpuid : 0: 0f 0b ud2 2: 78 65 js 69 4: 6e outsb %ds:(%rsi),(%dx) 5: 0f a2 cpuid 0007 : 7: 0f 0b ud2 9: 6b 76 6d 0f imul $0xf,0x6d(%rsi),%esi d: a2 .byte 0xa2 This will disturbe decoding bytestream. Anyway, with the next version it will be fixed in x86 insn decoder. Thanks, -- Masami Hiramatsu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.19 14:37, Jan Beulich wrote:
On 05.09.2019 14:27, Juergen Gross wrote:
On 05.09.19 14:22, Jan Beulich wrote:
On 05.09.2019 14:12, Juergen Gross wrote:
On 05.09.19 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer. In order not to limit buffer size
switch the related fields from unsigned int to unsigned long, as on
huge machines with RAM in the TB range it might be interesting to
support buffers >4GB.
Just as a further remark in this regard:
void debugtrace_printk(const char *fmt, ...)
{
static char buf[DEBUG_TRACE_ENTRY_SIZE];
-static unsigned int count, last_count, last_prd;
+static unsigned int count, last_count;
How long do we think will it take until their wrapping will become
an issue with such huge buffers?
Count wrapping will not result in any misbehavior of tracing. With
per-cpu buffers it might result in ambiguity regarding sorting the
entries, but I guess chances are rather low this being a real issue.
BTW: wrapping of count is not related to buffer size, but to the
amount of trace data written.
Sure, but the chance of ambiguity increases with larger buffer sizes.
Well, better safe than sorry. Switching to unsigned long will rarely
hurt, so I'm going to do just that. The only downside will be some waste
of buffer space for very long running traces with huge amounts of
entries.
Hmm, true. Maybe we could get someone else's opinion on this - anyone?
TBH, I wouldn't be concerned about the buffer space. In case there are
really billions of entries, the difference between a 10-digit count
value and maybe a 15 digit one (and that is already a massive amount)
isn't that large. The average printed size of count with about
4 billion entries is 9.75 digits (and not just 5 :-) ).
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.2019 14:27, Juergen Gross wrote:
> On 05.09.19 14:22, Jan Beulich wrote:
>> On 05.09.2019 14:12, Juergen Gross wrote:
>>> On 05.09.19 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
> As a preparation for per-cpu buffers do a little refactoring of the
> debugtrace data: put the needed buffer admin data into the buffer as
> it will be needed for each buffer. In order not to limit buffer size
> switch the related fields from unsigned int to unsigned long, as on
> huge machines with RAM in the TB range it might be interesting to
> support buffers >4GB.
Just as a further remark in this regard:
>void debugtrace_printk(const char *fmt, ...)
>{
>static char buf[DEBUG_TRACE_ENTRY_SIZE];
> -static unsigned int count, last_count, last_prd;
> +static unsigned int count, last_count;
How long do we think will it take until their wrapping will become
an issue with such huge buffers?
>>>
>>> Count wrapping will not result in any misbehavior of tracing. With
>>> per-cpu buffers it might result in ambiguity regarding sorting the
>>> entries, but I guess chances are rather low this being a real issue.
>>>
>>> BTW: wrapping of count is not related to buffer size, but to the
>>> amount of trace data written.
>>
>> Sure, but the chance of ambiguity increases with larger buffer sizes.
>
> Well, better safe than sorry. Switching to unsigned long will rarely
> hurt, so I'm going to do just that. The only downside will be some waste
> of buffer space for very long running traces with huge amounts of
> entries.
Hmm, true. Maybe we could get someone else's opinion on this - anyone?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 2/4] xen: move debugtrace coding to common/debugtrace.c
On 05.09.19 14:20, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
--- /dev/null
+++ b/xen/common/debugtrace.c
@@ -0,0 +1,181 @@
+/**
+ * debugtrace.c
+ *
+ * Debugtrace for Xen
+ */
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEBUG_TRACE_ENTRY_SIZE 1024
+
+/* Send output direct to console, or buffer it? */
+static volatile int debugtrace_send_to_console;
+
+static char*debugtrace_buf; /* Debug-trace buffer */
+static unsigned int debugtrace_prd; /* Producer index */
+static unsigned int debugtrace_kilobytes = 128, debugtrace_bytes;
+static unsigned int debugtrace_used;
+static char debugtrace_last_entry_buf[DEBUG_TRACE_ENTRY_SIZE];
+static DEFINE_SPINLOCK(debugtrace_lock);
+integer_param("debugtrace", debugtrace_kilobytes);
+
+static void debugtrace_dump_worker(void)
And another remark here too, despite my prior ack: By moving this into
its own file, the debugtrace_ prefixes of static symbols now all
become redundant, at least as far as their occurrence in e.g. call
stacks goes (where they'd be prefixes by the disambiguating source
file name). But I know we've got ample other examples where this is
also the case, and I also know there are contrary opinions on the
matter, so this is not strictly a request for further change.
I'm one of the "contrary opinion" guys. :-)
So I'd rather keep the prefix.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.19 14:22, Jan Beulich wrote:
On 05.09.2019 14:12, Juergen Gross wrote:
On 05.09.19 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer. In order not to limit buffer size
switch the related fields from unsigned int to unsigned long, as on
huge machines with RAM in the TB range it might be interesting to
support buffers >4GB.
Just as a further remark in this regard:
void debugtrace_printk(const char *fmt, ...)
{
static char buf[DEBUG_TRACE_ENTRY_SIZE];
-static unsigned int count, last_count, last_prd;
+static unsigned int count, last_count;
How long do we think will it take until their wrapping will become
an issue with such huge buffers?
Count wrapping will not result in any misbehavior of tracing. With
per-cpu buffers it might result in ambiguity regarding sorting the
entries, but I guess chances are rather low this being a real issue.
BTW: wrapping of count is not related to buffer size, but to the
amount of trace data written.
Sure, but the chance of ambiguity increases with larger buffer sizes.
Well, better safe than sorry. Switching to unsigned long will rarely
hurt, so I'm going to do just that. The only downside will be some waste
of buffer space for very long running traces with huge amounts of
entries.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 141042: tolerable all pass - PUSHED
flight 141042 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141042/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen fa8f9792befc6ca4982d191b8b1e32f70087ee9d baseline version: xen 039e70668a12f1fccdd89058ac3e9755733d9082 Last test of basis 141019 2019-09-04 19:01:13 Z0 days Testing same since 141042 2019-09-05 09:01:45 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Juergen Gross Roger Pau Monné Tim Deegan jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 039e70668a..fa8f9792be fa8f9792befc6ca4982d191b8b1e32f70087ee9d -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.2019 14:19, Juergen Gross wrote:
> On 05.09.19 14:13, Jan Beulich wrote:
>> On 05.09.2019 13:39, Juergen Gross wrote:
>>> --- a/xen/common/debugtrace.c
>>> +++ b/xen/common/debugtrace.c
>>> @@ -17,34 +17,40 @@
>>> #define DEBUG_TRACE_ENTRY_SIZE 1024
>>>
>>> /* Send output direct to console, or buffer it? */
>>> -static volatile int debugtrace_send_to_console;
>>> +static volatile bool debugtrace_send_to_console;
>>>
>>> -static char*debugtrace_buf; /* Debug-trace buffer */
>>> -static unsigned int debugtrace_prd; /* Producer index */
>>> -static unsigned int debugtrace_kilobytes = 128, debugtrace_bytes;
>>> -static unsigned int debugtrace_used;
>>> +struct debugtrace_data {
>>> +unsigned long bytes; /* Size of buffer. */
>>
>> Hmm, I'm sorry for recognizing this only now, but why does this
>> field need replicating? It's the same in all instances of the
>> structure afaict.
>
> Oh, right. In the beginning I had plans to support modifying the buffer
> size at runtime.
>
> Okay, I'll change it.
Thanks. FAOD this is not going to invalidate any of my acks.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 1/4] xen: fix debugtrace clearing
On 05.09.19 14:17, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
After dumping the debugtrace buffer it is cleared. This results in some
entries not being printed in case the buffer is dumped again before
having wrapped.
While at it remove the trailing zero byte in the buffer as it is no
longer needed. Commit b5e6e1ee8da59f introduced passing the number of
chars to be printed in the related interfaces, so the trailing 0 byte
is no longer required.
Signed-off-by: Juergen Gross
Technically this is fine, so it can have my
Reviewed-by: Jan Beulich
However, ...
@@ -1173,6 +1175,7 @@ static char*debugtrace_buf; /* Debug-trace buffer
*/
static unsigned int debugtrace_prd; /* Producer index */
static unsigned int debugtrace_kilobytes = 128, debugtrace_bytes;
static unsigned int debugtrace_used;
+static char debugtrace_last_entry_buf[DEBUG_TRACE_ENTRY_SIZE];
... this is what I was afraid would happen, but I admit I didn't
reply in a way previously indicating that I dislike such a
solution. This is also why, when noticing the issue, I didn't put
together a patch myself right away. In particular I'm of the
opinion that the three last_* values would better all stay
together, and then would better stay inside the only function
using them.
@@ -1279,11 +1280,11 @@ void debugtrace_printk(const char *fmt, ...)
}
else
{
-if ( strcmp(buf, last_buf) )
+if ( strcmp(buf, debugtrace_last_entry_buf) )
Wouldn't moving count to file scope and latching its value into
a new dump_count when dumping work:
if ( count == dump_count || strcmp(buf, last_buf) )
work?
I'd rather have a bool which will be reset in above condition. This will
avoid problems when count is wrapping.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.2019 14:12, Juergen Gross wrote:
> On 05.09.19 14:01, Jan Beulich wrote:
>> On 05.09.2019 13:39, Juergen Gross wrote:
>>> As a preparation for per-cpu buffers do a little refactoring of the
>>> debugtrace data: put the needed buffer admin data into the buffer as
>>> it will be needed for each buffer. In order not to limit buffer size
>>> switch the related fields from unsigned int to unsigned long, as on
>>> huge machines with RAM in the TB range it might be interesting to
>>> support buffers >4GB.
>>
>> Just as a further remark in this regard:
>>
>>> void debugtrace_printk(const char *fmt, ...)
>>> {
>>> static char buf[DEBUG_TRACE_ENTRY_SIZE];
>>> -static unsigned int count, last_count, last_prd;
>>> +static unsigned int count, last_count;
>>
>> How long do we think will it take until their wrapping will become
>> an issue with such huge buffers?
>
> Count wrapping will not result in any misbehavior of tracing. With
> per-cpu buffers it might result in ambiguity regarding sorting the
> entries, but I guess chances are rather low this being a real issue.
>
> BTW: wrapping of count is not related to buffer size, but to the
> amount of trace data written.
Sure, but the chance of ambiguity increases with larger buffer sizes.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 2/4] xen: move debugtrace coding to common/debugtrace.c
On 05.09.2019 13:39, Juergen Gross wrote:
> --- /dev/null
> +++ b/xen/common/debugtrace.c
> @@ -0,0 +1,181 @@
> +/**
> + * debugtrace.c
> + *
> + * Debugtrace for Xen
> + */
> +
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DEBUG_TRACE_ENTRY_SIZE 1024
> +
> +/* Send output direct to console, or buffer it? */
> +static volatile int debugtrace_send_to_console;
> +
> +static char*debugtrace_buf; /* Debug-trace buffer */
> +static unsigned int debugtrace_prd; /* Producer index */
> +static unsigned int debugtrace_kilobytes = 128, debugtrace_bytes;
> +static unsigned int debugtrace_used;
> +static char debugtrace_last_entry_buf[DEBUG_TRACE_ENTRY_SIZE];
> +static DEFINE_SPINLOCK(debugtrace_lock);
> +integer_param("debugtrace", debugtrace_kilobytes);
> +
> +static void debugtrace_dump_worker(void)
And another remark here too, despite my prior ack: By moving this into
its own file, the debugtrace_ prefixes of static symbols now all
become redundant, at least as far as their occurrence in e.g. call
stacks goes (where they'd be prefixes by the disambiguating source
file name). But I know we've got ample other examples where this is
also the case, and I also know there are contrary opinions on the
matter, so this is not strictly a request for further change.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.19 14:13, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
--- a/xen/common/debugtrace.c
+++ b/xen/common/debugtrace.c
@@ -17,34 +17,40 @@
#define DEBUG_TRACE_ENTRY_SIZE 1024
/* Send output direct to console, or buffer it? */
-static volatile int debugtrace_send_to_console;
+static volatile bool debugtrace_send_to_console;
-static char*debugtrace_buf; /* Debug-trace buffer */
-static unsigned int debugtrace_prd; /* Producer index */
-static unsigned int debugtrace_kilobytes = 128, debugtrace_bytes;
-static unsigned int debugtrace_used;
+struct debugtrace_data {
+unsigned long bytes; /* Size of buffer. */
Hmm, I'm sorry for recognizing this only now, but why does this
field need replicating? It's the same in all instances of the
structure afaict.
Oh, right. In the beginning I had plans to support modifying the buffer
size at runtime.
Okay, I'll change it.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 1/4] xen: fix debugtrace clearing
On 05.09.2019 13:39, Juergen Gross wrote:
> After dumping the debugtrace buffer it is cleared. This results in some
> entries not being printed in case the buffer is dumped again before
> having wrapped.
>
> While at it remove the trailing zero byte in the buffer as it is no
> longer needed. Commit b5e6e1ee8da59f introduced passing the number of
> chars to be printed in the related interfaces, so the trailing 0 byte
> is no longer required.
>
> Signed-off-by: Juergen Gross
Technically this is fine, so it can have my
Reviewed-by: Jan Beulich
However, ...
> @@ -1173,6 +1175,7 @@ static char*debugtrace_buf; /* Debug-trace
> buffer */
> static unsigned int debugtrace_prd; /* Producer index */
> static unsigned int debugtrace_kilobytes = 128, debugtrace_bytes;
> static unsigned int debugtrace_used;
> +static char debugtrace_last_entry_buf[DEBUG_TRACE_ENTRY_SIZE];
... this is what I was afraid would happen, but I admit I didn't
reply in a way previously indicating that I dislike such a
solution. This is also why, when noticing the issue, I didn't put
together a patch myself right away. In particular I'm of the
opinion that the three last_* values would better all stay
together, and then would better stay inside the only function
using them.
> @@ -1279,11 +1280,11 @@ void debugtrace_printk(const char *fmt, ...)
> }
> else
> {
> -if ( strcmp(buf, last_buf) )
> +if ( strcmp(buf, debugtrace_last_entry_buf) )
Wouldn't moving count to file scope and latching its value into
a new dump_count when dumping work:
if ( count == dump_count || strcmp(buf, last_buf) )
work?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.2019 13:39, Juergen Gross wrote:
> --- a/xen/common/debugtrace.c
> +++ b/xen/common/debugtrace.c
> @@ -17,34 +17,40 @@
> #define DEBUG_TRACE_ENTRY_SIZE 1024
>
> /* Send output direct to console, or buffer it? */
> -static volatile int debugtrace_send_to_console;
> +static volatile bool debugtrace_send_to_console;
>
> -static char*debugtrace_buf; /* Debug-trace buffer */
> -static unsigned int debugtrace_prd; /* Producer index */
> -static unsigned int debugtrace_kilobytes = 128, debugtrace_bytes;
> -static unsigned int debugtrace_used;
> +struct debugtrace_data {
> +unsigned long bytes; /* Size of buffer. */
Hmm, I'm sorry for recognizing this only now, but why does this
field need replicating? It's the same in all instances of the
structure afaict.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.19 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer. In order not to limit buffer size
switch the related fields from unsigned int to unsigned long, as on
huge machines with RAM in the TB range it might be interesting to
support buffers >4GB.
Just as a further remark in this regard:
void debugtrace_printk(const char *fmt, ...)
{
static char buf[DEBUG_TRACE_ENTRY_SIZE];
-static unsigned int count, last_count, last_prd;
+static unsigned int count, last_count;
How long do we think will it take until their wrapping will become
an issue with such huge buffers?
Count wrapping will not result in any misbehavior of tracing. With
per-cpu buffers it might result in ambiguity regarding sorting the
entries, but I guess chances are rather low this being a real issue.
BTW: wrapping of count is not related to buffer size, but to the
amount of trace data written.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.2019 13:39, Juergen Gross wrote:
> As a preparation for per-cpu buffers do a little refactoring of the
> debugtrace data: put the needed buffer admin data into the buffer as
> it will be needed for each buffer. In order not to limit buffer size
> switch the related fields from unsigned int to unsigned long, as on
> huge machines with RAM in the TB range it might be interesting to
> support buffers >4GB.
Just as a further remark in this regard:
> void debugtrace_printk(const char *fmt, ...)
> {
> static char buf[DEBUG_TRACE_ENTRY_SIZE];
> -static unsigned int count, last_count, last_prd;
> +static unsigned int count, last_count;
How long do we think will it take until their wrapping will become
an issue with such huge buffers?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 4/4] xen: add per-cpu buffer option to debugtrace
On 05.09.2019 13:39, Juergen Gross wrote: > debugtrace is normally writing trace entries into a single trace > buffer. There are cases where this is not optimal, e.g. when hunting > a bug which requires writing lots of trace entries and one cpu is > stuck. This will result in other cpus filling the trace buffer and > finally overwriting the interesting trace entries of the hanging cpu. > > In order to be able to debug such situations add the capability to use > per-cpu trace buffers. This can be selected by specifying the > debugtrace boot parameter with the modifier "cpu:", like: > > debugtrace=cpu:16 > > At the same time switch the parsing function to accept size modifiers > (e.g. 4M or 1G). > > Printing out the trace entries is done for each buffer in order to > minimize the effort needed during printing. As each entry is prefixed > with its sequence number sorting the entries can easily be done when > analyzing them. > > Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/libxl: choose a sane default for HAP
On 9/5/19 12:01 PM, Roger Pau Monné wrote: > On Thu, Sep 05, 2019 at 12:34:11PM +0200, George Dunlap wrote: >> >> >>> On Sep 5, 2019, at 11:01 AM, Roger Pau Monne wrote: >>> >>> On Thu, Sep 05, 2019 at 11:52:59AM +0200, Jan Beulich wrote: On 05.09.2019 11:34, Roger Pau Monne wrote: > Current libxl code will always enable Hardware Assisted Paging (HAP), > expecting that the hypervisor will fallback to shadow if HAP is not > available. With the changes to the domain builder that's not the case > any longer, and the hypervisor will raise an error if HAP is not > available instead of silently falling back to shadow. Would it really be much more involved than the change here to restore silent defaulting to shadow? >>> >>> But that would mean that a user having selected hap=1 on the config >>> file would get silently defaulted to shadow, which is wrong IMO. >> >> At the libxl layer, aren’t the options tristate? I.e., this would be “hap”, >> “shadow”, or “not specified”? >> >> The user needs to be able to specify “always use shadow”, “always use HAP”, >> or “use HAP if available, otherwise use shadow”. > > The "use HAP if available, otherwise use shadow" is currently only > possibly expressed by not setting the hap option in the config file. > >> At the moment, leaving it empty should be “use HAP if available, otherwise >> use shadow”; so “hap = 1” should fail if HAP is not available. > > Right, this is what this patch is trying to accomplish. Right; I wasn't trying to contradict you so much as "weigh in" (and basically agree with you). -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 11/11] arm64: use asm-generic/dma-mapping.h
Now that the Xen special cases are gone nothing worth mentioning is
left in the arm64 file, so switch to use the
asm-generic version instead.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Reviewed-by: Stefano Stabellini
---
arch/arm64/include/asm/Kbuild| 1 +
arch/arm64/include/asm/dma-mapping.h | 22 --
arch/arm64/mm/dma-mapping.c | 1 +
3 files changed, 2 insertions(+), 22 deletions(-)
delete mode 100644 arch/arm64/include/asm/dma-mapping.h
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index c52e151afab0..98a5405c8558 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -4,6 +4,7 @@ generic-y += delay.h
generic-y += div64.h
generic-y += dma.h
generic-y += dma-contiguous.h
+generic-y += dma-mapping.h
generic-y += early_ioremap.h
generic-y += emergency-restart.h
generic-y += hw_irq.h
diff --git a/arch/arm64/include/asm/dma-mapping.h
b/arch/arm64/include/asm/dma-mapping.h
deleted file mode 100644
index 67243255a858..
--- a/arch/arm64/include/asm/dma-mapping.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright (C) 2012 ARM Ltd.
- */
-#ifndef __ASM_DMA_MAPPING_H
-#define __ASM_DMA_MAPPING_H
-
-#ifdef __KERNEL__
-
-#include
-#include
-
-#include
-#include
-
-static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
-{
- return NULL;
-}
-
-#endif /* __KERNEL__ */
-#endif /* __ASM_DMA_MAPPING_H */
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 4b244a037349..6578abcfbbc7 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 06/11] xen: remove the exports for xen_{create, destroy}_contiguous_region
These routines are only used by swiotlb-xen, which cannot be modular.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 2 --
arch/x86/xen/mmu_pv.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 11d5ad26fcfe..9d73fa4a5991 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -154,13 +154,11 @@ int xen_create_contiguous_region(phys_addr_t pstart,
unsigned int order,
*dma_handle = pstart;
return 0;
}
-EXPORT_SYMBOL_GPL(xen_create_contiguous_region);
void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
{
return;
}
-EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
int __init xen_mm_init(void)
{
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 26e8b326966d..c8dbee62ec2a 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2625,7 +2625,6 @@ int xen_create_contiguous_region(phys_addr_t pstart,
unsigned int order,
*dma_handle = virt_to_machine(vstart).maddr;
return success ? 0 : -ENOMEM;
}
-EXPORT_SYMBOL_GPL(xen_create_contiguous_region);
void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
{
@@ -2660,7 +2659,6 @@ void xen_destroy_contiguous_region(phys_addr_t pstart,
unsigned int order)
spin_unlock_irqrestore(_reservation_lock, flags);
}
-EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
static noinline void xen_flush_tlb_all(void)
{
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 09/11] swiotlb-xen: simplify cache maintainance
Now that we know we always have the dma-noncoherent.h helpers available
if we are on an architecture with support for non-coherent devices,
we can just call them directly, and remove the calls to the dma-direct
routines, including the fact that we call the dma_direct_map_page
routines but ignore the value returned from it. Instead we now have
Xen wrappers for the arch_sync_dma_for_{device,cpu} helpers that call
the special Xen versions of those routines for foreign pages.
Note that the new helpers get the physical address passed in addition
to the dma address to avoid another translation for the local cache
maintainance. The pfn_valid checks remain on the dma address as in
the old code, even if that looks a little funny.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
arch/arm/xen/mm.c| 64 +++-
arch/x86/include/asm/xen/page-coherent.h | 14 --
drivers/xen/swiotlb-xen.c| 20
include/xen/arm/page-coherent.h | 63 ---
include/xen/swiotlb-xen.h| 5 ++
5 files changed, 32 insertions(+), 134 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 9d73fa4a5991..2b2c208408bb 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -60,63 +60,33 @@ static void dma_cache_maint(dma_addr_t handle, size_t size,
u32 op)
} while (size);
}
-static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
- size_t size, enum dma_data_direction dir)
+/*
+ * Dom0 is mapped 1:1, and while the Linux page can span across multiple Xen
+ * pages, it is not possible for it to contain a mix of local and foreign Xen
+ * pages. Calling pfn_valid on a foreign mfn will always return false, so if
+ * pfn_valid returns true the pages is local and we can use the native
+ * dma-direct functions, otherwise we call the Xen specific version.
+ */
+void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle,
+ phys_addr_t paddr, size_t size, enum dma_data_direction dir)
{
- if (dir != DMA_TO_DEVICE)
+ if (pfn_valid(PFN_DOWN(handle)))
+ arch_sync_dma_for_cpu(dev, paddr, size, dir);
+ else if (dir != DMA_TO_DEVICE)
dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
}
-static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
- size_t size, enum dma_data_direction dir)
+void xen_dma_sync_for_device(struct device *dev, dma_addr_t handle,
+ phys_addr_t paddr, size_t size, enum dma_data_direction dir)
{
- if (dir == DMA_FROM_DEVICE)
+ if (pfn_valid(PFN_DOWN(handle)))
+ arch_sync_dma_for_device(dev, paddr, size, dir);
+ else if (dir == DMA_FROM_DEVICE)
dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
else
dma_cache_maint(handle, size, GNTTAB_CACHE_CLEAN);
}
-void __xen_dma_map_page(struct device *hwdev, struct page *page,
-dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, unsigned long attrs)
-{
- if (dev_is_dma_coherent(hwdev))
- return;
- if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
- return;
-
- __xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
-}
-
-void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
- size_t size, enum dma_data_direction dir,
- unsigned long attrs)
-
-{
- if (dev_is_dma_coherent(hwdev))
- return;
- if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
- return;
-
- __xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_cpu(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- if (dev_is_dma_coherent(hwdev))
- return;
- __xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_device(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- if (dev_is_dma_coherent(hwdev))
- return;
- __xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
-}
-
bool xen_arch_need_swiotlb(struct device *dev,
phys_addr_t phys,
dma_addr_t dev_addr)
diff --git a/arch/x86/include/asm/xen/page-coherent.h
b/arch/x86/include/asm/xen/page-coherent.h
index 116777e7f387..63cd41b2e17a 100644
--- a/arch/x86/include/asm/xen/page-coherent.h
+++ b/arch/x86/include/asm/xen/page-coherent.h
@@ -21,18 +21,4 @@ static inline void xen_free_coherent_pages(struct device
*hwdev, size_t size,
free_pages((unsigned long) cpu_addr, get_order(size));
}
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir,
[Xen-devel] [PATCH 10/11] swiotlb-xen: merge xen_unmap_single into xen_swiotlb_unmap_page
No need for a no-op wrapper.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index f81031f0c1c7..1190934098eb 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -418,9 +418,8 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev,
struct page *page,
* After this call, reads by the cpu to the buffer are guaranteed to see
* whatever the device wrote there.
*/
-static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
-size_t size, enum dma_data_direction dir,
-unsigned long attrs)
+static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
{
phys_addr_t paddr = xen_bus_to_phys(dev_addr);
@@ -434,13 +433,6 @@ static void xen_unmap_single(struct device *hwdev,
dma_addr_t dev_addr,
swiotlb_tbl_unmap_single(hwdev, paddr, size, dir, attrs);
}
-static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
- size_t size, enum dma_data_direction dir,
- unsigned long attrs)
-{
- xen_unmap_single(hwdev, dev_addr, size, dir, attrs);
-}
-
static void
xen_swiotlb_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir)
@@ -481,7 +473,8 @@ xen_swiotlb_unmap_sg(struct device *hwdev, struct
scatterlist *sgl, int nelems,
BUG_ON(dir == DMA_NONE);
for_each_sg(sgl, sg, nelems, i)
- xen_unmap_single(hwdev, sg->dma_address, sg_dma_len(sg), dir,
attrs);
+ xen_swiotlb_unmap_page(hwdev, sg->dma_address, sg_dma_len(sg),
+ dir, attrs);
}
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 05/11] xen/arm: remove xen_dma_ops
arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no
need for a pointer indirection.
Signed-off-by: Christoph Hellwig
Reviewed-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
arch/arm/mm/dma-mapping.c| 3 ++-
arch/arm/xen/mm.c| 4
arch/arm64/mm/dma-mapping.c | 3 ++-
include/xen/arm/hypervisor.h | 2 --
4 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 738097396445..2661cad36359 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "dma.h"
#include "mm.h"
@@ -2360,7 +2361,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base,
u64 size,
#ifdef CONFIG_XEN
if (xen_initial_domain())
- dev->dma_ops = xen_dma_ops;
+ dev->dma_ops = _swiotlb_dma_ops;
#endif
dev->archdata.dma_ops_setup = true;
}
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 2fde161733b0..11d5ad26fcfe 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -162,16 +162,12 @@ void xen_destroy_contiguous_region(phys_addr_t pstart,
unsigned int order)
}
EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
-const struct dma_map_ops *xen_dma_ops;
-EXPORT_SYMBOL(xen_dma_ops);
-
int __init xen_mm_init(void)
{
struct gnttab_cache_flush cflush;
if (!xen_initial_domain())
return 0;
xen_swiotlb_init(1, false);
- xen_dma_ops = _swiotlb_dma_ops;
cflush.op = 0;
cflush.a.dev_bus_addr = 0;
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index bd2b039f43a6..4b244a037349 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
@@ -64,6 +65,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64
size,
#ifdef CONFIG_XEN
if (xen_initial_domain())
- dev->dma_ops = xen_dma_ops;
+ dev->dma_ops = _swiotlb_dma_ops;
#endif
}
diff --git a/include/xen/arm/hypervisor.h b/include/xen/arm/hypervisor.h
index 2982571f7cc1..43ef24dd030e 100644
--- a/include/xen/arm/hypervisor.h
+++ b/include/xen/arm/hypervisor.h
@@ -19,8 +19,6 @@ static inline enum paravirt_lazy_mode
paravirt_get_lazy_mode(void)
return PARAVIRT_LAZY_NONE;
}
-extern const struct dma_map_ops *xen_dma_ops;
-
#ifdef CONFIG_XEN
void __init xen_early_init(void);
#else
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 02/11] xen/arm: consolidate page-coherent.h
Shared the duplicate arm/arm64 code in include/xen/arm/page-coherent.h.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/xen/page-coherent.h | 75
arch/arm64/include/asm/xen/page-coherent.h | 75
include/xen/arm/page-coherent.h| 80 ++
3 files changed, 80 insertions(+), 150 deletions(-)
diff --git a/arch/arm/include/asm/xen/page-coherent.h
b/arch/arm/include/asm/xen/page-coherent.h
index 602ac02f154c..27e984977402 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -1,77 +1,2 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_ARM_XEN_PAGE_COHERENT_H
-#define _ASM_ARM_XEN_PAGE_COHERENT_H
-
-#include
-#include
#include
-
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
- dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
-{
- return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
-{
- dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
-
- if (pfn_valid(pfn))
- dma_direct_sync_single_for_cpu(hwdev, handle, size, dir);
- else
- __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
-}
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
- if (pfn_valid(pfn))
- dma_direct_sync_single_for_device(hwdev, handle, size, dir);
- else
- __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
-}
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, unsigned long attrs)
-{
- unsigned long page_pfn = page_to_xen_pfn(page);
- unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
- unsigned long compound_pages =
- (1<
-#include
#include
-
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
- dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
-{
- return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
-{
- dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
-
- if (pfn_valid(pfn))
- dma_direct_sync_single_for_cpu(hwdev, handle, size, dir);
- else
- __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
-}
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
- if (pfn_valid(pfn))
- dma_direct_sync_single_for_device(hwdev, handle, size, dir);
- else
- __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
-}
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, unsigned long attrs)
-{
- unsigned long page_pfn = page_to_xen_pfn(page);
- unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
- unsigned long compound_pages =
- (1<
+#include
+
void __xen_dma_map_page(struct device *hwdev, struct page *page,
dma_addr_t dev_addr, unsigned long offset, size_t size,
enum dma_data_direction dir, unsigned long attrs);
@@ -13,4 +16,81 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
void __xen_dma_sync_single_for_device(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir);
+static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
+{
+ return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
+}
+
+static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
+ void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
+{
+ dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
+}
+
+static inline void
[Xen-devel] [PATCH 03/11] xen/arm: use dev_is_dma_coherent
Use the dma-noncoherent dev_is_dma_coherent helper instead of the home
grown variant. Note that both are always initialized to the same
value in arch_setup_dma_ops.
Signed-off-by: Christoph Hellwig
Reviewed-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
arch/arm/include/asm/dma-mapping.h | 6 --
arch/arm/xen/mm.c| 12 ++--
arch/arm64/include/asm/dma-mapping.h | 9 -
3 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index dba9355e2484..bdd80ddbca34 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -91,12 +91,6 @@ static inline dma_addr_t virt_to_dma(struct device *dev,
void *addr)
}
#endif
-/* do not use this function in a driver */
-static inline bool is_device_dma_coherent(struct device *dev)
-{
- return dev->archdata.dma_coherent;
-}
-
/**
* arm_dma_alloc - allocate consistent memory for DMA
* @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d33b77e9add3..90574d89d0d4 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
#include
-#include
+#include
#include
#include
#include
@@ -99,7 +99,7 @@ void __xen_dma_map_page(struct device *hwdev, struct page
*page,
dma_addr_t dev_addr, unsigned long offset, size_t size,
enum dma_data_direction dir, unsigned long attrs)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
return;
@@ -112,7 +112,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t
handle,
unsigned long attrs)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
return;
@@ -123,7 +123,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t
handle,
void __xen_dma_sync_single_for_cpu(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
}
@@ -131,7 +131,7 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
void __xen_dma_sync_single_for_device(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
}
@@ -159,7 +159,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
* memory and we are not able to flush the cache.
*/
return (!hypercall_cflush && (xen_pfn != bfn) &&
- !is_device_dma_coherent(dev));
+ !dev_is_dma_coherent(dev));
}
int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
diff --git a/arch/arm64/include/asm/dma-mapping.h
b/arch/arm64/include/asm/dma-mapping.h
index bdcb0922a40c..67243255a858 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -18,14 +18,5 @@ static inline const struct dma_map_ops
*get_arch_dma_ops(struct bus_type *bus)
return NULL;
}
-/*
- * Do not use this function in a driver, it is only provided for
- * arch/arm/mm/xen.c, which is used by arm64 as well.
- */
-static inline bool is_device_dma_coherent(struct device *dev)
-{
- return dev->dma_coherent;
-}
-
#endif /* __KERNEL__ */
#endif /* __ASM_DMA_MAPPING_H */
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 07/11] swiotlb-xen: remove xen_swiotlb_dma_mmap and xen_swiotlb_dma_get_sgtable
There is no need to wrap the common version, just wire them up directly.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 29 ++---
1 file changed, 2 insertions(+), 27 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index eee86cc7046b..b8808677ae1d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -547,31 +547,6 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
return xen_virt_to_bus(xen_io_tlb_end - 1) <= mask;
}
-/*
- * Create userspace mapping for the DMA-coherent memory.
- * This function should be called with the pages from the current domain only,
- * passing pages mapped from other domains would lead to memory corruption.
- */
-static int
-xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
-void *cpu_addr, dma_addr_t dma_addr, size_t size,
-unsigned long attrs)
-{
- return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
-}
-
-/*
- * This function should be called with the pages from the current domain only,
- * passing pages mapped from other domains would lead to memory corruption.
- */
-static int
-xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
- void *cpu_addr, dma_addr_t handle, size_t size,
- unsigned long attrs)
-{
- return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size, attrs);
-}
-
const struct dma_map_ops xen_swiotlb_dma_ops = {
.alloc = xen_swiotlb_alloc_coherent,
.free = xen_swiotlb_free_coherent,
@@ -584,6 +559,6 @@ const struct dma_map_ops xen_swiotlb_dma_ops = {
.map_page = xen_swiotlb_map_page,
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
- .mmap = xen_swiotlb_dma_mmap,
- .get_sgtable = xen_swiotlb_get_sgtable,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 08/11] swiotlb-xen: use the same foreign page check everywhere
xen_dma_map_page uses a different and more complicated check for foreign
pages than the other three cache maintainance helpers. Switch it to the
simpler pfn_valid method a well, and document the scheme with a single
improved comment in xen_dma_map_page.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
include/xen/arm/page-coherent.h | 31 +--
1 file changed, 9 insertions(+), 22 deletions(-)
diff --git a/include/xen/arm/page-coherent.h b/include/xen/arm/page-coherent.h
index a840d6949a87..a8d9c0678c27 100644
--- a/include/xen/arm/page-coherent.h
+++ b/include/xen/arm/page-coherent.h
@@ -53,23 +53,17 @@ static inline void xen_dma_map_page(struct device *hwdev,
struct page *page,
dma_addr_t dev_addr, unsigned long offset, size_t size,
enum dma_data_direction dir, unsigned long attrs)
{
- unsigned long page_pfn = page_to_xen_pfn(page);
- unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
- unsigned long compound_pages =
- (1
[Xen-devel] [PATCH 04/11] xen/arm: simplify dma_cache_maint
Calculate the required operation in the caller, and pass it directly
instead of recalculating it for each page, and use simple arithmetics
to get from the physical address to Xen page size aligned chunks.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 61 ---
1 file changed, 21 insertions(+), 40 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 90574d89d0d4..2fde161733b0 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -35,64 +35,45 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
return __get_free_pages(flags, order);
}
-enum dma_cache_op {
- DMA_UNMAP,
- DMA_MAP,
-};
static bool hypercall_cflush = false;
-/* functions called by SWIOTLB */
-
-static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
- size_t size, enum dma_data_direction dir, enum dma_cache_op op)
+/* buffers in highmem or foreign pages cannot cross page boundaries */
+static void dma_cache_maint(dma_addr_t handle, size_t size, u32 op)
{
struct gnttab_cache_flush cflush;
- unsigned long xen_pfn;
- size_t left = size;
- xen_pfn = (handle >> XEN_PAGE_SHIFT) + offset / XEN_PAGE_SIZE;
- offset %= XEN_PAGE_SIZE;
+ cflush.a.dev_bus_addr = handle & XEN_PAGE_MASK;
+ cflush.offset = xen_offset_in_page(handle);
+ cflush.op = op;
do {
- size_t len = left;
-
- /* buffers in highmem or foreign pages cannot cross page
-* boundaries */
- if (len + offset > XEN_PAGE_SIZE)
- len = XEN_PAGE_SIZE - offset;
-
- cflush.op = 0;
- cflush.a.dev_bus_addr = xen_pfn << XEN_PAGE_SHIFT;
- cflush.offset = offset;
- cflush.length = len;
-
- if (op == DMA_UNMAP && dir != DMA_TO_DEVICE)
- cflush.op = GNTTAB_CACHE_INVAL;
- if (op == DMA_MAP) {
- if (dir == DMA_FROM_DEVICE)
- cflush.op = GNTTAB_CACHE_INVAL;
- else
- cflush.op = GNTTAB_CACHE_CLEAN;
- }
- if (cflush.op)
- HYPERVISOR_grant_table_op(GNTTABOP_cache_flush,
, 1);
+ if (size + cflush.offset > XEN_PAGE_SIZE)
+ cflush.length = XEN_PAGE_SIZE - cflush.offset;
+ else
+ cflush.length = size;
+
+ HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, , 1);
- offset = 0;
- xen_pfn++;
- left -= len;
- } while (left);
+ cflush.offset = 0;
+ cflush.a.dev_bus_addr += cflush.length;
+ size -= cflush.length;
+ } while (size);
}
static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
{
- dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir,
DMA_UNMAP);
+ if (dir != DMA_TO_DEVICE)
+ dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
}
static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
{
- dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir,
DMA_MAP);
+ if (dir == DMA_FROM_DEVICE)
+ dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
+ else
+ dma_cache_maint(handle, size, GNTTAB_CACHE_CLEAN);
}
void __xen_dma_map_page(struct device *hwdev, struct page *page,
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 0/4] xen: debugtrace cleanup and per-cpu buffer support
Another debugtrace enhancement I needed for core scheduling debugging, plus some cleanup. Changes in V5: - several comments by Jan addressed (code: patches 1 and 4, commit message of patch 3) Changes in V4: - replaced patch 1 (original one was committed, new one requested by Jan Beulich) - several comments by Jan addressed Changes in V3: - rebase to current staging Changes in V2: - added new patch 1 (preparing the move of debugtrace coding) - patch 4 (v1 patch 3): avoid leaking buffer Juergen Gross (4): xen: fix debugtrace clearing xen: move debugtrace coding to common/debugtrace.c xen: refactor debugtrace data xen: add per-cpu buffer option to debugtrace docs/misc/xen-command-line.pandoc | 7 +- xen/common/Makefile | 1 + xen/common/debugtrace.c | 276 ++ xen/drivers/char/console.c| 178 +--- 4 files changed, 282 insertions(+), 180 deletions(-) create mode 100644 xen/common/debugtrace.c -- 2.16.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 1/4] xen: fix debugtrace clearing
After dumping the debugtrace buffer it is cleared. This results in some
entries not being printed in case the buffer is dumped again before
having wrapped.
While at it remove the trailing zero byte in the buffer as it is no
longer needed. Commit b5e6e1ee8da59f introduced passing the number of
chars to be printed in the related interfaces, so the trailing 0 byte
is no longer required.
Signed-off-by: Juergen Gross
---
V5:
- invalidate last_buf instead of last_prd after printing the buffer
(Jan Beulich)
---
xen/drivers/char/console.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index f49c6f29a8..8df627c84a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -1166,6 +1166,8 @@ int printk_ratelimit(void)
#ifdef CONFIG_DEBUG_TRACE
+#define DEBUG_TRACE_ENTRY_SIZE 1024
+
/* Send output direct to console, or buffer it? */
static volatile int debugtrace_send_to_console;
@@ -1173,6 +1175,7 @@ static char*debugtrace_buf; /* Debug-trace buffer
*/
static unsigned int debugtrace_prd; /* Producer index */
static unsigned int debugtrace_kilobytes = 128, debugtrace_bytes;
static unsigned int debugtrace_used;
+static char debugtrace_last_entry_buf[DEBUG_TRACE_ENTRY_SIZE];
static DEFINE_SPINLOCK(debugtrace_lock);
integer_param("debugtrace", debugtrace_kilobytes);
@@ -1184,16 +1187,17 @@ static void debugtrace_dump_worker(void)
printk("debugtrace_dump() starting\n");
/* Print oldest portion of the ring. */
-ASSERT(debugtrace_buf[debugtrace_bytes - 1] == 0);
if ( debugtrace_buf[debugtrace_prd] != '\0' )
console_serial_puts(_buf[debugtrace_prd],
-debugtrace_bytes - debugtrace_prd - 1);
+debugtrace_bytes - debugtrace_prd);
/* Print youngest portion of the ring. */
debugtrace_buf[debugtrace_prd] = '\0';
console_serial_puts(_buf[0], debugtrace_prd);
memset(debugtrace_buf, '\0', debugtrace_bytes);
+debugtrace_prd = 0;
+debugtrace_last_entry_buf[0] = 0;
printk("debugtrace_dump() finished\n");
}
@@ -1241,15 +1245,14 @@ static void debugtrace_add_to_buf(char *buf)
for ( p = buf; *p != '\0'; p++ )
{
debugtrace_buf[debugtrace_prd++] = *p;
-/* Always leave a nul byte at the end of the buffer. */
-if ( debugtrace_prd == (debugtrace_bytes - 1) )
+if ( debugtrace_prd == debugtrace_bytes )
debugtrace_prd = 0;
}
}
void debugtrace_printk(const char *fmt, ...)
{
-static char buf[1024], last_buf[1024];
+static char buf[DEBUG_TRACE_ENTRY_SIZE];
static unsigned int count, last_count, last_prd;
char cntbuf[24];
@@ -1264,8 +1267,6 @@ void debugtrace_printk(const char *fmt, ...)
spin_lock_irqsave(_lock, flags);
-ASSERT(debugtrace_buf[debugtrace_bytes - 1] == 0);
-
va_start(args, fmt);
nr = vscnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
@@ -1279,11 +1280,11 @@ void debugtrace_printk(const char *fmt, ...)
}
else
{
-if ( strcmp(buf, last_buf) )
+if ( strcmp(buf, debugtrace_last_entry_buf) )
{
last_prd = debugtrace_prd;
last_count = ++count;
-safe_strcpy(last_buf, buf);
+safe_strcpy(debugtrace_last_entry_buf, buf);
snprintf(cntbuf, sizeof(cntbuf), "%u ", count);
}
else
--
2.16.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer. In order not to limit buffer size
switch the related fields from unsigned int to unsigned long, as on
huge machines with RAM in the TB range it might be interesting to
support buffers >4GB.
While at it switch debugtrace_send_to_console and debugtrace_used to
bool and delete an empty line.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V4:
- renamed struct debugtrace_data_s (Jan Beulich)
- renamed debtr_data (Jan Beulich)
- remove unneeded condition (Jan Beulich)
- recalc debugtrace_bytes (Jan Beulich)
---
xen/common/debugtrace.c | 64 -
1 file changed, 37 insertions(+), 27 deletions(-)
diff --git a/xen/common/debugtrace.c b/xen/common/debugtrace.c
index c1ee3f45b9..0eeb1a77c5 100644
--- a/xen/common/debugtrace.c
+++ b/xen/common/debugtrace.c
@@ -17,34 +17,40 @@
#define DEBUG_TRACE_ENTRY_SIZE 1024
/* Send output direct to console, or buffer it? */
-static volatile int debugtrace_send_to_console;
+static volatile bool debugtrace_send_to_console;
-static char*debugtrace_buf; /* Debug-trace buffer */
-static unsigned int debugtrace_prd; /* Producer index */
-static unsigned int debugtrace_kilobytes = 128, debugtrace_bytes;
-static unsigned int debugtrace_used;
+struct debugtrace_data {
+unsigned long bytes; /* Size of buffer. */
+unsigned long prd; /* Producer index. */
+char buf[];
+};
+
+static struct debugtrace_data *dt_data;
+
+static unsigned int debugtrace_kilobytes = 128;
+static bool debugtrace_used;
static char debugtrace_last_entry_buf[DEBUG_TRACE_ENTRY_SIZE];
static DEFINE_SPINLOCK(debugtrace_lock);
integer_param("debugtrace", debugtrace_kilobytes);
static void debugtrace_dump_worker(void)
{
-if ( (debugtrace_bytes == 0) || !debugtrace_used )
+if ( !debugtrace_used )
return;
printk("debugtrace_dump() starting\n");
/* Print oldest portion of the ring. */
-if ( debugtrace_buf[debugtrace_prd] != '\0' )
-console_serial_puts(_buf[debugtrace_prd],
-debugtrace_bytes - debugtrace_prd);
+if ( dt_data->buf[dt_data->prd] != '\0' )
+console_serial_puts(_data->buf[dt_data->prd],
+dt_data->bytes - dt_data->prd);
/* Print youngest portion of the ring. */
-debugtrace_buf[debugtrace_prd] = '\0';
-console_serial_puts(_buf[0], debugtrace_prd);
+dt_data->buf[dt_data->prd] = '\0';
+console_serial_puts(_data->buf[0], dt_data->prd);
-memset(debugtrace_buf, '\0', debugtrace_bytes);
-debugtrace_prd = 0;
+memset(dt_data->buf, '\0', dt_data->bytes);
+dt_data->prd = 0;
debugtrace_last_entry_buf[0] = 0;
printk("debugtrace_dump() finished\n");
@@ -70,7 +76,6 @@ static void debugtrace_toggle(void)
spin_unlock_irqrestore(_lock, flags);
watchdog_enable();
-
}
void debugtrace_dump(void)
@@ -92,26 +97,27 @@ static void debugtrace_add_to_buf(char *buf)
for ( p = buf; *p != '\0'; p++ )
{
-debugtrace_buf[debugtrace_prd++] = *p;
-if ( debugtrace_prd == debugtrace_bytes )
-debugtrace_prd = 0;
+dt_data->buf[dt_data->prd++] = *p;
+if ( dt_data->prd == dt_data->bytes )
+dt_data->prd = 0;
}
}
void debugtrace_printk(const char *fmt, ...)
{
static char buf[DEBUG_TRACE_ENTRY_SIZE];
-static unsigned int count, last_count, last_prd;
+static unsigned int count, last_count;
+static unsigned long last_prd;
char cntbuf[24];
va_list args;
unsigned long flags;
unsigned int nr;
-if ( debugtrace_bytes == 0 )
+if ( !dt_data )
return;
-debugtrace_used = 1;
+debugtrace_used = true;
spin_lock_irqsave(_lock, flags);
@@ -130,14 +136,14 @@ void debugtrace_printk(const char *fmt, ...)
{
if ( strcmp(buf, debugtrace_last_entry_buf) )
{
-last_prd = debugtrace_prd;
+last_prd = dt_data->prd;
last_count = ++count;
safe_strcpy(debugtrace_last_entry_buf, buf);
snprintf(cntbuf, sizeof(cntbuf), "%u ", count);
}
else
{
-debugtrace_prd = last_prd;
+dt_data->prd = last_prd;
snprintf(cntbuf, sizeof(cntbuf), "%u-%u ", last_count, ++count);
}
debugtrace_add_to_buf(cntbuf);
@@ -155,7 +161,8 @@ static void debugtrace_key(unsigned char key)
static int __init debugtrace_init(void)
{
int order;
-unsigned int kbytes, bytes;
+unsigned long kbytes, bytes;
+struct debugtrace_data *data;
/* Round size down to next power of two. */
while ( (kbytes = (debugtrace_kilobytes & (debugtrace_kilobytes-1))) != 0 )
@@ -166,12 +173,15 @@ static int __init debugtrace_init(void)
[Xen-devel] [PATCH v5 2/4] xen: move debugtrace coding to common/debugtrace.c
Instead of living in drivers/char/console.c move the debugtrace
related coding to a new file common/debugtrace.c
No functional change, code movement only.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
---
xen/common/Makefile| 1 +
xen/common/debugtrace.c| 181 +
xen/drivers/char/console.c | 179 +---
3 files changed, 183 insertions(+), 178 deletions(-)
create mode 100644 xen/common/debugtrace.c
diff --git a/xen/common/Makefile b/xen/common/Makefile
index eddda5daa6..62b34e69e9 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -4,6 +4,7 @@ obj-y += bsearch.o
obj-$(CONFIG_CORE_PARKING) += core_parking.o
obj-y += cpu.o
obj-y += cpupool.o
+obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o
obj-y += domctl.o
obj-y += domain.o
diff --git a/xen/common/debugtrace.c b/xen/common/debugtrace.c
new file mode 100644
index 00..c1ee3f45b9
--- /dev/null
+++ b/xen/common/debugtrace.c
@@ -0,0 +1,181 @@
+/**
+ * debugtrace.c
+ *
+ * Debugtrace for Xen
+ */
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEBUG_TRACE_ENTRY_SIZE 1024
+
+/* Send output direct to console, or buffer it? */
+static volatile int debugtrace_send_to_console;
+
+static char*debugtrace_buf; /* Debug-trace buffer */
+static unsigned int debugtrace_prd; /* Producer index */
+static unsigned int debugtrace_kilobytes = 128, debugtrace_bytes;
+static unsigned int debugtrace_used;
+static char debugtrace_last_entry_buf[DEBUG_TRACE_ENTRY_SIZE];
+static DEFINE_SPINLOCK(debugtrace_lock);
+integer_param("debugtrace", debugtrace_kilobytes);
+
+static void debugtrace_dump_worker(void)
+{
+if ( (debugtrace_bytes == 0) || !debugtrace_used )
+return;
+
+printk("debugtrace_dump() starting\n");
+
+/* Print oldest portion of the ring. */
+if ( debugtrace_buf[debugtrace_prd] != '\0' )
+console_serial_puts(_buf[debugtrace_prd],
+debugtrace_bytes - debugtrace_prd);
+
+/* Print youngest portion of the ring. */
+debugtrace_buf[debugtrace_prd] = '\0';
+console_serial_puts(_buf[0], debugtrace_prd);
+
+memset(debugtrace_buf, '\0', debugtrace_bytes);
+debugtrace_prd = 0;
+debugtrace_last_entry_buf[0] = 0;
+
+printk("debugtrace_dump() finished\n");
+}
+
+static void debugtrace_toggle(void)
+{
+unsigned long flags;
+
+watchdog_disable();
+spin_lock_irqsave(_lock, flags);
+
+/*
+ * Dump the buffer *before* toggling, in case the act of dumping the
+ * buffer itself causes more printk() invocations.
+ */
+printk("debugtrace_printk now writing to %s.\n",
+ !debugtrace_send_to_console ? "console": "buffer");
+if ( !debugtrace_send_to_console )
+debugtrace_dump_worker();
+
+debugtrace_send_to_console = !debugtrace_send_to_console;
+
+spin_unlock_irqrestore(_lock, flags);
+watchdog_enable();
+
+}
+
+void debugtrace_dump(void)
+{
+unsigned long flags;
+
+watchdog_disable();
+spin_lock_irqsave(_lock, flags);
+
+debugtrace_dump_worker();
+
+spin_unlock_irqrestore(_lock, flags);
+watchdog_enable();
+}
+
+static void debugtrace_add_to_buf(char *buf)
+{
+char *p;
+
+for ( p = buf; *p != '\0'; p++ )
+{
+debugtrace_buf[debugtrace_prd++] = *p;
+if ( debugtrace_prd == debugtrace_bytes )
+debugtrace_prd = 0;
+}
+}
+
+void debugtrace_printk(const char *fmt, ...)
+{
+static char buf[DEBUG_TRACE_ENTRY_SIZE];
+static unsigned int count, last_count, last_prd;
+
+char cntbuf[24];
+va_list args;
+unsigned long flags;
+unsigned int nr;
+
+if ( debugtrace_bytes == 0 )
+return;
+
+debugtrace_used = 1;
+
+spin_lock_irqsave(_lock, flags);
+
+va_start(args, fmt);
+nr = vsnprintf(buf, sizeof(buf), fmt, args);
+va_end(args);
+
+if ( debugtrace_send_to_console )
+{
+unsigned int n = scnprintf(cntbuf, sizeof(cntbuf), "%u ", ++count);
+
+console_serial_puts(cntbuf, n);
+console_serial_puts(buf, nr);
+}
+else
+{
+if ( strcmp(buf, debugtrace_last_entry_buf) )
+{
+last_prd = debugtrace_prd;
+last_count = ++count;
+safe_strcpy(debugtrace_last_entry_buf, buf);
+snprintf(cntbuf, sizeof(cntbuf), "%u ", count);
+}
+else
+{
+debugtrace_prd = last_prd;
+snprintf(cntbuf, sizeof(cntbuf), "%u-%u ", last_count, ++count);
+}
+debugtrace_add_to_buf(cntbuf);
+debugtrace_add_to_buf(buf);
+}
+
+spin_unlock_irqrestore(_lock, flags);
+}
+
+static void debugtrace_key(unsigned char key)
+{
+debugtrace_toggle();
+}
+
+static int __init
[Xen-devel] [PATCH v5 4/4] xen: add per-cpu buffer option to debugtrace
debugtrace is normally writing trace entries into a single trace
buffer. There are cases where this is not optimal, e.g. when hunting
a bug which requires writing lots of trace entries and one cpu is
stuck. This will result in other cpus filling the trace buffer and
finally overwriting the interesting trace entries of the hanging cpu.
In order to be able to debug such situations add the capability to use
per-cpu trace buffers. This can be selected by specifying the
debugtrace boot parameter with the modifier "cpu:", like:
debugtrace=cpu:16
At the same time switch the parsing function to accept size modifiers
(e.g. 4M or 1G).
Printing out the trace entries is done for each buffer in order to
minimize the effort needed during printing. As each entry is prefixed
with its sequence number sorting the entries can easily be done when
analyzing them.
Signed-off-by: Juergen Gross
---
V2:
- only allocate buffer if not already done so
V4:
- unsigned int -> unsigned long (Jan Beulich)
- replace check for bytes < PAGE_SIZE by !bytes (Jan Beulich)
- print info which buffer allocation failed (Jan Beulich)
- replace switch by if in cpu notifier handler (Jan Beulich)
V5:
- don't silently ignore trailing characters when parsing buffer size
(Jan Beulich)
- limit scope of some variables (Jan Beulich)
- adjust error message format (Jan Beulich)
---
docs/misc/xen-command-line.pandoc | 7 +-
xen/common/debugtrace.c | 159 +-
2 files changed, 126 insertions(+), 40 deletions(-)
diff --git a/docs/misc/xen-command-line.pandoc
b/docs/misc/xen-command-line.pandoc
index 7c72e31032..832797e2e2 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -644,12 +644,13 @@ over the PCI busses sequentially) or by PCI device (must
be on segment 0).
Limits the number lines printed in Xen stack traces.
### debugtrace
-> `= `
+> `= [cpu:]`
> Default: `128`
-Specify the size of the console debug trace buffer in KiB. The debug
-trace feature is only enabled in debugging builds of Xen.
+Specify the size of the console debug trace buffer. By specifying `cpu:`
+additionally a trace buffer of the specified size is allocated per cpu.
+The debug trace feature is only enabled in debugging builds of Xen.
### dma_bits
> `= `
diff --git a/xen/common/debugtrace.c b/xen/common/debugtrace.c
index 0eeb1a77c5..3467fc7363 100644
--- a/xen/common/debugtrace.c
+++ b/xen/common/debugtrace.c
@@ -6,6 +6,7 @@
#include
+#include
#include
#include
#include
@@ -26,34 +27,74 @@ struct debugtrace_data {
};
static struct debugtrace_data *dt_data;
+static DEFINE_PER_CPU(struct debugtrace_data *, dt_cpu_data);
-static unsigned int debugtrace_kilobytes = 128;
+static unsigned long debugtrace_bytes = 128 << 10;
+static bool debugtrace_per_cpu;
static bool debugtrace_used;
static char debugtrace_last_entry_buf[DEBUG_TRACE_ENTRY_SIZE];
static DEFINE_SPINLOCK(debugtrace_lock);
-integer_param("debugtrace", debugtrace_kilobytes);
-static void debugtrace_dump_worker(void)
+static int __init debugtrace_parse_param(const char *s)
{
-if ( !debugtrace_used )
+unsigned long bytes;
+
+if ( !strncmp(s, "cpu:", 4) )
+{
+debugtrace_per_cpu = true;
+s += 4;
+}
+bytes = parse_size_and_unit(s, );
+
+if ( *s )
+return -EINVAL;
+
+debugtrace_bytes = bytes;
+
+return 0;
+}
+custom_param("debugtrace", debugtrace_parse_param);
+
+static void debugtrace_dump_buffer(struct debugtrace_data *data,
+ const char *which)
+{
+if ( !data )
return;
-printk("debugtrace_dump() starting\n");
+printk("debugtrace_dump() %s buffer starting\n", which);
/* Print oldest portion of the ring. */
-if ( dt_data->buf[dt_data->prd] != '\0' )
-console_serial_puts(_data->buf[dt_data->prd],
-dt_data->bytes - dt_data->prd);
+if ( data->buf[data->prd] != '\0' )
+console_serial_puts(>buf[data->prd], data->bytes - data->prd);
/* Print youngest portion of the ring. */
-dt_data->buf[dt_data->prd] = '\0';
-console_serial_puts(_data->buf[0], dt_data->prd);
+data->buf[data->prd] = '\0';
+console_serial_puts(>buf[0], data->prd);
-memset(dt_data->buf, '\0', dt_data->bytes);
-dt_data->prd = 0;
-debugtrace_last_entry_buf[0] = 0;
+memset(data->buf, '\0', data->bytes);
+data->prd = 0;
+
+printk("debugtrace_dump() %s buffer finished\n", which);
+}
+
+static void debugtrace_dump_worker(void)
+{
+unsigned int cpu;
+
+if ( !debugtrace_used )
+return;
+
+debugtrace_dump_buffer(dt_data, "global");
-printk("debugtrace_dump() finished\n");
+for ( cpu = 0; cpu < nr_cpu_ids; cpu++ )
+{
+char buf[16];
+
+snprintf(buf, sizeof(buf), "cpu %u", cpu);
+debugtrace_dump_buffer(per_cpu(dt_cpu_data, cpu), buf);
+}
+
+debugtrace_last_entry_buf[0] =
[Xen-devel] [PATCH 01/11] xen/arm: use dma-noncoherent.h calls for xen-swiotlb cache maintainance
Copy the arm64 code that uses the dma-direct/swiotlb helpers for DMA
on-coherent devices.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/device.h| 3 -
arch/arm/include/asm/xen/page-coherent.h | 72 +---
arch/arm/mm/dma-mapping.c| 8 +--
drivers/xen/swiotlb-xen.c| 20 ---
4 files changed, 28 insertions(+), 75 deletions(-)
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index f6955b55c544..c675bc0d5aa8 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -14,9 +14,6 @@ struct dev_archdata {
#endif
#ifdef CONFIG_ARM_DMA_USE_IOMMU
struct dma_iommu_mapping*mapping;
-#endif
-#ifdef CONFIG_XEN
- const struct dma_map_ops *dev_dma_ops;
#endif
unsigned int dma_coherent:1;
unsigned int dma_ops_setup:1;
diff --git a/arch/arm/include/asm/xen/page-coherent.h
b/arch/arm/include/asm/xen/page-coherent.h
index 2c403e7c782d..602ac02f154c 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -6,23 +6,37 @@
#include
#include
-static inline const struct dma_map_ops *xen_get_dma_ops(struct device *dev)
-{
- if (dev && dev->archdata.dev_dma_ops)
- return dev->archdata.dev_dma_ops;
- return get_arch_dma_ops(NULL);
-}
-
static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
{
- return xen_get_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags,
attrs);
+ return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
}
static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
{
- xen_get_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
+ dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
+}
+
+static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ unsigned long pfn = PFN_DOWN(handle);
+
+ if (pfn_valid(pfn))
+ dma_direct_sync_single_for_cpu(hwdev, handle, size, dir);
+ else
+ __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
+}
+
+static inline void xen_dma_sync_single_for_device(struct device *hwdev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ unsigned long pfn = PFN_DOWN(handle);
+ if (pfn_valid(pfn))
+ dma_direct_sync_single_for_device(hwdev, handle, size, dir);
+ else
+ __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
}
static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
@@ -36,17 +50,8 @@ static inline void xen_dma_map_page(struct device *hwdev,
struct page *page,
bool local = (page_pfn <= dev_pfn) &&
(dev_pfn - page_pfn < compound_pages);
- /*
-* Dom0 is mapped 1:1, while the Linux page can span across
-* multiple Xen pages, it's not possible for it to contain a
-* mix of local and foreign Xen pages. So if the first xen_pfn
-* == mfn the page is local otherwise it's a foreign page
-* grant-mapped in dom0. If the page is local we can safely
-* call the native dma_ops function, otherwise we call the xen
-* specific function.
-*/
if (local)
- xen_get_dma_ops(hwdev)->map_page(hwdev, page, offset, size,
dir, attrs);
+ dma_direct_map_page(hwdev, page, offset, size, dir, attrs);
else
__xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir,
attrs);
}
@@ -63,33 +68,10 @@ static inline void xen_dma_unmap_page(struct device *hwdev,
dma_addr_t handle,
* safely call the native dma_ops function, otherwise we call the xen
* specific function.
*/
- if (pfn_valid(pfn)) {
- if (xen_get_dma_ops(hwdev)->unmap_page)
- xen_get_dma_ops(hwdev)->unmap_page(hwdev, handle, size,
dir, attrs);
- } else
+ if (pfn_valid(pfn))
+ dma_direct_unmap_page(hwdev, handle, size, dir, attrs);
+ else
__xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
}
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
- if (pfn_valid(pfn)) {
- if (xen_get_dma_ops(hwdev)->sync_single_for_cpu)
- xen_get_dma_ops(hwdev)->sync_single_for_cpu(hwdev,
handle, size, dir);
- } else
- __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
-}
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
-
[Xen-devel] swiotlb-xen cleanups v4
Hi Xen maintainers and friends, please take a look at this series that cleans up the parts of swiotlb-xen that deal with non-coherent caches. Changes since v3: - don't use dma_direct_alloc on x86 Changes since v2: - further dma_cache_maint improvements - split the previous patch 1 into 3 patches Changes since v1: - rewrite dma_cache_maint to be much simpler - improve various comments and commit logs - remove page-coherent.h entirely ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/2] x86/AMD: Fix handling of x87 exception pointers on Fam17h hardware
On 05/09/2019 10:00, Jan Beulich wrote:
> On 04.09.2019 19:57, Andrew Cooper wrote:
>> AMD Pre-Fam17h CPUs "optimise" {F,}X{SAVE,RSTOR} by not saving/restoring
>> FOP/FIP/FDP if an x87 exception isn't pending. This causes an information
>> leak, CVE-2006-1056, and worked around by several OSes, including Xen. AMD
>> Fam17h CPUs no longer have this leak, and advertise so in a CPUID bit.
>>
>> Introduce the RSTR_FP_ERR_PTRS feature, as specified by AMD, and expose to
>> all
>> guests by default. While adjusting libxl's cpuid table, add CLZERO which
>> looks to have been omitted previously.
>>
>> Also introduce an X86_BUG bit to trigger the (F)XRSTOR workaround, and set it
>> on AMD hardware where RSTR_FP_ERR_PTRS is not advertised. Optimise the
>> conditions for the workaround paths.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
> irrespective of a few remarks:
>
>> v3:
>> * Rename to X86_BUG_FPU_PTRS
> While I did agree to use this name, I'd still like to point out that
> whether or not this is viewed as a bug is a matter of the position
> one takes. I'm pretty sure the AMD engineers originally having decided
> to avoid saving/restoring these value wouldn't have called this a bug,
> but a feature.
I accept that different people might have different opinions on the
matter, but at the point that we and every other large software vendor
has issued a security fix because of it, it can't credibly be called a
feature, irrespective of the original intention.
The change of behaviour on Fam17h is either tacit agreement with this
point, or at least a begrudging acceptance that the only way the
workaround is going to go away is by changing the behaviour of the CPU.
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -580,6 +580,13 @@ static void init_amd(struct cpuinfo_x86 *c)
>> }
>>
>> /*
>> + * Older AMD CPUs don't save/load FOP/FIP/FDP unless an FPU exception
>> + * is pending. Xen works around this at (F)XRSTOR time.
>> + */
>> +if ( !cpu_has(c, X86_FEATURE_RSTR_FP_ERR_PTRS) )
>> +setup_force_cpu_cap(X86_BUG_FPU_PTRS);
> I think in this file you want to omit the blanks immediately inside
> the if() parentheses.
Oops yes.
>
>> @@ -169,11 +167,11 @@ static inline void fpu_fxsave(struct vcpu *v)
>> : "=m" (*fpu_ctxt) : "R" (fpu_ctxt) );
>>
>> /*
>> - * AMD CPUs don't save/restore FDP/FIP/FOP unless an exception
>> - * is pending.
>> + * Some CPUs don't save/restore FDP/FIP/FOP unless an exception is
>> + * pending. In this case, the restore side will arrange safe
>> values,
>> + * and there is no point trying to restore FCS/FDS in addition.
>> */
>> -if ( !(fpu_ctxt->fsw & 0x0080) &&
>> - boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
>> +if ( cpu_bug_fpu_ptrs && !(fpu_ctxt->fsw & 0x0080) )
>> return;
> Could I talk you into s/trying to restore/trying to collect/ for the
> comment? The consumer of the collected data could in principle be
> other than the corresponding restore code, e.g. the insn emulator.
> (hvmemul_put_fpu() has an example of the opposite direction, i.e.
> producing data for the restore logic to consume.)
Ok.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH -tip 0/2] x86: Prohibit kprobes on XEN_EMULATE_PREFIX
On Thu, 5 Sep 2019 08:54:17 +0100 Andrew Cooper wrote: > On 05/09/2019 02:49, Masami Hiramatsu wrote: > > On Wed, 4 Sep 2019 12:54:55 +0100 > > Andrew Cooper wrote: > > > >> On 04/09/2019 12:45, Masami Hiramatsu wrote: > >>> Hi, > >>> > >>> These patches allow x86 instruction decoder to decode > >>> xen-cpuid which has XEN_EMULATE_PREFIX, and prohibit > >>> kprobes to probe on it. > >>> > >>> Josh reported that the objtool can not decode such special > >>> prefixed instructions, and I found that we also have to > >>> prohibit kprobes to probe on such instruction. > >>> > >>> This series can be applied on -tip master branch which > >>> has merged Josh's objtool/perf sharing common x86 insn > >>> decoder series. > >> The paravirtualised xen-cpuid is were you'll see it most in a regular > >> kernel, but be aware that it is also used for testing purposes in other > >> circumstances, and there is an equivalent KVM prefix which is used for > >> KVM testing. > > Good catch! I didn't notice that. Is that really same sequance or KVM uses > > another sequence of instructions for KVM prefix? > > I don't know if you've spotted, but the prefix is a ud2a instruction > followed by 'xen' in ascii. > > The KVM version was added in c/s 6c86eedc206dd1f9d37a2796faa8e6f2278215d2 > Ah, OK. I see it. But it seems that another ud0/ud1 can be used by other (new) virtualization. So at this moment I will just add a sequence as a pattern of prefix. Not use a fixed ud2 + sig. Thank you, > > > >> It might be better to generalise the decode support to "virtualisation > >> escape prefix" or something slightly more generic. > > Agreed, it is easy to expand it, we can switch the prefix template. > > Could you tell me where I should look? I will add it. > > These are the only two I'm aware of. > > ~Andrew -- Masami Hiramatsu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/libxl: choose a sane default for HAP
On Thu, Sep 05, 2019 at 12:34:11PM +0200, George Dunlap wrote: > > > > On Sep 5, 2019, at 11:01 AM, Roger Pau Monne wrote: > > > > On Thu, Sep 05, 2019 at 11:52:59AM +0200, Jan Beulich wrote: > >> On 05.09.2019 11:34, Roger Pau Monne wrote: > >>> Current libxl code will always enable Hardware Assisted Paging (HAP), > >>> expecting that the hypervisor will fallback to shadow if HAP is not > >>> available. With the changes to the domain builder that's not the case > >>> any longer, and the hypervisor will raise an error if HAP is not > >>> available instead of silently falling back to shadow. > >> > >> Would it really be much more involved than the change here to restore > >> silent defaulting to shadow? > > > > But that would mean that a user having selected hap=1 on the config > > file would get silently defaulted to shadow, which is wrong IMO. > > At the libxl layer, aren’t the options tristate? I.e., this would be “hap”, > “shadow”, or “not specified”? > > The user needs to be able to specify “always use shadow”, “always use HAP”, > or “use HAP if available, otherwise use shadow”. The "use HAP if available, otherwise use shadow" is currently only possibly expressed by not setting the hap option in the config file. > At the moment, leaving it empty should be “use HAP if available, otherwise > use shadow”; so “hap = 1” should fail if HAP is not available. Right, this is what this patch is trying to accomplish. I have a v2 series which fills the capabilities field for ARM and also reports the hap capability in `xl info`. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 4/4] xen: add per-cpu buffer option to debugtrace
On 05.09.19 12:28, Jan Beulich wrote:
On 04.09.2019 15:46, Juergen Gross wrote:
@@ -25,33 +26,63 @@ struct debugtrace_data {
};
static struct debugtrace_data *dt_data;
+static DEFINE_PER_CPU(struct debugtrace_data *, dt_cpu_data);
-static unsigned int debugtrace_kilobytes = 128;
+static unsigned long debugtrace_bytes = 128 << 10;
+static bool debugtrace_per_cpu;
static bool debugtrace_used;
static DEFINE_SPINLOCK(debugtrace_lock);
-integer_param("debugtrace", debugtrace_kilobytes);
-static void debugtrace_dump_worker(void)
+static int __init debugtrace_parse_param(const char *s)
{
-if ( !debugtrace_used )
+if ( !strncmp(s, "cpu:", 4) )
+{
+debugtrace_per_cpu = true;
+s += 4;
+}
+debugtrace_bytes = parse_size_and_unit(s, NULL);
I'm afraid you can't pass NULL here, or a trailing % will be at best
ambiguous. In fact, the latest with the addition of % support to the
function I can't see (anymore) how calling the function with a NULL
2nd arg can be a good idea at all.
NP to change that.
+static void debugtrace_dump_worker(void)
+{
+unsigned int cpu;
+char buf[16];
+
+if ( !debugtrace_used )
+return;
+
+debugtrace_dump_buffer(dt_data, "global");
+
+for ( cpu = 0; cpu < nr_cpu_ids; cpu++ )
+{
+snprintf(buf, sizeof(buf), "cpu %u", cpu);
+debugtrace_dump_buffer(per_cpu(dt_cpu_data, cpu), buf);
+}
I think it would be nice if buf[]'s scope was just the for() body.
Okay.
void debugtrace_printk(const char *fmt, ...)
{
static char buf[1024], last_buf[1024];
-static unsigned int count, last_count;
+static unsigned int count, last_count, last_cpu;
char cntbuf[24];
va_list args;
unsigned long flags;
unsigned int nr;
+struct debugtrace_data *data;
+unsigned int cpu;
-if ( !dt_data )
+data = debugtrace_per_cpu ? this_cpu(dt_cpu_data) : dt_data;
+cpu = debugtrace_per_cpu ? smp_processor_id() : 0;
You use "cpu" only ...
@@ -131,16 +169,17 @@ void debugtrace_printk(const char *fmt, ...)
}
else
{
-if ( strcmp(buf, last_buf) )
+if ( strcmp(buf, last_buf) || cpu != last_cpu )
{
-dt_data->prd_last = dt_data->prd;
+data->prd_last = data->prd;
last_count = ++count;
+last_cpu = cpu;
safe_strcpy(last_buf, buf);
snprintf(cntbuf, sizeof(cntbuf), "%u ", count);
}
else
{
-dt_data->prd = dt_data->prd_last;
+data->prd = data->prd_last;
snprintf(cntbuf, sizeof(cntbuf), "%u-%u ", last_count, ++count);
}
debugtrace_add_to_buf(cntbuf);
.. in this scope, so perhaps worth latching (and declaring) it only
inside the first "else" above?
Fine with me.
@@ -155,34 +194,70 @@ static void debugtrace_key(unsigned char key)
debugtrace_toggle();
}
-static int __init debugtrace_init(void)
+static void debugtrace_alloc_buffer(struct debugtrace_data **ptr,
+unsigned int cpu)
{
int order;
-unsigned long kbytes, bytes;
struct debugtrace_data *data;
-/* Round size down to next power of two. */
-while ( (kbytes = (debugtrace_kilobytes & (debugtrace_kilobytes-1))) != 0 )
-debugtrace_kilobytes = kbytes;
-
-bytes = debugtrace_kilobytes << 10;
-if ( bytes == 0 )
-return 0;
+if ( !debugtrace_bytes || *ptr )
+return;
-order = get_order_from_bytes(bytes);
+order = get_order_from_bytes(debugtrace_bytes);
data = alloc_xenheap_pages(order, 0);
if ( !data )
-return -ENOMEM;
+{
+if ( debugtrace_per_cpu )
+printk("failed to allocate debugtrace buffer for cpu %u\n", cpu);
Could I talk you into using the more common "CPU%u: ..." layout here?
Sure.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/libxl: choose a sane default for HAP
On 05/09/2019 11:32, Jan Beulich wrote: > On 05.09.2019 12:01, Roger Pau Monné wrote: >> On Thu, Sep 05, 2019 at 11:52:59AM +0200, Jan Beulich wrote: >>> On 05.09.2019 11:34, Roger Pau Monne wrote: Current libxl code will always enable Hardware Assisted Paging (HAP), expecting that the hypervisor will fallback to shadow if HAP is not available. With the changes to the domain builder that's not the case any longer, and the hypervisor will raise an error if HAP is not available instead of silently falling back to shadow. >>> Would it really be much more involved than the change here to restore >>> silent defaulting to shadow? >> But that would mean that a user having selected hap=1 on the config >> file would get silently defaulted to shadow, which is wrong IMO. > Since you and Andrew agree, so be it. Personally I'd like it better > if "hap=1" didn't prevent a domain from starting on a HAP-incapable > host. I wouldn't mind a warning though. Behaviour like that could be arranged in libxl, which now has all the requisite pieces. What I'm not happy with is xc_domain_create() asking for a HAP domain and getting silently getting a shadow one. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/libxl: choose a sane default for HAP
> On Sep 5, 2019, at 11:01 AM, Roger Pau Monne wrote: > > On Thu, Sep 05, 2019 at 11:52:59AM +0200, Jan Beulich wrote: >> On 05.09.2019 11:34, Roger Pau Monne wrote: >>> Current libxl code will always enable Hardware Assisted Paging (HAP), >>> expecting that the hypervisor will fallback to shadow if HAP is not >>> available. With the changes to the domain builder that's not the case >>> any longer, and the hypervisor will raise an error if HAP is not >>> available instead of silently falling back to shadow. >> >> Would it really be much more involved than the change here to restore >> silent defaulting to shadow? > > But that would mean that a user having selected hap=1 on the config > file would get silently defaulted to shadow, which is wrong IMO. At the libxl layer, aren’t the options tristate? I.e., this would be “hap”, “shadow”, or “not specified”? The user needs to be able to specify “always use shadow”, “always use HAP”, or “use HAP if available, otherwise use shadow”. At the moment, leaving it empty should be “use HAP if available, otherwise use shadow”; so “hap = 1” should fail if HAP is not available. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/libxl: choose a sane default for HAP
On 05.09.2019 12:01, Roger Pau Monné wrote: > On Thu, Sep 05, 2019 at 11:52:59AM +0200, Jan Beulich wrote: >> On 05.09.2019 11:34, Roger Pau Monne wrote: >>> Current libxl code will always enable Hardware Assisted Paging (HAP), >>> expecting that the hypervisor will fallback to shadow if HAP is not >>> available. With the changes to the domain builder that's not the case >>> any longer, and the hypervisor will raise an error if HAP is not >>> available instead of silently falling back to shadow. >> >> Would it really be much more involved than the change here to restore >> silent defaulting to shadow? > > But that would mean that a user having selected hap=1 on the config > file would get silently defaulted to shadow, which is wrong IMO. Since you and Andrew agree, so be it. Personally I'd like it better if "hap=1" didn't prevent a domain from starting on a HAP-incapable host. I wouldn't mind a warning though. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 3/4] xen: refactor debugtrace data
On 05.09.19 12:06, Jan Beulich wrote:
On 04.09.2019 15:46, Juergen Gross wrote:
--- a/xen/common/debugtrace.c
+++ b/xen/common/debugtrace.c
@@ -15,35 +15,41 @@
#include
/* Send output direct to console, or buffer it? */
-static volatile int debugtrace_send_to_console;
+static volatile bool debugtrace_send_to_console;
-static char*debugtrace_buf; /* Debug-trace buffer */
-static unsigned int debugtrace_prd; /* Producer index */
-static unsigned int debugtrace_prd_last;
-static unsigned int debugtrace_kilobytes = 128, debugtrace_bytes;
-static unsigned int debugtrace_used;
+struct debugtrace_data {
+unsigned long bytes; /* Size of buffer. */
+unsigned long prd; /* Producer index. */
+unsigned long prd_last;
I'd still like this change from int to long mentioned / justified
in the description. With this
Reviewed-by: Jan Beulich
Okay, thanks.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
