Re: [Xen-devel] [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0
Hi Doug, > > 0 day build tests the kernel all the time, even if my patch gets > > missed, after a few days other will immediately notice. These days > > its extremely hard for me to build linux-next and have a build > > issue. > > > > I recommend we push on the momentum to see if we can piggy back > > on doing regular 0 day build tests with Xen too if possible. > > > >Luis > > Got links to where this is run? I'm assuming its using Autotest [1]? > > [1] https://autotest.github.io/ The 0day test infrastructure is running in Intel OTC Shanghai site. Most test scripts we run are available in the lkp-tests git tree, for example, autotest: https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/tests/autotest The project home page is at https://01.org/lkp The build test reports are archived in the kbuild-all mailing list: https://lists.01.org/pipermail/kbuild-all/2016-January/thread.html The runtime test reports are archived in the lkp list: https://lists.01.org/pipermail/lkp/2016-January/thread.html Thanks, Fengguang ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 80836: regressions - FAIL
flight 80836 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/80836/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543 version targeted for testing: ovmf 8de84d4242215252af9d2afecd45e2419689ee5f baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 60 days Failing since 65593 2015-12-08 23:44:51 Z 60 days 65 attempts Testing same since80836 2016-02-06 01:54:25 Z1 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Yao, Jiewen" Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Charles Duffy Cinnamon Shia Dandan Bi Daocheng Bu Daryl McDaniel Eric Dong Eric Dong Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Hao Wu Hess Chen Heyi Guo Jaben Carsey Jeff Fan Jiaxin Wu Jim Dailey Jordan Justen Karyne Mayer Larry Hauch Laszlo Ersek Leekha Shaveta Liming Gao Mark Rutland Michael Kinney Michael Thomas Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Qin Long Qiu Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Star Zeng Tapan Shah Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zhang Lubo 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.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 8049 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 80855: regressions - FAIL
flight 80855 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/80855/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 80121 test-armhf-armhf-libvirt-raw 6 xen-boot fail REGR. vs. 80121 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 80121 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 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-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-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass version targeted for testing: libvirt dcb3d87d789459f5374cfeb2b7050e19fa1ac9ea baseline version: libvirt 6ec319b84f67d72bf59fe7e0fd41d88ee9c393c7 Last test of basis80121 2016-02-03 04:26:28 Z3 days Failing since 80382 2016-02-04 04:29:24 Z2 days3 attempts Testing same since80855 2016-02-06 04:44:27 Z0 days1 attempts People who touched revisions under test: Cole Robinson Daniel P. Berrange Dmitry Andreev Erik Skultety Joao Martins John Ferlan Ján Tomko Martin Kletzander Michal Privoznik Nikolay Shirokovskiy Peter Krempa Roman Bogorodskiy Wido den Hollander 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 fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairfail test-amd64-i386-libvirt-pair fail test-armhf-armhf-libvirt-qcow2 fail test-armhf-armhf-libvirt-raw fail 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 Not pushing. (No revision log; it would be 608 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 test] 80752: regressions - FAIL
flight 80752 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/80752/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 66399 test-armhf-armhf-xl-xsm 16 guest-start.2fail in 80172 REGR. vs. 66399 test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 80533 REGR. vs. 66399 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-xsm 11 guest-startfail in 80370 pass in 80752 test-armhf-armhf-xl-rtds 11 guest-startfail in 80370 pass in 80752 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 80533 pass in 80752 test-armhf-armhf-xl-credit2 8 leak-check/basis(8) fail in 80533 pass in 80752 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail pass in 80172 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail pass in 80370 test-armhf-armhf-xl 11 guest-start fail pass in 80533 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 66399 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 66399 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 66399 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-check fail in 80533 never pass test-armhf-armhf-xl 13 saverestore-support-check fail in 80533 never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 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-amd64-i386-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-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 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-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass version targeted for testing: linux2d5f6b0413359df065fd02d695c08bbc7d998bbd baseline version: linux07cc49f66973f49a391c91bf4b158fa0f2562ca8 Last test of basis66399 2015-12-15 18:20:39 Z 53 days Failing since 78925 2016-01-24 13:50:39 Z 13 days 16 attempts Testing same since79642 2016-01-31 21:28:16 Z6 days7 attempts People who touched revisions under test: Acked-by: David Howells Al Viro Alan Stern Alexandra Yates Alexandru Cornea Alexei Starovoit
Re: [Xen-devel] [PATCH v2 03/13] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op (v7)
On 1/14/16 3:47 PM, Konrad Rzeszutek Wilk wrote:
> The implementation does not actually do any patching.
>
> It just adds the framework for doing the hypercalls,
> keeping track of ELF payloads, and the basic operations:
> - query which payloads exist,
> - query for specific payloads,
> - check*1, apply*1, replace*1, and unload payloads.
>
> *1: Which of course in this patch are nops.
>
> Acked-by: Daniel De Graaf
> Signed-off-by: Konrad Rzeszutek Wilk
> Signed-off-by: Ross Lagerwall
>
> ---
> v2: Rebased on keyhandler: rework keyhandler infrastructure
> v3: Fixed XSM.
> v4: Removed REVERTED state.
> Split status and error code.
> Add REPLACE action.
> Separate payload data from the payload structure.
> s/XSPLICE_ID_../XSPLICE_NAME_../
> v5: Add xsplice and CONFIG_XSPLICE build toption.
> Fix code per Jan's review.
> Update the sysctl.h (change bits to enum like)
> v6: Rebase on Kconfig changes.
> v7: Add missing pad checks. Re-order keyhandler.h to build on ARM.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> tools/flask/policy/policy/modules/xen/xen.te | 1 +
> xen/arch/arm/Kconfig | 1 +
> xen/arch/x86/Kconfig | 1 +
> xen/common/Kconfig | 14 +
> xen/common/Makefile | 2 +
> xen/common/sysctl.c | 8 +
> xen/common/xsplice.c | 386
> +++
> xen/include/public/sysctl.h | 156 +++
> xen/include/xen/xsplice.h| 7 +
> xen/xsm/flask/hooks.c| 6 +
> xen/xsm/flask/policy/access_vectors | 2 +
> 11 files changed, 584 insertions(+)
> create mode 100644 xen/common/xsplice.c
> create mode 100644 xen/include/xen/xsplice.h
>
> diff --git a/tools/flask/policy/policy/modules/xen/xen.te
> b/tools/flask/policy/policy/modules/xen/xen.te
> index d35ae22..542c3e1 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.te
> +++ b/tools/flask/policy/policy/modules/xen/xen.te
> @@ -72,6 +72,7 @@ allow dom0_t xen_t:xen2 {
> allow dom0_t xen_t:xen2 {
> pmu_ctrl
> get_symbol
> +xsplice_op
> };
> allow dom0_t xen_t:mmu memorymap;
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 60e923c..3780949 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -23,6 +23,7 @@ config ARM
> select HAS_PASSTHROUGH
> select HAS_PDX
> select HAS_VIDEO
> + select HAS_XSPLICE
>
> config ARCH_DEFCONFIG
> string
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 4781b34..2b6c832 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -18,6 +18,7 @@ config X86
> select HAS_PCI
> select HAS_PDX
> select HAS_VGA
> + select HAS_XSPLICE
>
> config ARCH_DEFCONFIG
> string
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index eadfc3b..aaf4053 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -51,6 +51,9 @@ config HAS_GDBSX
> config HAS_IOPORTS
> bool
>
> +config HAS_XSPLICE
> + bool
> +
> # Enable/Disable kexec support
> config KEXEC
> bool "kexec support"
> @@ -97,4 +100,15 @@ config XSM
>
> If unsure, say N.
>
> +# Enable/Disable xsplice support
> +config XSPLICE
> + bool "xsplice support"
> + default y
> + depends on HAS_XSPLICE
> + ---help---
> + Allows a running Xen hypervisor to be patched without rebooting.
> + This is primarily used to patch an hypervisor with XSA fixes.
> +
> + If unsure, say Y.
> +
> endmenu
I'm indifferent on the HAS_XSPLICE, you can drop that if you want to
simply stuff.
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 9f8b214..6fdeccf 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -71,3 +71,5 @@ subdir-$(coverage) += gcov
>
> subdir-y += libelf
> subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
> +
> +obj-$(CONFIG_XSPLICE) += xsplice.o
> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> index a3007b8..55e6cfa 100644
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
>
> long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
> {
> @@ -460,6 +461,13 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
> u_sysctl)
> ret = tmem_control(&op->u.tmem_op);
> break;
>
> +#ifdef CONFIG_XSPLICE
> +case XEN_SYSCTL_xsplice_op:
> +ret = xsplice_control(&op->u.xsplice);
> +copyback = 1;
> +break;
> +#endif
Should the case statement still exist and not just return -ENOSYS?
Otherwise we're needlessly going into arch_do_sysctl() just to get the
same result.
> +
> default:
> ret = arch_do_sysctl(op, u_sysctl);
> copyback = 0;
> diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> new file mode 100
[Xen-devel] [qemu-upstream-4.4-testing test] 80734: regressions - FAIL
flight 80734 qemu-upstream-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/80734/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 77834 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 77834 test-amd64-amd64-qemuu-nested-intel 9 debian-hvm-install fail REGR. vs. 77834 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail REGR. vs. 77834 test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-installfail REGR. vs. 77834 test-amd64-i386-freebsd10-i386 10 guest-start fail REGR. vs. 77834 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 77834 test-amd64-i386-qemuu-rhel6hvm-amd 9 redhat-install fail REGR. vs. 77834 test-amd64-amd64-xl-qemuu-winxpsp3 9 windows-install fail REGR. vs. 77834 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 77834 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 77834 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-installfail REGR. vs. 77834 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail like 77618 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail like 77618 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: qemuu11ac1da95c4e8b2c9c627e0cbcaa50c90c298a1b baseline version: qemuu2264b0c66075cc34c252a1386f019f8be6240890 Last test of basis77834 2016-01-11 13:28:00 Z 26 days Testing same since80734 2016-02-05 15:19:13 Z1 days1 attempts People who touched revisions under test: Gerd Hoffmann Jason Wang John Snow Laszlo Ersek P J P Paolo Bonzini Peter Maydell Prasad J Pandit Roger Pau Monne Roger Pau Monné Stefano Stabellini jobs: build-amd64-xend pass build-i386-xend 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 pass test-amd64-i386-xl pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-credit2 pass test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpupass test-amd64-amd64-pairpass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-amd64-pvgrubpass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2pass test-amd64-i386-xl-raw pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail test-amd64-amd64-libvirt-vhd pass test-amd64-amd64-xl-qemuu-winxpsp3 fail
Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy
On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote:
> int __init microcode_init(void)
> {
> [...]
> if (paravirt_enabled() || dis_ucode_ldr)
> return -EINVAL;
>
> This is also asking "are we the natively booted kernel?" This is
> plausibly useful for real. (Borislav, is this actually necessary?)
There was some breakage on 32-bit pvops with that.
> Seems to me there should be a function is_native_root_kernel() or
> similar. Obviously it could have false positives and code will have
> to deal with that. (This also could be entirely wrong. What code is
> responsible for CPU microcode updates on Xen? For all I know, dom0 is
> *supposed* to apply microcode updates, in which case that check really
> should be deleted.
So there are two aspects:
- the guest loading the microcode driver. Xen should behave like
qemu+kvm does: emulate the MSR accesses the microcode loader does.
- microcode application on Xen: we've had this before. The hypervisor
should do that (if it doesn't do so already).
So yes, that paravirt_enabled() thing should go away. Even more so if we
have CPUID leaf 0x4... reserved for hypervisors.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] deprecating pvgrub (grub-legacy)
Hi all, Given that pvgrub2 has been available for a while now and Ian did a good write up on the Xen blog of how to use it and a few downstream distros are starting to pick it up as the way to boot Xen images. Plus most downstreams switching exclusively to grub2 usage is it time to mark pvgrub (grub-legacy) as deprecated in all the docs and source? Maybe after a few release cycles it would be broken out of the tree into its own repo for anyone still interested in using it? Just a thought. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 80776: regressions - FAIL
flight 80776 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/80776/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 79947 build-amd64 5 xen-build fail REGR. vs. 79947 build-i386-xsm5 xen-build fail REGR. vs. 79947 build-amd64-xsm 5 xen-build fail REGR. vs. 79947 build-armhf 5 xen-build fail REGR. vs. 79947 build-armhf-xsm 5 xen-build fail REGR. vs. 79947 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1)
Re: [Xen-devel] [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0
On 2/5/16 10:07 PM, Luis R. Rodriguez wrote: > On Fri, Feb 05, 2016 at 10:52:01PM -0500, Konrad Rzeszutek Wilk wrote: >> On Fri, Feb 05, 2016 at 05:48:37PM -0800, Luis R. Rodriguez wrote: >>> On Fri, Nov 20, 2015 at 9:47 AM, Luis R. Rodriguez >>> wrote: From: "Luis R. Rodriguez" Here's a slew of build fixes as well as build warning fixes required when using the latest build tools, at least gcc 5 and binutils 2.25.0. >>> >>> One good reason for some folks to get discouraged to work with Xen: >> >> s/Xen/Any Open Source project/ >> >> Take a look in Documentation/SubmittingPatches, the " Don't get discouraged >> - or impatient" section. It mentions 'pinging'. > > I delays on pinging for new features, etc, things still being broken with > compiling the latest and greatest however is not. > >>> Patches for fixes on builds last ages to get merged >>> >>> In this case Mark Pryor reported an issue and >>> offered a fix on October 8, 2015 [0]. That did not go in as Jan noted >>> it was probably not the right fix. Last year in November I provided >>> what I think is a proper replacement set which I think addressed Jan's >>> concerns. >>> >>> ***Four*** months later and Xen still does not compile with the latest >>> and greatest. I have to go digging out in my git basement somewhere >>> some fixes I last used to build Xen to try to test some new >>> features... >> >> Odd it does compile for me - albeit I've had issues with the VNC >> part which also needs another patch. > > Is there an auto build test going on with different distros going ? > If not that might help. Trying to make that happen here: http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00984.html Currently its only on Ubuntu 14.04 but with a few different compilers. I've got follow on work that adds CentOS and will show others how they can easily add more. > >> But I hadn't had the chance to >> see whether the patch would break builds on much older version of >> distros. > > A static inline to define the new method in the old way of doing > things should suffice as well I think. > >>> What's up folks? How can this process be made smoother, did I do >>> something wrong, what can I do to help better? What can you do to help >>> ensure these types of things don't fall through the cracks. >> >> ping? The same thing you would do on LKML. > > 0 day build tests the kernel all the time, even if my patch gets > missed, after a few days other will immediately notice. These days > its extremely hard for me to build linux-next and have a build > issue. > > I recommend we push on the momentum to see if we can piggy back > on doing regular 0 day build tests with Xen too if possible. > >Luis Got links to where this is run? I'm assuming its using Autotest [1]? [1] https://autotest.github.io/ -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
On 2/5/16 10:03 PM, Luis R. Rodriguez wrote: > On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote: >> On Sat, Feb 06, 2016 at 02:44:54AM +0100, Luis R. Rodriguez wrote: >>> On Wed, Nov 25, 2015 at 03:44:30PM -0500, Konrad Rzeszutek Wilk wrote: On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote: > On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote: >> On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote: >>> From: "Luis R. Rodriguez" >>> >>> Using deprecate gnutls_*_set() triggers a failure to compile >>> with gnutls30-3.4.4, used on OpenSUSE factory: >>> >>> ../libqemu_common.a(vnc.o): In function `vnc_start_tls': >>> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined >>> reference to `gnutls_kx_set_priority' >>> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined >>> reference to `gnutls_certificate_type_set_priority' >>> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined >>> reference to `gnutls_protocol_set_priority' >>> >>> This compilation issue can be fixed by using the new routine >>> gnutls_priority_set_direct() which replaces the deprecated calls >>> which also simplifies the code considerably. >> >> >> Thanks for posting that! It certainly fixes that issue. > > Acked-by? Tested-by: Konrad Rzeszutek Wilk >>> >>> None of these are merged yet... >> >> And it looks like you didn't CC the maintainer. > > mcgrof@garbanzo ~/devel/xen (git::staging)$ ./scripts/get_maintainer.pl > ../xen-fixes/0002-proper-qemu-trad-gnutls.patch > Ian Campbell > Ian Jackson > Jan Beulich > Keir Fraser > Tim Deegan > xen-devel@lists.xen.org > > I missed Ian Jackson, Keir and Tim. > >> Also - how does this work if you have an older version of SuSE, >> say SLES10? > > Beats me. I just dealt with getting this to compile with what is current. > I kind of doubt what is in xen master or staging will end up in SLE10's > version of Xen too. If that had to happen people porting this to an old > library could just add a helper gnutls_priority_set_direct() wrapper to > do things the old way. > > Luis > I'd personally love to know what's the real minimum that needs to be supported by Xen master/staging. I tried [1] to put a line in the sand but that died. I'm also in the process on standing up some basic build CI [2] and as part of that I would build on new stuff and build on the oldest set that's supported. [1] http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03577.html [2] http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00984.html -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy
On Sat, Feb 6, 2016 at 12:59 AM, Luis R. Rodriguez wrote: > On Fri, Feb 05, 2016 at 11:11:34PM -0800, Andy Lutomirski wrote: >> On Feb 5, 2016 8:30 PM, "Luis R. Rodriguez" wrote: >> > >> > paravirt_enabled conveys the idea that if this is set or if >> > paravirt_enabled() returns true you are in a paravirtualized >> > environment. This is not true by any means, and left as-is >> > is just causing confusion and is prone to be misused and abused. >> > >> > This primitive is really only useful to determine if you have a >> > paravirtualization hypervisor that supports legacy paravirtualized >> > guests. At run time, this tells us if we've booted into a Linux guest >> > with support for legacy devices and features. >> > >> > To avoid further issues with semantics on this we loosely borrow >> > the definition of "legacy" from both the ACPI 5.2.9.3 "IA-PC Boot >> > Architecture Flags" section and the PC 2001 definition in the PC >> > Systems design guide [0]: >> > >> > paravirt_legacy() is true if this hypervisor supports legacy >> > x86 paravirtualized guests. >> >> This needs to be far more concrete. I'm reasonably well versed in x86 >> details relevant to kernels ans I have *no clue* what your semantics >> mean. > > Interesting. I'm glad you're chiming in :) > >> > +/** >> > + * struct pv_info - paravirt hypervisor information >> > + * >> > + * @supports_x86_legacy: true if this hypervisor supports legacy x86 >> > + * paravirtualized guests. The definition of legacy here adheres >> > + * *loosely* to both the notion of legacy in the ACPI 5.2.9.3 "IA-PC >> > Boot >> > + * Architecture Flags" section and the PC 2001 "legacy free" concept >> > [1] >> > + * referred to in the PC System Design Guide [2] [3] on Chapter 3, >> > Page 50 >> > + * [4]. Legacy x86 guests systems are guest systems which are not >> > "legacy >> > + * free" as per the PC 2001 definition, and in the ACPI sense could >> > have >> > + * any of the legacy ACPI IA-PC Boot architecture flags set. These >> > are x86 >> > + * systems with any type of legacy peripherals or requirements. >> > + * >> > + * Examples of some popular legacy peripherals: >> > + * >> > + * a) Floppy drive >> > + * b) Legacy ports [1] such as such as parallel ports, PS/2 >> > connectors, >> > + * serial ports / RS-232, game ports Parallel ATA, and IEEE 1394 >> > + * c) ISA bus >> > + * >> > + * Examples of features required to support such type of legacy guests >> > + * are the need for APM and a PNP BIOS. >> >> Seriously? >> >> I think you just defined every standard native x86 system >> as well as QEMU/KVM as "legacy". > > I was a afraid it was too broad, but its why I used "loosely". > >> Can we just enumerate this crap? I propose: >> >> Xen PV and lguest are paravirt_legacy. Nothing else is >> paravirt_legacy. > > Fine by me! > >> The addition of new paravirt_legacy support is >> strongly discouraged. > > Fine by me, but Boris is re-using that for HVMLite on his recently > proposed patches. Do we want that ? I'll also note that the goal > is to ensure its hardware_subarch will be 0 (PC), meanwhile old > PV will be Xen (although this hasn't been set yet). This mess is > part of the reason why I do think stronger semantics and clearer > definitions will help here. Without strong semantics I can't help > address the dead code concerns I've been rambling over. > > HVMLite is just a rebranding for PVH done right, and then it seems PVH will be > dropped and we'll have HVMLite rebranded back to PVH I guess it seems. PVH/HVMlite had better not be "paravirt" in this sense, I hope. > > The enumeration of legacy crap by ACPI boot flags seems to provide enough > details to suit our needs if we really wanted to zero down on the specifics of > what paravirt_legacy() means, there are these flags: > > /* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced > in this FADT revision */ > #define ACPI_FADT_LEGACY_DEVICES(1) /* 00: [V2] System has LPC or > ISA bus devices */ > #define ACPI_FADT_8042 (1<<1) /* 01: [V3] System has an > 8042 controller on port 60/64 */ > #define ACPI_FADT_NO_VGA(1<<2) /* 02: [V4] It is not safe to > probe for VGA hardware */ > #define ACPI_FADT_NO_MSI(1<<3) /* 03: [V4] Message Signaled > Interrupts (MSI) must not be enabled */ > #define ACPI_FADT_NO_ASPM (1<<4) /* 04: [V4] PCIe ASPM control > must not be enabled */ > #define ACPI_FADT_NO_CMOS_RTC (1<<5) /* 05: [V5] No CMOS real-time > clock present */ > > I checked and I didn't see qemu using any of the ACPI boot flags, > but I suspected qemu instances must use a series of legacy crap. > Likewise for KVM. So shouldn't Linux find out things from the FADT by reading the FADT rather than squishing them into a confusing single function? Anyway, this is all ridiculous. I propose that rath
[Xen-devel] [qemu-upstream-unstable baseline-only test] 38728: tolerable FAIL
This run is configured for baseline tests only. flight 38728 qemu-upstream-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38728/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 38704 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 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-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-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-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: qemuue9d825298c0d7e14caf6c4d36d4d3894d138f858 baseline version: qemuu2ce1d30ef2858dfed72a281872579e5a26b090dd Last test of basis38704 2016-01-26 17:24:46 Z 11 days Testing same since38728 2016-02-06 13:19:13 Z0 days1 attempts People who touched revisions under test: Jason Wang Laszlo Ersek Stefano Stabellini 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 pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm
[Xen-devel] [PULL v2 44/45] fix MSI injection on Xen
From: Stefano Stabellini
On Xen MSIs can be remapped into pirqs, which are a type of event
channels. It's mostly for the benefit of PCI passthrough devices, to
avoid the overhead of interacting with the emulated lapic.
However remapping interrupts and MSIs is also supported for emulated
devices, such as the e1000 and virtio-net.
When an interrupt or an MSI is remapped into a pirq, masking and
unmasking is done by masking and unmasking the event channel. The
masking bit on the PCI config space or MSI-X table should be ignored,
but it isn't at the moment.
As a consequence emulated devices which use MSI or MSI-X, such as
virtio-net, don't work properly (the guest doesn't receive any
notifications). The mechanism was working properly when xen_apic was
introduced, but I haven't narrowed down which commit in particular is
causing the regression.
Fix the issue by ignoring the masking bit for MSI and MSI-X which have
been remapped into pirqs.
Signed-off-by: Stefano Stabellini
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/hw/xen/xen.h | 1 +
hw/pci/msi.c | 9 -
hw/pci/msix.c| 12 ++--
hw/xen/xen_pt_msi.c | 4 +---
xen-hvm-stub.c | 5 +
xen-hvm.c| 9 +
6 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 1b81b4b..c577354 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -33,6 +33,7 @@ int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
void xen_piix3_set_irq(void *opaque, int irq_num, int level);
void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
void xen_hvm_inject_msi(uint64_t addr, uint32_t data);
+int xen_is_pirq_msi(uint32_t msi_data);
qemu_irq *xen_interrupt_controller_init(void);
diff --git a/hw/pci/msi.c b/hw/pci/msi.c
index 8efa23d..85f21b8 100644
--- a/hw/pci/msi.c
+++ b/hw/pci/msi.c
@@ -20,6 +20,7 @@
#include "qemu/osdep.h"
#include "hw/pci/msi.h"
+#include "hw/xen/xen.h"
#include "qemu/range.h"
/* PCI_MSI_ADDRESS_LO */
@@ -254,13 +255,19 @@ void msi_reset(PCIDevice *dev)
static bool msi_is_masked(const PCIDevice *dev, unsigned int vector)
{
uint16_t flags = pci_get_word(dev->config + msi_flags_off(dev));
-uint32_t mask;
+uint32_t mask, data;
+bool msi64bit = flags & PCI_MSI_FLAGS_64BIT;
assert(vector < PCI_MSI_VECTORS_MAX);
if (!(flags & PCI_MSI_FLAGS_MASKBIT)) {
return false;
}
+data = pci_get_word(dev->config + msi_data_off(dev, msi64bit));
+if (xen_is_pirq_msi(data)) {
+return false;
+}
+
mask = pci_get_long(dev->config +
msi_mask_off(dev, flags & PCI_MSI_FLAGS_64BIT));
return mask & (1U << vector);
diff --git a/hw/pci/msix.c b/hw/pci/msix.c
index 4fea7ed..eb4ef11 100644
--- a/hw/pci/msix.c
+++ b/hw/pci/msix.c
@@ -19,6 +19,7 @@
#include "hw/pci/msi.h"
#include "hw/pci/msix.h"
#include "hw/pci/pci.h"
+#include "hw/xen/xen.h"
#include "qemu/range.h"
#define MSIX_CAP_LENGTH 12
@@ -78,8 +79,15 @@ static void msix_clr_pending(PCIDevice *dev, int vector)
static bool msix_vector_masked(PCIDevice *dev, unsigned int vector, bool fmask)
{
-unsigned offset = vector * PCI_MSIX_ENTRY_SIZE +
PCI_MSIX_ENTRY_VECTOR_CTRL;
-return fmask || dev->msix_table[offset] & PCI_MSIX_ENTRY_CTRL_MASKBIT;
+unsigned offset = vector * PCI_MSIX_ENTRY_SIZE;
+uint32_t *data = (uint32_t *)&dev->msix_table[offset +
PCI_MSIX_ENTRY_DATA];
+/* MSIs on Xen can be remapped into pirqs. In those cases, masking
+ * and unmasking go through the PV evtchn path. */
+if (xen_is_pirq_msi(*data)) {
+return false;
+}
+return fmask || dev->msix_table[offset + PCI_MSIX_ENTRY_VECTOR_CTRL] &
+PCI_MSIX_ENTRY_CTRL_MASKBIT;
}
bool msix_is_masked(PCIDevice *dev, unsigned int vector)
diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 5624685..9a16f2b 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -115,9 +115,7 @@ static int msi_msix_setup(XenPCIPassthroughState *s,
assert((!is_msix && msix_entry == 0) || is_msix);
-if (gvec == 0) {
-/* if gvec is 0, the guest is asking for a particular pirq that
- * is passed as dest_id */
+if (xen_is_pirq_msi(data)) {
*ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
if (!*ppirq) {
/* this probably identifies an misconfiguration of the guest,
diff --git a/xen-hvm-stub.c b/xen-hvm-stub.c
index a6cb5d3..c500325 100644
--- a/xen-hvm-stub.c
+++ b/xen-hvm-stub.c
@@ -31,6 +31,11 @@ void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
{
}
+int xen_is_pirq_msi(uint32_t msi_data)
+{
+return 0;
+}
+
void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr,
Error **errp)
{
diff --git a/xen-hvm.c b/xen-hvm.c
index 1c9fb12..6861c51 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -13,6 +13,7 @@
#inc
Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen
On 02/05/2016 08:43 PM, Haozhong Zhang wrote:
> On 02/05/16 09:40, Ross Philipson wrote:
>> On 02/03/2016 09:09 AM, Andrew Cooper wrote:
> [...]
>>> I agree.
>>>
>>> There has to be a single entity responsible for collating the eventual
>>> ACPI handed to the guest, and this is definitely HVMLoader.
>>>
>>> However, it is correct that Qemu create the ACPI tables for the devices
>>> it emulates for the guest.
>>>
>>> We need to agree on a mechanism whereby each entity can provide their
>>> own subset of the ACPI tables to HVMLoader, and have HVMLoader present
>>> the final set properly to the VM.
>>>
>>> There is an existing usecase of passing the Host SLIC table to a VM, for
>>> OEM Versions of Windows. I believe this is achieved with
>>> HVM_XS_ACPI_PT_{ADDRESS,LENGTH}, but that mechanism is a little
>>> inflexible and could probably do with being made a little more generic.
>>
>> A while back I added a generic mechanism to load extra ACPI tables into a
>> guest, configurable at runtime. It looks like the functionality is still
>> present. That might be an option.
>>
>> Also, following the thread, it wasn't clear if some of the tables like the
>> SSDT for the NVDIMM device and it's _FIT/_DSM methods were something that
>> could be statically created at build time. If it is something that needs to
>> be generated at runtime (e.g. platform specific), I have a library that can
>> generate any AML on the fly and create SSDTs.
>>
>> Anyway just FYI in case this is helpful.
>>
>
> Hi Ross,
>
> Thanks for the information!
>
> SSDT for NVDIMM devices can not be created statically, because the
> number of some items in it can not be determined at build time. For
> example, the number of NVDIMM ACPI namespace devices (_DSM is under it)
> defined in SSDT is determined by the number of vNVDIMM devices in domain
> configuration. FYI, a sample SSDT for NVDIMM looks like
>
> Scope (\_SB){
> Device (NVDR) // NVDIMM Root device
> {
> Name (_HID, “ACPI0012”)
> Method (_STA) {...}
> Method (_FIT) {...}
> Method (_DSM, ...) {
> ...
> }
> }
>
> Device (NVD0) // 1st NVDIMM Device
> {
> Name(_ADR, h0)
> Method (_DSM, ...) {
> ...
> }
> }
>
> Device (NVD1) // 2nd NVDIMM Device
> {
> Name(_ADR, h1)
> Method (_DSM, ...) {
> ...
> }
> }
>
> ...
> }
Makes sense.
>
> I had ported QEMU's AML builder code as well as NVDIMM ACPI building
> code to hvmloader and it did work, but then there was too much
> duplicated code for vNVDIMM between QEMU and hvmloader for vNVDIMM.
> Therefore, I prefer to let QEMU that emulates vNVDIMM devices
> to build those tables, as in Andrew and Jan's replies.
Yea it looks like QEUM's AML generating code is quite complete nowadays.
Back when I wrote my library there wasn't really much out there. Anyway
this is where it is if there is something that I might generate that is
missing:
https://github.com/OpenXT/xctools/tree/master/libxenacpi
>
> Thanks,
> Haozhong
>
--
Ross Philipson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.3-testing test] 80730: regressions - FAIL
flight 80730 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/80730/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail REGR. vs. 77983 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 77983 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 77983 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: qemuu10c1b763c26feb645627a1639e722515f3e1e876 baseline version: qemuu6e184363e64a0610c35ca231bfc73cea56eb02f3 Last test of basis77983 2016-01-13 12:21:53 Z 24 days Testing same since80730 2016-02-05 15:13:13 Z0 days1 attempts People who touched revisions under test: Gerd Hoffmann Jason Wang John Snow Laszlo Ersek P J P Paolo Bonzini Peter Maydell Prasad J Pandit Roger Pau Monne Roger Pau Monné Stefano Stabellini jobs: 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 pass test-amd64-i386-xl pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpupass test-amd64-amd64-pairpass test-amd64-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-amd64-pvgrubpass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2pass test-amd64-i386-xl-raw pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail test-amd64-amd64-libvirt-vhd pass test-amd64-amd64-xl-qemuu-winxpsp3 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 Not pushing. commit 10c1b763c26feb645627a1639e722515f3e1e876 Author: Prasad J Pandit Date: Fri Nov 20 11:50:31 2015 +0530 net: pcnet: add check to validate receive data size(CVE-2015-7504) In loopback mode, pcnet_receive routine appends CRC code to the receive buffer. If the data size given is same as the buffer size, the appended CRC code overwrites 4 bytes after s->buffer. Added a check to avoid that. Reported by: Qinghao Tang Cc: qemu-sta...@nongnu.org Reviewe
[Xen-devel] [qemu-upstream-unstable test] 80694: tolerable FAIL - PUSHED
flight 80694 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/80694/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 78922 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail 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-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 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-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 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 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass version targeted for testing: qemuue9d825298c0d7e14caf6c4d36d4d3894d138f858 baseline version: qemuu2ce1d30ef2858dfed72a281872579e5a26b090dd Last test of basis78922 2016-01-24 13:49:56 Z 12 days Testing same since80694 2016-02-05 11:52:32 Z1 days1 attempts People who touched revisions under test: Jason Wang Laszlo Ersek Stefano Stabellini 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 pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-x
Re: [Xen-devel] [PATCH v3 1/3] xen-access: minor fixes
On 02/05/2016 11:22 PM, Tamas K Lengyel wrote: > Only copy the VCPU_PAUSED flag to the response. Copy the entire mem_access > struct which is useful and easily forgotten when also testing the emulate > response flags. Turn off singlestepping on the vCPUs once we are done > processing all events, as we might have turned on singlestep there and leave > the VM in an undesirable state. > > Signed-off-by: Tamas K Lengyel > Cc: Razvan Cojocaru > Cc: Ian Jackson > Cc: Stefano Stabellini > Cc: Ian Campbell > Cc: Wei Liu > --- > tools/tests/xen-access/xen-access.c | 46 > - > 1 file changed, 25 insertions(+), 21 deletions(-) Acked-by: Razvan Cojocaru ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] altp2m: Implement p2m_get_mem_access for altp2m views
On 02/05/2016 11:22 PM, Tamas K Lengyel wrote: > Extend the existing get_mem_access memop to allow querying permissions in > altp2m views as well. > > Signed-off-by: Tamas K Lengyel > Cc: Ian Jackson > Cc: Stefano Stabellini > Cc: Ian Campbell > Cc: Wei Liu > Cc: Razvan Cojocaru > Cc: Stefano Stabellini > Cc: George Dunlap > Cc: Keir Fraser > Cc: Jan Beulich > Cc: Andrew Cooper > --- > v3: Define a union over a memop field for the separate use during get and set > v2: Use unsigned int instead of unsigned long > Use a single p2m pointer > --- > tools/libxc/include/xenctrl.h | 3 ++- > tools/libxc/xc_mem_access.c | 10 ++ > tools/tests/xen-access/xen-access.c | 5 - > xen/arch/arm/p2m.c | 4 ++-- > xen/arch/x86/mm/p2m.c | 17 +++-- > xen/common/mem_access.c | 10 +- > xen/include/public/memory.h | 19 ++- > xen/include/xen/p2m-common.h| 3 ++- > 8 files changed, 50 insertions(+), 21 deletions(-) Acked-by: Razvan Cojocaru Took a bit longer on this one because I wanted to do a test run with our application after applying these last two patches and make sure things work. They seem to work. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao wrote: > From: Shannon Zhao > > ACPI 6.0 introduces a new table STAO to list the devices which are used > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical > UART is used by Xen. So here it hides UART from Dom0. > > Signed-off-by: Shannon Zhao > Reviewed-by: Stefano Stabellini Well, this doesn't look right to me. We need to find a nicer way to achieve what you want. Thanks, Rafael ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 80683: regressions - FAIL
flight 80683 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/80683/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 14 guest-saverestore.2 fail REGR. vs. 79422 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail REGR. vs. 79422 build-amd64-rumpuserxen 6 xen-buildfail like 79422 build-i386-rumpuserxen6 xen-buildfail like 79422 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 79422 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 79422 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 79422 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt 12 migrate-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-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 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-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 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 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail 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-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-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 version targeted for testing: xen 1ac81bb7166b79b6555290547d4e305c74d0 baseline version: xen 9937763265d9597e5f2439249b16d995842cdf0f Last test of basis79422 2016-01-29 14:09:49 Z7 days Failing since 79502 2016-01-30 20:16:40 Z6 days7 attempts Testing same since80683 2016-02-05 11:00:26 Z0 days1 attempts People who touched revisions under test: Alan.Robinson Andrew Cooper Boris Ostrovsky Corneliu ZUZU David Vrabel Doug Goldstein George Dunlap Graeme Gregory Hanjun Guo Huaitong Han Ian Campbell Ian Jackson Jan Beulich Jennifer Herbert Juergen Gross Kevin Tian Konrad Rzeszutek Wilk Olaf Hering Parth Dixit Rafael J. Wysocki Razvan Cojocaru Roger Pau Monne Roger Pau Monné Shannon Zhao Shuai Ruan Stefano Stabellini Tamas K Lengyel Tim Deegan Vitaly Kuznetsov Wei Liu Yu Zhang Zoltan Kiss jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm
Re: [Xen-devel] [PATCH v7 5/5] PCI: ACPI: Add a generic ACPI based host controller
Hi Rafael, On Sat, Feb 6, 2016 at 4:56 AM, Rafael J. Wysocki wrote: > On Friday, February 05, 2016 09:47:40 AM Lorenzo Pieralisi wrote: >> On Fri, Feb 05, 2016 at 02:05:37PM +0530, Jayachandran Chandrashekaran Nair >> wrote: >> >> [...] >> >> > pci_host_acpi.c is a generic implementation of these using a sysdata >> > pointing to acpi_pci_root_info, and using a pointer to the pci_mmcfg_region >> > to access ECAM area, Maybe I can rename this file to >> > pci_acpi_host_generic.c to reflect this better. >> >> Maybe you should stop sending this series and work with Tomasz to >> get this done, you are confusing everyone and I am really really >> annoyed about this. >> >> Do you realize there is no point in having two patch series doing >> the same thing and wasting everyone's review time ? >> >> Do you realize he started this work long before you and went through >> several rounds of review already (I told you before but in case you >> forgot) ? >> >> Tomasz posted a version yesterday, integrating comments following months >> of review and testing and I think it is ready to get upstream: >> >> https://lkml.org/lkml/2016/2/4/646 >> >> Did you even consider reviewing his code or helping him instead of >> churning out more patches doing the *SAME* thing ? >> >> Do you want all of us to go through your code and re-fix what has >> already been fixed in Tomasz's series with the end result of missing >> yet another merge window ? >> >> This is really annoying, stop it please, really. > > OK, so to be crystal clear here. > > I'm going to ignore the series the $subject patch belongs to going forward. It looks like you can already reviewed Tomasz's patchset and as Lorenzo says thinks that it can be merged. When I first posted the patchset the state of arm64 ACPI/PCI was not that clear - and I thought an alternative will help. Ideally I would expect maintainers to look at technical merit, but in this case any working solution merged will be great news. Thanks, JC. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-stretch test] 38727: tolerable FAIL
flight 38727 distros-debian-stretch real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38727/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-stretch-netboot-pvgrub 10 guest-start fail like 38716 Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-stretch-netboot-pygrub 12 saverestore-support-check fail never pass test-armhf-armhf-armhf-stretch-netboot-pygrub 11 migrate-support-check fail never pass baseline version: flight 38716 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-stretch-netboot-pvgrubfail test-amd64-i386-i386-stretch-netboot-pvgrub pass test-amd64-i386-amd64-stretch-netboot-pygrub pass test-armhf-armhf-armhf-stretch-netboot-pygrubpass test-amd64-amd64-i386-stretch-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 http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy
On Fri, Feb 05, 2016 at 11:11:34PM -0800, Andy Lutomirski wrote: > On Feb 5, 2016 8:30 PM, "Luis R. Rodriguez" wrote: > > > > paravirt_enabled conveys the idea that if this is set or if > > paravirt_enabled() returns true you are in a paravirtualized > > environment. This is not true by any means, and left as-is > > is just causing confusion and is prone to be misused and abused. > > > > This primitive is really only useful to determine if you have a > > paravirtualization hypervisor that supports legacy paravirtualized > > guests. At run time, this tells us if we've booted into a Linux guest > > with support for legacy devices and features. > > > > To avoid further issues with semantics on this we loosely borrow > > the definition of "legacy" from both the ACPI 5.2.9.3 "IA-PC Boot > > Architecture Flags" section and the PC 2001 definition in the PC > > Systems design guide [0]: > > > > paravirt_legacy() is true if this hypervisor supports legacy > > x86 paravirtualized guests. > > This needs to be far more concrete. I'm reasonably well versed in x86 > details relevant to kernels ans I have *no clue* what your semantics > mean. Interesting. I'm glad you're chiming in :) > > +/** > > + * struct pv_info - paravirt hypervisor information > > + * > > + * @supports_x86_legacy: true if this hypervisor supports legacy x86 > > + * paravirtualized guests. The definition of legacy here adheres > > + * *loosely* to both the notion of legacy in the ACPI 5.2.9.3 "IA-PC > > Boot > > + * Architecture Flags" section and the PC 2001 "legacy free" concept > > [1] > > + * referred to in the PC System Design Guide [2] [3] on Chapter 3, > > Page 50 > > + * [4]. Legacy x86 guests systems are guest systems which are not > > "legacy > > + * free" as per the PC 2001 definition, and in the ACPI sense could > > have > > + * any of the legacy ACPI IA-PC Boot architecture flags set. These are > > x86 > > + * systems with any type of legacy peripherals or requirements. > > + * > > + * Examples of some popular legacy peripherals: > > + * > > + * a) Floppy drive > > + * b) Legacy ports [1] such as such as parallel ports, PS/2 > > connectors, > > + * serial ports / RS-232, game ports Parallel ATA, and IEEE 1394 > > + * c) ISA bus > > + * > > + * Examples of features required to support such type of legacy guests > > + * are the need for APM and a PNP BIOS. > > Seriously? > > I think you just defined every standard native x86 system > as well as QEMU/KVM as "legacy". I was a afraid it was too broad, but its why I used "loosely". > Can we just enumerate this crap? I propose: > > Xen PV and lguest are paravirt_legacy. Nothing else is > paravirt_legacy. Fine by me! > The addition of new paravirt_legacy support is > strongly discouraged. Fine by me, but Boris is re-using that for HVMLite on his recently proposed patches. Do we want that ? I'll also note that the goal is to ensure its hardware_subarch will be 0 (PC), meanwhile old PV will be Xen (although this hasn't been set yet). This mess is part of the reason why I do think stronger semantics and clearer definitions will help here. Without strong semantics I can't help address the dead code concerns I've been rambling over. HVMLite is just a rebranding for PVH done right, and then it seems PVH will be dropped and we'll have HVMLite rebranded back to PVH I guess it seems. The enumeration of legacy crap by ACPI boot flags seems to provide enough details to suit our needs if we really wanted to zero down on the specifics of what paravirt_legacy() means, there are these flags: /* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced in this FADT revision */ #define ACPI_FADT_LEGACY_DEVICES(1) /* 00: [V2] System has LPC or ISA bus devices */ #define ACPI_FADT_8042 (1<<1) /* 01: [V3] System has an 8042 controller on port 60/64 */ #define ACPI_FADT_NO_VGA(1<<2) /* 02: [V4] It is not safe to probe for VGA hardware */ #define ACPI_FADT_NO_MSI(1<<3) /* 03: [V4] Message Signaled Interrupts (MSI) must not be enabled */ #define ACPI_FADT_NO_ASPM (1<<4) /* 04: [V4] PCIe ASPM control must not be enabled */ #define ACPI_FADT_NO_CMOS_RTC (1<<5) /* 05: [V5] No CMOS real-time clock present */ I checked and I didn't see qemu using any of the ACPI boot flags, but I suspected qemu instances must use a series of legacy crap. Likewise for KVM. coreboot defines legacy free when you don't have any of the above flags set: #define ACPI_FADT_LEGACY_FREE 0x00/* No legacy devices (including 8042) * Would it be sufficient to just stick to "pv legacy" equivalent of requiring just ACPI_FADT_LEGACY_DEVICES and ACPI_FADT_8042 ? I should point out It turns out ACPI_FADT_NO_CMOS_RTC matches lguest's and it seems that's the only reason we have that RTC PV flag and the features pv field..
