[Xen-devel] [seabios test] 124771: trouble: blocked/broken
flight 124771 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/124771/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvopsbroken build-i386-pvops broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-xsm broken build-i386-xsm4 host-install(4)broken REGR. vs. 124521 build-amd64-xsm 4 host-install(4)broken REGR. vs. 124521 build-amd64-pvops 4 host-install(4)broken REGR. vs. 124521 build-amd64 4 host-install(4)broken REGR. vs. 124521 build-i386-pvops 4 host-install(4)broken REGR. vs. 124521 build-i3864 host-install(4)broken REGR. vs. 124521 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-qemuu-nested-amd 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-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 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-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-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-amd64-xl-qemuu-win10-i386 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-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a version targeted for testing: seabios 69ea6dabeba4e080fc916a6bc9a2d53ffb4f916c baseline version: seabios 237fd3943d18d7d1a4c44aa2402c26fa62e7c380 Last test of basis 124521 2018-06-21 14:40:20 Z6 days Failing since124585 2018-06-22 06:10:18 Z5 days 10 attempts Testing same since 124758 2018-06-27 07:27:42 Z0 days3 attempts People who touched revisions under test: Gerd Hoffmann jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-qemuu-nested-amdblocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictblocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-amd64-xl-qemuu-win10-i386 blocked
[Xen-devel] [linux-4.14 test] 124744: trouble: blocked/broken
flight 124744 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/124744/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-armhf-xsm broken build-arm64-xsm broken build-i386-pvops broken build-i386 broken build-armhf-pvopsbroken build-i386-xsm broken build-amd64-pvopsbroken build-arm64-pvopsbroken build-armhf broken build-arm64 broken build-amd64-xsm broken build-amd64 4 host-install(4)broken REGR. vs. 124389 build-arm64-xsm 4 host-install(4)broken REGR. vs. 124389 build-arm64-pvops 4 host-install(4)broken REGR. vs. 124389 build-arm64 4 host-install(4)broken REGR. vs. 124389 build-amd64-pvops 4 host-install(4)broken REGR. vs. 124389 build-amd64-xsm 4 host-install(4)broken REGR. vs. 124389 build-i3864 host-install(4)broken REGR. vs. 124389 build-i386-pvops 4 host-install(4)broken REGR. vs. 124389 build-i386-xsm4 host-install(4)broken REGR. vs. 124389 build-armhf-xsm 4 host-install(4)broken REGR. vs. 124389 build-armhf-pvops 4 host-install(4)broken REGR. vs. 124389 build-armhf 4 host-install(4)broken REGR. vs. 124389 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-i386-examine 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-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-win10-i386 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-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked
Re: [Xen-devel] [PATCH] libxl: make sure buffer is null-terminated in libxl_read_file_contents
On Wed, Jun 27, 2018 at 8:29 PM, Wei Liu wrote:
> On Wed, Jun 27, 2018 at 07:37:42PM +0800, Robin Lee wrote:
>> On Wed, Jun 27, 2018 at 7:24 PM, Wei Liu wrote:
>> > On Wed, Jun 27, 2018 at 07:08:02PM +0800, Robin Lee wrote:
>> >> On Wed, Jun 27, 2018 at 6:58 PM, Wei Liu wrote:
>> >> > On Wed, Jun 27, 2018 at 09:13:11AM +, Robin Lee wrote:
>> >> >> On XenServer 7.1.1, we start a vm with XAPI but attach a block device
>> >> >> with xl.
>> >> >> We create an empty json config for the vm with the content "{}\n" and
>> >> >> then
>> >> >> run 'xl block-attach':
>> >> >>
>> >> >> # xl block-attach 1 phy:/dev/loop0 xvdz w
>> >> >> libxl: error: libxl_json.c:950:libxl__json_parse: yajl error: parse
>> >> >> error: trailing garbage
>> >> >> {} K]
>> >> >>(right here) --^
>> >> >>
>> >> >> libxl: error: libxl_json.c:1053:libxl__object_from_json: unable to
>> >> >> generate libxl__json_object from JSON representation of
>> >> >> libxl_domain_config.
>> >> >> libxl: error: libxl.c:1995:device_addrm_aocomplete: unable to add
>> >> >> device
>> >> >> libxl_device_disk_add failed.
>> >> >>
>> >> >> After investigation, we found the buffer returned from
>> >> >> libxl_read_file_contents
>> >> >> is not null-terminated. But later in libxl__object_from_json, the
>> >> >> buffer is expected to
>> >> >> be null-terminated. So parsing may exceeded the end of file and get in
>> >> >> to uninisialized
>> >> >> momery area.
>> >> >>
>> >> >> Signed-off-by: Robin Lee
>> >> >
>> >> > I can't seem to be able to reproduce this in upstream xen. Which version
>> >> > of Xen does XenServer 7.1.1 have? You can get that from the output of
>> >> > `xl info` -- look for xen_{major, minor, extra}.
>> >> I also met a strange case. We didn't see this problem with Xen 4.7.1
>> >> that released with
>> >> XenServer 7.1.1. But since a recently hotfix from XenServer that upgraded
>> >> Xen to
>> >> 4.7.4, this problem then shows up.
>> >>
>> >> The version of yajl (yajl-2.0.4-4.el7.x86_64) never changed.
>> >
>> > As far as I can tell, the stored json file already contains trailing 0,
>> > even in 4.7.4. There is nothing interesting between 4.7.1 and 4.7.4 in
>> > that area of code.
>> In my situation, the json file is created with external program and contains
>> just "{}\n" and not trailing 0.
>
> Alright. In that case please append 0 to the file you created.
>
> The json files are considered to be internal to libxl.
OK. I can conform that json file generated by xl contains a trailing 0.
But that seems not a common design to rely on the trailing 0 inside a text file.
>
> Wei.
-robin
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 124770: trouble: broken/pass
flight 124770 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/124770/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd-againbroken build-amd64-freebsd-again 5 host-install(5)broken REGR. vs. 124766 version targeted for testing: freebsd ee7076ae8a62ad170037180d45f05a07f4d83334 baseline version: freebsd d27905c3a3df138b9b6c6d0eade689ecb13706fc Last test of basis 124766 2018-06-27 16:11:00 Z0 days Testing same since 124770 2018-06-27 20:41:03 Z0 days1 attempts People who touched revisions under test: bdrewery brd gjb jhb trasz jobs: build-amd64-freebsd-againbroken build-amd64-freebsd 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 broken-job build-amd64-freebsd-again broken broken-step build-amd64-freebsd-again host-install(5) Not pushing. commit ee7076ae8a62ad170037180d45f05a07f4d83334 Author: bdrewery Date: Wed Jun 27 19:29:15 2018 + Don't use CCACHE for linking. MFC after: 2 weeks Sponsored by: Dell EMC commit 4cf8e902f8fdcf15469c62159a1e88f6c1a3a9da Author: trasz Date: Wed Jun 27 19:28:37 2018 + Fix description for the "autoconf" ifconfig(8) flag; it's an address property, not something you set for an interface. MFC after: 2 weeks commit 99a956a88b6502fe42f03a5779cd442f6b9a2873 Author: brd Date: Wed Jun 27 19:10:32 2018 + Chase the pwd_mkdb endian changes. Approved by:bapt (mentor) commit a472a4a146e803e1c1bff883be2b2c50fc62 Author: bdrewery Date: Wed Jun 27 18:43:34 2018 + Follow-up r335706: Fix LLVM_TARGET_ALL handling to use TARGET_ARCH. Pointyhat to: bdrewery MFC after: 2 weeks X-MFC-with: r335706 Reported by:Mark Millard Sponsored by: Dell EMC commit 18ddcb43ebef97d31864845d7191aa0bec2b1f6b Author: jhb Date: Wed Jun 27 18:14:33 2018 + Fix GCC 4.2.1 to honor --sysroot for includes. - Change the C++ directory entries to honor --sysroot if it is set. - Don't define CROSS_INCLUDE_DIR for the cross compiler. Instead, set TARGET_SYSTEM_ROOT to point to WORLDTMP and always define STANDARD_INCLUDE_DIR. - Change STANDARD_INCLUDE_DIR and the C++ include directories to just start with "/usr" always. The compiler will prepend the sysroot when doing cross-builds. GCC_INCLUDE_DIR (which contains headers that ship with the compiler such as intrinsincs rather than OS-supplied headers) remains hardcoded to look in TOOLS_PREFIX. Reviewed by:bdrewery (older version) Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D15127 commit 65c3d0c931f8cc6e09c41964be52ae4cdd3811b9 Author: jhb Date: Wed Jun 27 18:11:47 2018 + Don't hardcode the TOOLS_PREFIX for the startfiles directories. GCC 4.2 prefixes these directories with --sysroot meaning that during buildworld they have a double sysroot. Reviewed by:bdrewery Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D14780 commit 546ff97837d6d0e8eb3976330366f4772d9f7aa8 Author: gjb Date: Wed Jun 27 17:40:29 2018 + Add FreeBSD 11.2. Sponsored by: The FreeBSD Foundation commit 1f4f89f7573ed794caa8a7e4dba903f429c3a50d Author: bdrewery Date: Wed Jun 27 17:18:12 2018 + Regenerate commit b1324a4ff90f17d77b7f9f14997596fb6dd4389b Author: bdrewery Date: Wed Jun 27 17:13:36 2018 + Push users towards LLVM_TARGET_ALL. MFC after: 1 week commit fd8c7dd62a8321c3ea4161d70a4cf6ce0700b9c8 Author: bdrewery Date: Wed Jun 27 16:58:10 2018 + tinderbox: Only build clang/lld once if needed. Need to handle LLD_BOOTSTRAP separately (for archs like i386). This would be much better off with an off-by-default option like SHARED_TOOLCHAIN that universe force-enabled. Then a normal buildworld would store the toolchain there if enabled and otherwise in WORLDTMP with only the 1 arch selected. MFC after: 3 weeks
[Xen-devel] Patch "x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths" has been added to the 4.14-stable tree
This is a note to let you know that I've just added the patch titled
x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-xen-add-call-of-speculative_store_bypass_ht_init-to-pv-paths.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From 74899d92e3dc7671a8017b3146dcd4735f3b Mon Sep 17 00:00:00 2001
From: Juergen Gross
Date: Thu, 21 Jun 2018 10:43:31 +0200
Subject: x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths
From: Juergen Gross
commit 74899d92e3dc7671a8017b3146dcd4735f3b upstream.
Commit:
1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD")
... added speculative_store_bypass_ht_init() to the per-CPU initialization
sequence.
speculative_store_bypass_ht_init() needs to be called on each CPU for
PV guests, too.
Reported-by: Brian Woods
Tested-by: Brian Woods
Signed-off-by: Juergen Gross
Cc:
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: boris.ostrov...@oracle.com
Cc: xen-devel@lists.xenproject.org
Fixes: 1f50ddb4f4189243c05926b842dc1a0332195f31 ("x86/speculation: Handle HT
correctly on AMD")
Link: https://lore.kernel.org/lkml/20180621084331.21228-1-jgr...@suse.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/smp_pv.c |5 +
1 file changed, 5 insertions(+)
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
#include
@@ -70,6 +71,8 @@ static void cpu_bringup(void)
cpu_data(cpu).x86_max_cores = 1;
set_cpu_sibling_map(cpu);
+ speculative_store_bypass_ht_init();
+
xen_setup_cpu_clockevents();
notify_cpu_starting(cpu);
@@ -250,6 +253,8 @@ static void __init xen_pv_smp_prepare_cp
}
set_cpu_sibling_map(0);
+ speculative_store_bypass_ht_init();
+
xen_pmu_init(0);
if (xen_smp_intr_init(0) || xen_smp_intr_init_pv(0))
Patches currently in stable-queue which might be from jgr...@suse.com are
queue-4.14/x86-xen-add-call-of-speculative_store_bypass_ht_init-to-pv-paths.patch
queue-4.14/x86-platform-uv-add-kernel-parameter-to-set-memory-block-size.patch
queue-4.14/x86-platform-uv-use-new-set-memory-block-size-function.patch
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Patch "x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths" has been added to the 4.17-stable tree
This is a note to let you know that I've just added the patch titled
x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths
to the 4.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-xen-add-call-of-speculative_store_bypass_ht_init-to-pv-paths.patch
and it can be found in the queue-4.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From 74899d92e3dc7671a8017b3146dcd4735f3b Mon Sep 17 00:00:00 2001
From: Juergen Gross
Date: Thu, 21 Jun 2018 10:43:31 +0200
Subject: x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths
From: Juergen Gross
commit 74899d92e3dc7671a8017b3146dcd4735f3b upstream.
Commit:
1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD")
... added speculative_store_bypass_ht_init() to the per-CPU initialization
sequence.
speculative_store_bypass_ht_init() needs to be called on each CPU for
PV guests, too.
Reported-by: Brian Woods
Tested-by: Brian Woods
Signed-off-by: Juergen Gross
Cc:
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: boris.ostrov...@oracle.com
Cc: xen-devel@lists.xenproject.org
Fixes: 1f50ddb4f4189243c05926b842dc1a0332195f31 ("x86/speculation: Handle HT
correctly on AMD")
Link: https://lore.kernel.org/lkml/20180621084331.21228-1-jgr...@suse.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/smp_pv.c |5 +
1 file changed, 5 insertions(+)
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
#include
@@ -70,6 +71,8 @@ static void cpu_bringup(void)
cpu_data(cpu).x86_max_cores = 1;
set_cpu_sibling_map(cpu);
+ speculative_store_bypass_ht_init();
+
xen_setup_cpu_clockevents();
notify_cpu_starting(cpu);
@@ -250,6 +253,8 @@ static void __init xen_pv_smp_prepare_cp
}
set_cpu_sibling_map(0);
+ speculative_store_bypass_ht_init();
+
xen_pmu_init(0);
if (xen_smp_intr_init(0) || xen_smp_intr_init_pv(0))
Patches currently in stable-queue which might be from jgr...@suse.com are
queue-4.17/x86-xen-add-call-of-speculative_store_bypass_ht_init-to-pv-paths.patch
queue-4.17/x86-platform-uv-add-kernel-parameter-to-set-memory-block-size.patch
queue-4.17/x86-platform-uv-use-new-set-memory-block-size-function.patch
queue-4.17/x86-platform-uv-add-adjustable-set-memory-block-size-function.patch
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-coverity test] 124759: trouble: broken
flight 124759 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/124759/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: coverity-amd64 broken coverity-amd644 host-install(4)broken REGR. vs. 124430 version targeted for testing: xen 437211cb696515ee5bd5dae0ab72866c9f382a33 baseline version: xen 988d66cb78c35c620c2a0eb01bac842e4e99bf0e Last test of basis 124430 2018-06-20 09:18:50 Z7 days Testing same since 124663 2018-06-24 09:18:18 Z3 days2 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Juergen Gross jobs: coverity-amd64 broken 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 437211cb696515ee5bd5dae0ab72866c9f382a33 Author: Jan Beulich Date: Thu Jun 21 11:35:46 2018 +0200 x86/EFI: fix FPU state handling around runtime calls There are two issues. First, the nonlazy xstates were never restored after returning from the runtime call. Secondly, with the fully_eager_fpu mitigation for XSA-267 / LazyFPU, the unilateral stts() is no longer correct, and hits an assertion later when a lazy state restore tries to occur for a fully eager vcpu. Fix both of these issues by calling vcpu_restore_fpu_eager(). As EFI runtime services can be used in the idle context, the idle assertion needs to move until after the fully_eager_fpu check. Introduce a "curr" local variable and replace other uses of "current" at the same time. Reported-by: Andrew Cooper Signed-off-by: Jan Beulich Signed-off-by: Andrew Cooper Tested-by: Juergen Gross Release-acked-by: Juergen Gross (qemu changes not included) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Project Security Process Whitepaper v1 is ready for community review
On 27/06/2018, 22:47, "Steven Haigh" wrote: On Wednesday, 27 June 2018 7:19:58 PM AEST Jan Beulich wrote: > >>> On 27.06.18 at 06:05, wrote: > > Right now, we're at a stage where we could probably justify a new release > > of 4.6, 4.7, 4.8, 4.9, and 4.10 due to the depth of XSAs contained within > > that can't be patched on top of the release archive. > > 4.7.6 and 4.8.4 are imminent anyway, and 4.9.3 is due in about a > month's time (I'll send a respective call for pointing out missing > backports once I've flushed out my own queue). There's not going to > be another release off the 4.6 branch, at least not one organized by > XenProject. Even us meaning to do so for 4.7 is only because of the > circumstances. > > As mentioned before - personally I'm not fancying to do more frequent > stable releases. Surely we are able to automate the majority of the process? I could imagine that with a regular release schedule, it could be refined enough to automatically package the current git branch based on just committing a tag. There was a discussion at the summit in this area, which would be a step in the right direction, which was proposed by Doug from Rackspace and Matt from ARM. I still need to deal with the meeting notes Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 124767: trouble: blocked/broken
flight 124767 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/124767/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-i386 broken build-i386-xsm broken build-amd64-xsm broken build-i386-pvops broken build-i386-xsm4 host-install(4)broken REGR. vs. 124618 build-i386-pvops 4 host-install(4)broken REGR. vs. 124618 build-i3864 host-install(4)broken REGR. vs. 124618 build-amd64-pvops 4 host-install(4)broken REGR. vs. 124618 build-amd64 4 host-install(4)broken REGR. vs. 124618 build-amd64-xsm 4 host-install(4)broken REGR. vs. 124618 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 build-i386-libvirt1 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 975478f6bb22668efae311eb3f7406e1f18411c2 baseline version: ovmf 3b03b5e990f8bb347dfdb91926d8ef015d0b607e Last test of basis 124618 2018-06-22 19:10:57 Z5 days Failing since124675 2018-06-24 23:40:15 Z3 days4 attempts Testing same since 124767 2018-06-27 16:40:45 Z0 days1 attempts People who touched revisions under test: Bi, Dandan Chao Zhang Chasel Chiu Chasel, Chiu Dandan Bi Gary Lin Hao Wu Jaben Carsey Liming Gao Michael D Kinney Star Zeng Thomas Palmer Xu WeiX Zhang, Chao B jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken 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 broken-job build-amd64 broken broken-job build-amd64-pvops broken broken-job build-i386 broken broken-job build-i386-xsm broken broken-job build-amd64-xsm broken broken-job build-i386-pvops broken broken-step build-i386-xsm host-install(4) broken-step build-i386-pvops host-install(4) broken-step build-i386 host-install(4) broken-step build-amd64-pvops host-install(4) broken-step build-amd64 host-install(4) broken-step build-amd64-xsm host-install(4) Not pushing. (No revision log; it would be 670 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 124743: trouble: blocked/broken
flight 124743 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/124743/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm broken build-armhf-pvopsbroken build-armhf broken build-amd64 broken build-i386 broken build-arm64-pvopsbroken build-i386-pvops broken build-arm64 broken build-amd64-pvopsbroken build-i386-xsm broken build-amd64-xsm broken build-arm64-xsm broken build-i386-xsm4 host-install(4)broken REGR. vs. 123554 build-i3864 host-install(4)broken REGR. vs. 123554 build-arm64 4 host-install(4)broken REGR. vs. 123554 build-arm64-pvops 4 host-install(4)broken REGR. vs. 123554 build-arm64-xsm 4 host-install(4)broken REGR. vs. 123554 build-amd64 4 host-install(4)broken REGR. vs. 123554 build-i386-pvops 4 host-install(4)broken REGR. vs. 123554 build-amd64-pvops 4 host-install(4)broken REGR. vs. 123554 build-amd64-xsm 4 host-install(4)broken REGR. vs. 123554 build-armhf 4 host-install(4)broken REGR. vs. 123554 build-armhf-pvops 4 host-install(4)broken REGR. vs. 123554 build-armhf-xsm 4 host-install(4)broken REGR. vs. 123554 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-examine 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-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-pair 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-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1)
Re: [Xen-devel] [PATCH 0/2] xen/xsm: Cleanup in preparation for XSM SILO mode
On 26/06/2018 14:16, Jan Beulich wrote: On 26.06.18 at 14:42, wrote: >> On 26/06/18 13:04, Jan Beulich wrote: >> On 26.06.18 at 13:09, wrote: Future changes will introduce a new SILO mode, which is intended to be useful for cloud and enterprise setups where all domUs are unprivileged and have no buisness communicating directly. This was discussed at XenSummit, but I'll leave further details to the series which introduces it. However, to begin with, clean up the XSM namespacing to better separate XSM and FLASK. No functional change. Andrew Cooper (2): xen/xsm: Rename CONFIG_FLASK_* to CONFIG_XSM_FLASK_* xen/xsm: Rename CONIFIG_XSM_POLICY to CONFIG_XSM_FLASK_POLICY >>> I don't particularly mind the change, but I also don't view it as >>> particularly useful: For the first patch I'd see the point if you >>> meant to introduce some CONFIG_ABC_FLASK, but that's not how >>> I understand the description there. For the second I don't see >>> the point of retaining XSM in the name. >> XSM != Flask, and this is the naming confusion trying to be rectified. > But why is FLASK alone not meaningful enough? > >> CONFIG_XSM_SILO is going to be the introduced new mode. > And then SILO alone here? FLASK and SILO alone are meaningful to the core maintainers/developers, but only because they're aware (even if only tangentially) of all the development work going on. By namespacing with an XSM, it is far clearer as to the hierarchy of named features. This particular rename came about as a direct result of my observation of a room full of confused developers as to exactly where the split of various features lay. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen/xsm: Rename CONFIG_XSM_POLICY to CONFIG_XSM_FLASK_POLICY
On Tue, Jun 26, 2018 at 12:09:08PM +0100, Andrew Cooper wrote: > The embedded policy is specific flask, so update the infrastructure to reflect > this. > > Signed-off-by: Andrew Cooper The subject has a typo 'CONIFIG' -> 'CONFIG', with that fixed: Reviewed-by: Doug Goldstein > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index 0f15f72..068c320 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -127,10 +127,10 @@ config XSM_FLASK_AVC_STATS > > If unsure, say Y. > > -config XSM_POLICY > - bool "Compile Xen with a built-in security policy" (for Jan): This is what I'm talking about about the conflating the two. This isn't a XSM policy or a XSM security policy. Its specifically a FLASK security policy. The rest of this diff fixes that in numerous places. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] xen/xsm: Rename CONFIG_FLASK_* to CONFIG_XSM_FLASK_*
On Tue, Jun 26, 2018 at 12:09:07PM +0100, Andrew Cooper wrote: > Flask is one single XSM module, and another is about to be introduced. > Properly namespace the symbols for clarity. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] xen/xsm: Cleanup in preparation for XSM SILO mode
On Tue, Jun 26, 2018 at 07:16:08AM -0600, Jan Beulich wrote: > >>> On 26.06.18 at 14:42, wrote: > > On 26/06/18 13:04, Jan Beulich wrote: > > On 26.06.18 at 13:09, wrote: > >>> Future changes will introduce a new SILO mode, which is intended to be > >>> useful > >>> for cloud and enterprise setups where all domUs are unprivileged and have > >>> no > >>> buisness communicating directly. > >>> > >>> This was discussed at XenSummit, but I'll leave further details to the > >>> series > >>> which introduces it. However, to begin with, clean up the XSM > >>> namespacing to > >>> better separate XSM and FLASK. > >>> > >>> No functional change. > >>> > >>> Andrew Cooper (2): > >>> xen/xsm: Rename CONFIG_FLASK_* to CONFIG_XSM_FLASK_* > >>> xen/xsm: Rename CONIFIG_XSM_POLICY to CONFIG_XSM_FLASK_POLICY > >> I don't particularly mind the change, but I also don't view it as > >> particularly useful: For the first patch I'd see the point if you > >> meant to introduce some CONFIG_ABC_FLASK, but that's not how > >> I understand the description there. For the second I don't see > >> the point of retaining XSM in the name. > > > > XSM != Flask, and this is the naming confusion trying to be rectified. > > But why is FLASK alone not meaningful enough? Thoughout the code and docs there are conflations between XSM and FLASK when they're distict pieces of code. FLASK is akin to SELinux while XSM is akin to the LSM in Linux. To use the Linux paradigms their config options are: CONFIG_SECURITY - enables LSMs CONFIG_SECURITY_SELINUX - enables SELinux We're going to have similar menus to allow someone to select a different XSM implmentation. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 266 (CVE-2018-12892) - libxl fails to honour readonly flag on HVM emulated SCSI disks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-12892 / XSA-266
version 3
libxl fails to honour readonly flag on HVM emulated SCSI disks
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
libxl fails to pass the readonly flag to qemu when setting up a SCSI
disk, due to what was probably an erroneous merge conflict resolution.
IMPACT
==
Malicious guest administrators or (in some situations) users may be
able to write to supposedly read-only disk images.
VULNERABLE SYSTEMS
==
Only emulated SCSI disks (specified as "sd" in the libxl disk
configuration, or an equivalent) are affected. IDE disks ("hd") are
not affected (because attempts to make them readonly are rejected).
Additionally, CDROM devices (that is, devices specified to be
presented to the guest as CDROMs, regardless of the nature of the
backing storage on the host) are not affected; they are always
readonly.
Only systems using qemu-xen (rather than qemu-xen-traditional) as the
device model version are vulnerable.
Only systems using libxl or libxl-based toolstacks are vulnerable.
(This includes xl, and libvirt with the libxl driver.)
The vulnerability is present in Xen versions 4.7 and later.
(In earlier versions, provided that the patch for XSA-142 has been
applied, attempts to create readonly disks are rejected.)
If the host and guest together usually support PVHVM, the issue is
exploitable only if the malicious guest administrator has control of
the guest kernel or guest kernel command line.
MITIGATION
==
Switching to qemu-xen-traditional will avoid this vulnerability.
This can be done with
device_model_version="qemu-xen-traditional"
in the xl configuration file.
Using stub domain device models (which necessarily involves switching
to qemu-xen-traditional) will also avoid this vulnerability.
This can be done with
device_model_stubdomain_override=true
in the xl configuration file.
All of these mitigations are liable to have other guest-visible
effects or even regressions.
It may be possible, depending on the configuration, to make the
underlying storage object readonly, or to make it reject writes.
CREDITS
===
This issue was discovered by Andrew Reimers of OrionVM.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa266/*.patch xen-unstable
xsa266-4.10/*.patch Xen 4.10.x
xsa266-4.9/*.patch Xen 4.9.x
xsa266-4.8/*.patch Xen 4.8.x
xsa266-4.7/*.patch Xen 4.7.x
xsa266-4.6/*.patch Xen 4.6.x
$ sha256sum xsa266* xsa266*/*
d0d998bb3c2f36b0795cdf86d52aa2da3eee72218f9073f398fc6fd2cf5719cd xsa266.meta
0e5634c9b730e2e022bfef9ded2bb81b7740d05911dae6499671db5cb90663c0
xsa266-4.7/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch
e6dcef1bdd890a245cb9181266fc1378d77b08cf06c063f35a0835ab3b99cf91
xsa266-4.7/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch
19ce6f236702219eb4831ed597f82dc81122fd517131e826643cee95b53d9f1c
xsa266-4.8/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch
e0a4c616218bc42abada75aa5fa0c3e35da6b6334fe50d6104a5892ffebcdb04
xsa266-4.8/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch
9fd48f20da140731bb71dde07035b938cf0966339449a0b6833787767c588c0a
xsa266-4.9/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch
f23d0e76f15b1f6af487adc36a84cf2591197548ca7cab8ee84be72a87424cf7
xsa266-4.9/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch
3d857f38d11b5531a651a45c2f151ac1493260524d4f49ead6833b5f1d599e64
xsa266-4.10/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch
e380976abd77b5b46d69c9564aca3acf9bf467b36645ac34e035aba89d081591
xsa266-4.10/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch
160dc8c8a918cae7259c252af098206f9eff357e52bdfc0b15553e9c31c587e6
xsa266/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch
2b44fd6baac094c82145667a16d9b1530b97fa342d0e635c831425b53a336266
xsa266/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of patches or mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List). Specifically, deployment on public cloud systems
is NOT permitted.
This is because all of the patches and mitigations make significant
guest-visible changes. In particular, applying the patch will cause
the emulated SCSI disk object to be reported to the guest as readonly,
when previously it was reported as writeable.
Deployment is permitted only AFTER the embargo ends.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to
[Xen-devel] Xen Security Advisory 265 (CVE-2018-12893) - x86: #DB exception safety check can be triggered by a guest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-12893 / XSA-265 version 3 x86: #DB exception safety check can be triggered by a guest UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = One of the fixes in XSA-260 added some safety checks to help prevent Xen livelocking with debug exceptions. Unfortunately, due to an oversight, at least one of these safety checks can be triggered by a guest. IMPACT == A malicious PV guest can crash Xen, leading to a Denial of Service. VULNERABLE SYSTEMS == All Xen systems which have applied the XSA-260 fix are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 PV guests can exploit the vulnerability. x86 HVM and PVH guests cannot exploit the vulnerability. An attacker needs to be able to control hardware debugging facilities to exploit the vulnerability, but such permissions are typically available to unprivileged users. MITIGATION == Running only x86 HVM or PVH guests will avoid the vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa265.patch xen-unstable, Xen 4.10.x, 4.9.x, 4.8.x xsa265-4.7.patch Xen 4.7.x, 4.6.x $ sha256sum xsa265* 3eb66ed7251dcc4259eeffe608b2747857e269307d894a1cb950973420184aa7 xsa265.patch 00faf2a4159698b6540565ece06de103c3547855e2084324ca44772b8a24aa18 xsa265-4.7.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbM+5JAAoJEIP+FMlX6CvZtSgIAMF8d/3Jor6b0EbW55JSLh76 56I8QfkqX4Xv/yWri3sXGJmPz7Af/qjDO+Ix5IScq54ugN5C8z7OBcbXFpX1WxNJ xCv6QjsbPmGCZHsT+NdWrl/ac6ZH3xlhE+S1awQ+9SkC+r6bRH/iROO+4DhpYQde CGoyYIwFq2VJoovh8lWHMsVl8VUXisyDk3bPK17VlAEFF1LuOkaan1UGEKRsciGX 12IlNw/I6c8a85wWpFtph1AOVZfrodWdwyj8vgLY3MHnEs+86/cm5O4+GxKHezHf P5dJDZ38HBPRL1qC+yFRV2sLxLgrc7fYlSWr3/xtOGo23aDLjCvS+FsMfIpyjPQ= =sf+j -END PGP SIGNATURE- xsa265.patch Description: Binary data xsa265-4.7.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 264 (CVE-2018-12891) - preemption checks bypassed in x86 PV MM handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-12891 / XSA-264 version 3 preemption checks bypassed in x86 PV MM handling UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Certain PV MMU operations may take a long time to process. For that reason Xen explicitly checks for the need to preempt the current vCPU at certain points. A few rarely taken code paths did bypass such checks. By suitably enforcing the conditions through its own page table contents, a malicious guest may cause such bypasses to be used for an unbounded number of iterations. IMPACT == A malicious or buggy PV guest may cause a Denial of Service (DoS) affecting the entire host. Specifically, it may prevent use of a physical CPU for an indeterminate period of time. VULNERABLE SYSTEMS == All Xen versions from 3.4 onwards are vulnerable. Xen versions 3.3 and earlier are vulnerable to an even wider class of attacks, due to them lacking preemption checks altogether in the affected code paths. Only x86 systems are affected. ARM systems are not affected. Only multi-vCPU x86 PV guests can leverage the vulnerability. x86 HVM or PVH guests as well as x86 single-vCPU PV ones cannot leverage the vulnerability. MITIGATION == Running only HVM, PVH, or single-vCPU PV guests will avoid this vulnerability. For PV guests, the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa264.patch xen-unstable xsa264-4.10.patch Xen 4.10.x ... 4.6.x $ sha256sum xsa264* a7d2edf219af3375ac0d49bff9e64628c70e704fcf131ea21684694517aa9210 xsa264.patch 66aca234b168abc01f28fe131b7e07645a73fd5d0f1d141d68343f31914d96cc xsa264-4.10.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbM+5GAAoJEIP+FMlX6CvZy7cIALkEoEQnHw5O8vYC5KpDA24X P320Gh0OppT2qtQfKtAF7MaCc7VF9Tnhf3CrtNtolXMryM4vrh7KyOn8wk7jbRBy tp28e6ppO8ons9x1kBAmAZrno8LXwOa2t22hQpUv1mYksRkZotViAXS72t4HkOVl SEQVVLElWAIfPbGJwtu1/qgS8dCckA2MeLeN/dKHRm8gD63XsYt37nQnBa2iraKX yN5sdih+WLgXCf55mubFlQfE6+7qgn27khZpMeJAwGk6N+Rz/Q3q1zSFX9YB+P6d 9ppgoRFVxYpekwtCrLkVLxSAoEwCKi6sdYFnvIngHIMlLiVHjNsLd5YKTAsZcEE= =zTq5 -END PGP SIGNATURE- xsa264.patch Description: Binary data xsa264-4.10.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [seabios test] 124764: trouble: blocked/broken
flight 124764 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/124764/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm broken build-amd64-pvopsbroken build-amd64-xsm broken build-i386-pvops broken build-amd64 broken build-i386 broken build-i386-xsm4 host-install(4)broken REGR. vs. 124521 build-amd64-xsm 4 host-install(4)broken REGR. vs. 124521 build-amd64-pvops 4 host-install(4)broken REGR. vs. 124521 build-amd64 4 host-install(4)broken REGR. vs. 124521 build-i386-pvops 4 host-install(4)broken REGR. vs. 124521 build-i3864 host-install(4)broken REGR. vs. 124521 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 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-win10-i386 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-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a version targeted for testing: seabios 69ea6dabeba4e080fc916a6bc9a2d53ffb4f916c baseline version: seabios 237fd3943d18d7d1a4c44aa2402c26fa62e7c380 Last test of basis 124521 2018-06-21 14:40:20 Z6 days Failing since124585 2018-06-22 06:10:18 Z5 days9 attempts Testing same since 124758 2018-06-27 07:27:42 Z0 days2 attempts People who touched revisions under test: Gerd Hoffmann jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-qemuu-nested-amdblocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictblocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-amd64-xl-qemuu-win10-i386 blocked
[Xen-devel] [freebsd-master test] 124766: all pass - PUSHED
flight 124766 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/124766/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd d27905c3a3df138b9b6c6d0eade689ecb13706fc baseline version: freebsd 8c919b97c3e3b63937c2607de051992d459d858d Last test of basis 124762 2018-06-27 11:40:51 Z0 days Testing same since 124766 2018-06-27 16:11:00 Z0 days1 attempts People who touched revisions under test: asomers emaste hselasky np jobs: build-amd64-freebsd-againpass build-amd64-freebsd 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/freebsd.git 8c919b97c3e..d27905c3a3d d27905c3a3df138b9b6c6d0eade689ecb13706fc -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-upstream-4.11-testing baseline test] 124742: trouble: blocked/broken
"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 124742 qemu-upstream-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/124742/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm broken build-arm64-pvopsbroken build-armhf-xsm broken build-amd64 broken build-i386-pvops broken build-arm64-xsm broken build-armhf-pvopsbroken build-amd64-xsm broken build-arm64 broken build-i386 broken build-amd64-pvopsbroken build-armhf broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 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-i386-xl-pvshim 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1)
Re: [Xen-devel] [PATCH v3 13/31] libxl_qmp: Separate QMP message generation from qmp_send_prepare
On Wed, Jun 27, 2018 at 03:45:33PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v3 13/31] libxl_qmp: Separate QMP message
> generation from qmp_send_prepare"):
> > This new function qmp_prepare_qmp_cmd() can be reuse later when
> > introducing a different way to communicate with a QMP server,
> > libxl__ev_qmp.
> >
> > Also, add the QMP end of command '\r\n' into the generated string.
>
> Would it be terribly inconvenient if this function
>
> > +static char *qmp_prepare_qmp_cmd(libxl__gc *gc,
> > + const char *cmd,
> > + const libxl__json_object *args,
> > + int id,
> > + size_t *len_r)
> ...
> > +ret = libxl__malloc(NOGC, len + 3);
>
> actually used its incoming gc ?
Yes, because I wanted to keep the allocated buffers until it is actually
sent. But maybe we could provide a different gc, but I'm not sure which
one or how to get it.
That function is going to be called by:
> libxl__ev_qmp_register(libxl__gc *gc, libxl__ev_qmp *ev, )
introduce in the patch "libxl_qmp: Introduce libxl__ev_qmp functions"
> Perhaps it needs a 2nd gc argument ?
>
> I think for future we should be using some appropriate ao gc, or
> something, for these buffers. But, anyway, that is a future
> improvement, and not a blocker for this patch.
Sure.
> So:
>
> Acked-by: Ian Jackson
Thanks,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/2] x86/cpuid: Alter the policy logic for leaf 0xb to be multi-invocation
The new data lives in the .topo union, rather than being treated as a single
leaf in the basic union.
While adjusting cpuid_policy, pad .basic to CPUID_GUEST_NR_BASIC for the
benefit of people extending the number of leaves in the future.
Host data is scanned when filling in the raw policy, but Xen still discards
any toolstack settings for now.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Ian Jackson
CC: Wei Liu
CC: Roger Pau Monné
v2:
* s/harware/hardware/
* Comment about padding .basic in the commit message
---
tools/libxc/xc_cpuid_x86.c | 11 ++-
xen/arch/x86/cpuid.c| 41 +++--
xen/arch/x86/domctl.c | 8
xen/include/asm-x86/cpuid.h | 18 +-
4 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 21537f0..96c6c95 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -764,13 +764,22 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
domid,
if ( (regs[0] & 0x1f) != 0 )
continue;
}
+/* Extended Topology leaves. */
+else if ( input[0] == 0xb )
+{
+uint8_t level_type = regs[2] >> 8;
+
+input[1]++;
+if ( level_type >= 1 && level_type <= 2 )
+continue;
+}
input[0]++;
if ( !(input[0] & 0x8000u) && (input[0] > base_max ) )
input[0] = 0x8000u;
input[1] = XEN_CPUID_INPUT_UNUSED;
-if ( (input[0] == 4) || (input[0] == 7) )
+if ( (input[0] == 4) || (input[0] == 7) || (input[0] == 0xb) )
input[1] = 0;
else if ( input[0] == 0xd )
input[1] = 1; /* Xen automatically calculates almost everything. */
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index eca1a9a..c33c6d4 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -205,7 +205,10 @@ static void recalculate_misc(struct cpuid_policy *p)
p->basic.raw[0x6] = EMPTY_LEAF; /* Therm/Power not exposed to guests. */
p->basic.raw[0x8] = EMPTY_LEAF;
-p->basic.raw[0xb] = EMPTY_LEAF; /* TODO: Rework topology logic. */
+
+/* TODO: Rework topology logic. */
+memset(p->topo.raw, 0, sizeof(p->topo.raw));
+
p->basic.raw[0xc] = EMPTY_LEAF;
p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
@@ -273,7 +276,7 @@ static void __init calculate_raw_policy(void)
{
switch ( i )
{
-case 0x4: case 0x7: case 0xd:
+case 0x4: case 0x7: case 0xb: case 0xd:
/* Multi-invocation leaves. Deferred. */
continue;
}
@@ -316,6 +319,33 @@ static void __init calculate_raw_policy(void)
cpuid_count_leaf(7, i, >feat.raw[i]);
}
+if ( p->basic.max_leaf >= 0xb )
+{
+union {
+struct cpuid_leaf l;
+struct cpuid_topo_leaf t;
+} u;
+
+for ( i = 0; i < ARRAY_SIZE(p->topo.raw); ++i )
+{
+cpuid_count_leaf(0xb, i, );
+
+if ( u.t.type == 0 )
+break;
+
+p->topo.subleaf[i] = u.t;
+}
+
+/*
+ * The choice of CPUID_GUEST_NR_TOPO is per the manual. It may need
+ * to grow for future hardware.
+ */
+if ( i == ARRAY_SIZE(p->topo.raw) &&
+ (cpuid_count_leaf(0xb, i, ), u.t.type != 0) )
+printk(XENLOG_WARNING
+ "CPUID: Insufficient Leaf 0xb space for this hardware\n");
+}
+
if ( p->basic.max_leaf >= XSTATE_CPUID )
{
uint64_t xstates;
@@ -730,6 +760,13 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
*res = p->feat.raw[subleaf];
break;
+case 0xb:
+if ( subleaf >= ARRAY_SIZE(p->topo.raw) )
+return;
+
+*res = p->topo.raw[subleaf];
+break;
+
case XSTATE_CPUID:
if ( !p->basic.xsave || subleaf >= ARRAY_SIZE(p->xstate.raw) )
return;
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 105a576..3e9580b 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -70,6 +70,10 @@ static int update_domain_cpuid_info(struct domain *d,
ctl->input[1] >= ARRAY_SIZE(p->feat.raw) )
return 0;
+if ( ctl->input[0] == 0xb &&
+ ctl->input[1] >= ARRAY_SIZE(p->topo.raw) )
+return 0;
+
BUILD_BUG_ON(ARRAY_SIZE(p->xstate.raw) < 2);
if ( ctl->input[0] == XSTATE_CPUID &&
ctl->input[1] != 1 ) /* Everything else automatically calculated.
*/
@@ -100,6 +104,10 @@ static int update_domain_cpuid_info(struct domain *d,
p->feat.raw[ctl->input[1]] = leaf;
break;
+case 0xb:
+p->topo.raw[ctl->input[1]] = leaf;
+break;
+
case XSTATE_CPUID:
Re: [Xen-devel] [PATCH v3 10/31] libxl_qmp: Move buffers to the stack of qmp_next.
On Wed, Jun 27, 2018 at 03:32:32PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v3 10/31] libxl_qmp: Move buffers to the stack
> of qmp_next."):
> > That buffer is only used locally, and never reuse accross different call
> > of qmp_next. So remove it form the handler.
>
> How big is this buffer ?
It's 4k
> I think you're moving it from the heap to
> the stack ? Do we need to worry about stack size ?
We can probably remove this patch from the series. It is not important.
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 09/31] libxl_qmp: Move struct sockaddr_un variable to qmp_open()
On Wed, Jun 27, 2018 at 03:31:21PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v3 09/31] libxl_qmp: Move struct sockaddr_un
> variable to qmp_open()"):
> ...
> > And allow strncpy to use all the space in sun_path.
>
> I wasn't able to see in the diff what this entry in the commit message
> refers to.
I probably forgot to remove the -1 in the strncpy call or was thinking
about another patch.
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 07/31] libxl_qmp: Learned to send FD through QMP to QEMU
On Wed, Jun 27, 2018 at 03:26:51PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v3 07/31] libxl_qmp: Learned to send FD
> through QMP to QEMU"):
> > Adding the ability to send a file descriptor from libxl to QEMU via the
> > QMP interface. This will be use with the "add-fd" QMP command.
>
> Do you know which byte of the message the fd should be attached to ?
Yes, anywhere before the last byte of the command that is going to use
the fd. QEMU is going to store any fd received until a command is using
it.
We should be able to the the fd, then sent several qmp command, then the
add-fd command, and I think that will work fine.
> What if qemu reads a partial message, discarding the fd, and then
> reads the rest of the message, finding the fd missing ? Or something.
I don't think QEMU discards fds until a command is using it, or maybe
until a new fd comes in (I did not check this second thought).
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 124761: trouble: blocked/broken
flight 124761 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/124761/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-i386-pvops broken build-i386 broken build-i386-xsm broken build-i386-xsm4 host-install(4)broken REGR. vs. 124618 build-i386-pvops 4 host-install(4)broken REGR. vs. 124618 build-i3864 host-install(4)broken REGR. vs. 124618 build-amd64 4 host-install(4)broken REGR. vs. 124618 build-amd64-pvops 4 host-install(4)broken REGR. vs. 124618 build-amd64-xsm 4 host-install(4)broken REGR. vs. 124618 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 3c920616bb22c7f08d473ee555c1f51930aba35e baseline version: ovmf 3b03b5e990f8bb347dfdb91926d8ef015d0b607e Last test of basis 124618 2018-06-22 19:10:57 Z4 days Failing since124675 2018-06-24 23:40:15 Z2 days3 attempts Testing same since 124761 2018-06-27 10:25:30 Z0 days1 attempts People who touched revisions under test: Bi, Dandan Chao Zhang Chasel Chiu Chasel, Chiu Dandan Bi Gary Lin Hao Wu Jaben Carsey Liming Gao Michael D Kinney Star Zeng Thomas Palmer Xu WeiX Zhang, Chao B jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken 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 broken-job build-amd64 broken broken-job build-amd64-pvops broken broken-job build-amd64-xsm broken broken-job build-i386-pvops broken broken-job build-i386 broken broken-job build-i386-xsm broken broken-step build-i386-xsm host-install(4) broken-step build-i386-pvops host-install(4) broken-step build-i386 host-install(4) broken-step build-amd64 host-install(4) broken-step build-amd64-pvops host-install(4) broken-step build-amd64-xsm host-install(4) Not pushing. (No revision log; it would be 660 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 31/31] libxl: QEMU startup sync based on QMP
Anthony PERARD writes ("[PATCH v3 31/31] libxl: QEMU startup sync based on
QMP"):
> This is only activated when dm_restrict=1, as explained in the previous
> patch "libxl_dm: Pre-open QMP socket for QEMU"
...
> @@ -1603,11 +1603,16 @@ struct libxl__spawn_state {
> libxl__spawn_confirm_cb *confirm_cb;
> libxl__spawn_detached_cb *detached_cb;
>
> +/* If qmp_domid != INVALID_DOMID, then libxl__spawn_spawn will also use
> QMP
> + * to find out when the process is started */
> +uint32_t qmp_domid;
> +
I think this is a layering violation. libxl__spawn_* is a thing for
double forking and shouldn't know about qmp. I think you need to
handle this the way the xenstore readiness is handled.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 30/31] libxl_dm: Pre-open QMP socket for QEMU
Anthony PERARD writes ("[PATCH v3 30/31] libxl_dm: Pre-open QMP socket for
QEMU"):
> When starting QEMU with dm_restrict=1, pre-open the QMP socket before
> exec QEMU. That socket will be usefull to findout if QEMU is ready, and
> pre-opening it means that libxl can connect to it without waiting for
> QEMU to create it.
...
> +socket_fd = socket(AF_UNIX, SOCK_STREAM, 0);
> +*dm_monitor_fd = socket_fd;
> +if (socket_fd < 0) {
> +LOGED(ERROR, guest_domid, "Failed to create UNIX socket");
> +return ERROR_FAIL;
> +}
I can't help thinking that this is a lot of lines of code. Is none of
this available anywhere else for reuse ?
> +socket_path = GCSPRINTF("%s/qmp-libxl-%d",
> +libxl__run_dir_path(), guest_domid);
> +if (strlen(socket_path) > sizeof(un.sun_path)) {
> +LOGD(ERROR, guest_domid, "UNIX socket path '%s' is too long",
> + socket_path);
> +LOGD(DEBUG, guest_domid, "Path must be less than %zu bytes",
> + sizeof(un.sun_path));
> +return ERROR_FAIL;
> +}
Eg this part maybe ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 29/31] libxl_disk: Have libxl_cdrom_insert use libxl__ev_qmp
Anthony PERARD writes ("[PATCH v3 29/31] libxl_disk: Have libxl_cdrom_insert
use libxl__ev_qmp"):
> So when QEMU is involve, the operation will be asynchrone and will
> finish later.
This looks roughly plausible, in the sense that if you address my
internal API concerns, and make this part fit again, it will probably
be good.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/cpuid: Alter the policy logic for leaf 0xb to be multi-invocation
>>> On 27.06.18 at 17:58, wrote:
> On 27/06/18 15:58, Jan Beulich wrote:
> On 27.06.18 at 15:55, wrote:
>>> @@ -316,6 +319,33 @@ static void __init calculate_raw_policy(void)
>>> cpuid_count_leaf(7, i, >feat.raw[i]);
>>> }
>>>
>>> +if ( p->basic.max_leaf >= 0xb )
>>> +{
>>> +union {
>>> +struct cpuid_leaf l;
>>> +struct cpuid_topo_leaf t;
>>> +} u;
>>> +
>>> +for ( i = 0; i < ARRAY_SIZE(p->topo.raw); ++i )
>>> +{
>>> +cpuid_count_leaf(0xb, i, );
>>> +
>>> +if ( u.t.type == 0 )
>>> +break;
>>> +
>>> +p->topo.subleaf[i] = u.t;
>>> +}
>>> +
>>> +/*
>>> + * The choice of CPUID_GUEST_NR_TOPO is per the manual. It may
>>> need
>>> + * to grow for future harware.
>> Missing d.
>
> Where? I'm afraid that after repeated re-reads, I can't spot any issue.
hardware
>>> @@ -108,7 +109,11 @@ struct cpuid_policy
>>> uint64_t :64, :64; /* Leaf 0x9 - DCA */
>>>
>>> /* Leaf 0xa - Intel PMU. */
>>> -uint8_t pmu_version;
>>> +uint8_t pmu_version, _pmu[15];
>>> +
>>> +uint64_t :64, :64; /* Leaf 0xb - Topology. */
>>> +uint64_t :64, :64; /* Leaf 0xc - rsvd */
>>> +uint64_t :64, :64; /* Leaf 0xd - XSTATE. */
>> I don't understand why you add the latter two lines, neither in general
>> nor in the particular context of this patch.
>
> This is part of reducing the effort for people extending the CPUID
> leaves, by keeping the .basic union in line with max_leaf.
>
> There are further non-subleaf leaves beyond this point (0x15/0x16) and
> I've noticed several mistakes with newer submitted series. I'd much
> rather do this myself once now, than attempt to explain it to others
> during code review.
Ah, I see. If you make the commit message say so,
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 27/31] libxl_qmp: Implement libxl__qmp_insert_cdrom_ev
Anthony PERARD writes ("[PATCH v3 27/31] libxl_qmp: Implement
libxl__qmp_insert_cdrom_ev"):
> This function is a reimplementation of libxl__qmp_insert_cdrom() but to be
> use with libxl__ev_qmp.
Overall, I think what I am missing in much of this is a highly-formal
description of the states of these asynchronous things, and the
permitted call orders, etc. Like for libxl_ev_FOO, which you are
trying to follow, but doesn't really fit.
I appreciate that I may be asking for a lot of rework. Sorry.
I think before you do a full resend, it would be worth writing out the
internal interfaces in a form that addresses this aspect of my review
(ie, the part in libxl_internal.h).
Also my comments about whether the buffer queue is really needed.
Regards,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 26/31] libxl_qmp: Disable beautify for QMP generated cmd
Anthony PERARD writes ("[PATCH v3 26/31] libxl_qmp: Disable beautify for QMP
generated cmd"):
> There is no need for it.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 24/31] libxl_qmp_ev: Respond to QMP greeting
Anthony PERARD writes ("[PATCH v3 24/31] libxl_qmp_ev: Respond to QMP
greeting"):
> Slight change in the infrastructure to allow to send a buffer before any
> command that would already been prepared.
I'm inclined to think that this would be better done as part of the
"connect to qmp" state machine.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 22/31] libxl_qmp: Simplify qmp_response_type() prototype
Anthony PERARD writes ("[PATCH v3 22/31] libxl_qmp: Simplify
qmp_response_type() prototype"):
> Remove the libxl__qmp_handler* argument so the function can be reused
> later in a different context.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/cpuid: Alter the policy logic for leaf 0xb to be multi-invocation
On 27/06/18 17:00, Wei Liu wrote:
> On Wed, Jun 27, 2018 at 04:58:08PM +0100, Andrew Cooper wrote:
>> On 27/06/18 15:58, Jan Beulich wrote:
>> On 27.06.18 at 15:55, wrote:
@@ -316,6 +319,33 @@ static void __init calculate_raw_policy(void)
cpuid_count_leaf(7, i, >feat.raw[i]);
}
+if ( p->basic.max_leaf >= 0xb )
+{
+union {
+struct cpuid_leaf l;
+struct cpuid_topo_leaf t;
+} u;
+
+for ( i = 0; i < ARRAY_SIZE(p->topo.raw); ++i )
+{
+cpuid_count_leaf(0xb, i, );
+
+if ( u.t.type == 0 )
+break;
+
+p->topo.subleaf[i] = u.t;
+}
+
+/*
+ * The choice of CPUID_GUEST_NR_TOPO is per the manual. It may
need
+ * to grow for future harware.
>>> Missing d.
>> Where? I'm afraid that after repeated re-reads, I can't spot any issue.
>>
> har d ware. ;p
Wow I'm blind. Thanks.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/cpuid: Alter the policy logic for leaf 0xb to be multi-invocation
On Wed, Jun 27, 2018 at 04:58:08PM +0100, Andrew Cooper wrote:
> On 27/06/18 15:58, Jan Beulich wrote:
> On 27.06.18 at 15:55, wrote:
> >> @@ -316,6 +319,33 @@ static void __init calculate_raw_policy(void)
> >> cpuid_count_leaf(7, i, >feat.raw[i]);
> >> }
> >>
> >> +if ( p->basic.max_leaf >= 0xb )
> >> +{
> >> +union {
> >> +struct cpuid_leaf l;
> >> +struct cpuid_topo_leaf t;
> >> +} u;
> >> +
> >> +for ( i = 0; i < ARRAY_SIZE(p->topo.raw); ++i )
> >> +{
> >> +cpuid_count_leaf(0xb, i, );
> >> +
> >> +if ( u.t.type == 0 )
> >> +break;
> >> +
> >> +p->topo.subleaf[i] = u.t;
> >> +}
> >> +
> >> +/*
> >> + * The choice of CPUID_GUEST_NR_TOPO is per the manual. It may
> >> need
> >> + * to grow for future harware.
> > Missing d.
>
> Where? I'm afraid that after repeated re-reads, I can't spot any issue.
>
har d ware. ;p
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/cpuid: Alter the policy logic for leaf 0xb to be multi-invocation
On 27/06/18 15:58, Jan Beulich wrote:
On 27.06.18 at 15:55, wrote:
>> @@ -316,6 +319,33 @@ static void __init calculate_raw_policy(void)
>> cpuid_count_leaf(7, i, >feat.raw[i]);
>> }
>>
>> +if ( p->basic.max_leaf >= 0xb )
>> +{
>> +union {
>> +struct cpuid_leaf l;
>> +struct cpuid_topo_leaf t;
>> +} u;
>> +
>> +for ( i = 0; i < ARRAY_SIZE(p->topo.raw); ++i )
>> +{
>> +cpuid_count_leaf(0xb, i, );
>> +
>> +if ( u.t.type == 0 )
>> +break;
>> +
>> +p->topo.subleaf[i] = u.t;
>> +}
>> +
>> +/*
>> + * The choice of CPUID_GUEST_NR_TOPO is per the manual. It may need
>> + * to grow for future harware.
> Missing d.
Where? I'm afraid that after repeated re-reads, I can't spot any issue.
>
>> @@ -108,7 +109,11 @@ struct cpuid_policy
>> uint64_t :64, :64; /* Leaf 0x9 - DCA */
>>
>> /* Leaf 0xa - Intel PMU. */
>> -uint8_t pmu_version;
>> +uint8_t pmu_version, _pmu[15];
>> +
>> +uint64_t :64, :64; /* Leaf 0xb - Topology. */
>> +uint64_t :64, :64; /* Leaf 0xc - rsvd */
>> +uint64_t :64, :64; /* Leaf 0xd - XSTATE. */
> I don't understand why you add the latter two lines, neither in general
> nor in the particular context of this patch.
This is part of reducing the effort for people extending the CPUID
leaves, by keeping the .basic union in line with max_leaf.
There are further non-subleaf leaves beyond this point (0x15/0x16) and
I've noticed several mistakes with newer submitted series. I'd much
rather do this myself once now, than attempt to explain it to others
during code review.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 124762: all pass - PUSHED
flight 124762 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/124762/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 8c919b97c3e3b63937c2607de051992d459d858d baseline version: freebsd 6a3794ff6f6ec157f401e5e0c7dec2012ddc3cfc Last test of basis 124757 2018-06-27 07:10:56 Z0 days Testing same since 124762 2018-06-27 11:40:51 Z0 days1 attempts People who touched revisions under test: delphij jobs: build-amd64-freebsd-againpass build-amd64-freebsd 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/freebsd.git 6a3794ff6f6..8c919b97c3e 8c919b97c3e3b63937c2607de051992d459d858d -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 18/31] libxl_json: libxl__json_object_to_json
Anthony PERARD writes ("[PATCH v3 18/31] libxl_json:
libxl__json_object_to_json"):
> Allow to generate a JSON string from a libxl__json_object,
> usefull for debugging.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V4] x86/altp2m: Fix crash with INVALID_ALTP2M EPTP index
>>> On 27.06.18 at 17:25, wrote: > On 06/27/2018 06:04 PM, Jan Beulich wrote: > On 27.06.18 at 15:12, wrote: >>> xc_altp2m_set_vcpu_enable_notify() ends up calling >>> altp2m_vcpu_update_vmfunc_ve(), which sets the >>> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS bit on >>> vmx_secondary_exec_control. A subsequent call to >>> xc_altp2m_set_domain_state(..., false) (i.e. disabling altp2m >>> for the domain) ends up calling altp2m_vcpu_destroy(), which >>> calls (in this order) altp2m_vcpu_reset() (which sets the >>> current EPTP index to INVALID_ALTP2M), altp2m_vcpu_update_p2m() >>> (which __vmwrite()s EPTP_INDEX as INVALID_ALTP2M if >>> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set), and >>> altp2m_vcpu_update_vmfunc_ve() (which finally clears >>> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS). >> >> I continue to consider this paragraph unreadable, but perhaps it's >> just me. The rest of the description looks reasonable to me now. > > If you (or anyone else) have something specific in mind I'd be happy to > change it to that, otherwise I can also try again (the only concern is > that I might unwantedly continue to be unable to guess correctly at the > desired balance between technical clarity (detail) and general readability). > > Is "A VM entry handler executed immediately after enabling #VE might > find a stale __vmsave()d EPTP_INDEX, stored by calling > altp2m_vcpu_destroy() when SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS had > been set by altp2m_vcpu_update_vmfunc_ve()." a better first paragraph > perhaps? To me personally - yes, very much. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V4] x86/altp2m: Fix crash with INVALID_ALTP2M EPTP index
On 06/27/2018 06:04 PM, Jan Beulich wrote: On 27.06.18 at 15:12, wrote: >> xc_altp2m_set_vcpu_enable_notify() ends up calling >> altp2m_vcpu_update_vmfunc_ve(), which sets the >> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS bit on >> vmx_secondary_exec_control. A subsequent call to >> xc_altp2m_set_domain_state(..., false) (i.e. disabling altp2m >> for the domain) ends up calling altp2m_vcpu_destroy(), which >> calls (in this order) altp2m_vcpu_reset() (which sets the >> current EPTP index to INVALID_ALTP2M), altp2m_vcpu_update_p2m() >> (which __vmwrite()s EPTP_INDEX as INVALID_ALTP2M if >> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set), and >> altp2m_vcpu_update_vmfunc_ve() (which finally clears >> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS). > > I continue to consider this paragraph unreadable, but perhaps it's > just me. The rest of the description looks reasonable to me now. If you (or anyone else) have something specific in mind I'd be happy to change it to that, otherwise I can also try again (the only concern is that I might unwantedly continue to be unable to guess correctly at the desired balance between technical clarity (detail) and general readability). Is "A VM entry handler executed immediately after enabling #VE might find a stale __vmsave()d EPTP_INDEX, stored by calling altp2m_vcpu_destroy() when SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS had been set by altp2m_vcpu_update_vmfunc_ve()." a better first paragraph perhaps? > Please allow some more time than a single day between versions > though, so others also have a chance to respond. Sorry about that, I misremembered that I had sent V3 yesterday. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 15/31] libxl_qmp_ev: Implement fd callback and read data
Anthony PERARD writes ("[PATCH v3 15/31] libxl_qmp_ev: Implement fd callback
and read data"):
> First step into taking care of the input from QEMU's QMP socket. For
> now, we read data and store them in buffers.
How big is this data ? Is all this business with a linked list of
buffers really necessary ?
(Maybe I should be reading this as a final tree state rather than as
individual patches.)
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 14/31] libxl_qmp_ev: Introduce libxl__ev_qmp_start() to connect to QMP
Anthony PERARD writes ("[PATCH v3 14/31] libxl_qmp_ev: Introduce
libxl__ev_qmp_start() to connect to QMP"):
> This is a first patch to implement libxl__ev_qmp, it only connect to the
> QMP socket of QEMU and register a callback that does nothing.
...
> @@ -503,6 +504,9 @@ struct libxl__ctx {
> LIBXL_LIST_ENTRY(libxl_ctx) sigchld_users_entry;
>
> libxl_version_info version_info;
> +
> +// FIXME: May need a list, with on state for each domid
> +libxl__ev_qmp_state *qmp_ev;
My thought is that the lifetime of this thing should probably be in
each relevant ao.
Is it too inconvenient to reconnect to qmp for every libxl operation ?
If it is then this needs to be a cache, a bit like libxl__poller but
different. But that can be handled inside what you are calling
_ev_qmp_start.
Also, I think if you are going to have a libxl__ev_qmp it needs to be
just like all the other libxl__ev_ things. It's not clear to me that
QMP is similar enough.
Do you actually need an explicit "start" or "connect" operation ?
I think in any case the "send a qmp command" operations should
probably connect automatically.
So something like this:
/* libxl__qmp_state has the following states:
* Undefined
* Disconnected
* Connected
*/
void libxl__qmp_init(ibxl__qmp_state *qmp); /* U -> D */
int libxl__qmp_connect(libxl__gc *gc, uint32_t domid,
libxl__qmp_state *qmp_upd); /* [UC] -> C */
int libxl__qmp_dispose(libxl__qmp_state *qmp_upd); /* [DC] -> D */
int libxl__qmp_command( lots of parameters incl callback ); /* [DC] */
> +_hidden libxl__ev_qmp_state *libxl__ev_qmp_start(libxl__gc *gc, uint32_t
> domid);
Line length.
Also, this interface does not support returning a proper error status.
> +libxl__ev_qmp_state *libxl__ev_qmp_start(libxl__gc *gc, uint32_t domid)
> +{
> +int rc, r;
> +struct sockaddr_un un;
> +const char *qmp_socket_path;
> +libxl__ev_qmp_state *qmp;
...
> +out:
> +if (rc)
> +libxl__ev_qmp_stop(gc, qmp);
> +CTX_UNLOCK;
> +return qmp;
I think the error handling is messed up here. If this fails, you will
stop the qmp and then return it anyway.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V4] x86/altp2m: Fix crash with INVALID_ALTP2M EPTP index
>>> On 27.06.18 at 15:12, wrote: > xc_altp2m_set_vcpu_enable_notify() ends up calling > altp2m_vcpu_update_vmfunc_ve(), which sets the > SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS bit on > vmx_secondary_exec_control. A subsequent call to > xc_altp2m_set_domain_state(..., false) (i.e. disabling altp2m > for the domain) ends up calling altp2m_vcpu_destroy(), which > calls (in this order) altp2m_vcpu_reset() (which sets the > current EPTP index to INVALID_ALTP2M), altp2m_vcpu_update_p2m() > (which __vmwrite()s EPTP_INDEX as INVALID_ALTP2M if > SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set), and > altp2m_vcpu_update_vmfunc_ve() (which finally clears > SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS). I continue to consider this paragraph unreadable, but perhaps it's just me. The rest of the description looks reasonable to me now. Please allow some more time than a single day between versions though, so others also have a chance to respond. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 124741: trouble: blocked/broken
flight 124741 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/124741/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-amd64 broken build-arm64-pvopsbroken build-arm64 broken build-amd64-pvopsbroken build-i386 broken build-i386-pvops broken build-amd64-xsm broken build-armhf-xsm broken build-armhf-pvopsbroken build-i386-xsm broken build-armhf broken build-i386-pvops 4 host-install(4)broken REGR. vs. 124232 build-i386-xsm4 host-install(4)broken REGR. vs. 124232 build-arm64-xsm 4 host-install(4)broken REGR. vs. 124232 build-arm64 4 host-install(4)broken REGR. vs. 124232 build-arm64-pvops 4 host-install(4)broken REGR. vs. 124232 build-amd64-xsm 4 host-install(4)broken REGR. vs. 124232 build-amd64-pvops 4 host-install(4)broken REGR. vs. 124232 build-amd64 4 host-install(4)broken REGR. vs. 124232 build-i3864 host-install(4)broken REGR. vs. 124232 build-armhf-xsm 4 host-install(4)broken REGR. vs. 124232 build-armhf-pvops 4 host-install(4)broken REGR. vs. 124232 build-armhf 4 host-install(4)broken REGR. vs. 124232 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a build-arm64-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-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-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-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a
Re: [Xen-devel] [PATCH 2/2] x86/cpuid: Alter the policy logic for leaf 0xb to be multi-invocation
>>> On 27.06.18 at 15:55, wrote:
> @@ -316,6 +319,33 @@ static void __init calculate_raw_policy(void)
> cpuid_count_leaf(7, i, >feat.raw[i]);
> }
>
> +if ( p->basic.max_leaf >= 0xb )
> +{
> +union {
> +struct cpuid_leaf l;
> +struct cpuid_topo_leaf t;
> +} u;
> +
> +for ( i = 0; i < ARRAY_SIZE(p->topo.raw); ++i )
> +{
> +cpuid_count_leaf(0xb, i, );
> +
> +if ( u.t.type == 0 )
> +break;
> +
> +p->topo.subleaf[i] = u.t;
> +}
> +
> +/*
> + * The choice of CPUID_GUEST_NR_TOPO is per the manual. It may need
> + * to grow for future harware.
Missing d.
> @@ -108,7 +109,11 @@ struct cpuid_policy
> uint64_t :64, :64; /* Leaf 0x9 - DCA */
>
> /* Leaf 0xa - Intel PMU. */
> -uint8_t pmu_version;
> +uint8_t pmu_version, _pmu[15];
> +
> +uint64_t :64, :64; /* Leaf 0xb - Topology. */
> +uint64_t :64, :64; /* Leaf 0xc - rsvd */
> +uint64_t :64, :64; /* Leaf 0xd - XSTATE. */
I don't understand why you add the latter two lines, neither in general
nor in the particular context of this patch.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/cpuid: Fix up stale comments
>>> On 27.06.18 at 15:55, wrote: > * There is no legacy path any more. All static information is retrieved in >the first pass. > * d->arch.cpuids[] doesn't exist any more. > > Signed-off-by: Andrew Cooper 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 5/6] x86/msr: Clean up the MSR_APIC_BASE constants
On 27/06/18 14:35, Andrew Cooper wrote:
> On 27/06/18 14:32, Roger Pau Monné wrote:
>> On Tue, Jun 26, 2018 at 02:18:17PM +0100, Andrew Cooper wrote:
>>> We currently have MSR_IA32_APICBASE and MSR_IA32_APICBASE_MSR which are
>>> synonymous from a naming point of view, but refer to very different
>>> things.
>>>
>>> Cleave out the handling of MSR_APIC_BASE (0x1b), and rename
>>> MSR_IA32_APICBASE_BASE to APIC_BASE_ADDR_MASK to better describe its
>>> purpose.
>>>
>>> Signed-off-by: Andrew Cooper
>> Reviewed-by: Roger Pau Monné
>>
>>> diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
>>> index ffa5a69..aa677e0 100644
>>> --- a/xen/arch/x86/apic.c
>>> +++ b/xen/arch/x86/apic.c
>>> @@ -1446,23 +1448,21 @@ void __init record_boot_APIC_mode(void)
>>> apic_mode_to_str(apic_boot_mode));
>>> }
>>>
>>> -/* Look at the bits in MSR_IA32_APICBASE and work out which
>>> - * APIC mode we are in */
>>> +/* Look at the bits in MSR_APIC_BASE and work out which APIC mode we are
>>> in */
>>> enum apic_mode current_local_apic_mode(void)
>>> {
>>> u64 msr_contents;
>>>
>>> -rdmsrl(MSR_IA32_APICBASE, msr_contents);
>>> +rdmsrl(MSR_APIC_BASE, msr_contents);
>>>
>>> /* Reading EXTD bit from the MSR is only valid if CPUID
>>> * says so, else reserved */
>>> -if ( boot_cpu_has(X86_FEATURE_X2APIC)
>>> - && (msr_contents & MSR_IA32_APICBASE_EXTD) )
>>> +if ( boot_cpu_has(X86_FEATURE_X2APIC) && (msr_contents &
>>> APIC_BASE_EXTD) )
>> While there you could change it to cpu_has_x2apic.
> So I can. Thanks,
Actually, this code is some of my earliest contributions to Xen, and my
current self is really regretting the lack of review of my older self's
code.
Both comments are false and the check isn't necessary. I've fixed all
this up and added a comment to the commit message.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/3] libxc: do not return a value from xc_cpuid_policy
On Wed, Jun 27, 2018 at 04:32:14PM +0200, Roger Pau Monne wrote: > None of the called functions return any errors, so there's no point in > returning an int from xc_cpuid_policy. > > Signed-off-by: Roger Pau Monné What is the plan for this function? I expect it (and its children) to go away soon? You can also delete xch, I think. It is not used. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Project Security Process Whitepaper v1 is ready for community review
On Wednesday, 27 June 2018 7:19:58 PM AEST Jan Beulich wrote: > >>> On 27.06.18 at 06:05, wrote: > > Right now, we're at a stage where we could probably justify a new release > > of 4.6, 4.7, 4.8, 4.9, and 4.10 due to the depth of XSAs contained within > > that can't be patched on top of the release archive. > > 4.7.6 and 4.8.4 are imminent anyway, and 4.9.3 is due in about a > month's time (I'll send a respective call for pointing out missing > backports once I've flushed out my own queue). There's not going to > be another release off the 4.6 branch, at least not one organized by > XenProject. Even us meaning to do so for 4.7 is only because of the > circumstances. > > As mentioned before - personally I'm not fancying to do more frequent > stable releases. Surely we are able to automate the majority of the process? I could imagine that with a regular release schedule, it could be refined enough to automatically package the current git branch based on just committing a tag. -- Steven Haigh net...@crc.id.au https://www.crc.id.au +61 (3) 9001 6090 0412 935 897 signature.asc Description: This is a digitally signed message part. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 13/31] libxl_qmp: Separate QMP message generation from qmp_send_prepare
Anthony PERARD writes ("[PATCH v3 13/31] libxl_qmp: Separate QMP message
generation from qmp_send_prepare"):
> This new function qmp_prepare_qmp_cmd() can be reuse later when
> introducing a different way to communicate with a QMP server,
> libxl__ev_qmp.
>
> Also, add the QMP end of command '\r\n' into the generated string.
Would it be terribly inconvenient if this function
> +static char *qmp_prepare_qmp_cmd(libxl__gc *gc,
> + const char *cmd,
> + const libxl__json_object *args,
> + int id,
> + size_t *len_r)
...
> +ret = libxl__malloc(NOGC, len + 3);
actually used its incoming gc ? Perhaps it needs a 2nd gc argument ?
I think for future we should be using some appropriate ao gc, or
something, for these buffers. But, anyway, that is a future
improvement, and not a blocker for this patch.
So:
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] x86/cpuid: fix generation of auto cpuid header
On Wed, Jun 27, 2018 at 04:32:12PM +0200, Roger Pau Monne wrote: > The makefile rule to generate the cpuid-autogen.h header passes the > whole list of dependencies to gen-cpuid.py but only the first > dependency is actually needed. > > So far this seems to be harmless. > > Signed-off-by: Roger Pau Monné Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/3] libxc/cpuid: minor fixes
On 27/06/18 15:32, Roger Pau Monne wrote: > Hello, > > This series contain some minor fixes for cpuid header file generation > and a couple of fixes for libxc related cpuid functions. > > Thanks, Roger. > > Roger Pau Monne (3): > x86/cpuid: fix generation of auto cpuid header > libxc: fix stale PVH comment > libxc: do not return a value from xc_cpuid_policy All 3 Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/3] libxc: do not return a value from xc_cpuid_policy
None of the called functions return any errors, so there's no point in
returning an int from xc_cpuid_policy.
Signed-off-by: Roger Pau Monné
---
tools/libxc/xc_cpuid_x86.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 364f802c0f..3d1421aa50 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -592,9 +592,9 @@ static void xc_cpuid_pv_policy(xc_interface *xch,
}
}
-static int xc_cpuid_policy(xc_interface *xch,
- const struct cpuid_domain_info *info,
- const unsigned int *input, unsigned int *regs)
+static void xc_cpuid_policy(xc_interface *xch,
+const struct cpuid_domain_info *info,
+const unsigned int *input, unsigned int *regs)
{
/*
* For hypervisor leaves (0x4000) only 0x4000xx00.EAX[7:0] bits (max
@@ -604,15 +604,13 @@ static int xc_cpuid_policy(xc_interface *xch,
if ( (input[0] & 0x) == 0x4000 )
{
regs[0] = regs[1] = regs[2] = regs[3] = 0;
-return 0;
+return;
}
if ( info->hvm )
xc_cpuid_hvm_policy(xch, info, input, regs);
else
xc_cpuid_pv_policy(xch, info, input, regs);
-
-return 0;
}
static int xc_cpuid_do_domctl(
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 12/31] libxl_json: constify libxl__json_object_to_yajl_gen arguments
Anthony PERARD writes ("[PATCH v3 12/31] libxl_json: constify
libxl__json_object_to_yajl_gen arguments"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 11/31] libxl_qmp: Remove unused yajl_ctx form handler
Anthony PERARD writes ("[PATCH v3 11/31] libxl_qmp: Remove unused yajl_ctx form
handler"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/3] libxc: fix stale PVH comment
PVHv2 uses the HVM path, not the PV one.
Signed-off-by: Roger Pau Monné
---
tools/libxc/xc_cpuid_x86.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 21537f06f1..364f802c0f 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -666,7 +666,7 @@ static void sanitise_featureset(struct cpuid_domain_info
*info)
if ( info->hvm )
{
-/* HVM Guest */
+/* HVM or PVH Guest */
if ( !info->pae )
clear_bit(X86_FEATURE_PAE, info->featureset);
@@ -679,7 +679,7 @@ static void sanitise_featureset(struct cpuid_domain_info
*info)
}
else
{
-/* PV or PVH Guest */
+/* PV Guest */
if ( !info->pv64 )
{
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/3] x86/cpuid: fix generation of auto cpuid header
The makefile rule to generate the cpuid-autogen.h header passes the whole list of dependencies to gen-cpuid.py but only the first dependency is actually needed. So far this seems to be harmless. 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 --- xen/include/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/Makefile b/xen/include/Makefile index 8762ab3334..7c5034e6e0 100644 --- a/xen/include/Makefile +++ b/xen/include/Makefile @@ -143,7 +143,7 @@ endif ifeq ($(XEN_TARGET_ARCH),x86_64) $(BASEDIR)/include/asm-x86/cpuid-autogen.h: $(BASEDIR)/include/public/arch-x86/cpufeatureset.h $(BASEDIR)/tools/gen-cpuid.py FORCE - $(PYTHON) $(BASEDIR)/tools/gen-cpuid.py -i $^ -o $@.new + $(PYTHON) $(BASEDIR)/tools/gen-cpuid.py -i $< -o $@.new $(call move-if-changed,$@.new,$@) all: $(BASEDIR)/include/asm-x86/cpuid-autogen.h -- 2.17.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 10/31] libxl_qmp: Move buffers to the stack of qmp_next.
Anthony PERARD writes ("[PATCH v3 10/31] libxl_qmp: Move buffers to the stack
of qmp_next."):
> That buffer is only used locally, and never reuse accross different call
> of qmp_next. So remove it form the handler.
How big is this buffer ? I think you're moving it from the heap to
the stack ? Do we need to worry about stack size ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/3] libxc/cpuid: minor fixes
Hello, This series contain some minor fixes for cpuid header file generation and a couple of fixes for libxc related cpuid functions. Thanks, Roger. Roger Pau Monne (3): x86/cpuid: fix generation of auto cpuid header libxc: fix stale PVH comment libxc: do not return a value from xc_cpuid_policy tools/libxc/xc_cpuid_x86.c | 14 ++ xen/include/Makefile | 2 +- 2 files changed, 7 insertions(+), 9 deletions(-) -- 2.17.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 09/31] libxl_qmp: Move struct sockaddr_un variable to qmp_open()
Anthony PERARD writes ("[PATCH v3 09/31] libxl_qmp: Move struct sockaddr_un
variable to qmp_open()"):
...
> And allow strncpy to use all the space in sun_path.
I wasn't able to see in the diff what this entry in the commit message
refers to.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 08/31] libxl_qmp: Have QEMU save its state to a file descriptor
Anthony PERARD writes ("[PATCH v3 08/31] libxl_qmp: Have QEMU save its state to
a file descriptor"):
> In case QEMU have restricted access to the system, open the file for it,
> and QEMU will save its state to this file descritor.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/6] x86/msr: Introduce msr_{set, clear}_bits() helpers
On 27/06/18 15:17, Roger Pau Monné wrote:
> On Tue, Jun 26, 2018 at 07:22:44PM +0100, Andrew Cooper wrote:
>> One reoccuring code pattern is to read an MSR, modify one or more bits,
>> and write the result back. Introduce helpers for this purpose.
>>
>> First, introduce rdmsr_split() and wrmsr_split() which are tiny static inline
>> wrappers which deal with the MSR value in two 32bit halves.
> I think this needs some kind of explanation, since rdmsr/wrmsr already deal
> with MSR in two 32bit halves.
If you look closely, that's not how rdmsr() works. All of these macros
are for the chopping block over the course of the MSR cleanup.
>> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
>> index 09bb3f4..6619af9 100644
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -229,18 +229,15 @@ static void __init efi_arch_pre_exit_boot(void)
>>
>> static void __init noreturn efi_arch_post_exit_boot(void)
>> {
>> -u64 cr4 = XEN_MINIMAL_CR4 & ~X86_CR4_PGE, efer;
>> +bool nx = cpuid_ext_features & cpufeat_mask(X86_FEATURE_NX);
>> +uint64_t cr4 = XEN_MINIMAL_CR4 & ~X86_CR4_PGE, tmp;
>>
>> efi_arch_relocate_image(__XEN_VIRT_START - xen_phys_start);
>> memcpy((void *)trampoline_phys, trampoline_start, cfg.size);
>>
>> /* Set system registers and transfer control. */
>> asm volatile("pushq $0\n\tpopfq");
>> -rdmsrl(MSR_EFER, efer);
>> -efer |= EFER_SCE;
>> -if ( cpuid_ext_features & cpufeat_mask(X86_FEATURE_NX) )
>> -efer |= EFER_NXE;
>> -wrmsrl(MSR_EFER, efer);
>> +msr_set_bits(MSR_EFER, EFER_SCE | (nx ? EFER_NXE : 0));
> I think you can directly use cpu_has_nx?
boot_cpu_data[] isn't filled at this point during boot.
> Also isn't NX always present on amd64 capable CPUs?
If only. :(
The first generation of Intel's 64bit processors don't have NX.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 07/31] libxl_qmp: Learned to send FD through QMP to QEMU
Anthony PERARD writes ("[PATCH v3 07/31] libxl_qmp: Learned to send FD through
QMP to QEMU"):
> Adding the ability to send a file descriptor from libxl to QEMU via the
> QMP interface. This will be use with the "add-fd" QMP command.
Do you know which byte of the message the fd should be attached to ?
What if qemu reads a partial message, discarding the fd, and then
reads the rest of the message, finding the fd missing ? Or something.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 06/31] libxl_qmp: Add a warning to not trust QEMU
Anthony PERARD writes ("[PATCH v3 06/31] libxl_qmp: Add a warning to not trust
QEMU"):
> ... even if it is not the case for the current code.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 05/31] libxl_qmp: Move the buffer realloc to the same scope level as read
Anthony PERARD writes ("[PATCH v3 05/31] libxl_qmp: Move the buffer realloc to
the same scope level as read"):
> In qmp_next(), the inner loop should only try to parse messages from
> QMP, if there is more than one.
>
> The handling of the receive buffer ('incomplete'), should be done at the
> same scope level as read(). It doesn't need to be handle more that once
> after a read.
>
> Before this patch, when on message what handled, the inner loop would
> restart by adding the 'buffer' into 'incomplete' (after reallocation).
> Since 'rd' was not reset, the buffer would be strcat a second time.
> After that, the stream from the QMP server would have syntax error, and
> the parsor would throw errors.
>
> This is unlikely to happen as the receive buffer is very large. And
> receiving two messages in a row is unlikely. In the current case, this
> could be an event and a response to a command.
Acked-by: Ian Jackson
However, I have not reviewed the buffer handling in detail for
off-by-one errors etc.
I think it would be best for me to do a proper security-focused review
of the whole qmp arrangement after your series.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 04/31] libxl_json: fix build with DEBUG_ANSWER
Anthony PERARD writes ("[PATCH v3 04/31] libxl_json: fix build with
DEBUG_ANSWER"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
Although,
> yajl_gen_get_buf((yajl_ctx)->g, , ); \
> -LIBXL__LOG(libxl__gc_owner((yajl_ctx)->gc), LIBXL__LOG_DEBUG,
> -"response:\n", buf); \
> +LIBXL__LOG(libxl__gc_owner((yajl_ctx)->gc), XTL_DEBUG, \
> +"response: %s\n", buf); \
I'm not sure why you changed LIBXL__LOG_DEBUG to XTL_DEBUG. It would
be nice to mention it in the commit message. Personally I would
prefer it because (i) it's shorter (ii) we're not likely to want to
decouple the libxl log levels from the XTL ones (iii) if we do, in the
future, it will be an easy search-and-replace.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 03/31] libxl_qmp: Fix use of DEBUG_RECEIVED
Anthony PERARD writes ("[PATCH v3 03/31] libxl_qmp: Fix use of DEBUG_RECEIVED"):
> This patch fix complilation error with #define DEBUG_RECEIVED of the
> macro DEBUG_REPORT_RECEIVED.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 02/31] libxl_qmp: Documentation of the logic of the QMP client
Anthony PERARD writes ("[PATCH v3 02/31] libxl_qmp: Documentation of the logic
of the QMP client"):
> Signed-off-by: Anthony PERARD
> Acked-by: Wei Liu
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 01/31] libxl_event: Fix DEBUG prints
Anthony PERARD writes ("[PATCH v3 01/31] libxl_event: Fix DEBUG prints"):
> The libxl__log() call was missing the domid.
>
> The macro DBG is using LIBXL__LOG which rely on a "gc". Add a GC where
> needed.
>
> Signed-off-by: Anthony PERARD
> Reviewed-by: Wei Liu
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/6] x86/msr: Introduce msr_{set, clear}_bits() helpers
On Tue, Jun 26, 2018 at 07:22:44PM +0100, Andrew Cooper wrote:
> One reoccuring code pattern is to read an MSR, modify one or more bits,
> and write the result back. Introduce helpers for this purpose.
>
> First, introduce rdmsr_split() and wrmsr_split() which are tiny static inline
> wrappers which deal with the MSR value in two 32bit halves.
I think this needs some kind of explanation, since rdmsr/wrmsr already deal
with MSR in two 32bit halves.
> Next, construct msr_{set,clear}_bits() in terms of the {rdmsr,wrmsr}_split().
> The mask operations are deliberately performed as 32bit operations, because
> all callers pass in a constant to the mask parameter, and in all current
> cases, one of the two operations can be elided.
>
> For MSR_IA32_PSR_L3_QOS_CFG, switch PSR_L3_QOS_CDP_ENABLE from being a bit
> position variable to being a plain number.
>
> The resulting C is shorter, and doesn't require a temporary variable. The
> generated ASM is also more efficient, because of avoiding the
> packing/unpacking operations. e.g. the delta in the first hunk is from:
>
> b9 1b 00 00 00 mov$0x1b,%ecx
> 0f 32 rdmsr
> 48 c1 e2 20 shl$0x20,%rdx
> 48 09 d0or %rdx,%rax
> 80 e4 f3and$0xf3,%ah
> 48 89 c2mov%rax,%rdx
> 48 c1 ea 20 shr$0x20,%rdx
> 0f 30 wrmsr
>
> to:
>
> b9 1b 00 00 00 mov$0x1b,%ecx
> 0f 32 rdmsr
> 80 e4 f3and$0xf3,%ah
> 0f 30 wrmsr
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
If the intention behind introducing the _split helpers is detailed in
the commit message.
> diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c
> b/xen/arch/x86/cpu/mcheck/mce_intel.c
> index 2d285d0..c5f171d 100644
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> @@ -164,11 +164,8 @@ static void intel_init_thermal(struct cpuinfo_x86 *c)
> val |= (APIC_DM_FIXED | APIC_LVT_MASKED); /* we'll mask till we're
> ready */
> apic_write(APIC_LVTTHMR, val);
>
> -rdmsrl(MSR_IA32_THERM_INTERRUPT, msr_content);
> -wrmsrl(MSR_IA32_THERM_INTERRUPT, msr_content | 0x03);
> -
> -rdmsrl(MSR_IA32_MISC_ENABLE, msr_content);
> -wrmsrl(MSR_IA32_MISC_ENABLE, msr_content | (1ULL<<3));
> +msr_set_bits(MSR_IA32_THERM_INTERRUPT, 0x3);
> +msr_set_bits(MSR_IA32_MISC_ENABLE, 1 << 3);
>
> apic_write(APIC_LVTTHMR, val & ~APIC_LVT_MASKED);
> if ( opt_cpu_info )
> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index 09bb3f4..6619af9 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -229,18 +229,15 @@ static void __init efi_arch_pre_exit_boot(void)
>
> static void __init noreturn efi_arch_post_exit_boot(void)
> {
> -u64 cr4 = XEN_MINIMAL_CR4 & ~X86_CR4_PGE, efer;
> +bool nx = cpuid_ext_features & cpufeat_mask(X86_FEATURE_NX);
> +uint64_t cr4 = XEN_MINIMAL_CR4 & ~X86_CR4_PGE, tmp;
>
> efi_arch_relocate_image(__XEN_VIRT_START - xen_phys_start);
> memcpy((void *)trampoline_phys, trampoline_start, cfg.size);
>
> /* Set system registers and transfer control. */
> asm volatile("pushq $0\n\tpopfq");
> -rdmsrl(MSR_EFER, efer);
> -efer |= EFER_SCE;
> -if ( cpuid_ext_features & cpufeat_mask(X86_FEATURE_NX) )
> -efer |= EFER_NXE;
> -wrmsrl(MSR_EFER, efer);
> +msr_set_bits(MSR_EFER, EFER_SCE | (nx ? EFER_NXE : 0));
I think you can directly use cpu_has_nx?
Also isn't NX always present on amd64 capable CPUs?
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/6] x86/msr: Clean up the x2APIC MSR constants
On 27/06/18 14:50, Roger Pau Monné wrote:
> On Tue, Jun 26, 2018 at 02:18:18PM +0100, Andrew Cooper wrote:
>> The name MSR_IA32_APICBASE_MSR doesn't logically relate to its purpose.
>> Rename it to MSR_X2APIC_FIRST and introduce a corresponding
>> MSR_X2APIC_LAST to avoid opencoding the length of the x2APIC MSR range.
>>
>> For the specific registers, drop the IA32 infix, break the APIC part
>> away from the register name, and drop the MSR suffix.
>>
>> Signed-off-by: Andrew Cooper
>> Reviewed-by: Kevin Tian
> Reviewed-by: Roger Pau Monné
>
> Although I have some questions about the existing code.
>
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index d5334c9..48e2f8c 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -2995,19 +2995,19 @@ void vmx_vlapic_msr_changed(struct vcpu *v)
>> SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE;
>> if ( cpu_has_vmx_apic_reg_virt )
>> {
>> -for ( msr = MSR_IA32_APICBASE_MSR;
>> - msr <= MSR_IA32_APICBASE_MSR + 0xff; msr++ )
>> +for ( msr = MSR_X2APIC_FIRST;
>> + msr <= MSR_X2APIC_FIRST + 0xff; msr++ )
>> vmx_clear_msr_intercept(v, msr, VMX_MSR_R);
> I realize this is existing code, but do you know why 0xff is used here
> instead of 0xbff (MSR_X2APIC_LAST) or 0x83f (which is the last
> implemented x2APIC MSR)?.
Good questions. 0xbff can't be used because the SandyBridge uarch have
some undocumented MSRs implemented in that range.
There appears to be no justification for 0xff in the patch which
introduced it, and 0x83f would be a more appropriate upper bound. I'll
submit a separate fix for this, as there is a far far more efficient way
do this operation.
>
>>
>> -vmx_set_msr_intercept(v, MSR_IA32_APICPPR_MSR, VMX_MSR_R);
>> -vmx_set_msr_intercept(v, MSR_IA32_APICTMICT_MSR, VMX_MSR_R);
>> -vmx_set_msr_intercept(v, MSR_IA32_APICTMCCT_MSR, VMX_MSR_R);
>> +vmx_set_msr_intercept(v, MSR_X2APIC_PPR, VMX_MSR_R);
>> +vmx_set_msr_intercept(v, MSR_X2APIC_TMICT, VMX_MSR_R);
>> +vmx_set_msr_intercept(v, MSR_X2APIC_TMCCT, VMX_MSR_R);
>> }
>> if ( cpu_has_vmx_virtual_intr_delivery )
>> {
>> -vmx_clear_msr_intercept(v, MSR_IA32_APICTPR_MSR, VMX_MSR_W);
>> -vmx_clear_msr_intercept(v, MSR_IA32_APICEOI_MSR, VMX_MSR_W);
>> -vmx_clear_msr_intercept(v, MSR_IA32_APICSELF_MSR,
>> VMX_MSR_W);
>> +vmx_clear_msr_intercept(v, MSR_X2APIC_TPR, VMX_MSR_W);
>> +vmx_clear_msr_intercept(v, MSR_X2APIC_EOI, VMX_MSR_W);
>> +vmx_clear_msr_intercept(v, MSR_X2APIC_SELF, VMX_MSR_W);
>> }
>> }
>> else
>> @@ -3016,8 +3016,8 @@ void vmx_vlapic_msr_changed(struct vcpu *v)
>> }
>> if ( !(v->arch.hvm_vmx.secondary_exec_control &
>> SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE) )
>> -for ( msr = MSR_IA32_APICBASE_MSR;
>> - msr <= MSR_IA32_APICBASE_MSR + 0xff; msr++ )
>> +for ( msr = MSR_X2APIC_FIRST;
>> + msr <= MSR_X2APIC_FIRST + 0xff; msr++ )
>> vmx_set_msr_intercept(v, msr, VMX_MSR_RW);
>>
>> vmx_update_secondary_exec_control(v);
>> diff --git a/xen/include/asm-x86/msr-index.h
>> b/xen/include/asm-x86/msr-index.h
>> index ce2e847..9d96e96 100644
>> --- a/xen/include/asm-x86/msr-index.h
>> +++ b/xen/include/asm-x86/msr-index.h
>> @@ -49,6 +49,16 @@
>> #define MSR_MISC_FEATURES_ENABLES 0x0140
>> #define MISC_FEATURES_CPUID_FAULTING(_AC(1, ULL) << 0)
>>
>> +#define MSR_X2APIC_FIRST0x0800
>> +#define MSR_X2APIC_LAST 0x0bff
> I would use START and END because I think it's more natural rather
> that FIRST and LAST which to me seem to involve there being multiple
> x2APIC inside this range (but I'm not a native speaker, so FIRST and
> LAST might be just fine).
FIRST/LAST are entirely fine in this context, as far as English goes.
Last tends to be less ambiguous than end when it comes to fencepost
errors, as it is an inclusive term.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 02/15] xen/arm: move a few guest related #defines to public/arch-arm.h
On Wed, Jun 13, 2018 at 03:15:05PM -0700, Stefano Stabellini wrote: > Move a few constants defined by libxl_arm.c to > xen/include/public/arch-arm.h, so that they are together with the other > guest related #defines such as GUEST_GICD_BASE and GUEST_VPL011_SPI. > Also, this way they can be reused by hypervisor code. > > Signed-off-by: Stefano Stabellini > CC: wei.l...@citrix.com > CC: ian.jack...@eu.citrix.com FAOD I will defer this to Julien. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [seabios test] 124758: trouble: blocked/broken
flight 124758 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/124758/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-i386-pvops broken build-i386-xsm broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386 broken build-i386-xsm4 host-install(4)broken REGR. vs. 124521 build-amd64-xsm 4 host-install(4)broken REGR. vs. 124521 build-amd64-pvops 4 host-install(4)broken REGR. vs. 124521 build-amd64 4 host-install(4)broken REGR. vs. 124521 build-i386-pvops 4 host-install(4)broken REGR. vs. 124521 build-i3864 host-install(4)broken REGR. vs. 124521 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a version targeted for testing: seabios 69ea6dabeba4e080fc916a6bc9a2d53ffb4f916c baseline version: seabios 237fd3943d18d7d1a4c44aa2402c26fa62e7c380 Last test of basis 124521 2018-06-21 14:40:20 Z5 days Failing since124585 2018-06-22 06:10:18 Z5 days8 attempts Testing same since 124758 2018-06-27 07:27:42 Z0 days1 attempts People who touched revisions under test: Gerd Hoffmann jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-qemuu-nested-amdblocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictblocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-amd64-xl-qemuu-win10-i386 blocked
Re: [Xen-devel] [PATCH v2 8/8] tools/tests/depriv-fd-checker: Support checking of Linux tun devices
Wei Liu writes ("Re: [PATCH v2 8/8] tools/tests/depriv-fd-checker: Support
checking of Linux tun devices"):
> On Mon, Jun 11, 2018 at 03:13:24PM +0100, Ian Jackson wrote:
> > Signed-off-by: Ian Jackson
>
> The code looks OK. But I'm not sure how this is supposed to be used.
I'm not sure what you mean. You arrange for it to get a tun device.
It prints "tun maybe ...". You decide whether that
interface name is what you expected.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 8/8] tools/tests/depriv-fd-checker: Support checking of Linux tun devices
On Mon, Jun 11, 2018 at 03:13:24PM +0100, Ian Jackson wrote: > Signed-off-by: Ian Jackson The code looks OK. But I'm not sure how this is supposed to be used. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/2] x86/cpuid: Trivial fixes
This is some trivial prep work for the main CPUID work. Andrew Cooper (2): x86/cpuid: Fix up stale comments x86/cpuid: Alter the policy logic for leaf 0xb to be multi-invocation tools/libxc/xc_cpuid_x86.c | 11 ++- xen/arch/x86/cpuid.c| 43 --- xen/arch/x86/domctl.c | 13 ++--- xen/include/asm-x86/cpuid.h | 18 +- 4 files changed, 77 insertions(+), 8 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] x86/cpuid: Alter the policy logic for leaf 0xb to be multi-invocation
The new data lives in the .topo union, rather than being treated as a single
leaf in the basic union.
Host data is scanned when filling in the raw policy, but Xen still discards
any toolstack settings for now.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Ian Jackson
CC: Wei Liu
CC: Roger Pau Monné
---
tools/libxc/xc_cpuid_x86.c | 11 ++-
xen/arch/x86/cpuid.c| 41 +++--
xen/arch/x86/domctl.c | 8
xen/include/asm-x86/cpuid.h | 18 +-
4 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 21537f0..96c6c95 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -764,13 +764,22 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
domid,
if ( (regs[0] & 0x1f) != 0 )
continue;
}
+/* Extended Topology leaves. */
+else if ( input[0] == 0xb )
+{
+uint8_t level_type = regs[2] >> 8;
+
+input[1]++;
+if ( level_type >= 1 && level_type <= 2 )
+continue;
+}
input[0]++;
if ( !(input[0] & 0x8000u) && (input[0] > base_max ) )
input[0] = 0x8000u;
input[1] = XEN_CPUID_INPUT_UNUSED;
-if ( (input[0] == 4) || (input[0] == 7) )
+if ( (input[0] == 4) || (input[0] == 7) || (input[0] == 0xb) )
input[1] = 0;
else if ( input[0] == 0xd )
input[1] = 1; /* Xen automatically calculates almost everything. */
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index eca1a9a..a6f7bc6 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -205,7 +205,10 @@ static void recalculate_misc(struct cpuid_policy *p)
p->basic.raw[0x6] = EMPTY_LEAF; /* Therm/Power not exposed to guests. */
p->basic.raw[0x8] = EMPTY_LEAF;
-p->basic.raw[0xb] = EMPTY_LEAF; /* TODO: Rework topology logic. */
+
+/* TODO: Rework topology logic. */
+memset(p->topo.raw, 0, sizeof(p->topo.raw));
+
p->basic.raw[0xc] = EMPTY_LEAF;
p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
@@ -273,7 +276,7 @@ static void __init calculate_raw_policy(void)
{
switch ( i )
{
-case 0x4: case 0x7: case 0xd:
+case 0x4: case 0x7: case 0xb: case 0xd:
/* Multi-invocation leaves. Deferred. */
continue;
}
@@ -316,6 +319,33 @@ static void __init calculate_raw_policy(void)
cpuid_count_leaf(7, i, >feat.raw[i]);
}
+if ( p->basic.max_leaf >= 0xb )
+{
+union {
+struct cpuid_leaf l;
+struct cpuid_topo_leaf t;
+} u;
+
+for ( i = 0; i < ARRAY_SIZE(p->topo.raw); ++i )
+{
+cpuid_count_leaf(0xb, i, );
+
+if ( u.t.type == 0 )
+break;
+
+p->topo.subleaf[i] = u.t;
+}
+
+/*
+ * The choice of CPUID_GUEST_NR_TOPO is per the manual. It may need
+ * to grow for future harware.
+ */
+if ( i == ARRAY_SIZE(p->topo.raw) &&
+ (cpuid_count_leaf(0xb, i, ), u.t.type != 0) )
+printk(XENLOG_WARNING
+ "CPUID: Insufficient Leaf 0xb space for this hardware\n");
+}
+
if ( p->basic.max_leaf >= XSTATE_CPUID )
{
uint64_t xstates;
@@ -730,6 +760,13 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
*res = p->feat.raw[subleaf];
break;
+case 0xb:
+if ( subleaf >= ARRAY_SIZE(p->topo.raw) )
+return;
+
+*res = p->topo.raw[subleaf];
+break;
+
case XSTATE_CPUID:
if ( !p->basic.xsave || subleaf >= ARRAY_SIZE(p->xstate.raw) )
return;
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 105a576..3e9580b 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -70,6 +70,10 @@ static int update_domain_cpuid_info(struct domain *d,
ctl->input[1] >= ARRAY_SIZE(p->feat.raw) )
return 0;
+if ( ctl->input[0] == 0xb &&
+ ctl->input[1] >= ARRAY_SIZE(p->topo.raw) )
+return 0;
+
BUILD_BUG_ON(ARRAY_SIZE(p->xstate.raw) < 2);
if ( ctl->input[0] == XSTATE_CPUID &&
ctl->input[1] != 1 ) /* Everything else automatically calculated.
*/
@@ -100,6 +104,10 @@ static int update_domain_cpuid_info(struct domain *d,
p->feat.raw[ctl->input[1]] = leaf;
break;
+case 0xb:
+p->topo.raw[ctl->input[1]] = leaf;
+break;
+
case XSTATE_CPUID:
p->xstate.raw[ctl->input[1]] = leaf;
break;
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 4cce268..4113a5e 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -61,6 +61,7 @@ extern
[Xen-devel] [PATCH 1/2] x86/cpuid: Fix up stale comments
* There is no legacy path any more. All static information is retrieved in
the first pass.
* d->arch.cpuids[] doesn't exist any more.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/cpuid.c | 2 +-
xen/arch/x86/domctl.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index beee47d..eca1a9a 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -701,7 +701,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
* First pass:
* - Perform max_leaf/subleaf calculations. Out-of-range leaves return
* all zeros, following the AMD model.
- * - Fill in *res for leaves no longer handled on the legacy path.
+ * - Fill in *res with static data.
* - Dispatch the virtualised leaves to their respective handlers.
*/
switch ( leaf )
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 8fbbf3a..105a576 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -56,9 +56,8 @@ static int update_domain_cpuid_info(struct domain *d,
bool call_policy_changed = false; /* Avoid for_each_vcpu() unnecessarily */
/*
- * Skip update for leaves we don't care about. This avoids the overhead
- * of recalculate_cpuid_policy() and making d->arch.cpuids[] needlessly
- * longer to search.
+ * Skip update for leaves we don't care about, to avoid the overhead of
+ * recalculate_cpuid_policy().
*/
switch ( ctl->input[0] )
{
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 5/8] tools/tests/depriv: New test utility for deprivilege auditing
On Mon, Jun 11, 2018 at 03:13:21PM +0100, Ian Jackson wrote: > I have chosen to licence this utility as LGPL-v2.1-only, similar to > other LGPL elements of the Xen tools, because it may want to be moved > into or combined with osstest or some other project at some point in > the future, so it wants a licence compatible with osstest's AGPLv3+. > > Signed-off-by: Ian Jackson Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/6] x86/msr: Clean up the x2APIC MSR constants
On Tue, Jun 26, 2018 at 02:18:18PM +0100, Andrew Cooper wrote:
> The name MSR_IA32_APICBASE_MSR doesn't logically relate to its purpose.
> Rename it to MSR_X2APIC_FIRST and introduce a corresponding
> MSR_X2APIC_LAST to avoid opencoding the length of the x2APIC MSR range.
>
> For the specific registers, drop the IA32 infix, break the APIC part
> away from the register name, and drop the MSR suffix.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monné
Although I have some questions about the existing code.
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index d5334c9..48e2f8c 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2995,19 +2995,19 @@ void vmx_vlapic_msr_changed(struct vcpu *v)
> SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE;
> if ( cpu_has_vmx_apic_reg_virt )
> {
> -for ( msr = MSR_IA32_APICBASE_MSR;
> - msr <= MSR_IA32_APICBASE_MSR + 0xff; msr++ )
> +for ( msr = MSR_X2APIC_FIRST;
> + msr <= MSR_X2APIC_FIRST + 0xff; msr++ )
> vmx_clear_msr_intercept(v, msr, VMX_MSR_R);
I realize this is existing code, but do you know why 0xff is used here
instead of 0xbff (MSR_X2APIC_LAST) or 0x83f (which is the last
implemented x2APIC MSR)?.
>
> -vmx_set_msr_intercept(v, MSR_IA32_APICPPR_MSR, VMX_MSR_R);
> -vmx_set_msr_intercept(v, MSR_IA32_APICTMICT_MSR, VMX_MSR_R);
> -vmx_set_msr_intercept(v, MSR_IA32_APICTMCCT_MSR, VMX_MSR_R);
> +vmx_set_msr_intercept(v, MSR_X2APIC_PPR, VMX_MSR_R);
> +vmx_set_msr_intercept(v, MSR_X2APIC_TMICT, VMX_MSR_R);
> +vmx_set_msr_intercept(v, MSR_X2APIC_TMCCT, VMX_MSR_R);
> }
> if ( cpu_has_vmx_virtual_intr_delivery )
> {
> -vmx_clear_msr_intercept(v, MSR_IA32_APICTPR_MSR, VMX_MSR_W);
> -vmx_clear_msr_intercept(v, MSR_IA32_APICEOI_MSR, VMX_MSR_W);
> -vmx_clear_msr_intercept(v, MSR_IA32_APICSELF_MSR, VMX_MSR_W);
> +vmx_clear_msr_intercept(v, MSR_X2APIC_TPR, VMX_MSR_W);
> +vmx_clear_msr_intercept(v, MSR_X2APIC_EOI, VMX_MSR_W);
> +vmx_clear_msr_intercept(v, MSR_X2APIC_SELF, VMX_MSR_W);
> }
> }
> else
> @@ -3016,8 +3016,8 @@ void vmx_vlapic_msr_changed(struct vcpu *v)
> }
> if ( !(v->arch.hvm_vmx.secondary_exec_control &
> SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE) )
> -for ( msr = MSR_IA32_APICBASE_MSR;
> - msr <= MSR_IA32_APICBASE_MSR + 0xff; msr++ )
> +for ( msr = MSR_X2APIC_FIRST;
> + msr <= MSR_X2APIC_FIRST + 0xff; msr++ )
> vmx_set_msr_intercept(v, msr, VMX_MSR_RW);
>
> vmx_update_secondary_exec_control(v);
> diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
> index ce2e847..9d96e96 100644
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -49,6 +49,16 @@
> #define MSR_MISC_FEATURES_ENABLES 0x0140
> #define MISC_FEATURES_CPUID_FAULTING(_AC(1, ULL) << 0)
>
> +#define MSR_X2APIC_FIRST0x0800
> +#define MSR_X2APIC_LAST 0x0bff
I would use START and END because I think it's more natural rather
that FIRST and LAST which to me seem to involve there being multiple
x2APIC inside this range (but I'm not a native speaker, so FIRST and
LAST might be just fine).
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 6/8] tools/tests: Allow a test subdir to have `install' and `uninstall' targets
On Mon, Jun 11, 2018 at 03:13:22PM +0100, Ian Jackson wrote: > Signed-off-by: Ian Jackson Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 7/8] tools/tests/depriv: Install depriv-fd-checker in our private libexec directory
On Mon, Jun 11, 2018 at 03:13:23PM +0100, Ian Jackson wrote: > osstest is going to want to call it, and should not be expected to > fish it out of the build tree. > > Signed-off-by: Ian Jackson Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH] crontabs: Run freebsd-master only three times per week
freebsd master seems to update very frequently and our tests are
pretty minimal. Right now having a permanent freebsd build test going
is probably not a very good use of our resources.
CC: Roger Pau Monné
Signed-off-by: Ian Jackson
---
cr-for-branches | 2 +-
crontab | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cr-for-branches b/cr-for-branches
index 1c84c96..6f54437 100755
--- a/cr-for-branches
+++ b/cr-for-branches
@@ -31,7 +31,7 @@ scriptoptions="$1"; shift
LOGFILE=tmp/cr-for-branches.log
export LOGFILE
-: ${BRANCHES:=osstest xen-4.0-testing xen-4.1-testing xen-4.2-testing
xen-4.3-testing xen-4.4-testing xen-4.5-testing xen-4.6-testing xen-4.7-testing
xen-4.8-testing xen-4.9-testing xen-4.10-testing xen-4.11-testing xen-unstable
qemu-mainline qemu-upstream-unstable qemu-upstream-4.2-testing
qemu-upstream-4.3-testing qemu-upstream-4.4-testing qemu-upstream-4.5-testing
qemu-upstream-4.6-testing qemu-upstream-4.7-testing qemu-upstream-4.8-testing
qemu-upstream-4.9-testing qemu-upstream-4.10-testing qemu-upstream-4.11-testing
linux-linus linux-4.14 linux-4.9 linux-4.1 linux-3.18 linux-3.16 linux-3.14
linux-3.10 linux-3.4 linux-arm-xen seabios ovmf xtf freebsd-master
${EXTRA_BRANCHES}}
+: ${BRANCHES:=osstest xen-4.0-testing xen-4.1-testing xen-4.2-testing
xen-4.3-testing xen-4.4-testing xen-4.5-testing xen-4.6-testing xen-4.7-testing
xen-4.8-testing xen-4.9-testing xen-4.10-testing xen-4.11-testing xen-unstable
qemu-mainline qemu-upstream-unstable qemu-upstream-4.2-testing
qemu-upstream-4.3-testing qemu-upstream-4.4-testing qemu-upstream-4.5-testing
qemu-upstream-4.6-testing qemu-upstream-4.7-testing qemu-upstream-4.8-testing
qemu-upstream-4.9-testing qemu-upstream-4.10-testing qemu-upstream-4.11-testing
linux-linus linux-4.14 linux-4.9 linux-4.1 linux-3.18 linux-3.16 linux-3.14
linux-3.10 linux-3.4 linux-arm-xen seabios ovmf xtf ${EXTRA_BRANCHES}}
export BRANCHES
fetchwlem=$wlem
diff --git a/crontab b/crontab
index e7f2ad3..4e6a08e 100755
--- a/crontab
+++ b/crontab
@@ -11,7 +11,7 @@ MAILTO=osstest-ad...@xenproject.org
49 1 * * * cd testing.git &&
BRANCHES_ALWAYS=xen-unstable ./cr-for-branches branches -w "./cr-daily-branch
--real"
0 * * * * cd testing.git &&
BRANCHES=xen-unstable-smoke ./cr-for-branches branches -q "./cr-daily-branch
--real"
4-59/30* * * * cd testing.git &&
./cr-for-branches branches -q "./cr-daily-branch --real"
-18 9 * * 1,3,5 cd testing.git && BRANCHES=linux-next
./cr-for-branches branches -w "./cr-daily-branch --real"
+18 9 * * 1,3,5 cd testing.git && BRANCHES='linux-next
freebsd-master' ./cr-for-branches branches -w "./cr-daily-branch --real"
18 9 * * 3,7 cd testing.git &&
BRANCHES=xen-unstable-coverity ./cr-for-branches branches -w "./cr-daily-branch
--real"
34 15 23 * * cd testing.git && BRANCHES=examine
./cr-for-branches branches -w "./cr-daily-branch --real"
18 4 * * * cd testing.git && BRANCHES='linux-3.0
libvirt rumprun' ./cr-for-branches branches -w "./cr-daily-branch --real"
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/6] x86/msr: Clean up the MSR_APIC_BASE constants
On 27/06/18 14:32, Roger Pau Monné wrote:
> On Tue, Jun 26, 2018 at 02:18:17PM +0100, Andrew Cooper wrote:
>> We currently have MSR_IA32_APICBASE and MSR_IA32_APICBASE_MSR which are
>> synonymous from a naming point of view, but refer to very different
>> things.
>>
>> Cleave out the handling of MSR_APIC_BASE (0x1b), and rename
>> MSR_IA32_APICBASE_BASE to APIC_BASE_ADDR_MASK to better describe its
>> purpose.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Roger Pau Monné
>
>> diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
>> index ffa5a69..aa677e0 100644
>> --- a/xen/arch/x86/apic.c
>> +++ b/xen/arch/x86/apic.c
>> @@ -1446,23 +1448,21 @@ void __init record_boot_APIC_mode(void)
>> apic_mode_to_str(apic_boot_mode));
>> }
>>
>> -/* Look at the bits in MSR_IA32_APICBASE and work out which
>> - * APIC mode we are in */
>> +/* Look at the bits in MSR_APIC_BASE and work out which APIC mode we are in
>> */
>> enum apic_mode current_local_apic_mode(void)
>> {
>> u64 msr_contents;
>>
>> -rdmsrl(MSR_IA32_APICBASE, msr_contents);
>> +rdmsrl(MSR_APIC_BASE, msr_contents);
>>
>> /* Reading EXTD bit from the MSR is only valid if CPUID
>> * says so, else reserved */
>> -if ( boot_cpu_has(X86_FEATURE_X2APIC)
>> - && (msr_contents & MSR_IA32_APICBASE_EXTD) )
>> +if ( boot_cpu_has(X86_FEATURE_X2APIC) && (msr_contents &
>> APIC_BASE_EXTD) )
> While there you could change it to cpu_has_x2apic.
So I can. Thanks,
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/6] x86/msr: Introduce msr_{set, clear}_bits() helpers
On Tue, Jun 26, 2018 at 07:22:44PM +0100, Andrew Cooper wrote:
> One reoccuring code pattern is to read an MSR, modify one or more bits,
> and write the result back. Introduce helpers for this purpose.
>
> First, introduce rdmsr_split() and wrmsr_split() which are tiny static inline
> wrappers which deal with the MSR value in two 32bit halves.
>
> Next, construct msr_{set,clear}_bits() in terms of the {rdmsr,wrmsr}_split().
> The mask operations are deliberately performed as 32bit operations, because
> all callers pass in a constant to the mask parameter, and in all current
> cases, one of the two operations can be elided.
>
> For MSR_IA32_PSR_L3_QOS_CFG, switch PSR_L3_QOS_CDP_ENABLE from being a bit
> position variable to being a plain number.
>
> The resulting C is shorter, and doesn't require a temporary variable. The
> generated ASM is also more efficient, because of avoiding the
> packing/unpacking operations. e.g. the delta in the first hunk is from:
>
> b9 1b 00 00 00 mov$0x1b,%ecx
> 0f 32 rdmsr
> 48 c1 e2 20 shl$0x20,%rdx
> 48 09 d0or %rdx,%rax
> 80 e4 f3and$0xf3,%ah
> 48 89 c2mov%rax,%rdx
> 48 c1 ea 20 shr$0x20,%rdx
> 0f 30 wrmsr
>
> to:
>
> b9 1b 00 00 00 mov$0x1b,%ecx
> 0f 32 rdmsr
> 80 e4 f3and$0xf3,%ah
> 0f 30 wrmsr
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/6] x86/msr: Clean up the MSR_APIC_BASE constants
On Tue, Jun 26, 2018 at 02:18:17PM +0100, Andrew Cooper wrote:
> We currently have MSR_IA32_APICBASE and MSR_IA32_APICBASE_MSR which are
> synonymous from a naming point of view, but refer to very different
> things.
>
> Cleave out the handling of MSR_APIC_BASE (0x1b), and rename
> MSR_IA32_APICBASE_BASE to APIC_BASE_ADDR_MASK to better describe its
> purpose.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
> diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
> index ffa5a69..aa677e0 100644
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -1446,23 +1448,21 @@ void __init record_boot_APIC_mode(void)
> apic_mode_to_str(apic_boot_mode));
> }
>
> -/* Look at the bits in MSR_IA32_APICBASE and work out which
> - * APIC mode we are in */
> +/* Look at the bits in MSR_APIC_BASE and work out which APIC mode we are in
> */
> enum apic_mode current_local_apic_mode(void)
> {
> u64 msr_contents;
>
> -rdmsrl(MSR_IA32_APICBASE, msr_contents);
> +rdmsrl(MSR_APIC_BASE, msr_contents);
>
> /* Reading EXTD bit from the MSR is only valid if CPUID
> * says so, else reserved */
> -if ( boot_cpu_has(X86_FEATURE_X2APIC)
> - && (msr_contents & MSR_IA32_APICBASE_EXTD) )
> +if ( boot_cpu_has(X86_FEATURE_X2APIC) && (msr_contents & APIC_BASE_EXTD)
> )
While there you could change it to cpu_has_x2apic.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/6] x86/msr: Clean up the x2APIC MSR constants
On Tue, Jun 26, 2018 at 02:18:18PM +0100, Andrew Cooper wrote: > The name MSR_IA32_APICBASE_MSR doesn't logically relate to its purpose. > Rename it to MSR_X2APIC_FIRST and introduce a corresponding > MSR_X2APIC_LAST to avoid opencoding the length of the x2APIC MSR range. > > For the specific registers, drop the IA32 infix, break the APIC part > away from the register name, and drop the MSR suffix. > > Signed-off-by: Andrew Cooper > Reviewed-by: Kevin Tian Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/6] x86/msr: Clean up the MSR_APIC_BASE constants
On Tue, Jun 26, 2018 at 02:18:17PM +0100, Andrew Cooper wrote: > We currently have MSR_IA32_APICBASE and MSR_IA32_APICBASE_MSR which are > synonymous from a naming point of view, but refer to very different > things. > > Cleave out the handling of MSR_APIC_BASE (0x1b), and rename > MSR_IA32_APICBASE_BASE to APIC_BASE_ADDR_MASK to better describe its > purpose. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH V4] x86/altp2m: Fix crash with INVALID_ALTP2M EPTP index
xc_altp2m_set_vcpu_enable_notify() ends up calling
altp2m_vcpu_update_vmfunc_ve(), which sets the
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS bit on
vmx_secondary_exec_control. A subsequent call to
xc_altp2m_set_domain_state(..., false) (i.e. disabling altp2m
for the domain) ends up calling altp2m_vcpu_destroy(), which
calls (in this order) altp2m_vcpu_reset() (which sets the
current EPTP index to INVALID_ALTP2M), altp2m_vcpu_update_p2m()
(which __vmwrite()s EPTP_INDEX as INVALID_ALTP2M if
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set), and
altp2m_vcpu_update_vmfunc_ve() (which finally clears
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS).
However, vmx_vmexit_handler() __vmread()s EPTP_INDEX as soon as
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set, so if an
application enables altp2m on a domain, succesfully calls
xc_altp2m_set_vcpu_enable_notify(), then disables altp2m and
exits, a second run of said application will likely read the
INVALID_ALTP2M EPTP_INDEX set when disabling altp2m in the first
run, and crash the host with the BUG_ON(idx >= MAX_ALTP2M),
between xc_altp2m_set_vcpu_enable_notify() and
xc_altp2m_set_domain_state(..., false).
The problem is not restricted to an INVALID_ALTP2M EPTP_INDEX
(which cand only sanely happen on altp2m uninit), but applies
to any stale index previously saved - which means that all
altp2m_vcpu_update_vmfunc_ve() calls must also call
altp2m_vcpu_update_p2m() after setting
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS, in order to make sure
that the stored EPTP_INDEX is always valid at
vmx_vmexit_handler() time.
I don't however fold the two functions into one everywhere,
since in p2m_switch_domain_altp2m_by_id() and
p2m_switch_vcpu_altp2m_by_id() the extra work done by
altp2m_vcpu_update_vmfunc_ve() is unnecessary and has side
effects (such as __vmwrite(VM_FUNCTION_CONTROL, ...)).
Signed-off-by: Razvan Cojocaru
---
Changes since V3:
- Expanded and clarified the patch commit message.
---
xen/arch/x86/mm/altp2m.c | 1 -
xen/include/asm-x86/hvm/hvm.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index 930bdc2..9d60dc4 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -58,7 +58,6 @@ altp2m_vcpu_destroy(struct vcpu *v)
altp2m_vcpu_reset(v);
-altp2m_vcpu_update_p2m(v);
altp2m_vcpu_update_vmfunc_ve(v);
if ( v != current )
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index ef5e198..0bf6913 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -630,6 +630,8 @@ static inline void altp2m_vcpu_update_vmfunc_ve(struct vcpu
*v)
{
if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve )
hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v);
+
+altp2m_vcpu_update_p2m(v);
}
/* emulates #VE */
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] tools/libxl: Switch Arm guest type to PVH
On Mon, Jun 25, 2018 at 05:39:12PM +0100, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH RFC] tools/libxl: Switch Arm guest type
> to PVH"):
> > IMO I would remove the 'type' option from xl.cfg (so that it's
> > basically ignored) in the ARM case and force it internally to PVH (if
> > that's the best route for current ARM guests).
>
> What about libvirt users ? I haven't seen what a libvirt Xen ARM
> guest config looks like but we need to meak sure that existing guests
> don't break.
It may set type to pv. The following file is generated by the config
converter.
logs.test-lab.xenproject.org/osstest/logs/124566/test-armhf-armhf-libvirt-xsm/arndale-metrocentre---var-log-libvirt-libxl-debian.guest.osstest.log
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: Address "Bitwise-and with zero CONSTANT_EXPRESSION_RESULT" Coverity issues
>>> On 27.06.18 at 14:27, wrote: > Coverity complains at code which which performs a bitwise and with a constant > that happens to be zero. Both _PAGE_GNTTAB and PG_SH_enable may be 0 > depending on Kconfig settings. > > Rearrange the C to test the constant first and short circuit the bitwise and. Hmm, well, this makes the code look quite, ehem, interesting. Normally such would seem a prime candidate for cleaning up, especially without any comment attached. But anyway, if it helps ... > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-squeeze test] 74915: trouble: blocked/broken
flight 74915 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74915/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-i386 broken build-amd64-pvopsbroken build-armhf broken build-amd64 broken build-i386-pvops broken build-armhf 4 host-install(4) broken REGR. vs. 74890 build-armhf-pvops 4 host-install(4) broken REGR. vs. 74890 build-i386-pvops 4 host-install(4) broken REGR. vs. 74890 build-i3864 host-install(4) broken REGR. vs. 74890 build-amd64-pvops 4 host-install(4) broken REGR. vs. 74890 build-amd64 4 host-install(4) broken REGR. vs. 74890 Tests which did not succeed, but are not blocking: test-amd64-i386-i386-squeeze-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-squeeze-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-squeeze-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-squeeze-netboot-pygrub 1 build-check(1)blocked n/a baseline version: flight 74890 jobs: build-amd64 broken build-armhf broken build-i386 broken build-amd64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-squeeze-netboot-pygrubblocked test-amd64-i386-amd64-squeeze-netboot-pygrub blocked test-amd64-amd64-i386-squeeze-netboot-pygrub blocked test-amd64-i386-i386-squeeze-netboot-pygrub blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxl: make sure buffer is null-terminated in libxl_read_file_contents
On Wed, Jun 27, 2018 at 07:37:42PM +0800, Robin Lee wrote:
> On Wed, Jun 27, 2018 at 7:24 PM, Wei Liu wrote:
> > On Wed, Jun 27, 2018 at 07:08:02PM +0800, Robin Lee wrote:
> >> On Wed, Jun 27, 2018 at 6:58 PM, Wei Liu wrote:
> >> > On Wed, Jun 27, 2018 at 09:13:11AM +, Robin Lee wrote:
> >> >> On XenServer 7.1.1, we start a vm with XAPI but attach a block device
> >> >> with xl.
> >> >> We create an empty json config for the vm with the content "{}\n" and
> >> >> then
> >> >> run 'xl block-attach':
> >> >>
> >> >> # xl block-attach 1 phy:/dev/loop0 xvdz w
> >> >> libxl: error: libxl_json.c:950:libxl__json_parse: yajl error: parse
> >> >> error: trailing garbage
> >> >> {} K]
> >> >>(right here) --^
> >> >>
> >> >> libxl: error: libxl_json.c:1053:libxl__object_from_json: unable to
> >> >> generate libxl__json_object from JSON representation of
> >> >> libxl_domain_config.
> >> >> libxl: error: libxl.c:1995:device_addrm_aocomplete: unable to add
> >> >> device
> >> >> libxl_device_disk_add failed.
> >> >>
> >> >> After investigation, we found the buffer returned from
> >> >> libxl_read_file_contents
> >> >> is not null-terminated. But later in libxl__object_from_json, the
> >> >> buffer is expected to
> >> >> be null-terminated. So parsing may exceeded the end of file and get in
> >> >> to uninisialized
> >> >> momery area.
> >> >>
> >> >> Signed-off-by: Robin Lee
> >> >
> >> > I can't seem to be able to reproduce this in upstream xen. Which version
> >> > of Xen does XenServer 7.1.1 have? You can get that from the output of
> >> > `xl info` -- look for xen_{major, minor, extra}.
> >> I also met a strange case. We didn't see this problem with Xen 4.7.1
> >> that released with
> >> XenServer 7.1.1. But since a recently hotfix from XenServer that upgraded
> >> Xen to
> >> 4.7.4, this problem then shows up.
> >>
> >> The version of yajl (yajl-2.0.4-4.el7.x86_64) never changed.
> >
> > As far as I can tell, the stored json file already contains trailing 0,
> > even in 4.7.4. There is nothing interesting between 4.7.1 and 4.7.4 in
> > that area of code.
> In my situation, the json file is created with external program and contains
> just "{}\n" and not trailing 0.
Alright. In that case please append 0 to the file you created.
The json files are considered to be internal to libxl.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86: Address "Bitwise-and with zero CONSTANT_EXPRESSION_RESULT" Coverity issues
Coverity complains at code which which performs a bitwise and with a constant
that happens to be zero. Both _PAGE_GNTTAB and PG_SH_enable may be 0
depending on Kconfig settings.
Rearrange the C to test the constant first and short circuit the bitwise and.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Tim Deegan
CC: George Dunlap
---
xen/arch/x86/mm.c| 2 +-
xen/include/asm-x86/paging.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 2b74392..8d1120a 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1225,7 +1225,7 @@ void put_page_from_l1e(l1_pgentry_t l1e, struct domain
*l1e_owner)
* (Note that the undestroyable active grants are not a security hole in
* Xen. All active grants can safely be cleaned up when the domain dies.)
*/
-if ( (l1e_get_flags(l1e) & _PAGE_GNTTAB) &&
+if ( _PAGE_GNTTAB && (l1e_get_flags(l1e) & _PAGE_GNTTAB) &&
!l1e_owner->is_shutting_down && !l1e_owner->is_dying )
{
gdprintk(XENLOG_WARNING,
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index f008551..f0b6705 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -61,7 +61,8 @@
#define PG_MASK (PG_refcounts | PG_log_dirty | PG_translate | PG_external)
#define paging_mode_enabled(_d) (!!(_d)->arch.paging.mode)
-#define paging_mode_shadow(_d)(!!((_d)->arch.paging.mode & PG_SH_enable))
+#define paging_mode_shadow(_d)(PG_SH_enable && \
+ !!((_d)->arch.paging.mode & PG_SH_enable))
#define paging_mode_hap(_d) (!!((_d)->arch.paging.mode & PG_HAP_enable))
#define paging_mode_refcounts(_d) (!!((_d)->arch.paging.mode & PG_refcounts))
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V3] x86/altp2m: Fix crash with INVALID_ALTP2M EPTP index
>>> On 27.06.18 at 12:18, wrote: > On 06/27/2018 12:46 PM, Jan Beulich wrote: > On 26.06.18 at 16:21, wrote: >>> When SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set, >>> vmx_vcpu_update_eptp() __vmwrites() EPTP_INDEX in >>> altp2m_vcpu_destroy(). This means that when disabling altp2m on a >>> domain after xc_altp2m_set_vcpu_enable_notify() has been >>> successfully called, EPTP_INDEX ends up being stored as >>> INVALID_ALTP2M. This makes it possible for vmx_vmexit_handler() >>> to __vmread() the stale value after a subsequent call to >>> xc_altp2m_set_vcpu_enable_notify(), and BUG_ON(idx >= MAX_ALTP2M). >> >> I'm fine with the code change now, but I think this 3rd approach >> of addressing the issue needs the description to be changed. >> Already on v2 it wouldn't have become clear to me what the >> issue was from just reading the description. In particular you now >> want to point out why the change is correct / necessary also for >> the other invocation of altp2m_vcpu_update_vmfunc_ve(). It >> would also be helpful to have a statement on why other >> altp2m_vcpu_update_p2m() invocations don't need to be >> prefixed (now: replaced) by altp2m_vcpu_update_vmfunc_ve(). >> In the end it might well be that folding the two hooks into one is >> the best course of action. > > I'll do my best to make the description more readable. As for folding > the two hooks into one (I assume you mean having a single function, such > as, e.g. altp2m_vcpu_update_ve_and_p2m() and removing the other two), it > looks like vmx_vcpu_update_vmfunc_ve() does a few things that would be > unnnecessary (not optimal) in the general case. For example it calls > __vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING);, which > shouldn't necessarily happen at the callsites of > altp2m_vcpu_update_p2m(v) in p2m.c (in p2m_switch_vcpu_altp2m_by_id() > and p2m_switch_domain_altp2m_by_id()). So from that point of view, it > may be worth to keep both altp2m_vcpu_update_p2m() and > altp2m_vcpu_update_vmfunc_ve() (the latter still always needing to call > the former to do its job properly). > > It's possible that I've misunderstood your comment here though. I think you've understood me right; what you say makes sense at the first glance. Please summarize this in the commit message, so that further questions (perhaps also by others) can be avoided. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxl: make sure buffer is null-terminated in libxl_read_file_contents
On Wed, Jun 27, 2018 at 07:08:02PM +0800, Robin Lee wrote:
> On Wed, Jun 27, 2018 at 6:58 PM, Wei Liu wrote:
> > On Wed, Jun 27, 2018 at 09:13:11AM +, Robin Lee wrote:
> >> On XenServer 7.1.1, we start a vm with XAPI but attach a block device with
> >> xl.
> >> We create an empty json config for the vm with the content "{}\n" and then
> >> run 'xl block-attach':
> >>
> >> # xl block-attach 1 phy:/dev/loop0 xvdz w
> >> libxl: error: libxl_json.c:950:libxl__json_parse: yajl error: parse
> >> error: trailing garbage
> >> {} K]
> >>(right here) --^
> >>
> >> libxl: error: libxl_json.c:1053:libxl__object_from_json: unable to
> >> generate libxl__json_object from JSON representation of
> >> libxl_domain_config.
> >> libxl: error: libxl.c:1995:device_addrm_aocomplete: unable to add device
> >> libxl_device_disk_add failed.
> >>
> >> After investigation, we found the buffer returned from
> >> libxl_read_file_contents
> >> is not null-terminated. But later in libxl__object_from_json, the buffer
> >> is expected to
> >> be null-terminated. So parsing may exceeded the end of file and get in to
> >> uninisialized
> >> momery area.
> >>
> >> Signed-off-by: Robin Lee
> >
> > I can't seem to be able to reproduce this in upstream xen. Which version
> > of Xen does XenServer 7.1.1 have? You can get that from the output of
> > `xl info` -- look for xen_{major, minor, extra}.
> I also met a strange case. We didn't see this problem with Xen 4.7.1
> that released with
> XenServer 7.1.1. But since a recently hotfix from XenServer that upgraded Xen
> to
> 4.7.4, this problem then shows up.
>
> The version of yajl (yajl-2.0.4-4.el7.x86_64) never changed.
As far as I can tell, the stored json file already contains trailing 0,
even in 4.7.4. There is nothing interesting between 4.7.1 and 4.7.4 in
that area of code.
I'm afraid I can't take in your patch before we understand why the code
doesn't function as expected. The problem is likely to be somewhere
else.
You can inspect the files under /var/lib/xen (or the location configured
by XenServer). The names are like userdata-d.X.$UUID.libxl-json.
One theory is the upgrade left some stale libraries which your xl then
used. Use ldd `which xl` to see which libraries it used. And make sure
it uses the latest ones that come with the upgrade.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 124757: all pass - PUSHED
flight 124757 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/124757/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 6a3794ff6f6ec157f401e5e0c7dec2012ddc3cfc baseline version: freebsd f50037fe9555b6bcd7712d3d441c43c6599c9aff Last test of basis 124754 2018-06-27 02:51:32 Z0 days Testing same since 124757 2018-06-27 07:10:56 Z0 days1 attempts People who touched revisions under test: daichi imp miwi jobs: build-amd64-freebsd-againpass build-amd64-freebsd 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/freebsd.git f50037fe955..6a3794ff6f6 6a3794ff6f6ec157f401e5e0c7dec2012ddc3cfc -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/6] x86/msr: Clean up the MSR_FEATURE_CONTROL constants
On Tue, Jun 26, 2018 at 02:18:16PM +0100, Andrew Cooper wrote:
> The existing bit names are excessively long (45 chars!), and can be trimmed
> down substantially. Drop the IA32 prefix and abbreviate FEATURE_CONTROL to
> FEAT_CTL. Furthermore, all of these are feature enablement bits, so drop
> ENABLE/ON parts of the constants.
>
> While altering all the users, take the opportunity to introduce cpu_has_smx
> and clean up _vmx_cpu_up() with respect to its MSR_FEATURE_CONTROL handling.
>
> The SENTER constants are unreferenced and dropped.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index 884c672..95a0e37 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -610,9 +610,9 @@ void vmx_cpu_dead(unsigned int cpu)
>
> int _vmx_cpu_up(bool bsp)
> {
> -u32 eax, edx;
> -int rc, bios_locked, cpu = smp_processor_id();
> -u64 cr0, vmx_cr0_fixed0, vmx_cr0_fixed1;
> +int rc, cpu = smp_processor_id();
While there you could switch cpu to unsigned int.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxl: make sure buffer is null-terminated in libxl_read_file_contents
On 27/06/18 12:08, Robin Lee wrote:
> On Wed, Jun 27, 2018 at 6:58 PM, Wei Liu wrote:
>> On Wed, Jun 27, 2018 at 09:13:11AM +, Robin Lee wrote:
>>> On XenServer 7.1.1, we start a vm with XAPI but attach a block device with
>>> xl.
>>> We create an empty json config for the vm with the content "{}\n" and then
>>> run 'xl block-attach':
>>>
>>> # xl block-attach 1 phy:/dev/loop0 xvdz w
>>> libxl: error: libxl_json.c:950:libxl__json_parse: yajl error: parse
>>> error: trailing garbage
>>> {} K]
>>>(right here) --^
>>>
>>> libxl: error: libxl_json.c:1053:libxl__object_from_json: unable to
>>> generate libxl__json_object from JSON representation of libxl_domain_config.
>>> libxl: error: libxl.c:1995:device_addrm_aocomplete: unable to add device
>>> libxl_device_disk_add failed.
>>>
>>> After investigation, we found the buffer returned from
>>> libxl_read_file_contents
>>> is not null-terminated. But later in libxl__object_from_json, the buffer is
>>> expected to
>>> be null-terminated. So parsing may exceeded the end of file and get in to
>>> uninisialized
>>> momery area.
>>>
>>> Signed-off-by: Robin Lee
>> I can't seem to be able to reproduce this in upstream xen. Which version
>> of Xen does XenServer 7.1.1 have? You can get that from the output of
>> `xl info` -- look for xen_{major, minor, extra}.
> I also met a strange case. We didn't see this problem with Xen 4.7.1
> that released with
> XenServer 7.1.1. But since a recently hotfix from XenServer that upgraded Xen
> to
> 4.7.4, this problem then shows up.
A later hotfix even than that will bump to 4.7.5. (This is the
Spectre/Meltdown mitigations.)
XenServer has no interesting patches to libxl/xl, so this looks like it
may have been a regression which was backported into the stable trees.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
