Re: [Xen-devel] [RFC 01/29] build: import Kbuild/Kconfig from Linux 4.2
>>> On 06.10.15 at 18:47, wrote: > On 10/6/15 7:45 AM, Jan Beulich wrote: >> Also, btw - I don't think we should name the thing Kconfig in Xen; >> Xconfig would be odd too (to be confused with X), so maybe >> XenConfig? > > I forgot to answer the 2nd paragraph in my last reply. Sticking to > Kconfig was actually intentional to make it easy for us to stay in sync > with upstream development of Kconfig. How would a difference in names significantly hamper that? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof
>>> On 06.10.15 at 19:25, wrote: > On 05/10/15 11:31, Jan Beulich wrote: > On 04.10.15 at 21:24, wrote: >>> The keyword typeof is not portable: >>> >>> /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration >>> of function 'typeof' is invalid in C99 >>> [-Werror,-Wimplicit-function-declaration] >> >> Actually, it's worse than that - typeof() is a gcc extension, and we >> shouldn't use extensions in public headers without at least having >> alternative code for not gcc compatible compilers in place. In fact >> we should probably aim at removing the exclusion of public/arch-% >> in the ANSI conformance check; IIRC I had to add it because things >> wouldn't build without, but with the (then forgotten) goal of dealing >> with this properly later on. > > I don't see how header.chk would have catch my issue. The problem is in > the macro set_xen_guest_handle_raw which is not used within the headers > (except by set_xen_guest_handle which is not used at all). > > It may be worth to add a dummy .c which call the macros to check they > are ANSI compliant. Hmm, true, conformance of macros isn't being checked right now (i.e. we only verify that the header as such compiles, not that everything in the header can be used). A manually created source would help only to some degree, as it would need to be kept up to date with future additions. I.e. the long term solution probably ought to be an at least partially machine generated source file. I added this to my todo list (but towards the end of it). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: Tamás Lengyel to maintain mem-sharing
On Wed, Oct 7, 2015 at 2:24 AM, Jan Beulich wrote: > The component being unmaintained right now and him being the apparently > only user at present, this certainly is an improvement over the current > situation. > > Signed-off-by: Jan Beulich > Acked-by: Tamas K Lengyel > > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -369,10 +369,14 @@ > S: Supported > F: xen/arch/x86/mm/ > > -X86 MEMORY SHARING AND PAGING > +X86 MEMORY PAGING > S: Orphaned > -F: xen/arch/x86/mm/mem_sharing.c > F: xen/arch/x86/mm/mem_paging.c > + > +X86 MEMORY SHARING > +M: Tamas K Lengyel > +S: Odd Fixes > +F: xen/arch/x86/mm/mem_sharing.c > F: tools/memshr > > X86 SHADOW PAGETABLES > > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] MAINTAINERS: Tamás Lengyel to maintain mem-sharing
The component being unmaintained right now and him being the apparently only user at present, this certainly is an improvement over the current situation. Signed-off-by: Jan Beulich --- a/MAINTAINERS +++ b/MAINTAINERS @@ -369,10 +369,14 @@ S: Supported F: xen/arch/x86/mm/ -X86 MEMORY SHARING AND PAGING +X86 MEMORY PAGING S: Orphaned -F: xen/arch/x86/mm/mem_sharing.c F: xen/arch/x86/mm/mem_paging.c + +X86 MEMORY SHARING +M: Tamas K Lengyel +S: Odd Fixes +F: xen/arch/x86/mm/mem_sharing.c F: tools/memshr X86 SHADOW PAGETABLES ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-mingo-tip-master test] 62679: regressions - FAIL
flight 62679 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/62679/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail in 62645 REGR. vs. 60684 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail in 62645 pass in 62679 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail pass in 62645 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 62645 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass version targeted for testing: linux77880efd8affe3966a5da5fbc01c05f0d7ab7df5 baseline version: linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0 Last test of basis60684 2015-08-13 04:21:46 Z 55 days Failing since 60712 2015-08-15 18:33:48 Z 52 days 25 attempts Testing same since62645 2015-10-03 19:42:52 Z3 days2 attempts jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-amd64-i386-xl-xsm pass 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-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 p
[Xen-devel] how to use xentrace_format correctly
Hi, I am not sure how to use xentrace_format given that I have a trace file. Can someone gave me an example def file and the correct commands?? Thank you! ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] how to trace scheduling overheads using xentrace/xenalyze
Hi,
I am new to xen environment and I am wondering how to trace scheduling
overhead of guest vm using xentrace/xenalyze ?
I have tried using $xentrace -D -e all -S 256 {filename}
and then use various xenalyze options but most of them gave me empty
result, and I dont really see where I can get scheduling overhead so I can
see how are the jobs are scheduled and its execution time and stuff. Please
point me to a direction. Thank you!
Victor
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On Tue, Oct 06, 2015 at 12:18:50PM +0100, Wei Liu wrote: > On Tue, Oct 06, 2015 at 12:46:08PM +0200, Juergen Gross wrote: > > Remove lots of functions in tools/python/xen/lowlevel/xc/xc.c as they > > are not used anywhere in the tree. In fact only one function is still > > being used from pygrub, namely "xeninfo". All other users seem to have > > gone with nuking xm/xend. > > > > Signed-off-by: Juergen Gross > > Andrew said the python module is useful for debugging purpose. There are > out-of-tree users as well. > > I'm not too fussed about either keeping these functions or removing > them. But I would like to leave some time for other people to object. In QubesOS we use xc bindings. In the most recent version only for memory managing (domain_set_target_mem, domain_setmaxmem, domain_getinfo, physinfo). https://github.com/QubesOS/qubes-core-admin/blob/master/qmemman/qmemman.py This is used for real-time memory adjustment based on domain needs (think: give domain more memory when needed, before it start swapping), so directly manipulating with xc/xs is preferred over much slower alternatives like libvirt. Libxl would be probably enough, but libxl python bindings effectively doesn't exists. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? pgpstwR9jX9Pt.pgp Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] linux-next: manual merge of the xen-tip tree with Linus' tree
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/xen/p2m.c
between commit:
98dd166ea3a3 ("x86/xen/p2m: hint at the last populated P2M entry")
from Linus' tree and commit:
c5fdd42b47ab ("x86/xen: export xen_alloc_p2m_entry()")
from the xen-tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/xen/p2m.c
index 660b3cfef234,4ea676a49b6b..
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@@ -619,14 -611,9 +622,15 @@@ int xen_alloc_p2m_entry(unsigned long p
free_p2m_page(p2m);
}
+ /* Expanded the p2m? */
+ if (pfn > xen_p2m_last_pfn) {
+ xen_p2m_last_pfn = pfn;
+ HYPERVISOR_shared_info->arch.max_pfn = xen_p2m_last_pfn;
+ }
+
- return true;
+ return 0;
}
+ EXPORT_SYMBOL(xen_alloc_p2m_entry);
unsigned long __init set_phys_range_identity(unsigned long pfn_s,
unsigned long pfn_e)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing test] 62677: tolerable FAIL - PUSHED
flight 62677 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/62677/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start.2 fail REGR. vs. 62603 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail like 62603 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 62603 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-xl-qcow2 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-xl-raw 9 debian-di-installfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass version targeted for testing: xen b24ad7ba911a9f0688ab179736476e44c52144f1 baseline version: xen a15b47f4ce37c3ff0ea6d68418fbb88517fcdb9c Last test of basis62603 2015-10-01 18:21:13 Z5 days Testing same since62677 2015-10-05 14:44:46 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Dario Faggioli Ian Jackson Jan Beulich Ross Lagerwall 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
[Xen-devel] [xen-unstable-smoke test] 62705: tolerable all pass - PUSHED
flight 62705 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62705/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen a23ce429779011de127e8ff6c9bf3486d87154d5
baseline version:
xen 375a410b24d9fb7058fc7a3fe101189fe737c08b
Last test of basis62704 2015-10-06 16:53:49 Z0 days
Testing same since62705 2015-10-06 19:54:05 Z0 days1 attempts
People who touched revisions under test:
Daniel De Graaf
Konrad Rzeszutek Wilk
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=a23ce429779011de127e8ff6c9bf3486d87154d5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
a23ce429779011de127e8ff6c9bf3486d87154d5
+ branch=xen-unstable-smoke
+ revision=a23ce429779011de127e8ff6c9bf3486d87154d5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ : tested/2.6.39.x
+ . ./ap-common
++ xenbranch_forqemu=xen-unstable
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https:
[Xen-devel] [linux-arm-xen test] 62674: tolerable trouble: broken/fail/pass - PUSHED
flight 62674 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62674/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-raw 3 host-install(3) broken never pass
test-armhf-armhf-xl-qcow2 9 debian-di-installfail never pass
test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass
test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass
test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass
test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
version targeted for testing:
linux9550fff2bd1f88405dd61d86e90807046a580d6c
baseline version:
linux64972ceb0b0cafc91a09764bc731e1b7f0503b5c
Last test of basis58875 2015-06-24 06:26:26 Z 104 days
Testing same since62674 2015-10-05 12:24:43 Z1 days1 attempts
People who touched revisions under test:
Charles Keepax
David S. Miller
Michel Stam
Riku Voipio
jobs:
build-armhf-xsm pass
build-armhf pass
build-armhf-libvirt pass
build-armhf-pvopspass
test-armhf-armhf-xl pass
test-armhf-armhf-libvirt-xsm fail
test-armhf-armhf-xl-xsm pass
test-armhf-armhf-xl-arndale pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-armhf-armhf-libvirt fail
test-armhf-armhf-xl-multivcpupass
test-armhf-armhf-libvirt-qcow2 fail
test-armhf-armhf-xl-qcow2fail
test-armhf-armhf-libvirt-raw fail
test-armhf-armhf-xl-raw broken
test-armhf-armhf-xl-rtds fail
test-armhf-armhf-libvirt-vhd fail
test-armhf-armhf-xl-vhd fail
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-step test-armhf-armhf-xl-raw host-install(3)
Pushing revision :
+ branch=linux-arm-xen
+ revision=9550fff2bd1f88405dd61d86e90807046a580d6c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos
[Xen-devel] [linux-next test] 62673: tolerable FAIL
flight 62673 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/62673/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 15 guest-start.2 fail pass in 62630 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-raw 6 xen-boot fail REGR. vs. 62544 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 62544 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 62544 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 62630 REGR. vs. 62544 test-armhf-armhf-xl-cubietruck 6 xen-boot fail like 62544 test-armhf-armhf-xl-xsm 6 xen-boot fail like 62544 test-armhf-armhf-xl 6 xen-boot fail like 62544 test-armhf-armhf-xl-credit2 6 xen-boot fail like 62544 test-armhf-armhf-xl-multivcpu 6 xen-boot fail like 62544 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail like 62544 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62544 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 62544 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 62544 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-raw 9 debian-di-installfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-xl-qcow2 9 debian-di-installfail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass version targeted for testing: linuxdad463bdcbb41dfd17c799a5653bb57f185f2c76 baseline version: linux3225031fbeb1e32b269a82eccd815128267a4bfe Last test of basis (not found) Failing since 0 1970-01-01 00:00:00 Z 16714 days Testing same since62630 2015-10-02 22:46:42 Z3 days2 attempts jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl
[Xen-devel] [PATCH] x86/p2m: fix typo "populete"
Signed-off-by: Wei Liu --- xen/arch/x86/mm/p2m.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 09144e0..1178832 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1287,7 +1287,7 @@ void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn, } /** - * p2m_mem_paging_populate - Tell pager to populete a paged page + * p2m_mem_paging_populate - Tell pager to populate a paged page * @d: guest domain * @gfn: guest page in paging state * -- 2.5.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools/python: remove broken xl binding
On Tue, Oct 06, 2015 at 06:13:04PM +0100, Andrew Cooper wrote: > On 06/10/15 17:57, Wei Liu wrote: > > Various people say this binding doesn't compile or doesn't work. Remove > > it for the benefit of xl feature development -- so that new features > > won't need to worry about making this broken binding happy. > > > > This isn't going to expose any user visible changes because that module > > is not built by default. > > > > Signed-off-by: Wei Liu > > Reviewed-by: Andrew Cooper And Zhigang mentioned to me offline that he is OK with these being gone too. RIP python.. > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 62704: tolerable all pass - PUSHED
flight 62704 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62704/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 375a410b24d9fb7058fc7a3fe101189fe737c08b
baseline version:
xen 8db8887de6f53212e494e08c905d1d672081a01d
Last test of basis62680 2015-10-05 16:53:35 Z1 days
Testing same since62704 2015-10-06 16:53:49 Z0 days1 attempts
People who touched revisions under test:
Doug Goldstein
Roger Pau Monné
Wei Wang
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=375a410b24d9fb7058fc7a3fe101189fe737c08b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
375a410b24d9fb7058fc7a3fe101189fe737c08b
+ branch=xen-unstable-smoke
+ revision=375a410b24d9fb7058fc7a3fe101189fe737c08b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ : tested/2.6.39.x
+ . ./ap-common
++ xenbranch_forqemu=xen-unstable
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpk
Re: [Xen-devel] [PATCH] tools/python: remove broken xl binding
On Tue, Oct 06, 2015 at 02:06:57PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 06, 2015 at 05:57:26PM +0100, Wei Liu wrote:
> > Various people say this binding doesn't compile or doesn't work. Remove
> > it for the benefit of xl feature development -- so that new features
> > won't need to worry about making this broken binding happy.
> >
> > This isn't going to expose any user visible changes because that module
> > is not built by default.
> >
> > Signed-off-by: Wei Liu
>
> CC-ing Zhigang.
Actually doing it.
>
> > ---
> > tools/python/setup.py | 9 -
> > tools/python/xen/lowlevel/xl/xl.c | 797
> > --
> > 2 files changed, 806 deletions(-)
> > delete mode 100644 tools/python/xen/lowlevel/xl/xl.c
> >
> > diff --git a/tools/python/setup.py b/tools/python/setup.py
> > index 5bf81be..fdba866 100644
> > --- a/tools/python/setup.py
> > +++ b/tools/python/setup.py
> > @@ -27,17 +27,8 @@ xs = Extension("xs",
> > depends= [ PATH_XENSTORE + "/libxenstore.so" ],
> > sources= [ "xen/lowlevel/xs/xs.c" ])
> >
> > -xl = Extension("xl",
> > - extra_compile_args = extra_compile_args,
> > - include_dirs = [ PATH_XEN, PATH_LIBXL, PATH_LIBXC +
> > "/include", "xen/lowlevel/xl" ],
> > - library_dirs = [ PATH_LIBXL ],
> > - libraries = [ "xenlight" ],
> > - depends= [ PATH_LIBXL + "/libxenlight.so" ],
> > - sources= [ "xen/lowlevel/xl/xl.c",
> > "xen/lowlevel/xl/_pyxl_types.c" ])
> > -
> > plat = os.uname()[0]
> > modules = [ xc, xs ]
> > -#modules.extend([ xl ])
> >
> > setup(name= 'xen',
> >version = '3.0',
> > diff --git a/tools/python/xen/lowlevel/xl/xl.c
> > b/tools/python/xen/lowlevel/xl/xl.c
> > deleted file mode 100644
> > index 9b33731..000
> > --- a/tools/python/xen/lowlevel/xl/xl.c
> > +++ /dev/null
> > @@ -1,797 +0,0 @@
> > -/**
> > - * xl.c
> > - *
> > - * Copyright (c) 2010 Citrix Ltd.
> > - * Author: Gianni Tedesco
> > - *
> > - * This library is free software; you can redistribute it and/or
> > - * modify it under the terms of version 2.1 of the GNU Lesser General
> > Public
> > - * License as published by the Free Software Foundation.
> > - *
> > - * This library is distributed in the hope that it will be useful,
> > - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > - * Lesser General Public License for more details.
> > - *
> > - * You should have received a copy of the GNU Lesser General Public
> > - * License along with this library; If not, see
> >
Re: [Xen-devel] [PATCH] tools/python: remove broken xl binding
On Tue, Oct 06, 2015 at 05:57:26PM +0100, Wei Liu wrote:
> Various people say this binding doesn't compile or doesn't work. Remove
> it for the benefit of xl feature development -- so that new features
> won't need to worry about making this broken binding happy.
>
> This isn't going to expose any user visible changes because that module
> is not built by default.
>
> Signed-off-by: Wei Liu
CC-ing Zhigang.
> ---
> tools/python/setup.py | 9 -
> tools/python/xen/lowlevel/xl/xl.c | 797
> --
> 2 files changed, 806 deletions(-)
> delete mode 100644 tools/python/xen/lowlevel/xl/xl.c
>
> diff --git a/tools/python/setup.py b/tools/python/setup.py
> index 5bf81be..fdba866 100644
> --- a/tools/python/setup.py
> +++ b/tools/python/setup.py
> @@ -27,17 +27,8 @@ xs = Extension("xs",
> depends= [ PATH_XENSTORE + "/libxenstore.so" ],
> sources= [ "xen/lowlevel/xs/xs.c" ])
>
> -xl = Extension("xl",
> - extra_compile_args = extra_compile_args,
> - include_dirs = [ PATH_XEN, PATH_LIBXL, PATH_LIBXC +
> "/include", "xen/lowlevel/xl" ],
> - library_dirs = [ PATH_LIBXL ],
> - libraries = [ "xenlight" ],
> - depends= [ PATH_LIBXL + "/libxenlight.so" ],
> - sources= [ "xen/lowlevel/xl/xl.c",
> "xen/lowlevel/xl/_pyxl_types.c" ])
> -
> plat = os.uname()[0]
> modules = [ xc, xs ]
> -#modules.extend([ xl ])
>
> setup(name= 'xen',
>version = '3.0',
> diff --git a/tools/python/xen/lowlevel/xl/xl.c
> b/tools/python/xen/lowlevel/xl/xl.c
> deleted file mode 100644
> index 9b33731..000
> --- a/tools/python/xen/lowlevel/xl/xl.c
> +++ /dev/null
> @@ -1,797 +0,0 @@
> -/**
> - * xl.c
> - *
> - * Copyright (c) 2010 Citrix Ltd.
> - * Author: Gianni Tedesco
> - *
> - * This library is free software; you can redistribute it and/or
> - * modify it under the terms of version 2.1 of the GNU Lesser General Public
> - * License as published by the Free Software Foundation.
> - *
> - * This library is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> - * Lesser General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public
> - * License along with this library; If not, see
>
Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof
Hi Jan, On 05/10/15 11:31, Jan Beulich wrote: On 04.10.15 at 21:24, wrote: >> The keyword typeof is not portable: >> >> /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration >> of function 'typeof' is invalid in C99 >> [-Werror,-Wimplicit-function-declaration] > > Actually, it's worse than that - typeof() is a gcc extension, and we > shouldn't use extensions in public headers without at least having > alternative code for not gcc compatible compilers in place. In fact > we should probably aim at removing the exclusion of public/arch-% > in the ANSI conformance check; IIRC I had to add it because things > wouldn't build without, but with the (then forgotten) goal of dealing > with this properly later on. I don't see how header.chk would have catch my issue. The problem is in the macro set_xen_guest_handle_raw which is not used within the headers (except by set_xen_guest_handle which is not used at all). It may be worth to add a dummy .c which call the macros to check they are ANSI compliant. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools/python: remove broken xl binding
On 06/10/15 17:57, Wei Liu wrote: > Various people say this binding doesn't compile or doesn't work. Remove > it for the benefit of xl feature development -- so that new features > won't need to worry about making this broken binding happy. > > This isn't going to expose any user visible changes because that module > is not built by default. > > Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] Add Libc multiarch package as build prerequisites on 64-bit platforms to the README
When building on 64-bit platforms this prevents build errors for 32-bit components which are enabled on a default build. Signed-off-by: Sander Eikelenboom --- README | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README b/README index a7d0033..1324c7c 100644 --- a/README +++ b/README @@ -56,6 +56,9 @@ provided by your OS distributor: * GNU gettext * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs) * ACPI ASL compiler (iasl) +* Libc multiarch package (e.g. libc6-dev-i386 / glibc-devel.i686). + Required when building on a 64-bit platform to build + 32-bit components which are enabled on a default build. In addition to the above there are a number of optional build prerequisites. Omitting these will cause the related features to be -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] tools/python: remove broken xl binding
Various people say this binding doesn't compile or doesn't work. Remove
it for the benefit of xl feature development -- so that new features
won't need to worry about making this broken binding happy.
This isn't going to expose any user visible changes because that module
is not built by default.
Signed-off-by: Wei Liu
---
tools/python/setup.py | 9 -
tools/python/xen/lowlevel/xl/xl.c | 797 --
2 files changed, 806 deletions(-)
delete mode 100644 tools/python/xen/lowlevel/xl/xl.c
diff --git a/tools/python/setup.py b/tools/python/setup.py
index 5bf81be..fdba866 100644
--- a/tools/python/setup.py
+++ b/tools/python/setup.py
@@ -27,17 +27,8 @@ xs = Extension("xs",
depends= [ PATH_XENSTORE + "/libxenstore.so" ],
sources= [ "xen/lowlevel/xs/xs.c" ])
-xl = Extension("xl",
- extra_compile_args = extra_compile_args,
- include_dirs = [ PATH_XEN, PATH_LIBXL, PATH_LIBXC +
"/include", "xen/lowlevel/xl" ],
- library_dirs = [ PATH_LIBXL ],
- libraries = [ "xenlight" ],
- depends= [ PATH_LIBXL + "/libxenlight.so" ],
- sources= [ "xen/lowlevel/xl/xl.c",
"xen/lowlevel/xl/_pyxl_types.c" ])
-
plat = os.uname()[0]
modules = [ xc, xs ]
-#modules.extend([ xl ])
setup(name= 'xen',
version = '3.0',
diff --git a/tools/python/xen/lowlevel/xl/xl.c
b/tools/python/xen/lowlevel/xl/xl.c
deleted file mode 100644
index 9b33731..000
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ /dev/null
@@ -1,797 +0,0 @@
-/**
- * xl.c
- *
- * Copyright (c) 2010 Citrix Ltd.
- * Author: Gianni Tedesco
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of version 2.1 of the GNU Lesser General Public
- * License as published by the Free Software Foundation.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; If not, see
Re: [Xen-devel] [PATCH V7 6/7] xl: add usb-assignable-list command
On 25/09/15 03:11, Chunyan Liu wrote:
> Add xl usb-assignable-list command to list assignable USB devices.
> Assignable USB device means the USB device type is assignable and
> it's not assigned to any guest yet.
>
> Signed-off-by: Chunyan Liu
>
> ---
> Same as "libxl: add libxl_device_usb_assignable_list API" patch,
> this patch could be sqaushed to previous one. Split because of
> some dispute. Could be squashed if acceptable, otherwise could
> be removed.
I think it's worth pointing out to other reviewers that the
"usb-assignable-list" command introduced here:
1. Has identical behavior to "xm usb-assignable-list", but
2. Has different behavior than "xl pci-assignable-list".
Namely:
xl pci-assignable-list will list PCI devices which have been detached
from their normal driver and have been assigned to pciback (in
preparation for being attached to a domain).
This command will list all USB devices in dom0 that are not assigned to VMs.
Juergen and I had a long back-and-forth about it around v3. I thought
having slightly different semantics might be confusing, and Juergen
thought the functionality was important to include. We didn't really
come to a conclusion and none of the tools maintainers expressed an opinion.
I don't feel like arguing about it anymore, so I won't oppose the
naming; but I think whoever gives final approval should at least be
aware of the slight functional difference between {pci,usb}-assignable-list.
Other than that, the patch looks good to me.
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 02/29] build: trim down Linux bits
On Tue, 2015-10-06 at 11:42 -0500, Doug Goldstein wrote: > On 10/6/15 11:15 AM, Ian Campbell wrote: > > On Tue, 2015-10-06 at 11:02 -0500, Doug Goldstein wrote: > > > On 10/6/15 7:42 AM, Jan Beulich wrote: > > > > > > > On 06.10.15 at 00:03, wrote: > > > > > > > > Changes like this should be explained: > > > > > > > > > Signed-off-by: Doug Goldstein > > > > > --- > > > > > xen/scripts/basic/.gitignore | 1 - > > > > > xen/scripts/basic/Makefile | 1 - > > > > > 2 files changed, 2 deletions(-) > > > > > > > > > > diff --git a/xen/scripts/basic/.gitignore > > > > > b/xen/scripts/basic/.gitignore > > > > > index 9528ec9..a776371 100644 > > > > > --- a/xen/scripts/basic/.gitignore > > > > > +++ b/xen/scripts/basic/.gitignore > > > > > @@ -1,2 +1 @@ > > > > > fixdep > > > > > -bin2c > > > > > diff --git a/xen/scripts/basic/Makefile > > > > > b/xen/scripts/basic/Makefile > > > > > index ec10d93..4fcef87 100644 > > > > > --- a/xen/scripts/basic/Makefile > > > > > +++ b/xen/scripts/basic/Makefile > > > > > @@ -9,7 +9,6 @@ > > > > > # fixdep: Used to generate dependency information > > > > > during > > > > > build process > > > > > > > > > > hostprogs-y := fixdep > > > > > -hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c > > > > > > > > Why does Linux need this but we don't? > > > > > > > > Jan > > > > > > > > > > Its for building firmware into the kernel. It converts a blob/binary > > > to > > > a C-style header which can be included into the code. One of the many > > > things in their scripts directory that we won't need for Kconfig > > > support. > > > > ISTR there was a fork of Kconfig maintained for easy inclusion into > > other > > projects. I can't find it though, the closest I got was > > https://github.com/lacombar/kconfig/ which is clearly not the answer > > (not > > touched for 5yrs). > > > > Ian. > > > > I think this is the project? > > [... snip URL nangled by our stupid spam gateway...] Yes, that's the one, I think. > For some reason I couldn't find it when I started out on this originally > and planned on replacing the first few patches with that. But looking at > it now, it appears abandoned. Yeah, it doesn't look like a good option now. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On Tue, 2015-10-06 at 17:31 +0100, Wei Liu wrote: > On Tue, Oct 06, 2015 at 04:38:08PM +0100, Andrew Cooper wrote: > > On 06/10/15 16:26, Ian Campbell wrote: > > > On Tue, 2015-10-06 at 17:21 +0200, Juergen Gross wrote: > > > > On 10/06/2015 05:11 PM, Ian Campbell wrote: > > > > > On Tue, 2015-10-06 at 16:51 +0200, Juergen Gross wrote: > > > > > > On 10/06/2015 03:40 PM, Ian Campbell wrote: > > > > > > > On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: > > > > > > > > > > > > > > > And for the record, if my google-fu doesn't fail me, it's > > > > > > > > possible to > > > > > > > > load shared library into python interpreter using "dl" > > > > > > > > module in > > > > > > > > 2.7 > > > > > > > > and > > > > > > > > "ctypes" module in 3.x. > > > > > > > Possible, but not especially convenient since you need to > > > > > > > convert > > > > > > > the C > > > > > > > prototype manually, plus the result is not necessarily very > > > > > > > "pythonic". > > > > > > > > > > > > > > I could totally see why people would prefer these bindings > > > > > > > (or an > > > > > > > argument > > > > > > > for us providing a ctypes based wrapper). > > > > > > How often is such a debugging interface being used? Please > > > > > > consider > > > > > > the amount of code (my patch removed nearly 3000 lines of > > > > > > code!) and > > > > > > the availability of the xl wrapper. > > > > > My understanding was that this was used by the "xen-bugtool" > > > > > stuff in > > > > > XenServer, so for actual functionality (gathering debug info) and > > > > > not > > > > > debugging (I supposed that the reference to being used for > > > > > debugging was > > > > > due to the name of the tool). > > > > And this functionality isn't available via the xl bindings? > > > I don't know, we'll have to wait for those who are using it to chime > > > in. > > > > The python xl bindings? They don't even compile. > > Urgh. It does compile for me. Are you talking about tools/python/xen/lowlevel/xl/? Because that seems unlikely. In any case they certain don't work, they have a model for updating the C versions of the data structures in sync with the python code, as opposed to marshalling in and out around the libxl calls like the other language bindings do, which is IIRC broken wrt at least nested structures and keyed unions IIRC (and probably other stuff now). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 01/29] build: import Kbuild/Kconfig from Linux 4.2
On 10/6/15 7:45 AM, Jan Beulich wrote: On 06.10.15 at 00:03, wrote: >> Brings in the Kbuild/Kconfig plumbing from the Linux 4.2 release. >> >> Signed-off-by: Doug Goldstein >> --- >> xen/Makefile.linux | 1596 +++ >> xen/include/linux/kconfig.h| 54 + >> xen/scripts/Kbuild.include | 305 +++ >> xen/scripts/Makefile | 42 + >> xen/scripts/Makefile.asm-generic | 23 + >> xen/scripts/Makefile.build | 427 >> xen/scripts/Makefile.clean | 91 + >> xen/scripts/Makefile.extrawarn | 68 + >> xen/scripts/Makefile.help |3 + >> xen/scripts/Makefile.host | 128 ++ >> xen/scripts/Makefile.kasan | 29 + >> xen/scripts/Makefile.lib | 390 >> xen/scripts/Makefile.modpost | 152 ++ >> xen/scripts/basic/.gitignore |2 + >> xen/scripts/basic/Makefile | 16 + >> xen/scripts/basic/fixdep.c | 462 + >> xen/scripts/gcc-goto.sh| 21 + >> xen/scripts/kconfig/.gitignore | 22 + >> xen/scripts/kconfig/Makefile | 317 +++ >> xen/scripts/kconfig/POTFILES.in| 12 + >> xen/scripts/kconfig/check.sh | 13 + >> xen/scripts/kconfig/conf.c | 722 +++ >> xen/scripts/kconfig/confdata.c | 1248 >> xen/scripts/kconfig/expr.c | 1206 +++ >> xen/scripts/kconfig/expr.h | 238 +++ >> xen/scripts/kconfig/gconf.c| 1521 ++ >> xen/scripts/kconfig/gconf.glade| 661 ++ >> xen/scripts/kconfig/images.c | 326 +++ >> xen/scripts/kconfig/kxgettext.c| 235 +++ >> xen/scripts/kconfig/list.h | 131 ++ >> xen/scripts/kconfig/lkc.h | 186 ++ >> xen/scripts/kconfig/lkc_proto.h| 52 + >> xen/scripts/kconfig/lxdialog/.gitignore|4 + >> xen/scripts/kconfig/lxdialog/BIG.FAT.WARNING |4 + >> xen/scripts/kconfig/lxdialog/check-lxdialog.sh | 91 + >> xen/scripts/kconfig/lxdialog/checklist.c | 332 +++ >> xen/scripts/kconfig/lxdialog/dialog.h | 257 +++ >> xen/scripts/kconfig/lxdialog/inputbox.c| 301 +++ >> xen/scripts/kconfig/lxdialog/menubox.c | 437 >> xen/scripts/kconfig/lxdialog/textbox.c | 408 >> xen/scripts/kconfig/lxdialog/util.c| 713 +++ >> xen/scripts/kconfig/lxdialog/yesno.c | 114 ++ >> xen/scripts/kconfig/mconf.c| 1047 ++ >> xen/scripts/kconfig/menu.c | 697 +++ >> xen/scripts/kconfig/merge_config.sh| 158 ++ >> xen/scripts/kconfig/nconf.c| 1561 ++ >> xen/scripts/kconfig/nconf.gui.c| 656 ++ >> xen/scripts/kconfig/nconf.h| 96 + >> xen/scripts/kconfig/qconf.cc | 1798 + >> xen/scripts/kconfig/qconf.h| 338 > > Do we really need all the ?conf.[ch]* in Xen? Wouldn't the simple > non-GUI thing suffice for our needs? > > Also, btw - I don't think we should name the thing Kconfig in Xen; > Xconfig would be odd too (to be confused with X), so maybe > XenConfig? > > Jan > I forgot to answer the 2nd paragraph in my last reply. Sticking to Kconfig was actually intentional to make it easy for us to stay in sync with upstream development of Kconfig. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] gitingore: ignore extras/mini-os*
The original pattern doesn't handle mini-os-dir-remote. Signed-off-by: Wei Liu --- .gitignore | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 9ead7c4..91e1430 100644 --- a/.gitignore +++ b/.gitignore @@ -46,8 +46,7 @@ docs/man5/ docs/man8/ docs/pdf/ docs/txt/ -extras/mini-os -extras/mini-os-remote +extras/mini-os* install/* stubdom/autom4te.cache/ stubdom/binutils-* -- 2.5.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 02/29] build: trim down Linux bits
On 10/6/15 11:15 AM, Ian Campbell wrote: > On Tue, 2015-10-06 at 11:02 -0500, Doug Goldstein wrote: >> On 10/6/15 7:42 AM, Jan Beulich wrote: >> On 06.10.15 at 00:03, wrote: >>> >>> Changes like this should be explained: >>> Signed-off-by: Doug Goldstein --- xen/scripts/basic/.gitignore | 1 - xen/scripts/basic/Makefile | 1 - 2 files changed, 2 deletions(-) diff --git a/xen/scripts/basic/.gitignore b/xen/scripts/basic/.gitignore index 9528ec9..a776371 100644 --- a/xen/scripts/basic/.gitignore +++ b/xen/scripts/basic/.gitignore @@ -1,2 +1 @@ fixdep -bin2c diff --git a/xen/scripts/basic/Makefile b/xen/scripts/basic/Makefile index ec10d93..4fcef87 100644 --- a/xen/scripts/basic/Makefile +++ b/xen/scripts/basic/Makefile @@ -9,7 +9,6 @@ # fixdep: Used to generate dependency information during build process hostprogs-y := fixdep -hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c >>> >>> Why does Linux need this but we don't? >>> >>> Jan >>> >> >> Its for building firmware into the kernel. It converts a blob/binary to >> a C-style header which can be included into the code. One of the many >> things in their scripts directory that we won't need for Kconfig support. > > ISTR there was a fork of Kconfig maintained for easy inclusion into other > projects. I can't find it though, the closest I got was > https://github.com/lacombar/kconfig/ which is clearly not the answer (not > touched for 5yrs). > > Ian. > I think this is the project? http://ymorin.is-a-geek.org/projects/kconfig-frontends For some reason I couldn't find it when I started out on this originally and planned on replacing the first few patches with that. But looking at it now, it appears abandoned. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On Tue, Oct 06, 2015 at 05:38:42PM +0100, Ian Campbell wrote: > On Tue, 2015-10-06 at 17:31 +0100, Wei Liu wrote: > > On Tue, Oct 06, 2015 at 04:38:08PM +0100, Andrew Cooper wrote: > > > On 06/10/15 16:26, Ian Campbell wrote: > > > > On Tue, 2015-10-06 at 17:21 +0200, Juergen Gross wrote: > > > > > On 10/06/2015 05:11 PM, Ian Campbell wrote: > > > > > > On Tue, 2015-10-06 at 16:51 +0200, Juergen Gross wrote: > > > > > > > On 10/06/2015 03:40 PM, Ian Campbell wrote: > > > > > > > > On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: > > > > > > > > > > > > > > > > > And for the record, if my google-fu doesn't fail me, it's > > > > > > > > > possible to > > > > > > > > > load shared library into python interpreter using "dl" > > > > > > > > > module in > > > > > > > > > 2.7 > > > > > > > > > and > > > > > > > > > "ctypes" module in 3.x. > > > > > > > > Possible, but not especially convenient since you need to > > > > > > > > convert > > > > > > > > the C > > > > > > > > prototype manually, plus the result is not necessarily very > > > > > > > > "pythonic". > > > > > > > > > > > > > > > > I could totally see why people would prefer these bindings > > > > > > > > (or an > > > > > > > > argument > > > > > > > > for us providing a ctypes based wrapper). > > > > > > > How often is such a debugging interface being used? Please > > > > > > > consider > > > > > > > the amount of code (my patch removed nearly 3000 lines of > > > > > > > code!) and > > > > > > > the availability of the xl wrapper. > > > > > > My understanding was that this was used by the "xen-bugtool" > > > > > > stuff in > > > > > > XenServer, so for actual functionality (gathering debug info) and > > > > > > not > > > > > > debugging (I supposed that the reference to being used for > > > > > > debugging was > > > > > > due to the name of the tool). > > > > > And this functionality isn't available via the xl bindings? > > > > I don't know, we'll have to wait for those who are using it to chime > > > > in. > > > > > > The python xl bindings? They don't even compile. > > > > Urgh. It does compile for me. > > Are you talking about tools/python/xen/lowlevel/xl/? Because that seems > unlikely. > Yes. That one. It successfully built a xl.so, along with xs.so and xc.so. weil@zion:/local/scratch/xen.git$ file tools/python/build/lib.linux-x86_64-2.7/xen/lowlevel/xl.so tools/python/build/lib.linux-x86_64-2.7/xen/lowlevel/xl.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=e164a1e0f97a1c92fa10ef7b4b7b5918abacbec5, not stripped TBH I have no idea why. I don't particularly care about this thing either, just want to make sure we're on the same page talking about the same thing. > In any case they certain don't work, they have a model for updating the C > versions of the data structures in sync with the python code, as opposed to > marshalling in and out around the libxl calls like the other language > bindings do, which is IIRC broken wrt at least nested structures and keyed > unions IIRC (and probably other stuff now). > OK then. I will just send a patch to delete it. Wei. > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On Tue, Oct 06, 2015 at 04:38:08PM +0100, Andrew Cooper wrote: > On 06/10/15 16:26, Ian Campbell wrote: > > On Tue, 2015-10-06 at 17:21 +0200, Juergen Gross wrote: > >> On 10/06/2015 05:11 PM, Ian Campbell wrote: > >>> On Tue, 2015-10-06 at 16:51 +0200, Juergen Gross wrote: > On 10/06/2015 03:40 PM, Ian Campbell wrote: > > On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: > > > >> And for the record, if my google-fu doesn't fail me, it's > >> possible to > >> load shared library into python interpreter using "dl" module in > >> 2.7 > >> and > >> "ctypes" module in 3.x. > > Possible, but not especially convenient since you need to convert > > the C > > prototype manually, plus the result is not necessarily very > > "pythonic". > > > > I could totally see why people would prefer these bindings (or an > > argument > > for us providing a ctypes based wrapper). > How often is such a debugging interface being used? Please consider > the amount of code (my patch removed nearly 3000 lines of code!) and > the availability of the xl wrapper. > >>> My understanding was that this was used by the "xen-bugtool" stuff in > >>> XenServer, so for actual functionality (gathering debug info) and not > >>> debugging (I supposed that the reference to being used for debugging was > >>> due to the name of the tool). > >> And this functionality isn't available via the xl bindings? > > I don't know, we'll have to wait for those who are using it to chime in. > > The python xl bindings? They don't even compile. Urgh. It does compile for me. > > They really should be deleted - anyone wishing to resurrect them can > find them in source history. > But if nobody wants it I don't mind submitting a patch to delete it altogether. Wei. > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: LTS and stable release scheme
On Tue, 2015-10-06 at 17:25 +0100, Wei Liu wrote: > It could be an alias for all maintainers. Making sure a patch contains > CC stable@ is good enough for searching through git log for candidates. Ah yes, I suppose the Linux folks use git log --grep=stable@vger a lot, which does a bunch of the work for certain cases. But beyond that grep-fodder I'm not convinced that the actual alias itself as an email address is going to be any help at all. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: LTS and stable release scheme
On Tue, Oct 06, 2015 at 02:10:05PM +0100, Ian Campbell wrote: > On Tue, 2015-10-06 at 12:07 +0100, Wei Liu wrote: > > 2. What to do with the non-LTS releases? > > > > I think they should still be considered stable releases for some > > time. I'm just not sure for how long they should receive updates. One > > way of looking at them is to use the same concept as Linux -- they > > receive updates until next stable kernel is out. We can tweak this, of > > course. > > FWIW I think reducing the time non-LTS stable releases are supported would > be a reasonable way to offset the extra cost of maintaining the LTS > releases for longer overall. > > > Luckily I do see technical and procedural solution this is issue -- we > > can setup stable@ alias to keep track of requests [5]. With that all > > backport requests embedded in patches won't get lost. Downstream > > consumers can also benefit from this because they then easily know > > which patches are backport candidates. > > It sounds here like you are proposing something more than a simple mail > alias dropping into the relevant maintainer(s) INBOX, i.e. something which > actually tracks the requests and publishes the queue and status etc for the > benefit of both users and the maintainers? I don't have definitive answer in mind. It could be an alias for all maintainers. Making sure a patch contains CC stable@ is good enough for searching through git log for candidates. It could be a public mailing list that stable tree maintainers and interested downstream users subscribe to. The system you mentioned is a bit overly complicated as a starter. Let's start with something simple. Wei. > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On Tue, 2015-10-06 at 18:14 +0200, Juergen Gross wrote: > The original motivation was to get rid of the "superpages" option when > building a pv-domU. It's suffered rather from feature creep then, since removing that one interface seems like much less of a problem[0] than a wholesale skewering of bindings of entire librarier or even just cherry-picking the things no one is using and removing those. It's worth trying to clean up these legacy things occasionally and seeing who complains, but when someone does complain its usually time to step back and examine what the actual goal is and what the path to that place is. Unless you have the stomach for helping manage a transition away from the parts of these bindings that people are still using then I'd suggest just leaving it alone and concentrating on the superpages thing and whether that can be removed or what needs to happen first etc. Ian. [0] although we are still waiting for Konrad's reply on that one in the relevant thread. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] tests/mem-sharing: Add bulk option to memshrtool
On Tue, Oct 6, 2015 at 8:15 AM, Ian Campbell wrote: > On Tue, 2015-10-06 at 10:20 +0100, Wei Liu wrote: > > An unrelated note: do you think it make sense to move mem-sharing out of > > tests/ ? It doesn't look like a test to me. > > It was originally a sort of "unit test" / "manually poke it" type utility > rather than end user usable functionality. That might have changed though > (or be in the process of doing so). > > Ian > I'm not intending to make it into a end-user tool either though it could be now actually have some value for end-users doing cloning. For me it's just a reference implementation. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On 10/06/2015 05:45 PM, Ian Campbell wrote: On Tue, 2015-10-06 at 11:30 -0400, Zhigang Wang wrote: On 10/06/2015 11:26 AM, Ian Campbell wrote: On Tue, 2015-10-06 at 17:21 +0200, Juergen Gross wrote: On 10/06/2015 05:11 PM, Ian Campbell wrote: On Tue, 2015-10-06 at 16:51 +0200, Juergen Gross wrote: On 10/06/2015 03:40 PM, Ian Campbell wrote: On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: And for the record, if my google-fu doesn't fail me, it's possible to load shared library into python interpreter using "dl" module in 2.7 and "ctypes" module in 3.x. Possible, but not especially convenient since you need to convert the C prototype manually, plus the result is not necessarily very "pythonic". I could totally see why people would prefer these bindings (or an argument for us providing a ctypes based wrapper). How often is such a debugging interface being used? Please consider the amount of code (my patch removed nearly 3000 lines of code!) and the availability of the xl wrapper. My understanding was that this was used by the "xen-bugtool" stuff in XenServer, so for actual functionality (gathering debug info) and not debugging (I supposed that the reference to being used for debugging was due to the name of the tool). And this functionality isn't available via the xl bindings? I don't know, we'll have to wait for those who are using it to chime in. Ian. IanC: I remember you said xl bindings has some design issue and should not be used. Is it still the case today? Yes. Sorry, I read Juergen's original "via the xl bindings" as "via libxl", i.e. by using the library directly and forgot about the need for python bindings Uuh, too bad. So I should change my patch to remove the xl bindings? ;-) And what about xc bindings? What do I have to keep? Everything for xm and xend? Some bindings for your out-of-tree bugtool (can't this be converted to an in-tree tool written in C dumping out the information which is then post-processed with python) ? The original motivation was to get rid of the "superpages" option when building a pv-domU. If I have to keep xend compatibility I can't remove it. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 02/29] build: trim down Linux bits
On Tue, 2015-10-06 at 11:02 -0500, Doug Goldstein wrote: > On 10/6/15 7:42 AM, Jan Beulich wrote: > > > > > On 06.10.15 at 00:03, wrote: > > > > Changes like this should be explained: > > > > > Signed-off-by: Doug Goldstein > > > --- > > > xen/scripts/basic/.gitignore | 1 - > > > xen/scripts/basic/Makefile | 1 - > > > 2 files changed, 2 deletions(-) > > > > > > diff --git a/xen/scripts/basic/.gitignore > > > b/xen/scripts/basic/.gitignore > > > index 9528ec9..a776371 100644 > > > --- a/xen/scripts/basic/.gitignore > > > +++ b/xen/scripts/basic/.gitignore > > > @@ -1,2 +1 @@ > > > fixdep > > > -bin2c > > > diff --git a/xen/scripts/basic/Makefile b/xen/scripts/basic/Makefile > > > index ec10d93..4fcef87 100644 > > > --- a/xen/scripts/basic/Makefile > > > +++ b/xen/scripts/basic/Makefile > > > @@ -9,7 +9,6 @@ > > > # fixdep: Used to generate dependency information during > > > build process > > > > > > hostprogs-y := fixdep > > > -hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c > > > > Why does Linux need this but we don't? > > > > Jan > > > > Its for building firmware into the kernel. It converts a blob/binary to > a C-style header which can be included into the code. One of the many > things in their scripts directory that we won't need for Kconfig support. ISTR there was a fork of Kconfig maintained for easy inclusion into other projects. I can't find it though, the closest I got was https://github.com/lacombar/kconfig/ which is clearly not the answer (not touched for 5yrs). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: drop unused config variable CONFIG_HVM
>>> On 05.10.15 at 21:15, wrote: > CONFIG_HVM is not used anywhere in the build process so drop it. Now that I committed the patch I spotted where this ought to have been used: This line subdir-$(x86_64) += hvm in xen/common/Makefile. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] Bulk mem-share identical domains
On Tue, Oct 6, 2015 at 8:52 AM, Andrew Cooper wrote: > On 06/10/15 15:26, Ian Campbell wrote: > > On Sun, 2015-10-04 at 14:25 -0600, Tamas K Lengyel wrote: > >> The following patches add a convenience memop to the mem_sharing system, > >> allowing for the rapid deduplication of memory pages between identical > >> domains. > >> > >> The envisioned use-case for this is the following: > >> 1) Create two domains from the same snapshot using xl. > >>This step can also be performed by piping an existing domain's memory > >> with > >> "xl save -c | xl restore -p " > >>It is up for the user to create the appropriate configuration for the > >> clone, > >>including setting up a CoW-disk as well. > >> 2) Enable memory sharing on both domains > >> 3) Execute bulk dedup between the domains. > > This is a neat trick, but has the downside of first shovelling all the > data > > over a pipe and then needing to allocate it transiently before dedupping > it > > again. > > > > Have you looked at the possibility of doing the save+restore in the same > > process with a cut through for the RAM part which just dups the page into > > the target domain? > > > > Once upon a time (migr v1) that would certainly have been impossibly > hard, > > but with migr v2 it might be a lot easier to integrate something like > that > > (although surely not as easy as what you've done here!). > > > > Just an idea, and not intended at all as an argument for not taking this > > series or anything. > > If we are making modifications like this, make something like > XEN_DOMCTL_domain_clone which takes a source domid (must exist), pauses > it, creates a new domain, copies some state and shares all memory CoW > from source to the new domain. > > This will be far more efficient still than moving all the memory through > userspace in dom0. > > ~Andrew > It would be far more efficient, but unfortunately there is more to cloning then just the hypervisor side. Andres already made and suggested using xc_memshr_add_to_physmap, which could be used during domain creation to do something similar. However, 1) there is no reference implementation on how to do that domain creation cleanly 2) cloning HVM domains also requires cloning QEMU. As the only reference implementation on how to create an HVM domain from scratch is in libxl right now, it's a pretty huge task to untangle it to make something like this happen (at least for me). I've been staring at this from time-to-time for the past couple years and I'm still no closer to a working solution. In the interim, this patch at least improves something that I know that works and requires minimal changes to the tools/hypervisor. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 00/29] Incomplete Kconfig conversion
On Tue, 2015-10-06 at 10:58 -0500, Doug Goldstein wrote: > You stated this better than I did. My goal is not to necessarily make > this like the Linux kernel where users toggle on different bits at a > whim but more for developers and companies shipping Xen, basically those > with specialized environments could use this to upstream more code and > have it disabled by default. This last bit will need some care and consideration, since such options are liable to lead to the sort of fragmentation I'm worried about i.e. people thinking they can turn them on outside the specialized environments and be supported in doing so. But I think we can deal with that after this initial transition. It should dovetail quite nicely with the "feature lifecycle" stuff being discussed elsewhere. > The current patchset only exposes KEXEC as a user facing option because > its currently a user facing option in the source tree. I would not > expand the list of user facing options past that. I consider adding more > outside of the scope of this work and something that would happen after > this series lands on a case by case basis. > > My ultimate goal with this initial work is to get all the developer > knobs in one place because currently they are spread around as Makefile > defines or defines in a header file and get a little bit of code > comments around them. Great! Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] Bulk mem-share identical domains
On Tue, Oct 6, 2015 at 8:26 AM, Ian Campbell wrote: > On Sun, 2015-10-04 at 14:25 -0600, Tamas K Lengyel wrote: > > The following patches add a convenience memop to the mem_sharing system, > > allowing for the rapid deduplication of memory pages between identical > > domains. > > > > The envisioned use-case for this is the following: > > 1) Create two domains from the same snapshot using xl. > >This step can also be performed by piping an existing domain's memory > > with > > "xl save -c | xl restore -p " > >It is up for the user to create the appropriate configuration for the > > clone, > >including setting up a CoW-disk as well. > > 2) Enable memory sharing on both domains > > 3) Execute bulk dedup between the domains. > > This is a neat trick, but has the downside of first shovelling all the data > over a pipe and then needing to allocate it transiently before dedupping it > again. > Precisely. > > Have you looked at the possibility of doing the save+restore in the same > process with a cut through for the RAM part which just dups the page into > the target domain? > I have, but I have to stay untangling the internals of xl is pretty daunting.. > > Once upon a time (migr v1) that would certainly have been impossibly hard, > but with migr v2 it might be a lot easier to integrate something like that > (although surely not as easy as what you've done here!). > > Just an idea, and not intended at all as an argument for not taking this > series or anything. > So another trick that works pretty well for PV domains is to simply create them paused: xl create -p This takes pretty much no time and can be followed up by the bulk memory deduplication. The clone is fully functional afterwards. Unfortunately for HVM domains this is not sufficient as QEMU needs to be setup as well, for which right now only xl restore works. I experimented with saving the QEMU state separately, creating the paused HVM domain, killing it's qemu process, then starting a new one with the exact same parameters but with the extra -loadvm flag (reserving an extra page plus trying to wire up the hvmparams). Unfortunately this still crashes the guest after unpause so I'm pretty much stuck on that side. So yea, any help with that would be greatly appreciated ;) If there was an xl option to do what "xl restore" is doing, but to only load the QEMU state, that would be awesome. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 02/29] build: trim down Linux bits
On 10/6/15 7:42 AM, Jan Beulich wrote: On 06.10.15 at 00:03, wrote: > > Changes like this should be explained: > >> Signed-off-by: Doug Goldstein >> --- >> xen/scripts/basic/.gitignore | 1 - >> xen/scripts/basic/Makefile | 1 - >> 2 files changed, 2 deletions(-) >> >> diff --git a/xen/scripts/basic/.gitignore b/xen/scripts/basic/.gitignore >> index 9528ec9..a776371 100644 >> --- a/xen/scripts/basic/.gitignore >> +++ b/xen/scripts/basic/.gitignore >> @@ -1,2 +1 @@ >> fixdep >> -bin2c >> diff --git a/xen/scripts/basic/Makefile b/xen/scripts/basic/Makefile >> index ec10d93..4fcef87 100644 >> --- a/xen/scripts/basic/Makefile >> +++ b/xen/scripts/basic/Makefile >> @@ -9,7 +9,6 @@ >> # fixdep:Used to generate dependency information during build process >> >> hostprogs-y := fixdep >> -hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c > > Why does Linux need this but we don't? > > Jan > Its for building firmware into the kernel. It converts a blob/binary to a C-style header which can be included into the code. One of the many things in their scripts directory that we won't need for Kconfig support. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 01/29] build: import Kbuild/Kconfig from Linux 4.2
On 10/6/15 7:45 AM, Jan Beulich wrote: On 06.10.15 at 00:03, wrote: >> Brings in the Kbuild/Kconfig plumbing from the Linux 4.2 release. >> >> Signed-off-by: Doug Goldstein >> --- >> xen/Makefile.linux | 1596 +++ >> xen/include/linux/kconfig.h| 54 + >> xen/scripts/Kbuild.include | 305 +++ >> xen/scripts/Makefile | 42 + >> xen/scripts/Makefile.asm-generic | 23 + >> xen/scripts/Makefile.build | 427 >> xen/scripts/Makefile.clean | 91 + >> xen/scripts/Makefile.extrawarn | 68 + >> xen/scripts/Makefile.help |3 + >> xen/scripts/Makefile.host | 128 ++ >> xen/scripts/Makefile.kasan | 29 + >> xen/scripts/Makefile.lib | 390 >> xen/scripts/Makefile.modpost | 152 ++ >> xen/scripts/basic/.gitignore |2 + >> xen/scripts/basic/Makefile | 16 + >> xen/scripts/basic/fixdep.c | 462 + >> xen/scripts/gcc-goto.sh| 21 + >> xen/scripts/kconfig/.gitignore | 22 + >> xen/scripts/kconfig/Makefile | 317 +++ >> xen/scripts/kconfig/POTFILES.in| 12 + >> xen/scripts/kconfig/check.sh | 13 + >> xen/scripts/kconfig/conf.c | 722 +++ >> xen/scripts/kconfig/confdata.c | 1248 >> xen/scripts/kconfig/expr.c | 1206 +++ >> xen/scripts/kconfig/expr.h | 238 +++ >> xen/scripts/kconfig/gconf.c| 1521 ++ >> xen/scripts/kconfig/gconf.glade| 661 ++ >> xen/scripts/kconfig/images.c | 326 +++ >> xen/scripts/kconfig/kxgettext.c| 235 +++ >> xen/scripts/kconfig/list.h | 131 ++ >> xen/scripts/kconfig/lkc.h | 186 ++ >> xen/scripts/kconfig/lkc_proto.h| 52 + >> xen/scripts/kconfig/lxdialog/.gitignore|4 + >> xen/scripts/kconfig/lxdialog/BIG.FAT.WARNING |4 + >> xen/scripts/kconfig/lxdialog/check-lxdialog.sh | 91 + >> xen/scripts/kconfig/lxdialog/checklist.c | 332 +++ >> xen/scripts/kconfig/lxdialog/dialog.h | 257 +++ >> xen/scripts/kconfig/lxdialog/inputbox.c| 301 +++ >> xen/scripts/kconfig/lxdialog/menubox.c | 437 >> xen/scripts/kconfig/lxdialog/textbox.c | 408 >> xen/scripts/kconfig/lxdialog/util.c| 713 +++ >> xen/scripts/kconfig/lxdialog/yesno.c | 114 ++ >> xen/scripts/kconfig/mconf.c| 1047 ++ >> xen/scripts/kconfig/menu.c | 697 +++ >> xen/scripts/kconfig/merge_config.sh| 158 ++ >> xen/scripts/kconfig/nconf.c| 1561 ++ >> xen/scripts/kconfig/nconf.gui.c| 656 ++ >> xen/scripts/kconfig/nconf.h| 96 + >> xen/scripts/kconfig/qconf.cc | 1798 + >> xen/scripts/kconfig/qconf.h| 338 > > Do we really need all the ?conf.[ch]* in Xen? Wouldn't the simple > non-GUI thing suffice for our needs? > > Also, btw - I don't think we should name the thing Kconfig in Xen; > Xconfig would be odd too (to be confused with X), so maybe > XenConfig? > > Jan > I used a very very broad brush stroke when I grabbed kconfig. $ cp -r linux/scripts/ xen/xen/scripts/ And only removed what I knew was obviously not necessary. Before this patchset is considered for actual inclusion I plan on trimming this patch down. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] make-flight: Trim the matrix of disk format flights
On Wed, 2015-09-30 at 15:42 +0100, Ian Campbell wrote:
> > i386 amd64 armhf
> >
> > raw keep - -
> > vhd - - keep
> > qcow2 -keep -
> >
> > libvirt raw - - keep
> > libvirt vhd -keep -
> > libvirt qcow2 - - keep
> >
[...]
> Acked-by: Ian Campbell
It occurred to me just now (i.e. rather too late) that as things stand
debian-di-install does not work for ARM in production, since it is using
Wheezy but Jessie is required for ARM guest support.
Hence the above change effectively dropped testing of xl.vhd and
libvirt.{raw,qcow2}.
Now, we are at least testing something with each format, just not quite
what we expected.
Since I have patches pending for switching Jessie I don't suppose those
matters too much.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 00/29] Incomplete Kconfig conversion
On 10/6/15 8:05 AM, Ian Campbell wrote: > On Mon, 2015-10-05 at 17:03 -0500, Doug Goldstein wrote: >> Ultimately my goal is to allow for more parts of the hypervisor to be turned >> off at compile time and potentially make it easier to include more >> experimental features by others which can be turned off by default. Also to >> provide the one true location for all possible knobs in the source code. > > I'm OK with the switch to Kconfig generally but I'd like us to start with a > conversion which offers the exact same set of options as exist today in the > Makefile (i.e. not very many at all) and where the use of select and etc > means that anyone who asks Kconfig to generate the default config (i.e. not > an explicit defconfig file) will produce a binary with the exact same > feature set as today. (Sorry if I misunderstood whether that is the goal > with this initial series vs. your ultimate goal) > > IOW we start by treating Kconfig as a better way for _developers_ to > control the configuration of Xen at compile time than adding and removing > #defines (i.e. the one true location thing you mention) but not (yet) as a > way to let users produce a wide variety of different images. > > Then we can start to consider patches which make options available for > users, on a case by case basis. > > Maybe those options should be behind some sort of dependency gate which > means that explicit action is needed in order to deviating from the > defaults such that it is acknowledged by the user that they have done so > and that such configurations may not even build let alone work. > > I'd also like to propose that we consider having a strict requirement for > patches to the test infrastructure to exercise any new user-facing option > before we accept the patch implementing it. > > What I don't want to see is fragmentation where every distro does something > subtly different or normal users ending up with different configurations to > the norm. By "normal users" I mean those without specialised requirements > or environments who aren't willing/able to support their decision to step > off the beaten path. > > Ian. > Ian, You stated this better than I did. My goal is not to necessarily make this like the Linux kernel where users toggle on different bits at a whim but more for developers and companies shipping Xen, basically those with specialized environments could use this to upstream more code and have it disabled by default. The current patchset only exposes KEXEC as a user facing option because its currently a user facing option in the source tree. I would not expand the list of user facing options past that. I consider adding more outside of the scope of this work and something that would happen after this series lands on a case by case basis. My ultimate goal with this initial work is to get all the developer knobs in one place because currently they are spread around as Makefile defines or defines in a header file and get a little bit of code comments around them. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] flask: Allow initial domain to use XENPF_get_symbol
On October 6, 2015 10:59:21 AM EDT, Jan Beulich wrote:
On 06.10.15 at 16:52, wrote:
>> Daniel De Graaf writes ("Re: [PATCH] flask: Allow initial domain to
>use
>> XENPF_get_symbol"):
>>> On 05/10/15 11:16, Konrad Rzeszutek Wilk wrote:
>>> > It looks to be missing in the policy file for the initial
>>> > domain. Eventually we may want to extend this access to
>>> > non-dom0 domains but for now it certainly dom0-only.
>>> >
>>> > Reviewed-by: Boris Ostrovsky
>>> > Signed-off-by: Konrad Rzeszutek Wilk
>>>
>>> Acked-by: Daniel De Graaf
>>
>> Jan, do you want to commit this ?
>
>Sure, I could do so, but Konrad could also do so all by himself now
>that the ack is in place.
Right. I was thinking to do it later today if nobody beats me to it.
>
>Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 00/29] Incomplete Kconfig conversion
On 10/5/15 5:12 PM, Julien Grall wrote: > Hi, > > Can you please run scripts/get_maintainers.pl on every patch to get the > list of relevant maintainers. > > Regards, > Yes. Sorry for not doing so. I treated this patchset as incomplete and just wanted to ensure the community was ok with my approach so I didn't want to bombard the maintainers individually yet. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 05/29] build: convert HAS_PASSTHROUGH use to Kconfig
On 10/6/15 4:47 AM, Andrew Cooper wrote: > On 05/10/15 23:03, Doug Goldstein wrote: >> Use the Kconfig generated HAS_PASSTHROUGH defines for the code base. >> >> Signed-off-by: Doug Goldstein >> > > Moving to a Kconfig style of selecting features changes the meaning of > our HAS_ prefix. > > IMO, the HAS_ should disappear in the conversion, as the CONFIG_* itself > existing indicates that kconfig has decided that a feature is present. > > ~Andrew > So I am treating the CONFIG_HAS_ defines similar to how the Linux kernel has CONFIG_HAVE_. These are not actually user facing options but instead they are enforced by the architecture instead of being a user facing option. For example CONFIG_HAS_KEXEC means the architecture/platform supports KEXEC but CONFIG_KEXEC would be the user configurable option to turn it on/off. This would be consistent with the current behavior in the Xen tree where HAS_KEXEC means the architecture/platform supports KEXEC while 'kexec' as an env var allows the user to build kexec on or off. If that's not desired I can combine them. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On Tue, 2015-10-06 at 11:30 -0400, Zhigang Wang wrote: > On 10/06/2015 11:26 AM, Ian Campbell wrote: > > On Tue, 2015-10-06 at 17:21 +0200, Juergen Gross wrote: > > > On 10/06/2015 05:11 PM, Ian Campbell wrote: > > > > On Tue, 2015-10-06 at 16:51 +0200, Juergen Gross wrote: > > > > > On 10/06/2015 03:40 PM, Ian Campbell wrote: > > > > > > On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: > > > > > > > > > > > > > And for the record, if my google-fu doesn't fail me, it's > > > > > > > possible to > > > > > > > load shared library into python interpreter using "dl" module > > > > > > > in > > > > > > > 2.7 > > > > > > > and > > > > > > > "ctypes" module in 3.x. > > > > > > > > > > > > Possible, but not especially convenient since you need to > > > > > > convert > > > > > > the C > > > > > > prototype manually, plus the result is not necessarily very > > > > > > "pythonic". > > > > > > > > > > > > I could totally see why people would prefer these bindings (or > > > > > > an > > > > > > argument > > > > > > for us providing a ctypes based wrapper). > > > > > > > > > > How often is such a debugging interface being used? Please > > > > > consider > > > > > the amount of code (my patch removed nearly 3000 lines of code!) > > > > > and > > > > > the availability of the xl wrapper. > > > > > > > > My understanding was that this was used by the "xen-bugtool" stuff > > > > in > > > > XenServer, so for actual functionality (gathering debug info) and > > > > not > > > > debugging (I supposed that the reference to being used for > > > > debugging was > > > > due to the name of the tool). > > > > > > And this functionality isn't available via the xl bindings? > > > > I don't know, we'll have to wait for those who are using it to chime > > in. > > > > Ian. > > IanC: I remember you said xl bindings has some design issue and should > not be used. Is it still the case today? Yes. Sorry, I read Juergen's original "via the xl bindings" as "via libxl", i.e. by using the library directly and forgot about the need for python bindings . Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 27/29] build: convert HAS_GICV3 use to Kconfig
On 10/5/15 5:25 PM, Julien Grall wrote: > Hi, Thanks for the quick review! I appreciate it. > > On 05/10/2015 23:03, Doug Goldstein wrote: >> Use the Kconfig generated CONFIG_HAS_GICV3 defines in the code base. > > If you are going to rename all HAS_* to CONFIG_HAS_, please drop the HAS > which is now redundant. So I am treating the CONFIG_HAS_ defines similar to how the Linux kernel has CONFIG_HAVE_. These are not actually user facing options but instead they are enforced by the architecture instead of being a user facing option. For example CONFIG_HAS_KEXEC means the architecture/platform supports KEXEC but CONFIG_KEXEC would be the user configurable option to turn it on/off. This would be consistent with the current behavior in the Xen tree where HAS_KEXEC means the architecture/platform supports KEXEC while 'kexec' as an env var allows the user to build kexec on or off. > >> >> Signed-off-by: Doug Goldstein >> --- >> xen/arch/arm/Kconfig | 4 >> xen/arch/arm/Makefile| 2 +- >> xen/arch/arm/Rules.mk| 2 -- >> xen/arch/arm/vgic.c | 2 +- >> xen/include/asm-arm/domain.h | 3 ++- >> xen/include/asm-arm/gic.h| 4 ++-- >> xen/include/asm-arm/vgic.h | 2 +- >> 7 files changed, 11 insertions(+), 8 deletions(-) >> >> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig >> index f100f17..01744c7 100644 >> --- a/xen/arch/arm/Kconfig >> +++ b/xen/arch/arm/Kconfig >> @@ -28,6 +28,10 @@ config ARCH_DEFCONFIG >> default "arch/arm/arm32_defconfig" if ARM_32 >> default "arch/arm/arm64_defconfig" if ARM_64 >> >> +# Select HAS_GICV3 if Generic Interrupt Connect (GICv3) is supported > > s/Connect/Controller/ although saying GICv3 is enough. No need to spell > out the acronym. > > If you really want to spell it it should be Generic Interrupt Controller > v3. Thanks. I will update those comments. > >> +config HAS_GICV3 >> +bool >> + > > I may have miss something with this change GICv3 is not built anymore > for ARM64. > > The user should be able to get a Xen with the exactly the same features > after this series without any changes from his side. Definitely my goal with this patchset is to make sure everything behaves the same way it did before. > >> source "common/Kconfig" >> >> source "drivers/Kconfig" > > [...] > >> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h >> index b89727e..4dd72ed 100644 >> --- a/xen/include/asm-arm/domain.h >> +++ b/xen/include/asm-arm/domain.h >> @@ -102,7 +102,8 @@ struct arch_domain >> struct pending_irq *pending_irqs; >> /* Base address for guest GIC */ >> paddr_t dbase; /* Distributor base address */ >> -#ifdef HAS_GICV3 >> +paddr_t cbase; /* CPU base address */ > > Can you please make sure that you series don't re-introduce code or > change it. > > This should be pretty easy to check with grep. I.e any changes in *.c > and *.h files but in lines containing ifdef/endif are likely wrong. > > Regards, > Apologies, I made a mistake during a rebase. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 7/8] ts-freebsd-install: Pass -s option to kpartx
On Tue, 2015-10-06 at 16:16 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v2 7/8] ts-freebsd-install: Pass -s
> > Without this the following mount fails having apparently raced against
> > the creation of the device nodes.
> How exciting. (Why on earth is `sync mode' not the default?
It's always good to have plenty of rope. No, wait, that's mountaineering.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On 06/10/15 16:26, Ian Campbell wrote: > On Tue, 2015-10-06 at 17:21 +0200, Juergen Gross wrote: >> On 10/06/2015 05:11 PM, Ian Campbell wrote: >>> On Tue, 2015-10-06 at 16:51 +0200, Juergen Gross wrote: On 10/06/2015 03:40 PM, Ian Campbell wrote: > On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: > >> And for the record, if my google-fu doesn't fail me, it's >> possible to >> load shared library into python interpreter using "dl" module in >> 2.7 >> and >> "ctypes" module in 3.x. > Possible, but not especially convenient since you need to convert > the C > prototype manually, plus the result is not necessarily very > "pythonic". > > I could totally see why people would prefer these bindings (or an > argument > for us providing a ctypes based wrapper). How often is such a debugging interface being used? Please consider the amount of code (my patch removed nearly 3000 lines of code!) and the availability of the xl wrapper. >>> My understanding was that this was used by the "xen-bugtool" stuff in >>> XenServer, so for actual functionality (gathering debug info) and not >>> debugging (I supposed that the reference to being used for debugging was >>> due to the name of the tool). >> And this functionality isn't available via the xl bindings? > I don't know, we'll have to wait for those who are using it to chime in. The python xl bindings? They don't even compile. They really should be deleted - anyone wishing to resurrect them can find them in source history. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/9] x86/intel_pstate: add a new driver interface, setpolicy()
>>> On 14.09.15 at 04:32, wrote:
> In order to better support future Intel processors, intel_pstate
> changes to use percentage values to tune P-states. The setpolicy
> driver interface is used to configure the intel_pstate internal
> policy. The __cpufreq_set_policy needs to be intercepted to use
> the setpolicy driver if it exists.
>
> Signed-off-by: Wei Wang
Andrew having given his R-b I'm going to apply this as is, but I don't
see how ...
> --- a/xen/drivers/cpufreq/utility.c
> +++ b/xen/drivers/cpufreq/utility.c
> @@ -456,6 +456,9 @@ int __cpufreq_set_policy(struct cpufreq_policy *data,
>
> data->min = policy->min;
> data->max = policy->max;
> +data->limits = policy->limits;
... this and ...
> --- a/xen/include/acpi/cpufreq/cpufreq.h
> +++ b/xen/include/acpi/cpufreq/cpufreq.h
> @@ -41,6 +41,18 @@ struct cpufreq_cpuinfo {
> unsigned inttransition_latency; /* in 10^(-9) s = nanoseconds */
> };
>
> +struct perf_limits {
> +bool_t no_turbo;
> +bool_t turbo_disabled;
> +uint32_t turbo_pct;
> +uint32_t max_perf_pct; /* max performance in percentage */
> +uint32_t min_perf_pct; /* min performance in percentage */
> +uint32_t max_perf;
> +uint32_t min_perf;
> +uint32_t max_policy_pct;
> +uint32_t min_policy_pct;
> +};
.. this are related to the patch subject. In particular it is impossible
to tell at this point whether and how all of the fields above are
going to be used. Please try to split patch series into _logical_
pieces.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 4/5] standalone: Make it possible to pass options to run-test
Ian Campbell writes ("Re: [Xen-devel] [PATCH OSSTEST 4/5] standalone: Make it
possible to pass options to run-test"):
> Also in this patch was
> + for i in $@ ; do
> which is similarly wrong, I think.
I should have spotted that too...
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 4/5] standalone: Make it possible to pass options to run-test
On Tue, 2015-10-06 at 15:59 +0100, Ian Campbell wrote:
> On Tue, 2015-10-06 at 15:46 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH OSSTEST 4/5] standalone: Make it possible
> > to
> > pass options to run-test"):
> > > Currently the remainder of the comnand line is passed after the host=
> > > ident, which allows for other idents to be given, which isn't all
> > > that
> > > useful in practice.
> > >
> > > Instead arrange that any additional options up to a "--" marker are
> > > passed before host= and anything after are passed after.
> > ...
> > > - with_logging logs/$flight/$job.$ts.log ./$ts $hosts $@
> > > + with_logging logs/$flight/$job.$ts.log ./$ts
> > > ${options[@]}
> > > $hosts $@
> >
> > You mean ... ./$ts "${options[@]}" $hosts ...
> > by analogy with "$@"
>
> We (well, I, since I wrote that) don't use "$@" above but just the bare
> $@,
> which I copied. I suppose that one is wrong too?
I've decided it is and will insert a patch to fixup various unquoted uses
of $@.
Also in this patch was
+ for i in $@ ; do
which is similarly wrong, I think.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v4][PATCH 2/2] libxl: introduce gfx_passthru_kind
On Fri, 25 Sep 2015, Ian Campbell wrote: > On Fri, 2015-09-18 at 16:30 +0800, Tiejun Chen wrote: > > Although we already have 'gfx_passthru' in b_info, this doesn't suffice > > after we want to handle IGD specifically. Now we define a new field of > > type, gfx_passthru_kind, to indicate we're trying to pass IGD. Actually > > this means we can benefit this to support other specific devices just > > by extending gfx_passthru_kind. And then we can cooperate with > > gfx_passthru to address IGD cases as follows: > > > > gfx_passthru = 0=> sets build_info.u.gfx_passthru to false > > gfx_passthru = 1=> sets build_info.u.gfx_passthru to true and > >build_info.u.gfx_passthru_kind to DEFAULT > > gfx_passthru = "igd"=> sets build_info.u.gfx_passthru to true > >and build_info.u.gfx_passthru_kind to IGD > > > > Here if gfx_passthru_kind = DEFAULT, we will call > > libxl__is_igd_vga_passthru() to check if we're hitting that table to need > > to pass that option to qemu. But if gfx_passthru_kind = "igd" we always > > force to pass that. > > > > And "-gfx_passthru" is just introduced to work for qemu-xen-traditional > > so we should get this away from libxl__build_device_model_args_new() in > > the case of qemu upstream. > > > > Signed-off-by: Tiejun Chen > > Acked + applied both patches, thanks. > > Stefano -- are the QEMU side patches in qemu-upstream-unstable.git yet? If > not I suppose this is a call/reminder to backport them from mainline or > whatever. No, they are not, they'll be in qemu-upstream for Xen 4.7. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 5/8] ts-kernel-build: Explicitly enable CONFIG_CGROUPS
Ian Campbell writes ("Re: [PATCH OSSTEST v2 5/8] ts-kernel-build: Explicitly
enable CONFIG_CGROUPS"):
> On Tue, 2015-10-06 at 16:05 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH OSSTEST v2 5/8] ts-kernel-build: Explicitly
> > enable CONFIG_CGROUPS"):
> > > Arranging to install sysvinit-core during xen-create-image looks to be
> > > non-trivial. I hope it won't be necessary.
> >
> > If we do decide it's necessary, ISTR that telling x-c-i to add
> > specific additional packages is not too hard.
>
> Really? I did look and the advice I saw on the Internet seemed to revolve
> around adding wrappers around debootstrap and telling x-c-i to use them.
The --role= option seems to provide a suiteable hook. I looked at
/etc/xen-tools/role.d/builder and it seems a reasonable template.
Anyway, we can cross this bridge when we come to it.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8] run QEMU as non-root
Ian Campbell wrote: > On Tue, 2015-10-06 at 14:13 +0100, Stefano Stabellini wrote: >> On Mon, 5 Oct 2015, Ian Campbell wrote: >>> On Mon, 2015-10-05 at 16:53 +0100, Stefano Stabellini wrote: > Wasn't there some code to plumb this into xl at one point? Did that > get > dropped along the way? device_model_user is added to the idl by this patch, I think that is enough, right? >>> Depends what you mean by "enough", it adds it to the _libxl_ API, which >>> is >>> sufficient for the patch to be useful but it doesn't actually cause the >>> option to be available to users of xl via a cfg file, which arguably it >>> should. >>> >>> To make it available to xl users patches to tools/libxl/xl_cmdimpl.c >>> would >>> be needed (plus docs changes) >> I see. No, xl_cmdimpl.c support for the option was never written, as it >> was introduced principally for libvirt's benefit. > > Ah, I was wondering how this had been tested... Currently, there is no libivrt code to using this. But surely users would like to specify the qemu user in their xl config right? Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 62646: tolerable FAIL - PUSHED
On Mon, 2015-10-05 at 18:21 +, osstest service owner wrote: > flight 62646 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/62646/ > > Failures :-/ but no regressions. > > Regressions which are regarded as allowable (not blocking): > test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install > fail like 62583 > test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate > fail like 62583 http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/ALL.html paints a pretty sorry picture. http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/ALL.html is not a lot better, but does occasionally pass. It seems as if both suffer quite badly in the migration test cases. Both also suffer from issues with the install phase, but the test-amd64 -i386 case is much worse. It looks as if the failures are mostly on italia* and merlot*, however that might be somewhat down to the stickiness of failures. By contrast the same test cases without stubdom appear to be in reasonable shape (the odd failure, but nothing like as bad): http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm/ALL.html http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-debianhvm-amd64-xsm/ALL.html This is hampered somewhat by the lack of logging of the guest serial when stubdom is in use. For non-studom this ends up in the qemu log, for stubdom I'm not sure which blackhole it goes down. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On 10/06/2015 11:26 AM, Ian Campbell wrote: > On Tue, 2015-10-06 at 17:21 +0200, Juergen Gross wrote: >> On 10/06/2015 05:11 PM, Ian Campbell wrote: >>> On Tue, 2015-10-06 at 16:51 +0200, Juergen Gross wrote: On 10/06/2015 03:40 PM, Ian Campbell wrote: > On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: > >> And for the record, if my google-fu doesn't fail me, it's >> possible to >> load shared library into python interpreter using "dl" module in >> 2.7 >> and >> "ctypes" module in 3.x. > > Possible, but not especially convenient since you need to convert > the C > prototype manually, plus the result is not necessarily very > "pythonic". > > I could totally see why people would prefer these bindings (or an > argument > for us providing a ctypes based wrapper). How often is such a debugging interface being used? Please consider the amount of code (my patch removed nearly 3000 lines of code!) and the availability of the xl wrapper. >>> >>> My understanding was that this was used by the "xen-bugtool" stuff in >>> XenServer, so for actual functionality (gathering debug info) and not >>> debugging (I supposed that the reference to being used for debugging was >>> due to the name of the tool). >> >> And this functionality isn't available via the xl bindings? > > I don't know, we'll have to wait for those who are using it to chime in. > > Ian. IanC: I remember you said xl bindings has some design issue and should not be used. Is it still the case today? Zhigang ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On 10/06/2015 05:11 PM, Ian Campbell wrote: On Tue, 2015-10-06 at 16:51 +0200, Juergen Gross wrote: On 10/06/2015 03:40 PM, Ian Campbell wrote: On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: And for the record, if my google-fu doesn't fail me, it's possible to load shared library into python interpreter using "dl" module in 2.7 and "ctypes" module in 3.x. Possible, but not especially convenient since you need to convert the C prototype manually, plus the result is not necessarily very "pythonic". I could totally see why people would prefer these bindings (or an argument for us providing a ctypes based wrapper). How often is such a debugging interface being used? Please consider the amount of code (my patch removed nearly 3000 lines of code!) and the availability of the xl wrapper. My understanding was that this was used by the "xen-bugtool" stuff in XenServer, so for actual functionality (gathering debug info) and not debugging (I supposed that the reference to being used for debugging was due to the name of the tool). And this functionality isn't available via the xl bindings? I always thought that a use case like this was one of the motivations to introduce libxl. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 0/8] Use the DTB provided by the kernel we are trying to boot
Ian Campbell writes ("[PATCH OSSTEST v2 0/8] Use the DTB provided by the kernel
we are trying to boot"):
> On ARM we have been booting using the DTBS provided by the host Debian
> kernel package (i.e. the ones from 3.16) even when we are booting a
> Xen+kernel which we have built ourselves.
...
> This is all acked but there were some changes suggested along with the
> acks, which I've made and am posting here. It was all pretty minor so I've
> kept the acks, I hope that is ok.
Indeed, it's what I expected, thanks.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 5/8] ts-kernel-build: Explicitly enable CONFIG_CGROUPS
On Tue, 2015-10-06 at 16:05 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v2 5/8] ts-kernel-build: Explicitly
> enable CONFIG_CGROUPS"):
> > This is not enabled in the arm defconfig (it is in x86) and without it
> > a Debian Jessie userspace with systemd fails to boot with:
> >
> > systemd[1]: Failed to mount tmpfs at /sys/fs/cgroup: No such file or
> > directory
> >
> > While we arrange to use sysvinit in the host and in d-i installed
> > guests we do not do so for xen-create-image guests.
>
> Acked-by: Ian Jackson
Thanks.
> > Arranging to install sysvinit-core during xen-create-image looks to be
> > non-trivial. I hope it won't be necessary.
>
> If we do decide it's necessary, ISTR that telling x-c-i to add
> specific additional packages is not too hard.
Really? I did look and the advice I saw on the Internet seemed to revolve
around adding wrappers around debootstrap and telling x-c-i to use them.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.4-testing test] 62675: trouble: broken/pass
flight 62675 qemu-upstream-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/62675/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-vhd2 hosts-allocate running test-amd64-i386-libvirt-qcow2 2 hosts-allocate running test-amd64-i386-xl-qcow2 2 hosts-allocate running test-amd64-i386-libvirt-raw 2 hosts-allocate running test-amd64-amd64-xl-raw 2 hosts-allocate running test-amd64-amd64-libvirt 2 hosts-allocate running test-amd64-i386-libvirt 2 hosts-allocate running test-amd64-amd64-xl 2 hosts-allocate running test-amd64-i386-pv2 hosts-allocate running test-amd64-i386-qemuu-rhel6hvm-intel 2 hosts-allocate running test-amd64-amd64-pair 2 hosts-allocate running test-amd64-amd64-i386-pvgrub 2 hosts-allocate running test-amd64-amd64-xl-multivcpu 2 hosts-allocate running test-amd64-amd64-libvirt-qcow2 2 hosts-allocate running test-amd64-amd64-xl-credit2 2 hosts-allocate running test-amd64-amd64-pygrub 2 hosts-allocate running test-amd64-amd64-libvirt-raw 2 hosts-allocate running test-amd64-i386-pair 2 hosts-allocate running test-amd64-amd64-xl-qemuu-debianhvm-amd64 2 hosts-allocaterunning test-amd64-i386-libvirt-pair 2 hosts-allocate running test-amd64-i386-qemuu-rhel6hvm-amd 2 hosts-allocate running test-amd64-amd64-xl-qcow2 2 hosts-allocate running test-amd64-amd64-xl-vhd 2 hosts-allocate running test-amd64-amd64-libvirt-vhd 2 hosts-allocate running test-amd64-amd64-amd64-pvgrub 2 hosts-allocate running test-amd64-i386-xl-qemuu-ovmf-amd64 2 hosts-allocate running test-amd64-amd64-xl-qemuu-ovmf-amd64 2 hosts-allocate running test-amd64-amd64-libvirt-pair 2 hosts-allocate running test-amd64-amd64-xl-qemuu-win7-amd64 2 hosts-allocate running test-amd64-i386-freebsd10-amd64 2 hosts-allocate running test-amd64-i386-xl-qemuu-win7-amd64 2 hosts-allocate running test-amd64-i386-xl2 hosts-allocate running test-amd64-i386-xl-qemuu-debianhvm-amd64 2 hosts-allocate running test-amd64-amd64-pv 2 hosts-allocate running test-amd64-i386-xl-raw2 hosts-allocate running test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 2 hosts-allocate running test-amd64-i386-freebsd10-i386 2 hosts-allocate running test-amd64-i386-libvirt-vhd 2 hosts-allocate running test-amd64-amd64-xl-qemuu-winxpsp3 2 hosts-allocate running version targeted for testing: qemuu5fe74249f5ab528fe84a26fa60438a6de4c787f0 baseline version: qemuu0fc147387f0b683d2dfefec7b1af569f17b72e9c Last test of basis60565 2015-08-04 01:59:38 Z 63 days Failing since 61617 2015-09-08 12:10:54 Z 28 days 13 attempts Testing same since62062 2015-09-16 11:15:04 Z 20 days9 attempts People who touched revisions under test: Gerd Hoffmann P J P Peter Lieven Stefan Hajnoczi Stefano Stabellini jobs: build-amd64-xend pass build-i386-xend pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl broken test-amd64-i386-xl broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-debianhvm-amd64broken test-amd64-i386-xl-qemuu-debianhvm-amd64 broken test-amd64-i386-freebsd10-amd64 broken test-amd64-amd64-xl-qemuu-ovmf-amd64 broken test-amd64-i386-xl-qemuu-ovmf-amd64 broken test-amd64-amd64-xl-qemuu-win7-amd64 broken test-amd64-i386-xl-qemuu-win7-amd64 broken test-amd64-amd64-xl-credit2 broken test-amd64-i386-
Re: [Xen-devel] RFC: LTS and stable release scheme
On Tue, 2015-10-06 at 12:07 +0100, Wei Liu wrote: > Hi all > > A majority of developers express interests in trying a shorter > release > cycle -- to change from 9 months to 6 months [0]. There are, however, > repercussions on how we manage stable and possible LTS releases. > > I start this thread hoping it's clearer that downstream consumers > like > distributions and individual packagers can voice their opinions. I've > CC'ed some people I can think of who might be interested in this > topic. > Feel free to CC more people. > Cc-ing Michael, the Fedora package maintainer, and Marek, from QubesOS. Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On Tue, 2015-10-06 at 17:21 +0200, Juergen Gross wrote: > On 10/06/2015 05:11 PM, Ian Campbell wrote: > > On Tue, 2015-10-06 at 16:51 +0200, Juergen Gross wrote: > > > On 10/06/2015 03:40 PM, Ian Campbell wrote: > > > > On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: > > > > > > > > > And for the record, if my google-fu doesn't fail me, it's > > > > > possible to > > > > > load shared library into python interpreter using "dl" module in > > > > > 2.7 > > > > > and > > > > > "ctypes" module in 3.x. > > > > > > > > Possible, but not especially convenient since you need to convert > > > > the C > > > > prototype manually, plus the result is not necessarily very > > > > "pythonic". > > > > > > > > I could totally see why people would prefer these bindings (or an > > > > argument > > > > for us providing a ctypes based wrapper). > > > > > > How often is such a debugging interface being used? Please consider > > > the amount of code (my patch removed nearly 3000 lines of code!) and > > > the availability of the xl wrapper. > > > > My understanding was that this was used by the "xen-bugtool" stuff in > > XenServer, so for actual functionality (gathering debug info) and not > > debugging (I supposed that the reference to being used for debugging was > > due to the name of the tool). > > And this functionality isn't available via the xl bindings? I don't know, we'll have to wait for those who are using it to chime in. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 4/5] standalone: Make it possible to pass options to run-test
Ian Campbell writes ("Re: [PATCH OSSTEST 4/5] standalone: Make it possible to
pass options to run-test"):
> On Tue, 2015-10-06 at 15:46 +0100, Ian Jackson wrote:
> > You mean ... ./$ts "${options[@]}" $hosts ...
> > by analogy with "$@"
>
> We (well, I, since I wrote that) don't use "$@" above but just the bare $@,
> which I copied. I suppose that one is wrong too?
Yes, indeed. Sorry for not spotting that earlier.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 1/5] xsplice: Design document.
>>> On 16.09.15 at 23:01, wrote:
> +### Symbol names
> +
> +
> +Xen as it is now, has a couple of non-unique symbol names which will
> +make runtime symbol identification hard. Sometimes, static symbols
> +simply have the same name in C files, sometimes such symbols get
> +included via header files, and some C files are also compiled
> +multiple times and linked under different names (guest_walk.c).
> +
> +As such we need to modify the linker to make sure that the symbol
> +table qualifies also symbols by their source file name.
> +
> +For the awkward situations in which C-files are compiled multiple
> +times patches we would need to some modification in the Xen code.
> +
> +
> +The convention for file-type symbols (that would allow to map many
> +symbols to their compilation unit) says that only the basename (i.e.,
> +without directories) is embedded. This creates another layer of
> +confusion for duplicate file names in the build tree.
> +
> +That would have to be resolved.
So here's a draft (some debugging code left and not yet tested
on a really old tool chain) patch doing the prefixing. I also have
9 more patches on top of this, most dealing with individual
symbols that are still left as duplicates (some also do other
cleanup I no longer directly need with the approach now taken).
Sadly the set of duplicates depends on the compiler version in
some cases, hence at the end of the full current series there
are still some duplicate symbol warnings left. I think we can live
with those though for the moment.
Jan
TODO: remove //temp-s
Note: Not warning about duplicate symbols in the EFI case for now, as
a binutils bug causes misnamed file name entries to appear in EFI
binaries' symbol tables when the file name is longer than 18 chars.
(Not doing so also avoids other duplicates getting printed twice.)
--- unstable.orig/xen/arch/x86/Makefile
+++ unstable/xen/arch/x86/Makefile
@@ -106,11 +106,13 @@ $(BASEDIR)/common/symbols-dummy.o:
$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
$(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
- $(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
+ $(NM) -pa --format=sysv $(@D)/.$(@F).0 \
+ | $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
- $(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
+ $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
+ | $(BASEDIR)/tools/symbols --sysv --sort --warn-dup
>$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
$(@D)/.$(@F).1.o -o $@
@@ -133,13 +135,15 @@ $(TARGET).efi: prelink-efi.o efi.lds efi
$(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $<
efi/relocs-dummy.o \
$(BASEDIR)/common/symbols-dummy.o -o
$(@D)/.$(@F).$(base).0 &&) :
$(guard) efi/mkreloc $(foreach base,$(VIRT_BASE)
$(ALT_BASE),$(@D)/.$(@F).$(base).0) >$(@D)/.$(@F).0r.S
- $(guard) $(NM) -n $(@D)/.$(@F).$(VIRT_BASE).0 | $(guard)
$(BASEDIR)/tools/symbols >$(@D)/.$(@F).0s.S
+ $(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).0 \
+ | $(guard) $(BASEDIR)/tools/symbols --sysv --sort
>$(@D)/.$(@F).0s.S
$(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0r.o
$(@D)/.$(@F).0s.o
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
$(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< \
$(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o -o
$(@D)/.$(@F).$(base).1 &&) :
$(guard) efi/mkreloc $(foreach base,$(VIRT_BASE)
$(ALT_BASE),$(@D)/.$(@F).$(base).1) >$(@D)/.$(@F).1r.S
- $(guard) $(NM) -n $(@D)/.$(@F).$(VIRT_BASE).1 | $(guard)
$(BASEDIR)/tools/symbols >$(@D)/.$(@F).1s.S
+ $(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).1 \
+ | $(guard) $(BASEDIR)/tools/symbols --sysv --sort
>$(@D)/.$(@F).1s.S
$(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1r.o
$(@D)/.$(@F).1s.o
$(guard) $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T efi.lds -N $< \
$(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o -o $@
--- unstable.orig/xen/arch/x86/time.c
+++ unstable/xen/arch/x86/time.c
@@ -2059,6 +2059,7 @@ static struct keyhandler dump_softtsc_ke
static int __init setup_dump_softtsc(void)
{
register_keyhandler('s', &dump_softtsc_keyhandler);
+dump_execution_state();//temp
return 0;
}
__initcall(setup_dump_softtsc);
--- unstable.orig/xen/tools/symbols.c
+++ unstable/xen/tools/symbols.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#define KSYM_NAME_LEN 127
@@ -40,13 +41,14 @@ struct sym_entry {
unsigned int len;
unsigned c
Re: [Xen-devel] [xen-4.4-testing test] 62616: regressions - FAIL
On Mon, 2015-10-05 at 04:21 -0600, Jan Beulich wrote:
> Agreed, I think we should force push here.
After discussion IRL and on IRC Ian was OK with this too.
>From the original report:
> version targeted for testing:
> xen 4d99a76cfeba6d23504121a51e7750f230128d85
> baseline version:
> xen 3646b134c1673f09c0a239de10b0da4c9265c8e8
(test-lab)osstest@osstest:~/branches/for-xen-4.4-testing.git$
OSSTEST_CONFIG=production-config ./ap-push xen-4.4-testing
4d99a76cfeba6d23504121a51e7750f230128d85
+ branch=xen-4.4-testing
+ revision=4d99a76cfeba6d23504121a51e7750f230128d85
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-4.4-testing
4d99a76cfeba6d23504121a51e7750f230128d85
+ branch=xen-4.4-testing
+ revision=4d99a76cfeba6d23504121a51e7750f230128d85
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.4-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.4-testing
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-4.4-testing
+ prevxenbranch=xen-4.3-testing
+ : tested/2.6.39.x
+ . ./ap-common
++ xenbranch_forqemu=xen-4.4-testing
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.4-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : daily-cron.xen-4.4-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.4-testing.git
++ : daily-cron.xen-4.4-te
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On 10/06/2015 10:51 AM, Juergen Gross wrote: > On 10/06/2015 03:40 PM, Ian Campbell wrote: >> On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: >> >>> And for the record, if my google-fu doesn't fail me, it's possible to >>> load shared library into python interpreter using "dl" module in 2.7 and >>> "ctypes" module in 3.x. >> >> Possible, but not especially convenient since you need to convert the C >> prototype manually, plus the result is not necessarily very "pythonic". >> >> I could totally see why people would prefer these bindings (or an argument >> for us providing a ctypes based wrapper). > > How often is such a debugging interface being used? Please consider > the amount of code (my patch removed nearly 3000 lines of code!) and > the availability of the xl wrapper. We use these extentions along with xend XMLRPC API/xm. Even when move to xl, this will give us a choice to reserve some logic. Thanks, Zhigang ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [qemu-upstream-4.4-testing test] 62580: regressions - FAIL
On Mon, 2015-10-05 at 09:56 +0100, Ian Campbell wrote: > On Sat, 2015-10-03 at 19:32 +, osstest service owner wrote: > > flight 62580 qemu-upstream-4.4-testing real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/62580/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > test-amd64-i386-xl-vhd9 debian-di-install fail REGR. > > vs. 60565 > > test-amd64-i386-xl-qcow2 9 debian-di-install fail REGR. > > vs. 60565 > > From: > http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-upstream- > 4.4-testing/test-amd64-i386-xl-vhd.debian-di-install.html > and > http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-upstream- > 4.4-testing/test-amd64-i386-xl-qcow2.debian-di-install.html > > It seems like it is unable to reproduce the baseline pass. > > I think what has happened here is that these test cases have landed on > merlot* and are waiting for "libxl: Increase device model startup timeout > to 1min." which is currently in staging-4.4 (and seems to be stuck there, > which is next on my list to investigate). > > I think this justifies force pushing qemu-upstream-4.4-testing in the > meantime. In the end we decided (in "[xen-4.4-testing test] 62616: regressions - FAIL") to force push xen-4.4-testing, meaning that the thing which is blocking these qemu-upstream-4.4-testing runs will go away. So no force push for this one, I am however about to kill flight 62675 so we can get a replacement going on the new xen-4.4-testing baseline. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: change to 6 months release cycle
On Mon, 5 Oct 2015, Ian Campbell wrote: > On Fri, 2015-10-02 at 19:21 +0100, Andrew Cooper wrote: > > On 02/10/15 18:52, Juergen Gross wrote: > > > On 10/02/2015 07:43 PM, Wei Liu wrote: > > > > Hi all > > > > > > > > As I understand it in the past there were discussions on release > > > > every > > > > 6 months. I would like to revisit this topic. > > > > > > > > # Rationale for a shorter release cycle > > > > > > > > The current 9 months cadence is too long. That create at least two > > > > problems for us. > > > > > > > > The first problem is that Xen delivers features much slower than > > > > other > > > > projects. Linux kernel releases every 3 months. QEMU releases every 4 > > > > months. They deliver new features at a much higher frequency. > > > > > > > > The second problem is that the opportunity cost for vendors to miss a > > > > release is very high. When combined with the freeze exception scheme, > > > > tension quickly builds up around cut-off point, which creates > > > > frictions and frustrations for both contributors and maintainers. > > > > This > > > > is detrimental to the project in the long run. > > > > > > > > Having a shorter release cycle plus some other measures seem to make > > > > sense. > > > > > > > > The main objection from previous discussion seems to be that "shorter > > > > release cycle creates burdens for downstream projects". I couldn't > > > > quite get the idea, but I think we can figure out a way to sort that > > > > out once we know what exactly the burdens are. > > > > > > > > A side note is that if we really go down this route we need to stick > > > > with it for a few releases to let people get used to it. Any change > > > > to > > > > the release process is going to cause some issues. > > > > > > > > # Proposed release cycle > > > > > > > > Aim for 6 months release cycle -- 4 months development period, 2 > > > > months hardening period. Make two releases per year. > > > > > > > > Fixed hard cut-off date, no more freeze exception. Arrange RCs > > > > immediately after cut-off. > > > > > > > > Take into account holiday seasons in US, Europe and China, the two > > > > cut-off dates are the Fridays in which that last day of March and > > > > September are in. > > > > > > > > Targeted release date is two months after cut-off date. Still, we > > > > pick > > > > a Friday using the same rule. We can also release a bit earlier if > > > > everything goes well. If we somehow fail to release on time, we eat > > > > into next development cycle. The next cut-off date will still be > > > > fixed. > > > > > > > > With the proposed scheme, the dates will be: > > > > > > > > - 4.7 cut-off date: April 1, 2016 > > > > - 4.7 release date: June 1, 2016 > > > > > > > > - 4.8 cut-off date: September 30, 2016 > > > > - 4.8 release date: December 2, 2016 > > > > > > > > - 4.9 cut-off date: March 31, 2017 > > > > - 4.9 release date: June 2, 2017 > > > > > > > > and it goes on. > > > > > > > > # Feasibility analysis > > > > > > > > Xen 4.6 is almost out of the door. I think it's convenient to use it > > > > as one > > > > data point about how we can achieve the proposed plan. > > > > > > > > Xen 4.6 release time line broken down: > > > > > > > > - developemnt: 6 months > > > > - consideration for freeze exception: 1 week > > > > - applying patches with free exception: 1 week > > > > - fix major bugs: 2 weeks > > > > - RCs: every 1 to 2 weeks > > > > > > > > We aimed for a 9 months release cycle. That means we have 3 months > > > > for > > > > stabilisation and RCs. > > > > > > > > Note that the 2 weeks used to fix bugs were mostly for bugs > > > > introduced > > > > during free exception. > > > > > > > > The riddance of freeze exception saves us at least the first 2 weeks. > > > > And because there are less changes due to shorter development cycle > > > > and > > > > no freeze exception, there are probably less bugs, which means we can > > > > potentially save another week or two. So the 6 months time line is > > > > realistic to achieve. +1 > > > Expecting less bugs due to a shorter development cycle is strange. I'd > > > expect more bugs as large features have less time to be stabilized. Or > > > are you expecting only small features in the future? I don't hope so. > > > > The expectation is that with a shorter release cycle, there will be less > > pressure to push large series in at the last minute, as deferring them > > to the next release comes with a substantially smaller penalty. As a > > result, large series will (hopefully) be better baked when they do get > > accepted. > > Right, essentially this is reducing average the latency between acceptance > of a feature and the release which contains it, hopefully relieving some of > the pressure to get something in right away. I think so too ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: libxl: allow permissive qemu-upstream pci passthrough.
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] tools: libxl: allow
permissive qemu-upstream pci passthrough."):
> All the QEMU side XSA-131 patches are already in the qemu-xen 4.3, 4.4
> and 4.5 trees.
>
> On Tue, 6 Oct 2015, Ian Campbell wrote:
> > Ian, Can you backport this to 4.5 and earlier please.
Thanks. I have added this to my queue.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On Tue, 2015-10-06 at 16:51 +0200, Juergen Gross wrote: > On 10/06/2015 03:40 PM, Ian Campbell wrote: > > On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: > > > > > And for the record, if my google-fu doesn't fail me, it's possible to > > > load shared library into python interpreter using "dl" module in 2.7 > > > and > > > "ctypes" module in 3.x. > > > > Possible, but not especially convenient since you need to convert the C > > prototype manually, plus the result is not necessarily very "pythonic". > > > > I could totally see why people would prefer these bindings (or an > > argument > > for us providing a ctypes based wrapper). > > How often is such a debugging interface being used? Please consider > the amount of code (my patch removed nearly 3000 lines of code!) and > the availability of the xl wrapper. My understanding was that this was used by the "xen-bugtool" stuff in XenServer, so for actual functionality (gathering debug info) and not debugging (I supposed that the reference to being used for debugging was due to the name of the tool). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 7/8] ts-freebsd-install: Pass -s option to kpartx
Ian Campbell writes ("[PATCH OSSTEST v2 7/8] ts-freebsd-install: Pass -s option
to kpartx"):
> This is "Sync mode. Don't return until the partitions are created",
> which seems to be needed in Jessie. The option also exists in Wheezy,
> according to the manpage.
Acked-by: Ian Jackson
> Without this the following mount fails having apparently raced against
> the creation of the device nodes.
How exciting. (Why on earth is `sync mode' not the default? Don't
get me started...)
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 6/8] ts-debian-di-install: Use correct per-arch name for kernel.
Ian Campbell writes ("[PATCH OSSTEST v2 6/8] ts-debian-di-install: Use correct
per-arch name for kernel."):
> The x86 and arm kernels are inconsistently named upstream, and then
> renamed in mg-debian-installer-update as:
>
> == KERNEL == INITRD ==
> Debian Osstest Debian Osstest
> ------ ----
> x86/native: linux => linuxinitrd.gz => initrd.gz
> x86/xen:xen/vmlinuz => vmlinuz-xen xen/initrd.gz => initrd.gz-xen
> arm/native: vmlinuz => linuxinitrd.gz => initrd.gz
> arm/xen:vmlinuz => linuxinitrd.gz => initrd.gz
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 5/8] ts-kernel-build: Explicitly enable CONFIG_CGROUPS
Ian Campbell writes ("[PATCH OSSTEST v2 5/8] ts-kernel-build: Explicitly enable
CONFIG_CGROUPS"):
> This is not enabled in the arm defconfig (it is in x86) and without it
> a Debian Jessie userspace with systemd fails to boot with:
>
> systemd[1]: Failed to mount tmpfs at /sys/fs/cgroup: No such file or directory
>
> While we arrange to use sysvinit in the host and in d-i installed
> guests we do not do so for xen-create-image guests.
Acked-by: Ian Jackson
> Arranging to install sysvinit-core during xen-create-image looks to be
> non-trivial. I hope it won't be necessary.
If we do decide it's necessary, ISTR that telling x-c-i to add
specific additional packages is not too hard.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 62666: tolerable FAIL - PUSHED
flight 62666 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/62666/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass version targeted for testing: libvirt ce692d5ea6e067a7fc655da89cddfa1a3487d51c baseline version: libvirt 5e06a4f063dc6cf2ae14a361ddeb805d3f3ae440 Last test of basis62435 2015-09-27 08:39:40 Z9 days Failing since 62551 2015-09-30 04:20:46 Z6 days3 attempts Testing same since62666 2015-10-04 18:50:47 Z1 days1 attempts People who touched revisions under test: Cole Robinson Daniel P. Berrange Daniel Veillard Ján Tomko Laine Stump Martin Kletzander Michal Privoznik Pavel Fedin jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-i386-libvirt-qcow2pass test-amd64-amd64-libvirt-raw pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-libvirt-vhd fail test-amd64-i386-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.gi
Re: [Xen-devel] [linux-3.18 test] 62651: regressions - FAIL
Ian Campbell writes ("Re: [linux-3.18 test] 62651: regressions - FAIL"):
> On Tue, 2015-10-06 at 04:21 +, osstest service owner wrote:
> 2015-10-06 00:50:13 Z guest redhat.guest.osstest 5a:36:0e:bb:00:3a 22
> link/ip/tcp: ok. (35s)
> 2015-10-06 00:50:13 Z executing ssh ... root@172.16.146.215 echo guest
> redhat.guest.osstest: ok
> 2015-10-06 00:50:43 Z command timed out [30]: timeout 60 ssh -o
> StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o
> ServerAliveInterval=100 -o PasswordAuthentication=no -o
> ChallengeResponseAuthentication=no -o
> UserKnownHostsFile=tmp/t.known_hosts_62651.test-amd64-i386-qemut-rhel6hvm-amd
> root@172.16.146.215 echo guest redhat.guest.osstest: ok
> status (timed out) at Osstest/TestSupport.pm line 410.
This is quite different: it's a timeout. And, a 30s one.
> I think it is specific to merlot and will work itself out next time. From
> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-qemut-rhel6hvm-amd/linux-3.18.html
> there was one similar failure months ago which succeeded on a second attempt.
I just looked at a Debian HVM stubom failure in the osstest baseline
62620:
http://logs.test-lab.xenproject.org/osstest/logs/62620/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/info.html
That was a 10s timeout but otherwise very similar. There wasn't
enough information in the logs to see anything wrong.
We don't seem to have a useable guest console log in these tests.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: LTS and stable release scheme
On Tue, Oct 06, 2015 at 08:52:23AM -0600, Jan Beulich wrote: > >>> On 06.10.15 at 16:09, wrote: > > What do you propose when we regarding stable branches when we switch to > > 6 months cycle? > > See the chicken-and-egg problem: I can't answer this, because the > issues with the stable trees are the main reason I don't support the > change to the release cycle (yet). > I have mistakenly taken your final reply to the other thread as your agreement to the new release cycle. Maybe we should continue our discussion there. Let's draw an conclusion if we really want 6 months before pursuing this LTS topic further. Wei. > Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] flask: Allow initial domain to use XENPF_get_symbol
>>> On 06.10.15 at 16:52, wrote:
> Daniel De Graaf writes ("Re: [PATCH] flask: Allow initial domain to use
> XENPF_get_symbol"):
>> On 05/10/15 11:16, Konrad Rzeszutek Wilk wrote:
>> > It looks to be missing in the policy file for the initial
>> > domain. Eventually we may want to extend this access to
>> > non-dom0 domains but for now it certainly dom0-only.
>> >
>> > Reviewed-by: Boris Ostrovsky
>> > Signed-off-by: Konrad Rzeszutek Wilk
>>
>> Acked-by: Daniel De Graaf
>
> Jan, do you want to commit this ?
Sure, I could do so, but Konrad could also do so all by himself now
that the ack is in place.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 4/5] standalone: Make it possible to pass options to run-test
On Tue, 2015-10-06 at 15:46 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST 4/5] standalone: Make it possible to
> pass options to run-test"):
> > Currently the remainder of the comnand line is passed after the host=
> > ident, which allows for other idents to be given, which isn't all that
> > useful in practice.
> >
> > Instead arrange that any additional options up to a "--" marker are
> > passed before host= and anything after are passed after.
> ...
> > - with_logging logs/$flight/$job.$ts.log ./$ts $hosts $@
> > + with_logging logs/$flight/$job.$ts.log ./$ts ${options[@]}
> > $hosts $@
>
> You mean ... ./$ts "${options[@]}" $hosts ...
> by analogy with "$@"
We (well, I, since I wrote that) don't use "$@" above but just the bare $@,
which I copied. I suppose that one is wrong too?
> mariner:~> a=(a "1 2" b)
> mariner:~> echo = ${a[@]}
> = a 1 2 b
> mariner:~> echo = "${a[@]}"
> = a 1 2 b
> mariner:~>
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 2/5] cs-adjust-flight: Add job-status to report job stats
On Tue, 2015-10-06 at 15:44 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST 2/5] cs-adjust-flight: Add job
> -status to report job stats"):
> > The return code of sg-run-job does not reflect the state of the job,
> > which is instead written to the database. For the benefit of running
> > tests in a loop until failure add a command to retrieve the status to
> > stdout.
> ...
> > +job_status() {
> > +flight=$1; shift
> > +job=$1; shift
> > +
> > +status=$(OSSTEST_CONFIG=$config \
> > + ./cs-adjust-flight $flight job-status $job)
> > +echo "$status"
> > +}
>
> This is rather odd. Why do you capture the value in a variable and
> then pass it to echo ? You could just let the job_status command
> print its output directly.
It was previously echo "${status#* }" (or something like that). I should
have changed it.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] xen/arm: gic: Check the size of the CPU and vCPU interface retrieved from DT
On Tue, 2015-10-06 at 15:39 +0100, Julien Grall wrote: > > > +csize = SZ_8K; > > > +} > > > + > > > +/* > > > + * Check if the CPU interface and virtual CPU interface have the > > > + * same size. > > > + */ > > > +if ( csize != vsize ) > > > +printk(XENLOG_WARNING "GICv2: WARNING: " > > > + "Sizes of GICC (%#"PRIpaddr") and GICV (%#"PRIpaddr") > > > don't match\n", > > > + csize, vsize); > > > > Should we also force them to be equal? Either > > csize = vsize = min(csize,vsize) > > If we restrict csize we will get to some other troubles later because > vsize may be only 4KB. Does Xen work with that? I suppose so. > > > > WRT to the XXX I think I'd be happier if this was < SZ_8K for each. > > Otherwise some future GIC which is compatible but has extensions to the > > register space would needlessly require changes here. But I can live > > with > > this. > > The GICv2 CPU interface is always at least 8KB. Having an higher value > may mean that the GIC is aliased. Or that this is a GICvN which has 8KB of GICv2 compatible registers and then some extensions. In either that situation or the aliasing one it would be safe to expose the first 8KB as a gic-v2 to the guest. > GICv2 on GICv3 is only used for guest. I prefer to restrict the usage to > known and safe value until we have someone using different size. > > This will avoid to expose unwanted data/value to a guest. Right, I'm not saying we should expose the whole region, just the known to be gic-v2 compatible first 8KB. NB I'm talking about domU here, things are more complicated with dom0 and in that case you are right that it would be a bad idea. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: drop unused config variable CONFIG_HVM
On 05/10/15 20:15, Doug Goldstein wrote: > CONFIG_HVM is not used anywhere in the build process so drop it. > > Signed-off-by: Doug Goldstein Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] flask: Allow initial domain to use XENPF_get_symbol
Daniel De Graaf writes ("Re: [PATCH] flask: Allow initial domain to use
XENPF_get_symbol"):
> On 05/10/15 11:16, Konrad Rzeszutek Wilk wrote:
> > It looks to be missing in the policy file for the initial
> > domain. Eventually we may want to extend this access to
> > non-dom0 domains but for now it certainly dom0-only.
> >
> > Reviewed-by: Boris Ostrovsky
> > Signed-off-by: Konrad Rzeszutek Wilk
>
> Acked-by: Daniel De Graaf
Jan, do you want to commit this ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: LTS and stable release scheme
>>> On 06.10.15 at 16:09, wrote: > What do you propose when we regarding stable branches when we switch to > 6 months cycle? See the chicken-and-egg problem: I can't answer this, because the issues with the stable trees are the main reason I don't support the change to the release cycle (yet). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] Bulk mem-share identical domains
On 06/10/15 15:26, Ian Campbell wrote: > On Sun, 2015-10-04 at 14:25 -0600, Tamas K Lengyel wrote: >> The following patches add a convenience memop to the mem_sharing system, >> allowing for the rapid deduplication of memory pages between identical >> domains. >> >> The envisioned use-case for this is the following: >> 1) Create two domains from the same snapshot using xl. >>This step can also be performed by piping an existing domain's memory >> with >> "xl save -c | xl restore -p " >>It is up for the user to create the appropriate configuration for the >> clone, >>including setting up a CoW-disk as well. >> 2) Enable memory sharing on both domains >> 3) Execute bulk dedup between the domains. > This is a neat trick, but has the downside of first shovelling all the data > over a pipe and then needing to allocate it transiently before dedupping it > again. > > Have you looked at the possibility of doing the save+restore in the same > process with a cut through for the RAM part which just dups the page into > the target domain? > > Once upon a time (migr v1) that would certainly have been impossibly hard, > but with migr v2 it might be a lot easier to integrate something like that > (although surely not as easy as what you've done here!). > > Just an idea, and not intended at all as an argument for not taking this > series or anything. If we are making modifications like this, make something like XEN_DOMCTL_domain_clone which takes a source domid (must exist), pauses it, creates a new domain, copies some state and shares all memory CoW from source to the new domain. This will be far more efficient still than moving all the memory through userspace in dom0. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: remove unused wrappers for python
On 10/06/2015 03:40 PM, Ian Campbell wrote: On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote: And for the record, if my google-fu doesn't fail me, it's possible to load shared library into python interpreter using "dl" module in 2.7 and "ctypes" module in 3.x. Possible, but not especially convenient since you need to convert the C prototype manually, plus the result is not necessarily very "pythonic". I could totally see why people would prefer these bindings (or an argument for us providing a ctypes based wrapper). How often is such a debugging interface being used? Please consider the amount of code (my patch removed nearly 3000 lines of code!) and the availability of the xl wrapper. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: drop unused config variable CONFIG_HVM
Doug Goldstein writes ("[PATCH] build: drop unused config variable CONFIG_HVM"):
> CONFIG_HVM is not used anywhere in the build process so drop it.
This wants a HV maintainer ack I think. CCing Andrew.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: LTS and stable release scheme
>>> On 06.10.15 at 16:12, wrote: > On Tue, Oct 6, 2015 at 2:38 PM, Jan Beulich wrote: >> I'm not sure if it's still that way nowadays, but in the years after >> stable and long term releases got introduced in Linux even long >> term branches weren't all equal: The general stable tree maintainer >> actively argued against the use of certain branches (or certain >> releases on a branch after it changed ownership), due to it being >> of unknown (in the best case) quality. > > Perhaps I'm not familiar enough with what went on with Linux, but I > can't make much sense out of what you're describing here. Are you > saying that the stable tree maintainer would say, "Officially 3.X.Y is > a stable release, but really you shouldn't use it, because it's a bit > dodgy. Use 3.Z.Q or 3.M.N instead." Yes. Or "Use 3.X.Y only up to a certain Y." >> Bottom line: I think the current model, with all releases being >> equal and there being the opportunity to hand over branches to >> "external" maintainers after the XenProject support ended >> (exercised exactly once to date), is quite a bit better than any >> of the LTS options I've seen proposed so far. > > There's no reason that people can't offer to take up specific versions > once they fall off our own LTS. Of course not, and I don't think I ruled this out. It's just that such a branch wouldn't be considered XenProject.org-maintained anymore. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 5/5] standalone: Use fail() from mgi-common in most places
Ian Campbell writes ("[PATCH OSSTEST 5/5] standalone: Use fail() from
mgi-common in most places"):
> Functional change is simply to prepend "$0: ", to change the exit
> code for unknown operation and to slightly alter the error message
> when no arguments are given.
>
> A few "exit 0" and "exit $rc" remain.
>
> Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 4/5] standalone: Make it possible to pass options to run-test
Ian Campbell writes ("[PATCH OSSTEST 4/5] standalone: Make it possible to pass
options to run-test"):
> Currently the remainder of the comnand line is passed after the host=
> ident, which allows for other idents to be given, which isn't all that
> useful in practice.
>
> Instead arrange that any additional options up to a "--" marker are
> passed before host= and anything after are passed after.
...
> - with_logging logs/$flight/$job.$ts.log ./$ts $hosts $@
> + with_logging logs/$flight/$job.$ts.log ./$ts ${options[@]} $hosts $@
You mean ... ./$ts "${options[@]}" $hosts ...
by analogy with "$@"
mariner:~> a=(a "1 2" b)
mariner:~> echo = ${a[@]}
= a 1 2 b
mariner:~> echo = "${a[@]}"
= a 1 2 b
mariner:~>
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 2/5] cs-adjust-flight: Add job-status to report job stats
Ian Campbell writes ("[PATCH OSSTEST 2/5] cs-adjust-flight: Add job-status to
report job stats"):
> The return code of sg-run-job does not reflect the state of the job,
> which is instead written to the database. For the benefit of running
> tests in a loop until failure add a command to retrieve the status to
> stdout.
...
> +job_status() {
> +flight=$1; shift
> +job=$1; shift
> +
> +status=$(OSSTEST_CONFIG=$config \
> + ./cs-adjust-flight $flight job-status $job)
> +echo "$status"
> +}
This is rather odd. Why do you capture the value in a variable and
then pass it to echo ? You could just let the job_status command
print its output directly.
(Also I might quibble about unparsing the arguments to echo. Observe
the output of (say) `echo -n'. printf is often better. This is only
relevant if $status might start with `-' and if you want to keep the
echo.)
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 1/5] cs-adjust-flight: `branch' command ought to be `branch-set'
Ian Campbell writes ("[PATCH OSSTEST 1/5] cs-adjust-flight: `branch' command
ought to be `branch-set'"):
> Also add a doc string and since this op is not a change adjust the doc
> comment accordingly.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] xen/arm: gic: Check the size of the CPU and vCPU interface retrieved from DT
On 06/10/15 15:11, Ian Campbell wrote:
> On Mon, 2015-10-05 at 15:17 +0100, Julien Grall wrote:
>> @@ -641,7 +643,29 @@ static int __init gicv2_init(void)
>> panic("GICv2: Cannot find the maintenance IRQ");
>> gicv2_info.maintenance_irq = res;
>>
>> -/* TODO: Add check on distributor, cpu size */
>> +/* TODO: Add check on distributor */
>> +
>> +/*
>> + * The GICv2 CPU interface should at least be 8KB. Although, most of
>> the DT
>> + * doesn't correctly set it and use the GICv1 CPU interface size (i.e
>> 4KB).
>> + * Warn and then fixup.
>> + */
>> +if ( csize < SZ_8K )
>> +{
>> +printk(XENLOG_WARNING "GICv2: WARNING: "
>> + "The GICC size is wrong: %#"PRIx64" expected %#x\n",
>> + csize, SZ_8K);
>
> "is too small"?
Ok.
>
>> +csize = SZ_8K;
>> +}
>> +
>> +/*
>> + * Check if the CPU interface and virtual CPU interface have the
>> + * same size.
>> + */
>> +if ( csize != vsize )
>> +printk(XENLOG_WARNING "GICv2: WARNING: "
>> + "Sizes of GICC (%#"PRIpaddr") and GICV (%#"PRIpaddr") don't
>> match\n",
>> + csize, vsize);
>
> Should we also force them to be equal? Either
> csize = vsize = min(csize,vsize)
If we restrict csize we will get to some other troubles later because
vsize may be only 4KB.
> or
> vsize = csize
>
> (probably the first)?
None of them.
>
>> +/*
>> + * Only allow support of GICv2 compatible when the CPU interface
>> + * and virtual CPU interface are 8KB
>> + * XXX: Handle other size?
>> + */
>> +if ( csize != SZ_8K && vsize != SZ_8K )
>
> I think you meant || ? Otherwise this is happy so long as one of them is
> right rather than requiring both of them to be 8K.
Right.
>
> WRT to the XXX I think I'd be happier if this was < SZ_8K for each.
> Otherwise some future GIC which is compatible but has extensions to the
> register space would needlessly require changes here. But I can live with
> this.
The GICv2 CPU interface is always at least 8KB. Having an higher value
may mean that the GIC is aliased.
GICv2 on GICv3 is only used for guest. I prefer to restrict the usage to
known and safe value until we have someone using different size.
This will avoid to expose unwanted data/value to a guest.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] Bulk mem-share identical domains
On Sun, 2015-10-04 at 14:25 -0600, Tamas K Lengyel wrote: > The following patches add a convenience memop to the mem_sharing system, > allowing for the rapid deduplication of memory pages between identical > domains. > > The envisioned use-case for this is the following: > 1) Create two domains from the same snapshot using xl. >This step can also be performed by piping an existing domain's memory > with > "xl save -c | xl restore -p " >It is up for the user to create the appropriate configuration for the > clone, >including setting up a CoW-disk as well. > 2) Enable memory sharing on both domains > 3) Execute bulk dedup between the domains. This is a neat trick, but has the downside of first shovelling all the data over a pipe and then needing to allocate it transiently before dedupping it again. Have you looked at the possibility of doing the save+restore in the same process with a cut through for the RAM part which just dups the page into the target domain? Once upon a time (migr v1) that would certainly have been impossibly hard, but with migr v2 it might be a lot easier to integrate something like that (although surely not as easy as what you've done here!). Just an idea, and not intended at all as an argument for not taking this series or anything. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] tests/mem-sharing: Add bulk option to memshrtool
On Tue, 2015-10-06 at 10:20 +0100, Wei Liu wrote: > An unrelated note: do you think it make sense to move mem-sharing out of > tests/ ? It doesn't look like a test to me. It was originally a sort of "unit test" / "manually poke it" type utility rather than end user usable functionality. That might have changed though (or be in the process of doing so). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 7/9] xen/arm: vgic: Optimize the way to store the target vCPU in the rank
On 06/10/15 14:59, Ian Campbell wrote: > On Mon, 2015-10-05 at 13:51 +0100, Julien Grall wrote: >> Xen is currently directly storing the value of GICD_ITARGETSR register >> (for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the >> emulation of the registers access very simple but makes the code to get >> the target vCPU for a given vIRQ more complex. >> >> While the target vCPU of an vIRQ is retrieved every time an vIRQ is >> injected to the guest, the access to the register occurs less often. >> >> So the data structure should be optimized for the most common case >> rather than the inverse. >> >> This patch introduces the usage of an array to store the target vCPU for >> every interrupt in the rank. This will make the code to get the target >> very quick. The emulation code will now have to generate the >> GICD_ITARGETSR >> and GICD_IROUTER register for read access and split it to store in a >> convenient way. >> >> With the new way to store the target vCPU, the structure vgic_irq_rank >> is shrinked down from 320 bytes to 92 bytes. This is saving about 228 > > "shrunk" > >> bytes of memory allocated separately per vCPU. >> >> Note that with these changes, any read to those registers will list only >> the target vCPU used by Xen. This is fine because the GIC spec doesn't >> require to return exactly the value written and it can be seen as if we >> decide to implement the register read-only. > > I'd prefer if instead of "this is fine..." this said something like "We > think this is likely to be OK because...(stuff)...". Will do. I will resend the whole series fixing the different error you mentioned within the series and add your various acked. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: LTS and stable release scheme
On Tue, Oct 6, 2015 at 2:38 PM, Jan Beulich wrote: > I'm not sure if it's still that way nowadays, but in the years after > stable and long term releases got introduced in Linux even long > term branches weren't all equal: The general stable tree maintainer > actively argued against the use of certain branches (or certain > releases on a branch after it changed ownership), due to it being > of unknown (in the best case) quality. Perhaps I'm not familiar enough with what went on with Linux, but I can't make much sense out of what you're describing here. Are you saying that the stable tree maintainer would say, "Officially 3.X.Y is a stable release, but really you shouldn't use it, because it's a bit dodgy. Use 3.Z.Q or 3.M.N instead." > Bottom line: I think the current model, with all releases being > equal and there being the opportunity to hand over branches to > "external" maintainers after the XenProject support ended > (exercised exactly once to date), is quite a bit better than any > of the LTS options I've seen proposed so far. There's no reason that people can't offer to take up specific versions once they fall off our own LTS. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] xen/arm: gic: Check the size of the CPU and vCPU interface retrieved from DT
On Mon, 2015-10-05 at 15:17 +0100, Julien Grall wrote:
> @@ -641,7 +643,29 @@ static int __init gicv2_init(void)
> panic("GICv2: Cannot find the maintenance IRQ");
> gicv2_info.maintenance_irq = res;
>
> -/* TODO: Add check on distributor, cpu size */
> +/* TODO: Add check on distributor */
> +
> +/*
> + * The GICv2 CPU interface should at least be 8KB. Although, most of the
> DT
> + * doesn't correctly set it and use the GICv1 CPU interface size (i.e
> 4KB).
> + * Warn and then fixup.
> + */
> +if ( csize < SZ_8K )
> +{
> +printk(XENLOG_WARNING "GICv2: WARNING: "
> + "The GICC size is wrong: %#"PRIx64" expected %#x\n",
> + csize, SZ_8K);
"is too small"?
> +csize = SZ_8K;
> +}
> +
> +/*
> + * Check if the CPU interface and virtual CPU interface have the
> + * same size.
> + */
> +if ( csize != vsize )
> +printk(XENLOG_WARNING "GICv2: WARNING: "
> + "Sizes of GICC (%#"PRIpaddr") and GICV (%#"PRIpaddr") don't
> match\n",
> + csize, vsize);
Should we also force them to be equal? Either
csize = vsize = min(csize,vsize)
or
vsize = csize
(probably the first)?
> +/*
> + * Only allow support of GICv2 compatible when the CPU interface
> + * and virtual CPU interface are 8KB
> + * XXX: Handle other size?
> + */
> +if ( csize != SZ_8K && vsize != SZ_8K )
I think you meant || ? Otherwise this is happy so long as one of them is
right rather than requiring both of them to be 8K.
WRT to the XXX I think I'd be happier if this was < SZ_8K for each.
Otherwise some future GIC which is compatible but has extensions to the
register space would needlessly require changes here. But I can live with
this.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
