[Xen-devel] [ovmf test] 99912: all pass - PUSHED
flight 99912 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/99912/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 846ea5f537c8f8313abb2f8f29794d13ac4becec baseline version: ovmf a6d594c5fabd8da2273d2794826ec086cf9c3c04 Last test of basis99910 2016-08-02 23:15:13 Z0 days Testing same since99912 2016-08-03 01:45:58 Z0 days1 attempts People who touched revisions under test: Dong, EricEric Dong Giri P Mudusuru jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 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=ovmf + revision=846ea5f537c8f8313abb2f8f29794d13ac4becec + . ./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 ovmf 846ea5f537c8f8313abb2f8f29794d13ac4becec + branch=ovmf + revision=846ea5f537c8f8313abb2f8f29794d13ac4becec + . ./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=ovmf + xenbranch=xen-unstable + '[' xovmf = xlinux ']' + linuxbranch= + '[' x = x ']' + qemuubranch=qemu-upstream-unstable + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable + prevxenbranch=xen-4.7-testing + '[' x846ea5f537c8f8313abb2f8f29794d13ac4becec = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/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
Re: [Xen-devel] [PATCH] xen: use a common function for pv and hvm guest backend register calls
On 02/08/16 20:27, Stefano Stabellini wrote: > On Tue, 2 Aug 2016, Juergen Gross wrote: >> Instead of calling xen_be_register() for each supported backend type >> for hvm and pv guests in their machine init functions use a common >> function in order not to have to add new backends twice. >> >> This at once fixes the error that hvm domains couldn't use the qusb >> backend. >> >> Signed-off-by: Juergen Gross>> --- >> Is it on purpose the qnic and vfb backends are not registered for HVM? > > Yes, it is on purpose: there is no code in any toolstacks to use qnic, > and the presence of vfb can cause problems to Linux HVM guests (or at > least it used to), additionally vfb for HVM guests is also disabled in > libxl. > > In general, it is a good idea to disable code that is not supposed to be > used. > > Can qusb be used with HVM guests with libxl/xl? Yes. You have to specify "type=qusb" for usbctrl, then it will work. I have verified that. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 66892: trouble: blocked/broken/pass
This run is configured for baseline tests only. flight 66892 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66892/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken REGR. vs. 66890 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a6d594c5fabd8da2273d2794826ec086cf9c3c04 baseline version: ovmf 8265373e60ad79acd4a20affe2c49470c68d6a9c Last test of basis66890 2016-08-02 23:20:21 Z0 days Testing same since66892 2016-08-03 01:49:39 Z0 days1 attempts People who touched revisions under test: Cinnamon Shiajobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 broken build-i386 pass build-amd64-libvirt blocked build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary broken-step build-amd64 host-install(3) Push not applicable. commit a6d594c5fabd8da2273d2794826ec086cf9c3c04 Author: Cinnamon Shia Date: Wed Aug 3 01:25:10 2016 +0800 OvmfPkg: use StatusCode Router and Handler from MdeModulePkg In the Platform Init v1.4a spec, - Volume 1 "4.7 Status Code Service" defines the EFI_PEI_SERVICES.ReportStatusCode() service, - Volume 1 "6.3.5 Status Code PPI (Optional)" defines the EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above), - Volume 2 "14.2 Status Code Runtime Protocol" defines the EFI_STATUS_CODE_PROTOCOL. These allow PEIMs and DXE (and later) modules to report status codes. Currently OvmfPkg uses modules from under "IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above abstractions (PPI and PROTOCOL) directly, and write the status codes, as they are reported, to the serial port or to a memory buffer. This is called "handling" the status codes. In the Platform Init v1.4a spec, - Volume 3 "7.2.2 Report Status Code Handler PPI" defines EFI_PEI_RSC_HANDLER_PPI, - Volume 3 "7.2.1 Report Status Code Handler Protocol" defines EFI_RSC_HANDLER_PROTOCOL. These allow several PEIMs and runtime DXE drivers to register callbacks for status code handling. MdeModulePkg offers a PEIM under "MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe" that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL. MdeModulePkg also offers status code handler modules under MdeModulePkg/Universal/StatusCodeHandler/ that depend on EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively. The StatusCodeHandler modules register themselves with ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI / EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches the phase-matching ReportStatusCodeRouter module first, which in turn passes the status code to the pre-registered, phase-matching StatusCodeHandler module. The status code handling in the StatusCodeHandler modules is identical to the one currently provided by the IntelFrameworkModulePkg modules. Replace the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can decrease our dependency on IntelFrameworkModulePkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia
Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection
> On 25/07/16 07:09, Kang, Luwei wrote: > First of all - please don't top post. > > > What about remove the dependency between AVX2 and AVX512F > >> ( AVX2: > [AVX512F], ) ? > > Yes, that's what I think we want, but we need Andrew's agreement here. > > >>> Hi Andrew, what is your opinion ? > >> You are in a better position to answer than me. > >> > >> For a specific instruction which may be VEX and EVEX encoded, is the > >> circuitry for a specific instruction shared, or discrete? Is there a > >> plausible future where you might support only the EVEX variant of an > >> instruction, and not the VEX variant? > >> > >> These dependences are about what may be reasonably assumed about the > >> way the environment is structured. It doesn't look reasonable to > >> advertise an AVX512 environment to guests while at the same time > >> stating that AVX2 is not present. If this is correct, then the dependency > >> should stay. > >> If Intel plausibly things it might release hardware with !AVX2 but > >> AVX512, then the dependency should be dropped. > > Regarding the dependency between AVX2 and AVX512F, I have ask some hardware > > architecture engineer. > > > > AVX512 is a superset of AVX2, the most important item being the state. If > > the state for AVX2 isn't enabled (in XCR0), then AVX512 > also can't function. > > > > So if we want to use AVX512, AVX2 must be supported and enabled. The > > dependence between AVX512F and AVX2 may need be > reserved. > > Ok, so AVX512 strictly depends on AVX2. > > In which case, the python code was correct. The meaning of the key/value > relationship is "if the feature in the key is not present, all > features in the value must also be disabled". Hi jan, what is your opinion? > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] tools:libxl: return tty path for all serials
When specifying a serial list in domain config, users of libxl_console_get_tty cannot get the tty path of a second specified pty serial, since right now it always returns the tty path of serial 0. Signed-off-by: Bob Liu--- tools/libxl/libxl.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 2cf7451..00af286 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1795,7 +1795,7 @@ int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, switch (type) { case LIBXL_CONSOLE_TYPE_SERIAL: -tty_path = GCSPRINTF("%s/serial/0/tty", dom_path); +tty_path = GCSPRINTF("%s/serial/%d/tty", dom_path, cons_num); break; case LIBXL_CONSOLE_TYPE_PV: if (cons_num == 0) -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 99910: all pass - PUSHED
flight 99910 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/99910/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf a6d594c5fabd8da2273d2794826ec086cf9c3c04 baseline version: ovmf 8265373e60ad79acd4a20affe2c49470c68d6a9c Last test of basis99908 2016-08-02 17:49:34 Z0 days Testing same since99910 2016-08-02 23:15:13 Z0 days1 attempts People who touched revisions under test: Cinnamon Shiajobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 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=ovmf + revision=a6d594c5fabd8da2273d2794826ec086cf9c3c04 + . ./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 ovmf a6d594c5fabd8da2273d2794826ec086cf9c3c04 + branch=ovmf + revision=a6d594c5fabd8da2273d2794826ec086cf9c3c04 + . ./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=ovmf + xenbranch=xen-unstable + '[' xovmf = xlinux ']' + linuxbranch= + '[' x = x ']' + qemuubranch=qemu-upstream-unstable + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable + prevxenbranch=xen-4.7-testing + '[' xa6d594c5fabd8da2273d2794826ec086cf9c3c04 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/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
[Xen-devel] [xen-4.6-testing baseline-only test] 66887: tolerable trouble: broken/fail/pass
This run is configured for baseline tests only. flight 66887 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66887/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken blocked in 66869 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken blocked in 66869 test-amd64-amd64-rumpuserxen-amd64 3 host-install(3) broken blocked in 66869 test-amd64-i386-libvirt-xsm 3 host-install(3)broken blocked in 66869 test-amd64-amd64-xl-pvh-amd 3 host-install(3)broken blocked in 66869 test-amd64-amd64-xl-multivcpu 3 host-install(3) broken blocked in 66869 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken blocked in 66869 test-amd64-amd64-i386-pvgrub 3 host-install(3)broken blocked in 66869 test-amd64-amd64-libvirt-vhd 3 host-install(3)broken blocked in 66869 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken blocked in 66869 test-amd64-amd64-pygrub 3 host-install(3)broken blocked in 66869 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken blocked in 66869 test-amd64-amd64-libvirt-xsm 3 host-install(3)broken blocked in 66869 test-amd64-amd64-xl-qcow2 3 host-install(3)broken blocked in 66869 test-amd64-i386-libvirt-pair 4 host-install/dst_host(4) broken blocked in 66869 test-amd64-amd64-migrupgrade 4 host-install/dst_host(4) broken blocked in 66869 test-amd64-i386-migrupgrade 4 host-install/dst_host(4) broken blocked in 66869 test-amd64-amd64-pair 4 host-install/dst_host(4) broken blocked in 66869 test-amd64-amd64-libvirt-pair 4 host-install/dst_host(4) broken blocked in 66869 test-amd64-amd64-libvirt-pair 3 host-install/src_host(3) broken blocked in 66869 test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail blocked in 66869 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 8 leak-check/basis(8) fail blocked in 66869 test-amd64-amd64-amd64-pvgrub 10 guest-start fail blocked in 66869 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail blocked in 66869 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-saverestore.2 fail blocked in 66869 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stopfail blocked in 66869 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 66869 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail blocked in 66869 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 66869 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for
[Xen-devel] [ovmf baseline-only test] 66890: regressions - FAIL
This run is configured for baseline tests only. flight 66890 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66890/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-build fail REGR. vs. 66888 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 8265373e60ad79acd4a20affe2c49470c68d6a9c baseline version: ovmf 8134f7d9d2654a49916f627783c956f3eca78421 Last test of basis66888 2016-08-02 17:48:24 Z0 days Testing same since66890 2016-08-02 23:20:21 Z0 days1 attempts People who touched revisions under test: Ard BiesheuvelLaszlo Ersek Satya Yarlagadda Yarlagadda, Satya P Yonghong Zhu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 fail build-i386 pass build-amd64-libvirt blocked build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 8265373e60ad79acd4a20affe2c49470c68d6a9c Author: Yarlagadda, Satya P Date: Mon Aug 1 19:41:34 2016 +0800 IntelFsp2Pkg: Locate FSP Info Header dynamically we need to locate the FSP Info Header by calculating offset dynamically to handle the scenario of FSP component is being rebased to different location. Cc: Maurice Ma Cc: Jiewen Yao Cc: Giri P Mudusuru Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Satya Yarlagadda Reviewed-by: Maurice Ma Reviewed-by: Jiewen Yao Reviewed-by: Giri P Mudusuru commit d54e2d6c1e68f2edfa06a6a331e808f109df779f Author: Ard Biesheuvel Date: Tue Aug 2 12:08:03 2016 +0200 ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: deal with relaxed XIP alignment Commit b89919ee8f8c ("BaseTools AARCH64: override XIP module linker alignment to 32 bytes") updated the various AARCH64 toolchain definitions to allow SEC, PEI_CORE and PEIM modules to be built with minimal alignment requirements even when using the AArch64 small code model which normally requires 4 KB section alignment. This involves conversion of ADRP instructions into ADR instructions, which can only be done reliably if the ELF and the PE/COFF sections appear at the same offset modulo 4 KB. The ArmVirtPrePiUniCoreRelocatable linker script did not yet take this into account, so update it by starting the .text section at the next appropriately aligned offset PECOFF_HEADER_SIZE bytes into the image. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Acked-by: Laszlo Ersek commit e5cf919889b92a5fb89638ea10cebbb3ef59b5c7 Author: Yonghong Zhu Date: Tue Jul 26 15:17:15 2016 +0800 BaseTools: Keep the Pcd order in the Asbuilt Inf is same with Source The original behavior is that in the Asbuilt inf Pcd's order is base on the Pcd's offset. Now we change the order to keep it is same with the Pcd order in the source inf file. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu Reviewed-by: Liming Gao
[Xen-devel] [DRAFT v4] PV Calls protocol design document (former XenSock)
Hi all, This is the design document of the PV Calls protocol. You can find prototypes of the Linux frontend and backend drivers here: git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-4 To use them, make sure to enable CONFIG_PVCALLS in your kernel config and add "pvcalls=1" to the command line of your DomU Linux kernel. You also need the toolstack to create the initial xenstore nodes for the protocol. To do that, please apply the attached patch to libxl (the patch is based on Xen 4.7.0-rc3) and add "pvcalls=1" to your DomU config file. Note that previous versions of the protocols were named XenSock. It has been renamed for clarity of scope and to avoid confusion with hv_sock and vsock, which are used for inter-VMs communications. Cheers, Stefano Changes in v4: - rename xensock to pvcalls Changes in v3: - add a dummy element to struct xen_xensock_request to make sure the size of the struct is the same on both x86_32 and x86_64 Changes in v2: - add max-dataring-page-order - add "Publish backend features and transport parameters" to backend xenbus workflow - update new cmd values - update xen_xensock_request - add backlog parameter to listen and binary layout - add description of new data ring format (interface+data) - modify connect and accept to reflect new data ring format - add link to POSIX docs - add error numbers - add address format section and relevant numeric definitions - add explicit mention of unimplemented commands - add protocol node name - add xenbus shutdown diagram - add socket operation --- # PV Calls Protocol ## Rationale PV Calls is a paravirtualized protocol for the POSIX socket API. The purpose of PV Calls is to allow the implementation of a specific set of POSIX functions to be done in a domain other than your own. It allows connect, accept, bind, release, listen, poll, recvmsg and sendmsg to be implemented in another domain. PV Calls provides the following benefits: * guest networking works out of the box with VPNs, wireless networks and any other complex configurations on the host * guest services listen on ports bound directly to the backend domain IP addresses * localhost becomes a secure namespace for inter-VMs communications * full visibility of the guest behavior on the backend domain, allowing for inexpensive filtering and manipulation of any guest calls * excellent performance ## Design ### Xenstore The frontend and the backend connect to each other exchanging information via xenstore. The toolstack creates front and back nodes with state XenbusStateInitialising. The protocol node name is **pvcalls**. There can only be one PV Calls frontend per domain. Frontend XenBus Nodes port Values: The identifier of the Xen event channel used to signal activity in the ring buffer. ring-ref Values: The Xen grant reference granting permission for the backend to map the sole page in a single page sized ring buffer. Backend XenBus Nodes max-dataring-page-order Values: The maximum supported size of the data ring in units of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages, etc.). State Machine Initialization: *Front* *Back* XenbusStateInitialising XenbusStateInitialising - Query virtual device- Query backend device properties. identification data. - Setup OS device instance. - Publish backend features - Allocate and initialize the and transport parameters request ring. | - Publish transport parameters | that will be in effect during V this connection.XenbusStateInitWait | | V XenbusStateInitialised - Query frontend transport parameters. - Connect to the request ring and event channel. | | V XenbusStateConnected - Query backend device properties. - Finalize OS virtual device instance. | | V XenbusStateConnected Once frontend and backend are connected, they have a shared page, which will is used to exchange messages over a ring, and an event channel, which is used to send notifications. Shutdown: *Front**Back* XenbusStateConnected XenbusStateConnected | | V XenbusStateClosing
[Xen-devel] [xen-unstable test] 99906: tolerable FAIL - PUSHED
flight 99906 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/99906/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 99897 build-i386-rumpuserxen6 xen-buildfail like 99897 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 99897 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 99897 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99897 test-amd64-amd64-xl-rtds 9 debian-install fail like 99897 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 99897 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-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 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 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass version targeted for testing: xen 2eee1c746af6f683247700642786b7c21c991234 baseline version: xen caefc852d5a3be3965a0c0131ce62e7f3a313f04 Last test of basis99897 2016-08-02 07:33:22 Z0 days Testing same since99906 2016-08-02 15:19:48 Z0 days1 attempts People who touched revisions under test: Andrew Cooperjobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-prev
[Xen-devel] [ovmf test] 99908: all pass - PUSHED
flight 99908 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/99908/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8265373e60ad79acd4a20affe2c49470c68d6a9c baseline version: ovmf 8134f7d9d2654a49916f627783c956f3eca78421 Last test of basis99903 2016-08-02 10:47:05 Z0 days Testing same since99908 2016-08-02 17:49:34 Z0 days1 attempts People who touched revisions under test: Ard BiesheuvelLaszlo Ersek Satya Yarlagadda Yarlagadda, Satya P Yonghong Zhu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 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=ovmf + revision=8265373e60ad79acd4a20affe2c49470c68d6a9c + . ./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 ovmf 8265373e60ad79acd4a20affe2c49470c68d6a9c + branch=ovmf + revision=8265373e60ad79acd4a20affe2c49470c68d6a9c + . ./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=ovmf + xenbranch=xen-unstable + '[' xovmf = xlinux ']' + linuxbranch= + '[' x = x ']' + qemuubranch=qemu-upstream-unstable + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable + prevxenbranch=xen-4.7-testing + '[' x8265373e60ad79acd4a20affe2c49470c68d6a9c = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/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"}
Re: [Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings
On Tue, Aug 2, 2016 at 4:05 PM, Julien Grallwrote: > > > On 02/08/2016 22:34, Tamas K Lengyel wrote: >> >> On Tue, Aug 2, 2016 at 2:02 PM, Julien Grall wrote: >>> >>> Hello Tamas, >>> >>> Thank you for taking care of this bug. >>> >>> On 02/08/2016 19:53, Tamas K Lengyel wrote: When mem_access settings change, the active vCPUs may still cause a violation until the TLB gets flushed. Instead of just reinjecting the violation to the guest, in this patch we direct the vCPU to retry the access where appropriate or we crash the domain where the mem_access settings are corrupted. >>> >>> With this patch p2m_mem_access_check will always return false. So I am >>> not >>> sure why you want to return in p2m_mem_access_check. >> >> >> That's not the case, it returns true if mem_access is not enabled on >> the domain, which means whatever caused the trap wasn't mem_access and >> thus we should fall back on the default behavior, which is injecting >> the fault to the guest. >> >>> >>> Requested-by: Julien Grall Signed-off-by: Tamas K Lengyel --- Cc: Stefano Stabellini Cc: Julien Grall --- xen/arch/arm/p2m.c | 29 ++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 40a0b80..a4b6b7b 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -1657,8 +1657,26 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec) return true; rc = p2m_get_mem_access(v->domain, _gfn(paddr_to_pfn(gpa)), ); -if ( rc ) -return true; +switch (rc ) +{ +case -ESRCH: +/* + * If we can't find any mem_access setting for this page then the page + * might have just been removed and the event was triggered by no longer + * valid settings. The vCPU should just retry to get to the proper error + * path. + */ +return false; +case -ERANGE: +/* + * The mem_access settings are corrupted. Crashing the domain is the + * appropriate step in this case. + */ +domain_crash(v->domain); +return false; +}; + +ASSERT(!rc); >>> >>> >>> >>> It would be easier to do: >>> >>> rc = p2m_mem_access_check(gpa, gva, npfec); >>> if (!rc) >>> return; >>> >>> by >>> >>> p2m_mem_access_check(gpa, gva, npfec); >>> return; >>> >>> in both do_trap_instr_abort_guest and do_trap_data_abort_guest. >>> >>> This would also helps to fallback on another permission check if in the >>> future we decide to use permission for other reasons. >>> >>> Or is there any reason you may want to inject a data abort to the guest >>> if >>> memaccess has failed (i.e return true)? >>> >> >> Yes, if the fault wasn't caused by mem_access (ie. it's not enabled on >> the domain). > > > Well, the data abort can only be a permission fault if memaccess is inuse so > far. Unless there is another race condition in the memaccess code and in > this case this is not the fault of the guest. So sending a data abort to the > guest will not really help to know what's going on. From my perspective it doesn't matter whether the fault is injected into the guest or not when mem_access is not in use. Since that's the default behavior right now, my opinion is that it should get reinjected but that's beyond the scope of mem_access itself so it's up to you to decide. If you really prefer to have the mem_access check just be a void function and not inject a fault to the guest, I'm certainly fine with that. > Also, you are assuming that it will never be possible in the future to have > another usage of the permission fault. By returning false you say "I handled > the fault, it is not necessary to hand over to someone else". I only return false here if mem_access is enabled. If any other system in the future is going to make use of these permissions then it needs to be carefully evaluated what the handover setup should be when the mem_access state doesn't seem to be the reason for the violation. I can forsee some issues if one system would like the instruction to be reexecuted while the other to do something else. As this all being hypothetical at this point I don't really know what to do with this right now. > The right thing here is: > 1) Try to handle memaccess > 2) Re-execute the instruction > > The instruction will fault again if it was really a permission issue. > Otherwise it will normally be executed. And that's what this patch does. If mem_access is enabled it will try to handle it, but if something doesn't add
Re: [Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings
On 02/08/2016 22:34, Tamas K Lengyel wrote: On Tue, Aug 2, 2016 at 2:02 PM, Julien Grallwrote: Hello Tamas, Thank you for taking care of this bug. On 02/08/2016 19:53, Tamas K Lengyel wrote: When mem_access settings change, the active vCPUs may still cause a violation until the TLB gets flushed. Instead of just reinjecting the violation to the guest, in this patch we direct the vCPU to retry the access where appropriate or we crash the domain where the mem_access settings are corrupted. With this patch p2m_mem_access_check will always return false. So I am not sure why you want to return in p2m_mem_access_check. That's not the case, it returns true if mem_access is not enabled on the domain, which means whatever caused the trap wasn't mem_access and thus we should fall back on the default behavior, which is injecting the fault to the guest. Requested-by: Julien Grall Signed-off-by: Tamas K Lengyel --- Cc: Stefano Stabellini Cc: Julien Grall --- xen/arch/arm/p2m.c | 29 ++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 40a0b80..a4b6b7b 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -1657,8 +1657,26 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec) return true; rc = p2m_get_mem_access(v->domain, _gfn(paddr_to_pfn(gpa)), ); -if ( rc ) -return true; +switch (rc ) +{ +case -ESRCH: +/* + * If we can't find any mem_access setting for this page then the page + * might have just been removed and the event was triggered by no longer + * valid settings. The vCPU should just retry to get to the proper error + * path. + */ +return false; +case -ERANGE: +/* + * The mem_access settings are corrupted. Crashing the domain is the + * appropriate step in this case. + */ +domain_crash(v->domain); +return false; +}; + +ASSERT(!rc); It would be easier to do: rc = p2m_mem_access_check(gpa, gva, npfec); if (!rc) return; by p2m_mem_access_check(gpa, gva, npfec); return; in both do_trap_instr_abort_guest and do_trap_data_abort_guest. This would also helps to fallback on another permission check if in the future we decide to use permission for other reasons. Or is there any reason you may want to inject a data abort to the guest if memaccess has failed (i.e return true)? Yes, if the fault wasn't caused by mem_access (ie. it's not enabled on the domain). Well, the data abort can only be a permission fault if memaccess is inuse so far. Unless there is another race condition in the memaccess code and in this case this is not the fault of the guest. So sending a data abort to the guest will not really help to know what's going on. Also, you are assuming that it will never be possible in the future to have another usage of the permission fault. By returning false you say "I handled the fault, it is not necessary to hand over to someone else". The right thing here is: 1) Try to handle memaccess 2) Re-execute the instruction The instruction will fault again if it was really a permission issue. Otherwise it will normally be executed. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings
On Tue, Aug 2, 2016 at 2:02 PM, Julien Grallwrote: > Hello Tamas, > > Thank you for taking care of this bug. > > On 02/08/2016 19:53, Tamas K Lengyel wrote: >> >> When mem_access settings change, the active vCPUs may still cause a >> violation >> until the TLB gets flushed. Instead of just reinjecting the violation to >> the >> guest, in this patch we direct the vCPU to retry the access where >> appropriate or we crash the domain where the mem_access settings are >> corrupted. >> > > With this patch p2m_mem_access_check will always return false. So I am not > sure why you want to return in p2m_mem_access_check. That's not the case, it returns true if mem_access is not enabled on the domain, which means whatever caused the trap wasn't mem_access and thus we should fall back on the default behavior, which is injecting the fault to the guest. > > >> Requested-by: Julien Grall >> Signed-off-by: Tamas K Lengyel >> --- >> Cc: Stefano Stabellini >> Cc: Julien Grall >> --- >> xen/arch/arm/p2m.c | 29 ++--- >> 1 file changed, 26 insertions(+), 3 deletions(-) >> >> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c >> index 40a0b80..a4b6b7b 100644 >> --- a/xen/arch/arm/p2m.c >> +++ b/xen/arch/arm/p2m.c >> @@ -1657,8 +1657,26 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t >> gla, const struct npfec npfec) >> return true; >> >> rc = p2m_get_mem_access(v->domain, _gfn(paddr_to_pfn(gpa)), ); >> -if ( rc ) >> -return true; >> +switch (rc ) >> +{ >> +case -ESRCH: >> +/* >> + * If we can't find any mem_access setting for this page then the >> page >> + * might have just been removed and the event was triggered by no >> longer >> + * valid settings. The vCPU should just retry to get to the >> proper error >> + * path. >> + */ >> +return false; >> +case -ERANGE: >> +/* >> + * The mem_access settings are corrupted. Crashing the domain is >> the >> + * appropriate step in this case. >> + */ >> +domain_crash(v->domain); >> +return false; >> +}; >> + >> +ASSERT(!rc); > > > It would be easier to do: > > rc = p2m_mem_access_check(gpa, gva, npfec); > if (!rc) > return; > > by > > p2m_mem_access_check(gpa, gva, npfec); > return; > > in both do_trap_instr_abort_guest and do_trap_data_abort_guest. > > This would also helps to fallback on another permission check if in the > future we decide to use permission for other reasons. > > Or is there any reason you may want to inject a data abort to the guest if > memaccess has failed (i.e return true)? > Yes, if the fault wasn't caused by mem_access (ie. it's not enabled on the domain). Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 99909: tolerable all pass - PUSHED
flight 99909 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/99909/ 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 e9522e4932aaa7f083688b6612b5897839409260 baseline version: xen 8746f06cbeef6ff1b0e9f413a222ebf00718b3f9 Last test of basis99907 2016-08-02 16:02:38 Z0 days Testing same since99909 2016-08-02 19:03:26 Z0 days1 attempts People who touched revisions under test: Andrew CooperGeorge Dunlap Ian Jackson Jan Beulich Jim Fehlig Juergen Gross Paul Durrant Roger Pau Monne Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable-smoke + revision=e9522e4932aaa7f083688b6612b5897839409260 + . ./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 e9522e4932aaa7f083688b6612b5897839409260 + branch=xen-unstable-smoke + revision=e9522e4932aaa7f083688b6612b5897839409260 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable-smoke + qemuubranch=qemu-upstream-unstable + '[' xxen = xlinux ']' + linuxbranch= + '[' xqemu-upstream-unstable = x ']' + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable-smoke + prevxenbranch=xen-4.7-testing + '[' xe9522e4932aaa7f083688b6612b5897839409260 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/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
[Xen-devel] [xen-unstable baseline-only test] 66886: regressions - trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 66886 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66886/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 3 host-install(3) broken REGR. vs. 66882 test-amd64-amd64-pygrub 3 host-install(3) broken REGR. vs. 66882 test-amd64-amd64-xl-qcow2 3 host-install(3) broken REGR. vs. 66882 test-amd64-amd64-migrupgrade 4 host-install/dst_host(4) broken REGR. vs. 66882 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 66882 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 66882 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 66882 test-amd64-amd64-i386-pvgrub 10 guest-start fail REGR. vs. 66882 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 3 host-install(3) broken REGR. vs. 66882 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken like 66882 test-amd64-amd64-xl-credit2 3 host-install(3) broken like 66882 test-amd64-amd64-qemuu-nested-amd 3 host-install(3) broken like 66882 test-amd64-amd64-pair 4 host-install/dst_host(4) broken like 66882 test-amd64-amd64-libvirt-vhd 3 host-install(3) broken like 66882 build-i3863 host-install(3) broken like 66882 build-amd64-rumpuserxen 6 xen-buildfail like 66882 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66882 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a build-i386-rumpuserxen1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a 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-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass
[Xen-devel] [qemu-mainline test] 99904: tolerable FAIL - PUSHED
flight 99904 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/99904/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99892 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 99892 test-amd64-amd64-xl-rtds 9 debian-install fail like 99892 test-armhf-armhf-xl-rtds 11 guest-start fail like 99892 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass version targeted for testing: qemuu8b54a6a6c63dc84f2744f6b125c1a6c5a16ee10b baseline version: qemuucc0100f464c94bf80ad36cd432f4a1ed58126b60 Last test of basis99892 2016-08-01 19:44:19 Z1 days Testing same since99904 2016-08-02 12:43:48 Z0 days1 attempts People who touched revisions under test: Eduardo HabkostIgor Mammedov Peter Maydell jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
[Xen-devel] [ovmf baseline-only test] 66888: trouble: blocked/broken/pass
This run is configured for baseline tests only. flight 66888 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66888/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvops 3 host-install(3) broken REGR. vs. 66885 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 8134f7d9d2654a49916f627783c956f3eca78421 baseline version: ovmf 28ade7b802e0732cf9839017ee6e9cf78b842582 Last test of basis66885 2016-08-02 10:48:15 Z0 days Testing same since66888 2016-08-02 17:48:24 Z0 days1 attempts People who touched revisions under test: Ard BiesheuvelArd Biesheuvel # ARM Jordan Justen Laszlo Ersek Leif Lindholm # AArch64 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-pvopsbroken build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary broken-step build-amd64-pvops host-install(3) Push not applicable. commit 8134f7d9d2654a49916f627783c956f3eca78421 Author: Ard Biesheuvel Date: Tue Aug 2 11:16:44 2016 +0200 ShellBinPkg Arm/AArch64 Shell binary update The binaries of ShellBinPkg are generated with ShellPkg from b89919ee8f8c ("BaseTools AARCH64: override XIP module linker alignment to 32 bytes") Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm Tested-by: Leif Lindholm # AArch64 Tested-by: Ard Biesheuvel # ARM commit b89919ee8f8c9441c3514a3c5f352c0901103569 Author: Ard Biesheuvel Date: Wed Jul 27 12:08:20 2016 +0200 BaseTools AARCH64: override XIP module linker alignment to 32 bytes Now that GenFw converts small code model ADRP instructions to ADR on the fly, we can reduce the alignment for XIP modules, where large alignment values may cause considerable waste of flash space due to excessive padding. This limits the module size to 1 MB, but this is not a concern in practice. So set the XIP section alignment to 0x20 for DEBUG_GCC49, DEBUG_GCC5 and *_CLANG35, all of which use the small code model. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm commit 026a82abf0bd6268d32f4559dbede00715264f74 Author: Ard Biesheuvel Date: Tue Jul 26 16:37:37 2016 +0200 BaseTools/GenFw AARCH64: convert ADRP to ADR instructions if binary size allows it The ADRP instruction in the AArch64 ISA requires the link time and load time offsets of a binary to be equal modulo 4 KB. The reason is that this instruction always produces a multiple of 4 KB, and relies on a subsequent ADD or LDR instruction to set the offset into the page. The resulting symbol reference only produces the correct value if the symbol in question resides at that exact offset into the page, and so loading the binary at arbitrary offsets is not possible. Due to the various levels of padding when packing FVs into FVs into FDs, this alignment is very costly for XIP code, and so we would like to relax this alignment requirement if possible. Given that symbols that are sufficiently close (within 1 MB) of the reference can also be reached using an ADR instruction which does not suffer from this alignment issue, let's replace ADRP
Re: [Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings
Hello Tamas, Thank you for taking care of this bug. On 02/08/2016 19:53, Tamas K Lengyel wrote: When mem_access settings change, the active vCPUs may still cause a violation until the TLB gets flushed. Instead of just reinjecting the violation to the guest, in this patch we direct the vCPU to retry the access where appropriate or we crash the domain where the mem_access settings are corrupted. With this patch p2m_mem_access_check will always return false. So I am not sure why you want to return in p2m_mem_access_check. Requested-by: Julien GrallSigned-off-by: Tamas K Lengyel --- Cc: Stefano Stabellini Cc: Julien Grall --- xen/arch/arm/p2m.c | 29 ++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 40a0b80..a4b6b7b 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -1657,8 +1657,26 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec) return true; rc = p2m_get_mem_access(v->domain, _gfn(paddr_to_pfn(gpa)), ); -if ( rc ) -return true; +switch (rc ) +{ +case -ESRCH: +/* + * If we can't find any mem_access setting for this page then the page + * might have just been removed and the event was triggered by no longer + * valid settings. The vCPU should just retry to get to the proper error + * path. + */ +return false; +case -ERANGE: +/* + * The mem_access settings are corrupted. Crashing the domain is the + * appropriate step in this case. + */ +domain_crash(v->domain); +return false; +}; + +ASSERT(!rc); It would be easier to do: rc = p2m_mem_access_check(gpa, gva, npfec); if (!rc) return; by p2m_mem_access_check(gpa, gva, npfec); return; in both do_trap_instr_abort_guest and do_trap_data_abort_guest. This would also helps to fallback on another permission check if in the future we decide to use permission for other reasons. Or is there any reason you may want to inject a data abort to the guest if memaccess has failed (i.e return true)? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 1/4] tools: remove systemd xenstore socket definitions
> On 2 Aug 2016, at 12:07, Wei Liuwrote: > > On Tue, Aug 02, 2016 at 12:39:25PM +0200, Juergen Gross wrote: >> On a system with systemd the xenstore sockets are created via systemd. >> Remove the related configuration files in order to be able to decide >> at runtime whether the sockets should be created or not. This will >> enable Xen to start xenstore either via a daemon or via a stub domain. >> >> As the xenstore domain start program will exit after it has done its >> job prepare the same behaviour to be tolerated by systemd for the >> xenstore daemon by specifying the appropriate flags in the service >> file. >> >> A rerun of autogen.sh is required. >> >> Signed-off-by: Juergen Gross > > Acked-by: Wei Liu > > The ocaml bits would need an ack from Dave. The OCaml bits look fine to me Acked-by: David Scott Cheers, Dave ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/8] x86/time: improve cross-CPU clock monotonicity (and more)
On 15/06/16 11:26, Jan Beulich wrote: > Using the bare return value from read_platform_stime() is not suitable > when local_time_calibration() is going to use its fast path: Divergence > of several dozen microseconds between NOW() return values on different > CPUs results when platform and local time don't stay in close sync. > > Latch local and platform time on the CPU initiating AP bringup, such > that the AP can use these values to seed its stime_local_stamp with as > little of an error as possible. The boot CPU, otoh, can simply > calculate the correct initial value (other CPUs could do so too with > even greater accuracy than the approach being introduced, but that can > work only if all CPUs' TSCs start ticking at the same time, which > generally can't be assumed to be the case on multi-socket systems). > > This slightly defers init_percpu_time() (moved ahead by commit > dd2658f966 ["x86/time: initialise time earlier during > start_secondary()"]) in order to reduce as much as possible the gap > between populating the stamps and consuming them. > > Signed-off-by: Jan BeulichSubject to the style issue spotted by Joao, Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/8] x86/time: calibrate TSC against platform timer
On 20/06/16 16:19, Jan Beulich wrote: On 20.06.16 at 16:20,wrote: >> On 15/06/16 11:28, Jan Beulich wrote: >>> --- a/xen/arch/x86/i8259.c >>> +++ b/xen/arch/x86/i8259.c >>> @@ -359,12 +359,7 @@ void __init init_IRQ(void) >>> >>> apic_intr_init(); >>> >>> -/* Set the clock to HZ Hz */ >>> -#define CLOCK_TICK_RATE 1193182 /* crystal freq (Hz) */ >>> -#define LATCH (((CLOCK_TICK_RATE)+(HZ/2))/HZ) >>> -outb_p(0x34, PIT_MODE);/* binary, mode 2, LSB/MSB, ch 0 */ >>> -outb_p(LATCH & 0xff, PIT_CH0); /* LSB */ >>> -outb(LATCH >> 8, PIT_CH0); /* MSB */ >>> +preinit_pit(); >> This highlights the fact that we have two unconditional calls to >> preinit_pit() during startup, which is one too many. >> >> init_IRQ() is called rather earlier than early_time_init(), but I can't >> spot anything inbetween the two calls which would require the PIT to be >> set up. AFAICT, it is safe to just drop the preinit_pit() call here. > LAPIC initialization makes use of the PIT, and I think that would > break when removing it here. And since doing it twice is benign, > I'd also like to not drop it from early_time_init(). Where? LAPIC initialisation is before this point - its higher up in init_IRQ() so surely can't depend on this currently working. As for benign, at the best it is a waste of time, and on reduced hardware platforms, wrong. We shouldn't be propagating problems like these. > >>> @@ -340,7 +348,8 @@ static struct platform_timesource __init >>> .frequency = CLOCK_TICK_RATE, >>> .read_counter = read_pit_count, >>> .counter_bits = 32, >>> -.init = init_pit >>> +.init = init_pit, >>> +.resume = resume_pit >> Please add a redundant comma at the end, to reduce the next diff to >> change this block. > Well, I'd like the three instance to remain consistent in this regard > (yet touching the others doesn't seem warranted). And a change > here isn't all that likely. This is just like any other bit of style - it should be fixed up while editing even if the rest of the file isn't completely up to scratch. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/8] x86/time: correctly honor late clearing of TSC related feature flags
On 04/07/16 16:53, Jan Beulich wrote: On 04.07.16 at 17:39,wrote: >> On 20/06/16 16:20, Jan Beulich wrote: >> On 20.06.16 at 16:32, wrote: On 15/06/16 11:28, Jan Beulich wrote: > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -1358,6 +1358,24 @@ static void time_calibration(void *unuse > , 1); > } > > +void __init clear_tsc_cap(unsigned int feature) > +{ > +void (*rendezvous_fn)(void *) = time_calibration_std_rendezvous; This should read time_calibration_rendezvous_fn rather than assuming time_calibration_std_rendezvous. Otherwise, there is a risk that it could be reset back to time_calibration_std_rendezvous. >>> But that's the purpose: We may need to switch back. >> Under what circumstances could we ever move from re-syncing back to not >> re-syncing? > verify_tsc_reliability() may result in X86_FEATURE_TSC_RELIABLE > getting cleared. That's an initcall, which means it runs after > init_xen_time(), and hence after the rendezvous function got > established initially. Right, but that isn't important. There will never be a case where, once TSC_RELIABLE is cleared, it is safe to revert back to std_rendezvous, even if TSC_RELIABLE is subsequently re-set. Therefore, this function must never accidentally revert time_calibration_rendezvous_fn from time_calibration_tsc_rendezvous back to time_calibration_std_rendezvous. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?
> > Can you try > > > > ((void *)(md) + (m)->desc_size - 1) < > > (m)->map_end; \ > > > > instead? with the 'baseline' as referenced + a patched kernel > Can you try >((void *)(md) + (m)->desc_size - 1) < (m)->map_end; \ with efi cmd line opts: +"/mapbs" The system now boots correctly uname -rm 4.7.0-6-default x86_64 xl list NameID Mem VCPUs State Time(s) Domain-0 0 4096 1 r- 52.4 g1 1 2049 1 -b 15.0 g2 2 1025 1 -b 15.5 g3 3 1025 1 -b 16.2 g4 4 1025 1 -b 19.6 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] live migrating hvm from 4.4 to 4.5 fails due to kvmvapic
On Tue, 2 Aug 2016, Olaf Hering wrote: > As a followup to the issue below, and the one which "just" popped in in > qemu-2.6+: > > Why is the machine description for xen not fixed? xenfv comes from a time when QEMU didn't have machine description versioning. To have versioning, it is possible to use a regular PC machine plus accel=xen. I tried to change the libxl default from xenfv to a versioned pc machine with accel=xen a couple of years back, but unfortunately it created ABI incompatibilities, see: http://marc.info/?i=alpine.DEB.2.02.1406121512360.13771%40kaball.uk.xensource.com > Shouldnt the be some sort of verification of old and new 'xenfv' when a > new qemu rc1 is done? It would be great to have > Is there a way to dump the machine description in text form? I don't know, but people at qemu-devel might. > On Fri, May 13, Stefano Stabellini wrote: > > > On Thu, 12 May 2016, Olaf Hering wrote: > > > On Thu, May 12, Olaf Hering wrote: > > > > > > > One thing to fix it in staging-4.5 is to introduce a dummy device which > > > > handles a section named "kvm-tpr-opt". I already have a hack which does > > > > that, and the migration proceeds. I will propose a patch to deal with > > > > this part of the bug. > > > > > > Something like shown below. > > > > Thanks for looking into this. I don't think that adding a dummy device > > in QEMU is acceptable. This kind of problems is usually solved with > > versioning the PC machine in QEMU, see all the pc_machine_* in > > hw/i386/pc_piix.c. One specific version of the machine is supposed to > > remain identical over multiple QEMU releases. In this case xenfv (or the > > pc machine you are using, if you are not using xenfv) has to be always > > identical. That's why I think we need to add kvmapic back to it for > > compatibility. I know it sucks. But we can choose a different PC machine > > with accel=xen for new VMs. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings
When mem_access settings change, the active vCPUs may still cause a violation until the TLB gets flushed. Instead of just reinjecting the violation to the guest, in this patch we direct the vCPU to retry the access where appropriate or we crash the domain where the mem_access settings are corrupted. Requested-by: Julien GrallSigned-off-by: Tamas K Lengyel --- Cc: Stefano Stabellini Cc: Julien Grall --- xen/arch/arm/p2m.c | 29 ++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 40a0b80..a4b6b7b 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -1657,8 +1657,26 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec) return true; rc = p2m_get_mem_access(v->domain, _gfn(paddr_to_pfn(gpa)), ); -if ( rc ) -return true; +switch (rc ) +{ +case -ESRCH: +/* + * If we can't find any mem_access setting for this page then the page + * might have just been removed and the event was triggered by no longer + * valid settings. The vCPU should just retry to get to the proper error + * path. + */ +return false; +case -ERANGE: +/* + * The mem_access settings are corrupted. Crashing the domain is the + * appropriate step in this case. + */ +domain_crash(v->domain); +return false; +}; + +ASSERT(!rc); /* Now check for mem_access violation. */ switch ( xma ) @@ -1692,8 +1710,13 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec) break; } +/* + * If there is no violation found based on the current setting this event + * has been triggereded by a setting that is no longer current. The vCPU + * should just retry the access in this case. + */ if ( !violation ) -return true; +return false; /* First, handle rx2rw and n2rwx conversion automatically. */ if ( npfec.write_access && xma == XENMEM_access_rx2rw ) -- 2.8.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h
On Tue, 2 Aug 2016, Jan Beulich wrote: > >>> On 02.08.16 at 16:59,wrote: > > On 02/08/16 15:54, Jan Beulich wrote: > > On 02.08.16 at 16:26, wrote: > >>> On 02/08/16 15:17, Jan Beulich wrote: > Well, I find it quite odd for hypercall argument counts to differ > between arches. I.e. I'd conclude the ABI was mis-specified. > >>> Is it documented somewhere for the x86 code? Looking at Linux, the > >>> privcmd call is only passing 5 arguments on both ARM and x86. > >> arch-x86/xen-x86_32.h has > >> > >> * Hypercall interface: > >> * Input: %ebx, %ecx, %edx, %esi, %edi, %ebp (arguments 1-6) > >> * Output: %eax > >> > >> while arch-x86/xen-x86_64.h has > >> > >> * Hypercall interface: > >> * Input: %rdi, %rsi, %rdx, %r10, %r8, %r9 (arguments 1-6) > >> * Output: %rax > > > > The only actual 6 argument hypercall is the v4v hypercall, better known > > as __HYPERVISOR_xc_reserved_op at index 39, but that isn't implemented > > anywhere upstream. > > But it serves as an example what now wouldn't work on ARM. At the time the arm hypercall ABI was published, it matched the x86 hypercall ABI, which had only 5 hypercall arguments. The issue is that the x86 hypercall ABI changed, and now is out of sync with ARM. The faulty commit being: commit 4af64160c580b02f28c992c09d55957cb20a9b91 Author: David Vrabel Date: Wed May 30 09:25:11 2012 +0100 x86: document register for 6th hypercall argument From: David Vrabel Signed-off-by: David Vrabel Committed-by: Keir Fraser While the ARM ABI is from few months earlier: commit 40f20c4bfcd5d25c90f9419250ca8a229bf4c1e5 Author: Stefano Stabellini Date: Tue Mar 13 16:04:05 2012 + arm: use r12 to pass the hypercall number ** This is a guest visible ABI change which requires an updated guest kernel ** Use r12 to pass the hypercall number and r0-r4 for the hypercall arguments. Use the ISS to pass an hypervisor specific tag. Remove passing unused registers to arm_hypercall_table: we don't have 6 arguments hypercalls and we never use 64 bit values as hypercall arguments, 64 bit values are only contained within structs passed as arguments. Signed-off-by: Stefano Stabellini [ use #ifndef NDEBUG, fix coding style, expand calling convention comment slightly and added a big fat note about ABI change - ijc ] ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 09/15] hvmloader: Check modules whereabouts in perform_tests
On Thu, Jul 28, 2016 at 03:08:29PM +0100, Andrew Cooper wrote: > On 28/07/16 11:50, Anthony PERARD wrote: > > As perform_tests() is going to clear memory past 4MB, we check that the > > memory can be use or we skip the tests. > > > > Signed-off-by: Anthony PERARD> > This is a loosing battle of overlap checks, and they are far less useful > than they used to be if they are conditionally skipped. The tests may be skipped if OVMF is used as firmware, otherwise it does not really happen. > I would just drop tests.c entirely. This was one longterm goal of mine > with XTF, and it is a far more appropriate way to get tests done, > especially as it is almost integrated into OSSTest now. I guess I can drop tests.c and this patch if I have to send another version of the patch series. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: use a common function for pv and hvm guest backend register calls
On Tue, 2 Aug 2016, Gerd Hoffmann wrote: > On Di, 2016-08-02 at 08:32 +0200, Juergen Gross wrote: > > Instead of calling xen_be_register() for each supported backend type > > for hvm and pv guests in their machine init functions use a common > > function in order not to have to add new backends twice. > > > > This at once fixes the error that hvm domains couldn't use the qusb > > backend. > > Looks good to me. Should I take this through the usb patch queue, > together with the other xen-usb fixes (once codestyle issues are fixed)? > If so, can I get an ack from xen please, preferably fast enough for > -rc2? Hi Gerd, I am happy for you to handle all three patches (if for any reasons you change your mind I can do it). "xen: bug fixes in Xen backend handling" v2 is ready to be committed, and I am just waiting for an answer on this patch. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: use a common function for pv and hvm guest backend register calls
On Tue, 2 Aug 2016, Juergen Gross wrote: > Instead of calling xen_be_register() for each supported backend type > for hvm and pv guests in their machine init functions use a common > function in order not to have to add new backends twice. > > This at once fixes the error that hvm domains couldn't use the qusb > backend. > > Signed-off-by: Juergen Gross> --- > Is it on purpose the qnic and vfb backends are not registered for HVM? Yes, it is on purpose: there is no code in any toolstacks to use qnic, and the presence of vfb can cause problems to Linux HVM guests (or at least it used to), additionally vfb for HVM guests is also disabled in libxl. In general, it is a good idea to disable code that is not supposed to be used. Can qusb be used with HVM guests with libxl/xl? > hw/xen/xen_backend.c | 10 ++ > hw/xenpv/xen_machine_pv.c| 7 +-- > include/hw/xen/xen_backend.h | 1 + > xen-hvm.c| 4 +--- > 4 files changed, 13 insertions(+), 9 deletions(-) > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c > index bab79b1..1b88891 100644 > --- a/hw/xen/xen_backend.c > +++ b/hw/xen/xen_backend.c > @@ -800,6 +800,16 @@ int xen_be_register(const char *type, struct XenDevOps > *ops) > return xenstore_scan(type, xen_domid, ops); > } > > +void xen_be_register_common(void) > +{ > +xen_be_register("console", _console_ops); > +xen_be_register("vkbd", _kbdmouse_ops); > +xen_be_register("qdisk", _blkdev_ops); > +#ifdef CONFIG_USB_LIBUSB > +xen_be_register("qusb", _usb_ops); > +#endif > +} > + > int xen_be_bind_evtchn(struct XenDevice *xendev) > { > if (xendev->local_port != -1) { > diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c > index 48f725c..79aef4e 100644 > --- a/hw/xenpv/xen_machine_pv.c > +++ b/hw/xenpv/xen_machine_pv.c > @@ -67,14 +67,9 @@ static void xen_init_pv(MachineState *machine) > break; > } > > -xen_be_register("console", _console_ops); > -xen_be_register("vkbd", _kbdmouse_ops); > +xen_be_register_common(); > xen_be_register("vfb", _framebuffer_ops); > -xen_be_register("qdisk", _blkdev_ops); > xen_be_register("qnic", _netdev_ops); > -#ifdef CONFIG_USB_LIBUSB > -xen_be_register("qusb", _usb_ops); > -#endif > > /* configure framebuffer */ > if (xenfb_enabled) { > diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h > index 754c0a4..0df282a 100644 > --- a/include/hw/xen/xen_backend.h > +++ b/include/hw/xen/xen_backend.h > @@ -87,6 +87,7 @@ void xen_be_check_state(struct XenDevice *xendev); > > /* xen backend driver bits */ > int xen_be_init(void); > +void xen_be_register_common(void); > int xen_be_register(const char *type, struct XenDevOps *ops); > int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state); > int xen_be_bind_evtchn(struct XenDevice *xendev); > diff --git a/xen-hvm.c b/xen-hvm.c > index eb57792..3b0343a 100644 > --- a/xen-hvm.c > +++ b/xen-hvm.c > @@ -1318,9 +1318,7 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion > **ram_memory) > error_report("xen backend core setup failed"); > goto err; > } > -xen_be_register("console", _console_ops); > -xen_be_register("vkbd", _kbdmouse_ops); > -xen_be_register("qdisk", _blkdev_ops); > +xen_be_register_common(); > xen_read_physmap(state); > return; > > -- > 2.6.6 > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 08/15] hvmloader: Locate the BIOS blob
On Thu, Jul 28, 2016 at 02:44:24PM +0100, Andrew Cooper wrote: > On 28/07/16 11:50, Anthony PERARD wrote: > > @@ -293,8 +340,17 @@ int main(void) > > } > > > > printf("Loading %s ...\n", bios->name); > > -if ( bios->bios_load ) > > -bios->bios_load(bios); > > +bios_module = get_module_entry(hvm_start_info, "firmware"); > > +if ( bios_module && bios->bios_load ) > > +{ > > +uint32_t paddr = bios_module->paddr; > > + > > +bios->bios_load(bios, (void*)paddr, bios_module->size); > > +} > > +else if ( bios->bios_load ) > > +{ > > +bios->bios_load(bios, NULL, 0); > > This is an unnecessary change in behaviour. Currently, 'bios' is never > NULL, and would never pass bogus information to bios_load. > > As this is the new way of providing firmware, it should be a hard error > if get_module_entry(, "firmware") fails, at which point this logic can > collapse down quite a lot. At this point in the patch series, the module is not used yet, and the seabios loader does not have a bios_load function. Also I've change the logic again in "hvmloader: bios->bios_load() now needs to be defined". Also, I've left ROMBIOS embedded in hvmloader, because it comes with VGABIOS and Etherboot, so it would be a bit more complicated. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 99907: tolerable all pass - PUSHED
flight 99907 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/99907/ 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 8746f06cbeef6ff1b0e9f413a222ebf00718b3f9 baseline version: xen 2eee1c746af6f683247700642786b7c21c991234 Last test of basis99900 2016-08-02 10:01:42 Z0 days Testing same since99907 2016-08-02 16:02:38 Z0 days1 attempts People who touched revisions under test: Boris OstrovskyJan Beulich Kevin Tian 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=8746f06cbeef6ff1b0e9f413a222ebf00718b3f9 + . ./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 8746f06cbeef6ff1b0e9f413a222ebf00718b3f9 + branch=xen-unstable-smoke + revision=8746f06cbeef6ff1b0e9f413a222ebf00718b3f9 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable-smoke + qemuubranch=qemu-upstream-unstable + '[' xxen = xlinux ']' + linuxbranch= + '[' xqemu-upstream-unstable = x ']' + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable-smoke + prevxenbranch=xen-4.7-testing + '[' x8746f06cbeef6ff1b0e9f413a222ebf00718b3f9 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/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
Re: [Xen-devel] [PATCH] xen: use a common function for pv and hvm guest backend register calls
On Tue, Aug 02, 2016 at 08:32:32AM +0200, Juergen Gross wrote: > Instead of calling xen_be_register() for each supported backend type > for hvm and pv guests in their machine init functions use a common > function in order not to have to add new backends twice. > > This at once fixes the error that hvm domains couldn't use the qusb > backend. > > Signed-off-by: Juergen GrossAcked-by: Anthony PERARD > --- > Is it on purpose the qnic and vfb backends are not registered for HVM? I guess it has not been usefull. Stefano may have a better answer. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] systemd: remove hard-coded pid file in xendriverdomain service
Wei Liu: > On Tue, Aug 02, 2016 at 02:41:58PM +0100, Ian Jackson wrote: >> Wei Liu writes ("[PATCH] systemd: remove hard-coded pid file in >> xendriverdomain service"): >>> Per the discussion in [0], the hard-coded pid file can be removed >>> completely. Systemd has no trouble figuring out the pid of devd all by >>> itself. >>> >>> [0]: https://lists.xen.org/archives/html/xen-devel/2016-07/msg01393.html >> >> I'm not qualified to have much of an opinion this but I'm happy to see >> it go in based on what I assume is a test report from Rusty Bird ? >> > > No, it's not a test report. > > Rusty Bird was the submitter of that xl devd unit file. I assumed he had > experience of setting up xl devd without a pid file under systemd and > did what he asked for. Yes, I tried it without a PID file and did not notice any issues. Rusty signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 99903: all pass - PUSHED
flight 99903 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/99903/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8134f7d9d2654a49916f627783c956f3eca78421 baseline version: ovmf 28ade7b802e0732cf9839017ee6e9cf78b842582 Last test of basis99896 2016-08-02 06:46:13 Z0 days Testing same since99903 2016-08-02 10:47:05 Z0 days1 attempts People who touched revisions under test: Ard BiesheuvelArd Biesheuvel # ARM Jordan Justen Laszlo Ersek Leif Lindholm # AArch64 jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 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=ovmf + revision=8134f7d9d2654a49916f627783c956f3eca78421 + . ./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 ovmf 8134f7d9d2654a49916f627783c956f3eca78421 + branch=ovmf + revision=8134f7d9d2654a49916f627783c956f3eca78421 + . ./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=ovmf + xenbranch=xen-unstable + '[' xovmf = xlinux ']' + linuxbranch= + '[' x = x ']' + qemuubranch=qemu-upstream-unstable + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable + prevxenbranch=xen-4.7-testing + '[' x8134f7d9d2654a49916f627783c956f3eca78421 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/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
[Xen-devel] [xen-4.6-testing test] 99902: tolerable FAIL - PUSHED
flight 99902 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/99902/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 99894 pass in 99902 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail pass in 99894 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 99776 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 99776 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 99776 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99776 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 99776 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail 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-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 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-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass version targeted for testing: xen 625c3e47e077129b0bc903e8db03bdf1cbbeb413 baseline version: xen dfe85d302f5f127c4ab5e2a5e8bcd6a964f7218c Last test of basis99776 2016-07-29 04:09:24 Z4 days Testing same since99894 2016-08-02 02:03:03 Z0 days2 attempts People who touched revisions under test: Julien Gralljobs: 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-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass
Re: [Xen-devel] [PATCH] libxl: use llabs() instead abs() for int64_t argument
On 02/08/16 18:25, Juergen Gross wrote: > Commit 57f8b13c724023c78fa15a80452d1de3e51a1418 ("libxl: memory size > in kb requires 64 bit variable") introduced a bug: abs() shouldn't > be called with an int64_t argument. llabs() is to be used here. Possibly worth identifying that this was caught by a clang build, citing: libxl.c:4198:33: error: absolute value function 'abs' given an argument of type 'int64_t' (aka 'long') but has parameter of type 'int' which may cause truncation of value [-Werror,-Wabsolute-value] if (target_memkb < 0 && abs(target_memkb) > current_target_memkb) ^ Otherwise, LGTM. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] libxl: use llabs() instead abs() for int64_t argument
Commit 57f8b13c724023c78fa15a80452d1de3e51a1418 ("libxl: memory size in kb requires 64 bit variable") introduced a bug: abs() shouldn't be called with an int64_t argument. llabs() is to be used here. Signed-off-by: Juergen Gross--- tools/libxl/libxl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index de8f058..7bd3e8c 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -4195,7 +4195,7 @@ retry_transaction: videoram = videoram_s ? atoi(videoram_s) : 0; if (relative) { -if (target_memkb < 0 && abs(target_memkb) > current_target_memkb) +if (target_memkb < 0 && llabs(target_memkb) > current_target_memkb) new_target_memkb = 0; else new_target_memkb = current_target_memkb + target_memkb; -- 2.6.6 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On Tue, Aug 2, 2016 at 10:40 AM, Julien Grallwrote: > > > On 02/08/16 17:05, George Dunlap wrote: >> >> On 02/08/16 16:48, Tamas K Lengyel wrote: >>> >>> On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap >>> wrote: On 02/08/16 08:38, Julien Grall wrote: > > Hello Tamas, > > On 01/08/2016 21:41, Tamas K Lengyel wrote: >> >> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall >> wrote: we did discuss whether altp2m on ARM should be exposed to guests or not but we did not agree whether restricting it on ARM is absolutely necessary. Altp2m was designed even on the x86 to be accessible from within the guest on all systems irrespective of actual hardware support for it. Thus, this design fits ARM as well where there is no dedicated hardware support, from the altp2m perspective there is no difference. >>> >>> >>> >>> Really? I looked at the design document [1] which is Intel focus. >>> Similar >>> think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c). >> >> >> That design cover letter mentions specifically "Both VMFUNC and #VE >> are designed such that a VMM can emulate them on legacy CPUs". While >> they certainly had only Intel hardware in-mind, the software route can >> also be taken on ARM as well. As our primary use-case is purely >> external use of altp2m we have not implemented the bits that enable >> the injection of mem_access faults into the guest (equivalent of #VE). >> Whether without that the altp2m switching from within the guest make >> sense or not is beyond the scope of this series but as it could >> technically be implemented in the future, I don't see a reason to >> disable that possibility right away. > > > The question here, is how a guest could take advantage to access to > altp2m on ARM today? Whilst on x86 a guest could be notified about > memaccess change, this is not yet the case on ARM. > > So, from my understanding, exposing this feature to a guest is like > exposing a no-op with side effects. We should avoid to expose feature > to > the guest until there is a real usage and the guest could do something > useful with it. It seems like having guest altp2m support without the equivalent of a #VE does seem pretty useless. Would you disagree with this assessment, Tamas? Every interface we expose to the guest increases the surface of attack; so it seems like until there is a usecase for guest altp2m, we should probably disable it. >>> >>> Hi George, >>> I disagree. On x86 using VMFUNC EPTP switching is not bound to #VE in >>> any way. The two can certainly benefit from being used together but >>> there is no enforced interdependence between the two. It is certainly >>> possible to derive a use-case for just having the altp2m switch >>> operations available to the guest. For example, I could imagine the >>> gfn remapping be used to protect kernel memory areas against >>> information disclosure by only switching to the accessible mapping >>> when certain conditions are met. >> >> >> That's true -- I suppose gfn remapping is something that would be useful >> even without #VE. >> >>> As our usecase is purely external implementing the emulated #VE at >>> this time has been deemed out-of-scope but it could be certainly >>> implemented for ARM as well. Now that I'm thinking about it it might >>> actually not be necessary to implement the #VE at all the way x86 does >>> by injecting an interrupt as we might just be able to allow the domain >>> to enable the existing mem_access ring directly. >> >> >> That would be a possibility, but before that could be considered a >> feature we'd need someone to go through and make sure that this >> self-mem_access funcitonality worked properly. (And I take it at the >> moment that's not work you're volunteering to do.) >> >> But the gfn remapping is something that could be used immediately. > > > I looked at the implementation of gfn remapping and I am a bit confused. > From my understanding of the code, the same MFN could be mapped twice in the > altp2m. Is that right? May I ask the purpose of this? > > So if the guest is removing the mapping from the host p2m (by calling > XENMEM_decrease_reservation), only one of the mapping will be removed. > > That will leave the other mapping potentially mapped in one of the altp2m. > However, AFAICT, x86 does take a reference on the page for mapping. So this > may point to memory that does not belong to the domain anymore. Did I miss > anything? > > After writing the above paragraphs, I noticed that p2m_change_altp2m_gfn > seem to take care of this use case. Right, using the min/max_remapped_gfn the p2m_altp2m_propagate_change can check if the change involves the
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On Tue, Aug 2, 2016 at 10:40 AM, Julien Grallwrote: > > > On 02/08/16 17:05, George Dunlap wrote: >> >> On 02/08/16 16:48, Tamas K Lengyel wrote: >>> >>> On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap >>> wrote: On 02/08/16 08:38, Julien Grall wrote: > > Hello Tamas, > > On 01/08/2016 21:41, Tamas K Lengyel wrote: >> >> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall >> wrote: we did discuss whether altp2m on ARM should be exposed to guests or not but we did not agree whether restricting it on ARM is absolutely necessary. Altp2m was designed even on the x86 to be accessible from within the guest on all systems irrespective of actual hardware support for it. Thus, this design fits ARM as well where there is no dedicated hardware support, from the altp2m perspective there is no difference. >>> >>> >>> >>> Really? I looked at the design document [1] which is Intel focus. >>> Similar >>> think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c). >> >> >> That design cover letter mentions specifically "Both VMFUNC and #VE >> are designed such that a VMM can emulate them on legacy CPUs". While >> they certainly had only Intel hardware in-mind, the software route can >> also be taken on ARM as well. As our primary use-case is purely >> external use of altp2m we have not implemented the bits that enable >> the injection of mem_access faults into the guest (equivalent of #VE). >> Whether without that the altp2m switching from within the guest make >> sense or not is beyond the scope of this series but as it could >> technically be implemented in the future, I don't see a reason to >> disable that possibility right away. > > > The question here, is how a guest could take advantage to access to > altp2m on ARM today? Whilst on x86 a guest could be notified about > memaccess change, this is not yet the case on ARM. > > So, from my understanding, exposing this feature to a guest is like > exposing a no-op with side effects. We should avoid to expose feature > to > the guest until there is a real usage and the guest could do something > useful with it. It seems like having guest altp2m support without the equivalent of a #VE does seem pretty useless. Would you disagree with this assessment, Tamas? Every interface we expose to the guest increases the surface of attack; so it seems like until there is a usecase for guest altp2m, we should probably disable it. >>> >>> Hi George, >>> I disagree. On x86 using VMFUNC EPTP switching is not bound to #VE in >>> any way. The two can certainly benefit from being used together but >>> there is no enforced interdependence between the two. It is certainly >>> possible to derive a use-case for just having the altp2m switch >>> operations available to the guest. For example, I could imagine the >>> gfn remapping be used to protect kernel memory areas against >>> information disclosure by only switching to the accessible mapping >>> when certain conditions are met. >> >> >> That's true -- I suppose gfn remapping is something that would be useful >> even without #VE. >> >>> As our usecase is purely external implementing the emulated #VE at >>> this time has been deemed out-of-scope but it could be certainly >>> implemented for ARM as well. Now that I'm thinking about it it might >>> actually not be necessary to implement the #VE at all the way x86 does >>> by injecting an interrupt as we might just be able to allow the domain >>> to enable the existing mem_access ring directly. >> >> >> That would be a possibility, but before that could be considered a >> feature we'd need someone to go through and make sure that this >> self-mem_access funcitonality worked properly. (And I take it at the >> moment that's not work you're volunteering to do.) >> >> But the gfn remapping is something that could be used immediately. > > > I looked at the implementation of gfn remapping and I am a bit confused. > From my understanding of the code, the same MFN could be mapped twice in the > altp2m. Is that right? May I ask the purpose of this? Yes, that's correct. I can tell you my use-case for it. I'm using breakpoints to trace the execution of the kernel by writing 0xCC to function entry points and configure the VMCS to trap to the VMM when such instructions execute. Now, the kernel can detect that these instruction are written to it's memory and for example Windows would blue-screen. So, to avoid that, I create a shadow copy of the page and only add breakpoints there. Then create an altp2m view and use gfn remapping to point the gfn to this new mfn. This view is execute only, thus when the kernel tries to read, we can switch back to view 0 where
Re: [Xen-devel] [PATCH v1 Altp2m cleanup 1/3] altp2m cleanup work
(Removing Paul, adding Lars) Ravi, I just got to this thread, and I was quite disappointed with both the code and the interaction here. In patch 1, the naming of the min/max is obviously inappropriate, and a.cmd is compared to HVMOP_cmd_max twice in a row. In patch 3, unused elements of the struct are commented out rather than deleted. These aren't "new to the Xen way of doing things" mistakes, these are basic programming errors. Did anyone review this series internally? -George On Tue, Jun 21, 2016 at 5:04 PM, Paul Laiwrote: > Indent goto labels by one space > Inline (header) altp2m functions > Define default behavior in switch > Define max and min for range of altp2m macroed values > > Signed-off-by: Paul Lai > --- > xen/arch/x86/hvm/hvm.c | 33 + > xen/include/asm-x86/hvm/hvm.h | 19 --- > xen/include/public/hvm/hvm_op.h | 2 ++ > 3 files changed, 27 insertions(+), 27 deletions(-) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 22f045e..1595b3e 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -1926,11 +1926,11 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned > long gla, > * Otherwise, this is an error condition. */ > rc = fall_through; > > -out_put_gfn: > + out_put_gfn: > __put_gfn(p2m, gfn); > if ( ap2m_active ) > __put_gfn(hostp2m, gfn); > -out: > + out: > /* All of these are delayed until we exit, since we might > * sleep on event ring wait queues, and we must not hold > * locks in such circumstance */ > @@ -5207,9 +5207,11 @@ static int do_altp2m_op( > return -EFAULT; > > if ( a.pad1 || a.pad2 || > - (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) || > - (a.cmd < HVMOP_altp2m_get_domain_state) || > - (a.cmd > HVMOP_altp2m_change_gfn) ) > +(a.version != HVMOP_ALTP2M_INTERFACE_VERSION) || > +(a.cmd < HVMOP_cmd_min) || (a.cmd > HVMOP_cmd_max)) > +return -EINVAL; > + > +if (a.cmd > HVMOP_cmd_max) > return -EINVAL; > > d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ? > @@ -5329,6 +5331,8 @@ static int do_altp2m_op( > rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view, > _gfn(a.u.change_gfn.old_gfn), > _gfn(a.u.change_gfn.new_gfn)); > +default: > +return -EINVAL; > } > > out: > @@ -5816,25 +5820,6 @@ void hvm_toggle_singlestep(struct vcpu *v) > v->arch.hvm_vcpu.single_step = !v->arch.hvm_vcpu.single_step; > } > > -void altp2m_vcpu_update_p2m(struct vcpu *v) > -{ > -if ( hvm_funcs.altp2m_vcpu_update_p2m ) > -hvm_funcs.altp2m_vcpu_update_p2m(v); > -} > - > -void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v) > -{ > -if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve ) > -hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v); > -} > - > -bool_t altp2m_vcpu_emulate_ve(struct vcpu *v) > -{ > -if ( hvm_funcs.altp2m_vcpu_emulate_ve ) > -return hvm_funcs.altp2m_vcpu_emulate_ve(v); > -return 0; > -} > - > int hvm_set_mode(struct vcpu *v, int mode) > { > > diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h > index f486ee9..231c921 100644 > --- a/xen/include/asm-x86/hvm/hvm.h > +++ b/xen/include/asm-x86/hvm/hvm.h > @@ -589,13 +589,26 @@ static inline bool_t hvm_altp2m_supported(void) > } > > /* updates the current hardware p2m */ > -void altp2m_vcpu_update_p2m(struct vcpu *v); > +static inline void altp2m_vcpu_update_p2m(struct vcpu *v) > +{ > +if ( hvm_funcs.altp2m_vcpu_update_p2m ) > +hvm_funcs.altp2m_vcpu_update_p2m(v); > +} > > /* updates VMCS fields related to VMFUNC and #VE */ > -void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v); > +static inline void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v) > +{ > +if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve ) > +hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v); > +} > > /* emulates #VE */ > -bool_t altp2m_vcpu_emulate_ve(struct vcpu *v); > +static inline bool_t altp2m_vcpu_emulate_ve(struct vcpu *v) > +{ > +if ( hvm_funcs.altp2m_vcpu_emulate_ve ) > +return hvm_funcs.altp2m_vcpu_emulate_ve(v); > +return 0; > +} > > /* Check CR4/EFER values */ > const char *hvm_efer_valid(const struct vcpu *v, uint64_t value, > diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h > index ebb907a..3350492 100644 > --- a/xen/include/public/hvm/hvm_op.h > +++ b/xen/include/public/hvm/hvm_op.h > @@ -479,6 +479,8 @@ struct xen_hvm_altp2m_op { > #define HVMOP_altp2m_set_mem_access 7 > /* Change a p2m entry to have a different gfn->mfn mapping */ > #define HVMOP_altp2m_change_gfn 8 > +#define HVMOP_cmd_min HVMOP_altp2m_get_domain_state > +#define HVMOP_cmd_max HVMOP_altp2m_change_gfn > domid_t domain; > uint16_t pad1; > uint32_t pad2; > -- >
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On 02/08/16 17:05, George Dunlap wrote: On 02/08/16 16:48, Tamas K Lengyel wrote: On Tue, Aug 2, 2016 at 5:17 AM, George Dunlapwrote: On 02/08/16 08:38, Julien Grall wrote: Hello Tamas, On 01/08/2016 21:41, Tamas K Lengyel wrote: On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall wrote: we did discuss whether altp2m on ARM should be exposed to guests or not but we did not agree whether restricting it on ARM is absolutely necessary. Altp2m was designed even on the x86 to be accessible from within the guest on all systems irrespective of actual hardware support for it. Thus, this design fits ARM as well where there is no dedicated hardware support, from the altp2m perspective there is no difference. Really? I looked at the design document [1] which is Intel focus. Similar think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c). That design cover letter mentions specifically "Both VMFUNC and #VE are designed such that a VMM can emulate them on legacy CPUs". While they certainly had only Intel hardware in-mind, the software route can also be taken on ARM as well. As our primary use-case is purely external use of altp2m we have not implemented the bits that enable the injection of mem_access faults into the guest (equivalent of #VE). Whether without that the altp2m switching from within the guest make sense or not is beyond the scope of this series but as it could technically be implemented in the future, I don't see a reason to disable that possibility right away. The question here, is how a guest could take advantage to access to altp2m on ARM today? Whilst on x86 a guest could be notified about memaccess change, this is not yet the case on ARM. So, from my understanding, exposing this feature to a guest is like exposing a no-op with side effects. We should avoid to expose feature to the guest until there is a real usage and the guest could do something useful with it. It seems like having guest altp2m support without the equivalent of a #VE does seem pretty useless. Would you disagree with this assessment, Tamas? Every interface we expose to the guest increases the surface of attack; so it seems like until there is a usecase for guest altp2m, we should probably disable it. Hi George, I disagree. On x86 using VMFUNC EPTP switching is not bound to #VE in any way. The two can certainly benefit from being used together but there is no enforced interdependence between the two. It is certainly possible to derive a use-case for just having the altp2m switch operations available to the guest. For example, I could imagine the gfn remapping be used to protect kernel memory areas against information disclosure by only switching to the accessible mapping when certain conditions are met. That's true -- I suppose gfn remapping is something that would be useful even without #VE. As our usecase is purely external implementing the emulated #VE at this time has been deemed out-of-scope but it could be certainly implemented for ARM as well. Now that I'm thinking about it it might actually not be necessary to implement the #VE at all the way x86 does by injecting an interrupt as we might just be able to allow the domain to enable the existing mem_access ring directly. That would be a possibility, but before that could be considered a feature we'd need someone to go through and make sure that this self-mem_access funcitonality worked properly. (And I take it at the moment that's not work you're volunteering to do.) But the gfn remapping is something that could be used immediately. I looked at the implementation of gfn remapping and I am a bit confused. From my understanding of the code, the same MFN could be mapped twice in the altp2m. Is that right? May I ask the purpose of this? So if the guest is removing the mapping from the host p2m (by calling XENMEM_decrease_reservation), only one of the mapping will be removed. That will leave the other mapping potentially mapped in one of the altp2m. However, AFAICT, x86 does take a reference on the page for mapping. So this may point to memory that does not belong to the domain anymore. Did I miss anything? After writing the above paragraphs, I noticed that p2m_change_altp2m_gfn seem to take care of this use case. However, the locking is not the same to protect min_remapped_gfn and max_remapped_gfn. p2m_altp2m_propagate_change is protecting them by taking the altp2m_list_lock whilst p2m_change_altp2m_gfn is using the altp2m lock. Maybe George or Tamas could give more insight here. BTW, the x86 version of p2m_change_altp2m_gfn (I have not yet looked at the ARM one) does not seem to lock the hostp2m. Is it normal? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 Altp2m cleanup 1/3] altp2m cleanup work
On Thu, Jun 23, 2016 at 7:23 PM, Lai, Paul Cwrote: > I'm opposed to moving HVMOP_cmd_min and HVMOP_cmd_max somewhere else. That > would make reading/understanding of the macros more difficult. This practice > is common. Also, If min & max are defined elsewhere, it will be more likely > to lead to mistakes/bugs. > > The use of "_min" and "_max" should be quite clear and is common use in linux > code; Yes, I know this is xen code and I see it here too. If there's a > better way, please propose the better. Maybe you're suggesting the macro > names should be all caps: > HVMOP_CMD_MIN, HVMOP_CMD_MAX > ? I was following the coding style within the file itself. Jan was suggesting that these should be called HVMOP_altp2m_{max,min} (or perhaps HVMOP_altp2m_cmd_{max,min}). But in any case, the most robust thing to do is not to check the values here at all -- just add a default: clause to the switch() statement which returns -ENOSYS. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request
On Tue, Aug 2, 2016 at 10:13 AM, Jan Beulichwrote: On 02.08.16 at 18:06, wrote: >> On Tue, Aug 2, 2016 at 9:23 AM, Tamas K Lengyel >> wrote: >>> On Aug 2, 2016 06:45, "Jan Beulich" wrote: >>> On 01.08.16 at 18:52, wrote: > +int hvm_monitor_mem_access(struct vcpu* v, bool_t sync, > + vm_event_request_t *req) > +{ > +return monitor_traps(v, sync, req); > +} Overall - is this a useful wrapper? Why can't the caller(s) call monitor_traps() directly? And if you really want to keep it, it would probably better be an inline one. >>> >>> The reason for this wrapper is to avoid having to include the common monitor >>> header here. I can move it into the hvm monitor header as inline, that's no >>> problem. >> >> Actually, making it into inline would require that hvm/monitor.h >> include the common monitor.h as well, at which point having the >> wrapper would be useless as hvm.c would have effectively include >> common monitor.h too. So yea, the goal is to avoid having to include >> both common/monitor and hvm/monitor in hvm.c and it needs this kind of >> wrapper. > > But what's wrong with including a header that declares a function you > want to call? > Nothing really, just wanted to separate things more neatly into their appropriate locations. It might be an overkill though I admit.. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On Tue, Aug 2, 2016 at 10:08 AM, Andrew Cooperwrote: > On 02/08/16 08:34, Julien Grall wrote: >> Hi Andrew, >> >> On 02/08/2016 00:14, Andrew Cooper wrote: >>> On 01/08/2016 19:15, Julien Grall wrote: On 01/08/16 18:10, Sergej Proskurin wrote: > > Hello all, Hello Sergej, > The following patch series can be found on Github[0] and is part of my > contribution to this year's Google Summer of Code (GSoC)[1]. My > project is > managed by the organization The Honeynet Project. As part of GSoC, I > am being > supervised by the Xen developer Tamas K. Lengyel > , George > D. Webster, and Steven Maresca. > > In this patch series, we provide an implementation of the altp2m > subsystem for > ARM. Our implementation is based on the altp2m subsystem for x86, > providing > additional --alternate-- views on the guest's physical memory by > means of the > ARM 2nd stage translation mechanism. The patches introduce new HVMOPs > and > extend the p2m subsystem. Also, we extend libxl to support altp2m on > ARM and > modify xen-access to test the suggested functionality. > > To be more precise, altp2m allows to create and switch to additional > p2m views > (i.e. gfn to mfn mappings). These views can be manipulated and > activated as > will through the provided HVMOPs. In this way, the active guest > instance in > question can seamlessly proceed execution without noticing that > anything has > changed. The prime scope of application of altp2m is Virtual Machine > Introspection, where guest systems are analyzed from the outside of > the VM. > > Altp2m can be activated by means of the guest control parameter > "altp2m" on x86 > and ARM architectures. The altp2m functionality by default can also > be used > from within the guest by design. For use-cases requiring purely > external access > to altp2m, a custom XSM policy is necessary on both x86 and ARM. As said on the previous version, altp2m operation *should not* be exposed to ARM guest. Any design written for x86 may not fit exactly for ARM (and vice versa), you will need to explain why you think we should follow the same pattern. >>> >>> Sorry, but I am going to step in here and disagree. All the x86 >>> justifications for altp2m being accessible to guests apply equally to >>> ARM, as they are hardware independent. >>> >>> I realise you are maintainer, but the onus is on you to justify why the >>> behaviour should be different between x86 and ARM, rather than simply to >>> complain at it being the same. >>> >>> Naturally, technical issues about the details of the implementation, or >>> the algorithms etc. are of course fine, but I don't see any plausible >>> reason why ARM should purposefully different from x86 in terms of >>> available functionality, and several good reasons why it should be the >>> same (least of all, feature parity across architectures). >> >> The question here, is how a guest could take advantage to access to >> altp2m on ARM today? Whilst on x86 a guest could be notified about >> memaccess change, this is not yet the case on ARM. > > Does ARM have anything like #VE whereby an in-guest entity can receive > notification of violations? > > If not, then I can't see any way that an in-guest entity can usefully > use altp2m, and by that logic, shouldn't have access to something it > can't usefully use. As I mentioned earlier, #VE and VMFUNC are not interdependent and there can be use-cases just for having the altp2m switch ops and gfn remapping, without any use mem_access and need for a #VE equivalent. It's not our usecase so we are fine with just restricting the whole altp2m system for the guest if that's the consensus. > > I suppose something could be synthesized with an event channel, if > in-guest use is wanted/needed. True, that might be a viable route for a #VE equivalent in the future. Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request
>>> On 02.08.16 at 18:06,wrote: > On Tue, Aug 2, 2016 at 9:23 AM, Tamas K Lengyel > wrote: >> On Aug 2, 2016 06:45, "Jan Beulich" wrote: >>> >>> On 01.08.16 at 18:52, wrote: >>> > +int hvm_monitor_mem_access(struct vcpu* v, bool_t sync, >>> > + vm_event_request_t *req) >>> > +{ >>> > +return monitor_traps(v, sync, req); >>> > +} >>> >>> Overall - is this a useful wrapper? Why can't the caller(s) call >>> monitor_traps() directly? And if you really want to keep it, it would >>> probably better be an inline one. >> >> The reason for this wrapper is to avoid having to include the common monitor >> header here. I can move it into the hvm monitor header as inline, that's no >> problem. > > Actually, making it into inline would require that hvm/monitor.h > include the common monitor.h as well, at which point having the > wrapper would be useless as hvm.c would have effectively include > common monitor.h too. So yea, the goal is to avoid having to include > both common/monitor and hvm/monitor in hvm.c and it needs this kind of > wrapper. But what's wrong with including a header that declares a function you want to call? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?
>>> On 02.08.16 at 17:04,wrote: > On Tue, Aug 2, 2016, at 07:50 AM, Jan Beulich wrote: >> - one with some suitable variant of reboot= > > What exactly is "some suitable variant of reboot" ? I can't really tell you which of the possible "reboot=" option values would work on your system. "reboot=acpi" is a pretty safe bet, though. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation
>>> On 02.08.16 at 17:49,wrote: > On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote: >> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote: >> > As this is for the construction of dom0, it would be better to take a >> > preemptible pointer, loop in construct_dom0(), with a >> > process_pending_softirqs() call in between. >> >> Now fixed. > > Hm, I have to stand corrected, using hypercall_preempt_check (as > any of the *_set_allocation function use), is not safe at this point: > > (XEN) [ Xen-4.8-unstable x86_64 debug=y Tainted:C ] > (XEN) CPU:0 > (XEN) RIP:e008:[] > hap.c#local_events_need_delivery+0x27/0x40 > (XEN) RFLAGS: 00010246 CONTEXT: hypervisor > (XEN) rax: rbx: 83023f5a5000 rcx: 82d080312900 > (XEN) rdx: 0001 rsi: 83023f5a56c8 rdi: 8300b213d000 > (XEN) rbp: 82d080307cc8 rsp: 82d080307cc8 r8: 0180 > (XEN) r9: r10: 00247000 r11: 82d08029a5b0 > (XEN) r12: 0011 r13: 23ac r14: 82d080307d4c > (XEN) r15: 83023f5a56c8 cr0: 8005003b cr4: 001526e0 > (XEN) cr3: b20fc000 cr2: > (XEN) ds: es: fs: gs: ss: cs: e008 > (XEN) Xen code around > (hap.c#local_events_need_delivery+0x27/0x40): > (XEN) 0d ad fa ff 48 8b 47 08 <80> 38 00 74 09 80 78 01 00 0f 94 c0 eb 02 31 > c0 > (XEN) Xen stack trace from rsp=82d080307cc8: > (XEN)82d080307d08 82d08022fc47 83023f5a5000 > (XEN)83023f5a5648 82d080307d4c 2400 > (XEN)82d080307d38 82d08020008c 000d 8300b1efd000 > (XEN)83023f5a5000 82d080307d4c 82d080307d78 82d0802cad30 > (XEN)00203000 83023f5a5000 82d0802bf860 > (XEN)0001 8308bef0 82d080307de8 82d0802c91e0 > (XEN)82d080307de8 82d080143900 82d080307de8 > (XEN)8308bf00 82d0802eb480 82d080307dc4 82d08028b1cd > (XEN)8308bf00 0001 83023f5a5000 > (XEN)82d080307f08 82d0802bf0c9 > (XEN) 82d080307f18 8308bee0 0001 > (XEN)0001 0001 0010 > (XEN)0001 00247000 8308bef4 0010 > (XEN)8301 00247001 0014 0001 > (XEN)8300ffec 8308bef0 82d0802e0640 8308bfb0 > (XEN) 0111 0008 > (XEN)0001006e 0003 02f8 > (XEN)ad5c0bd0 0001 0008 > (XEN) 82d080100073 > (XEN) > (XEN) Xen call trace: > (XEN)[] hap.c#local_events_need_delivery+0x27/0x40 > (XEN)[] hap_set_allocation+0x107/0x130 > (XEN)[] paging_set_allocation+0x4c/0x80 > (XEN)[] domain_build.c#hvm_setup_p2m+0x70/0x1a0 > (XEN)[] domain_build.c#construct_dom0_hvm+0x60/0x120 > (XEN)[] __start_xen+0x1ea9/0x23a0 > (XEN)[] __high_start+0x53/0x60 > (XEN) > (XEN) Pagetable walk from : Sadly you don't make clear what pointer it is that is NULL at that point. > I've tried setting current to d->vcpu[0], but that just makes the call to > hypercall_preempt_check crash in some scheduler assert. In any case, I've > added the preempt parameter to the paging_set_allocation function, but I > don't plan to use it in the domain builder for the time being. Does that > sound right? Not really, new huge latency issues like this shouldn't be reintroduced; we've been fighting hard to get rid of those (and we still occasionally find some no-one had noticed before). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On Tue, Aug 2, 2016 at 10:11 AM, Julien Grallwrote: > > > On 02/08/16 17:00, Tamas K Lengyel wrote: >> >> On Tue, Aug 2, 2016 at 1:38 AM, Julien Grall wrote: >> Hi Julien, >> as I said our use-case is purely external so I don't have an actual >> use-case for anything being accessible from within the guest. However, >> I could imagine the gfn remapping be used to protect kernel memory >> areas against information disclosure by only switching to the >> accessible mapping >> when certain conditions are met. Also, I had been able to use >> mem_access from domUs with the use of XSM so I believe it would be >> possible for a domain to enable mem_access on itself that way and thus >> not having to implement #VE exactly the way x86 does and still have >> feature parity. > > > I believe that your suggestion does not currently work. memaccess will pause > the current vCPU whilst the introspection app will handle the access (see > p2m_mem_access_check). How can the guest handle the event if the vCPU has > been paused? > True. Not in all cases though - there are async violations - but yea, that certainly could be a pain. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On 02/08/16 08:34, Julien Grall wrote: > Hi Andrew, > > On 02/08/2016 00:14, Andrew Cooper wrote: >> On 01/08/2016 19:15, Julien Grall wrote: >>> On 01/08/16 18:10, Sergej Proskurin wrote: Hello all, >>> >>> Hello Sergej, >>> The following patch series can be found on Github[0] and is part of my contribution to this year's Google Summer of Code (GSoC)[1]. My project is managed by the organization The Honeynet Project. As part of GSoC, I am being supervised by the Xen developer Tamas K. Lengyel, George D. Webster, and Steven Maresca. In this patch series, we provide an implementation of the altp2m subsystem for ARM. Our implementation is based on the altp2m subsystem for x86, providing additional --alternate-- views on the guest's physical memory by means of the ARM 2nd stage translation mechanism. The patches introduce new HVMOPs and extend the p2m subsystem. Also, we extend libxl to support altp2m on ARM and modify xen-access to test the suggested functionality. To be more precise, altp2m allows to create and switch to additional p2m views (i.e. gfn to mfn mappings). These views can be manipulated and activated as will through the provided HVMOPs. In this way, the active guest instance in question can seamlessly proceed execution without noticing that anything has changed. The prime scope of application of altp2m is Virtual Machine Introspection, where guest systems are analyzed from the outside of the VM. Altp2m can be activated by means of the guest control parameter "altp2m" on x86 and ARM architectures. The altp2m functionality by default can also be used from within the guest by design. For use-cases requiring purely external access to altp2m, a custom XSM policy is necessary on both x86 and ARM. >>> >>> As said on the previous version, altp2m operation *should not* be >>> exposed to ARM guest. Any design written for x86 may not fit exactly >>> for ARM (and vice versa), you will need to explain why you think we >>> should follow the same pattern. >> >> Sorry, but I am going to step in here and disagree. All the x86 >> justifications for altp2m being accessible to guests apply equally to >> ARM, as they are hardware independent. >> >> I realise you are maintainer, but the onus is on you to justify why the >> behaviour should be different between x86 and ARM, rather than simply to >> complain at it being the same. >> >> Naturally, technical issues about the details of the implementation, or >> the algorithms etc. are of course fine, but I don't see any plausible >> reason why ARM should purposefully different from x86 in terms of >> available functionality, and several good reasons why it should be the >> same (least of all, feature parity across architectures). > > The question here, is how a guest could take advantage to access to > altp2m on ARM today? Whilst on x86 a guest could be notified about > memaccess change, this is not yet the case on ARM. Does ARM have anything like #VE whereby an in-guest entity can receive notification of violations? If not, then I can't see any way that an in-guest entity can usefully use altp2m, and by that logic, shouldn't have access to something it can't usefully use. I suppose something could be synthesized with an event channel, if in-guest use is wanted/needed. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On 02/08/16 17:00, Tamas K Lengyel wrote: On Tue, Aug 2, 2016 at 1:38 AM, Julien Grallwrote: Hi Julien, as I said our use-case is purely external so I don't have an actual use-case for anything being accessible from within the guest. However, I could imagine the gfn remapping be used to protect kernel memory areas against information disclosure by only switching to the accessible mapping when certain conditions are met. Also, I had been able to use mem_access from domUs with the use of XSM so I believe it would be possible for a domain to enable mem_access on itself that way and thus not having to implement #VE exactly the way x86 does and still have feature parity. I believe that your suggestion does not currently work. memaccess will pause the current vCPU whilst the introspection app will handle the access (see p2m_mem_access_check). How can the guest handle the event if the vCPU has been paused? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 3/4] tools: use pidfile for test if xenstored is running
Instead of trying to read xenstore via xenstore-read use the pidfile of xenstored for the test whether xenstored is running. This prepares support of xenstore domain, as trying to read xenstore will block for ever in case xenstore domain is started after trying to read. Signed-off-by: Juergen GrossAcked-by: Wei Liu --- V4: use @XEN_RUN_DIR@ as requested by Wei Liu --- tools/hotplug/Linux/init.d/xencommons.in | 2 +- tools/hotplug/Linux/launch-xenstore.in | 58 +++- 2 files changed, 35 insertions(+), 25 deletions(-) diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in index a32608c..a6a40d6 100644 --- a/tools/hotplug/Linux/init.d/xencommons.in +++ b/tools/hotplug/Linux/init.d/xencommons.in @@ -96,7 +96,7 @@ case "$1" in do_start ;; status) -${bindir}/xenstore-read -s / +test -f @XEN_RUN_DIR@/xenstored.pid ;; stop) do_stop diff --git a/tools/hotplug/Linux/launch-xenstore.in b/tools/hotplug/Linux/launch-xenstore.in index 61541be..32de540 100644 --- a/tools/hotplug/Linux/launch-xenstore.in +++ b/tools/hotplug/Linux/launch-xenstore.in @@ -18,38 +18,48 @@ XENSTORED=@XENSTORED@ . @XEN_SCRIPT_DIR@/hotplugpath.sh -test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons && . @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons -time=0 -timeout=30 +test_xenstore () { + test -f @XEN_RUN_DIR@/xenstored.pid + return $? +} -if ! `${bindir}/xenstore-read -s / >/dev/null 2>&1` -then - test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@" - rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null - test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T @XEN_LOG_DIR@/xenstored-trace.log" +timeout_xenstore () { + local time=0 + local timeout=30 - if [ -n "$XENSTORED" ] ; then - echo -n Starting $XENSTORED... - $XENSTORED --pid-file @XEN_RUN_DIR@/xenstored.pid $XENSTORED_ARGS - else - echo "No xenstored found" - exit 1 - fi - - # Wait for xenstored to actually come up, timing out after 30 seconds - while [ $time -lt $timeout ] && ! `${bindir}/xenstore-read -s / >/dev/null 2>&1` ; do - echo -n . - time=$(($time+1)) - sleep 1 + while [ $time -lt $timeout ] && ! test_xenstore ; do + echo -n . + time=$(($time+1)) + sleep 1 done echo - + # Exit if we timed out if ! [ $time -lt $timeout ] ; then - echo Could not start xenstored - exit 1 + echo "Could not start $@" + return 1 fi + + return 0 +} + +test_xenstore && exit 0 + +test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons && . @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons + +test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@" +rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null +test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T @XEN_LOG_DIR@/xenstored-trace.log" + +if [ -n "$XENSTORED" ] ; then + echo -n Starting $XENSTORED... + $XENSTORED --pid-file @XEN_RUN_DIR@/xenstored.pid $XENSTORED_ARGS +else + echo "No xenstored found" + exit 1 fi +timeout_xenstore $XENSTORED || exit 1 + exit 0 -- 2.6.6 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: create xenstore nodes for control/feature-XXX flags
On Mon, Aug 01, 2016 at 03:19:35PM +0100, Wei Liu wrote: > On Mon, Aug 01, 2016 at 09:57:10AM +0100, Paul Durrant wrote: > > The xenstore-paths documentation specifies various control/feature-XXX > > flags to allow a guest to tell a toolstack about its abilities to > > respond to values written to control/shutdown. However, because the > > parent control xenstore key is created read-only to the guest, unless > > empty nodes for the feature flags are also created reat/write by the > > toolstack, the guest will not be able to set any flags. > > > > This patch adds code to create all specified feature flag nodes at > > domain creation time. > > > > Signed-off-by: Paul Durrant> > Cc: Ian Jackson > > Cc: Wei Liu > > This is in accordance with docs/mis/xenstore-paths.markdown. > > Acked-by: Wei Liu Pushed. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On Tue, Aug 2, 2016 at 10:05 AM, George Dunlapwrote: > On 02/08/16 16:48, Tamas K Lengyel wrote: >> On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap >> wrote: >>> On 02/08/16 08:38, Julien Grall wrote: Hello Tamas, On 01/08/2016 21:41, Tamas K Lengyel wrote: > On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall > wrote: >>> we did discuss whether altp2m on ARM should be exposed to guests or >>> not but we did not agree whether restricting it on ARM is absolutely >>> necessary. Altp2m was designed even on the x86 to be accessible from >>> within the guest on all systems irrespective of actual hardware >>> support for it. Thus, this design fits ARM as well where there is no >>> dedicated hardware support, from the altp2m perspective there is no >>> difference. >> >> >> Really? I looked at the design document [1] which is Intel focus. >> Similar >> think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c). > > That design cover letter mentions specifically "Both VMFUNC and #VE > are designed such that a VMM can emulate them on legacy CPUs". While > they certainly had only Intel hardware in-mind, the software route can > also be taken on ARM as well. As our primary use-case is purely > external use of altp2m we have not implemented the bits that enable > the injection of mem_access faults into the guest (equivalent of #VE). > Whether without that the altp2m switching from within the guest make > sense or not is beyond the scope of this series but as it could > technically be implemented in the future, I don't see a reason to > disable that possibility right away. The question here, is how a guest could take advantage to access to altp2m on ARM today? Whilst on x86 a guest could be notified about memaccess change, this is not yet the case on ARM. So, from my understanding, exposing this feature to a guest is like exposing a no-op with side effects. We should avoid to expose feature to the guest until there is a real usage and the guest could do something useful with it. >>> >>> It seems like having guest altp2m support without the equivalent of a >>> #VE does seem pretty useless. Would you disagree with this assessment, >>> Tamas? >>> >>> Every interface we expose to the guest increases the surface of attack; >>> so it seems like until there is a usecase for guest altp2m, we should >>> probably disable it. >>> >> >> Hi George, >> I disagree. On x86 using VMFUNC EPTP switching is not bound to #VE in >> any way. The two can certainly benefit from being used together but >> there is no enforced interdependence between the two. It is certainly >> possible to derive a use-case for just having the altp2m switch >> operations available to the guest. For example, I could imagine the >> gfn remapping be used to protect kernel memory areas against >> information disclosure by only switching to the accessible mapping >> when certain conditions are met. > > That's true -- I suppose gfn remapping is something that would be useful > even without #VE. > >> As our usecase is purely external implementing the emulated #VE at >> this time has been deemed out-of-scope but it could be certainly >> implemented for ARM as well. Now that I'm thinking about it it might >> actually not be necessary to implement the #VE at all the way x86 does >> by injecting an interrupt as we might just be able to allow the domain >> to enable the existing mem_access ring directly. > > That would be a possibility, but before that could be considered a > feature we'd need someone to go through and make sure that this > self-mem_access funcitonality worked properly. (And I take it at the > moment that's not work you're volunteering to do.) Right, not at this time, it's a bit beyond our scope for now. Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 0/4] tools: make xenstore domain/daemon configurable
Add a configuration option to /etc/sysconfig/xencommons to let the user configure whether he wants to start xenstore service as a daemon or as a stubdom. Changes in V5: - patch 2: undo &> to 2> conversion Changes in V4: - patch 1: remove sd_booted() test, undo unintended white space changes - patch 3: use @XEN_RUN_DIR@ as requested by Wei Liu Changes in V3: - patch 1: re-add sd_notify() call - split up former patch 2 into 3 patches as requested by Ian Jackson - patch 4 (was 2): remove check for running xenstore domain, as this is done in init-xenstore-domain already - patch 4 (was 2): if booted with systemd send a systemd-notify message in the xenstore domain case - patch 4 (was 2): if booted with systemd don't wait until xenstore daemon is running, as the daemon will have sent a notify message by its own Changes in V2: - move service type modification form patch 2 to patch 1 as implied by Ross Lagerwall (at least I guess so) - add .gitignore entry for launch-xenstore Juergen Gross (4): tools: remove systemd xenstore socket definitions tools: split out xenstored starting form xencommons tools: use pidfile for test if xenstored is running tools: make xenstore domain easy configurable .gitignore | 1 + tools/configure| 7 +- tools/configure.ac | 3 +- tools/hotplug/Linux/Makefile | 1 + tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 42 - tools/hotplug/Linux/init.d/xencommons.in | 38 +--- tools/hotplug/Linux/launch-xenstore.in | 87 + tools/hotplug/Linux/systemd/Makefile | 5 - tools/hotplug/Linux/systemd/xenstored.service.in | 13 +-- tools/hotplug/Linux/systemd/xenstored.socket.in| 13 --- tools/hotplug/Linux/systemd/xenstored_ro.socket.in | 13 --- tools/ocaml/xenstored/systemd.ml | 2 - tools/ocaml/xenstored/systemd.mli | 8 -- tools/ocaml/xenstored/systemd_stubs.c | 98 tools/ocaml/xenstored/utils.ml | 9 +- tools/ocaml/xenstored/xenstored.ml | 3 +- tools/xenstore/xenstored_core.c| 103 + 17 files changed, 146 insertions(+), 300 deletions(-) create mode 100644 tools/hotplug/Linux/launch-xenstore.in delete mode 100644 tools/hotplug/Linux/systemd/xenstored.socket.in delete mode 100644 tools/hotplug/Linux/systemd/xenstored_ro.socket.in -- 2.6.6 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 4/4] tools: make xenstore domain easy configurable
Add configuration entries to sysconfig.xencommons for selection of the xenstore type (domain or daemon) and start the selected xenstore service via a script called from sysvinit or systemd. Signed-off-by: Juergen GrossAcked-by: Wei Liu --- V3: - remove check for running xenstore domain, as this is done in init-xenstore-domain already - if booted with systemd send a systemd-notify message in the xenstore domain case - if booted with systemd don't wait until xenstore daemon is running, as the daemon will have sent a notify message by its own - split up patch as requested by Ian Jackson V2: - add .gitignore entry for launch-xenstore --- tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 42 -- tools/hotplug/Linux/launch-xenstore.in | 42 -- tools/hotplug/Linux/systemd/xenstored.service.in | 8 + 3 files changed, 72 insertions(+), 20 deletions(-) diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in index c27a476..cc8185c 100644 --- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in +++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in @@ -6,12 +6,24 @@ #XENCONSOLED_TRACE=[none|guest|hv|all] ## Type: string +## Default: daemon +# +# Select type of xentore service. +# +# This can be either of: +# * daemon +# * domain +# +# Changing this requires a reboot to take effect. +# +#XENSTORETYPE=daemon + +## Type: string ## Default: xenstored # # Select xenstore implementation, this can be either -# of these below. If using systemd it's preferred that you -# just edit the xenstored.service unit file and change -# the XENSTORED variable there. +# of these below. +# Only evaluated if XENSTORETYPE is "daemon". # # This can be either of: # * @sbindir@/oxenstored @@ -26,21 +38,45 @@ # Additional commandline arguments to start xenstored, # like "--trace-file @XEN_LOG_DIR@/xenstored-trace.log" # See "@sbindir@/xenstored --help" for possible options. +# Only evaluated if XENSTORETYPE is "daemon". XENSTORED_ARGS= ## Type: string ## Default: Not defined, tracing off # # Log xenstored messages +# Only evaluated if XENSTORETYPE is "daemon". #XENSTORED_TRACE=[yes|on|1] ## Type: string ## Default: "@XEN_LIB_STORED@" # # Running xenstored on XENSTORED_ROOTDIR +# Only evaluated if XENSTORETYPE is "daemon". #XENSTORED_ROOTDIR=@XEN_LIB_STORED@ ## Type: string +## Default: @LIBEXEC@/boot/xenstore-stubdom.gz +# +# xenstore domain kernel. +# Only evaluated if XENSTORETYPE is "domain". +#XENSTORE_DOMAIN_KERNEL=@LIBEXEC@/boot/xenstore-stubdom.gz + +## Type: integer +## Default: 8 +# +# xenstore domain memory size in MiB. +# Only evaluated if XENSTORETYPE is "domain". +#XENSTORE_DOMAIN_SIZE=8 + +## Type: string +## Default: "" +# +# Additional arguments for starting the xenstore domain. +# Only evaluated if XENSTORETYPE is "domain". +XENSTORE_DOMAIN_ARGS= + +## Type: string ## Default: Not defined, xenbackendd debug mode off # # Running xenbackendd in debug mode diff --git a/tools/hotplug/Linux/launch-xenstore.in b/tools/hotplug/Linux/launch-xenstore.in index 32de540..46defd6 100644 --- a/tools/hotplug/Linux/launch-xenstore.in +++ b/tools/hotplug/Linux/launch-xenstore.in @@ -48,18 +48,40 @@ test_xenstore && exit 0 test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons && . @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons -test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@" -rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null -test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T @XEN_LOG_DIR@/xenstored-trace.log" +[ "$XENSTORETYPE" = "" ] && XENSTORETYPE=daemon + +/bin/mkdir -p @XEN_RUN_DIR@ + +[ "$XENSTORETYPE" = "daemon" ] && { + [ -z "$XENSTORED_ROOTDIR" ] && XENSTORED_ROOTDIR="@XEN_LIB_STORED@" + /bin/rm -f $XENSTORED_ROOTDIR/tdb* &>/dev/null + [ -z "$XENSTORED_TRACE" ] || XENSTORED_ARGS="$XENSTORED_ARGS -T @XEN_LOG_DIR@/xenstored-trace.log" + [ -z "$XENSTORED" ] && XENSTORED=@XENSTORED@ + [ -x "$XENSTORED" ] || { + echo "No xenstored found" + exit 1 + } -if [ -n "$XENSTORED" ] ; then echo -n Starting $XENSTORED... $XENSTORED --pid-file @XEN_RUN_DIR@/xenstored.pid $XENSTORED_ARGS -else - echo "No xenstored found" - exit 1 -fi -timeout_xenstore $XENSTORED || exit 1 + systemd-notify --booted 2>/dev/null || timeout_xenstore $XENSTORED || exit 1 -exit 0 + exit 0 +} + +[ "$XENSTORETYPE" = "domain" ] && { + [ -z "$XENSTORE_DOMAIN_KERNEL" ] && XENSTORE_DOMAIN_KERNEL=@LIBEXEC@/boot/xenstore-stubdom.gz + XENSTORE_DOMAIN_ARGS="$XENSTORE_DOMAIN_ARGS --kernel $XENSTORE_DOMAIN_KERNEL" + [ -z "$XENSTORE_DOMAIN_SIZE" ] && XENSTORE_DOMAIN_SIZE=8 + XENSTORE_DOMAIN_ARGS="$XENSTORE_DOMAIN_ARGS --memory $XENSTORE_DOMAIN_SIZE" + + echo -n Starting
[Xen-devel] [PATCH v5 2/4] tools: split out xenstored starting form xencommons
In order to prepare starting a xenstore domain split out the starting of the xenstore daemon from the xencommons script into a dedicated launch-xenstore script. A rerun of autogen.sh is required. Signed-off-by: Juergen Gross--- V5: undo &> to 2> conversion --- .gitignore | 1 + tools/configure | 3 +- tools/configure.ac | 1 + tools/hotplug/Linux/Makefile | 1 + tools/hotplug/Linux/init.d/xencommons.in | 36 ++--- tools/hotplug/Linux/launch-xenstore.in | 55 6 files changed, 63 insertions(+), 34 deletions(-) create mode 100644 tools/hotplug/Linux/launch-xenstore.in diff --git a/.gitignore b/.gitignore index 9b8dece..d193820 100644 --- a/.gitignore +++ b/.gitignore @@ -157,6 +157,7 @@ tools/hotplug/Linux/init.d/xen-watchdog tools/hotplug/Linux/init.d/xencommons tools/hotplug/Linux/init.d/xendomains tools/hotplug/Linux/init.d/xendriverdomain +tools/hotplug/Linux/launch-xenstore tools/hotplug/Linux/systemd/*.conf tools/hotplug/Linux/systemd/*.mount tools/hotplug/Linux/systemd/*.socket diff --git a/tools/configure b/tools/configure index 1c84c6c..51f16c5 100755 --- a/tools/configure +++ b/tools/configure @@ -2410,7 +2410,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu -ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/FreeBSD/rc.d/xendriverdomain hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/sysconfig.xendomains hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/init.d/xendriverdomain hotplug/Linux/vif-setup hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons hotplug/NetBSD/rc.d/xendriverdomain libxl/xenlight.pc.in libxl/xlutil.pc.in ocaml/xenstored/oxenstored.conf" +ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/FreeBSD/rc.d/xendriverdomain hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/sysconfig.xendomains hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/init.d/xendriverdomain hotplug/Linux/launch-xenstore hotplug/Linux/vif-setup hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons hotplug/NetBSD/rc.d/xendriverdomain libxl/xenlight.pc.in libxl/xlutil.pc.in ocaml/xenstored/oxenstored.conf" ac_config_headers="$ac_config_headers config.h" @@ -10376,6 +10376,7 @@ do "hotplug/Linux/init.d/xencommons") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/init.d/xencommons" ;; "hotplug/Linux/init.d/xendomains") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/init.d/xendomains" ;; "hotplug/Linux/init.d/xendriverdomain") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/init.d/xendriverdomain" ;; +"hotplug/Linux/launch-xenstore") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/launch-xenstore" ;; "hotplug/Linux/vif-setup") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/vif-setup" ;; "hotplug/Linux/xen-hotplug-common.sh") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xen-hotplug-common.sh" ;; "hotplug/Linux/xendomains") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xendomains" ;; diff --git a/tools/configure.ac b/tools/configure.ac index f991ab3..3a4abb5 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -15,6 +15,7 @@ hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/init.d/xendriverdomain +hotplug/Linux/launch-xenstore hotplug/Linux/vif-setup hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile index 6d6ccee..29280cb 100644 --- a/tools/hotplug/Linux/Makefile +++ b/tools/hotplug/Linux/Makefile @@ -30,6 +30,7 @@ XEN_SCRIPTS += block-drbd-probe XEN_SCRIPTS += block-dummy XEN_SCRIPTS += $(XEN_SCRIPTS-y) XEN_SCRIPTS += colo-proxy-setup +XEN_SCRIPTS += launch-xenstore SUBDIRS-$(CONFIG_SYSTEMD) += systemd diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in index 2d8f30b..a32608c 100644 --- a/tools/hotplug/Linux/init.d/xencommons.in +++ b/tools/hotplug/Linux/init.d/xencommons.in @@ -18,7 +18,6 @@ # Description: Starts and stops the daemons neeeded for xl/xend ### END INIT INFO -XENSTORED=@XENSTORED@ BACKEND_MODULES="@LINUX_BACKEND_MODULES@" . @XEN_SCRIPT_DIR@/hotplugpath.sh @@ -53,8 +52,6 @@ if test -f /proc/xen/capabilities && \ fi do_start () { -local time=0 - local timeout=30 local mod for mod in $BACKEND_MODULES ; do modprobe "$mod" &>/dev/null ; done @@ -62,37 +59,10 @@ do_start () { mkdir -p ${XEN_RUN_DIR} mkdir -p ${XEN_LOCK_DIR} - if ! `${bindir}/xenstore-read -s / >/dev/null 2>&1` - then - test -z
[Xen-devel] [PATCH v5 1/4] tools: remove systemd xenstore socket definitions
On a system with systemd the xenstore sockets are created via systemd. Remove the related configuration files in order to be able to decide at runtime whether the sockets should be created or not. This will enable Xen to start xenstore either via a daemon or via a stub domain. As the xenstore domain start program will exit after it has done its job prepare the same behaviour to be tolerated by systemd for the xenstore daemon by specifying the appropriate flags in the service file. A rerun of autogen.sh is required. Signed-off-by: Juergen GrossAcked-by: Wei Liu --- V4: remove sd_booted() test, undo unintended white space changes V3: re-add sd_notify() call --- tools/configure| 4 +- tools/configure.ac | 2 - tools/hotplug/Linux/systemd/Makefile | 5 - tools/hotplug/Linux/systemd/xenstored.service.in | 5 +- tools/hotplug/Linux/systemd/xenstored.socket.in| 13 --- tools/hotplug/Linux/systemd/xenstored_ro.socket.in | 13 --- tools/ocaml/xenstored/systemd.ml | 2 - tools/ocaml/xenstored/systemd.mli | 8 -- tools/ocaml/xenstored/systemd_stubs.c | 98 tools/ocaml/xenstored/utils.ml | 9 +- tools/ocaml/xenstored/xenstored.ml | 3 +- tools/xenstore/xenstored_core.c| 103 + 12 files changed, 10 insertions(+), 255 deletions(-) delete mode 100644 tools/hotplug/Linux/systemd/xenstored.socket.in delete mode 100644 tools/hotplug/Linux/systemd/xenstored_ro.socket.in diff --git a/tools/configure b/tools/configure index 5b5dcce..1c84c6c 100755 --- a/tools/configure +++ b/tools/configure @@ -9670,7 +9670,7 @@ fi if test "x$systemd" = "xy"; then : -ac_config_files="$ac_config_files hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xendriverdomain.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket" +ac_config_files="$ac_config_files hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xendriverdomain.service hotplug/Linux/systemd/xenstored.service" fi @@ -10394,8 +10394,6 @@ do "hotplug/Linux/systemd/xendomains.service") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/systemd/xendomains.service" ;; "hotplug/Linux/systemd/xendriverdomain.service") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/systemd/xendriverdomain.service" ;; "hotplug/Linux/systemd/xenstored.service") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/systemd/xenstored.service" ;; -"hotplug/Linux/systemd/xenstored.socket") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/systemd/xenstored.socket" ;; -"hotplug/Linux/systemd/xenstored_ro.socket") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/systemd/xenstored_ro.socket" ;; *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;; esac diff --git a/tools/configure.ac b/tools/configure.ac index 87e14a8..f991ab3 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -438,8 +438,6 @@ AS_IF([test "x$systemd" = "xy"], [ hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xendriverdomain.service hotplug/Linux/systemd/xenstored.service -hotplug/Linux/systemd/xenstored.socket -hotplug/Linux/systemd/xenstored_ro.socket ]) ]) diff --git a/tools/hotplug/Linux/systemd/Makefile b/tools/hotplug/Linux/systemd/Makefile index 558e459..7d24bbe 100644 --- a/tools/hotplug/Linux/systemd/Makefile +++ b/tools/hotplug/Linux/systemd/Makefile @@ -6,9 +6,6 @@ XEN_SYSTEMD_MODULES = xen.conf XEN_SYSTEMD_MOUNT = proc-xen.mount XEN_SYSTEMD_MOUNT += var-lib-xenstored.mount -XEN_SYSTEMD_SOCKET = xenstored.socket -XEN_SYSTEMD_SOCKET += xenstored_ro.socket - XEN_SYSTEMD_SERVICE = xenstored.service XEN_SYSTEMD_SERVICE += xenconsoled.service XEN_SYSTEMD_SERVICE += xen-qemu-dom0-disk-backend.service @@ -19,7 +16,6 @@ XEN_SYSTEMD_SERVICE += xendriverdomain.service ALL_XEN_SYSTEMD = $(XEN_SYSTEMD_MODULES) \ $(XEN_SYSTEMD_MOUNT)\ - $(XEN_SYSTEMD_SOCKET) \ $(XEN_SYSTEMD_SERVICE) .PHONY: all @@ -38,7 +34,6 @@ install: $(ALL_XEN_SYSTEMD) $(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_DIR) [ -d
Re: [Xen-devel] [PATCH v3] libxl: memory size in kb requires 64 bit variable
On Tue, Aug 02, 2016 at 10:49:24AM +0100, Wei Liu wrote: > On Thu, Jul 28, 2016 at 03:35:19PM +0200, Juergen Gross wrote: > > libxl_set_memory_target() and several other interface functions of > > libxl use a 32 bit sized parameter for a memory size value in kBytes. > > This limits the maximum size to be passed in such a parameter > > depending on signedness of the parameter to 2TB or 4TB. > > > > Correct this by using 64 bit types. > > > > Signed-off-by: Juergen Gross> > Reviewed-by: Dario Faggioli > > --- > [...] > > +static int libxl__memkb_64to32(libxl_ctx *ctx, int rc, > > + uint64_t val64, uint32_t *ptr32) > > +{ > > It's a bit unusual for an internal function to take ctx. But I think you > want to avoid code repetition in the compact functions. > > I can live with this. > > Acked-by: Wei Liu > > And thanks Dario for reviewing. Pushed. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] docs: define semantics of vncpasswd in xl.cfg
On Mon, Aug 01, 2016 at 10:44:45AM +0100, Ian Jackson wrote: > Jim Fehlig writes ("[PATCH] docs: define semantics of vncpasswd in xl.cfg"): > > A recent discussion around LSN-2016-0001 [1] included defining > > the sematics of an empty string for a VNC password. It was stated > > that "libxl interprets an empty password in the caller's > > configuration to mean that passwordless access should be permitted". > > > > The same applies for vncpasswd setting in xl.cfg. This patch > > extends to xl.cfg documentation to define the semantics of setting > > vncpasswd to an empty string. > > Acked-by: Ian Jackson> > I think this is a backport candidate. > Acked + pushed. > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9] x86/mem-sharing: mem-sharing a range of memory
On Tue, Aug 02, 2016 at 01:17:01PM +0100, Wei Liu wrote: > On Mon, Aug 01, 2016 at 11:14:27AM -0600, Tamas K Lengyel wrote: > > Currently mem-sharing can be performed on a page-by-page basis from the > > control > > domain. However, this process is quite wasteful when a range of pages have > > to > > be deduplicated. > > > > This patch introduces a new mem_sharing memop for range sharing where > > the user doesn't have to separately nominate each page in both the source > > and > > destination domain, and the looping over all pages happen in the hypervisor. > > This significantly reduces the overhead of sharing a range of memory. > > > > Signed-off-by: Tamas K Lengyel> > Acked-by: Wei Liu > > Reviewed-by: Andrew Cooper > > I notice this patch has got sufficient acks. > > I will queue this up. Pushed. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix printing hotplug arguments/environment
Pushed. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request
On Tue, Aug 2, 2016 at 9:23 AM, Tamas K Lengyelwrote: > On Aug 2, 2016 06:45, "Jan Beulich" wrote: >> >> >>> On 01.08.16 at 18:52, wrote: >> > --- a/xen/arch/x86/hvm/hvm.c >> > +++ b/xen/arch/x86/hvm/hvm.c >> > @@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, >> > unsigned long gla, >> > int rc, fall_through = 0, paged = 0; >> > int sharing_enomem = 0; >> > vm_event_request_t *req_ptr = NULL; >> > -bool_t ap2m_active; >> > +bool_t ap2m_active, sync = 0; >> > >> > /* On Nested Virtualization, walk the guest page table. >> > * If this succeeds, all is fine. >> > @@ -1846,11 +1846,12 @@ int hvm_hap_nested_page_fault(paddr_t gpa, >> > unsigned long gla, >> > } >> > } >> > >> > -if ( p2m_mem_access_check(gpa, gla, npfec, _ptr) ) >> > -{ >> > +sync = p2m_mem_access_check(gpa, gla, npfec, _ptr); >> > + >> > +if ( !sync ) { >> >> Coding style. If you dropped the brace entirely, you could at once >> adjust ... >> >> > fall_through = 1; >> > } else { >> >> ... coding style here. >> >> > -/* Rights not promoted, vcpu paused, work here is done >> > */ >> > +/* Rights not promoted (aka. sync event), work here is >> > done */ >> >> Comment style. More of these elsewhere. >> >> > +int hvm_monitor_mem_access(struct vcpu* v, bool_t sync, >> >> Coding style. >> >> > + vm_event_request_t *req) >> > +{ >> > +return monitor_traps(v, sync, req); >> > +} >> >> Overall - is this a useful wrapper? Why can't the caller(s) call >> monitor_traps() directly? And if you really want to keep it, it would >> probably better be an inline one. >> > > The reason for this wrapper is to avoid having to include the common monitor > header here. I can move it into the hvm monitor header as inline, that's no > problem. > Actually, making it into inline would require that hvm/monitor.h include the common monitor.h as well, at which point having the wrapper would be useless as hvm.c would have effectively include common monitor.h too. So yea, the goal is to avoid having to include both common/monitor and hvm/monitor in hvm.c and it needs this kind of wrapper. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On 02/08/16 16:48, Tamas K Lengyel wrote: > On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap> wrote: >> On 02/08/16 08:38, Julien Grall wrote: >>> Hello Tamas, >>> >>> On 01/08/2016 21:41, Tamas K Lengyel wrote: On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall wrote: >> we did discuss whether altp2m on ARM should be exposed to guests or >> not but we did not agree whether restricting it on ARM is absolutely >> necessary. Altp2m was designed even on the x86 to be accessible from >> within the guest on all systems irrespective of actual hardware >> support for it. Thus, this design fits ARM as well where there is no >> dedicated hardware support, from the altp2m perspective there is no >> difference. > > > Really? I looked at the design document [1] which is Intel focus. > Similar > think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c). That design cover letter mentions specifically "Both VMFUNC and #VE are designed such that a VMM can emulate them on legacy CPUs". While they certainly had only Intel hardware in-mind, the software route can also be taken on ARM as well. As our primary use-case is purely external use of altp2m we have not implemented the bits that enable the injection of mem_access faults into the guest (equivalent of #VE). Whether without that the altp2m switching from within the guest make sense or not is beyond the scope of this series but as it could technically be implemented in the future, I don't see a reason to disable that possibility right away. >>> >>> The question here, is how a guest could take advantage to access to >>> altp2m on ARM today? Whilst on x86 a guest could be notified about >>> memaccess change, this is not yet the case on ARM. >>> >>> So, from my understanding, exposing this feature to a guest is like >>> exposing a no-op with side effects. We should avoid to expose feature to >>> the guest until there is a real usage and the guest could do something >>> useful with it. >> >> It seems like having guest altp2m support without the equivalent of a >> #VE does seem pretty useless. Would you disagree with this assessment, >> Tamas? >> >> Every interface we expose to the guest increases the surface of attack; >> so it seems like until there is a usecase for guest altp2m, we should >> probably disable it. >> > > Hi George, > I disagree. On x86 using VMFUNC EPTP switching is not bound to #VE in > any way. The two can certainly benefit from being used together but > there is no enforced interdependence between the two. It is certainly > possible to derive a use-case for just having the altp2m switch > operations available to the guest. For example, I could imagine the > gfn remapping be used to protect kernel memory areas against > information disclosure by only switching to the accessible mapping > when certain conditions are met. That's true -- I suppose gfn remapping is something that would be useful even without #VE. > As our usecase is purely external implementing the emulated #VE at > this time has been deemed out-of-scope but it could be certainly > implemented for ARM as well. Now that I'm thinking about it it might > actually not be necessary to implement the #VE at all the way x86 does > by injecting an interrupt as we might just be able to allow the domain > to enable the existing mem_access ring directly. That would be a possibility, but before that could be considered a feature we'd need someone to go through and make sure that this self-mem_access funcitonality worked properly. (And I take it at the moment that's not work you're volunteering to do.) But the gfn remapping is something that could be used immediately. I'd leave it to Julien to determine the window of functionality he wants to support. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On Tue, Aug 2, 2016 at 1:38 AM, Julien Grallwrote: > Hello Tamas, > > On 01/08/2016 21:41, Tamas K Lengyel wrote: >> >> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall wrote: we did discuss whether altp2m on ARM should be exposed to guests or not but we did not agree whether restricting it on ARM is absolutely necessary. Altp2m was designed even on the x86 to be accessible from within the guest on all systems irrespective of actual hardware support for it. Thus, this design fits ARM as well where there is no dedicated hardware support, from the altp2m perspective there is no difference. >>> >>> >>> >>> Really? I looked at the design document [1] which is Intel focus. Similar >>> think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c). >> >> >> That design cover letter mentions specifically "Both VMFUNC and #VE >> are designed such that a VMM can emulate them on legacy CPUs". While >> they certainly had only Intel hardware in-mind, the software route can >> also be taken on ARM as well. As our primary use-case is purely >> external use of altp2m we have not implemented the bits that enable >> the injection of mem_access faults into the guest (equivalent of #VE). >> Whether without that the altp2m switching from within the guest make >> sense or not is beyond the scope of this series but as it could >> technically be implemented in the future, I don't see a reason to >> disable that possibility right away. > > > The question here, is how a guest could take advantage to access to altp2m > on ARM today? Whilst on x86 a guest could be notified about memaccess > change, this is not yet the case on ARM. > > So, from my understanding, exposing this feature to a guest is like exposing > a no-op with side effects. We should avoid to expose feature to the guest > until there is a real usage and the guest could do something useful with it. > > This has always been the case where some features were not fully ported on > ARM until there is an actual usage (or we differ because there will be > no-usage). The interface is already there, so a future Xen release can > decide to give access to the guest when (and only when) this will be useful. > Hi Julien, as I said our use-case is purely external so I don't have an actual use-case for anything being accessible from within the guest. However, I could imagine the gfn remapping be used to protect kernel memory areas against information disclosure by only switching to the accessible mapping when certain conditions are met. Also, I had been able to use mem_access from domUs with the use of XSM so I believe it would be possible for a domain to enable mem_access on itself that way and thus not having to implement #VE exactly the way x86 does and still have feature parity. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] monitor access to pages with a specific p2m_type_t
On Tue, Aug 2, 2016 at 12:19 AM, sepanta swrote: > > > On Sat, Jul 23, 2016 at 3:49 PM, sepanta s wrote: > >> Hi, Is there any sample code which I can undestand how to capture the events on the gfns which have p2m_ram_shared enabled ? I couldn't find any ... . I would be grateful if any help , as there is not any documents through net to use :( >>> Should I just set the ring_page as the pages which are shared and mark them read-only, then capture the write events? >>> >>> Not sure what ring_page you are talking about, but if you mark the pages >>> read-only with mem_access you will get notifications for events that lead >>> to unsharing with p2m_ram_shared type pages as well. >>> >> >> There was a function in mem-sharing.c which is intended to announce the >> failed unshared pages. It is "mem_sharing_notify_enomem" . >> I added "mem_sharing_notify_unshare" as a new function and call it in >> also XEN_DOMCTL_VM_EVENT_OP_UNSHARING and "HVM_PARAM_USHARING_RING_PFN". >> I also added the required codes in /xen/common/vm_event.c and >> /tools/libxc/xc_vm_event so as >> I have added a new event for the unsharing actions of a page. >> Then, I wrote a sample code line xen-access and create a ring for the >> pages of a domain and listen to unshared events of it. >> >>> BTW, I added a function called mem_sharing_notify_unshare to mem_sharing.c and added it to __mem_sharing_unshare_page at this part: *if ( p2m_change_type_one(d, gfn, p2m_ram_shared, p2m_ram_rw) )* *{* *gdprintk(XENLOG_ERR, "Could not change p2m type d %hu gfn %lx.\n", * *d->domain_id, gfn);* *BUG();* *}else {* * mem_sharing_notify_unshare(d,gfn.0);* *}* >>> IMHO this duplicates a lot of what mem_access does already, I don't >>> think there is a need for a separate notification on another ring. >>> >>> >> You are right, xen-access should work but I couldn't change its code and >> couldn't get the mem-access events. >> I just added the above function to be sure that unsharing a page happens >> and works fine. Because I couldn't get the access requests on shared-pages >> of a vm. >> In xen-access, Instead of setting all the pages' default access to rx , I >> just call xc_set_mem_access for the pages with p2m_ram_shared and assign rx >> as the default access but there is no requests on this ring. >> >>> >> >> So by having a vm event channel listening to unsharing event, I can see the notification in xen-access . To do so, I have used vm_event_enable which uses HVM_PARAM_SHARING_RING_PFN . But, when I used memshrtool to share all the pages of two vms - my vm1 and its clone vm2 . About 900 MB of the ram is shared but there are a lot of unshared events happening. >>> >>> Yes, I would say that's expected. >>> >> >>> When I do the sharing one more time, there is not any pages unshared as the total number of shared pages stay the same. >>> >>> Well, if you let the domain run for a while after sharing, then you do >>> the sharing like that again you are likely going to crash the VM. >>> >>> Seems no unsharing is done as the number of shared pages are the same. Does any page fault triggers when a write operation is done on a shared page among two vms ? >>> >>> I would guess the the VM crashed and that's why you don't see any more >>> unsharing at that point. >>> >> Yes it was crashed as I checked it. >> The scenario of sharing is I use: >> I pause the origin VM and then run memshrtool on origin VM and clone VM. >> After sharing all the pages between these two VMs,Clone VM seems to be >> inaccessible. The clone seems to work as the attached photo shows, its cpu >> time increases and it exceeds the dom0 cpu time but when I use gvncviewer >> to see the GUI of the Clone VM, the mouse or keyboard don't work. (origin >> VM is ubunut-64-1 and clone VM is ubuntu-64-clone-1). Is there anything I >> have missed in sharing between two VMs? >> >> [image: Inline image 2] >> > > Can someone help please ? still have problem with the machine . > is it because sharing is not based on content? > > Well, the emulated device contexts probably get all messed up when you just clone over the memory of the domain and that's why they don't work. The only way I got this to work is by doing a save/restore of the origin domain before doing the memory sharing. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation
On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote: > On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote: > > On 29/07/16 17:28, Roger Pau Monne wrote: > > > diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c > > > index 107fc8c..1b270df 100644 > > > --- a/xen/arch/x86/mm/paging.c > > > +++ b/xen/arch/x86/mm/paging.c > > > @@ -953,6 +953,22 @@ void paging_write_p2m_entry(struct p2m_domain *p2m, > > > unsigned long gfn, > > > safe_write_pte(p, new); > > > } > > > > > > +int paging_set_allocation(struct domain *d, unsigned long pages) > > > +{ > > > +int rc; > > > + > > > +ASSERT(paging_mode_enabled(d)); > > > + > > > +paging_lock(d); > > > +if ( hap_enabled(d) ) > > > +rc = hap_set_allocation(d, pages, NULL); > > > +else > > > +rc = sh_set_allocation(d, pages, NULL); > > > > (without looking at the rest of the series) Your NMI is probably a > > watchdog timeout from this call, as passing NULL means "non-preemptible". > > I don't think so, the NMI I saw happened while the guest was booting. > > > As this is for the construction of dom0, it would be better to take a > > preemptible pointer, loop in construct_dom0(), with a > > process_pending_softirqs() call in between. > > Now fixed. Hm, I have to stand corrected, using hypercall_preempt_check (as any of the *_set_allocation function use), is not safe at this point: (XEN) [ Xen-4.8-unstable x86_64 debug=y Tainted:C ] (XEN) CPU:0 (XEN) RIP:e008:[] hap.c#local_events_need_delivery+0x27/0x40 (XEN) RFLAGS: 00010246 CONTEXT: hypervisor (XEN) rax: rbx: 83023f5a5000 rcx: 82d080312900 (XEN) rdx: 0001 rsi: 83023f5a56c8 rdi: 8300b213d000 (XEN) rbp: 82d080307cc8 rsp: 82d080307cc8 r8: 0180 (XEN) r9: r10: 00247000 r11: 82d08029a5b0 (XEN) r12: 0011 r13: 23ac r14: 82d080307d4c (XEN) r15: 83023f5a56c8 cr0: 8005003b cr4: 001526e0 (XEN) cr3: b20fc000 cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen code around (hap.c#local_events_need_delivery+0x27/0x40): (XEN) 0d ad fa ff 48 8b 47 08 <80> 38 00 74 09 80 78 01 00 0f 94 c0 eb 02 31 c0 (XEN) Xen stack trace from rsp=82d080307cc8: (XEN)82d080307d08 82d08022fc47 83023f5a5000 (XEN)83023f5a5648 82d080307d4c 2400 (XEN)82d080307d38 82d08020008c 000d 8300b1efd000 (XEN)83023f5a5000 82d080307d4c 82d080307d78 82d0802cad30 (XEN)00203000 83023f5a5000 82d0802bf860 (XEN)0001 8308bef0 82d080307de8 82d0802c91e0 (XEN)82d080307de8 82d080143900 82d080307de8 (XEN)8308bf00 82d0802eb480 82d080307dc4 82d08028b1cd (XEN)8308bf00 0001 83023f5a5000 (XEN)82d080307f08 82d0802bf0c9 (XEN) 82d080307f18 8308bee0 0001 (XEN)0001 0001 0010 (XEN)0001 00247000 8308bef4 0010 (XEN)8301 00247001 0014 0001 (XEN)8300ffec 8308bef0 82d0802e0640 8308bfb0 (XEN) 0111 0008 (XEN)0001006e 0003 02f8 (XEN)ad5c0bd0 0001 0008 (XEN) 82d080100073 (XEN) (XEN) Xen call trace: (XEN)[] hap.c#local_events_need_delivery+0x27/0x40 (XEN)[] hap_set_allocation+0x107/0x130 (XEN)[] paging_set_allocation+0x4c/0x80 (XEN)[] domain_build.c#hvm_setup_p2m+0x70/0x1a0 (XEN)[] domain_build.c#construct_dom0_hvm+0x60/0x120 (XEN)[] __start_xen+0x1ea9/0x23a0 (XEN)[] __high_start+0x53/0x60 (XEN) (XEN) Pagetable walk from : (XEN) L4[0x000] = 000245233063 (XEN) L3[0x000] = 000245232063 (XEN) L2[0x000] = 000245231063 (XEN) L1[0x000] = (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) FATAL PAGE FAULT (XEN) [error_code=] (XEN) Faulting linear address: (XEN) I've tried setting current to d->vcpu[0], but that just makes the call to hypercall_preempt_check crash in some scheduler assert. In any case, I've added the preempt parameter to the paging_set_allocation function, but
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On Tue, Aug 2, 2016 at 5:17 AM, George Dunlapwrote: > On 02/08/16 08:38, Julien Grall wrote: >> Hello Tamas, >> >> On 01/08/2016 21:41, Tamas K Lengyel wrote: >>> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall >>> wrote: > we did discuss whether altp2m on ARM should be exposed to guests or > not but we did not agree whether restricting it on ARM is absolutely > necessary. Altp2m was designed even on the x86 to be accessible from > within the guest on all systems irrespective of actual hardware > support for it. Thus, this design fits ARM as well where there is no > dedicated hardware support, from the altp2m perspective there is no > difference. Really? I looked at the design document [1] which is Intel focus. Similar think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c). >>> >>> That design cover letter mentions specifically "Both VMFUNC and #VE >>> are designed such that a VMM can emulate them on legacy CPUs". While >>> they certainly had only Intel hardware in-mind, the software route can >>> also be taken on ARM as well. As our primary use-case is purely >>> external use of altp2m we have not implemented the bits that enable >>> the injection of mem_access faults into the guest (equivalent of #VE). >>> Whether without that the altp2m switching from within the guest make >>> sense or not is beyond the scope of this series but as it could >>> technically be implemented in the future, I don't see a reason to >>> disable that possibility right away. >> >> The question here, is how a guest could take advantage to access to >> altp2m on ARM today? Whilst on x86 a guest could be notified about >> memaccess change, this is not yet the case on ARM. >> >> So, from my understanding, exposing this feature to a guest is like >> exposing a no-op with side effects. We should avoid to expose feature to >> the guest until there is a real usage and the guest could do something >> useful with it. > > It seems like having guest altp2m support without the equivalent of a > #VE does seem pretty useless. Would you disagree with this assessment, > Tamas? > > Every interface we expose to the guest increases the surface of attack; > so it seems like until there is a usecase for guest altp2m, we should > probably disable it. > Hi George, I disagree. On x86 using VMFUNC EPTP switching is not bound to #VE in any way. The two can certainly benefit from being used together but there is no enforced interdependence between the two. It is certainly possible to derive a use-case for just having the altp2m switch operations available to the guest. For example, I could imagine the gfn remapping be used to protect kernel memory areas against information disclosure by only switching to the accessible mapping when certain conditions are met. As our usecase is purely external implementing the emulated #VE at this time has been deemed out-of-scope but it could be certainly implemented for ARM as well. Now that I'm thinking about it it might actually not be necessary to implement the #VE at all the way x86 does by injecting an interrupt as we might just be able to allow the domain to enable the existing mem_access ring directly. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] What distros have Xen 4.7 packages that work on UEFI hardware?
> The level of support you get is somewhat proportional to the amount of money > you spend. I shared that comment here, and the immediate follow-on response was: "Great. Money's not the problem. Which commercial entity provides a supported solution?" We're happy to consider Oracle, Redhat, Ubuntu or XenServer for commercial distros. Debian too, if there's commercial support. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] xen: drain submit queue in xen-usb before removing device
On Tue, Aug 02, 2016 at 02:14:04PM +0200, Juergen Gross wrote: > When unplugging a device in the Xen pvusb backend drain the submit > queue before deallocation of the control structures. Otherwise there > will be bogus memory accesses when I/O contracts are finished. > > Correlated to this issue is the handling of cancel requests: a packet > cancelled will still lead to the call of complete, so add a flag > to the request indicating it should be just dropped on complete. > > Signed-off-by: Juergen GrossAcked-by: Anthony PERARD -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request
On Aug 2, 2016 06:45, "Jan Beulich"wrote: > > >>> On 01.08.16 at 18:52, wrote: > > --- a/xen/arch/x86/hvm/hvm.c > > +++ b/xen/arch/x86/hvm/hvm.c > > @@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla, > > int rc, fall_through = 0, paged = 0; > > int sharing_enomem = 0; > > vm_event_request_t *req_ptr = NULL; > > -bool_t ap2m_active; > > +bool_t ap2m_active, sync = 0; > > > > /* On Nested Virtualization, walk the guest page table. > > * If this succeeds, all is fine. > > @@ -1846,11 +1846,12 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla, > > } > > } > > > > -if ( p2m_mem_access_check(gpa, gla, npfec, _ptr) ) > > -{ > > +sync = p2m_mem_access_check(gpa, gla, npfec, _ptr); > > + > > +if ( !sync ) { > > Coding style. If you dropped the brace entirely, you could at once > adjust ... > > > fall_through = 1; > > } else { > > ... coding style here. > > > -/* Rights not promoted, vcpu paused, work here is done */ > > +/* Rights not promoted (aka. sync event), work here is done */ > > Comment style. More of these elsewhere. > > > +int hvm_monitor_mem_access(struct vcpu* v, bool_t sync, > > Coding style. > > > + vm_event_request_t *req) > > +{ > > +return monitor_traps(v, sync, req); > > +} > > Overall - is this a useful wrapper? Why can't the caller(s) call > monitor_traps() directly? And if you really want to keep it, it would > probably better be an inline one. > The reason for this wrapper is to avoid having to include the common monitor header here. I can move it into the hvm monitor header as inline, that's no problem. Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9] x86/mem-sharing: mem-sharing a range of memory
On Aug 2, 2016 06:17, "Wei Liu"wrote: > > On Mon, Aug 01, 2016 at 11:14:27AM -0600, Tamas K Lengyel wrote: > > Currently mem-sharing can be performed on a page-by-page basis from the control > > domain. However, this process is quite wasteful when a range of pages have to > > be deduplicated. > > > > This patch introduces a new mem_sharing memop for range sharing where > > the user doesn't have to separately nominate each page in both the source and > > destination domain, and the looping over all pages happen in the hypervisor. > > This significantly reduces the overhead of sharing a range of memory. > > > > Signed-off-by: Tamas K Lengyel > > Acked-by: Wei Liu > > Reviewed-by: Andrew Cooper > > I notice this patch has got sufficient acks. > > I will queue this up. Thanks! Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Discussion about virtual iommu support for Xen guest
On 5/27/2016 4:19 PM, Lan Tianyu wrote: > As for the individual issue of 288vcpu support, there are already issues > with 64vcpu guests at the moment. While it is certainly fine to remove > the hard limit at 255 vcpus, there is a lot of other work required to > even get 128vcpu guests stable. Could you give some points to these issues? We are enabling more vcpus support and it can boot up 255 vcpus without IR support basically. It's very helpful to learn about known issues. Hi Andrew: We are designing vIOMMU support for Xen. Increasing vcpu from 128 to 255 also can be implemented parallelly since it doesn't need vIOMMU support. From your previous comment "there is a lot of other work required to even get 128vcpu guests stable", you have some concerns about stability of 128vcpus. I wonder what we need to do before starting work of increasing vcpu number from 128 to 255? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h
>>> On 02.08.16 at 16:59,wrote: > On 02/08/16 15:54, Jan Beulich wrote: > On 02.08.16 at 16:26, wrote: >>> On 02/08/16 15:17, Jan Beulich wrote: Well, I find it quite odd for hypercall argument counts to differ between arches. I.e. I'd conclude the ABI was mis-specified. >>> Is it documented somewhere for the x86 code? Looking at Linux, the >>> privcmd call is only passing 5 arguments on both ARM and x86. >> arch-x86/xen-x86_32.h has >> >> * Hypercall interface: >> * Input: %ebx, %ecx, %edx, %esi, %edi, %ebp (arguments 1-6) >> * Output: %eax >> >> while arch-x86/xen-x86_64.h has >> >> * Hypercall interface: >> * Input: %rdi, %rsi, %rdx, %r10, %r8, %r9 (arguments 1-6) >> * Output: %rax > > The only actual 6 argument hypercall is the v4v hypercall, better known > as __HYPERVISOR_xc_reserved_op at index 39, but that isn't implemented > anywhere upstream. But it serves as an example what now wouldn't work on ARM. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?
On Tue, Aug 2, 2016, at 07:50 AM, Jan Beulich wrote: > - one with some suitable variant of reboot= What exactly is "some suitable variant of reboot" ? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 99897: tolerable FAIL - PUSHED
flight 99897 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/99897/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 99891 build-i386-rumpuserxen6 xen-buildfail like 99891 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 99891 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 99891 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99891 test-amd64-amd64-xl-rtds 9 debian-install fail like 99891 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 99891 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-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 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 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass version targeted for testing: xen caefc852d5a3be3965a0c0131ce62e7f3a313f04 baseline version: xen 2d12afe43a5e52a7ac4d2d633caf657d0eb10dc1 Last test of basis99891 2016-08-01 18:44:40 Z0 days Testing same since99893 2016-08-02 01:13:18 Z0 days2 attempts People who touched revisions under test: Andrew CooperChao Gao Jan Beulich jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern
Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h
On 02/08/16 15:54, Jan Beulich wrote: On 02.08.16 at 16:26,wrote: >> On 02/08/16 15:17, Jan Beulich wrote: >> On 02.08.16 at 16:04, wrote: On 02/08/16 14:28, Jan Beulich wrote: On 02.08.16 at 15:14, wrote: >> On 02/08/16 13:50, Jan Beulich wrote: >> On 18.07.16 at 11:51, wrote: #include /* for do_mca */ -#include + +typedef unsigned long hypercall_fn_t( +unsigned long, unsigned long, unsigned long, +unsigned long, unsigned long, unsigned long); >>> Wouldn't this better go into xen/hypercall.h? >> It is architecture specific. >> >> ARM's version is >> >> typedef register_t (*arm_hypercall_fn_t)( >> register_t, register_t, register_t, register_t, register_t); > Which is bogus - they're lucky we so far don't have any 6-argument > hypercalls. Or the other way around - we could limit hypercalls to > just five arguments (for now) on x86 too, allowing things to get > unified. Anyway - that probably goes too far right now, so feel free > to add my ack to the patch. I am not sure why you think we are lucky on ARM. The hypercall has been defined on ARM to support up to 5 arguments (public/arch-arm.h): "A hypercall can take up to 5 arguments. These are passed in registers, the first argument in x0/r0 (for arm64/arm32 guests respectively irrespective of whether the underlying hypervisor is 32- or 64-bit), the second argument in x1/r1, the third in x2/r2, the forth in x3/r3 and the fifth in x4/r4." So the prototype matches the ABI. >>> Well, I find it quite odd for hypercall argument counts to differ >>> between arches. I.e. I'd conclude the ABI was mis-specified. >> Is it documented somewhere for the x86 code? Looking at Linux, the >> privcmd call is only passing 5 arguments on both ARM and x86. > arch-x86/xen-x86_32.h has > > * Hypercall interface: > * Input: %ebx, %ecx, %edx, %esi, %edi, %ebp (arguments 1-6) > * Output: %eax > > while arch-x86/xen-x86_64.h has > > * Hypercall interface: > * Input: %rdi, %rsi, %rdx, %r10, %r8, %r9 (arguments 1-6) > * Output: %rax The only actual 6 argument hypercall is the v4v hypercall, better known as __HYPERVISOR_xc_reserved_op at index 39, but that isn't implemented anywhere upstream. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h
>>> On 02.08.16 at 16:26,wrote: > > On 02/08/16 15:17, Jan Beulich wrote: > On 02.08.16 at 16:04, wrote: >>> On 02/08/16 14:28, Jan Beulich wrote: >>> On 02.08.16 at 15:14, wrote: > On 02/08/16 13:50, Jan Beulich wrote: > On 18.07.16 at 11:51, wrote: >>> #include /* for do_mca */ >>> -#include >>> + >>> +typedef unsigned long hypercall_fn_t( >>> +unsigned long, unsigned long, unsigned long, >>> +unsigned long, unsigned long, unsigned long); >> Wouldn't this better go into xen/hypercall.h? > > It is architecture specific. > > ARM's version is > > typedef register_t (*arm_hypercall_fn_t)( > register_t, register_t, register_t, register_t, register_t); Which is bogus - they're lucky we so far don't have any 6-argument hypercalls. Or the other way around - we could limit hypercalls to just five arguments (for now) on x86 too, allowing things to get unified. Anyway - that probably goes too far right now, so feel free to add my ack to the patch. >>> >>> I am not sure why you think we are lucky on ARM. The hypercall has been >>> defined on ARM to support up to 5 arguments (public/arch-arm.h): >>> >>> "A hypercall can take up to 5 arguments. These are passed in >>> registers, the first argument in x0/r0 (for arm64/arm32 guests >>> respectively irrespective of whether the underlying hypervisor is >>> 32- or 64-bit), the second argument in x1/r1, the third in x2/r2, >>> the forth in x3/r3 and the fifth in x4/r4." >>> >>> So the prototype matches the ABI. >> >> Well, I find it quite odd for hypercall argument counts to differ >> between arches. I.e. I'd conclude the ABI was mis-specified. > > Is it documented somewhere for the x86 code? Looking at Linux, the > privcmd call is only passing 5 arguments on both ARM and x86. arch-x86/xen-x86_32.h has * Hypercall interface: * Input: %ebx, %ecx, %edx, %esi, %edi, %ebp (arguments 1-6) * Output: %eax while arch-x86/xen-x86_64.h has * Hypercall interface: * Input: %rdi, %rsi, %rdx, %r10, %r8, %r9 (arguments 1-6) * Output: %rax Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?
>>> On 02.08.16 at 16:25,wrote: > On Tue, Aug 2, 2016, at 07:13 AM, Jan Beulich wrote: >> Unless /mapbs really produces an _exactly_ identical crash, I'd like to >> see that boot's output at maximum log level. I don't recall "efi=no-rs" >> having been mentioned before on this thread, but yes, I'd expect >> that one to help as much as the suggested "reboot=..." option, so >> if either doesn't, logs thereof would also be of interest. > > You criticize MY vagueness then do this. There's nothing vague in my above reply afaict: > Identical crash to WHAT? I do recall only a single full log that you had provided so far, so that's the baseline to me. > WHICH boot's output? I've named them: - one with /mapbs - one with efi=no-rs - one with some suitable variant of reboot= > WHAT do you consider maximum > log level -- DIFFERENT than what I've already provided? "maximum log level" == "loglvl=all guest_loglvl=all"; I don't think there's any other interpretation. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC Design Doc v2] Add vNVDIMM support for Xen
>>> On 18.07.16 at 02:29,wrote: > 4.2.2 Detection of Host pmem Devices > > The detection and initialize host pmem devices require a non-trivial > driver to interact with the corresponding ACPI namespace devices, > parse namespace labels and make necessary recovery actions. Instead > of duplicating the comprehensive Linux pmem driver in Xen hypervisor, > our designs leaves it to Dom0 Linux and let Dom0 Linux report > detected host pmem devices to Xen hypervisor. > > Our design takes following steps to detect host pmem devices when Xen > boots. > (1) As booting on bare metal, host pmem devices are detected by Dom0 > Linux NVDIMM driver. > > (2) Our design extends Linux NVDIMM driver to reports SPA's and sizes > of the pmem devices and reserved areas to Xen hypervisor via a > new hypercall. > > (3) Xen hypervisor then checks > - whether SPA and size of the newly reported pmem device is overlap >with any previously reported pmem devices; ... or with system RAM. > - whether the reserved area can fit in the pmem device and is >large enough to hold page_info structs for itself. So "reserved" here means available for Xen's use, but not for more general purposes? How would the area Linux uses for its own purposes get represented? > (4) Because the reserved area is now used by Xen hypervisor, it > should not be accessible by Dom0 any more. Therefore, if a host > pmem device is recorded by Xen hypervisor, Xen will unmap its > reserved area from Dom0. Our design also needs to extend Linux > NVDIMM driver to "balloon out" the reserved area after it > successfully reports a pmem device to Xen hypervisor. ... "balloon out" ... _after_? That'd be unsafe. > 4.2.3 Get Host Machine Address (SPA) of Host pmem Files > > Before a pmem file is assigned to a domain, we need to know the host > SPA ranges that are allocated to this file. We do this work in xl. > > If a pmem device /dev/pmem0 is given, xl will read > /sys/block/pmem0/device/{resource,size} respectively for the start > SPA and size of the pmem device. > > If a pre-allocated file /mnt/dax/file is given, > (1) xl first finds the host pmem device where /mnt/dax/file is. Then > it uses the method above to get the start SPA of the host pmem > device. > (2) xl then uses fiemap ioctl to get the extend mappings of > /mnt/dax/file, and adds the corresponding physical offsets and > lengths in each mapping entries to above start SPA to get the SPA > ranges pre-allocated for this file. Remind me again: These extents never change, not even across reboot? I think this would be good to be written down here explicitly. Hadn't there been talk of using labels to be able to allow a guest to own the exact same physical range again after reboot or guest or host? > 3) When hvmloader loads a type 0 entry, it extracts the signature > from the data blob and search for it in builtin_table_sigs[]. If > found anyone, hvmloader will report an error and stop. Otherwise, > it will append it to the end of loaded guest ACPI. Duplicate table names aren't generally collisions: There can, for example, be many tables named "SSDT". > 4) When hvmloader loads a type 1 entry, it extracts the device name > from the data blob and search for it in builtin_nd_names[]. If > found anyone, hvmloader will report and error and stop. Otherwise, > it will wrap the AML code snippet by "Device (name[4]) {...}" and > include it in a new SSDT which is then appended to the end of > loaded guest ACPI. But all of these could go into a single SSDT, instead of (as it sounds) each into its own one? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] live migrating hvm from 4.4 to 4.5 fails due to kvmvapic
As a followup to the issue below, and the one which "just" popped in in qemu-2.6+: Why is the machine description for xen not fixed? Shouldnt the be some sort of verification of old and new 'xenfv' when a new qemu rc1 is done? Is there a way to dump the machine description in text form? Olaf On Fri, May 13, Stefano Stabellini wrote: > On Thu, 12 May 2016, Olaf Hering wrote: > > On Thu, May 12, Olaf Hering wrote: > > > > > One thing to fix it in staging-4.5 is to introduce a dummy device which > > > handles a section named "kvm-tpr-opt". I already have a hack which does > > > that, and the migration proceeds. I will propose a patch to deal with > > > this part of the bug. > > > > Something like shown below. > > Thanks for looking into this. I don't think that adding a dummy device > in QEMU is acceptable. This kind of problems is usually solved with > versioning the PC machine in QEMU, see all the pc_machine_* in > hw/i386/pc_piix.c. One specific version of the machine is supposed to > remain identical over multiple QEMU releases. In this case xenfv (or the > pc machine you are using, if you are not using xenfv) has to be always > identical. That's why I think we need to add kvmapic back to it for > compatibility. I know it sucks. But we can choose a different PC machine > with accel=xen for new VMs. signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/PCI: Update ACPI Check to include SGI Ux3
From: rootThese systems use variations of SGI3* for ID string. Instead of adding abother set of strings do what Linux did in commit 526018bc and look at first three letters. Signed-off-by: Boris Ostrovsky --- xen/arch/x86/x86_64/acpi_mmcfg.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xen/arch/x86/x86_64/acpi_mmcfg.c b/xen/arch/x86/x86_64/acpi_mmcfg.c index f01ad70..3ce85c9 100644 --- a/xen/arch/x86/x86_64/acpi_mmcfg.c +++ b/xen/arch/x86/x86_64/acpi_mmcfg.c @@ -55,8 +55,7 @@ static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg, if (cfg->address < 0x) return 0; -if (!strcmp(mcfg->header.oem_id, "SGI") || -!strcmp(mcfg->header.oem_id, "SGI2")) +if (!strncmp(mcfg->header.oem_id, "SGI", 3)) return 0; if (mcfg->header.revision >= 1 && -- 1.8.3.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h
On 02/08/16 15:17, Jan Beulich wrote: On 02.08.16 at 16:04,wrote: On 02/08/16 14:28, Jan Beulich wrote: On 02.08.16 at 15:14, wrote: On 02/08/16 13:50, Jan Beulich wrote: On 18.07.16 at 11:51, wrote: --- a/xen/include/asm-x86/hypercall.h +++ b/xen/include/asm-x86/hypercall.h @@ -5,9 +5,21 @@ #ifndef __ASM_X86_HYPERCALL_H__ #define __ASM_X86_HYPERCALL_H__ +#include #include +#include Why? You snipped the commit message, which justifies why. This header file cannot currently be included in isolation, and I need it to be. Ah, that sentence there also relates to this addition. #include /* for do_mca */ -#include + +typedef unsigned long hypercall_fn_t( +unsigned long, unsigned long, unsigned long, +unsigned long, unsigned long, unsigned long); Wouldn't this better go into xen/hypercall.h? It is architecture specific. ARM's version is typedef register_t (*arm_hypercall_fn_t)( register_t, register_t, register_t, register_t, register_t); Which is bogus - they're lucky we so far don't have any 6-argument hypercalls. Or the other way around - we could limit hypercalls to just five arguments (for now) on x86 too, allowing things to get unified. Anyway - that probably goes too far right now, so feel free to add my ack to the patch. I am not sure why you think we are lucky on ARM. The hypercall has been defined on ARM to support up to 5 arguments (public/arch-arm.h): "A hypercall can take up to 5 arguments. These are passed in registers, the first argument in x0/r0 (for arm64/arm32 guests respectively irrespective of whether the underlying hypervisor is 32- or 64-bit), the second argument in x1/r1, the third in x2/r2, the forth in x3/r3 and the fifth in x4/r4." So the prototype matches the ABI. Well, I find it quite odd for hypercall argument counts to differ between arches. I.e. I'd conclude the ABI was mis-specified. Is it documented somewhere for the x86 code? Looking at Linux, the privcmd call is only passing 5 arguments on both ARM and x86. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?
On Tue, Aug 2, 2016, at 07:13 AM, Jan Beulich wrote: > > You keep stating what you don't see. > > Because you keep being vague... I have attempted to provide everything that's been asked of me. If you don't like it that's fine. State with specificity what it is you want. > Unless /mapbs really produces an _exactly_ identical crash, I'd like to > see that boot's output at maximum log level. I don't recall "efi=no-rs" > having been mentioned before on this thread, but yes, I'd expect > that one to help as much as the suggested "reboot=..." option, so > if either doesn't, logs thereof would also be of interest. You criticize MY vagueness then do this. Identical crash to WHAT? WHICH boot's output? WHAT do you consider maximum log level -- DIFFERENT than what I've already provided? I am not a good mind reader, interpreter, guesser. Just like I said I would, if & when you or someone else who cares to provides clear unequivocal set of options / cases that you want tested I will provide them. Or do you really want a fishing expedition with every possible combination of every option? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/kconfig: unify messages of options moved from command line to kconfig
>>> On 02.08.16 at 15:58,wrote: > On Mon, Aug 01, 2016 at 09:21:28AM -0600, Jan Beulich wrote: >> >>> On 26.07.16 at 17:45, wrote: >> > Change the message so that it mentions running from the top level directory >> > and using '-C xen' in order to call the 'menuconfig' target inside of the >> > xen directory (there's no top-level menuconfig target). >> >> Well, I'm not convinced whether this end up clarifying or confusing >> things, as that partly depends on how you normally invoke make (or >> the various makes of the sub-trees individually). > > Hm, and what about adding a top-level menuconfig target, does that sound any > better? Well, suitable named, that might be an option. "menuconfig" won't do well, since that's only relevant to the xen/ subtree. Something like "xen-config" maybe? Doug, any thoughts? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/9] x86/pv: Implement pv_hypercall() in C
>>> On 02.08.16 at 16:06,wrote: > On 02/08/16 14:12, Jan Beulich wrote: > On 18.07.16 at 11:51, wrote: >>> +long pv_hypercall(struct cpu_user_regs *regs) >>> +{ >>> +struct vcpu *curr = current; >>> +#ifndef NDEBUG >>> +unsigned long old_rip = regs->rip; >>> +#endif >>> +long ret; >>> +uint32_t eax = regs->eax; >>> + >>> +ASSERT(curr->arch.flags & TF_kernel_mode); >> I'm afraid TF_kernel_mode can't be relied on for 32-bit guests, so >> this needs to move into the if() below. > > In which case it should become ASSERT(guest_mode_kernel(curr, regs)) Ah, yes. >>> +if ( (eax >= NR_hypercalls) || !hypercall_table[eax] ) >>> + return -ENOSYS; >>> + >>> +if ( !is_pv_32bit_vcpu(curr) ) >>> +{ >>> +unsigned long rdi = regs->rdi; >>> +unsigned long rsi = regs->rsi; >>> +unsigned long rdx = regs->rdx; >>> +unsigned long r10 = regs->r10; >>> +unsigned long r8 = regs->r8; >>> +unsigned long r9 = regs->r9; >>> + >>> +#ifndef NDEBUG >>> +/* Deliberately corrupt parameter regs not used by this hypercall. >>> */ >>> +switch ( hypercall_args_table[eax] ) >>> +{ >>> +case 0: rdi = 0xdeadbeefdeadf00dUL; >>> +case 1: rsi = 0xdeadbeefdeadf00dUL; >>> +case 2: rdx = 0xdeadbeefdeadf00dUL; >>> +case 3: r10 = 0xdeadbeefdeadf00dUL; >>> +case 4: r8 = 0xdeadbeefdeadf00dUL; >>> +case 5: r9 = 0xdeadbeefdeadf00dUL; >> Without comments, aren't these going to become 5 new Coverity >> issues? > > There are no current warnings from the HVM side, so I doubt it. > Coverities' logic is rather complicated, but in this case I think the > lack of any break statements at all is a sufficient hint that its fine. Okay. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] xen: Make VPMU init message look less scary
On 08/02/2016 03:22 AM, Juergen Gross wrote: The default for the Xen hypervisor is to not enable VPMU in order to avoid security issues. In this case the Linux kernel will issue the message "Could not initialize VPMU for cpu 0, error -95" which looks more like an error than a normal state. Change the message to something less scary in case the hypervisor returns EOPNOTSUPP or ENOSYS when trying to activate VPMU. Signed-off-by: Juergen GrossReviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/4] tools: split out xenstored starting form xencommons
On Tue, Aug 02, 2016 at 02:48:54PM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [PATCH v4 2/4] tools: split out xenstored starting form > xencommons"): > > On Tue, Aug 02, 2016 at 01:20:40PM +0200, Juergen Gross wrote: > > > Still confused? > > > > Ah, the 2> vs &> thing is really subtle. I missed that, sorry. > > `&>' is a (bash-specific, I think) syntax for redirection, not a > request to run anything in the background. > I skimmed too fast and read that as "& >". :-/ > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?
>>> On 02.08.16 at 15:54,wrote: > > On Tue, Aug 2, 2016, at 06:38 AM, Jan Beulich wrote: >> Well, without going through the _full_ thread again, what I could >> easily find is >> >> "So full console output from boot -> crash now doesn't look any different >> than > >> >> https://lists.xen.org/archives/html/xen-devel/2016-07/msg02814.html >> " >> >> which doesn't tell me at all which combination of /mapbs and/or >> /noexitboot was used. Certainly in that run "efi=attr=uc" wasn't >> used. It in particular seems highly questionable to me that the >> reboot crash would look _exactly_ the same with /mapbs. > > You keep stating what you don't see. Because you keep being vague... > Afaict, there are four options that seem to have been talked about > > /mapbs & /noexitboot on the EFI cmd line > > and > > efi=attr=uc and ef=no-rs on the xen cmd line > > I really don't want to keep guessing and reposting unnecessary information, > and am TRYING to provide the right information. > > Can you simply say what output you want? What combination of options of efi > cmd line, xen cmd line, and log options? > > I will provide THAT. Unless /mapbs really produces an _exactly_ identical crash, I'd like to see that boot's output at maximum log level. I don't recall "efi=no-rs" having been mentioned before on this thread, but yes, I'd expect that one to help as much as the suggested "reboot=..." option, so if either doesn't, logs thereof would also be of interest. Jan Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: rename xen_pmu_init() in sys-hypervisor.c
On 08/02/2016 02:53 AM, Juergen Gross wrote: There are two functions with name xen_pmu_init() in the kernel. Rename the one in drivers/xen/sys-hypervisor.c to avoid shadowing the one in arch/x86/xen/pmu.c To avoid the same problem in future rename some more functions. Signed-off-by: Juergen GrossReviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 23/25] arm/altp2m: Extend libxl to activate altp2m on ARM.
Hi Wei, On 08/02/2016 01:59 PM, Wei Liu wrote: > On Mon, Aug 01, 2016 at 07:10:26PM +0200, Sergej Proskurin wrote: >> The current implementation allows to set the parameter HVM_PARAM_ALTP2M. >> This parameter allows further usage of altp2m on ARM. For this, we >> define an additional, common altp2m field as part of the >> libxl_domain_type struct. This field can be set on x86 and on ARM systems >> through the "altp2m" switch in the domain's configuration file (i.e. >> set altp2m=1). >> >> Note, that the old parameter "altp2mhvm" is still valid for x86. Since >> this commit defines this old parameter as deprecated, libxl will >> generate a warning during processing. >> >> Signed-off-by: Sergej Proskurin>> --- >> Cc: Ian Jackson >> Cc: Wei Liu >> --- >> v2: The macro LIBXL_HAVE_ALTP2M is now valid for x86 and ARM. >> >> Moved the field altp2m out of info->u.pv.altp2m into the common >> field info->altp2m, where it can be accessed independent by the >> underlying architecture (x86 or ARM). Now, altp2m can be activated >> by the guest control parameter "altp2m". >> >> Adopted initialization routines accordingly. >> --- >> tools/libxl/libxl.h | 3 ++- >> tools/libxl/libxl_create.c | 8 +--- >> tools/libxl/libxl_dom.c | 4 ++-- >> tools/libxl/libxl_types.idl | 4 +++- >> tools/libxl/xl_cmdimpl.c| 26 +- >> 5 files changed, 37 insertions(+), 8 deletions(-) >> >> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h >> index 48a43ce..a2cbd34 100644 >> --- a/tools/libxl/libxl.h >> +++ b/tools/libxl/libxl.h >> @@ -839,7 +839,8 @@ typedef struct libxl__ctx libxl_ctx; >> >> /* >> * LIBXL_HAVE_ALTP2M >> - * If this is defined, then libxl supports alternate p2m functionality. >> + * If this is defined, then libxl supports alternate p2m functionality for >> + * x86 HVM and ARM PV guests. >> */ >> #define LIBXL_HAVE_ALTP2M 1 > Either you misunderstood or I said something wrong. > > These macros have defined semantics that shouldn't be changed because > application code uses them to detect the presence / absence of certain > things. > > We need a new macro for ARM altp2m. I think > >LIBXL_HAVE_ARM_ALTP2M > > would do. Sorry, this is entirely my fault. Although I have explicitly asked whether we need two different LIBXL_HAVE_* macros, I somehow omitted that one. I will fix that right now and provide two LIBXL_HAVE_* macros in the next patch. >> >> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c >> index d7db9e9..16d3b52 100644 >> --- a/tools/libxl/libxl_create.c >> +++ b/tools/libxl/libxl_create.c >> @@ -319,7 +319,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc, >> libxl_defbool_setdefault(_info->u.hvm.hpet, true); >> libxl_defbool_setdefault(_info->u.hvm.vpt_align, true); >> libxl_defbool_setdefault(_info->u.hvm.nested_hvm, false); >> -libxl_defbool_setdefault(_info->u.hvm.altp2m, false); >> libxl_defbool_setdefault(_info->u.hvm.usb,false); >> libxl_defbool_setdefault(_info->u.hvm.xen_platform_pci, true); >> >> @@ -406,6 +405,9 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc, >> libxl_domain_type_to_string(b_info->type)); >> return ERROR_INVAL; >> } >> + >> +libxl_defbool_setdefault(_info->altp2m, false); >> + >> return 0; >> } >> >> @@ -901,8 +903,8 @@ static void initiate_domain_create(libxl__egc *egc, >> >> if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM && >> (libxl_defbool_val(d_config->b_info.u.hvm.nested_hvm) && >> - libxl_defbool_val(d_config->b_info.u.hvm.altp2m))) { >> -LOG(ERROR, "nestedhvm and altp2mhvm cannot be used together"); >> + libxl_defbool_val(d_config->b_info.altp2m))) { >> +LOG(ERROR, "nestedhvm and altp2m cannot be used together"); >> goto error_out; >> } >> >> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c >> index ec29060..1550ef8 100644 >> --- a/tools/libxl/libxl_dom.c >> +++ b/tools/libxl/libxl_dom.c >> @@ -291,8 +291,6 @@ static void hvm_set_conf_params(xc_interface *handle, >> uint32_t domid, >> libxl_defbool_val(info->u.hvm.vpt_align)); >> xc_hvm_param_set(handle, domid, HVM_PARAM_NESTEDHVM, >> libxl_defbool_val(info->u.hvm.nested_hvm)); >> -xc_hvm_param_set(handle, domid, HVM_PARAM_ALTP2M, >> -libxl_defbool_val(info->u.hvm.altp2m)); >> } >> >> int libxl__build_pre(libxl__gc *gc, uint32_t domid, >> @@ -434,6 +432,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid, >> #endif >> } >> >> +xc_hvm_param_set(ctx->xch, domid, HVM_PARAM_ALTP2M, >> libxl_defbool_val(info->altp2m)); >> + > And the reason for moving this call to this function is? Since this implementation
[Xen-devel] [PATCH v4 2/2] qdisk - hw/block/xen_disk: grant copy implementation
Copy data operated on during request from/to local buffers to/from the grant references. Before grant copy operation local buffers must be allocated what is done by calling ioreq_init_copy_buffers. For the 'read' operation, first, the qemu device invokes the read operation on local buffers and on the completion grant copy is called and buffers are freed. For the 'write' operation grant copy is performed before invoking write by qemu device. A new value 'feature_grant_copy' is added to recognize when the grant copy operation is supported by a guest. Signed-off-by: Paulina Szubarczyk--- Changes since v3: - qemu_memalign/qemu_free is used instead function allocating memory from xc. - removed the get_buffer function instead there is a direct call to qemu_memalign. - moved ioreq_copy for write operation to ioreq_runio_qemu_aio. - added struct xengnttab_grant_copy_segment_t and stub in xen_common.h for version of xen earlier then 480. - added checking for version 480 to configure. The test repeats all the operation that are required for version < 480 and checks if xengnttab_grant_copy() is implemented. * I did not change the way of testing if grant_copy operation is implemented. As far as I understand if the code from gnttab_unimp.c is used then the gnttab device is unavailable and the handler to gntdev would be invalid. But if the handler is valid then the ioctl should return operation unimplemented if the gntdev does not implement the operation. --- configure | 56 + hw/block/xen_disk.c | 142 ++-- include/hw/xen/xen_common.h | 25 3 files changed, 218 insertions(+), 5 deletions(-) diff --git a/configure b/configure index f57fcc6..b5bf7d4 100755 --- a/configure +++ b/configure @@ -1956,6 +1956,62 @@ EOF /* * If we have stable libs the we don't want the libxc compat * layers, regardless of what CFLAGS we may have been given. + * + * Also, check if xengnttab_grant_copy_segment_t is defined and + * grant copy operation is implemented. + */ +#undef XC_WANT_COMPAT_EVTCHN_API +#undef XC_WANT_COMPAT_GNTTAB_API +#undef XC_WANT_COMPAT_MAP_FOREIGN_API +#include +#include +#include +#include +#include +#include +#include +#if !defined(HVM_MAX_VCPUS) +# error HVM_MAX_VCPUS not defined +#endif +int main(void) { + xc_interface *xc = NULL; + xenforeignmemory_handle *xfmem; + xenevtchn_handle *xe; + xengnttab_handle *xg; + xen_domain_handle_t handle; + xengnttab_grant_copy_segment_t* seg = NULL; + + xs_daemon_open(); + + xc = xc_interface_open(0, 0, 0); + xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0); + xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0); + xc_hvm_inject_msi(xc, 0, 0xf000, 0x); + xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL); + xc_domain_create(xc, 0, handle, 0, NULL, NULL); + + xfmem = xenforeignmemory_open(0, 0); + xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0); + + xe = xenevtchn_open(0, 0); + xenevtchn_fd(xe); + + xg = xengnttab_open(0, 0); + xengnttab_map_grant_ref(xg, 0, 0, 0); + xengnttab_grant_copy(xg, 0, seg); + + return 0; +} +EOF + compile_prog "" "$xen_libs $xen_stable_libs" +then +xen_ctrl_version=480 +xen=yes + elif + cat > $TMPC page[i] = NULL; +} + +qemu_vfree(ioreq->pages); +} + +static int ioreq_init_copy_buffers(struct ioreq *ioreq) +{ +int i; + +if (ioreq->v.niov == 0) { +return 0; +} + +ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov * XC_PAGE_SIZE); +if (!ioreq->pages) { +return -1; +} + +for (i = 0; i < ioreq->v.niov; i++) { +ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE; +ioreq->v.iov[i].iov_base = ioreq->page[i]; +} + +return 0; +} + +static int ioreq_copy(struct ioreq *ioreq) +{ +xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev; +xengnttab_grant_copy_segment_t segs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; +int i, count = 0, r, rc; +int64_t file_blk = ioreq->blkdev->file_blk; + +if (ioreq->v.niov == 0) { +return 0; +} + +count = ioreq->v.niov; + +for (i = 0; i < count; i++) { + +if (ioreq->req.operation == BLKIF_OP_READ) { +segs[i].flags = GNTCOPY_dest_gref; +segs[i].dest.foreign.ref = ioreq->refs[i]; +segs[i].dest.foreign.domid = ioreq->domids[i]; +segs[i].dest.foreign.offset = ioreq->req.seg[i].first_sect * file_blk; +segs[i].source.virt = ioreq->v.iov[i].iov_base; +} else { +segs[i].flags = GNTCOPY_source_gref; +segs[i].source.foreign.ref = ioreq->refs[i]; +segs[i].source.foreign.domid = ioreq->domids[i]; +segs[i].source.foreign.offset = ioreq->req.seg[i].first_sect * file_blk; +segs[i].dest.virt = ioreq->v.iov[i].iov_base; +} +
[Xen-devel] Publishing livepatch instructions for XSAs from livepatch wiki
Hey, My goal for Xen 4.8 is to get OSSTest to regularly test livepatch mechanism. I am struggling with OSSTest but I am sure I will figure it out. But in the meantime I was wondering what the community feels about publishing step-by-step instructions on how to use livepatching for XSAs. When XSA-182 came out I prepared an document (see attached). Now that XSA 182 is public it can be put on the Wiki page. What I was wondering if folks would be OK with: 1). Linking it from http://wiki.xen.org/wiki/LivePatch? 2). Adding 'Security' and 'Livepatch' category to it? (That means if one searches for 'security' you can find the livepatch and say Xen Security policies and such). ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 0/2] qemu-qdisk: Implementation of grant copy operation.
Hi, It is a proposition for implementation of grant copy operation in qemu-qdisk and interface in libxc/libs. Changes since v3: Interface: - revert to cast from xengnttab_grant_copy_segment_t to ioctl_gntdev_grant_copy. - added compile-time check to compare the libs xengnttab_grant_copy_segment_t with the ioctl structure. The patch relies on Wei patch introducing XENGNTTAB_BUILD_BUG_ON in libs/gnttab. qemu-qdisk: - qemu_memalign/qemu_free is used instead function allocating memory from xc. - removed the get_buffer function instead there is a direct call to qemu_memalign. - moved ioreq_copy for write operation to ioreq_runio_qemu_aio. - added struct xengnttab_grant_copy_segment_t and stub in xen_common.h for version of Xen earlier then 480. - added checking for version 480 to configure. The test repeats all the operation that are required for version < 480 and checks if xengnttab_grant_copy() is implemented. Changes since v2: Interface: - dropped the changes in libxc/include/xenctrl_compat - changed the MINOR version in Makefile - replaced 'return -1' -> 'abort()'in libs/gnttab/gnttab_unimp.c - moved the struct 'xengnttab_copy_grant_segment' to libs/gnttab/include/xengnttab.h - added explicit assingment to ioctl_gntdev_grant_copy_segment to the linux part qemu-qdisk: - to use the xengnttab_* function directly added -lxengnttab to configure and include in include/hw/xen/xen_common.h - in ioreq_copy removed an out path, changed a log level, made explicit assignement to 'xengnttab_copy_grant_segment' * I did not change the way of testing if grant_copy operation is implemented. As far as I understand if the code from gnttab_unimp.c is used then the gnttab device is unavailable and the handler to gntdev would be invalid. But if the handler is valid then the ioctl should return operation unimplemented if the gntdev does not implement the operation. Changes since v1: Interface: - changed the interface to call grant copy operation to match ioctl int xengnttab_grant_copy(xengnttab_handle *xgt, uint32_t count, xengnttab_grant_copy_segment_t* segs) - added a struct 'xengnttab_copy_grant_segment' definition to tools/libs /gnttab/private.h, tools/libxc/include/xenctrl_compat.h - changed the function 'osdep_gnttab_grant_copy' which right now just call the ioctl - added a new VER1.1 to tools/libs/gnttab/libxengnttab.map qemu-qdisk: - removed the 'ioreq_write','ioreq_read_init','ioreq_read' functions - implemented 'ioreq_init_copy_buffers', 'ioreq_copy' - reverted the removal of grant map and introduced conditional invoking grant copy or grant map - resigned from caching the local buffers on behalf of allocating the required amount of pages at once. The cached structure would require to have an lock guard and I suppose that the performance improvement would degraded. For the functional test I attached the device with a qdisk backend to the guest, mounted, performed some reads and writes. I run fio tests[1] with different iodepth and size of the block. The test can be accessed on my github[2] but mainly after the warm up I run for 60 seconds: fio --time_based \ --clocksource=clock_gettime \ --rw=randread \ --random_distribution=pareto:0.9 \ --size=10g \ --direct='1' \ --ioengine=libaio \ --filename=$DEV \ --iodepth=$IODEPTH \ --bs=$BS \ --name=$NAME \ --runtime=$RUNTIME >> $FILENAME The test were repeated at least three times. [1] https://docs.google.com/spreadsheets/d/1E6AMiB8ceJpExL6jWpH9u2yy6DZxzhmDUyFf-eUuJ0c/edit?usp=sharing [2] https://github.com/paulina-szubarczyk/xen-benchmark - multitest_with_iodepth.sh Thanks and regards, Paulina ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/9] x86/pv: Implement pv_hypercall() in C
On 02/08/16 14:12, Jan Beulich wrote: On 18.07.16 at 11:51,wrote: >> +long pv_hypercall(struct cpu_user_regs *regs) >> +{ >> +struct vcpu *curr = current; >> +#ifndef NDEBUG >> +unsigned long old_rip = regs->rip; >> +#endif >> +long ret; >> +uint32_t eax = regs->eax; >> + >> +ASSERT(curr->arch.flags & TF_kernel_mode); > I'm afraid TF_kernel_mode can't be relied on for 32-bit guests, so > this needs to move into the if() below. In which case it should become ASSERT(guest_mode_kernel(curr, regs)) > >> +if ( (eax >= NR_hypercalls) || !hypercall_table[eax] ) >> + return -ENOSYS; >> + >> +if ( !is_pv_32bit_vcpu(curr) ) >> +{ >> +unsigned long rdi = regs->rdi; >> +unsigned long rsi = regs->rsi; >> +unsigned long rdx = regs->rdx; >> +unsigned long r10 = regs->r10; >> +unsigned long r8 = regs->r8; >> +unsigned long r9 = regs->r9; >> + >> +#ifndef NDEBUG >> +/* Deliberately corrupt parameter regs not used by this hypercall. >> */ >> +switch ( hypercall_args_table[eax] ) >> +{ >> +case 0: rdi = 0xdeadbeefdeadf00dUL; >> +case 1: rsi = 0xdeadbeefdeadf00dUL; >> +case 2: rdx = 0xdeadbeefdeadf00dUL; >> +case 3: r10 = 0xdeadbeefdeadf00dUL; >> +case 4: r8 = 0xdeadbeefdeadf00dUL; >> +case 5: r9 = 0xdeadbeefdeadf00dUL; > Without comments, aren't these going to become 5 new Coverity > issues? There are no current warnings from the HVM side, so I doubt it. Coverities' logic is rather complicated, but in this case I think the lack of any break statements at all is a sufficient hint that its fine. > >> --- a/xen/arch/x86/x86_64/compat/entry.S >> +++ b/xen/arch/x86/x86_64/compat/entry.S >> @@ -25,70 +25,10 @@ UNLIKELY_START(ne, msi_check) >> LOAD_C_CLOBBERED compat=1 ax=0 >> UNLIKELY_END(msi_check) >> >> -movl UREGS_rax(%rsp),%eax >> GET_CURRENT(bx) >> >> -cmpl $NR_hypercalls,%eax >> -jae compat_bad_hypercall >> -#ifndef NDEBUG >> -/* Deliberately corrupt parameter regs not used by this hypercall. >> */ >> -pushq UREGS_rbx(%rsp); pushq %rcx; pushq %rdx; pushq %rsi; pushq >> %rdi >> -pushq UREGS_rbp+5*8(%rsp) >> -leaq compat_hypercall_args_table(%rip),%r10 >> -movl $6,%ecx >> -subb (%r10,%rax,1),%cl >> -movq %rsp,%rdi >> -movl $0xDEADBEEF,%eax >> -rep stosq >> -popq %r8 ; popq %r9 ; xchgl %r8d,%r9d /* Args 5&6: zero extend */ >> -popq %rdx; popq %rcx; xchgl %edx,%ecx /* Args 3&4: zero extend */ >> -popq %rdi; popq %rsi; xchgl %edi,%esi /* Args 1&2: zero extend */ >> -movl UREGS_rax(%rsp),%eax >> -pushq %rax >> -pushq UREGS_rip+8(%rsp) >> -#define SHADOW_BYTES 16 /* Shadow EIP + shadow hypercall # */ >> -#else >> -/* Relocate argument registers and zero-extend to 64 bits. */ >> -xchgl %ecx,%esi /* Arg 2, Arg 4 */ >> -movl %edx,%edx /* Arg 3*/ >> -movl %edi,%r8d /* Arg 5*/ >> -movl %ebp,%r9d /* Arg 6*/ >> -movl UREGS_rbx(%rsp),%edi /* Arg 1*/ >> -#define SHADOW_BYTES 0 /* No on-stack shadow state */ >> -#endif >> -cmpb $0,tb_init_done(%rip) >> -UNLIKELY_START(ne, compat_trace) >> -call __trace_hypercall_entry >> -/* Restore the registers that __trace_hypercall_entry clobbered. */ >> -movl UREGS_rax+SHADOW_BYTES(%rsp),%eax /* Hypercall # */ >> -movl UREGS_rbx+SHADOW_BYTES(%rsp),%edi /* Arg 1*/ >> -movl UREGS_rcx+SHADOW_BYTES(%rsp),%esi /* Arg 2*/ >> -movl UREGS_rdx+SHADOW_BYTES(%rsp),%edx /* Arg 3*/ >> -movl UREGS_rsi+SHADOW_BYTES(%rsp),%ecx /* Arg 4*/ >> -movl UREGS_rdi+SHADOW_BYTES(%rsp),%r8d /* Arg 5*/ >> -movl UREGS_rbp+SHADOW_BYTES(%rsp),%r9d /* Arg 6*/ >> -#undef SHADOW_BYTES >> -UNLIKELY_END(compat_trace) >> -leaq compat_hypercall_table(%rip),%r10 >> -PERFC_INCR(hypercalls, %rax, %rbx) >> -callq *(%r10,%rax,8) >> -#ifndef NDEBUG >> -/* Deliberately corrupt parameter regs used by this hypercall. */ >> -popq %r10 # Shadow RIP >> -cmpq %r10,UREGS_rip+8(%rsp) >> -popq %rcx # Shadow hypercall index >> -jne compat_skip_clobber /* If RIP has changed then don't clobber. >> */ >> -leaq compat_hypercall_args_table(%rip),%r10 >> -movb (%r10,%rcx,1),%cl >> -movl $0xDEADBEEF,%r10d >> -testb %cl,%cl; jz compat_skip_clobber; movl %r10d,UREGS_rbx(%rsp) >> -cmpb $2, %cl; jb compat_skip_clobber; movl %r10d,UREGS_rcx(%rsp) >> -cmpb $3, %cl; jb compat_skip_clobber; movl %r10d,UREGS_rdx(%rsp) >> -cmpb $4, %cl; jb compat_skip_clobber;
[Xen-devel] [PATCH v4 1/2] Interface for grant copy operation in libs.
In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) system call is invoked. In mini-os the operation is yet not implemented. For the OSs that does not implement gnttab the call of the grant copy operation causes abort. Signed-off-by: Paulina Szubarczyk--- Changes since v3: - revert to cast from xengnttab_grant_copy_segment_t to ioctl_gntdev_grant_copy. - added compile-time check to compare the libs xengnttab_grant_copy_segment_t with the ioctl structure. The patch relies on Wei patch introducing XENGNTTAB_BUILD_BUG_ON in libs/gnttab. --- tools/include/xen-sys/Linux/gntdev.h | 21 ++ tools/libs/gnttab/Makefile| 2 +- tools/libs/gnttab/gnttab_core.c | 6 +++ tools/libs/gnttab/gnttab_unimp.c | 6 +++ tools/libs/gnttab/include/xengnttab.h | 28 + tools/libs/gnttab/libxengnttab.map| 5 +++ tools/libs/gnttab/linux.c | 79 +++ tools/libs/gnttab/minios.c| 6 +++ tools/libs/gnttab/private.h | 4 ++ 9 files changed, 156 insertions(+), 1 deletion(-) diff --git a/tools/include/xen-sys/Linux/gntdev.h b/tools/include/xen-sys/Linux/gntdev.h index caf6fb4..0ca07c9 100644 --- a/tools/include/xen-sys/Linux/gntdev.h +++ b/tools/include/xen-sys/Linux/gntdev.h @@ -147,4 +147,25 @@ struct ioctl_gntdev_unmap_notify { /* Send an interrupt on the indicated event channel */ #define UNMAP_NOTIFY_SEND_EVENT 0x2 +struct ioctl_gntdev_grant_copy_segment { +union { +void *virt; +struct { +uint32_t ref; +uint16_t offset; +uint16_t domid; +} foreign; +} source, dest; +uint16_t len; +uint16_t flags; +int16_t status; +}; + +#define IOCTL_GNTDEV_GRANT_COPY \ +_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy)) +struct ioctl_gntdev_grant_copy { +unsigned int count; +struct ioctl_gntdev_grant_copy_segment *segments; +}; + #endif /* __LINUX_PUBLIC_GNTDEV_H__ */ diff --git a/tools/libs/gnttab/Makefile b/tools/libs/gnttab/Makefile index af64542..95c2cd8 100644 --- a/tools/libs/gnttab/Makefile +++ b/tools/libs/gnttab/Makefile @@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../.. include $(XEN_ROOT)/tools/Rules.mk MAJOR= 1 -MINOR= 0 +MINOR= 1 SHLIB_LDFLAGS += -Wl,--version-script=libxengnttab.map CFLAGS += -Werror -Wmissing-prototypes diff --git a/tools/libs/gnttab/gnttab_core.c b/tools/libs/gnttab/gnttab_core.c index 5d0474d..968c833 100644 --- a/tools/libs/gnttab/gnttab_core.c +++ b/tools/libs/gnttab/gnttab_core.c @@ -113,6 +113,12 @@ int xengnttab_unmap(xengnttab_handle *xgt, void *start_address, uint32_t count) return osdep_gnttab_unmap(xgt, start_address, count); } +int xengnttab_grant_copy(xengnttab_handle *xgt, + uint32_t count, + xengnttab_grant_copy_segment_t *segs) +{ +return osdep_gnttab_grant_copy(xgt, count, segs); +} /* * Local variables: * mode: C diff --git a/tools/libs/gnttab/gnttab_unimp.c b/tools/libs/gnttab/gnttab_unimp.c index b3a4a20..829eced 100644 --- a/tools/libs/gnttab/gnttab_unimp.c +++ b/tools/libs/gnttab/gnttab_unimp.c @@ -78,6 +78,12 @@ int xengnttab_unmap(xengnttab_handle *xgt, void *start_address, uint32_t count) abort(); } +int xengnttab_copy_grant(xengnttab_handle *xgt, + uint32_t count, + xengnttab_copy_grant_segment_t *segs) +{ +abort(); +} /* * Local variables: * mode: C diff --git a/tools/libs/gnttab/include/xengnttab.h b/tools/libs/gnttab/include/xengnttab.h index 0431dcf..949fd9e 100644 --- a/tools/libs/gnttab/include/xengnttab.h +++ b/tools/libs/gnttab/include/xengnttab.h @@ -258,6 +258,34 @@ int xengnttab_unmap(xengnttab_handle *xgt, void *start_address, uint32_t count); int xengnttab_set_max_grants(xengnttab_handle *xgt, uint32_t nr_grants); +struct xengnttab_grant_copy_segment { +union xengnttab_copy_ptr { +void *virt; +struct { +uint32_t ref; +uint16_t offset; +uint16_t domid; +} foreign; +} source, dest; +uint16_t len; +uint16_t flags; +int16_t status; +}; + +typedef struct xengnttab_grant_copy_segment xengnttab_grant_copy_segment_t; + +/** + * Copy memory from or to grant references. The information of each operations + * are contained in 'xengnttab_grant_copy_segment_t'. The @flag value indicate + * the direction of an operation (GNTCOPY_source_gref\GNTCOPY_dest_gref). + * + * The sum of fields @offset[i] and @len[i] of 'xengnttab_grant_copy_segment_t' + * should not exceed XEN_PAGE_SIZE + */ +int xengnttab_grant_copy(xengnttab_handle *xgt, + uint32_t count, + xengnttab_grant_copy_segment_t *segs); + /* * Grant Sharing Interface (allocating and granting pages to others) */ diff --git
Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h
Hi Jan, On 02/08/16 14:28, Jan Beulich wrote: On 02.08.16 at 15:14,wrote: On 02/08/16 13:50, Jan Beulich wrote: On 18.07.16 at 11:51, wrote: --- a/xen/include/asm-x86/hypercall.h +++ b/xen/include/asm-x86/hypercall.h @@ -5,9 +5,21 @@ #ifndef __ASM_X86_HYPERCALL_H__ #define __ASM_X86_HYPERCALL_H__ +#include #include +#include Why? You snipped the commit message, which justifies why. This header file cannot currently be included in isolation, and I need it to be. Ah, that sentence there also relates to this addition. #include /* for do_mca */ -#include + +typedef unsigned long hypercall_fn_t( +unsigned long, unsigned long, unsigned long, +unsigned long, unsigned long, unsigned long); Wouldn't this better go into xen/hypercall.h? It is architecture specific. ARM's version is typedef register_t (*arm_hypercall_fn_t)( register_t, register_t, register_t, register_t, register_t); Which is bogus - they're lucky we so far don't have any 6-argument hypercalls. Or the other way around - we could limit hypercalls to just five arguments (for now) on x86 too, allowing things to get unified. Anyway - that probably goes too far right now, so feel free to add my ack to the patch. I am not sure why you think we are lucky on ARM. The hypercall has been defined on ARM to support up to 5 arguments (public/arch-arm.h): "A hypercall can take up to 5 arguments. These are passed in registers, the first argument in x0/r0 (for arm64/arm32 guests respectively irrespective of whether the underlying hypervisor is 32- or 64-bit), the second argument in x1/r1, the third in x2/r2, the forth in x3/r3 and the fifth in x4/r4." So the prototype matches the ABI. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/kconfig: unify messages of options moved from command line to kconfig
On Mon, Aug 01, 2016 at 09:21:28AM -0600, Jan Beulich wrote: > >>> On 26.07.16 at 17:45,wrote: > > Change the message so that it mentions running from the top level directory > > and using '-C xen' in order to call the 'menuconfig' target inside of the > > xen directory (there's no top-level menuconfig target). > > Well, I'm not convinced whether this end up clarifying or confusing > things, as that partly depends on how you normally invoke make (or > the various makes of the sub-trees individually). Hm, and what about adding a top-level menuconfig target, does that sound any better? TBH, I'm not specially thrilled either way, I just think the message is misleading, but I don't mind putting this aside if everyone else is fine with it. > > --- a/xen/Rules.mk > > +++ b/xen/Rules.mk > > @@ -9,27 +9,31 @@ lto ?= n > > > > include $(XEN_ROOT)/Config.mk > > > > +error_str = "You must use '$(MAKE) -C xen menuconfig' from the top level > > directory to enable/disable $(1) now." > > +error_msg = $(error $(error_str)) > > +warning_msg = $(warning $(error_str)) > > In any event with the two given uses "error_str" is not an > appropriate name. How about "build-diag" or some such? > > > + > > > > ifneq ($(origin crash_debug),undefined) > > And please don't add a stray second blank line like this. Ack to the above comments, but will wait for opinions before resending. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] systemd: remove hard-coded pid file in xendriverdomain service
On Tue, Aug 02, 2016 at 02:41:58PM +0100, Ian Jackson wrote: > Wei Liu writes ("[PATCH] systemd: remove hard-coded pid file in > xendriverdomain service"): > > Per the discussion in [0], the hard-coded pid file can be removed > > completely. Systemd has no trouble figuring out the pid of devd all by > > itself. > > > > [0]: https://lists.xen.org/archives/html/xen-devel/2016-07/msg01393.html > > I'm not qualified to have much of an opinion this but I'm happy to see > it go in based on what I assume is a test report from Rusty Bird ? > No, it's not a test report. Rusty Bird was the submitter of that xl devd unit file. I assumed he had experience of setting up xl devd without a pid file under systemd and did what he asked for. > On that basis, > > Acked-by: Ian Jackson> > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] x86/hap: use the right cache attributes when MTRR is disabled
Currently the code that calculates the cache attributes of the HAP page tables assume that if MTRR are disabled the memory type is UC, this can cause issues if MTRR are never enabled because the guest only plans to use PAT. In order to solve this modify epte_get_entry_emt so that is takes into account that MTRR can be disabled and that PAT should be used instead, this also implies that when page tables are enabled inside the guest a recalculation of the HAP page table cache attributes must be performed. The special casing that was previously done for PVHv1 guests can now be removed, since PVHv1 guest cannot have MTRR enabled or paging disabled, so the memory type is always going to be MTRR_TYPE_WRBACK in that case. Signed-off-by: Roger Pau Monné--- Cc: Jan Beulich Cc: Andrew Cooper --- Changes since v1: - Fix comments. - Slightly change the if ... else logic. - Correctly check if MTRR are enabled. - Expand description. --- xen/arch/x86/hvm/hvm.c | 4 xen/arch/x86/hvm/mtrr.c | 17 + 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index daaee1d..db4b2d6 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -2283,7 +2283,11 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer) if ( !nestedhvm_vmswitch_in_progress(v) && nestedhvm_vcpu_in_guestmode(v) ) paging_update_nestedmode(v); else +{ paging_update_paging_modes(v); +/* Force an update of the memory cache attributes. */ +memory_type_changed(d); +} } return X86EMUL_OKAY; diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c index f7831ff..bf3ab72 100644 --- a/xen/arch/x86/hvm/mtrr.c +++ b/xen/arch/x86/hvm/mtrr.c @@ -814,10 +814,19 @@ int epte_get_entry_emt(struct domain *d, unsigned long gfn, mfn_t mfn, if ( gmtrr_mtype == -EADDRNOTAVAIL ) return -1; -gmtrr_mtype = is_hvm_domain(d) && v ? - get_mtrr_type(>arch.hvm_vcpu.mtrr, -gfn << PAGE_SHIFT, order) : - MTRR_TYPE_WRBACK; +if ( !v ) +gmtrr_mtype = MTRR_TYPE_WRBACK; +else if ( v->arch.hvm_vcpu.mtrr.enabled & 0x2 ) +/* MTRR is enabled, use MTRR. */ +gmtrr_mtype = get_mtrr_type(>arch.hvm_vcpu.mtrr, gfn << PAGE_SHIFT, +order); +else if ( !hvm_paging_enabled(v) ) +/* MTRR is not enabled and paging is disabled, force UC. */ +gmtrr_mtype = MTRR_TYPE_UNCACHABLE; +else +/* MTRR is not enabled and paging is enabled, use PAT. */ +gmtrr_mtype = MTRR_TYPE_WRBACK; + hmtrr_mtype = get_mtrr_type(_state, mfn_x(mfn) << PAGE_SHIFT, order); if ( gmtrr_mtype < 0 || hmtrr_mtype < 0 ) return -1; -- 2.7.4 (Apple Git-66) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel