[Xen-devel] [ovmf test] 99912: all pass - PUSHED

[osstest service owner]

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, Eric 
  Eric 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

[Juergen Gross]

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

[Platform Team regression test user]

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 Shia 

jobs:
 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

[Kang, Luwei]

> 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

[Bob Liu]

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

[osstest service owner]

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 Shia 

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=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

[Platform Team regression test user]

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

[Platform Team regression test user]

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 Biesheuvel 
  Laszlo 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)

[Stefano Stabellini]

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

[osstest service owner]

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 Cooper 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev

[Xen-devel] [ovmf test] 99908: all pass - PUSHED

[osstest service owner]

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 Biesheuvel 
  Laszlo 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

[Tamas K Lengyel]

On Tue, Aug 2, 2016 at 4:05 PM, Julien Grall  wrote:
>
>
> 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

[Julien Grall]

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.


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

[Tamas K Lengyel]

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).

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

[osstest service owner]

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 Cooper 
  George 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

[Platform Team regression test user]

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

[osstest service owner]

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 Habkost 
  Igor 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

[Platform Team regression test user]

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 Biesheuvel 
  Ard 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

[Julien Grall]

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 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)?


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

[David Scott]

> On 2 Aug 2016, at 12:07, Wei Liu  wrote:
> 
> 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)

[Andrew Cooper]

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 Beulich 

Subject 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

[Andrew Cooper]

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

[Andrew Cooper]

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 ?

[lists]

> > 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

[Stefano Stabellini]

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

[Tamas K Lengyel]

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 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);
 
 /* 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

[Stefano Stabellini]

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

[Anthony PERARD]

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

[Stefano Stabellini]

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

[Stefano Stabellini]

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

[Anthony PERARD]

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

[osstest service owner]

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 Ostrovsky 
  Jan 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

[Anthony PERARD]

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 Gross 

Acked-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

[Rusty Bird]

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

[osstest service owner]

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 Biesheuvel 
  Ard 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

[osstest service owner]

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 Grall 

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-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

[Andrew Cooper]

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

[Juergen Gross]

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.

[Tamas K Lengyel]

On Tue, Aug 2, 2016 at 10:40 AM, Julien Grall  wrote:
>
>
> 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.

[Tamas K Lengyel]

On Tue, Aug 2, 2016 at 10:40 AM, Julien Grall  wrote:
>
>
> 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

[George Dunlap]

(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 Lai  wrote:
> 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.

[Julien Grall]

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.


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

[George Dunlap]

On Thu, Jun 23, 2016 at 7:23 PM, Lai, Paul C  wrote:
> 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

[Tamas Lengyel]

On Tue, Aug 2, 2016 at 10:13 AM, Jan Beulich  wrote:
 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.

[Tamas K Lengyel]

On Tue, Aug 2, 2016 at 10:08 AM, Andrew Cooper
 wrote:
> 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

[Jan Beulich]

>>> 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 ?

[Jan Beulich]

>>> 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

[Jan Beulich]

>>> 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.

[Tamas K Lengyel]

On Tue, Aug 2, 2016 at 10:11 AM, Julien Grall  wrote:
>
>
> 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.

[Andrew Cooper]

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.

[Julien Grall]

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?


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

[Juergen Gross]

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 Gross 
Acked-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

[Wei Liu]

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.

[Tamas K Lengyel]

On Tue, Aug 2, 2016 at 10:05 AM, 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.)

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

[Juergen Gross]

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

[Juergen Gross]

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 Gross 
Acked-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

[Juergen Gross]

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

[Juergen Gross]

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 
---
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

[Wei Liu]

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

[Wei Liu]

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

[Wei Liu]

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

[Wei Liu]

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

[Tamas K Lengyel]

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:
>> > --- 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.

[George Dunlap]

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.

[Tamas K Lengyel]

On Tue, Aug 2, 2016 at 1:38 AM, 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.
>
> 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

[Tamas K Lengyel]

On Tue, Aug 2, 2016 at 12:19 AM, sepanta s  wrote:

>
>
> 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

[Roger Pau Monne]

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.

[Tamas K Lengyel]

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.

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?

[lists]

> 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

[Anthony PERARD]

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 Gross 

Acked-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

[Tamas K Lengyel]

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

[Tamas K Lengyel]

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

[Lan, Tianyu]

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

[Jan Beulich]

>>> 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 ?

[lists]

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

[osstest service owner]

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 Cooper 
  Chao 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

[Andrew Cooper]

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

[Jan Beulich]

>>> 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 ?

[Jan Beulich]

>>> 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

[Jan Beulich]

>>> 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

[Olaf Hering]

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

[Boris Ostrovsky]

From: root 

These 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

[Julien Grall]

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 ?

[lists]

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

[Jan Beulich]

>>> 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

[Jan Beulich]

>>> 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

[Boris Ostrovsky]

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 Gross 


Reviewed-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

[Wei Liu]

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 ?

[Jan Beulich]

>>> 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

[Boris Ostrovsky]

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 Gross 


Reviewed-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.

[Sergej Proskurin]

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

[Paulina Szubarczyk]

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

[Konrad Rzeszutek Wilk]

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.

[Paulina Szubarczyk]

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

[Andrew Cooper]

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.

[Paulina Szubarczyk]

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

[Julien Grall]

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

[Roger Pau Monne]

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

[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.

> 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

[Roger Pau Monne]

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