[Xen-devel] [ovmf baseline-only test] 68262: tolerable FAIL
This run is configured for baseline tests only. flight 68262 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68262/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail like 68258 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail like 68258 version targeted for testing: ovmf 413535bb33d60417d681725af0274086630e7987 baseline version: ovmf d0c80b8a2de8ac90f51b86cce24e6c9c267ae5b4 Last test of basis68258 2016-12-22 02:17:43 Z1 days Testing same since68262 2016-12-23 02:20:28 Z0 days1 attempts People who touched revisions under test: Hao Wu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail 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. commit 413535bb33d60417d681725af0274086630e7987 Author: Hao Wu Date: Tue Nov 15 16:25:22 2016 +0800 NetworkPkg: Refine UintnToAscDecWithFormat functions logic This commit refines the logic for HttpBootUintnToAscDecWithFormat and PxeBcUintnToAscDecWithFormat. It avoids using the decrement operator '--' for array index to prevent possible mis-reports by static code checkers. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu Reviewed-by: Fu Siyuan Reviewed-by: Ye Ting Reviewed-by: Wu Jiaxin commit 81a108434041f6bed629123922772279d98d91a8 Author: Hao Wu Date: Tue Nov 15 16:12:30 2016 +0800 MdeModulePkg/UefiPxeBcDxe: Refine the CvtNum function logic This commit refines the logic for the CvtNum function. It avoids using the decrement operator '--' for array index to prevent possible mis-reports by static code checkers. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu Reviewed-by: Fu Siyuan Reviewed-by: Ye Ting Reviewed-by: Wu Jiaxin commit 69e856dfa56cebfba1abf160f3c86458dde850d4 Author: Hao Wu Date: Tue Nov 15 15:39:44 2016 +0800 MdeModulePkg/DxeNetLib: Rewrite NetblockChecksum function logic This commit rewrites the logic for NetblockChecksum. It processes the checksum of the left-over byte first to prevent possible mis-reports by static code checkers. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu Reviewed-by: Fu Siyuan Reviewed-by: Ye Ting Reviewed-by: Wu Jiaxin commit 9088c61e2d2de8c844f1850e6a96a69f81c0d010 Author: Hao Wu Date: Tue Nov 15 13:26:47 2016 +0800 MdePkg/MemoryLib: Refine InternalMemSetMem16|32|64 functions logic This commit refines the logic for InternalMemSetMem16|32|64 functions. It avoids using the decrement operator '--' for array index to prevent possible mis-reports by static code checkers. Please note that those modified functions are only consumed within MemoryLib by APIs SetMem16|32|64, and those APIs will handle the case when the input number of bytes to set is 0. Hence, the behavior of APIs SetMem16|32|64 is not changed. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu Reviewed-by: Michael Kinney commit 753a18f965cb9cd9e48d376a6c71823548eeb3a0 Author: Hao Wu Date: Wed Dec 7 10:39:03 2016 +0800 MdePkg/BaseLib: Add an additional check within (Ascii)StrnCmp This commit adds an addtional check in AsciiStrnCmp and StrnCmp. It explicitly checks the end of the sting pointed by 'SecondString' to make the code logic easier for reading and to prevent possible mis-reports by static code checkers. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu Reviewed-by: Michael Kinney commit c07c517cc51a4f947022aa5eebe2aace326137e5 Author: Hao Wu
[Xen-devel] [distros-debian-jessie test] 68263: regressions - FAIL
flight 68263 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68263/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-armhf-jessie-netboot-pygrub 14 guest-start/debian.repeat fail REGR. vs. 68229 Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail never pass test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail never pass baseline version: flight 68229 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-jessie-netboot-pvgrub pass test-amd64-i386-i386-jessie-netboot-pvgrub pass test-amd64-i386-amd64-jessie-netboot-pygrub pass test-armhf-armhf-armhf-jessie-netboot-pygrub fail test-amd64-amd64-i386-jessie-netboot-pygrub pass 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.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables
On Thu, Dec 22, 2016 at 01:19:36PM -0500, Boris Ostrovsky wrote: > On 12/22/2016 11:44 AM, Roger Pau Monne wrote: > > On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote: > > On 22.12.16 at 17:17, wrote: > >>> On 12/22/2016 07:17 AM, Roger Pau Monne wrote: > Maybe Boris has some ideas about how to do CPU hotplug for Dom0? > >>> Why would Xen need to be able to parse the AML that is intended to be > >>> executed by dom0? I'd think that all the hypervisor would need to do is > >>> to load it into memory, not any different from how it's done for regular > >>> guests. > >> Well, if Dom0 executed the unmodified _MAT, it would get back > >> data relating to the physical CPU. Roger is overriding MADT to > >> present virtual CPU information to Dom0, and this would likewise > >> need to happen for the _MAT return value. > > By "unmodified _MAT" you mean system's _MAT? Why can't we provide our > own that will return _MAT object properly adjusted for dom0? We are > going to provide our own (i.e. not system's) DSDT, aren't we? Providing Dom0 with a different DSDT is almost impossible from a Xen PoV, for once Xen cannot parse the original DSDT (because it's a dynamic table), and then if we would be to provide a modified DSDT, we would also need an asl assembler, so that we could parse the DSDT, modify it, and then compile it again in order to provide it to Dom0. Although all this code could be put under an init section that would be freed after Dom0 creation it seems overkill and very far from trivial, not to mention that I'm not even sure what side-effects there would be if Xen parsed the DSDT itself without having any drivers. > > This is one of the problems with this Dom/Xen0 split brain problem that we > > have, and cannot get away from. > > > > To clarify a little bit, I'm not overwriting the original MADT in memory, so > > Dom0 should still be able to access it if the implementation of _MAT returns > > data from that area. AFAICT when plugging in a physical CPU (pCPU) into the > > hardware, Dom0 should see "correct" data returned by the _MAT method. > > However > > (as represented by the " I've used), this data will not match Dom0 vCPU > > topology, and should not be used by Dom0 (only reported to Xen in order to > > bring up the new pCPU). > > So the problem seems to be that we need to run both _MATs --- system's > and dom0's. Exactly, we need _MAT for pCPUs and _MAT for _vCPUs. > > Then the problem arises because we have no way to perform vCPU hotplug for > > Dom0, not at least as it is done for DomU (using ACPI), so we would have to > > use > > an out-of-band method in order to do vCPU hotplug for Dom0, which is a PITA. > > > I would very much like to avoid this. Maybe we can provide an extra SSDT for Dom0 that basically overwrites the CPU objects (_PR.CPUX), but I'm not sure if ACPI allows this kind of objects overwrites? After reading the spec, I came across the following note in the SSDT section: "Additional tables can only add data; they cannot overwrite data from previous tables." So I guess this is a no-go. I only see the following options: - Prevent Dom0 from using the original _MAT methods (or even the full _PR.CPU objects) using the STAO, and then provide Dom0 with an out-of-band method (ie: not ACPI) in order to do CPU hotplug. - Expand the STAO so that it can be used to override ACPI namespace objects, possibly by adding a payload field that contains aml code. It seems that Linux already supports overwriting part of the ACPI namespace from user-space[0], so part of the needed machinery seem to be already in place (hopefully in acpica code?). - Disable the native CPU objects in the DSDT/SSDT using the STAO. Then pick up unused ACPI CPU IDs and use those for vCPUs. Provide an additional SSDT that contains ACPI objects for those vCPUs (as is done for DomU). This means we would probably have to start using x2APIC entries in the MADT, since the CPUs IDs might easily expand past 255 (AFAICT we could still keep the APIC IDs low however, since those two are disjoint). I don't really fancy any of these two options, probably the last one seems like the best IMHO, but I would like to hear some feedback about them, and of course I'm open to suggestions :). Roger. [0] https://www.kernel.org/doc/Documentation/acpi/method-customizing.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] tools/blktap2/drivers: Remove non-existent sys/sysctl.h include
On Thu, Dec 22, 2016 at 07:44:19AM -0800, Alistair Francis wrote: > On Thu, Dec 22, 2016 at 2:54 AM, Wei Liu wrote: > > On Tue, Dec 20, 2016 at 11:47:00AM -0800, Alistair Francis wrote: > >> To avoid build errors related to missing file 'sys/sysctl.h' by removing > >> the #include statement. > >> > >> Signed-off-by: Alistair Francis > > > > I can find this in Linux. Maybe this is also due to the libc you're > > using? > > Yes, I think you are right. I am using musl when I see the error. > > > > > On the flip side, if this header is unused anyway I think I'm fine with > > taking this patch. > > Thanks, that is what I was thinking too. > OK. I think I will need to update the commit message to: tools/blktap2: remove unused inclusion of sys/sysctl.h That header file is not used. Removing it would avoid build error with musl libc, which doesn't have that header. If you have no objection I can make the change while committing. Wei. > Thanks, > > Alistair > > > > >> --- > >> tools/blktap2/drivers/block-remus.c | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/tools/blktap2/drivers/block-remus.c > >> b/tools/blktap2/drivers/block-remus.c > >> index 079588d..7401800 100644 > >> --- a/tools/blktap2/drivers/block-remus.c > >> +++ b/tools/blktap2/drivers/block-remus.c > >> @@ -54,7 +54,6 @@ > >> #include > >> #include > >> #include > >> -#include > >> #include > >> #include > >> > >> -- > >> 2.7.4 > >> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 103803: regressions - FAIL
flight 103803 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/103803/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 103466 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 103394 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 103466 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 103466 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 103466 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103466 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103466 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 103466 test-amd64-amd64-xl-rtds 9 debian-install fail like 103466 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103466 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen fb4c92ffa661516e41d24974d3d0a2a3608caf68 baseline version: xen fc9229c4bb35c5474fbc67f78e628dcbcc90afc5 Last test of basis 103466 2016-12-16 13:24:29 Z6 days Failing since103540 2016-12-17 16:30:58 Z5 days8 attempts Testing same since 103803 2016-12-22 09:04:55 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Anshul Makkar Bhupinder Thakur Boris Ostrovsky Cédric Bosdonnat Daniel De Graaf Dario Faggioli Edgar E. Iglesias Haozhong Zhang Ian Jackson Jan Beulich Juergen Gross Julien Grall Kevin Tian Konrad Rzeszutek Wilk Praveen Kumar Razvan Cojocaru Roger Pau Monne Roger Pau Monné Ross Lagerwall Stefano Stabellini Suravee Suthikulpanit Tamas K Lengyel Tim Deegan Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386
Re: [Xen-devel] [PATCH] libxl/libxl_qmp.c: Fix code style in qmp_next()
On Fri, Dec 23, 2016 at 11:16:58AM +0800, Zhang Chen wrote: [...] > >>+ > >Here, as I understand it, read can return incomplete message. For > >example, when the buffer is not big enough. > > > >And the inner loop in original code handles that by checking if there is > >"\r\n". If not, it will read from the socket again. > > > >So I'm afraid this patch is not correct. Please point out if there is > >anything I missed. > > Yes, this patch have some logic error, but I think the code > looks odd like that: > " > } while (s < s_end); >} while (s < s_end); > " > > The original code use "break" and "continue" to control the double loop > that make people hard to understand. > > So, Can I change the code without "break" and "continue" like this? I'm not sure I follow how you would like to change the code. There is one continue for outer loop and one break for inner loop. I don't think you can eliminate the continue for outer loop, otherwise how could you restart the loop? > " > } while (end); > } while (s < s_end); > " As for this, I think it is buggy, too. It will cause the inner loop to loop indefinitely. Wei. > > If yes, I will fix this in next version. > > Thanks > Zhang Chen > > >Wei. > > > > > >. > > > > -- > Thanks > Zhang Chen > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] build: move setting LTO options to xen/Rules.mk
Having them in StdGNU.mk would affect both hypervisor and tools build. However judging from the commit message of e4cdd74f LTO was only meant to affect hypvervisor build. Move the relevant bits to xen/Rules.mk. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- config/StdGNU.mk | 4 xen/Rules.mk | 2 ++ 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/config/StdGNU.mk b/config/StdGNU.mk index 6be8233..039274e 100644 --- a/config/StdGNU.mk +++ b/config/StdGNU.mk @@ -35,7 +35,3 @@ UTIL_LIBS = -lutil SONAME_LDFLAG = -soname SHLIB_LDFLAGS = -shared -ifeq ($(lto),y) -CFLAGS += -flto -LDFLAGS-$(clang) += -plugin LLVMgold.so -endif diff --git a/xen/Rules.mk b/xen/Rules.mk index 24d13dc..77bcd44 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -120,6 +120,8 @@ $(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += - endif ifeq ($(CONFIG_LTO),y) +CFLAGS += -flto +LDFLAGS-$(clang) += -plugin LLVMgold.so # Would like to handle all object files as bitcode, but objects made from # pure asm are in a different format and have to be collected separately. # Mirror the directory tree, collecting them as built_in_bin.o. -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/2] build: minor adjustment
Wei Liu (2):
build: move debug{,_symbols} to tools/Rules.mk
build: use debug_symbols to add -g3
Config.mk | 9 -
tools/Rules.mk | 10 +-
2 files changed, 9 insertions(+), 10 deletions(-)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/2] build: move debug{, _symbols} to tools/Rules.mk
31d41d7b tried to make debug affect tools build only but failed to take care of debug_symbols (which appends "-g" to CFLAGS). Move both to tools/Rules.mk at once in this patch. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- Config.mk | 9 - tools/Rules.mk | 8 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/Config.mk b/Config.mk index b26e15c..189a443 100644 --- a/Config.mk +++ b/Config.mk @@ -16,11 +16,6 @@ or = $(if $(strip $(1)),$(1),$(if $(strip $(2)),$(2),$(if $(strip $(3)),$( -include $(XEN_ROOT)/.config -# A debug build of tools? -# Hypervisor debug build is controlled by Kconfig. -debug ?= y -debug_symbols ?= $(debug) - XEN_COMPILE_ARCH?= $(shell uname -m | sed -e s/i.86/x86_32/ \ -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \ -e s/armv7.*/arm32/ -e s/armv8.*/arm64/ \ @@ -211,10 +206,6 @@ define buildmakevars2header-closure $(call move-if-changed,$(1).tmp,$(1)) endef -ifeq ($(debug_symbols),y) -CFLAGS += -g -endif - CFLAGS += -fno-strict-aliasing CFLAGS += -std=gnu99 diff --git a/tools/Rules.mk b/tools/Rules.mk index 0e73690..9a87f18 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -26,6 +26,14 @@ CFLAGS_xeninclude = -I$(XEN_INCLUDE) XENSTORE_XENSTORED ?= y +# A debug build of tools? +debug ?= y +debug_symbols ?= $(debug) + +ifeq ($(debug_symbols),y) +CFLAGS += -g +endif + ifneq ($(nosharedlibs),y) INSTALL_SHLIB = $(INSTALL_PROG) SYMLINK_SHLIB = ln -sf -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/2] build: use debug_symbols to add -g3
While doing archeology I found 38ce7ce3, we should also make sure debug_symbols is the responsible for adding "-g" to CFLAGS. Move adding "-g3" from being guarded by debug to being guarded by debug_symbols. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- tools/Rules.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/Rules.mk b/tools/Rules.mk index 9a87f18..c8386b1 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -31,7 +31,7 @@ debug ?= y debug_symbols ?= $(debug) ifeq ($(debug_symbols),y) -CFLAGS += -g +CFLAGS += -g3 endif ifneq ($(nosharedlibs),y) @@ -146,7 +146,7 @@ SHLIB_libxenvchan = $(SHDEPS_libxenvchan) -Wl,-rpath-link=$(XEN_LIBVCHAN) ifeq ($(debug),y) # Disable optimizations and enable debugging information for macros -CFLAGS += -O0 -g3 -fno-omit-frame-pointer +CFLAGS += -O0 -fno-omit-frame-pointer # But allow an override to -O0 in case Python enforces -D_FORTIFY_SOURCE=. PY_CFLAGS += $(PY_NOOPT_CFLAGS) else -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue
On December 22, 2016 4:12 PM, Jan Beulich wrote: On 21.12.16 at 06:44, wrote: >> --- a/xen/arch/x86/hvm/vmx/intr.c >> +++ b/xen/arch/x86/hvm/vmx/intr.c >> @@ -315,9 +315,13 @@ void vmx_intr_assist(void) >> * Set eoi_exit_bitmap for periodic timer interrup to cause >EOI-induced VM >> * exit, then pending periodic time interrups have the chance >to be injected >> * for compensation >> +* Set eoi_exit_bitmap for intack.vector when it's higher than >pending >> +* periodic time interrupts. This way we can guarantee there's >always a chance >> +* to post periodic time interrupts when periodic time >interrupts becomes the >> +* highest one >> */ >> if (pt_vector != -1) >> -vmx_set_eoi_exit_bitmap(v, pt_vector); >> +vmx_set_eoi_exit_bitmap(v, intack.vector); > >The comment does not clarify why max(pt_vector, intack.vector) is not >needed. And I'd expect you to add ASSERT(intack.vector >= pt_vector) then, >to prove this (and one might argue that this addition could be sufficient >documentation, albeit perhaps a brief comment next to the assertion >would help readers of this non-trivial piece of code). > Kevin or Jan.. ASSERT(...) is ok to me.. Could you help me give a brief comment? Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] build: move setting LTO options to xen/Rules.mk
Having them in StdGNU.mk would affect both hypervisor and tools build. However judging from the commit message of e4cdd74f LTO was only meant to affect hypvervisor build. Move the relevant bits to xen/Rules.mk. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- config/StdGNU.mk | 4 xen/Rules.mk | 2 ++ 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/config/StdGNU.mk b/config/StdGNU.mk index 6be8233..039274e 100644 --- a/config/StdGNU.mk +++ b/config/StdGNU.mk @@ -35,7 +35,3 @@ UTIL_LIBS = -lutil SONAME_LDFLAG = -soname SHLIB_LDFLAGS = -shared -ifeq ($(lto),y) -CFLAGS += -flto -LDFLAGS-$(clang) += -plugin LLVMgold.so -endif diff --git a/xen/Rules.mk b/xen/Rules.mk index 24d13dc..77bcd44 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -120,6 +120,8 @@ $(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += - endif ifeq ($(CONFIG_LTO),y) +CFLAGS += -flto +LDFLAGS-$(clang) += -plugin LLVMgold.so # Would like to handle all object files as bitcode, but objects made from # pure asm are in a different format and have to be collected separately. # Mirror the directory tree, collecting them as built_in_bin.o. -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] build: move setting LTO options to xen/Rules.mk
On Fri, Dec 23, 2016 at 12:24:17PM +, Wei Liu wrote: > Having them in StdGNU.mk would affect both hypervisor and tools build. > However judging from the commit message of e4cdd74f LTO was only meant > to affect hypvervisor build. > > Move the relevant bits to xen/Rules.mk. > Ah, git send-email *.patch -- please ignore this patch in this series. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] How to find device name in order to fill STAO ACPI table
Hello, I've been looking into the STAO specification[0], because I think it would also be useful for x86 PVHv2 Dom0, but I'm not really sure how is Xen supposed to use it. Xen doesn't have an AML parser, so I'm not sure how is it supposed to guess the name of the devices it wants to hide from Dom0. Is there something I'm missing that can be used in order to find out the device name in the ACPI namespace without parsing AML tables? Thanks, Roger. [0] https://lists.xen.org/archives/html/xen-devel/2016-08/pdfYfOWKJ83jH.pdf ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Bug report
On Thu, Dec 22, 2016 at 05:07:58PM -0300, Ing. Ricardo Brisighelli wrote: > Hi my name is Richard and i suscribe to this list but dont know if this list > is for reports bugs. > Yes. Please read https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen Wei. > Tnks > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Stale Xenstore entries after start of domU with stubdom
Anyone an idea why I have additional stale Xenstore entries each time I've started a new domU with a stubdom? After 4 such starts I have: vm = "" -0100--fd7f-489bdb5a = "" memory = "6651" -0100--fc7f-48dbe98a = "" memory = "6651" -0100--ff7f-482b19f9 = "" memory = "6651" -0100--ff7f-48ebcf93 = "" memory = "6651" The "memory" size reported is the same as for dom0. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.8-testing test] 103807: tolerable FAIL - PUSHED
flight 103807 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103807/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103767 test-amd64-amd64-xl-rtds 9 debian-install fail like 103767 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103767 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 12 saverestore-support-checkfail never pass version targeted for testing: xen 24ccfc33272be300b306873b75352c0de3deca94 baseline version: xen b996efb23864f7135db3578a3a2059fe2f3c1a98 Last test of basis 103767 2016-12-20 04:56:08 Z3 days Testing same since 103792 2016-12-21 17:10:20 Z1 days2 attempts People who touched revisions under test: Jan Beulich jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2
[Xen-devel] [BUG]: [PATCH added] Incorrect queue counters in netback interface
Hello Xen Devel, We encountered an issue with one of our instances pushing a lot of (network) data, resulting in incorrect bandwidth reporting. We do poll interface traffic every 5 minutes for every interface of our instances (from Dom0) and store those values for reporting/graphing. At some point we discovered reports of machines pushing a lot of data, were incorrect and were going down in chucks of about 4 GB, while you expect this is an always increasing number (or wraps around a 32 or 64 bit counter) After futher analysing the problem and the source code we discovered that the counters of the queues in the code are handled as 32-bit integers, while the total bytes tx/rx for the while interface are counted as 64-bit longs. Attached a patch to solve the problem. Regards, Mart van Santen Below test results: Test existed of 2 DomU's on the same Dom0. Stats were gatherer from Dom0. The 2 DomU's were pushing data to each other using a network performance tool (iperf) Non-patched kernel results: node309 statistics # pwd /sys/devices/vif-2-0/net/vif2.0/statistics node309 statistics # node309 statistics # while [ 1 == 1 ]; do cat rx_bytes; sleep 1; done 873025622 1235062978 1572261463 2146257487 2700756931 3270058797 3843728761 113171325 665259289 1190130825 159865 1950490941 2499614765 3062263901 3640042389 4202300253 477729635 1046926733 ^C Patched kernel: node310 statistics # pwd /sys/devices/vif-2-0/net/vif2.0/statistics node310 statistics # while [ 1 == 1 ]; do cat rx_bytes; sleep 1; done 38069388494 38632298582 39187057066 39749628321 40316842297 40875579821 41440446165 42005641261 42539933757 42991421265 43543245209 44104655317 44666040545 45218321305 45780709593 46346749753 46897399881 47393645401 47687655485 48069251037 48463066305 48866467737 4926633 49695523708 50119597344 50541042376 50985332831 51446717847 51856736763 52234568347 52684797743 53250974835 53828014155 54406444595 54972895475 55548898027 55894007361 56408304870 56865463506 57435079678 57998185298 58577528786 59149894510 59715804286 60292539214 60861187894 61431075562 ^C (etc) (increasing numbers, as expected) -- Mart van Santen Greenhost E: m...@greenhost.nl T: +31 20 4890444 W: https://greenhost.nl A PGP signature can be attached to this e-mail, you need PGP software to verify it. My public key is available in keyserver(s) see: http://tinyurl.com/openpgp-manual PGP Fingerprint: CA85 EB11 2B70 042D AF66 B29A 6437 01A1 10A3 D3A5 --- a/drivers/net/xen-netback/common.h 2016-12-22 15:41:07.785535748 + +++ b/drivers/net/xen-netback/common.h 2016-12-23 13:08:18.123080064 + @@ -119,10 +119,10 @@ * A subset of struct net_device_stats that contains only the * fields that are updated in netback.c for each queue. */ - unsigned int rx_bytes; - unsigned int rx_packets; - unsigned int tx_bytes; - unsigned int tx_packets; + unsigned long rx_bytes; + unsigned long rx_packets; + unsigned long tx_bytes; + unsigned long tx_packets; /* Additional stats used by xenvif */ unsigned long rx_gso_checksum_fixup; signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 103842: tolerable all pass - PUSHED
flight 103842 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103842/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen ad891b1389cbafce2d31ef3f0c060c781689e2e0
baseline version:
xen 3ab1876504d409689824e161a8b04e57e1e5dd46
Last test of basis 103808 2016-12-22 15:01:57 Z0 days
Testing same since 103842 2016-12-23 12:01:45 Z0 days1 attempts
People who touched revisions under test:
Jan Beulich
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=ad891b1389cbafce2d31ef3f0c060c781689e2e0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
ad891b1389cbafce2d31ef3f0c060c781689e2e0
+ branch=xen-unstable-smoke
+ revision=ad891b1389cbafce2d31ef3f0c060c781689e2e0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' xad891b1389cbafce2d31ef3f0c060c781689e2e0 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/gi
[Xen-devel] [xen-4.7-testing test] 103802: regressions - FAIL
flight 103802 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103802/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 16 guest-start.2 fail in 103790 REGR. vs. 103769 Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt 3 host-install(3) broken in 103790 pass in 103802 test-amd64-amd64-xl-multivcpu 3 host-install(3) broken in 103790 pass in 103802 test-armhf-armhf-xl 6 xen-boot fail in 103790 pass in 103802 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail pass in 103790 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken in 103790 like 103769 test-amd64-i386-xl-qemut-win7-amd64 3 host-install(3) broken in 103790 like 103769 test-amd64-amd64-xl-pvh-intel 3 host-install(3) broken in 103790 like 103769 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103754 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103754 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 103754 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 103769 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 103769 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103769 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 103769 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass version targeted for testing: xen 9f3c5553ebf5978992cf02664002570e15ed8ebd baseline version: xen c5feb915d8536f235b74195bf33f4bb0e82734cd Last test of basis 103769 2016-12-20 06:00:24 Z3 days Testing same since 103790 2016-12-21 17:08:56 Z1 days2 attempts People who touched revisions under test: Jan Beulich jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386
Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables
On 12/23/2016 05:27 AM, Roger Pau Monne wrote: > On Thu, Dec 22, 2016 at 01:19:36PM -0500, Boris Ostrovsky wrote: >> On 12/22/2016 11:44 AM, Roger Pau Monne wrote: >>> On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote: >>> On 22.12.16 at 17:17, wrote: > On 12/22/2016 07:17 AM, Roger Pau Monne wrote: >> Maybe Boris has some ideas about how to do CPU hotplug for Dom0? > Why would Xen need to be able to parse the AML that is intended to be > executed by dom0? I'd think that all the hypervisor would need to do is > to load it into memory, not any different from how it's done for regular > guests. Well, if Dom0 executed the unmodified _MAT, it would get back data relating to the physical CPU. Roger is overriding MADT to present virtual CPU information to Dom0, and this would likewise need to happen for the _MAT return value. >> By "unmodified _MAT" you mean system's _MAT? Why can't we provide our >> own that will return _MAT object properly adjusted for dom0? We are >> going to provide our own (i.e. not system's) DSDT, aren't we? > Providing Dom0 with a different DSDT is almost impossible from a Xen PoV, for > once Xen cannot parse the original DSDT (because it's a dynamic table), and > then if we would be to provide a modified DSDT, we would also need an asl > assembler, so that we could parse the DSDT, modify it, and then compile it > again in order to provide it to Dom0. > > Although all this code could be put under an init section that would be freed > after Dom0 creation it seems overkill and very far from trivial, not to > mention > that I'm not even sure what side-effects there would be if Xen parsed the DSDT > itself without having any drivers. > >>> This is one of the problems with this Dom/Xen0 split brain problem that we >>> have, and cannot get away from. >>> >>> To clarify a little bit, I'm not overwriting the original MADT in memory, so >>> Dom0 should still be able to access it if the implementation of _MAT returns >>> data from that area. AFAICT when plugging in a physical CPU (pCPU) into the >>> hardware, Dom0 should see "correct" data returned by the _MAT method. >>> However >>> (as represented by the " I've used), this data will not match Dom0 vCPU >>> topology, and should not be used by Dom0 (only reported to Xen in order to >>> bring up the new pCPU). >> So the problem seems to be that we need to run both _MATs --- system's >> and dom0's. > Exactly, we need _MAT for pCPUs and _MAT for _vCPUs. > >>> Then the problem arises because we have no way to perform vCPU hotplug for >>> Dom0, not at least as it is done for DomU (using ACPI), so we would have to >>> use >>> an out-of-band method in order to do vCPU hotplug for Dom0, which is a PITA. >> >> I would very much like to avoid this. > Maybe we can provide an extra SSDT for Dom0 that basically overwrites the CPU > objects (_PR.CPUX), but I'm not sure if ACPI allows this kind of objects > overwrites? > > After reading the spec, I came across the following note in the SSDT section: > > "Additional tables can only add data; they cannot overwrite data from previous > tables." > > So I guess this is a no-go. > > I only see the following options: > > - Prevent Dom0 from using the original _MAT methods (or even the full _PR.CPU >objects) using the STAO, and then provide Dom0 with an out-of-band method >(ie: not ACPI) in order to do CPU hotplug. I don't see how we can have dom0 execute system's _MAT (or, indeed, anything in _PR_CPU) and not try to add the processor to its own (vCPU) list. > > - Expand the STAO so that it can be used to override ACPI namespace objects, >possibly by adding a payload field that contains aml code. It seems that >Linux already supports overwriting part of the ACPI namespace from >user-space[0], so part of the needed machinery seem to be already in place >(hopefully in acpica code?). At least judging by the pathname in sysfs this may be a debugging feature. Which doesn't mean it can't be used, but we'll need to confirm this with (Linux) APCI people. > > - Disable the native CPU objects in the DSDT/SSDT using the STAO. Then pick > up >unused ACPI CPU IDs and use those for vCPUs. Provide an additional SSDT > that >contains ACPI objects for those vCPUs (as is done for DomU). This means we >would probably have to start using x2APIC entries in the MADT, since the >CPUs IDs might easily expand past 255 (AFAICT we could still keep the APIC >IDs low however, since those two are disjoint). But this still assumes that dom0 handles ACPI event for a pCPUs as well, right? And I am not sure this can work. Actually, how do we hotplug pCPUs now? -boris > > I don't really fancy any of these two options, probably the last one seems > like > the best IMHO, but I would like to hear some feedback about them, and of > course > I'm open to suggestions :). > > Roger. > > [0] https://www.kernel.org/doc/Documentation/acpi/method-
Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables
On Fri, Dec 23, 2016 at 10:27:46AM +, Roger Pau Monne wrote: > On Thu, Dec 22, 2016 at 01:19:36PM -0500, Boris Ostrovsky wrote: > > On 12/22/2016 11:44 AM, Roger Pau Monne wrote: > > > On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote: > > > On 22.12.16 at 17:17, wrote: > > >>> On 12/22/2016 07:17 AM, Roger Pau Monne wrote: > > Maybe Boris has some ideas about how to do CPU hotplug for Dom0? > > >>> Why would Xen need to be able to parse the AML that is intended to be > > >>> executed by dom0? I'd think that all the hypervisor would need to do is > > >>> to load it into memory, not any different from how it's done for regular > > >>> guests. > > >> Well, if Dom0 executed the unmodified _MAT, it would get back > > >> data relating to the physical CPU. Roger is overriding MADT to > > >> present virtual CPU information to Dom0, and this would likewise > > >> need to happen for the _MAT return value. > > > > By "unmodified _MAT" you mean system's _MAT? Why can't we provide our > > own that will return _MAT object properly adjusted for dom0? We are > > going to provide our own (i.e. not system's) DSDT, aren't we? > > Providing Dom0 with a different DSDT is almost impossible from a Xen PoV, for > once Xen cannot parse the original DSDT (because it's a dynamic table), and > then if we would be to provide a modified DSDT, we would also need an asl > assembler, so that we could parse the DSDT, modify it, and then compile it > again in order to provide it to Dom0. > > Although all this code could be put under an init section that would be freed > after Dom0 creation it seems overkill and very far from trivial, not to > mention > that I'm not even sure what side-effects there would be if Xen parsed the DSDT > itself without having any drivers. > > > > This is one of the problems with this Dom/Xen0 split brain problem that we > > > have, and cannot get away from. > > > > > > To clarify a little bit, I'm not overwriting the original MADT in memory, > > > so > > > Dom0 should still be able to access it if the implementation of _MAT > > > returns > > > data from that area. AFAICT when plugging in a physical CPU (pCPU) into > > > the > > > hardware, Dom0 should see "correct" data returned by the _MAT method. > > > However > > > (as represented by the " I've used), this data will not match Dom0 vCPU > > > topology, and should not be used by Dom0 (only reported to Xen in order to > > > bring up the new pCPU). > > > > So the problem seems to be that we need to run both _MATs --- system's > > and dom0's. > > Exactly, we need _MAT for pCPUs and _MAT for _vCPUs. > > > > Then the problem arises because we have no way to perform vCPU hotplug for > > > Dom0, not at least as it is done for DomU (using ACPI), so we would have > > > to use > > > an out-of-band method in order to do vCPU hotplug for Dom0, which is a > > > PITA. > > > > > > I would very much like to avoid this. > > Maybe we can provide an extra SSDT for Dom0 that basically overwrites the CPU > objects (_PR.CPUX), but I'm not sure if ACPI allows this kind of objects > overwrites? > > After reading the spec, I came across the following note in the SSDT section: > > "Additional tables can only add data; they cannot overwrite data from previous > tables." > > So I guess this is a no-go. > > I only see the following options: > > - Prevent Dom0 from using the original _MAT methods (or even the full _PR.CPU >objects) using the STAO, and then provide Dom0 with an out-of-band method >(ie: not ACPI) in order to do CPU hotplug. > > - Expand the STAO so that it can be used to override ACPI namespace objects, >possibly by adding a payload field that contains aml code. It seems that >Linux already supports overwriting part of the ACPI namespace from >user-space[0], so part of the needed machinery seem to be already in place >(hopefully in acpica code?). > > - Disable the native CPU objects in the DSDT/SSDT using the STAO. Then pick > up >unused ACPI CPU IDs and use those for vCPUs. Provide an additional SSDT > that You need those so that the C and P state parser can actually parse the other CPU states which it will upload to Xen. >contains ACPI objects for those vCPUs (as is done for DomU). This means we >would probably have to start using x2APIC entries in the MADT, since the >CPUs IDs might easily expand past 255 (AFAICT we could still keep the APIC >IDs low however, since those two are disjoint). > - Import ACPI AML parser in Xen. > I don't really fancy any of these two options, probably the last one seems > like > the best IMHO, but I would like to hear some feedback about them, and of > course > I'm open to suggestions :). - Do the same thing we had been doing with Xen and Linux PV. Expose the full machine MADT and then massage it. Yuck. I am full of bad ideas today. ___ Xen-devel mailing list Xen-devel@lists.xen.org https:/
Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables
> But this still assumes that dom0 handles ACPI event for a pCPUs as well, > right? And I am not sure this can work. > > Actually, how do we hotplug pCPUs now? xen-hptool ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables
On 12/23/2016 10:31 AM, Konrad Rzeszutek Wilk wrote: >> But this still assumes that dom0 handles ACPI event for a pCPUs as well, >> right? And I am not sure this can work. >> >> Actually, how do we hotplug pCPUs now? > xen-hptool Yes, but this has nothing to do with an actual pCPU being hot-plugged into the system. It's similar to doing 'echo 1 > /sys/.../cpuX/online in Lnux. My question is --- how do we (hypervisor/dom0/toolstack) become aware of appearance of a new processor. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 103800: regressions - FAIL
flight 103800 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103800/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-i386-libvirt-pair 9 xen-boot/src_hostfail REGR. vs. 101675 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 101675 test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail REGR. vs. 101675 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 101675 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101675 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101675 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-amd64-pvgrub 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 101675 build-i386-pvops 5 kernel-build fail in 102732 REGR. vs. 101675 build-armhf-libvirt 4 host-build-prep fail in 102875 REGR. vs. 101675 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 103750 pass in 103800 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken in 103750 pass in 103800 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 103750 pass in 103800 test-amd64-amd64-xl-rtds 3 host-install(3) broken in 103750 pass in 103800 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 103750 pass in 103800 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 103786 pass in 103800 test-amd64-i386-libvirt-pair 3 host-install/src_host(3) broken in 103786 pass in 103800 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 103786 pass in 103800 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 103786 pass in 103800 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken in 103786 pass in 103800 test-amd64-amd64-libvirt-pair 3 host-install/src_host(3) broken in 103786 pass in 103800 test-amd64-i386-xl-qemut-win7-amd64 3 host-install(3) broken in 103786 pass in 103800 test-amd64-amd64-amd64-pvgrub 3 host-install(3) broken in 103786 pass in 103800 test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail in 103312 pass in 103800 test-armhf-armhf-libvirt 4 host-ping-check-native fail in 103688 pass in 103800 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail in 103750 pass in 103786 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 5 xen-install fail in 103750 pass in 103800 test-amd64-amd64-libvirt 5 xen-install fail in 103750 pass in 103800 test-amd64-i386-xl-xsm 11 guest-start fail in 103750 pass in 103800 test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-install fail in 103750 pass in 103800 test-amd64-i386-qemut-rhel6hvm-intel 11 guest-start/redhat.repeat fail in 103750 pass in 103800 test-armhf-armhf-xl-xsm 11 guest-start fail in 103750 pass in 103800 test-armhf-armhf-xl-multivcpu 6 xen-bootfail in 103786 pass in 103800 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 103786 pass in 103800 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 102732 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 102732 test-amd64-amd64-xl-xsm 6 xen-boot fail pass in 102732 test-amd64-amd64-i386-pvgrub 6 xen-boot fail pass in 102754 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 102823 test-amd64-amd64-libvirt 6 xen-boot fail pass in 102823 test-amd64-amd64-xl-credit2 6 xen-boot fail pass in 102875 test-amd64-i386-xl-raw6 xen-boot fail pass in 102875 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail pass in 102974 test-amd64-i386-freebsd10-i386 6 xen-boot fail pass in 103169 test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail pass in 103312 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail pass in 103688 test-amd64-i386-xl6 xen-boot fail pass in 103738 test-amd64-amd64-pygrub 6 xen-boot fail pass in 1
Re: [Xen-devel] [BUG]: [PATCH added] Incorrect queue counters in netback interface
On 23/12/16 15:24, Mart van Santen wrote: > Hello Xen Devel, > > We encountered an issue with one of our instances pushing a lot of > (network) data, resulting in incorrect bandwidth reporting. We do poll > interface traffic every 5 minutes for every interface of our instances > (from Dom0) and store those values for reporting/graphing. At some point > we discovered reports of machines pushing a lot of data, were incorrect > and were going down in chucks of about 4 GB, while you expect this is an > always increasing number (or wraps around a 32 or 64 bit counter) > > After futher analysing the problem and the source code we discovered > that the counters of the queues in the code are handled as 32-bit > integers, while the total bytes tx/rx for the while interface are > counted as 64-bit longs. > > > Attached a patch to solve the problem. ... > --- a/drivers/net/xen-netback/common.h2016-12-22 15:41:07.785535748 > + > +++ b/drivers/net/xen-netback/common.h2016-12-23 13:08:18.123080064 > + > @@ -119,10 +119,10 @@ >* A subset of struct net_device_stats that contains only the >* fields that are updated in netback.c for each queue. >*/ > - unsigned int rx_bytes; > - unsigned int rx_packets; > - unsigned int tx_bytes; > - unsigned int tx_packets; > + unsigned long rx_bytes; > + unsigned long rx_packets; > + unsigned long tx_bytes; > + unsigned long tx_packets; So on 32 bit kernels you'll still encounter the same problem. Please use the type "u64" as (nearly) everywhere else. You might want to read Documentation/SubmittingPatches in the Linux kernel source tree. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables
On Fri, Dec 23, 2016 at 10:35:10AM -0500, Boris Ostrovsky wrote: > On 12/23/2016 10:31 AM, Konrad Rzeszutek Wilk wrote: > >> But this still assumes that dom0 handles ACPI event for a pCPUs as well, > >> right? And I am not sure this can work. > >> > >> Actually, how do we hotplug pCPUs now? > > xen-hptool > > Yes, but this has nothing to do with an actual pCPU being hot-plugged > into the system. It's similar to doing 'echo 1 > /sys/.../cpuX/online in > Lnux. > > My question is --- how do we (hypervisor/dom0/toolstack) become aware of > appearance of a new processor. Ooooh. drivers/xen/xen-acpi-cpuhotplug.c But 213 config XEN_STUB 214 bool "Xen stub drivers" 215 depends on XEN && X86_64 && BROKEN 216 default n 235 config XEN_ACPI_HOTPLUG_CPU 236 tristate "Xen ACPI cpu hotplug" 237 depends on XEN_DOM0 && XEN_STUB && ACPI So it is probably very very badly not working. > > -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xl restore and migrating problem - hardware compatibility]
Hi, i'm gentoo user and try with xen 4.6.3 and 4.7.1 in both version have the same problem. My cpu is AMD A10-7860K I run VM as PVlinux, then try migrate to other server (same hardware) and dont work, same occurs when try restore a saved VM, but this works well (migrate and restore) if run VM as HVM. I try same instalation in cpu Intel I7-4790 and ir works well VM as PVlinux and HVM Hardware Problem #cat /proc/cpuinfo (only last core) proprocessor: 3 vendor_id : AuthenticAMD cpu family : 21 model : 56 model name : AMD A10-7860K Radeon R7, 12 Compute Cores 4C+8G stepping: 1 microcode : 0x6003106 cpu MHz : 3591.088 cache size : 2048 KB physical id : 0 siblings: 4 core id : 3 cpu cores : 4 apicid : 0 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu de tsc msr pae mce cx8 apic mca cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt l m constant_tsc rep_good nopl nonstop_tsc extd_apicid eagerfpu pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsav e avx f16c hypervisor lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch xop fma4 tce tbm perfctr _core perfctr_nb bpext arat cpb hw_pstate vmmcall fsgsbase bmi1 xsaveopt bugs: fxsave_leak bogomips: 7182.17 TLB size: 1536 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro [13] Migration problem: #xl migrate fs dstdomain migration target: Ready to receive domain. Saving to migration stream new xl format (info 0x3/0x0/1307) Loading new save file (new xl fmt info 0x3/0x0/1307) Savefile contains xl domain config in JSON format Parsing config from xc: info: Saving domain 5, type x86 PV xc: info: Found x86 PV domain from Xen 4.6 xc: info: Restoring domain xc: error: X86_PV_VCPU_MSRS record truncated: length 8, min 9: Internal error xc: error: Restore failed (0 = Success): Internal error libxl: error: libxl_stream_read.c:749:libxl__xc_domain_restore_done: restoring domain: Success libxl: error: libxl_create.c:1144:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1610:libxl__destroy_domid: non-existant domain 1 libxl: error: libxl.c:1568:domain_destroy_callback: unable to destroy guest with domid 1 libxl: error: libxl.c:1495:domain_destroy_cb: destruction of domain 1 failed migration target: Domain creation failed (code -3). libxl: error: libxl_utils.c:430:libxl_read_exactly: file/stream truncated reading ready message from migration receiver stream libxl: info: libxl_exec.c:118:libxl_report_child_exitstatus: migration transport process [4250] exited with error status 3 Migration failed, resuming at sender. Save and restore problem: #xl save fs fs.snap Saving to fs.snap new xl format (info 0x3/0x0/1307) xc: info: Saving domain 5, type x86 PV xc: Frames: 131072/131072 100% xc: End of stream: 0/00% #xl restore fs.snap Loading new save file fs.snap (new xl fmt info 0x3/0x0/1307) Savefile contains xl domain config in JSON format Parsing config from xc: info: Found x86 PV domain from Xen 4.6 xc: info: Restoring domain xc: error: X86_PV_VCPU_MSRS record truncated: length 8, min 9: Internal error xc: error: Restore failed (0 = Success): Internal error libxl: error: libxl_stream_read.c:749:libxl__xc_domain_restore_done: restoring domain: Success libxl: error: libxl_create.c:1144:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1610:libxl__destroy_domid: non-existant domain 6 libxl: error: libxl.c:1568:domain_destroy_callback: unable to destroy guest with domid 6 libxl: error: libxl.c:1495:domain_destroy_cb: destruction of domain 6 failed #verify-stream-v2 -v -f xl -i fs.snap Processed xl header Libxl Header: little endian Libxl Record: Libxc context, length 0 Libxc Image Header: little endian Domain Header: x86 PV from Xen 4.6 Libxc Record: x86 PV info, length 8 64bit guest, 4 levels of pagetables Libxc Record: x86 PV P2M frames, length 2056 Start pfn 0x0, End 0x1 Squashed 128 Page Data records together Libxc Record: TSC info, length 24 Mode 0, 3591089 kHz, 1189155414000 ns, incarnation 1 Libxc Record: Shared info, length 4096 Libxc Record: x86 PV vcpu basic, length 5176 vcpu0 basic context, 5168 bytes Libxc Record: x86 PV vcpu extended, length 64 vcpu0 extended context, 56 bytes Libxc Record: x86 PV vcpu xsave, length 856 vcpu0 xsave context, 848 bytes Libxc Record: x86 PV vcpu msrs, length 8 Stream Error: Traceback (most recent call last): File "/usr/libexec/xen/bin/verify-stream-v2", line 82, in read_stream VerifyLibxl(info, stream_read).verify() File "/usr/lib64/python2.7/site-packages/xen/migration/libxl.py", line 82, in verify whil
[Xen-devel] [xen-4.5-testing test] 103805: tolerable FAIL - PUSHED
flight 103805 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103805/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-migrupgrade 3 host-install/src_host(3) broken in 103791 pass in 103805 test-amd64-amd64-libvirt-pair 4 host-install/dst_host(4) broken in 103791 pass in 103805 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 103791 pass in 103805 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat fail pass in 103791 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 3 host-install(3) broken in 103791 like 103770 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 103791 like 103770 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103755 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103755 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103755 test-xtf-amd64-amd64-3 53 leak-check/check fail like 103770 test-amd64-amd64-xl-rtds 6 xen-boot fail like 103770 test-xtf-amd64-amd64-2 53 leak-check/check fail like 103770 test-xtf-amd64-amd64-1 53 leak-check/check fail like 103770 test-xtf-amd64-amd64-4 53 leak-check/check fail like 103770 test-xtf-amd64-amd64-5 53 leak-check/check fail like 103770 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 103770 test-armhf-armhf-xl-rtds 11 guest-start fail like 103770 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 103770 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-2 18 xtf/test-hvm32-cpuid-faulting fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-xtf-amd64-amd64-2 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-1 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 40 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 18 xtf/test-hvm32-cpuid-faulting fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-xtf-amd64-amd64-4 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 40 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-xsa-195 fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-5 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 40 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 40 xtf/test-hvm64-cpuid-faulting fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-xtf-amd64-amd64-1 52 xtf/test-hvm64-xsa-195 fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-xsa-195 fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 10 guest-start fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 10 guest-start fail never
Re: [Xen-devel] [xl restore and migrating problem - hardware compatibility]
On 23/12/16 16:32, Ing. Ricardo Brisighelli wrote:
Hi, i'm gentoo user and try with xen 4.6.3 and 4.7.1 in both version have the
same problem.
My cpu is AMD A10-7860K
This issue has been reported before ("[Xen-devel] "X86_PV_VCPU_MSRS
record truncated" during domain restore").
I submitted patches to fix it ("Fix issues with zero-length records in
migration v2" in July even), which made no progress. As the author of
migration v2, and unfortunately of this bug, I stand by v1 of my fix
without any further modification.
You can find the patches here:
https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/tools-fix-zero-length-records
Julien: As 4.9 RM, please mark this as a release blocker. It is very
poor that we as a community had this reported and fixed 6 months ago,
and yet it still didn't make it into 4.8
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables
On 12/23/2016 11:02 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Dec 23, 2016 at 10:35:10AM -0500, Boris Ostrovsky wrote: >> On 12/23/2016 10:31 AM, Konrad Rzeszutek Wilk wrote: But this still assumes that dom0 handles ACPI event for a pCPUs as well, right? And I am not sure this can work. Actually, how do we hotplug pCPUs now? >>> xen-hptool >> Yes, but this has nothing to do with an actual pCPU being hot-plugged >> into the system. It's similar to doing 'echo 1 > /sys/.../cpuX/online in >> Lnux. >> >> My question is --- how do we (hypervisor/dom0/toolstack) become aware of >> appearance of a new processor. > Ooooh. drivers/xen/xen-acpi-cpuhotplug.c Looking at this code I think we should be able to at least differentiate between pCPU and vCPU and not add pCPU to dom0. -boris > > > But > 213 config XEN_STUB > > 214 bool "Xen stub drivers" > > 215 depends on XEN && X86_64 && BROKEN > > 216 default n > > > 235 config XEN_ACPI_HOTPLUG_CPU > > 236 tristate "Xen ACPI cpu hotplug" > > 237 depends on XEN_DOM0 && XEN_STUB && ACPI > > So it is probably very very badly not working. > >> -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] ACPI suspend/resume not failing with (dom0) kernel panic
Hey, I was trying ACPI suspend/resume for testing some patches to Xen, on a box on which I'm 100% sure I've seen it working a few time back. Right now, suspending seems ok, but upon resuming, this is what I see (and after that, everything is just locked): [ 132.790494] smpboot: CPU 15 is now offline [ 132.797383] ACPI: Low-level resume complete [ 132.801635] PM: Restoring platform NVS memory [ 142.805036] Kernel panic - not syncing: DMAR hardware is malfunctioning [ 142.805036] [ 142.813109] CPU: 0 PID: 1386 Comm: pm-suspend Not tainted 4.8.0-2-amd64 #1 Debian 4.8.11-1 [ 142.821345] Hardware name: Dell Inc. Precision WorkStation T5500 /0CRH6C, BIOS A09 04/20/2011 [ 142.829928] 0086 ca1fa4d3 8cb269f5 89b99d076200 [ 142.837340] 89b99b763d48 8c97a6b2 0008 89b99b763d58 [ 142.844751] 89b99b763cf0 ca1fa4d3 0046 0002 [ 142.852159] Call Trace: [ 142.854602] [] ? dump_stack+0x5c/0x77 [ 142.859980] [] ? panic+0xe4/0x226 [ 142.865004] [] ? dmar_disable_qi+0x108/0x110 [ 142.870978] [] ? dmar_reenable_qi+0x1e/0x30 [ 142.876863] [] ? reenable_irq_remapping+0x2f/0x110 [ 142.883358] [] ? lapic_resume+0x1ed/0x290 [ 142.889073] [] ? syscore_resume+0x44/0x180 [ 142.894873] [] ? suspend_devices_and_enter+0x654/0x6f0 [ 142.901711] [] ? pm_suspend+0x321/0x3a0 [ 142.907253] [] ? state_store+0x6f/0xd0 [ 142.912707] [] ? kernfs_fop_write+0x118/0x1a0 [ 142.918766] [] ? vfs_write+0xb3/0x1a0 [ 142.924131] [] ? SyS_write+0x52/0xc0 [ 142.929413] [] ? system_call_fast_compare_end+0xc/0x96 [ 142.936264] Kernel Offset: 0xb80 from 0x8100 (relocation range: 0x8000-0xbfff) [ 142.947007] ---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning Does this ring any bell? Thanks and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [xl restore and migrating problem - hardware compatibility]
On 23/12/16 17:00, Andrew Cooper wrote:
On 23/12/16 16:32, Ing. Ricardo Brisighelli wrote:
Hi, i'm gentoo user and try with xen 4.6.3 and 4.7.1 in both version
have the
same problem.
My cpu is AMD A10-7860K
This issue has been reported before ("[Xen-devel] "X86_PV_VCPU_MSRS
record truncated" during domain restore").
I submitted patches to fix it ("Fix issues with zero-length records in
migration v2" in July even), which made no progress. As the author of
migration v2, and unfortunately of this bug, I stand by v1 of my fix
without any further modification.
You can find the patches here:
https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/tools-fix-zero-length-records
If you don't want to take patches, you should be able to work around the
issue by booting Xen with
cpuid_mask_ext_ecx=fbff
Specifically, you are looking to hide the DBEXT feature from Xen so it
doesn't choose to insert them into the migration stream to start with.
This migration bug only manifests when the hardware is capable, but the
VM isn't using the feature.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI suspend/resume not failing with (dom0) kernel panic
On 12/23/2016 12:16 PM, Dario Faggioli wrote: > Hey, > > I was trying ACPI suspend/resume for testing some patches to Xen, on a > box on which I'm 100% sure I've seen it working a few time back. > > Right now, suspending seems ok, but upon resuming, this is what I see > (and after that, everything is just locked): > > [ 132.790494] smpboot: CPU 15 is now offline > [ 132.797383] ACPI: Low-level resume complete > [ 132.801635] PM: Restoring platform NVS memory > [ 142.805036] Kernel panic - not syncing: DMAR hardware is malfunctioning > [ 142.805036] > [ 142.813109] CPU: 0 PID: 1386 Comm: pm-suspend Not tainted 4.8.0-2-amd64 #1 > Debian 4.8.11-1 > [ 142.821345] Hardware name: Dell Inc. Precision WorkStation T5500 /0CRH6C, > BIOS A09 04/20/2011 > [ 142.829928] 0086 ca1fa4d3 8cb269f5 > 89b99d076200 > [ 142.837340] 89b99b763d48 8c97a6b2 0008 > 89b99b763d58 > [ 142.844751] 89b99b763cf0 ca1fa4d3 0046 > 0002 > [ 142.852159] Call Trace: > [ 142.854602] [] ? dump_stack+0x5c/0x77 > [ 142.859980] [] ? panic+0xe4/0x226 > [ 142.865004] [] ? dmar_disable_qi+0x108/0x110 > [ 142.870978] [] ? dmar_reenable_qi+0x1e/0x30 > [ 142.876863] [] ? reenable_irq_remapping+0x2f/0x110 > [ 142.883358] [] ? lapic_resume+0x1ed/0x290 > [ 142.889073] [] ? syscore_resume+0x44/0x180 > [ 142.894873] [] ? suspend_devices_and_enter+0x654/0x6f0 > [ 142.901711] [] ? pm_suspend+0x321/0x3a0 > [ 142.907253] [] ? state_store+0x6f/0xd0 > [ 142.912707] [] ? kernfs_fop_write+0x118/0x1a0 > [ 142.918766] [] ? vfs_write+0xb3/0x1a0 > [ 142.924131] [] ? SyS_write+0x52/0xc0 > [ 142.929413] [] ? system_call_fast_compare_end+0xc/0x96 > [ 142.936264] Kernel Offset: 0xb80 from 0x8100 (relocation > range: 0x8000-0xbfff) > [ 142.947007] ---[ end Kernel panic - not syncing: DMAR hardware is > malfunctioning > > Does this ring any bell? Not really. Does this happen without your patches too? What about other Xen versions and/or baremetal? Try also booting Xen with "iommu=debug" and see if something shows up in the log. -boris signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI suspend/resume not failing with (dom0) kernel panic
On Fri, 2016-12-23 at 12:34 -0500, Boris Ostrovsky wrote: > On 12/23/2016 12:16 PM, Dario Faggioli wrote: > > [ 132.790494] smpboot: CPU 15 is now offline > > [ 132.797383] ACPI: Low-level resume complete > > [ 132.801635] PM: Restoring platform NVS memory > > [ 142.805036] Kernel panic - not syncing: DMAR hardware is > > malfunctioning > > [ 142.805036] > > [ 142.813109] CPU: 0 PID: 1386 Comm: pm-suspend Not tainted 4.8.0- > > 2-amd64 #1 Debian 4.8.11-1 > > [ 142.821345] Hardware name: Dell Inc. Precision WorkStation > > T5500 /0CRH6C, BIOS A09 04/20/2011 > > [ 142.829928] 0086 ca1fa4d3 8cb269f5 > > 89b99d076200 > > [ 142.837340] 89b99b763d48 8c97a6b2 0008 > > 89b99b763d58 > > [ 142.844751] 89b99b763cf0 ca1fa4d3 0046 > > 0002 > > [ 142.852159] Call Trace: > > [ 142.854602] [] ? dump_stack+0x5c/0x77 > > [ 142.859980] [] ? panic+0xe4/0x226 > > [ 142.865004] [] ? dmar_disable_qi+0x108/0x110 > > [ 142.870978] [] ? dmar_reenable_qi+0x1e/0x30 > > [ 142.876863] [] ? > > reenable_irq_remapping+0x2f/0x110 > > [ 142.883358] [] ? lapic_resume+0x1ed/0x290 > > [ 142.889073] [] ? syscore_resume+0x44/0x180 > > [ 142.894873] [] ? > > suspend_devices_and_enter+0x654/0x6f0 > > [ 142.901711] [] ? pm_suspend+0x321/0x3a0 > > [ 142.907253] [] ? state_store+0x6f/0xd0 > > [ 142.912707] [] ? kernfs_fop_write+0x118/0x1a0 > > [ 142.918766] [] ? vfs_write+0xb3/0x1a0 > > [ 142.924131] [] ? SyS_write+0x52/0xc0 > > [ 142.929413] [] ? > > system_call_fast_compare_end+0xc/0x96 > > [ 142.936264] Kernel Offset: 0xb80 from 0x8100 > > (relocation range: 0x8000-0xbfff) > > [ 142.947007] ---[ end Kernel panic - not syncing: DMAR hardware > > is malfunctioning > > > > Does this ring any bell? > > Not really. > > Does this happen without your patches too? What about other Xen > versions > and/or baremetal? > Yes, it happens without my patches. Xen version is current staging. I didn't think about testing baremetal. I've just done it, and yes, it _crashes_ in the same way. I'd say this is not a Xen issue then, and I should report to proper Linux people (after having tried 4.9, probably). Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] PROBLEM: Kernel BUG with raid5 soft + Xen + DRBD - invalid opcode
Hello Guys, I've having some trouble on a new system I'm setting up. I'm getting a kernel BUG message, seems to be related with the use of Xen (when I boot the system _without_ Xen, I don't get any crash). Here is configuration : - 3x Hard Drives running on RAID 5 Software raid created by mdadm - On top of it, DRBD for replication over another node (Active/passive cluster) - On top of it, a BTRFS FileSystem with a few subvolumes - On top of it, XEN VMs running. The BUG is happening when I'm making "huge" I/O (20MB/s with a rsync for example) on the RAID5 stack. I've to reset system to make it work again. Reproducible : ALWAYS (making the i/o, it crash in 2-5mins). Also reproducible on another system with the same hardware. Kernel versions impacted (at least): kernel-4.4.26, kernel-4.8.15, kernel-4.9.0 Here dmesg errors : [ 937.123220] [ cut here ] [ 937.127549] kernel BUG at drivers/md/raid5.c:527! [ 937.131891] invalid opcode: [#1] SMP [ 937.136216] Modules linked in: x86_pkg_temp_thermal coretemp crc32c_intel aesni_intel aes_x86_64 ablk_helper mei_me mei mpt3sas [ 937.145665] CPU: 2 PID: 9704 Comm: kworker/u16:8 Not tainted 4.9.0-gentoo #2 [ 937.150293] Hardware name: Supermicro Super Server/X10SDV-4C-7TP4F, BIOS 1.0b 11/21/2016 [ 937.155531] Workqueue: drbd0_submit do_submit [ 937.160506] task: 88026b0b2940 task.stack: c9000a66c000 [ 937.164115] RIP: e030:[] [] raid5_get_active_stripe+0x5e1/0x670 [ 937.169584] RSP: e02b:c9000a66fa58 EFLAGS: 00010086 [ 937.175070] RAX: RBX: 880249d5 RCX: 8802648bb5d0 [ 937.180640] RDX: RSI: 0001 RDI: 880249d5 [ 937.185505] RBP: c9000a66faf0 R08: 8801f4813288 R09: [ 937.190631] R10: 0288 R11: R12: [ 937.196030] R13: 1e773e88 R14: 880249d5 R15: 8802648bb400 [ 937.202011] FS: () GS:880270c8() knlGS:880270c8 [ 937.206628] CS: e033 DS: ES: CR0: 80050033 [ 937.212372] CR2: 7f68a101b520 CR3: 000257875000 CR4: 00042660 [ 937.217538] Stack: [ 937.223361] 8802648bb400 880269550b40 000166cf3800 [ 937.229103] 1e773e88 8802648bb5d0 0001 [ 937.233707] 8802648bb40c 0001 c9000a66faf0 880047cba958 [ 937.239736] Call Trace: [ 937.244406] [] raid5_make_request+0x17d/0xdf0 [ 937.250345] [] ? wake_up_atomic_t+0x30/0x30 [ 937.256173] [] md_make_request+0xe3/0x220 [ 937.261031] [] generic_make_request+0xcb/0x1a0 [ 937.265615] [] drbd_send_and_submit+0x497/0x1310 [ 937.271605] [] ? wake_up_atomic_t+0x30/0x30 [ 937.276726] [] send_and_submit_pending+0x6a/0x90 [ 937.282292] [] do_submit+0x463/0x550 [ 937.288333] [] ? wake_up_atomic_t+0x30/0x30 [ 937.293205] [] process_one_work+0x170/0x420 [ 937.298982] [] worker_thread+0x123/0x500 [ 937.304154] [] ? process_one_work+0x420/0x420 [ 937.310314] [] ? process_one_work+0x420/0x420 [ 937.316013] [] kthread+0xc5/0xe0 [ 937.320918] [] ? __switch_to+0x355/0x7a0 [ 937.327029] [] ? kthread_park+0x60/0x60 [ 937.331994] [] ret_from_fork+0x25/0x30 [ 937.338068] Code: 85 d0 fb ff ff f0 41 80 8f 98 02 00 00 04 e9 c2 fb ff ff f3 90 41 8b 47 70 a8 01 75 f6 89 45 a4 e9 e2 fd ff ff 0f 0b 0f 0b 0f 0b <0f> 0b 49 89 d6 e9 e1 fa ff ff 49 8b 82 e8 01 00 00 4d 8b 8a e0 [ 937.349579] RIP [] raid5_get_active_stripe+0x5e1/0x670 [ 937.355290] RSP [ 937.386587] ---[ end trace b870be01f61065a5 ]--- [ 941.931453] BUG: unable to handle kernel NULL pointer dereference at (null) [ 941.937139] IP: [] __wake_up_common+0x26/0x80 [ 941.943106] PGD 252dde067 [ 941.943219] PUD 252ee7067 [ 941.950107] PMD 0 [ 941.956080] Oops: [#2] SMP [ 941.961919] Modules linked in: x86_pkg_temp_thermal coretemp crc32c_intel aesni_intel aes_x86_64 ablk_helper mei_me mei mpt3sas [ 941.974933] CPU: 2 PID: 9704 Comm: kworker/u16:8 Tainted: G D 4.9.0-gentoo #2 [ 941.982080] Hardware name: Supermicro Super Server/X10SDV-4C-7TP4F, BIOS 1.0b 11/21/2016 [ 941.989296] task: 88026b0b2940 task.stack: c9000a66c000 [ 941.996831] RIP: e030:[] [] __wake_up_common+0x26/0x80 [ 942.004391] RSP: e02b:c9000a66fe50 EFLAGS: 00010086 [ 942.011818] RAX: 0200 RBX: c9000a66ff18 RCX: [ 942.019290] RDX: RSI: 0003 RDI: c9000a66ff18 [ 942.026779] RBP: c9000a66fe88 R08: R09: [ 942.034246] R10: 0008 R11: 0001 R12: c9000a66ff20 [ 942.041693] R13: 0200 R14: R15: 0003 [ 942.049166] FS: () GS:880270c8() knlGS:880270c8 [ 942.056599] CS: e033 DS: ES: CR0: 80050033 [ 942.063953] CR2: 002
[Xen-devel] [xen-4.4-testing test] 103812: tolerable FAIL - PUSHED
flight 103812 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103812/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 103796 pass in 103812 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail pass in 103796 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 103796 like 103756 test-xtf-amd64-amd64-4 16 xtf/test-pv32pae-selftestfail like 103782 test-xtf-amd64-amd64-2 16 xtf/test-pv32pae-selftestfail like 103782 test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail like 103782 test-xtf-amd64-amd64-3 32 xtf/test-hvm32pae-invlpg~shadow fail like 103782 test-xtf-amd64-amd64-2 53 leak-check/check fail like 103782 test-xtf-amd64-amd64-3 43 xtf/test-hvm64-invlpg~shadow fail like 103782 test-xtf-amd64-amd64-5 53 leak-check/check fail like 103782 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103782 test-xtf-amd64-amd64-4 53 leak-check/check fail like 103782 test-xtf-amd64-amd64-3 53 leak-check/check fail like 103782 test-xtf-amd64-amd64-1 53 leak-check/check fail like 103782 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103782 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 10 xtf-fep fail never pass test-xtf-amd64-amd64-4 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 10 xtf-fep fail never pass test-xtf-amd64-amd64-1 16 xtf/test-pv32pae-selftestfail never pass build-i386-rumprun7 xen-buildfail never pass test-xtf-amd64-amd64-4 30 xtf/test-hvm32pae-cpuid-faulting fail never pass build-amd64-rumprun 7 xen-buildfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-1 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 10 xtf-fep fail never pass test-xtf-amd64-amd64-2 10 xtf-fep fail never pass test-xtf-amd64-amd64-2 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-1 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 40 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-xtf-amd64-amd64-2 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 40 xtf/test-hvm64-cpuid-faulting fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-xtf-amd64-amd64-1 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-3 10 xtf-fep fail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-1 40 xtf/test-hvm64-cpuid-faulting fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-xsa-195 fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-xsa-195 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-xtf-amd64-amd64-1 52 xtf/test-hvm64-xsa-195 fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-s
[Xen-devel] [qemu-mainline test] 103818: tolerable FAIL - PUSHED
flight 103818 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/103818/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 103797 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103797 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 103797 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 103797 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103797 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 103797 test-amd64-amd64-xl-rtds 9 debian-install fail like 103797 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: qemuuc76904ef2fc920bc6f73a827412cedac0aa167ad baseline version: qemuu82ecffa8c050bf5bbc13329e9b65eac1caa5b55c Last test of basis 103797 2016-12-22 03:56:22 Z1 days Testing same since 103818 2016-12-22 23:15:04 Z0 days1 attempts People who touched revisions under test: Artyom Tarasenko [sparc part] Bastian Koppelmann [tricore part] Cornelia Huck [s390x part] Daniel P. Berrange Edgar E. Iglesias [crisµblaze part] Eduardo Habkost [i386 part] Guan Xuetao [unicore32 part] Hervé Poussineau Laurent Vivier [m68k part] Longpeng(Mike) Marc-André Lureau Max Filippov [xtensa part] Michael Walle [lm32 part] Peter Maydell Richard Henderson [alpha part] Samuel Thibault Thomas Huth Yuval Shaia jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl
Re: [Xen-devel] [PATCH v2 5/5] tools/blktap2/drivers: Removenon-existent sys/sysctl.h include
Hey Wei, Sorry about the top post but I’m doing this from my phone. That sounds good to me, you can use that commit message. Thanks, Alistair From: Wei Liu Sent: Friday, 23 December 2016 6:12 AM To: Alistair Francis Cc: Wei Liu; Doug Goldstein; ian.jack...@eu.citrix.com; imhy.y...@gmail.com; rshri...@cs.ubc.ca; xen-de...@lists.xenproject.org Subject: Re: [Xen-devel] [PATCH v2 5/5] tools/blktap2/drivers: Removenon-existent sys/sysctl.h include On Thu, Dec 22, 2016 at 07:44:19AM -0800, Alistair Francis wrote: > On Thu, Dec 22, 2016 at 2:54 AM, Wei Liu wrote: > > On Tue, Dec 20, 2016 at 11:47:00AM -0800, Alistair Francis wrote: > >> To avoid build errors related to missing file 'sys/sysctl.h' by removing > >> the #include statement. > >> > >> Signed-off-by: Alistair Francis > > > > I can find this in Linux. Maybe this is also due to the libc you're > > using? > > Yes, I think you are right. I am using musl when I see the error. > > > > > On the flip side, if this header is unused anyway I think I'm fine with > > taking this patch. > > Thanks, that is what I was thinking too. > OK. I think I will need to update the commit message to: tools/blktap2: remove unused inclusion of sys/sysctl.h That header file is not used. Removing it would avoid build error with musl libc, which doesn't have that header. If you have no objection I can make the change while committing. Wei. > Thanks, > > Alistair > > > > >> --- > >> tools/blktap2/drivers/block-remus.c | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/tools/blktap2/drivers/block-remus.c > >> b/tools/blktap2/drivers/block-remus.c > >> index 079588d..7401800 100644 > >> --- a/tools/blktap2/drivers/block-remus.c > >> +++ b/tools/blktap2/drivers/block-remus.c > >> @@ -54,7 +54,6 @@ > >> #include > >> #include > >> #include > >> -#include > >> #include > >> #include > >> > >> -- > >> 2.7.4 > >> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [xl restore and migrating problem - hardware compatibility]
El Vie 23 Dic 2016 17:16:32 Andrew Cooper escribió:
> On 23/12/16 17:00, Andrew Cooper wrote:
> > On 23/12/16 16:32, Ing. Ricardo Brisighelli wrote:
> >> Hi, i'm gentoo user and try with xen 4.6.3 and 4.7.1 in both version
> >> have the
> >> same problem.
> >>
> >> My cpu is AMD A10-7860K
> >
> > This issue has been reported before ("[Xen-devel] "X86_PV_VCPU_MSRS
> > record truncated" during domain restore").
> >
> > I submitted patches to fix it ("Fix issues with zero-length records in
> > migration v2" in July even), which made no progress. As the author of
> > migration v2, and unfortunately of this bug, I stand by v1 of my fix
> > without any further modification.
> >
> > You can find the patches here:
> > https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=r
> > efs/heads/tools-fix-zero-length-records
> If you don't want to take patches, you should be able to work around the
> issue by booting Xen with
>
> cpuid_mask_ext_ecx=fbff
>
> Specifically, you are looking to hide the DBEXT feature from Xen so it
> doesn't choose to insert them into the migration stream to start with.
> This migration bug only manifests when the hardware is capable, but the
> VM isn't using the feature.
>
> ~Andrew
Hi Andrew, first i try boot xen with cpuid_mask_ext_ecx=fbff, restore and
migration works well, then try apply the patchs
tools/python: Adjust migration v2 library to warn about...
tools/libxc: Avoid generating inappropriate zero-length...
tools/libxc: Tolerate zero-length records in migration...
remove cpuid_mask, recompile and install xen-4.7.1, reboot and the problem
persist. I'm missing something?
Regards
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [xl restore and migrating problem - hardware compatibility]
On 23/12/16 22:56, Ing. Ricardo Brisighelli wrote:
El Vie 23 Dic 2016 17:16:32 Andrew Cooper escribió:
On 23/12/16 17:00, Andrew Cooper wrote:
On 23/12/16 16:32, Ing. Ricardo Brisighelli wrote:
Hi, i'm gentoo user and try with xen 4.6.3 and 4.7.1 in both version
have the
same problem.
My cpu is AMD A10-7860K
This issue has been reported before ("[Xen-devel] "X86_PV_VCPU_MSRS
record truncated" during domain restore").
I submitted patches to fix it ("Fix issues with zero-length records in
migration v2" in July even), which made no progress. As the author of
migration v2, and unfortunately of this bug, I stand by v1 of my fix
without any further modification.
You can find the patches here:
https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=r
efs/heads/tools-fix-zero-length-records
If you don't want to take patches, you should be able to work around the
issue by booting Xen with
cpuid_mask_ext_ecx=fbff
Specifically, you are looking to hide the DBEXT feature from Xen so it
doesn't choose to insert them into the migration stream to start with.
This migration bug only manifests when the hardware is capable, but the
VM isn't using the feature.
~Andrew
Hi Andrew, first i try boot xen with cpuid_mask_ext_ecx=fbff, restore and
migration works well, then try apply the patchs
tools/python: Adjust migration v2 library to warn about...
tools/libxc: Avoid generating inappropriate zero-length...
tools/libxc: Tolerate zero-length records in migration...
remove cpuid_mask, recompile and install xen-4.7.1, reboot and the problem
persist. I'm missing something?
Does Gentoo split the various parts of Xen apart into sub-packages? This
needs to be the dom0 tools build, not the hypervisor build.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 103827: tolerable all pass - PUSHED
flight 103827 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103827/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 103479
test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 103479
test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 103479
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 103479
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
version targeted for testing:
libvirt 67882e56d1591402c292964960b3a80bd996ee69
baseline version:
libvirt 50b2a2375ad0eb26974039647fc705a32b10ac55
Last test of basis 103479 2016-12-16 17:26:38 Z7 days
Failing since103766 2016-12-20 04:20:04 Z3 days3 attempts
Testing same since 103827 2016-12-23 04:23:17 Z0 days1 attempts
People who touched revisions under test:
Andrea Bolognani
Boris Fiuczynski
Cédric Bosdonnat
Daniel P. Berrange
Guido Günther
Jiri Denemark
John Ferlan
Marc Hartmayer
Maxim Nestratov
Michal Privoznik
Nikolay Shirokovskiy
Pavel Hrdina
Peter Krempa
Pino Toscano
Shivaprasad G Bhat
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pairpass
test-amd64-i386-libvirt-pair pass
test-armhf-armhf-libvirt-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-amd64-libvirt-vhd pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=libvirt
+ revision=67882e56d1591402c292964960b3a80bd996ee69
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
[Xen-devel] [xen-4.5-testing baseline-only test] 68264: regressions - FAIL
This run is configured for baseline tests only. flight 68264 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68264/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-i386-pvgrub 6 xen-boot fail REGR. vs. 68250 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 68250 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail REGR. vs. 68250 Regressions which are regarded as allowable (not blocking): test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail like 68250 test-xtf-amd64-amd64-3 32 xtf/test-hvm32pae-invlpg~shadow fail like 68250 test-xtf-amd64-amd64-3 43 xtf/test-hvm64-invlpg~shadow fail like 68250 test-amd64-amd64-xl-rtds 6 xen-boot fail like 68250 test-xtf-amd64-amd64-4 53 leak-check/check fail like 68250 test-xtf-amd64-amd64-2 53 leak-check/check fail like 68250 test-xtf-amd64-amd64-1 53 leak-check/check fail like 68250 test-xtf-amd64-amd64-3 53 leak-check/check fail like 68250 test-xtf-amd64-amd64-5 53 leak-check/check fail like 68250 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 68250 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 68250 test-amd64-amd64-xl-qemut-winxpsp3 9 windows-install fail like 68250 Tests which did not succeed, but are not blocking: test-amd64-i386-rumprun-i386 10 rumprun-demo-xenstorels/xenstorels fail never pass test-amd64-amd64-rumprun-amd64 10 rumprun-demo-xenstorels/xenstorels fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-xsa-195 fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 10 guest-start fail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-1 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-xsa-195 fail never pass test-armhf-armhf-libvirt-raw 10 guest-start fail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-xsa-195 fail never pass test-armhf-armhf-xl-vhd 10 guest-start fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 0bd7faf010631d5bbebd2cf81c75a5f9ef635c51 baseline version: xen e3426e23cac566d508902fc5f49c8fc054111cf0 Last test of basis68250 2016-12-21 03:47:40 Z2 days Testing same since68264 2016-12-23 16:43:29 Z0 days1 attempts People who touched revisions under test: Jan Beulich jobs: build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass
[Xen-devel] [xen-unstable test] 103840: regressions - FAIL
flight 103840 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/103840/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 9 debian-di-installfail REGR. vs. 103394 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 103466 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 103466 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103466 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103466 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 103466 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 103466 test-amd64-amd64-xl-rtds 9 debian-install fail like 103466 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103466 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen 3ab1876504d409689824e161a8b04e57e1e5dd46 baseline version: xen fc9229c4bb35c5474fbc67f78e628dcbcc90afc5 Last test of basis 103466 2016-12-16 13:24:29 Z7 days Failing since103540 2016-12-17 16:30:58 Z6 days9 attempts Testing same since 103840 2016-12-23 11:23:56 Z0 days1 attempts People who touched revisions under test: Alistair Francis Andrew Cooper Anshul Makkar Bhupinder Thakur Boris Ostrovsky Cédric Bosdonnat Daniel De Graaf Dario Faggioli Edgar E. Iglesias Eric DeVolder Haozhong Zhang Ian Jackson Jan Beulich Juergen Gross Julien Grall Kevin Tian Konrad Rzeszutek Wilk Praveen Kumar Razvan Cojocaru Roger Pau Monne Roger Pau Monné Ross Lagerwall Stefano Stabellini Suravee Suthikulpanit Tamas K Lengyel Tim Deegan Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt
[Xen-devel] [linux-3.18 bisection] complete test-amd64-i386-pair
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-pair
testid xen-boot/src_host
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Bug introduced: 24542192519d21719377d89f14654b3afd993a61
Bug not present: c6f51aabaf400f357eebe8f8f17e8bb39fc033dc
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103876/
commit 24542192519d21719377d89f14654b3afd993a61
Author: Kashyap Desai
Date: Fri Oct 21 06:33:32 2016 -0700
scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough)
devices
[ Upstream commit 1e793f6fc0db920400574211c48f9157a37e3945 ]
Commit 02b01e010afe ("megaraid_sas: return sync cache call with
success") modified the driver to successfully complete SYNCHRONIZE_CACHE
commands without passing them to the controller. Disk drive caches are
only explicitly managed by controller firmware when operating in RAID
mode. So this commit effectively disabled writeback cache flushing for
any drives used in JBOD mode, leading to data integrity failures.
[mkp: clarified patch description]
Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
Reviewed-by: Hannes Reinecke
Reviewed-by: Ewan D. Milne
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-amd64-i386-pair.xen-boot--src_host.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/linux-3.18/test-amd64-i386-pair.xen-boot--src_host
--summary-out=tmp/103876.bisection-summary --basis-template=101675
--blessings=real,real-bisect linux-3.18 test-amd64-i386-pair xen-boot/src_host
Searching for failure / basis pass:
103800 fail [dst_host=nobling1,src_host=nobling0] / 101675
[dst_host=baroque1,src_host=baroque0] 101662 ok.
Failure / basis pass flights: 103800 / 101662
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest ac3d826bef907afe35f80ecccbcdd57223df4b88
c530a75c1e6a472b0eb9558310b518f0dfcd8860
b669e922b37b8957248798a5eb7aa96a666cd3fe
4220231eb22235e757d269722b9f6a594fbcb70f
fc9229c4bb35c5474fbc67f78e628dcbcc90afc5
Basis pass a6846cfd266b48af1ee7c3c19d5cb60477ca4469
c530a75c1e6a472b0eb9558310b518f0dfcd8860
c4e0d84d3c92923fdbc7fa922638d54e5e834753
6cfcdf037edadba984ccf8476b5d1e2a0940b789
0beaeccdd6cf8accfbdbeb8f92542a16eac81e5e
Generating revisions with ./adhoc-revtuple-generator
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#a6846cfd266b48af1ee7c3c19d5cb60477ca4469-ac3d826bef907afe35f80ecccbcdd57223df4b88
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
git://xenbits.xen.org/qemu-xen-traditional.git#c4e0d84d3c92923fdbc7fa922638d54e5e834753-b669e922b37b8957248798a5eb7aa96a666cd3fe
git://xenbits.xen.org/qemu-xen.git#6cfcdf037edadba984ccf8476b5d1e2a0940b789-4220231eb22235e757d269722b9f6a594fbcb70f
git://xenbits.xen.org/xen.git#0beaeccdd6cf8accfbdbeb8f92542a16eac81e5e-fc9229c4bb35c5474fbc67f78e628dcbcc90afc5
Loaded 7356 nodes in revision graph
Searching for test results:
101648 fail irrelevant
101637 fail irrelevant
101623 fail irrelevant
101662 pass a6846cfd266b48af1ee7c3c19d5cb60477ca4469
c530a75c1e6a472b0eb9558310b518f0dfcd8860
c4e0d84d3c92923fdbc7fa922638d54e5e834753
6cfcdf037edadba984ccf8476b5d1e2a0940b789
0beaeccdd6cf8accfbdbeb8f92542a16eac81e5e
101675 [dst_host=baroque1,src_host=baroque0]
102732 []
102754 fail irrelevant
102773 fail ac3d826bef907afe35f80ecccbcdd57223df4b88
c530a75c1e6a472b0eb9558310b518f0dfcd8860
89c4cbe8d234049b0145e4dc5e5d19d626250b57
4220231eb22235e757d269722b9f6a594fbcb70f
a7a578ce6b8634eec30cb8445ea98e18d9b4e9b8
102823 fail ac3d826bef907afe35f80ecccbcdd57223df4b88
c530a75c1e6a472b0eb9558310b518f0dfcd8860
89c4cbe8d234049b0145e4dc5e5d19d626250b57
4220231eb22235e757d269722b9f6a594fbcb70f
a7a578ce6b8634eec30cb8445ea98e18d9b4e9b8
102875
[Xen-devel] [xen-4.4-testing baseline-only test] 68265: tolerable FAIL
This run is configured for baseline tests only. flight 68265 xen-4.4-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68265/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 68256 test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail like 68256 test-xtf-amd64-amd64-3 32 xtf/test-hvm32pae-invlpg~shadow fail like 68256 test-xtf-amd64-amd64-3 43 xtf/test-hvm64-invlpg~shadow fail like 68256 test-xtf-amd64-amd64-2 20 xtf/test-hvm32-invlpg~shadow fail like 68256 test-xtf-amd64-amd64-2 32 xtf/test-hvm32pae-invlpg~shadow fail like 68256 test-xtf-amd64-amd64-2 43 xtf/test-hvm64-invlpg~shadow fail like 68256 test-xtf-amd64-amd64-4 53 leak-check/check fail like 68256 test-xtf-amd64-amd64-3 53 leak-check/check fail like 68256 test-xtf-amd64-amd64-5 53 leak-check/check fail like 68256 test-amd64-amd64-xl 19 guest-start/debian.repeatfail like 68256 test-xtf-amd64-amd64-2 53 leak-check/check fail like 68256 test-xtf-amd64-amd64-1 53 leak-check/check fail like 68256 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 68256 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 68256 test-amd64-i386-xend-qemut-winxpsp3 9 windows-install fail like 68256 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 10 xtf-fep fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-xtf-amd64-amd64-3 10 xtf-fep fail never pass test-xtf-amd64-amd64-5 10 xtf-fep fail never pass test-xtf-amd64-amd64-2 10 xtf-fep fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 11 guest-start fail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-1 10 xtf-fep fail never pass build-i386-rumprun6 xen-buildfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-xsa-195 fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass build-amd64-rumprun 6 xen-buildfail never pass test-xtf-amd64-amd64-1 52 xtf/test-hvm64-xsa-195 fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 394ddc2de62cbcaf9d28cc7373fde175e6ba3a5d baseline version: xen 5a343e41f55d23c74fa3bdf430dacfa47a1a74d7 Last test of basis68256 2016-12-21 22:13:30 Z2 days Testing same since68265 2016-12-23 19:43:40 Z0 days1 attempts People who touched revisions under test: Jan Beulich jobs: build-amd64-xend pass build-i386-xend pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build
[Xen-devel] [xen-4.8-testing test] 103847: regressions - FAIL
flight 103847 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103847/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pygrub 9 debian-di-installfail REGR. vs. 103807 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 103807 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 103807 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 103807 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103807 test-amd64-amd64-xl-rtds 9 debian-install fail like 103807 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103807 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 12 saverestore-support-checkfail never pass version targeted for testing: xen d57590205ebab425d670340c788a9ad4f4ad9914 baseline version: xen 24ccfc33272be300b306873b75352c0de3deca94 Last test of basis 103807 2016-12-22 14:33:10 Z1 days Testing same since 103847 2016-12-23 14:19:37 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun
[Xen-devel] [linux-4.1 test] 103832: regressions - FAIL
flight 103832 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103832/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101737 test-amd64-amd64-xl-pvh-intel 6 xen-bootfail REGR. vs. 101737 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101737 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101737 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 build-armhf-pvops 5 kernel-build fail in 102733 REGR. vs. 101737 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 103011 pass in 103832 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 103011 pass in 103832 test-amd64-i386-xl 3 host-install(3) broken in 103011 pass in 103832 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 103011 pass in 103832 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 103011 pass in 103832 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 103011 pass in 103832 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken in 103749 pass in 103832 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 103749 pass in 103832 test-amd64-amd64-xl-multivcpu 3 host-install(3) broken in 103784 pass in 103832 test-amd64-amd64-xl-pvh-intel 3 host-install(3) broken in 103784 pass in 103832 test-amd64-amd64-xl-xsm 3 host-install(3) broken in 103784 pass in 103832 test-amd64-i386-libvirt-xsm 3 host-install(3) broken in 103784 pass in 103832 test-amd64-i386-xl-qemut-win7-amd64 3 host-install(3) broken in 103784 pass in 103832 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 103784 pass in 103832 test-amd64-amd64-i386-pvgrub 3 host-install(3) broken in 103784 pass in 103832 test-amd64-amd64-pygrub 3 host-install(3) broken in 103784 pass in 103832 test-amd64-amd64-libvirt-vhd 9 debian-di-install fail in 102733 pass in 102886 test-amd64-amd64-xl-xsm 19 guest-start/debian.repeat fail in 102755 pass in 103089 test-armhf-armhf-libvirt-xsm 14 guest-stop fail in 102755 pass in 103832 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 102829 pass in 103832 test-amd64-i386-xl-xsm6 xen-boot fail in 102886 pass in 103832 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail in 102886 pass in 103832 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 102886 pass in 103832 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 103011 pass in 103832 test-armhf-armhf-libvirt-xsm 11 guest-start fail in 103011 pass in 103832 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 103089 pass in 103832 test-armhf-armhf-libvirt-xsm 6 xen-boot fail in 103451 pass in 103832 test-armhf-armhf-xl-credit2 6 xen-boot fail in 103749 pass in 103832 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail in 103749 pass in 103832 test-armhf-armhf-xl-arndale 5 xen-install fail in 103749 pass in 103832 test-armhf-armhf-libvirt 11 guest-start fail in 103784 pass in 103832 test-armhf-armhf-xl-rtds 9 debian-install fail in 103784 pass in 103832 test-amd64-i386-xl-raw6 xen-boot fail pass in 102733 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail pass in 102733 test-amd64-amd64-libvirt 6 xen-boot fail pass in 102733 test-amd64-i386-libvirt-xsm 6 xen-boot fail pass in 102755 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-boot fail pass in 102755 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail pass in 102829 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 102886 test-amd64-amd64-libvirt-vhd 6 xen-boot fail pass in 102886 test-amd64-i386-freebsd10-i386 6 xen-boot fail pass in 103011 test-amd64-amd64-xl-rtds 6 xen-boot fail pass in 103089 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 103089 test-amd64-amd64-xl-xsm 6 xen-boot fail pass in 103089 test-amd64-amd64-libvirt-pair 9 xen-boot/src_host
[Xen-devel] [qemu-mainline baseline-only test] 68266: regressions - FAIL
This run is configured for baseline tests only. flight 68266 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68266/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pair 11 host-ping-check-xen/src_host fail REGR. vs. 68261 test-armhf-armhf-xl-vhd 9 debian-di-install fail REGR. vs. 68261 Regressions which are regarded as allowable (not blocking): test-amd64-i386-freebsd10-i386 10 guest-start fail like 68261 test-amd64-i386-freebsd10-amd64 10 guest-start fail like 68261 test-amd64-amd64-qemuu-nested-intel 9 debian-hvm-install fail like 68261 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail like 68261 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail like 68261 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail like 68261 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-installfail like 68261 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: qemuuc76904ef2fc920bc6f73a827412cedac0aa167ad baseline version: qemuu82ecffa8c050bf5bbc13329e9b65eac1caa5b55c Last test of basis68261 2016-12-22 23:21:47 Z1 days Testing same since68266 2016-12-23 21:14:28 Z0 days1 attempts People who touched revisions under test: Artyom Tarasenko [sparc part] Bastian Koppelmann [tricore part] Cornelia Huck [s390x part] Daniel P. Berrange Edgar E. Iglesias [crisµblaze part] Eduardo Habkost [i386 part] Guan Xuetao [unicore32 part] Hervé Poussineau Laurent Vivier [m68k part] Longpeng(Mike) Marc-André Lureau Max Filippov [xtensa part] Michael Walle [lm32 part] Peter Maydell Richard Henderson [alpha part] Samuel Thibault Thomas Huth Yuval Shaia jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass buil
