* [xen-unstable test] 77945: regressions - FAIL
@ 2016-01-13 19:30 ` osstest service owner
2016-01-14 9:30 ` Jan Beulich
0 siblings, 1 reply; 37+ messages in thread
From: osstest service owner @ 2016-01-13 19:30 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 77945 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77945/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
test-amd64-amd64-xl-xsm 5 xen-install fail REGR. vs. 77892
test-amd64-i386-xl-xsm 5 xen-install fail REGR. vs. 77892
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 77892
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt-xsm 5 xen-install fail REGR. vs. 77892
test-amd64-amd64-libvirt-xsm 5 xen-install fail REGR. vs. 77892
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 77892
test-amd64-i386-rumpuserxen-i386 10 guest-start fail like 77892
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 77892
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 77892
test-armhf-armhf-xl-rtds 9 debian-install fail like 77892
test-amd64-amd64-libvirt-vhd 9 debian-di-install fail like 77892
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-saverestore fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 guest-saverestore fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-saverestore fail never pass
test-armhf-armhf-xl-vhd 9 debian-di-install fail never pass
version targeted for testing:
xen 20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
baseline version:
xen f7347a282420a5edc74afb31e7c42c2765f24de5
Last test of basis 77892 2016-01-12 11:30:40 Z 1 days
Testing same since 77945 2016-01-13 04:01:14 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Brendan Gregg <bgregg@netflix.com>
Daniel De Graaf <dgdegra@tycho.nsa.gov>
Doug Goldstein <cardoe@cardoe.com>
Haozhong Zhang <haozhong.zhang@intel.com>
Juergen Gross <jgross@suse.com>
Kevin Tian <kevin.tian@intel.com>
Wei Liu <wei.liu2@citrix.com> for tools bits
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-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumpuserxen pass
build-i386-rumpuserxen pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm fail
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm fail
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm fail
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail
test-amd64-amd64-libvirt-xsm fail
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm fail
test-amd64-amd64-xl-xsm fail
test-armhf-armhf-xl-xsm fail
test-amd64-i386-xl-xsm fail
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumpuserxen-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumpuserxen-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 fail
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd fail
test-armhf-armhf-xl-vhd fail
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-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 20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
Author: Doug Goldstein <cardoe@cardoe.com>
Date: Tue Jan 12 11:39:47 2016 +0100
convert XSM_ENABLE to Kconfig
Converts the existing XSM_ENABLE flag from Config.mk to CONFIG_XSM
within Kconfig. This also re-adds the dependency of CONFIG_FLASK on
CONFIG_XSM.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
commit 529298fdf9097f8e637f754c9b29bd58a8a714e9
Author: Doug Goldstein <cardoe@cardoe.com>
Date: Tue Jan 12 11:36:33 2016 +0100
convert FLASK_ENABLE to Kconfig
Converts the Config.mk option of FLASK_ENABLE into a Kconfig option for
the hypervisor called CONFIG_FLASK. This commit knowingly breaks the
dependent relationship on XSM_ENABLE which is addressed when XSM_ENABLE
is converted to Kconfig.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
commit 361b4f9f0f0d4adc19df428e224a7b8fa62cd392
Author: Doug Goldstein <cardoe@cardoe.com>
Date: Tue Jan 12 11:33:55 2016 +0100
build: save generated xen .config
Since we now support changing Xen options with Kconfig, we should save
the configuration that was used to build up Xen. This will save it in
/usr/lib/debug alongside xen-syms and call it xen-$(FULLVERSION).config
Suggested-by: Ian Campbell <ian.campbell@citrix.com>
Requested-by: Jan Beulich <jbeulich@suse.com> # the directory
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
commit e3cce1799df2f957dfa00f84a5315cbf896490fe
Author: Brendan Gregg <bgregg@netflix.com>
Date: Tue Jan 12 11:33:16 2016 +0100
x86/VPMU: implement ipc and arch filter flags
This introduces a way to have a restricted VPMU, by specifying one of two
predefined groups of PMCs to make available. For secure environments, this
allows the VPMU to be used without needing to enable all PMCs.
Signed-off-by: Brendan Gregg <bgregg@netflix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
commit 5513bd0b4675e2fa2ff4e9a06885f16727901805
Author: Juergen Gross <jgross@suse.com>
Date: Tue Jan 12 11:29:55 2016 +0100
add xenstore domain flag to hypervisor
In order to be able to have full support of a xenstore domain in Xen
add a "Xenstore-domain" flag to the hypervisor. This flag must be
specified at domain creation time and is returned by
XEN_DOMCTL_getdomaininfo.
It will allow the domain to retrieve domain information by issuing the
XEN_DOMCTL_getdomaininfo itself in order to be able to check for
domains having been destroyed. At the same time this flag will inhibit
the domain to be migrated, as this wouldn't be a very wise thing to do.
In case of a later support of a rebootable Dom0 this flag will allow to
recognize a xenstore domain already being present to connect to.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Andrew Cooper <andrew.cooper3@citirx.com>
commit cfacce340608be5f94ce0c8f424487b63c3d5399
Author: Haozhong Zhang <haozhong.zhang@intel.com>
Date: Tue Jan 12 11:29:25 2016 +0100
x86/hvm: add support for pcommit instruction
Pass PCOMMIT CPU feature into HVM domain. Currently, we do not intercept
pcommit instruction for L1 guest, and allow L1 to intercept pcommit
instruction for L2 guest.
The specification of pcommit instruction can be found in
https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Acked-by: Wei Liu <wei.liu2@citrix.com> for tools bits
commit 3cb82a561382466208db50d41d6401e2cc4819dd
Author: Haozhong Zhang <haozhong.zhang@intel.com>
Date: Tue Jan 12 11:28:58 2016 +0100
x86/hvm: allow guest to use clflushopt and clwb
Pass CPU features CLFLUSHOPT and CLWB into HVM domain so that those two
instructions can be used by guest.
The specification of above two instructions can be found in
https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Acked-by: Wei Liu <wei.liu2@citrix.com> for tools bits
commit 165f36d5fa60ade72f691fbb81aad0a2cadaca37
Author: Doug Goldstein <cardoe@cardoe.com>
Date: Tue Jan 12 11:27:49 2016 +0100
x86: convert bigmem to Kconfig
Convert the bigmem build option to Kconfig.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
(qemu changes not included)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL
2016-01-13 19:30 ` [xen-unstable test] 77945: regressions - FAIL osstest service owner
@ 2016-01-14 9:30 ` Jan Beulich
2016-01-14 11:42 ` Ian Campbell
0 siblings, 1 reply; 37+ messages in thread
From: Jan Beulich @ 2016-01-14 9:30 UTC (permalink / raw)
To: Doug Goldstein, osstest-admin; +Cc: xen-devel
>>> On 13.01.16 at 20:30, <osstest-admin@xenproject.org> wrote:
> flight 77945 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/77945/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
> test-amd64-amd64-xl-xsm 5 xen-install fail REGR. vs. 77892
> test-amd64-i386-xl-xsm 5 xen-install fail REGR. vs. 77892
> test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
> test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
> test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
> test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
> test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 77892
All perhaps because of multiple instances of
2016-01-13 16:20:48 Z (skipping entry at 303..316; XSM policy file not present)
2016-01-13 16:20:48 Z (skipping entry at 317..330; XSM policy file not present)
? Are we having another ordering problem with the XSM/FLASK
Kconfig-conversion patches?
Jan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL
2016-01-14 9:30 ` Jan Beulich
@ 2016-01-14 11:42 ` Ian Campbell
2016-01-14 12:50 ` Jan Beulich
0 siblings, 1 reply; 37+ messages in thread
From: Ian Campbell @ 2016-01-14 11:42 UTC (permalink / raw)
To: Jan Beulich, Doug Goldstein, osstest-admin; +Cc: xen-devel
On Thu, 2016-01-14 at 02:30 -0700, Jan Beulich wrote:
> > > > On 13.01.16 at 20:30, <osstest-admin@xenproject.org> wrote:
> > flight 77945 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/77945/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 5 xen-install
> > fail REGR. vs. 77892
> > test-amd64-amd64-xl-xsm 5 xen-install fail REGR.
> > vs. 77892
> > test-amd64-i386-xl-xsm 5 xen-install fail REGR.
> > vs. 77892
> > test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 5 xen-install
> > fail REGR. vs. 77892
> > test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 5 xen-install fail REGR.
> > vs. 77892
> > test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR.
> > vs. 77892
> > test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 5 xen-install fail REGR.
> > vs. 77892
> > test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR.
> > vs. 77892
>
> All perhaps because of multiple instances of
>
> 2016-01-13 16:20:48 Z (skipping entry at 303..316; XSM policy file not
> present)
> 2016-01-13 16:20:48 Z (skipping entry at 317..330; XSM policy file not
> present)
>
> ? Are we having another ordering problem with the XSM/FLASK
> Kconfig-conversion patches?
The logs (at the bottom of the summary linked about) claim harness
revision fff2921dd931d92de43cde2f977b2c6ac3605966 which includes the
osstest side.
Looking at the build-amd64-xsm job
http://logs.test-lab.xenproject.org/osstest/logs/77945/build-amd64-xsm/info.html
I can see in the resulting tarballs that the policy is indeed missing and
that the build log (5.ts-xen-build.log) seems to not contain the bits which
build the policy (comparing with 77892's logs)
The bisector is working:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-install.html
and has gotten to this range:
$ git log --oneline 5513bd0b4675..20c8f1a8a5fd
20c8f1a convert XSM_ENABLE to Kconfig
529298f convert FLASK_ENABLE to Kconfig
361b4f9 build: save generated xen .config
e3cce17 x86/VPMU: implement ipc and arch filter flags
I suspect the issue is that 529298f removes FLASK_ENABLE from the top-
level, but that is used in tools/Makefile. i.e. there is that other patch
which needed to go before the two included above.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL
2016-01-14 11:42 ` Ian Campbell
@ 2016-01-14 12:50 ` Jan Beulich
2016-01-14 13:57 ` Ian Campbell
0 siblings, 1 reply; 37+ messages in thread
From: Jan Beulich @ 2016-01-14 12:50 UTC (permalink / raw)
To: Doug Goldstein, Ian Campbell; +Cc: xen-devel, osstest-admin
>>> On 14.01.16 at 12:42, <ian.campbell@citrix.com> wrote:
> The bisector is working:
> http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test
> -amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-install.html
>
> and has gotten to this range:
>
> $ git log --oneline 5513bd0b4675..20c8f1a8a5fd
> 20c8f1a convert XSM_ENABLE to Kconfig
> 529298f convert FLASK_ENABLE to Kconfig
> 361b4f9 build: save generated xen .config
> e3cce17 x86/VPMU: implement ipc and arch filter flags
>
> I suspect the issue is that 529298f removes FLASK_ENABLE from the top-
> level, but that is used in tools/Makefile. i.e. there is that other patch
> which needed to go before the two included above.
And is that other patch ready to go in? If not, do we need to
revert another time?
In any event - Doug, you should point out such dependencies in
the submission, e.g. after the first --- marker.
Jan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL
2016-01-14 12:50 ` Jan Beulich
@ 2016-01-14 13:57 ` Ian Campbell
2016-01-14 14:07 ` Doug Goldstein
2016-01-14 16:27 ` [xen-unstable test] 77945: regressions - FAIL [and 2 more messages] Ian Jackson
0 siblings, 2 replies; 37+ messages in thread
From: Ian Campbell @ 2016-01-14 13:57 UTC (permalink / raw)
To: Jan Beulich, Doug Goldstein; +Cc: xen-devel, osstest-admin
On Thu, 2016-01-14 at 05:50 -0700, Jan Beulich wrote:
> > > > On 14.01.16 at 12:42, <ian.campbell@citrix.com> wrote:
> > The bisector is working:
> > http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable
> > /test
> > -amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-install.html
> >
> > and has gotten to this range:
> >
> > $ git log --oneline 5513bd0b4675..20c8f1a8a5fd
> > 20c8f1a convert XSM_ENABLE to Kconfig
> > 529298f convert FLASK_ENABLE to Kconfig
> > 361b4f9 build: save generated xen .config
> > e3cce17 x86/VPMU: implement ipc and arch filter flags
> >
> > I suspect the issue is that 529298f removes FLASK_ENABLE from the top-
> > level, but that is used in tools/Makefile. i.e. there is that other
> > patch
> > which needed to go before the two included above.
>
> And is that other patch ready to go in? If not, do we need to
> revert another time?
I think that is likely to be the case, yes.
> In any event - Doug, you should point out such dependencies in
> the submission, e.g. after the first --- marker.
Really they should have been in the same series in this case.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL
2016-01-14 13:57 ` Ian Campbell
@ 2016-01-14 14:07 ` Doug Goldstein
2016-01-14 14:44 ` Ian Campbell
2016-01-14 14:48 ` Jan Beulich
2016-01-14 16:27 ` [xen-unstable test] 77945: regressions - FAIL [and 2 more messages] Ian Jackson
1 sibling, 2 replies; 37+ messages in thread
From: Doug Goldstein @ 2016-01-14 14:07 UTC (permalink / raw)
To: Ian Campbell, Jan Beulich; +Cc: xen-devel, osstest-admin
[-- Attachment #1.1: Type: text/plain, Size: 1414 bytes --]
On 1/14/16 7:57 AM, Ian Campbell wrote:
> On Thu, 2016-01-14 at 05:50 -0700, Jan Beulich wrote:
>>>>> On 14.01.16 at 12:42, <ian.campbell@citrix.com> wrote:
>>> The bisector is working:
>>> http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable
>>> /test
>>> -amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-install.html
>>>
>>> and has gotten to this range:
>>>
>>> $ git log --oneline 5513bd0b4675..20c8f1a8a5fd
>>> 20c8f1a convert XSM_ENABLE to Kconfig
>>> 529298f convert FLASK_ENABLE to Kconfig
>>> 361b4f9 build: save generated xen .config
>>> e3cce17 x86/VPMU: implement ipc and arch filter flags
>>>
>>> I suspect the issue is that 529298f removes FLASK_ENABLE from the top-
>>> level, but that is used in tools/Makefile. i.e. there is that other
>>> patch
>>> which needed to go before the two included above.
>>
>> And is that other patch ready to go in? If not, do we need to
>> revert another time?
>
> I think that is likely to be the case, yes.
>
>> In any event - Doug, you should point out such dependencies in
>> the submission, e.g. after the first --- marker.
>
> Really they should have been in the same series in this case.
>
> Ian.
>
They were all in the same thread. And were all acked. But the first one
against the tools shouldn't have been necessary, it should have still built.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* [OSSTEST PATCH] pass --{enable, disable}-xsmpolicy based on XSM state
@ 2016-01-14 14:28 ` Doug Goldstein
2016-01-13 19:30 ` [xen-unstable test] 77945: regressions - FAIL osstest service owner
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: Doug Goldstein @ 2016-01-14 14:28 UTC (permalink / raw)
To: xen-devel; +Cc: Doug Goldstein, Ian Jackson, Ian Campbell
If the test should build with XSM then supply --enable-xsmpolicy to the
tools/configure script otherwise provide --disable-xsmpolicy. This will
allow the default to change from --enable-xsmpolicy to
--disable-xsmpolicy in the Xen tree without breaking OSSTest.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
---
ts-xen-build | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ts-xen-build b/ts-xen-build
index bc4e41a..4812dff 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -111,6 +111,7 @@ END
sub build () {
my $xend_opt= $r{enable_xend} =~ m/true/ ? "--enable-xend" : "--disable-xend";
my $ovmf_opt= $r{enable_ovmf} =~ m/true/ ? "--enable-ovmf" : "--disable-ovmf";
+ my $xsm_opt= $r{enable_xsm} =~ m/true/ ? "--enable-xsmpolicy" : "--disable-xsmpolicy";
my $configure_prefix = $r{cmdprefix_configure} // '';
my $make_prefix = $r{cmdprefix_make} // '';
@@ -123,8 +124,11 @@ sub build () {
if grep -q -- $ovmf_opt tools/configure ; then
ovmf=$ovmf_opt
fi
+ if grep -q -- $xsm_opt tools/configure ; then
+ xsm=$xsm_opt
+ fi
END
- $configure_prefix ./configure --sysconfdir=/etc \$xend \$ovmf
+ $configure_prefix ./configure --sysconfdir=/etc \$xend \$ovmf \$xsm
END
fi
END
--
2.4.10
^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL
2016-01-14 14:07 ` Doug Goldstein
@ 2016-01-14 14:44 ` Ian Campbell
2016-01-14 14:54 ` Doug Goldstein
2016-01-14 14:48 ` Jan Beulich
1 sibling, 1 reply; 37+ messages in thread
From: Ian Campbell @ 2016-01-14 14:44 UTC (permalink / raw)
To: Doug Goldstein, Jan Beulich; +Cc: xen-devel, osstest-admin
On Thu, 2016-01-14 at 08:07 -0600, Doug Goldstein wrote:
> On 1/14/16 7:57 AM, Ian Campbell wrote:
> > On Thu, 2016-01-14 at 05:50 -0700, Jan Beulich wrote:
> > > > > > On 14.01.16 at 12:42, <ian.campbell@citrix.com> wrote:
> > > > The bisector is working:
> > > > http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unst
> > > > able
> > > > /test
> > > > -amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-install.html
> > > >
> > > > and has gotten to this range:
> > > >
> > > > $ git log --oneline 5513bd0b4675..20c8f1a8a5fd
> > > > 20c8f1a convert XSM_ENABLE to Kconfig
> > > > 529298f convert FLASK_ENABLE to Kconfig
> > > > 361b4f9 build: save generated xen .config
> > > > e3cce17 x86/VPMU: implement ipc and arch filter flags
> > > >
> > > > I suspect the issue is that 529298f removes FLASK_ENABLE from the
> > > > top-
> > > > level, but that is used in tools/Makefile. i.e. there is that other
> > > > patch
> > > > which needed to go before the two included above.
> > >
> > > And is that other patch ready to go in? If not, do we need to
> > > revert another time?
> >
> > I think that is likely to be the case, yes.
> >
> > > In any event - Doug, you should point out such dependencies in
> > > the submission, e.g. after the first --- marker.
> >
> > Really they should have been in the same series in this case.
> >
> > Ian.
> >
>
> They were all in the same thread. And were all acked. But the first one
> against the tools shouldn't have been necessary, it should have still
> built.
I was talking about "tools: make flask utils build unconditional" from <145
0759603-24249-1-git-send-email-cardoe@cardoe.com> which appears to be a
singleton patch, not part of a series. Maybe that is unrelated to this
breakage then?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL
2016-01-14 14:07 ` Doug Goldstein
2016-01-14 14:44 ` Ian Campbell
@ 2016-01-14 14:48 ` Jan Beulich
2016-01-14 15:04 ` Doug Goldstein
1 sibling, 1 reply; 37+ messages in thread
From: Jan Beulich @ 2016-01-14 14:48 UTC (permalink / raw)
To: Doug Goldstein; +Cc: xen-devel, Ian Campbell, osstest-admin
>>> On 14.01.16 at 15:07, <cardoe@cardoe.com> wrote:
> On 1/14/16 7:57 AM, Ian Campbell wrote:
>> On Thu, 2016-01-14 at 05:50 -0700, Jan Beulich wrote:
>>> In any event - Doug, you should point out such dependencies in
>>> the submission, e.g. after the first --- marker.
>>
>> Really they should have been in the same series in this case.
>
> They were all in the same thread. And were all acked. But the first one
> against the tools shouldn't have been necessary, it should have still built.
Indeed I now see they were, but that's visible only in a threading
capable mail client (which mine isn't). The patches should have
been 1/3, 2/3, and 3/3, instead of the tools one being unnumbered
and the hypervisor ones being 1/2 and 2/2. And the latest at the
point where we had to revert the hypervisor ones (or when we
were about to re-apply them) you should have shouted to tell us
(me) that these got applied too early anyway.
Jan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL
2016-01-14 14:44 ` Ian Campbell
@ 2016-01-14 14:54 ` Doug Goldstein
0 siblings, 0 replies; 37+ messages in thread
From: Doug Goldstein @ 2016-01-14 14:54 UTC (permalink / raw)
To: Ian Campbell, Jan Beulich; +Cc: xen-devel, osstest-admin
[-- Attachment #1.1: Type: text/plain, Size: 2340 bytes --]
On 1/14/16 8:44 AM, Ian Campbell wrote:
> On Thu, 2016-01-14 at 08:07 -0600, Doug Goldstein wrote:
>> On 1/14/16 7:57 AM, Ian Campbell wrote:
>>> On Thu, 2016-01-14 at 05:50 -0700, Jan Beulich wrote:
>>>>>>> On 14.01.16 at 12:42, <ian.campbell@citrix.com> wrote:
>>>>> The bisector is working:
>>>>> http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unst
>>>>> able
>>>>> /test
>>>>> -amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-install.html
>>>>>
>>>>> and has gotten to this range:
>>>>>
>>>>> $ git log --oneline 5513bd0b4675..20c8f1a8a5fd
>>>>> 20c8f1a convert XSM_ENABLE to Kconfig
>>>>> 529298f convert FLASK_ENABLE to Kconfig
>>>>> 361b4f9 build: save generated xen .config
>>>>> e3cce17 x86/VPMU: implement ipc and arch filter flags
>>>>>
>>>>> I suspect the issue is that 529298f removes FLASK_ENABLE from the
>>>>> top-
>>>>> level, but that is used in tools/Makefile. i.e. there is that other
>>>>> patch
>>>>> which needed to go before the two included above.
>>>>
>>>> And is that other patch ready to go in? If not, do we need to
>>>> revert another time?
>>>
>>> I think that is likely to be the case, yes.
>>>
>>>> In any event - Doug, you should point out such dependencies in
>>>> the submission, e.g. after the first --- marker.
>>>
>>> Really they should have been in the same series in this case.
>>>
>>> Ian.
>>>
>>
>> They were all in the same thread. And were all acked. But the first one
>> against the tools shouldn't have been necessary, it should have still
>> built.
>
> I was talking about "tools: make flask utils build unconditional" from <145
> 0759603-24249-1-git-send-email-cardoe@cardoe.com> which appears to be a
> singleton patch, not part of a series. Maybe that is unrelated to this
> breakage then?
>
> Ian.
>
>
It shouldn't have been required. Its all controlled by
--enable-xsmpolicy or --disable-xsmpolicy.
But I now see where it is. Technically the OSSTest depends on
FLASK_ENABLE but only sets XSM_ENABLE in the tests. It relies on the
fact that FLASK_ENABLE defaults to the same value as XSM_ENABLE but I
removed that in the last patch.
I will provide patches to OSSTest to set the proper variables rather
than assuming they will be populated appropriately.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* [OSSTEST PATCH] enable FLASK_ENABLE when using it for testing
@ 2016-01-14 14:58 Doug Goldstein
2016-01-14 14:28 ` [OSSTEST PATCH] pass --{enable, disable}-xsmpolicy based on XSM state Doug Goldstein
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: Doug Goldstein @ 2016-01-14 14:58 UTC (permalink / raw)
To: xen-devel; +Cc: Doug Goldstein, Ian Jackson, Ian Campbell
Currently OSSTest has 'XSM' tests but XSM and FLASK are two different
options and OSSTests's 'XSM' test depends on FLASK so ensure that FLASK
is enabled so that tests pass.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
---
ts-xen-build | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-xen-build b/ts-xen-build
index 4812dff..228ceac 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -60,6 +60,7 @@ END
echo >>xen/.config CONFIG_FLASK='${build_xsm}'
fi
echo >>.config XSM_ENABLE='${build_xsm}'
+ echo >>.config FLASK_ENABLE='${build_xsm}'
END
(nonempty($r{tree_qemu}) ? <<END : '').
echo >>.config QEMU_REMOTE='$r{tree_qemu}'
--
2.4.10
^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL
2016-01-14 14:48 ` Jan Beulich
@ 2016-01-14 15:04 ` Doug Goldstein
0 siblings, 0 replies; 37+ messages in thread
From: Doug Goldstein @ 2016-01-14 15:04 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Ian Campbell, osstest-admin
[-- Attachment #1.1: Type: text/plain, Size: 1321 bytes --]
On 1/14/16 8:48 AM, Jan Beulich wrote:
>>>> On 14.01.16 at 15:07, <cardoe@cardoe.com> wrote:
>> On 1/14/16 7:57 AM, Ian Campbell wrote:
>>> On Thu, 2016-01-14 at 05:50 -0700, Jan Beulich wrote:
>>>> In any event - Doug, you should point out such dependencies in
>>>> the submission, e.g. after the first --- marker.
>>>
>>> Really they should have been in the same series in this case.
>>
>> They were all in the same thread. And were all acked. But the first one
>> against the tools shouldn't have been necessary, it should have still built.
>
> Indeed I now see they were, but that's visible only in a threading
> capable mail client (which mine isn't). The patches should have
> been 1/3, 2/3, and 3/3, instead of the tools one being unnumbered
> and the hypervisor ones being 1/2 and 2/2. And the latest at the
> point where we had to revert the hypervisor ones (or when we
> were about to re-apply them) you should have shouted to tell us
> (me) that these got applied too early anyway.
>
> Jan
>
I believe the issue is some underlying assumptions between OSSTest and
the Xen code base and myself. I've submitted patches to OSSTest to right
the ship. That first patch in the thread shouldn't really be necessary.
It'd be nice to clean it up but not required.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [OSSTEST PATCH] enable FLASK_ENABLE when using it for testing
2016-01-14 14:58 [OSSTEST PATCH] enable FLASK_ENABLE when using it for testing Doug Goldstein
2016-01-14 14:28 ` [OSSTEST PATCH] pass --{enable, disable}-xsmpolicy based on XSM state Doug Goldstein
@ 2016-01-14 16:22 ` Ian Campbell
2016-01-14 16:34 ` Doug Goldstein
2016-01-16 20:54 ` Doug Goldstein
2 siblings, 1 reply; 37+ messages in thread
From: Ian Campbell @ 2016-01-14 16:22 UTC (permalink / raw)
To: Doug Goldstein, xen-devel; +Cc: Ian Jackson
On Thu, 2016-01-14 at 08:58 -0600, Doug Goldstein wrote:
> Currently OSSTest has 'XSM' tests but XSM and FLASK are two different
> options and OSSTests's 'XSM' test depends on FLASK so ensure that FLASK
> is enabled so that tests pass.
IMHO the xen/Kconfig should be arranged such that if XSM is enabled then
FLASK is on by default. Having XSM but not Flask as what happens if you
enable XSM isn't helpful.
However, xen/common/Kconfig already has "default y" and "depends XSM" for
the FLASK entry, which I would have said was what was required to behave as
I suggest.
So why isn't it I wonder?
After a plain "make -C xen defconfig" I end up with a xen/.config
containing "CONFIG_XSM is not set" and no mention of CONFIG_FLASK (as
expected, due to the depends).
Adding CONFIG_XSM=y to the end of xen/.config and running "make -C xen
oldconfig" I then get asked:
FLux Advanced Security Kernel support (FLASK) [Y/n/?] (NEW)
IOW it does appear to be defaulting to on (I also get asked about
LATE_HWDOM).
osstest uses "olddefconfig", and with:
$ make -C xen olddefconfig
$ echo 'CONFIG_XSM=y' >> xen/.config
$ make -C xen olddefconfig
I end up with both XSM and FLASK enabled:
$ grep -E XSM\|FLASK xen/.config
CONFIG_FLASK=y
CONFIG_XSM=y
which is what we want and is expected etc. Looking at the results of the
latest xen-unstable http://logs.test-lab.xenproject.org/osstest/logs/77945/
and specifically at
http://logs.test-lab.xenproject.org/osstest/logs/77945/build-amd64-xsm/build/xen-hv-config
it seems that the automated version is doing what is expected too. IOW this
patch is both unnecessary (since it already works) and wrong (since it is
working how we want it to) and the issue exhibited by the test cases in
77945 is something different.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-14 13:57 ` Ian Campbell
2016-01-14 14:07 ` Doug Goldstein
@ 2016-01-14 16:27 ` Ian Jackson
2016-01-14 17:07 ` Doug Goldstein
` (2 more replies)
1 sibling, 3 replies; 37+ messages in thread
From: Ian Jackson @ 2016-01-14 16:27 UTC (permalink / raw)
To: Doug Goldstein, Ian Campbell
Cc: xen-devel, osstest-admin, Jan Beulich, xen-devel
I have to confess I'm quite confused now. Maybe there are many
underlying disagreements here but mostly I seem befogged. However,
here are some principles I currently believe in for how this should
all work:
* It should be possible to enable, or disable, all of the following
things by pulling one handle:
- XSM hypervisor support
- FLASK hypervisor support
- installation of the FLASK policy in /boot
- presence of the Xen+XSM boot entry
* FAOD it is IMO OK for some of those things to be configurable
separately, but there should be one most obvious way to enable, or
disable, them all together.
* This single handle should be used by osstest, so that osstest is
testing the most usual build method. (Corollary: current code in
osstest that conditionally copies the policy is a bodge which would
ideally go away.)
* I do not have a strong opinion about whether FLASK policy-handling
tools ought to be always built. I see no harm in building them
always and I can see arguments in favour.
* Users should not get boot config options that are definitely not
going to work (see above). (Or at least, not unless they try
hard.)
* The hypervisor maintainers object to autoconf. This is fine. But
it means that if we want to have a single configuration option
which affects both hypervisor and tools (at least, by default),
that it should be possible for tools config options to at least
inherit their defaults from Kconfig.
* Perhaps this should be done by having the tools configure run some
Kconfig. If so there should be an autoconf command line option to
suppress this.
* Alternatively, perhaps configure should be changed so that it can
set Kconfig settings which the hypervisor build will pick up.
* IMO it is fine to put the Xen Kconfig config file in /boot. Given
the existing state of the rest of the universe, this seems like the
best place for me.
* osstest's replacement Xen grub menu entry generator ought to be on
an upstream track. This is necessary because osstest ought to be
using features that users will get too.
* I don't have a clear design proposal for the above but I think Doug
can probably provide one. I'm hoping this is more a matter of
thinking carefully than of extensive build system programming!
* If a fix for this is hard to achieve for some reason I will be
content with patches which make things no worse, overall, than they
were before Christmas :-). (By which I do not mean that I demand a
Pareto improvement.)
Is any of this of any use ?
Thanks,
Ian.
(no less confused after writing this than I was before)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [OSSTEST PATCH] enable FLASK_ENABLE when using it for testing
2016-01-14 16:22 ` [OSSTEST PATCH] enable FLASK_ENABLE when using it for testing Ian Campbell
@ 2016-01-14 16:34 ` Doug Goldstein
0 siblings, 0 replies; 37+ messages in thread
From: Doug Goldstein @ 2016-01-14 16:34 UTC (permalink / raw)
To: Ian Campbell, xen-devel; +Cc: Ian Jackson
[-- Attachment #1.1: Type: text/plain, Size: 2591 bytes --]
On 1/14/16 10:22 AM, Ian Campbell wrote:
> On Thu, 2016-01-14 at 08:58 -0600, Doug Goldstein wrote:
>> Currently OSSTest has 'XSM' tests but XSM and FLASK are two different
>> options and OSSTests's 'XSM' test depends on FLASK so ensure that FLASK
>> is enabled so that tests pass.
>
> IMHO the xen/Kconfig should be arranged such that if XSM is enabled then
> FLASK is on by default. Having XSM but not Flask as what happens if you
> enable XSM isn't helpful.
That is how its setup. But a test framework should be explicit over
implicit over behaviors.
>
> However, xen/common/Kconfig already has "default y" and "depends XSM" for
> the FLASK entry, which I would have said was what was required to behave as
> I suggest.
>
> So why isn't it I wonder?
It is. If the test framework enabled FLASK since its testing FLASK then
I would agree with you. I'd actually argue that my patch didn't go far
enough and change all the places to FLASK instead of XSM.
>
> After a plain "make -C xen defconfig" I end up with a xen/.config
> containing "CONFIG_XSM is not set" and no mention of CONFIG_FLASK (as
> expected, due to the depends).
>
> Adding CONFIG_XSM=y to the end of xen/.config and running "make -C xen
> oldconfig" I then get asked:
>
> FLux Advanced Security Kernel support (FLASK) [Y/n/?] (NEW)
>
> IOW it does appear to be defaulting to on (I also get asked about
> LATE_HWDOM).
>
> osstest uses "olddefconfig", and with:
>
> $ make -C xen olddefconfig
> $ echo 'CONFIG_XSM=y' >> xen/.config
> $ make -C xen olddefconfig
>
> I end up with both XSM and FLASK enabled:
>
> $ grep -E XSM\|FLASK xen/.config
> CONFIG_FLASK=y
> CONFIG_XSM=y
>
> which is what we want and is expected etc. Looking at the results of the
> latest xen-unstable http://logs.test-lab.xenproject.org/osstest/logs/77945/
> and specifically at
> http://logs.test-lab.xenproject.org/osstest/logs/77945/build-amd64-xsm/build/xen-hv-config
> it seems that the automated version is doing what is expected too. IOW this
> patch is both unnecessary (since it already works) and wrong (since it is
> working how we want it to) and the issue exhibited by the test cases in
> 77945 is something different.
>
> Ian.
>
This patch is for the tooling. The point of the patch is to be explicit
over implicit defaults. FLASK depends on XSM. The test framework tests
FLASK. It was relying on the behavior that FLASK is defaulted to enabled
when XSM is enabled but if it wants to test FLASK it should turn on FLASK.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-14 16:27 ` [xen-unstable test] 77945: regressions - FAIL [and 2 more messages] Ian Jackson
@ 2016-01-14 17:07 ` Doug Goldstein
2016-01-14 17:18 ` Ian Jackson
2016-01-15 16:06 ` Jan Beulich
2016-01-15 17:06 ` Ian Campbell
2 siblings, 1 reply; 37+ messages in thread
From: Doug Goldstein @ 2016-01-14 17:07 UTC (permalink / raw)
To: Ian Jackson, Ian Campbell
Cc: xen-devel, osstest-admin, Jan Beulich, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 5264 bytes --]
On 1/14/16 10:27 AM, Ian Jackson wrote:
> I have to confess I'm quite confused now. Maybe there are many
> underlying disagreements here but mostly I seem befogged. However,
> here are some principles I currently believe in for how this should
> all work:
>
> * It should be possible to enable, or disable, all of the following
> things by pulling one handle:
> - XSM hypervisor support
> - FLASK hypervisor support
> - installation of the FLASK policy in /boot
> - presence of the Xen+XSM boot entry
I think this is where the issue lies. There have always been multiple
switches to pull and different assumptions where made.
- XSM in the hypervisor was enabled by XSM_ENABLE at the top level.
Currently it is enabled by the CONFIG_XSM Kconfig switch in the xen/
directory.
- FLASK in the hypervisor was enabled by FLASK_ENABLE at the top level.
It did not depend on XSM_ENABLE in the Makefile rules (but the code did
ifdef it out since it needed XSM_ENABLE). Currently it is enabled by the
CONFIG_FLASK Kconfig switch in the xen/ directory. It depends on CONFIG_XSM.
- The FLASK policy installation is controlled in the tools/ by
--enable-xsmpolicy (which is the default) however the policy COULDN'T
build without FLASK_ENABLE being set at the top level but you could
disable XSM_ENABLE and it would still build. (which is what my patch
tried to make more explicit in osstest)
- Xen+XSM boot entry doesn't exist today but with storing the state of
the hypervisor in the .config we'll be able to make this smart by saying
"Xen supports FLASK so load in the policy since the policy is present"
>
> * FAOD it is IMO OK for some of those things to be configurable
> separately, but there should be one most obvious way to enable, or
> disable, them all together.
That's fine but we need to make the pull switch explicitly set all the
knobs correctly and not rely on implicit defaults.
>
> * This single handle should be used by osstest, so that osstest is
> testing the most usual build method. (Corollary: current code in
> osstest that conditionally copies the policy is a bodge which would
> ideally go away.)
Will it be if we document it that people need to provide a Kconfig file
to enable it and then configure with --enable-xsmpolicy?
>
> * I do not have a strong opinion about whether FLASK policy-handling
> tools ought to be always built. I see no harm in building them
> always and I can see arguments in favour.
>
> * Users should not get boot config options that are definitely not
> going to work (see above). (Or at least, not unless they try
> hard.)
I agree and that's more likely to happen now with the Kconfig file being
saved.
>
> * The hypervisor maintainers object to autoconf. This is fine. But
> it means that if we want to have a single configuration option
> which affects both hypervisor and tools (at least, by default),
> that it should be possible for tools config options to at least
> inherit their defaults from Kconfig.
So that was my question early on in the Kconfig bits if it the .config
bits should drag up to the top level or just be contained into xen/ and
I was told to keep it in xen/ hence for the split.
>
> * Perhaps this should be done by having the tools configure run some
> Kconfig. If so there should be an autoconf command line option to
> suppress this.
>
> * Alternatively, perhaps configure should be changed so that it can
> set Kconfig settings which the hypervisor build will pick up.
I'm not sure of the best approach here. It will require a little bit of
tinkering.
>
> * IMO it is fine to put the Xen Kconfig config file in /boot. Given
> the existing state of the rest of the universe, this seems like the
> best place for me.
I agree with you. But Jan disagreed. I submitted a patch both ways
because progress was better than bikeshedding and he merged the patch
into /usr/lib/debug. I'd be in favor of seeing it moved to /boot.
>
> * osstest's replacement Xen grub menu entry generator ought to be on
> an upstream track. This is necessary because osstest ought to be
> using features that users will get too.
I agree here as well. I've got a few patches that I'm planning on
submitting to grub as well to make the options a little clearer and the
defaults do the right thing in more cases.
>
> * I don't have a clear design proposal for the above but I think Doug
> can probably provide one. I'm hoping this is more a matter of
> thinking carefully than of extensive build system programming!
>
> * If a fix for this is hard to achieve for some reason I will be
> content with patches which make things no worse, overall, than they
> were before Christmas :-). (By which I do not mean that I demand a
> Pareto improvement.)
>
> Is any of this of any use ?
>
> Thanks,
> Ian.
> (no less confused after writing this than I was before)
>
The take away I see here is whatever path is taken we just need to be a
bit more explicit with what does what or what is called what to avoid
potential breakages.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-14 17:07 ` Doug Goldstein
@ 2016-01-14 17:18 ` Ian Jackson
2016-01-14 17:25 ` Ian Campbell
2016-01-14 19:10 ` Doug Goldstein
0 siblings, 2 replies; 37+ messages in thread
From: Ian Jackson @ 2016-01-14 17:18 UTC (permalink / raw)
To: Doug Goldstein
Cc: xen-devel, xen-devel, Ian Campbell, Jan Beulich, osstest-admin
Doug Goldstein writes ("Re: [Xen-devel] [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]"):
> On 1/14/16 10:27 AM, Ian Jackson wrote:
> > Is any of this of any use ?
> >
> > Thanks,
> > Ian.
> > (no less confused after writing this than I was before)
>
> The take away I see here is whatever path is taken we just need to be a
> bit more explicit with what does what or what is called what to avoid
> potential breakages.
Heh. Does this mean that we should expect more or different patches
from you ? I see your conversation with Ian Campbell about at least
one of the osstest patches is ongoing...
Ian.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-14 17:18 ` Ian Jackson
@ 2016-01-14 17:25 ` Ian Campbell
2016-01-14 19:10 ` Doug Goldstein
1 sibling, 0 replies; 37+ messages in thread
From: Ian Campbell @ 2016-01-14 17:25 UTC (permalink / raw)
To: Ian Jackson, Doug Goldstein
Cc: xen-devel, osstest-admin, Jan Beulich, xen-devel
On Thu, 2016-01-14 at 17:18 +0000, Ian Jackson wrote:
> Doug Goldstein writes ("Re: [Xen-devel] [xen-unstable test] 77945:
> regressions - FAIL [and 2 more messages]"):
> > On 1/14/16 10:27 AM, Ian Jackson wrote:
> > > Is any of this of any use ?
> > >
> > > Thanks,
> > > Ian.
> > > (no less confused after writing this than I was before)
> >
> > The take away I see here is whatever path is taken we just need to be a
> > bit more explicit with what does what or what is called what to avoid
> > potential breakages.
>
> Heh. Does this mean that we should expect more or different patches
> from you ? I see your conversation with Ian Campbell about at least
> one of the osstest patches is ongoing...
I was confused about which .config that was touching (.config vs
xen/.config), so I think my feedback was largely nonsense.
Although in the light of what was written in this thread I'm not sure what
the next step is WRT that patch either.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-14 17:18 ` Ian Jackson
2016-01-14 17:25 ` Ian Campbell
@ 2016-01-14 19:10 ` Doug Goldstein
1 sibling, 0 replies; 37+ messages in thread
From: Doug Goldstein @ 2016-01-14 19:10 UTC (permalink / raw)
To: Ian Jackson
Cc: xen-devel, xen-devel, Ian Campbell, Jan Beulich, osstest-admin
[-- Attachment #1.1: Type: text/plain, Size: 1151 bytes --]
On 1/14/16 11:18 AM, Ian Jackson wrote:
> Doug Goldstein writes ("Re: [Xen-devel] [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]"):
>> On 1/14/16 10:27 AM, Ian Jackson wrote:
>>> Is any of this of any use ?
>>>
>>> Thanks,
>>> Ian.
>>> (no less confused after writing this than I was before)
>>
>> The take away I see here is whatever path is taken we just need to be a
>> bit more explicit with what does what or what is called what to avoid
>> potential breakages.
>
> Heh. Does this mean that we should expect more or different patches
> from you ? I see your conversation with Ian Campbell about at least
> one of the osstest patches is ongoing...
>
> Ian.
>
So I stand behind the two submitted patches for osstest because I feel
that it makes it more explicit. However, I understand your point that
you would prefer 1 knob and it be the same knob that users use so I'm
willing to do the work necessarily to get the code behaving how you
would prefer but I would hope we make the code more explicit is all.
So basically, if the patches are thumbs downed I'll change.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [OSSTEST PATCH] pass --{enable, disable}-xsmpolicy based on XSM state
2016-01-14 14:28 ` [OSSTEST PATCH] pass --{enable, disable}-xsmpolicy based on XSM state Doug Goldstein
2016-01-13 19:30 ` [xen-unstable test] 77945: regressions - FAIL osstest service owner
@ 2016-01-14 21:40 ` Doug Goldstein
2016-01-16 20:50 ` Doug Goldstein
2 siblings, 0 replies; 37+ messages in thread
From: Doug Goldstein @ 2016-01-14 21:40 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson, Ian Campbell
[-- Attachment #1.1: Type: text/plain, Size: 1689 bytes --]
On 1/14/16 8:28 AM, Doug Goldstein wrote:
> If the test should build with XSM then supply --enable-xsmpolicy to the
> tools/configure script otherwise provide --disable-xsmpolicy. This will
> allow the default to change from --enable-xsmpolicy to
> --disable-xsmpolicy in the Xen tree without breaking OSSTest.
>
> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
> ---
> ts-xen-build | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/ts-xen-build b/ts-xen-build
> index bc4e41a..4812dff 100755
> --- a/ts-xen-build
> +++ b/ts-xen-build
> @@ -111,6 +111,7 @@ END
> sub build () {
> my $xend_opt= $r{enable_xend} =~ m/true/ ? "--enable-xend" : "--disable-xend";
> my $ovmf_opt= $r{enable_ovmf} =~ m/true/ ? "--enable-ovmf" : "--disable-ovmf";
> + my $xsm_opt= $r{enable_xsm} =~ m/true/ ? "--enable-xsmpolicy" : "--disable-xsmpolicy";
>
> my $configure_prefix = $r{cmdprefix_configure} // '';
> my $make_prefix = $r{cmdprefix_make} // '';
> @@ -123,8 +124,11 @@ sub build () {
> if grep -q -- $ovmf_opt tools/configure ; then
> ovmf=$ovmf_opt
> fi
> + if grep -q -- $xsm_opt tools/configure ; then
> + xsm=$xsm_opt
> + fi
> END
> - $configure_prefix ./configure --sysconfdir=/etc \$xend \$ovmf
> + $configure_prefix ./configure --sysconfdir=/etc \$xend \$ovmf \$xsm
> END
> fi
> END
>
So this patch should definitely wait until a direction is selected on
the other submitted XSM/FLASK patches for the tools.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-14 16:27 ` [xen-unstable test] 77945: regressions - FAIL [and 2 more messages] Ian Jackson
2016-01-14 17:07 ` Doug Goldstein
@ 2016-01-15 16:06 ` Jan Beulich
2016-01-15 17:06 ` Ian Campbell
2 siblings, 0 replies; 37+ messages in thread
From: Jan Beulich @ 2016-01-15 16:06 UTC (permalink / raw)
To: Ian Jackson
Cc: osstest-admin, xen-devel, Doug Goldstein, Ian Campbell, xen-devel
>>> On 14.01.16 at 17:27, <Ian.Jackson@eu.citrix.com> wrote:
> I have to confess I'm quite confused now. Maybe there are many
> underlying disagreements here but mostly I seem befogged. However,
> here are some principles I currently believe in for how this should
> all work:
>
> * It should be possible to enable, or disable, all of the following
> things by pulling one handle:
> - XSM hypervisor support
> - FLASK hypervisor support
> - installation of the FLASK policy in /boot
> - presence of the Xen+XSM boot entry
>
> * FAOD it is IMO OK for some of those things to be configurable
> separately, but there should be one most obvious way to enable, or
> disable, them all together.
Both of these would be nice, but I don't view this a requirement.
> * Users should not get boot config options that are definitely not
> going to work (see above). (Or at least, not unless they try
> hard.)
Agreed.
> * The hypervisor maintainers object to autoconf. This is fine. But
> it means that if we want to have a single configuration option
> which affects both hypervisor and tools (at least, by default),
> that it should be possible for tools config options to at least
> inherit their defaults from Kconfig.
>
> * Perhaps this should be done by having the tools configure run some
> Kconfig. If so there should be an autoconf command line option to
> suppress this.
>
> * Alternatively, perhaps configure should be changed so that it can
> set Kconfig settings which the hypervisor build will pick up.
All of these fall into the same area as the first two above - would
be nice, but not strict requirement. In particular with the various
subtrees there's no requirement for both tools and hypervisor to
be built at all in the same tree. (In fact on my only left 32-bit host
this is what happens - the 32-bit build tree only gets tools built,
and the 64-bit build tree only gets the hypervisor built.)
> * IMO it is fine to put the Xen Kconfig config file in /boot. Given
> the existing state of the rest of the universe, this seems like the
> best place for me.
I continue to disagree, but I wouldn't outright veto someone else
committing a change to this effect. I won't, however, commit
such a change myself (or only with an Explicitly-not-acked-by:
tag).
Jan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-14 16:27 ` [xen-unstable test] 77945: regressions - FAIL [and 2 more messages] Ian Jackson
2016-01-14 17:07 ` Doug Goldstein
2016-01-15 16:06 ` Jan Beulich
@ 2016-01-15 17:06 ` Ian Campbell
2016-01-15 17:10 ` Ian Jackson
` (2 more replies)
2 siblings, 3 replies; 37+ messages in thread
From: Ian Campbell @ 2016-01-15 17:06 UTC (permalink / raw)
To: Ian Jackson, Doug Goldstein
Cc: xen-devel, osstest-admin, Jan Beulich, xen-devel
On Thu, 2016-01-14 at 16:27 +0000, Ian Jackson wrote:
> * I don't have a clear design proposal for the above but I think Doug
> can probably provide one. I'm hoping this is more a matter of
> thinking carefully than of extensive build system programming!
I think we should:
1) Move /usr/lib/debug/xen-4.7-unstable.config to /boot. I previously
didn't care about what path it was, but the usecase of having grub be able
to react to the config (see below) is a strong reason to have it in /boot
IMHO. Jan has said he won't veto such a change, AFAICT everyone else is
happy with it.
2) Assume that grub (specifically the patch in http://savannah.gnu.org/bugs
/?43420 and as used by osstest today) will at some point be modified to
look at /boot/xenconfig-$version to decide whether to create an XSM entry
or not instead of the presence of /boot/xenpolicy-$version. This step
belongs here logically but chronologically could come much later since
osstest will do the right thing even if there is a spurious
/boot/xenpolicy-$version file (which is to say it will ignore the spurious
entry and boot the right thing).
3) Have tools/* always build the FLASK+XSM tools _and_ the FLASK policy and
to always install both. Any related configure options can go away and we no
longer need to worry about synchronising the configuration of the tools and
xen trees, this is desirable because we would prefer to have one set of
tools which gracefully handles differing hypervisor configurations over
needing different sets of tools (FLASK+XSM was one of the few exceptions to
that rule AFAICT).
I think with this plan there is no need to modify osstest.git, since it
already does the right thing (which is, it sets XSM for Xen builds, which
in turn enables FLASK and it does nothing for tools/* which is correct once
#3 above has happened).
The only downside is a spurious /boot/xenpolicy-$version installed when the
corresponding Xen binary doesn't support XSM, however given the assumption
in #2 (which implies the user will never see a spurious grub entry, which
is the important thing) and the fact that it avoids the complexity of
having tools/* rely in some way on xen/.config I think that is a worthwhile
trade-off.
Hopefully this simplifies a bunch of the arguments we have been having and
provides a path forwards?
Objections?
Doug, I think you have the majority of #1 and #3 already in some form or
other? #2 is not on the critical path and can come later.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-15 17:06 ` Ian Campbell
@ 2016-01-15 17:10 ` Ian Jackson
2016-01-15 17:15 ` Jan Beulich
2016-01-15 17:21 ` Doug Goldstein
2 siblings, 0 replies; 37+ messages in thread
From: Ian Jackson @ 2016-01-15 17:10 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel, Doug Goldstein, osstest-admin, Jan Beulich, xen-devel
Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]"):
...
> The only downside is a spurious /boot/xenpolicy-$version installed when the
> corresponding Xen binary doesn't support XSM, however given the assumption
> in #2 (which implies the user will never see a spurious grub entry, which
> is the important thing) and the fact that it avoids the complexity of
> having tools/* rely in some way on xen/.config I think that is a worthwhile
> trade-off.
I like this plan and I think this downside is quite tolerable.
Ian.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-15 17:06 ` Ian Campbell
2016-01-15 17:10 ` Ian Jackson
@ 2016-01-15 17:15 ` Jan Beulich
2016-01-15 17:24 ` Andrew Cooper
2016-01-15 17:21 ` Doug Goldstein
2 siblings, 1 reply; 37+ messages in thread
From: Jan Beulich @ 2016-01-15 17:15 UTC (permalink / raw)
To: Ian Campbell
Cc: osstest-admin, Ian Jackson, Doug Goldstein, xen-devel, xen-devel
>>> On 15.01.16 at 18:06, <ian.campbell@citrix.com> wrote:
> On Thu, 2016-01-14 at 16:27 +0000, Ian Jackson wrote:
>> * I don't have a clear design proposal for the above but I think Doug
>> can probably provide one. I'm hoping this is more a matter of
>> thinking carefully than of extensive build system programming!
>
> I think we should:
>
> 1) Move /usr/lib/debug/xen-4.7-unstable.config to /boot. I previously
> didn't care about what path it was, but the usecase of having grub be able
> to react to the config (see below) is a strong reason to have it in /boot
> IMHO. Jan has said he won't veto such a change, AFAICT everyone else is
> happy with it.
>
> 2) Assume that grub (specifically the patch in http://savannah.gnu.org/bugs
> /?43420 and as used by osstest today) will at some point be modified to
> look at /boot/xenconfig-$version to decide whether to create an XSM entry
> or not instead of the presence of /boot/xenpolicy-$version. This step
> belongs here logically but chronologically could come much later since
> osstest will do the right thing even if there is a spurious
> /boot/xenpolicy-$version file (which is to say it will ignore the spurious
> entry and boot the right thing).
>
> 3) Have tools/* always build the FLASK+XSM tools _and_ the FLASK policy and
> to always install both. Any related configure options can go away and we no
> longer need to worry about synchronising the configuration of the tools and
> xen trees, this is desirable because we would prefer to have one set of
> tools which gracefully handles differing hypervisor configurations over
> needing different sets of tools (FLASK+XSM was one of the few exceptions to
> that rule AFAICT).
>
> I think with this plan there is no need to modify osstest.git, since it
> already does the right thing (which is, it sets XSM for Xen builds, which
> in turn enables FLASK and it does nothing for tools/* which is correct once
> #3 above has happened).
>
> The only downside is a spurious /boot/xenpolicy-$version installed when the
> corresponding Xen binary doesn't support XSM, however given the assumption
> in #2 (which implies the user will never see a spurious grub entry, which
> is the important thing) and the fact that it avoids the complexity of
> having tools/* rely in some way on xen/.config I think that is a worthwhile
> trade-off.
>
> Hopefully this simplifies a bunch of the arguments we have been having and
> provides a path forwards?
>
> Objections?
My opinion on 1 and 2 is known; 3 seems like a good step to me.
Jan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-15 17:06 ` Ian Campbell
2016-01-15 17:10 ` Ian Jackson
2016-01-15 17:15 ` Jan Beulich
@ 2016-01-15 17:21 ` Doug Goldstein
2 siblings, 0 replies; 37+ messages in thread
From: Doug Goldstein @ 2016-01-15 17:21 UTC (permalink / raw)
To: Ian Campbell, Ian Jackson
Cc: xen-devel, osstest-admin, Jan Beulich, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 2817 bytes --]
On 1/15/16 11:06 AM, Ian Campbell wrote:
> On Thu, 2016-01-14 at 16:27 +0000, Ian Jackson wrote:
>> * I don't have a clear design proposal for the above but I think Doug
>> can probably provide one. I'm hoping this is more a matter of
>> thinking carefully than of extensive build system programming!
>
> I think we should:
>
> 1) Move /usr/lib/debug/xen-4.7-unstable.config to /boot. I previously
> didn't care about what path it was, but the usecase of having grub be able
> to react to the config (see below) is a strong reason to have it in /boot
> IMHO. Jan has said he won't veto such a change, AFAICT everyone else is
> happy with it.
>
> 2) Assume that grub (specifically the patch in http://savannah.gnu.org/bugs
> /?43420 and as used by osstest today) will at some point be modified to
> look at /boot/xenconfig-$version to decide whether to create an XSM entry
> or not instead of the presence of /boot/xenpolicy-$version. This step
> belongs here logically but chronologically could come much later since
> osstest will do the right thing even if there is a spurious
> /boot/xenpolicy-$version file (which is to say it will ignore the spurious
> entry and boot the right thing).
>
> 3) Have tools/* always build the FLASK+XSM tools _and_ the FLASK policy and
> to always install both. Any related configure options can go away and we no
> longer need to worry about synchronising the configuration of the tools and
> xen trees, this is desirable because we would prefer to have one set of
> tools which gracefully handles differing hypervisor configurations over
> needing different sets of tools (FLASK+XSM was one of the few exceptions to
> that rule AFAICT).
>
> I think with this plan there is no need to modify osstest.git, since it
> already does the right thing (which is, it sets XSM for Xen builds, which
> in turn enables FLASK and it does nothing for tools/* which is correct once
> #3 above has happened).
>
> The only downside is a spurious /boot/xenpolicy-$version installed when the
> corresponding Xen binary doesn't support XSM, however given the assumption
> in #2 (which implies the user will never see a spurious grub entry, which
> is the important thing) and the fact that it avoids the complexity of
> having tools/* rely in some way on xen/.config I think that is a worthwhile
> trade-off.
>
> Hopefully this simplifies a bunch of the arguments we have been having and
> provides a path forwards?
>
> Objections?
>
> Doug, I think you have the majority of #1 and #3 already in some form or
> other? #2 is not on the critical path and can come later.
>
> Ian.
>
Yes. No objections here. Yes I've submitted a patch for #1 and #3
earlier. They'll need to be rebased but that's easy.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-15 17:15 ` Jan Beulich
@ 2016-01-15 17:24 ` Andrew Cooper
2016-01-15 17:42 ` Ian Campbell
0 siblings, 1 reply; 37+ messages in thread
From: Andrew Cooper @ 2016-01-15 17:24 UTC (permalink / raw)
To: Jan Beulich, Ian Campbell
Cc: Doug Goldstein, xen-devel, Ian Jackson, osstest-admin, xen-devel
On 15/01/16 17:15, Jan Beulich wrote:
>>>> On 15.01.16 at 18:06, <ian.campbell@citrix.com> wrote:
>> On Thu, 2016-01-14 at 16:27 +0000, Ian Jackson wrote:
>>> * I don't have a clear design proposal for the above but I think Doug
>>> can probably provide one. I'm hoping this is more a matter of
>>> thinking carefully than of extensive build system programming!
>> I think we should:
>>
>> 1) Move /usr/lib/debug/xen-4.7-unstable.config to /boot. I previously
>> didn't care about what path it was, but the usecase of having grub be able
>> to react to the config (see below) is a strong reason to have it in /boot
>> IMHO. Jan has said he won't veto such a change, AFAICT everyone else is
>> happy with it.
>>
>> 2) Assume that grub (specifically the patch in http://savannah.gnu.org/bugs
>> /?43420 and as used by osstest today) will at some point be modified to
>> look at /boot/xenconfig-$version to decide whether to create an XSM entry
>> or not instead of the presence of /boot/xenpolicy-$version. This step
>> belongs here logically but chronologically could come much later since
>> osstest will do the right thing even if there is a spurious
>> /boot/xenpolicy-$version file (which is to say it will ignore the spurious
>> entry and boot the right thing).
>>
>> 3) Have tools/* always build the FLASK+XSM tools _and_ the FLASK policy and
>> to always install both. Any related configure options can go away and we no
>> longer need to worry about synchronising the configuration of the tools and
>> xen trees, this is desirable because we would prefer to have one set of
>> tools which gracefully handles differing hypervisor configurations over
>> needing different sets of tools (FLASK+XSM was one of the few exceptions to
>> that rule AFAICT).
>>
>> I think with this plan there is no need to modify osstest.git, since it
>> already does the right thing (which is, it sets XSM for Xen builds, which
>> in turn enables FLASK and it does nothing for tools/* which is correct once
>> #3 above has happened).
>>
>> The only downside is a spurious /boot/xenpolicy-$version installed when the
>> corresponding Xen binary doesn't support XSM, however given the assumption
>> in #2 (which implies the user will never see a spurious grub entry, which
>> is the important thing) and the fact that it avoids the complexity of
>> having tools/* rely in some way on xen/.config I think that is a worthwhile
>> trade-off.
>>
>> Hopefully this simplifies a bunch of the arguments we have been having and
>> provides a path forwards?
>>
>> Objections?
> My opinion on 1 and 2 is known; 3 seems like a good step to me.
FWIW, I also prefer option 3. It lends itself better to a toolstack
which functions in the same way, irrespective of hypervisor configuration.
~Andrew
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-15 17:24 ` Andrew Cooper
@ 2016-01-15 17:42 ` Ian Campbell
2016-01-18 7:49 ` Jan Beulich
0 siblings, 1 reply; 37+ messages in thread
From: Ian Campbell @ 2016-01-15 17:42 UTC (permalink / raw)
To: Andrew Cooper, Jan Beulich
Cc: Doug Goldstein, xen-devel, Ian Jackson, osstest-admin, xen-devel
On Fri, 2016-01-15 at 17:24 +0000, Andrew Cooper wrote:
> On 15/01/16 17:15, Jan Beulich wrote:
> > > > > On 15.01.16 at 18:06, <ian.campbell@citrix.com> wrote:
> > > On Thu, 2016-01-14 at 16:27 +0000, Ian Jackson wrote:
> > > > * I don't have a clear design proposal for the above but I think Doug
> > > > can probably provide one. I'm hoping this is more a matter of
> > > > thinking carefully than of extensive build system programming!
> > > I think we should:
> > >
> > > 1) Move /usr/lib/debug/xen-4.7-unstable.config to /boot. I previously
> > > didn't care about what path it was, but the usecase of having grub be able
> > > to react to the config (see below) is a strong reason to have it in /boot
> > > IMHO. Jan has said he won't veto such a change, AFAICT everyone else is
> > > happy with it.
> > >
> > > 2) Assume that grub (specifically the patch in http://savannah.gnu.org/bugs
> > > /?43420 and as used by osstest today) will at some point be modified to
> > > look at /boot/xenconfig-$version to decide whether to create an XSM entry
> > > or not instead of the presence of /boot/xenpolicy-$version. This step
> > > belongs here logically but chronologically could come much later since
> > > osstest will do the right thing even if there is a spurious
> > > /boot/xenpolicy-$version file (which is to say it will ignore the spurious
> > > entry and boot the right thing).
> > >
> > > 3) Have tools/* always build the FLASK+XSM tools _and_ the FLASK policy and
> > > to always install both. Any related configure options can go away and we no
> > > longer need to worry about synchronising the configuration of the tools and
> > > xen trees, this is desirable because we would prefer to have one set of
> > > tools which gracefully handles differing hypervisor configurations over
> > > needing different sets of tools (FLASK+XSM was one of the few exceptions to
> > > that rule AFAICT).
> > >
> > > I think with this plan there is no need to modify osstest.git, since it
> > > already does the right thing (which is, it sets XSM for Xen builds, which
> > > in turn enables FLASK and it does nothing for tools/* which is correct once
> > > #3 above has happened).
> > >
> > > The only downside is a spurious /boot/xenpolicy-$version installed when the
> > > corresponding Xen binary doesn't support XSM, however given the assumption
> > > in #2 (which implies the user will never see a spurious grub entry, which
> > > is the important thing) and the fact that it avoids the complexity of
> > > having tools/* rely in some way on xen/.config I think that is a worthwhile
> > > trade-off.
> > >
> > > Hopefully this simplifies a bunch of the arguments we have been having and
> > > provides a path forwards?
> > >
> > > Objections?
> > My opinion on 1 and 2 is known; 3 seems like a good step to me.
>
> FWIW, I also prefer option 3. It lends itself better to a toolstack
> which functions in the same way, irrespective of hypervisor configuration.
To be clear: These are not options, they are steps in a plan, to be
followed in order.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [OSSTEST PATCH] pass --{enable, disable}-xsmpolicy based on XSM state
2016-01-14 14:28 ` [OSSTEST PATCH] pass --{enable, disable}-xsmpolicy based on XSM state Doug Goldstein
2016-01-13 19:30 ` [xen-unstable test] 77945: regressions - FAIL osstest service owner
2016-01-14 21:40 ` [OSSTEST PATCH] pass --{enable, disable}-xsmpolicy based on XSM state Doug Goldstein
@ 2016-01-16 20:50 ` Doug Goldstein
2 siblings, 0 replies; 37+ messages in thread
From: Doug Goldstein @ 2016-01-16 20:50 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson, Ian Campbell
[-- Attachment #1.1: Type: text/plain, Size: 1756 bytes --]
On 1/14/16 8:28 AM, Doug Goldstein wrote:
> If the test should build with XSM then supply --enable-xsmpolicy to the
> tools/configure script otherwise provide --disable-xsmpolicy. This will
> allow the default to change from --enable-xsmpolicy to
> --disable-xsmpolicy in the Xen tree without breaking OSSTest.
>
> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
> ---
> ts-xen-build | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/ts-xen-build b/ts-xen-build
> index bc4e41a..4812dff 100755
> --- a/ts-xen-build
> +++ b/ts-xen-build
> @@ -111,6 +111,7 @@ END
> sub build () {
> my $xend_opt= $r{enable_xend} =~ m/true/ ? "--enable-xend" : "--disable-xend";
> my $ovmf_opt= $r{enable_ovmf} =~ m/true/ ? "--enable-ovmf" : "--disable-ovmf";
> + my $xsm_opt= $r{enable_xsm} =~ m/true/ ? "--enable-xsmpolicy" : "--disable-xsmpolicy";
>
> my $configure_prefix = $r{cmdprefix_configure} // '';
> my $make_prefix = $r{cmdprefix_make} // '';
> @@ -123,8 +124,11 @@ sub build () {
> if grep -q -- $ovmf_opt tools/configure ; then
> ovmf=$ovmf_opt
> fi
> + if grep -q -- $xsm_opt tools/configure ; then
> + xsm=$xsm_opt
> + fi
> END
> - $configure_prefix ./configure --sysconfdir=/etc \$xend \$ovmf
> + $configure_prefix ./configure --sysconfdir=/etc \$xend \$ovmf \$xsm
> END
> fi
> END
>
Given the support of the maintainers and committers for the proposal
[1], this patch should NOT be applied.
[1]
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01796.html
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [OSSTEST PATCH] enable FLASK_ENABLE when using it for testing
2016-01-14 14:58 [OSSTEST PATCH] enable FLASK_ENABLE when using it for testing Doug Goldstein
2016-01-14 14:28 ` [OSSTEST PATCH] pass --{enable, disable}-xsmpolicy based on XSM state Doug Goldstein
2016-01-14 16:22 ` [OSSTEST PATCH] enable FLASK_ENABLE when using it for testing Ian Campbell
@ 2016-01-16 20:54 ` Doug Goldstein
2 siblings, 0 replies; 37+ messages in thread
From: Doug Goldstein @ 2016-01-16 20:54 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson, Ian Campbell
[-- Attachment #1.1: Type: text/plain, Size: 994 bytes --]
On 1/14/16 8:58 AM, Doug Goldstein wrote:
> Currently OSSTest has 'XSM' tests but XSM and FLASK are two different
> options and OSSTests's 'XSM' test depends on FLASK so ensure that FLASK
> is enabled so that tests pass.
>
> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
> ---
> ts-xen-build | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/ts-xen-build b/ts-xen-build
> index 4812dff..228ceac 100755
> --- a/ts-xen-build
> +++ b/ts-xen-build
> @@ -60,6 +60,7 @@ END
> echo >>xen/.config CONFIG_FLASK='${build_xsm}'
> fi
> echo >>.config XSM_ENABLE='${build_xsm}'
> + echo >>.config FLASK_ENABLE='${build_xsm}'
> END
> (nonempty($r{tree_qemu}) ? <<END : '').
> echo >>.config QEMU_REMOTE='$r{tree_qemu}'
>
Given the support of the maintainers and committers for the proposal
[1], this patch should NOT be applied.
[1]
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01796.html
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-15 17:42 ` Ian Campbell
@ 2016-01-18 7:49 ` Jan Beulich
2016-01-18 8:55 ` Andrew Cooper
2016-01-18 9:41 ` Ian Campbell
0 siblings, 2 replies; 37+ messages in thread
From: Jan Beulich @ 2016-01-18 7:49 UTC (permalink / raw)
To: Ian Campbell
Cc: Andrew Cooper, Doug Goldstein, osstest-admin, xen-devel,
xen-devel, Ian Jackson
>>> On 15.01.16 at 18:42, <ian.campbell@citrix.com> wrote:
> On Fri, 2016-01-15 at 17:24 +0000, Andrew Cooper wrote:
>> On 15/01/16 17:15, Jan Beulich wrote:
>> > > > > On 15.01.16 at 18:06, <ian.campbell@citrix.com> wrote:
>> > > On Thu, 2016-01-14 at 16:27 +0000, Ian Jackson wrote:
>> > > > * I don't have a clear design proposal for the above but I think Doug
>> > > > can probably provide one. I'm hoping this is more a matter of
>> > > > thinking carefully than of extensive build system programming!
>> > > I think we should:
>> > >
>> > > 1) Move /usr/lib/debug/xen-4.7-unstable.config to /boot. I previously
>> > > didn't care about what path it was, but the usecase of having grub be able
>> > > to react to the config (see below) is a strong reason to have it in /boot
>> > > IMHO. Jan has said he won't veto such a change, AFAICT everyone else is
>> > > happy with it.
>> > >
>> > > 2) Assume that grub (specifically the patch in http://savannah.gnu.org/bugs
>> > > /?43420 and as used by osstest today) will at some point be modified to
>> > > look at /boot/xenconfig-$version to decide whether to create an XSM entry
>> > > or not instead of the presence of /boot/xenpolicy-$version. This step
>> > > belongs here logically but chronologically could come much later since
>> > > osstest will do the right thing even if there is a spurious
>> > > /boot/xenpolicy-$version file (which is to say it will ignore the spurious
>> > > entry and boot the right thing).
>> > >
>> > > 3) Have tools/* always build the FLASK+XSM tools _and_ the FLASK policy and
>> > > to always install both. Any related configure options can go away and we no
>> > > longer need to worry about synchronising the configuration of the tools and
>> > > xen trees, this is desirable because we would prefer to have one set of
>> > > tools which gracefully handles differing hypervisor configurations over
>> > > needing different sets of tools (FLASK+XSM was one of the few exceptions to
>> > > that rule AFAICT).
>> > >
>> > > I think with this plan there is no need to modify osstest.git, since it
>> > > already does the right thing (which is, it sets XSM for Xen builds, which
>> > > in turn enables FLASK and it does nothing for tools/* which is correct once
>> > > #3 above has happened).
>> > >
>> > > The only downside is a spurious /boot/xenpolicy-$version installed when the
>> > > corresponding Xen binary doesn't support XSM, however given the assumption
>> > > in #2 (which implies the user will never see a spurious grub entry, which
>> > > is the important thing) and the fact that it avoids the complexity of
>> > > having tools/* rely in some way on xen/.config I think that is a worthwhile
>> > > trade-off.
>> > >
>> > > Hopefully this simplifies a bunch of the arguments we have been having and
>> > > provides a path forwards?
>> > >
>> > > Objections?
>> > My opinion on 1 and 2 is known; 3 seems like a good step to me.
>>
>> FWIW, I also prefer option 3. It lends itself better to a toolstack
>> which functions in the same way, irrespective of hypervisor configuration.
>
> To be clear: These are not options, they are steps in a plan, to be
> followed in order.
"Not options" - indeed, but "in order"? At least 3 seems independent
of both 1 and 2.
Jan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-18 7:49 ` Jan Beulich
@ 2016-01-18 8:55 ` Andrew Cooper
2016-01-18 9:41 ` Ian Campbell
1 sibling, 0 replies; 37+ messages in thread
From: Andrew Cooper @ 2016-01-18 8:55 UTC (permalink / raw)
To: Jan Beulich, Ian Campbell
Cc: osstest-admin, Ian Jackson, Doug Goldstein, xen-devel, xen-devel
On 18/01/2016 07:49, Jan Beulich wrote:
>>>> On 15.01.16 at 18:42, <ian.campbell@citrix.com> wrote:
>> On Fri, 2016-01-15 at 17:24 +0000, Andrew Cooper wrote:
>>> On 15/01/16 17:15, Jan Beulich wrote:
>>>>>>> On 15.01.16 at 18:06, <ian.campbell@citrix.com> wrote:
>>>>> On Thu, 2016-01-14 at 16:27 +0000, Ian Jackson wrote:
>>>>>> * I don't have a clear design proposal for the above but I think Doug
>>>>>> can probably provide one. I'm hoping this is more a matter of
>>>>>> thinking carefully than of extensive build system programming!
>>>>> I think we should:
>>>>>
>>>>> 1) Move /usr/lib/debug/xen-4.7-unstable.config to /boot. I previously
>>>>> didn't care about what path it was, but the usecase of having grub be able
>>>>> to react to the config (see below) is a strong reason to have it in /boot
>>>>> IMHO. Jan has said he won't veto such a change, AFAICT everyone else is
>>>>> happy with it.
>>>>>
>>>>> 2) Assume that grub (specifically the patch in http://savannah.gnu.org/bugs
>>>>> /?43420 and as used by osstest today) will at some point be modified to
>>>>> look at /boot/xenconfig-$version to decide whether to create an XSM entry
>>>>> or not instead of the presence of /boot/xenpolicy-$version. This step
>>>>> belongs here logically but chronologically could come much later since
>>>>> osstest will do the right thing even if there is a spurious
>>>>> /boot/xenpolicy-$version file (which is to say it will ignore the spurious
>>>>> entry and boot the right thing).
>>>>>
>>>>> 3) Have tools/* always build the FLASK+XSM tools _and_ the FLASK policy and
>>>>> to always install both. Any related configure options can go away and we no
>>>>> longer need to worry about synchronising the configuration of the tools and
>>>>> xen trees, this is desirable because we would prefer to have one set of
>>>>> tools which gracefully handles differing hypervisor configurations over
>>>>> needing different sets of tools (FLASK+XSM was one of the few exceptions to
>>>>> that rule AFAICT).
>>>>>
>>>>> I think with this plan there is no need to modify osstest.git, since it
>>>>> already does the right thing (which is, it sets XSM for Xen builds, which
>>>>> in turn enables FLASK and it does nothing for tools/* which is correct once
>>>>> #3 above has happened).
>>>>>
>>>>> The only downside is a spurious /boot/xenpolicy-$version installed when the
>>>>> corresponding Xen binary doesn't support XSM, however given the assumption
>>>>> in #2 (which implies the user will never see a spurious grub entry, which
>>>>> is the important thing) and the fact that it avoids the complexity of
>>>>> having tools/* rely in some way on xen/.config I think that is a worthwhile
>>>>> trade-off.
>>>>>
>>>>> Hopefully this simplifies a bunch of the arguments we have been having and
>>>>> provides a path forwards?
>>>>>
>>>>> Objections?
>>>> My opinion on 1 and 2 is known; 3 seems like a good step to me.
>>> FWIW, I also prefer option 3. It lends itself better to a toolstack
>>> which functions in the same way, irrespective of hypervisor configuration.
>> To be clear: These are not options, they are steps in a plan, to be
>> followed in order.
> "Not options" - indeed, but "in order"? At least 3 seems independent
> of both 1 and 2.
3 is required to unblock OSSTest and needs to happen ASAP.
That is the absolute priority at this point.
~Andrew
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-18 7:49 ` Jan Beulich
2016-01-18 8:55 ` Andrew Cooper
@ 2016-01-18 9:41 ` Ian Campbell
2016-01-18 9:47 ` Jan Beulich
1 sibling, 1 reply; 37+ messages in thread
From: Ian Campbell @ 2016-01-18 9:41 UTC (permalink / raw)
To: Jan Beulich
Cc: Andrew Cooper, Doug Goldstein, osstest-admin, xen-devel,
xen-devel, Ian Jackson
On Mon, 2016-01-18 at 00:49 -0700, Jan Beulich wrote:
> > > > On 15.01.16 at 18:42, <ian.campbell@citrix.com> wrote:
> > On Fri, 2016-01-15 at 17:24 +0000, Andrew Cooper wrote:
> > > On 15/01/16 17:15, Jan Beulich wrote:
> > > > > > > On 15.01.16 at 18:06, <ian.campbell@citrix.com> wrote:
> > > > > On Thu, 2016-01-14 at 16:27 +0000, Ian Jackson wrote:
> > > > > > * I don't have a clear design proposal for the above but I
> > > > > > think Doug
> > > > > > can probably provide one. I'm hoping this is more a matter
> > > > > > of
> > > > > > thinking carefully than of extensive build system
> > > > > > programming!
> > > > > I think we should:
> > > > >
> > > > > 1) Move /usr/lib/debug/xen-4.7-unstable.config to /boot. I
> > > > > previously
> > > > > didn't care about what path it was, but the usecase of having
> > > > > grub be able
> > > > > to react to the config (see below) is a strong reason to have it
> > > > > in /boot
> > > > > IMHO. Jan has said he won't veto such a change, AFAICT everyone
> > > > > else is
> > > > > happy with it.
> > > > >
> > > > > 2) Assume that grub (specifically the patch in http://savannah.gn
> > > > > u.org/bugs
> > > > > /?43420 and as used by osstest today) will at some point be
> > > > > modified to
> > > > > look at /boot/xenconfig-$version to decide whether to create an
> > > > > XSM entry
> > > > > or not instead of the presence of /boot/xenpolicy-$version. This
> > > > > step
> > > > > belongs here logically but chronologically could come much later
> > > > > since
> > > > > osstest will do the right thing even if there is a spurious
> > > > > /boot/xenpolicy-$version file (which is to say it will ignore the
> > > > > spurious
> > > > > entry and boot the right thing).
> > > > >
> > > > > 3) Have tools/* always build the FLASK+XSM tools _and_ the FLASK
> > > > > policy and
> > > > > to always install both. Any related configure options can go away
> > > > > and we no
> > > > > longer need to worry about synchronising the configuration of the
> > > > > tools and
> > > > > xen trees, this is desirable because we would prefer to have one
> > > > > set of
> > > > > tools which gracefully handles differing hypervisor
> > > > > configurations over
> > > > > needing different sets of tools (FLASK+XSM was one of the few
> > > > > exceptions to
> > > > > that rule AFAICT).
> > > > >
> > > > > I think with this plan there is no need to modify osstest.git,
> > > > > since it
> > > > > already does the right thing (which is, it sets XSM for Xen
> > > > > builds, which
> > > > > in turn enables FLASK and it does nothing for tools/* which is
> > > > > correct once
> > > > > #3 above has happened).
> > > > >
> > > > > The only downside is a spurious /boot/xenpolicy-$version
> > > > > installed when the
> > > > > corresponding Xen binary doesn't support XSM, however given the
> > > > > assumption
> > > > > in #2 (which implies the user will never see a spurious grub
> > > > > entry, which
> > > > > is the important thing) and the fact that it avoids the
> > > > > complexity of
> > > > > having tools/* rely in some way on xen/.config I think that is a
> > > > > worthwhile
> > > > > trade-off.
> > > > >
> > > > > Hopefully this simplifies a bunch of the arguments we have been
> > > > > having and
> > > > > provides a path forwards?
> > > > >
> > > > > Objections?
> > > > My opinion on 1 and 2 is known; 3 seems like a good step to me.
> > >
> > > FWIW, I also prefer option 3. It lends itself better to a toolstack
> > > which functions in the same way, irrespective of hypervisor
> > > configuration.
> >
> > To be clear: These are not options, they are steps in a plan, to be
> > followed in order.
>
> "Not options" - indeed, but "in order"? At least 3 seems independent
> of both 1 and 2.
Without #1 we cannot make the assumption in #2.
Without (the assumption of eventually doing) #2 we cannot do #3 because
that would result in spurious boot menu entries for users (i.e. ones which
claim to enable XSM but boot an XSM incapable Xen) which several of us feel
we should avoid.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-18 9:41 ` Ian Campbell
@ 2016-01-18 9:47 ` Jan Beulich
2016-01-18 11:22 ` Ian Campbell
0 siblings, 1 reply; 37+ messages in thread
From: Jan Beulich @ 2016-01-18 9:47 UTC (permalink / raw)
To: Ian Campbell
Cc: Andrew Cooper, Doug Goldstein, osstest-admin, xen-devel,
xen-devel, Ian Jackson
>>> On 18.01.16 at 10:41, <ian.campbell@citrix.com> wrote:
> On Mon, 2016-01-18 at 00:49 -0700, Jan Beulich wrote:
>> > > > On 15.01.16 at 18:42, <ian.campbell@citrix.com> wrote:
>> > On Fri, 2016-01-15 at 17:24 +0000, Andrew Cooper wrote:
>> > > On 15/01/16 17:15, Jan Beulich wrote:
>> > > > > > > On 15.01.16 at 18:06, <ian.campbell@citrix.com> wrote:
>> > > > > On Thu, 2016-01-14 at 16:27 +0000, Ian Jackson wrote:
>> > > > > > * I don't have a clear design proposal for the above but I
>> > > > > > think Doug
>> > > > > > can probably provide one. I'm hoping this is more a matter
>> > > > > > of
>> > > > > > thinking carefully than of extensive build system
>> > > > > > programming!
>> > > > > I think we should:
>> > > > >
>> > > > > 1) Move /usr/lib/debug/xen-4.7-unstable.config to /boot. I
>> > > > > previously
>> > > > > didn't care about what path it was, but the usecase of having
>> > > > > grub be able
>> > > > > to react to the config (see below) is a strong reason to have it
>> > > > > in /boot
>> > > > > IMHO. Jan has said he won't veto such a change, AFAICT everyone
>> > > > > else is
>> > > > > happy with it.
>> > > > >
>> > > > > 2) Assume that grub (specifically the patch in http://savannah.gn
>> > > > > u.org/bugs
>> > > > > /?43420 and as used by osstest today) will at some point be
>> > > > > modified to
>> > > > > look at /boot/xenconfig-$version to decide whether to create an
>> > > > > XSM entry
>> > > > > or not instead of the presence of /boot/xenpolicy-$version. This
>> > > > > step
>> > > > > belongs here logically but chronologically could come much later
>> > > > > since
>> > > > > osstest will do the right thing even if there is a spurious
>> > > > > /boot/xenpolicy-$version file (which is to say it will ignore the
>> > > > > spurious
>> > > > > entry and boot the right thing).
>> > > > >
>> > > > > 3) Have tools/* always build the FLASK+XSM tools _and_ the FLASK
>> > > > > policy and
>> > > > > to always install both. Any related configure options can go away
>> > > > > and we no
>> > > > > longer need to worry about synchronising the configuration of the
>> > > > > tools and
>> > > > > xen trees, this is desirable because we would prefer to have one
>> > > > > set of
>> > > > > tools which gracefully handles differing hypervisor
>> > > > > configurations over
>> > > > > needing different sets of tools (FLASK+XSM was one of the few
>> > > > > exceptions to
>> > > > > that rule AFAICT).
>> > > > >
>> > > > > I think with this plan there is no need to modify osstest.git,
>> > > > > since it
>> > > > > already does the right thing (which is, it sets XSM for Xen
>> > > > > builds, which
>> > > > > in turn enables FLASK and it does nothing for tools/* which is
>> > > > > correct once
>> > > > > #3 above has happened).
>> > > > >
>> > > > > The only downside is a spurious /boot/xenpolicy-$version
>> > > > > installed when the
>> > > > > corresponding Xen binary doesn't support XSM, however given the
>> > > > > assumption
>> > > > > in #2 (which implies the user will never see a spurious grub
>> > > > > entry, which
>> > > > > is the important thing) and the fact that it avoids the
>> > > > > complexity of
>> > > > > having tools/* rely in some way on xen/.config I think that is a
>> > > > > worthwhile
>> > > > > trade-off.
>> > > > >
>> > > > > Hopefully this simplifies a bunch of the arguments we have been
>> > > > > having and
>> > > > > provides a path forwards?
>> > > > >
>> > > > > Objections?
>> > > > My opinion on 1 and 2 is known; 3 seems like a good step to me.
>> > >
>> > > FWIW, I also prefer option 3. It lends itself better to a toolstack
>> > > which functions in the same way, irrespective of hypervisor
>> > > configuration.
>> >
>> > To be clear: These are not options, they are steps in a plan, to be
>> > followed in order.
>>
>> "Not options" - indeed, but "in order"? At least 3 seems independent
>> of both 1 and 2.
>
> Without #1 we cannot make the assumption in #2.
>
> Without (the assumption of eventually doing) #2 we cannot do #3 because
> that would result in spurious boot menu entries for users (i.e. ones which
> claim to enable XSM but boot an XSM incapable Xen) which several of us feel
> we should avoid.
Ugly. Could we live with that until #1 and #2 get put in place?
Otherwise it looks very much like reverting the two Kconfig
conversion patches is the only possible solution at this point...
Jan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-18 9:47 ` Jan Beulich
@ 2016-01-18 11:22 ` Ian Campbell
2016-01-18 11:28 ` Ian Jackson
0 siblings, 1 reply; 37+ messages in thread
From: Ian Campbell @ 2016-01-18 11:22 UTC (permalink / raw)
To: Jan Beulich
Cc: Andrew Cooper, Doug Goldstein, osstest-admin, xen-devel,
xen-devel, Ian Jackson
On Mon, 2016-01-18 at 02:47 -0700, Jan Beulich wrote:
> Ugly. Could we live with that until #1 and #2 get put in place?
#1 is trivial (see below).
#2 is, as noted in my original mail, something which while it logically belongs between #1 and #3 could be deferred.
> Otherwise it looks very much like reverting the two Kconfig
> conversion patches is the only possible solution at this point...
IMHO we should apply the patch below + Doug's patch from <1452879580-1770-1
-git-send-email-cardoe@cardoe.com> today at the latest.
Ian.
8<-------------------------------
From 011f218e11972c6cea7d4c5f11f0559bef337085 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 18 Jan 2016 11:19:27 +0000
Subject: [PATCH] xen: move installed copy of xen/.config file to /boot
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
xen/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/Makefile b/xen/Makefile
index 3699b20..2b34898 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -58,7 +58,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
ln -f -s $(T)-$(XEN_FULLVERSION)$(Z) $(D)$(BOOT_DIR)/$(T)$(Z)
[ -d "$(D)$(DEBUG_DIR)" ] || $(INSTALL_DIR) $(D)$(DEBUG_DIR)
$(INSTALL_DATA) $(TARGET)-syms $(D)$(DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION)
- $(INSTALL_DATA) $(KCONFIG_CONFIG) $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).config
+ $(INSTALL_DATA) $(KCONFIG_CONFIG) $(D)$(BOOT_DIR)/$(T)-$(XEN_FULLVERSION).config
if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
[ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
$(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-18 11:22 ` Ian Campbell
@ 2016-01-18 11:28 ` Ian Jackson
2016-01-18 11:36 ` Ian Campbell
0 siblings, 1 reply; 37+ messages in thread
From: Ian Jackson @ 2016-01-18 11:28 UTC (permalink / raw)
To: Ian Campbell
Cc: Andrew Cooper, Doug Goldstein, osstest-admin, xen-devel,
Jan Beulich, xen-devel
Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]"):
> On Mon, 2016-01-18 at 02:47 -0700, Jan Beulich wrote:
> > Ugly. Could we live with that until #1 and #2 get put in place?
>
> #1 is trivial (see below).
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> #2 is, as noted in my original mail, something which while it logically belongs between #1 and #3 could be deferred.
>
> > Otherwise it looks very much like reverting the two Kconfig
> > conversion patches is the only possible solution at this point...
>
> IMHO we should apply the patch below + Doug's patch from <1452879580-1770-1
> -git-send-email-cardoe@cardoe.com> today at the latest.
FR, this latter message is "tools: make FLASK utils build
unconditional".
With these, is osstest going to DTRT ?
My fear is that the appearance of the policy will cause non-XSM builds
to generate an XSM boot entry which will osstest might select. But I
haven't peered at the interlocking bits of code to see what will
happen.
Ian.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-18 11:28 ` Ian Jackson
@ 2016-01-18 11:36 ` Ian Campbell
2016-01-18 12:09 ` Ian Campbell
0 siblings, 1 reply; 37+ messages in thread
From: Ian Campbell @ 2016-01-18 11:36 UTC (permalink / raw)
To: Ian Jackson
Cc: Andrew Cooper, Doug Goldstein, osstest-admin, xen-devel,
Jan Beulich, xen-devel
On Mon, 2016-01-18 at 11:28 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 77945:
> regressions - FAIL [and 2 more messages]"):
> > On Mon, 2016-01-18 at 02:47 -0700, Jan Beulich wrote:
> > > Ugly. Could we live with that until #1 and #2 get put in place?
> >
> > #1 is trivial (see below).
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Thanks.
> > #2 is, as noted in my original mail, something which while it logically
> > belongs between #1 and #3 could be deferred.
> >
> > > Otherwise it looks very much like reverting the two Kconfig
> > > conversion patches is the only possible solution at this point...
> >
> > IMHO we should apply the patch below + Doug's patch from <1452879580-
> > 1770-1
> > -git-send-email-cardoe@cardoe.com> today at the latest.
>
> FR, this latter message is "tools: make FLASK utils build
> unconditional".
>
> With these, is osstest going to DTRT ?
I think so.
> My fear is that the appearance of the policy will cause non-XSM builds
> to generate an XSM boot entry which will osstest might select. But I
> haven't peered at the interlocking bits of code to see what will
> happen.
Osstest::Debian::setupboot_grub2 takes a "$want_xsm" parameter and has
code:
} elsif ($want_xsm && !defined $entry->{Xenpolicy}) {
logm("(skipping entry at $entry->{StartLine}..$.;".
" XSM policy file not present)");
which isn't quite what I expected, as it solves half the problem (booting a
non-XSM Xen when Xsm is desired) I think.
I think we'd want to add another case like:
} elsif (!$want_xsm && defined $entry->{Xenpolicy}) {
logm("(skipping entry at $entry->{StartLine}..$.;".
" XSM policy file present)");
?
However I don't think this is urgent (i.e. blocking) since, as it happens (and due to the way 20_linux_xen is patched), the non-XSM entry always precedes the XSM one, so a non-XSM test would find that first and stop looking.
So I think we can go ahead and I will turn the above into an osstest patch in parallel.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
2016-01-18 11:36 ` Ian Campbell
@ 2016-01-18 12:09 ` Ian Campbell
0 siblings, 0 replies; 37+ messages in thread
From: Ian Campbell @ 2016-01-18 12:09 UTC (permalink / raw)
To: Ian Jackson
Cc: Andrew Cooper, Doug Goldstein, osstest-admin, xen-devel,
Jan Beulich, xen-devel
On Mon, 2016-01-18 at 11:36 +0000, Ian Campbell wrote:
> On Mon, 2016-01-18 at 11:28 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 77945:
> > regressions - FAIL [and 2 more messages]"):
> > > On Mon, 2016-01-18 at 02:47 -0700, Jan Beulich wrote:
> > > > Ugly. Could we live with that until #1 and #2 get put in place?
> > >
> > > #1 is trivial (see below).
> >
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> Thanks.
>
> > > #2 is, as noted in my original mail, something which while it
> > > logically
> > > belongs between #1 and #3 could be deferred.
> > >
> > > > Otherwise it looks very much like reverting the two Kconfig
> > > > conversion patches is the only possible solution at this point...
> > >
> > > IMHO we should apply the patch below + Doug's patch from <1452879580-
> > > 1770-1
> > > -git-send-email-cardoe@cardoe.com> today at the latest.
> >
> > FR, this latter message is "tools: make FLASK utils build
> > unconditional".
> >
> > With these, is osstest going to DTRT ?
>
> I think so.
>
> > My fear is that the appearance of the policy will cause non-XSM builds
> > to generate an XSM boot entry which will osstest might select. But I
> > haven't peered at the interlocking bits of code to see what will
> > happen.
>
[...]
> So I think we can go ahead and I will turn the above into an osstest
> patch in parallel.
Ian was convinced by my argumentation here (and told me so on IRC) so I
have gone ahead and pushed this and acked + applied Doug's patch too.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2016-01-18 12:09 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-14 14:58 [OSSTEST PATCH] enable FLASK_ENABLE when using it for testing Doug Goldstein
2016-01-14 14:28 ` [OSSTEST PATCH] pass --{enable, disable}-xsmpolicy based on XSM state Doug Goldstein
2016-01-13 19:30 ` [xen-unstable test] 77945: regressions - FAIL osstest service owner
2016-01-14 9:30 ` Jan Beulich
2016-01-14 11:42 ` Ian Campbell
2016-01-14 12:50 ` Jan Beulich
2016-01-14 13:57 ` Ian Campbell
2016-01-14 14:07 ` Doug Goldstein
2016-01-14 14:44 ` Ian Campbell
2016-01-14 14:54 ` Doug Goldstein
2016-01-14 14:48 ` Jan Beulich
2016-01-14 15:04 ` Doug Goldstein
2016-01-14 16:27 ` [xen-unstable test] 77945: regressions - FAIL [and 2 more messages] Ian Jackson
2016-01-14 17:07 ` Doug Goldstein
2016-01-14 17:18 ` Ian Jackson
2016-01-14 17:25 ` Ian Campbell
2016-01-14 19:10 ` Doug Goldstein
2016-01-15 16:06 ` Jan Beulich
2016-01-15 17:06 ` Ian Campbell
2016-01-15 17:10 ` Ian Jackson
2016-01-15 17:15 ` Jan Beulich
2016-01-15 17:24 ` Andrew Cooper
2016-01-15 17:42 ` Ian Campbell
2016-01-18 7:49 ` Jan Beulich
2016-01-18 8:55 ` Andrew Cooper
2016-01-18 9:41 ` Ian Campbell
2016-01-18 9:47 ` Jan Beulich
2016-01-18 11:22 ` Ian Campbell
2016-01-18 11:28 ` Ian Jackson
2016-01-18 11:36 ` Ian Campbell
2016-01-18 12:09 ` Ian Campbell
2016-01-15 17:21 ` Doug Goldstein
2016-01-14 21:40 ` [OSSTEST PATCH] pass --{enable, disable}-xsmpolicy based on XSM state Doug Goldstein
2016-01-16 20:50 ` Doug Goldstein
2016-01-14 16:22 ` [OSSTEST PATCH] enable FLASK_ENABLE when using it for testing Ian Campbell
2016-01-14 16:34 ` Doug Goldstein
2016-01-16 20:54 ` Doug Goldstein
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.