[Xen-devel] [xen-unstable test] 102097: tolerable FAIL - PUSHED

[osstest service owner]

flight 102097 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102097/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102045
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102068
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102068
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102068
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102068
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102068
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102068
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102068
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 102068

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-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 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 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-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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

version targeted for testing:
 xen  a0b4e3c0681a11b765fe218fba0ba4ebb9fa56c5
baseline version:
 xen  bcb13635fa503113c981c6ea7423f930c1548452

Last test of basis   102068  2016-11-09 13:00:05 Z1 days
Failing since102084  2016-11-10 06:57:01 Z1 days2 attempts
Testing same since   102097  2016-11-10 20:48:30 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Julien Grall 
  Stefano Stabellini 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  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   

[Xen-devel] [xen-unstable-smoke test] 102107: tolerable all pass - PUSHED

[osstest service owner]

flight 102107 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102107/

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  9fdffbbab3ada427bac07076f042f0265e5ae05f
baseline version:
 xen  88f21a0c2a4c8d59cf25ba2d6e6f13d6ce5a42ae

Last test of basis   102102  2016-11-11 02:01:54 Z0 days
Testing same since   102107  2016-11-11 04:12:06 Z0 days1 attempts


People who touched revisions under test:
  Cédric Bosdonnat 
  Daniel De Graaf 
  Quan Xu 

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=9fdffbbab3ada427bac07076f042f0265e5ae05f
+ . ./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 
9fdffbbab3ada427bac07076f042f0265e5ae05f
+ branch=xen-unstable-smoke
+ revision=9fdffbbab3ada427bac07076f042f0265e5ae05f
+ . ./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
+ '[' x9fdffbbab3ada427bac07076f042f0265e5ae05f = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.or

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Tan, Jianfeng]

Hi Thomas and Konrad,


On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote:

On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon
 wrote:

2016-11-07 07:38, Jianfeng Tan:

As some users are still using xen as the hypervisor, I suggest to
continue support for xen in DPDK. And from 16.11, I will be the
maintainer of all xen-related files.

Signed-off-by: Jianfeng Tan 

Applied

Please Jianfeng, could you start your new role by sending a status
of Xen dom0 support in DPDK? I think there are some issues in latest releases.


Yes, I'm on this. And hope to send out update in the next week.




Pls also CC me and xen-de...@lists.xenproject.org if possible.


Glad to do that.

Thanks,
Jianfeng



Thanks!



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 102102: tolerable all pass - PUSHED

[osstest service owner]

flight 102102 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102102/

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  88f21a0c2a4c8d59cf25ba2d6e6f13d6ce5a42ae
baseline version:
 xen  0a34e43d0f74ecaf815bf094443925857b9e83a1

Last test of basis   102095  2016-11-10 19:02:20 Z0 days
Testing same since   102102  2016-11-11 02:01:54 Z0 days1 attempts


People who touched revisions under test:
  Roger Pau Monne 
  Roger Pau Monné 
  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=88f21a0c2a4c8d59cf25ba2d6e6f13d6ce5a42ae
+ . ./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 
88f21a0c2a4c8d59cf25ba2d6e6f13d6ce5a42ae
+ branch=xen-unstable-smoke
+ revision=88f21a0c2a4c8d59cf25ba2d6e6f13d6ce5a42ae
+ . ./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
+ '[' x88f21a0c2a4c8d59cf25ba2d6e6f13d6ce5a42ae = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Stefano Stabellini]

On Thu, 10 Nov 2016, Julien Grall wrote:
> (CC Stefano and change the title)
> 
> Hello,
> 
> On 10/11/16 12:13, casionwoo wrote:
> > I’m pleased about your reply and you have a lot of code to clean-up.
> > 
> > As you mentioned, It’s really huge to digest at once. Thank you for
> > understanding me.
> > 
> > And that’s why i need a small fix up and todo list.
> > 
> > I feel familiar with ARM and c language and there’s no specific area yet.
> > 
> > I think that i can find interesting area with following up the codes.
> > 
> > I’m looking forward to being stuck on Xen.
> > 
> > Then it would be easier for me to understand about Xen on ARM.
> > 
> > Please let me know the TODO and bug-fix lists.
> 
> Stefano, before giving a list of code clean-up, do you have any small TODO on
> ARM in mind?

A simple task we talked about recently is to enable the vuart
(xen/arch/arm/vuart.c) for all guests. At the moment it is only emulated
for Dom0, but some guests, in particular BareMetal guests
(https://en.wikipedia.org/wiki/BareMetal), would benefit from it.

It would be best to introduce an option in libxl to explicitly
enable/disable the vuart for DomUs. Something like vuart=1 in the VM
config file.

BTW we should keep this up to date:

https://wiki.xenproject.org/wiki/Xen_ARM_TODO___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] libxl: fix gentypes call in Makefile

[Wei Liu]

On Thu, Nov 10, 2016 at 05:46:00PM +0100, Cédric Bosdonnat wrote:
> From the make documentation:
> 
> "$* [...] If the target is `dir/a.foo.b' and the target pattern is
> `a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
> stem is part of the file name that matched the `%' in the target
> pattern."
> 
> The rule generating the c types files from the idl ones is not
> a static pattern rule, but rather an implicit rule. Thus the value
> of $* is preceded by the file path, instead of only what matches %.
> 
> In order to get this fixed, drop the path using a $(notdir $*).
> 
> Signed-off-by: Cédric Bosdonnat 

OOI how did you discover this? Should we consider backporting this to
some older versions?

> ---
>   v2: use $(notdir $*) instead of $(shell basename $*)
> ---
>  tools/libxl/Makefile | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index af0a3ad..4dbaa98 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -250,12 +250,13 @@ $(LIBXL_OBJS) $(LIBXL_TEST_OBJS) $(LIBXLU_OBJS) \
>  $(LIBXL_OBJS) $(LIBXL_TEST_OBJS): libxl_internal.h
>  
>  _libxl_type%.h _libxl_type%_json.h _libxl_type%_private.h _libxl_type%.c: 
> libxl_type%.idl gentypes.py idl.py
> - $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h 
> __libxl_type$*_private.h \
> - __libxl_type$*_json.h  __libxl_type$*.c
> - $(call move-if-changed,__libxl_type$*.h,_libxl_type$*.h)
> - $(call move-if-changed,__libxl_type$*_private.h,_libxl_type$*_private.h)
> - $(call move-if-changed,__libxl_type$*_json.h,_libxl_type$*_json.h)
> - $(call move-if-changed,__libxl_type$*.c,_libxl_type$*.c)
> + $(eval stem = $(notdir $*))
> + $(PYTHON) gentypes.py libxl_type$(stem).idl __libxl_type$(stem).h 
> __libxl_type$(stem)_private.h \
> + __libxl_type$(stem)_json.h  __libxl_type$(stem).c
> + $(call move-if-changed,__libxl_type$(stem).h,_libxl_type$(stem).h)
> + $(call 
> move-if-changed,__libxl_type$(stem)_private.h,_libxl_type$(stem)_private.h)
> + $(call 
> move-if-changed,__libxl_type$(stem)_json.h,_libxl_type$(stem)_json.h)
> + $(call move-if-changed,__libxl_type$(stem).c,_libxl_type$(stem).c)
>  
>  libxenlight.so: libxenlight.so.$(MAJOR)
>   $(SYMLINK_SHLIB) $< $@
> -- 
> 2.10.1
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Fix misleading indentation warnings

[Wei Liu]

On Thu, Nov 10, 2016 at 10:23:31AM +0100, Cédric Bosdonnat wrote:
> Gcc6 build reports misleading indentation as warnings. Fix a few
> warnings in stubdom.
> 
> Signed-off-by: Cédric Bosdonnat 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] per-domain logging

[Wei Liu]

On Wed, Nov 09, 2016 at 11:27:34AM +0100, Cedric Bosdonnat wrote:
> Hi Wei, Ian,
> 
> I now have a big lot of changes to use the LOG*D family through the libxl 
> code.
> What should be the best way to submit that for review? I guess a giant commit
> won't be too easy to handle for review and maintenance, maybe I should have 
> one
> commit per changed file... any opinion on that?
> 

Please have the first patch to be the one adding the LOG*D family
macros.

I don't really have an opinion on how to organise the actual changes to
various files. I think I would be more interested in how you classify
different LOG macros  and decide which ones to switch to LOGD family.

If the changes are done mechanically using tool like spatch, please
add the relevant runes into command message.

> --
> Cedric
> 
> On Thu, 2016-10-13 at 10:41 +0100, Wei Liu wrote:
> > On Thu, Oct 13, 2016 at 11:28:21AM +0200, Cedric Bosdonnat wrote:
> > > Hi Wei, Ian,
> > > 
> > > In quite a number of places, the domid we have in the function calling 
> > > LOG*
> > > may be the one of a stubdom. In the log we want to output the domid of the
> > > domain the user knows about. Would there be a way to get it?
> > > 
> > > An example of that is do_pci_add. It has a libxl_is_stubdom call, 
> > > suggesting
> > > that domid may not be the real domain id. An I wonder if there are other
> > > places where domid may be the one of a stubdom and I don't know it.
> > > 
> > 
> > The third argument of libxl_is_stubdom can be used to retrieve the
> > target domid.
> > 
> > If you find other places where you need to get the domid, please let me
> > know. I believe there are some fields embedded in various structs that
> > we can interrogate.
> > 
> > Wei.
> > 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

[Wei Liu]

On Thu, Nov 10, 2016 at 01:01:38PM +, Julien Grall wrote:
> (CC Wei as release manager)
> 
> On 10/11/16 08:30, Peng Fan wrote:
> >Hi Julien,
> 
> Hi Peng,
> 
> >On Tue, Nov 01, 2016 at 02:42:06PM +, Julien Grall wrote:
> >>Hi Peng,
> >>
> >>Sorry for the late answer.
> >>
> >>On 23/09/2016 03:55, Peng Fan wrote:
> >>>On AArch64 SoCs, some IPs may only have the capability to access
> >>>32 bits address space. The physical memory assigned for Dom0 maybe
> >>>not in 4GB address space, then the IPs will not work properly.
> >>>So need to allocate memory under 4GB for Dom0.
> >>>
> >>>There is no restriction that how much lowmem needs to be allocated for
> >>>Dom0 ,so allocate lowmem as much as possible for Dom0.
> >>>
> >>>This patch does not affect 32-bit domain, because Variable "lowmem" is
> >>>set to true at the beginning. If failed to allocate bank0 under 4GB,
> >>>need to panic for 32-bit domain, because 32-bit domain requires bank0
> >>>be allocated under 4GB.
> >>>
> >>>For 64-bit domain, set "lowmem" to false, and continue allocating
> >>>memory from above 4GB.
> >>>
> >>>Signed-off-by: Peng Fan 
> >>>Cc: Stefano Stabellini 
> >>>Cc: Julien Grall 
> >>
> >>Reviewed-by: Julien Grall 
> >>
> >>I am undecided whether this should be considered as a bug fix for Xen 4.8.
> >>Are you aware of any ARM64 platform we currently support requiring 
> >>allocation
> >>of memory below 4GB?
> >
> >I have no idea about this (:, but I think this is a bug fix. Alought current
> >supported platforms works well, users may choose 4.8 to support their
> >new platform which has the limitation to access 64bit address.
> 
> We are already late in the release process (rc5) for Xen 4.8. So we need to
> be careful when including a bug fix and evaluate the pros and cons.
> 
> This patch is modifying the DOM0 memory layout for all 64-bit platforms. So
> it could potentially break one of the platform we  officially support (see
> [1] for a non-exhaustive list). We don't have a test suite running
> automatically for ARM64 at the moment (it is been working on), this means
> that manual testing needs to be done. I am not aware of any platform, in the
> list we supports, having this issue so I prefer to stay on the safe side and
> defer this patch for Xen 4.9.
> 
> If a user cares about Xen 4.8 for their platforms, then they could request
> the patch to be backported in Xen 4.8 after the release and after extensive
> testing in staging.
> 

I agree with your reasoning.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] libxc: fix unmap of ACPI guest memory region

[Wei Liu]

On Tue, Nov 08, 2016 at 05:22:15PM +0100, Roger Pau Monne wrote:
> Commit fac7f7 changed the value of ptr so that it points to the right memory
> area, taking the page offset into account, but failed to remove this when
> doing the unmap, which caused the region to not be unmapped. Fix this by not
> modifying ptr and instead adding the page offset directly in the memcpy
> call.
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

[Peng Fan]

On Thu, Nov 10, 2016 at 01:01:38PM +, Julien Grall wrote:
>(CC Wei as release manager)
>
>On 10/11/16 08:30, Peng Fan wrote:
>>Hi Julien,
>
>Hi Peng,
>
>>On Tue, Nov 01, 2016 at 02:42:06PM +, Julien Grall wrote:
>>>Hi Peng,
>>>
>>>Sorry for the late answer.
>>>
>>>On 23/09/2016 03:55, Peng Fan wrote:
On AArch64 SoCs, some IPs may only have the capability to access
32 bits address space. The physical memory assigned for Dom0 maybe
not in 4GB address space, then the IPs will not work properly.
So need to allocate memory under 4GB for Dom0.

There is no restriction that how much lowmem needs to be allocated for
Dom0 ,so allocate lowmem as much as possible for Dom0.

This patch does not affect 32-bit domain, because Variable "lowmem" is
set to true at the beginning. If failed to allocate bank0 under 4GB,
need to panic for 32-bit domain, because 32-bit domain requires bank0
be allocated under 4GB.

For 64-bit domain, set "lowmem" to false, and continue allocating
memory from above 4GB.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
>>>
>>>Reviewed-by: Julien Grall 
>>>
>>>I am undecided whether this should be considered as a bug fix for Xen 4.8.
>>>Are you aware of any ARM64 platform we currently support requiring allocation
>>>of memory below 4GB?
>>
>>I have no idea about this (:, but I think this is a bug fix. Alought current
>>supported platforms works well, users may choose 4.8 to support their
>>new platform which has the limitation to access 64bit address.
>
>We are already late in the release process (rc5) for Xen 4.8. So we need to
>be careful when including a bug fix and evaluate the pros and cons.
>
>This patch is modifying the DOM0 memory layout for all 64-bit platforms. So
>it could potentially break one of the platform we  officially support (see
>[1] for a non-exhaustive list). We don't have a test suite running
>automatically for ARM64 at the moment (it is been working on), this means
>that manual testing needs to be done. I am not aware of any platform, in the
>list we supports, having this issue so I prefer to stay on the safe side and
>defer this patch for Xen 4.9.

Ok. Defer it for 4.9 to avoid breaking any platforms. :)

>
>If a user cares about Xen 4.8 for their platforms, then they could request
>the patch to be backported in Xen 4.8 after the release and after extensive
>testing in staging.

Yeah. Agree

Thanks,
Peng.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 102086: regressions - FAIL

[osstest service owner]

flight 102086 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102086/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt  11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail REGR. vs. 101909
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail REGR. vs. 101909
 test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
 test-amd64-i386-libvirt-xsm  11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-pair 20 guest-start/debian  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 101909
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 101909
 test-armhf-armhf-libvirt 11 guest-start  fail REGR. vs. 101909

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 3 host-install(3) broken in 102070 pass in 102086
 test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 102070 pass in 102086
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat  fail pass in 102070

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101909
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101909

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-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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  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  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-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-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu9b4b0350264d8164996265d635c8b9599673afb4
baseline version:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f

Last test of basis   101909  2016-11-03 23:21:40 Z7 days
Failing since101943  2016-11-04 22:40:48 Z6 days9 attempts
Testing same since   102070  2016-11-09 14:41:39 Z1 days2 attempts


People who touched revisions under test:
  Christian Borntraeger 
  Cornelia Huck 
  Julian Brown 
  Kevin Wolf 
  Marcin Krzeminski 
  Olaf Hering 
  Paolo Bonzini 
  Peter Maydell 
  Prasad J Pandit 
  Sander Eikelenboom 
  Stefan Hajnoczi 
  Stefano Stabellini 
  Thomas Huth 
  Wei Liu 

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 

Re: [Xen-devel] [PATCH] Fix misleading indentation warnings

[Xuquan (Quan Xu)]

On November 10, 2016 11:25 PM, Daniel De Graaf wrote:
>On 11/10/2016 04:23 AM, Cédric Bosdonnat wrote:
>> Gcc6 build reports misleading indentation as warnings. Fix a few
>> warnings in stubdom.
>>
>> Signed-off-by: Cédric Bosdonnat 
>
>Acked-by: Daniel De Graaf 


Acked-by: Quan Xu 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH Altp2m cleanup 2/3 v12 1/3] Move altp2m specific functions to altp2m files.

[Paul Lai]

Moving altp2m domain startup and teardown into altp2m_domain_init()
and altp2m_domain_teardown() respectively.
Moving hvm_altp2m_supported() check into functions that use it
for better readability.
Got rid of stray blanks after open paren after function names.
Defining _XEN_ASM_X86_P2M_H instead of _XEN_P2M_H for
xen/include/asm-x86/p2m.h.

Signed-off-by: Paul Lai 
---
 xen/arch/x86/mm/altp2m.c | 55 
 xen/arch/x86/mm/hap/hap.c| 14 +--
 xen/include/asm-x86/altp2m.h |  4 +++-
 3 files changed, 59 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index 930bdc2..317c8f7 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -66,6 +67,60 @@ altp2m_vcpu_destroy(struct vcpu *v)
 }
 
 /*
+ *  allocate and initialize memory for altp2m portion of domain
+ *
+ *  returns < 0 on error
+ *  returns 0 on no operation & success
+ */
+int
+altp2m_domain_init(struct domain *d)
+{
+int rc;
+unsigned int i;
+
+if ( !hvm_altp2m_supported() )
+return 0;
+
+/* Init alternate p2m data. */
+if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
+return -ENOMEM;
+
+for ( i = 0; i < MAX_EPTP; i++ )
+d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
+if ( rc != 0 )
+{
+altp2m_domain_teardown(d);
+return rc;
+}
+}
+
+d->arch.altp2m_active = 0;
+
+return rc;
+}
+
+void
+altp2m_domain_teardown(struct domain *d)
+{
+unsigned int i;
+
+if ( !hvm_altp2m_supported() )
+return;
+
+d->arch.altp2m_active = 0;
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+p2m_teardown(d->arch.altp2m_p2m[i]);
+
+free_xenheap_page(d->arch.altp2m_eptp);
+d->arch.altp2m_eptp = NULL;
+}
+
+/*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 3218fa2..7fe6f83 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -533,19 +533,7 @@ void hap_final_teardown(struct domain *d)
 {
 unsigned int i;
 
-if ( hvm_altp2m_supported() )
-{
-d->arch.altp2m_active = 0;
-
-if ( d->arch.altp2m_eptp )
-{
-free_xenheap_page(d->arch.altp2m_eptp);
-d->arch.altp2m_eptp = NULL;
-}
-
-for ( i = 0; i < MAX_ALTP2M; i++ )
-p2m_teardown(d->arch.altp2m_p2m[i]);
-}
+altp2m_domain_teardown(d);
 
 /* Destroy nestedp2m's first */
 for (i = 0; i < MAX_NESTEDP2M; i++) {
diff --git a/xen/include/asm-x86/altp2m.h b/xen/include/asm-x86/altp2m.h
index 64c7618..0090c89 100644
--- a/xen/include/asm-x86/altp2m.h
+++ b/xen/include/asm-x86/altp2m.h
@@ -18,7 +18,6 @@
 #ifndef __ASM_X86_ALTP2M_H
 #define __ASM_X86_ALTP2M_H
 
-#include 
 #include  /* for struct vcpu, struct domain */
 #include   /* for vcpu_altp2m */
 
@@ -38,4 +37,7 @@ static inline uint16_t altp2m_vcpu_idx(const struct vcpu *v)
 return vcpu_altp2m(v).p2midx;
 }
 
+int altp2m_domain_init(struct domain *d);
+void altp2m_domain_teardown(struct domain *d);
+
 #endif /* __ASM_X86_ALTP2M_H */
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH Altp2m cleanup 2/3 v12 2/3] Altp2m cleanup: cleaning up partial memory allocations in hap_enable().

[Paul Lai]

In hap_enable(), clean up memory leaks upon failure of altp2m_domain_init().
Comment the memory error handling to help match allocs with cleanups.
Consolidate the memory error handing into single code path.
---
 xen/arch/x86/mm/hap/hap.c | 42 ++
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 7fe6f83..e63ffb0 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -488,43 +489,44 @@ int hap_enable(struct domain *d, u32 mode)
 /* allocate P2m table */
 if ( mode & PG_translate )
 {
+/* p2m_alloc_table() #1 */
 rv = p2m_alloc_table(p2m_get_hostp2m(d));
 if ( rv != 0 )
 goto out;
 }
 
 for (i = 0; i < MAX_NESTEDP2M; i++) {
+/* nested p2m_alloc_table() #2 */
 rv = p2m_alloc_table(d->arch.nested_p2m[i]);
 if ( rv != 0 )
goto out;
 }
 
-if ( hvm_altp2m_supported() )
-{
-/* Init alternate p2m data */
-if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
-{
-rv = -ENOMEM;
-goto out;
-}
+if ( (rv = altp2m_domain_init(d)) < 0 )
+goto out;
 
-for ( i = 0; i < MAX_EPTP; i++ )
-d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
+/* Now let other users see the new mode */
+d->arch.paging.mode = mode | PG_HAP_enable;
 
-for ( i = 0; i < MAX_ALTP2M; i++ )
-{
-rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
-if ( rv != 0 )
-   goto out;
-}
+domain_unpause(d);
+return rv;
 
-d->arch.altp2m_active = 0;
+ out:
+/* Unravel the partial nested p2m_alloc_table() #2 above */
+for ( i = 0; i < MAX_NESTEDP2M; i++ )
+{
+p2m_teardown(d->arch.nested_p2m[i]);
 }
 
-/* Now let other users see the new mode */
-d->arch.paging.mode = mode | PG_HAP_enable;
+/* Unravel p2m_alloc_table() #1 above */
+p2m_teardown(p2m_get_hostp2m(d));
+
+/* Unravel the hap_set_allocation(d, 256, NULL) above */
+paging_lock(d);
+hap_set_allocation(d, 0, NULL);
+ASSERT(d->arch.paging.hap.p2m_pages == 0);
+paging_unlock(d);
 
- out:
 domain_unpause(d);
 return rv;
 }
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH Altp2m cleanup 2/3 v12 3/3] Moving ept code to ept specific files.

[Paul Lai]

The was requested in:
  https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html
Renamed p2m_init_altp2m_helper() to p2m_init_altp2m_ept().

Signed-off-by: Paul Lai 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 xen/arch/x86/mm/p2m-ept.c | 39 +++
 xen/arch/x86/mm/p2m.c | 43 ++-
 xen/include/asm-x86/hvm/vmx/vmx.h |  3 +++
 xen/include/asm-x86/p2m.h |  9 +++-
 4 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 13cab24..04878f5 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1329,6 +1329,45 @@ void setup_ept_dump(void)
 register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT tables", 0);
 }
 
+void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
+{
+struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct ept_data *ept;
+
+p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
+p2m->max_remapped_gfn = 0;
+ept = &p2m->ept;
+ept->asr = pagetable_get_pfn(p2m_get_pagetable(p2m));
+d->arch.altp2m_eptp[i] = ept_get_eptp(ept);
+}
+
+unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp)
+{
+struct p2m_domain *p2m;
+struct ept_data *ept;
+unsigned int i;
+
+altp2m_list_lock(d);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+ept = &p2m->ept;
+
+if ( eptp == ept_get_eptp(ept) )
+goto out;
+}
+
+i = INVALID_ALTP2M;
+
+ out:
+altp2m_list_unlock(d);
+return i;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 6a45185..aa627d8 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2342,33 +2342,6 @@ int unmap_mmio_regions(struct domain *d,
 return i == nr ? 0 : i ?: ret;
 }
 
-unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp)
-{
-struct p2m_domain *p2m;
-struct ept_data *ept;
-unsigned int i;
-
-altp2m_list_lock(d);
-
-for ( i = 0; i < MAX_ALTP2M; i++ )
-{
-if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
-continue;
-
-p2m = d->arch.altp2m_p2m[i];
-ept = &p2m->ept;
-
-if ( eptp == ept_get_eptp(ept) )
-goto out;
-}
-
-i = INVALID_ALTP2M;
-
- out:
-altp2m_list_unlock(d);
-return i;
-}
-
 bool_t p2m_switch_vcpu_altp2m_by_id(struct vcpu *v, unsigned int idx)
 {
 struct domain *d = v->domain;
@@ -2474,18 +2447,6 @@ void p2m_flush_altp2m(struct domain *d)
 altp2m_list_unlock(d);
 }
 
-static void p2m_init_altp2m_helper(struct domain *d, unsigned int i)
-{
-struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
-struct ept_data *ept;
-
-p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
-p2m->max_remapped_gfn = 0;
-ept = &p2m->ept;
-ept->asr = pagetable_get_pfn(p2m_get_pagetable(p2m));
-d->arch.altp2m_eptp[i] = ept_get_eptp(ept);
-}
-
 int p2m_init_altp2m_by_id(struct domain *d, unsigned int idx)
 {
 int rc = -EINVAL;
@@ -2497,7 +2458,7 @@ int p2m_init_altp2m_by_id(struct domain *d, unsigned int 
idx)
 
 if ( d->arch.altp2m_eptp[idx] == mfn_x(INVALID_MFN) )
 {
-p2m_init_altp2m_helper(d, idx);
+p2m_init_altp2m_ept(d, idx);
 rc = 0;
 }
 
@@ -2517,7 +2478,7 @@ int p2m_init_next_altp2m(struct domain *d, uint16_t *idx)
 if ( d->arch.altp2m_eptp[i] != mfn_x(INVALID_MFN) )
 continue;
 
-p2m_init_altp2m_helper(d, i);
+p2m_init_altp2m_ept(d, i);
 *idx = i;
 rc = 0;
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 4cdd9b1..9f4c7de 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -561,6 +561,9 @@ void ept_p2m_uninit(struct p2m_domain *p2m);
 void ept_walk_table(struct domain *d, unsigned long gfn);
 bool_t ept_handle_misconfig(uint64_t gpa);
 void setup_ept_dump(void);
+void p2m_init_altp2m_ept(struct domain *d, unsigned int i);
+/* Locate an alternate p2m by its EPTP */
+unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp);
 
 void update_guest_eip(void);
 
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 7035860..0e72880 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -23,8 +23,8 @@
  * along with this program; If not, see .
  */
 
-#ifndef _XEN_P2M_H
-#define _XEN_P2M_H
+#ifndef _XEN_ASM_X86_P2M_H
+#define _XEN_ASM_X86_P2M_H
 
 #include 
 #include 
@@ -784,9 +784,6 @@ static inline struct p2m_domain *p2m_get_altp2m(struct vcpu 
*v)
 return v->domain->arch.altp2m_p2m[index];
 }
 
-/* Locate an alternate p2m by its EPTP */
-unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp);
-
 /* Switch alternate p2m 

[Xen-devel] [PATCH Altp2m cleanup 2/3 v12 0/3] altp2m cleanup

[Paul Lai]

The altp2m clean work is motivated by the following URLs:
   https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04454.html

Most of the work has been:
Lots of white space, indentation, and other coding style preference
corrections.
Lots of moving altp2m functions to the altp2m file.
Lots of moving ept functions to the ept file.
Fixing memory leaks in the hap_enable() memory allocation failures.


Paul Lai (3):
  Move altp2m specific functions to altp2m files.
  Altp2m cleanup: cleaning up partial memory allocations in
hap_enable().
  Moving ept code to ept specific files.

 xen/arch/x86/mm/altp2m.c  | 55 +++
 xen/arch/x86/mm/hap/hap.c | 61 ---
 xen/arch/x86/mm/p2m-ept.c | 39 +
 xen/arch/x86/mm/p2m.c | 43 ++-
 xen/include/asm-x86/altp2m.h  |  4 ++-
 xen/include/asm-x86/hvm/vmx/vmx.h |  3 ++
 xen/include/asm-x86/p2m.h |  9 ++
 7 files changed, 130 insertions(+), 84 deletions(-)

--
since v11

Fixed bug(s) in the memory leak error paths of hap_enable().
Consolidated the memory error path into a single code path for better
maintainability.
Created seperate patch for the memory error cleanup in hap_enable() for easier
backportability.

since v10

Removed the check for d == 0 at the head of altp2m_domain_init() per request.

Fixing code style issues missed in v10.  It was apparent that our eyes
are failing to see code style issues, so we started using some vim scripts
to assist.  Here's one for spaces after parens:
  pclai@pclaidev:/rhel-home/pclai/p2m_new/xen/output$ cat ~/vim_xen
  :highlight ForIfLParenNoSpace ctermbg=red guibg=red
  :highlight ForIfRParenNoSpace ctermbg=red guibg=red
  :match ForIfLParenNoSpace /['for''if'] ([a-zA-Z0-9]/
  :2match ForIfRParenNoSpace /['for''if'] .*[a-zA-Z0-9-+]+[)]$/

Here's another to catch dangling left curly braces:
  pclai@pclaidev:/rhel-home/pclai/p2m_new/xen/output$ cat ~/vim_xen_curly
  :highlight RParenCurly ctermbg=red guibg=red
  :match RParenCurly /) *[{]$/

We specifically unraval p2m_alloc_table() and hap_set_allocation() by
hand instead of calling p2m_teardown().
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Error migrating VM to secondary host using COLO replication

[Sadi]

Hi,

Thanks for helping me.

I'm trying lots of different things so maybe there are traces of older
tries i've done conflicting right now.

I'm planning on starting over again from the very beginning. I just wanna
know what tutorial follow. The one from the Wiki,  from the mail thread or
another one.

Link to tutorials:

Wiki: http://wiki.xenproject.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
Mail Thread: http://xen.markmail.org/search/?q=COLO#query:COLO+page:1+
mid:fb7wrn62vbks4unn+state:results

I had a little fight against ubuntu, so if you could suggest me an
operating system to, would be of great help.

Thanks,

Sadi.

On Wed, Nov 9, 2016 at 11:03 PM, Wen Congyang  wrote:

> On 11/10/2016 01:31 AM, Sadi wrote:
> > Hello again,
> >
> > Looking at the primary host's syslog, the arptables command from
> xen/etc/scripts/colo-proxy-setup has failed.
> >
> > Here's the log:
> >
> > Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: setup
> XENBUS_PATH=
> > Nov  9 14:43:39 colop kernel: [  302.825788] u32 classifier
> > Nov  9 14:43:39 colop kernel: [  302.825791] Actions configured
> > Nov  9 14:43:39 colop kernel: [  302.835407] Mirror/redirect action on
> > Nov  9 14:43:39 colop kernel: [  302.919605] ip6_tables: (C) 2000-2006
> Netfilter Core Team
> > Nov  9 14:43:39 colop kernel: [  302.941511] arp_tables: (C) 2002 David
> S. Miller
> > Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup:
> arptables -I INPUT -i eth1 -j MARK --set-mark 1 failed
> > Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: Writing
> /hotplug-status connected to xenstore.
> > Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup:
> Successful colo-proxy-setup setup for vif2.0-emu. mode = primary  vifname:
> vif2.0-emu, index: 1, forwarddev: eth1.
> >
> > It's ok for the --set-mark argument to have value equal '1' , not a hex?
>
> This log is very useful, we will investigate it.
>
> Thanks
> Wen Congyang
>
> >
> > The i got running the command is:
> > root@colop:~# arptables -I INPUT -i eth1 -j MARK --set-mark 1
> > Bad argument `1'
> >
> > Thanks, Sadi.
> >
> >
> >
> > On Tue, Nov 8, 2016 at 6:53 PM, Sadi  sadi...@gmail.com>> wrote:
> >
> > Hi,
> >
> > Apparently vif2.0-emu was already binded with br0 when "brctl addif
> br0 vif2.0-emu" failed.
> >
> > root@colob-HP-Compaq-6005-Pro-MT-PC:~# brctl addif br0 vif2.0-emu
> > device vif2.0-emu is already a member of a bridge; can't enslave it
> to bridge br0.
> > root@colob-HP-Compaq-6005-Pro-MT-PC:~# brctl show
> > bridge name bridge id   STP enabled interfaces
> > br0 8000.001a3fc46255   no  eth0
> > vif2.0
> > vif2.0-emu
> > br1 8000.   no
> >
> > About the iptables, it seems like SECCOLO target can't be recognised.
> >
> > root@colob-HP-Compaq-6005-Pro-MT-PC:~# iptables -t mangle -D
> PREROUTING -m physdev --physdev-in vif2.0-emu -j SECCOLO --index 1
> > iptables: No chain/target/match by that name.
> >
> > Here is my active modules matching colo:
> >
> > root@colob-HP-Compaq-6005-Pro-MT-PC:~# lsmod | grep -i colo
> > xt_SECCOLO 16384  1
> > nf_conntrack_colo  16384  2 xt_SECCOLO
> > x_tables   36864  8 xt_physdev,ip6table_mangle,ip_
> tables,xt_SECCOLO,xt_tcpudp,iptable_filter,iptable_mangle,ip6_tables
> > nf_conntrack  106496  4 xt_SECCOLO,nf_nat,nf_
> conntrack_colo,nf_conntrack_ipv4
> >
> > So i was looking in the iptables and this really looks like the
> source of the problem.
> >
> > Sadi.
> >
> > On Tue, Nov 8, 2016 at 5:57 PM, Konrad Rzeszutek Wilk <
> konrad.w...@oracle.com > wrote:
> >
> > > entered forwarding state
> > > Nov  7 18:10:30 colob NetworkManager[907]: 
> (vif2.0-emu): enslaved
> > > to br0
> > > Nov  7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup:
> brctl addif
> > > br0 vif2.0-emu failed
> >
> >
> > How come this failed?
> >
> > > Nov  7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup:
> iptables -t
> > > mangle -D PREROUTING -m physdev --physdev-in vif2.0-emu -j
> SECCOLO --index
> > > 1 failed
> >
> > Ah b/c of this. Are there any errors of what exactly failed?
> >
> >
> >
> >
> > --
> > Sadi.
> >
> >
> >
> >
> > --
> > Sadi.
>
>
>
>


-- 
Sadi.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 06/24] ARM: GICv3 ITS: introduce host LPI array

[Stefano Stabellini]

On Thu, 10 Nov 2016, Andre Przywara wrote:
> Hi,
> 
> On 27/10/16 23:59, Stefano Stabellini wrote:
> > On Wed, 28 Sep 2016, Andre Przywara wrote:
> >> The number of LPIs on a host can be potentially huge (millions),
> >> although in practise will be mostly reasonable. So prematurely allocating
> >> an array of struct irq_desc's for each LPI is not an option.
> >> However Xen itself does not care about LPIs, as every LPI will be injected
> >> into a guest (Dom0 for now).
> >> Create a dense data structure (8 Bytes) for each LPI which holds just
> >> enough information to determine the virtual IRQ number and the VCPU into
> >> which the LPI needs to be injected.
> >> Also to not artificially limit the number of LPIs, we create a 2-level
> >> table for holding those structures.
> >> This patch introduces functions to initialize these tables and to
> >> create, lookup and destroy entries for a given LPI.
> >> We allocate and access LPI information in a way that does not require
> >> a lock.
> >>
> >> Signed-off-by: Andre Przywara 
> >> ---
> >>  xen/arch/arm/gic-its.c| 154 
> >> ++
> >>  xen/include/asm-arm/gic-its.h |  18 +
> >>  2 files changed, 172 insertions(+)
> >>
> >> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> >> index 88397bc..2140e4a 100644
> >> --- a/xen/arch/arm/gic-its.c
> >> +++ b/xen/arch/arm/gic-its.c
> >> @@ -18,18 +18,31 @@
> >>  
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>  
> >> +/* LPIs on the host always go to a guest, so no struct irq_desc for them. 
> >> */
> >> +union host_lpi {
> >> +uint64_t data;
> >> +struct {
> >> +uint64_t virt_lpi:32;
> >> +uint64_t dom_id:16;
> >> +uint64_t vcpu_id:16;
> >> +};
> >> +};
> > 
> > Why not the following?
> > 
> >   union host_lpi {
> >   uint64_t data;
> >   struct {
> >   uint32_t virt_lpi;
> >   uint16_t dom_id;
> >   uint16_t vcpu_id;
> >   };
> >   };
> 
> I am not sure that gives me a guarantee of stuffing everything into a
> u64 (as per the C standard). It probably will on arm64 with gcc, but I
> thought better safe than sorry.

I am pretty sure that it is covered by the standard, also see
IHI0055A_aapcs64. Additionally I don't think the union with "data" is
actually required either.


> >>  /* Global state */
> >>  static struct {
> >>  uint8_t *lpi_property;
> >> +union host_lpi **host_lpis;
> >>  int host_lpi_bits;
> >>  } lpi_data;
> >>  
> >> @@ -43,6 +56,26 @@ static DEFINE_PER_CPU(void *, pending_table);
> >>  #define MAX_HOST_LPI_BITS\
> >>  min_t(unsigned int, lpi_data.host_lpi_bits, CONFIG_HOST_LPI_BITS)
> >>  #define MAX_HOST_LPIS   (BIT(MAX_HOST_LPI_BITS) - 8192)
> >> +#define HOST_LPIS_PER_PAGE  (PAGE_SIZE / sizeof(union host_lpi))
> >> +
> >> +static union host_lpi *gic_find_host_lpi(uint32_t lpi, struct domain *d)
> > 
> > I take "lpi" is the physical lpi here. Maybe we would rename it to "plpi"
> > for clarity.
> 
> Indeed.
> 
> > 
> >> +{
> >> +union host_lpi *hlpi;
> >> +
> >> +if ( lpi < 8192 || lpi >= MAX_HOST_LPIS + 8192 )
> >> +return NULL;
> >> +
> >> +lpi -= 8192;
> >> +if ( !lpi_data.host_lpis[lpi / HOST_LPIS_PER_PAGE] )
> >> +return NULL;
> >> +
> >> +hlpi = &lpi_data.host_lpis[lpi / HOST_LPIS_PER_PAGE][lpi % 
> >> HOST_LPIS_PER_PAGE];
> > 
> > I realize I am sometimes obsessive about this, but division operations
> > are expensive and this is on the hot path, so I would do:
> > 
> > #define HOST_LPIS_PER_PAGE  (PAGE_SIZE >> 3)
> 
> to replace
> #define HOST_LPIS_PER_PAGE  (PAGE_SIZE / sizeof(union host_lpi))?
> 
> This should be computed by the compiler, as it's constant.
> 
> > unsigned int table = lpi / HOST_LPIS_PER_PAGE;
> 
> So I'd rather replace this by ">> (PAGE_SIZE - 3)".

This is actually what I meant, thanks.


> But again the compiler would do this for us, as replacing "constant
> divisions by power-of-two" with "right shifts" are a text book example
> of easy optimization, if I remember this compiler class at uni correctly ;-)

Yet, we found instanced where this didn't happen in the common Xen
scheduler code on x86.


> > then use table throughout this function.
> 
> I see your point (though this is ARMv8, which always has udiv).
> But to prove your paranoia wrong: I don't see any divisions in the
> disassembly, but a lsr #3 and a lsr #9 and various other clever and
> cheap ARMv8 instructions ;-)
> Compilers have really come a long way in 2016 ...

Fair enough, thanks for checking. That is enough for me.


> >> +if ( d && hlpi->dom_id != d->domain_id )
> >> +return NULL;
> > 
> > I think this function is very useful so I would avoid making any domain
> > checks here: one day we might wa

Re: [Xen-devel] [RFC PATCH 03/24] ARM: GICv3 ITS: allocate device and collection table

[Stefano Stabellini]

On Thu, 10 Nov 2016, Andre Przywara wrote:
> Hi,
> 
> On 26/10/16 23:57, Stefano Stabellini wrote:
> > On Wed, 28 Sep 2016, Andre Przywara wrote:
> >> Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
> >> an EventID (the MSI payload or interrupt ID) to a pair of LPI number
> >> and collection ID, which points to the target CPU.
> >> This mapping is stored in the device and collection tables, which software
> >> has to provide for the ITS to use.
> >> Allocate the required memory and hand it the ITS.
> >> We limit the number of devices to cover 4 PCI busses for now.
> >>
> >> Signed-off-by: Andre Przywara 
> >> ---
> >>  xen/arch/arm/gic-its.c| 114 
> >> ++
> >>  xen/arch/arm/gic-v3.c |   5 ++
> >>  xen/include/asm-arm/gic-its.h |  49 +-
> >>  3 files changed, 167 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> >> index b52dff3..40238a2 100644
> >> --- a/xen/arch/arm/gic-its.c
> >> +++ b/xen/arch/arm/gic-its.c
> >> @@ -21,6 +21,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -38,6 +39,119 @@ static DEFINE_PER_CPU(void *, pending_table);
> >>  min_t(unsigned int, lpi_data.host_lpi_bits, CONFIG_HOST_LPI_BITS)
> >>  #define MAX_HOST_LPIS   (BIT(MAX_HOST_LPI_BITS) - 8192)
> >>  
> >> +#define BASER_ATTR_MASK   \
> >> +((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
> >> + (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
> >> + (0x7UL << GITS_BASER_INNER_CACHEABILITY_SHIFT))
> >> +#define BASER_RO_MASK   (GENMASK(52, 48) | GENMASK(58, 56))
> >> +
> >> +static uint64_t encode_phys_addr(paddr_t addr, int page_bits)
> >> +{
> >> +uint64_t ret;
> >> +
> >> +if ( page_bits < 16)
> >> +return (uint64_t)addr & GENMASK(47, page_bits);
> >> +
> >> +ret = addr & GENMASK(47, 16);
> >> +return ret | (addr & GENMASK(51, 48)) >> (48 - 12);
> >> +}
> >> +
> >> +static int gicv3_map_baser(void __iomem *basereg, uint64_t regc, int 
> >> nr_items)
> > 
> > Shouldn't this be called its_map_baser?
> 
> Yes, the BASER registers are an ITS property.
> 
> >> +{
> >> +uint64_t attr;
> >> +int entry_size = (regc >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0x1f;
> > 
> > The spec says "This field is read-only and specifies the number of
> > bytes per entry, minus one." Do we need to increment it by 1?
> 
> Mmh, looks so. I guess it worked because the number gets dwarfed by the
> page size round up below.
> 
> >> +int pagesz;
> >> +int order;
> >> +void *buffer = NULL;
> >> +
> >> +attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
> >> +attr |= GIC_BASER_CACHE_SameAsInner << 
> >> GITS_BASER_OUTER_CACHEABILITY_SHIFT;
> >> +attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
> >> +
> >> +/*
> >> + * Loop over the page sizes (4K, 16K, 64K) to find out what the host
> >> + * supports.
> >> + */
> > 
> > Is this really the best way to do it? Can't we assume ITS supports 4K,
> > given that Xen requires 4K pages at the moment?
> 
> The ITS pages are totally independent from the core's MMU page size.
> So the spec says: "If the GIC implementation supports only a single,
> fixed page size, this field might be RO."
> I take it that this means that the only implemented page size could be
> 64K, for instance. And in fact the KVM ITS emulation advertises exactly
> this to a guest.
> 
> > Is it actually possible
> > to find hardware that supports 4K but with an ITS that only support 64K
> > or 16K pages? It seems insane to me. Otherwise can't we probe the page
> > size somehow?
> 
> We can probe by writing and seeing if it sticks - that's what the code
> does. Is it really so horrible? I agree it's nasty, but isn't it
> basically a loop around the code needed anyway?

It looks very strange that there isn't a better way to find that info.
It looks a bit like an hack. It is also bad from a software point of
view being forced to cope with all three possible page granularities.

But oh well, sometimes we just have to deal with whatever the hardware
offers us.


> Yes to the rest of the comments.
> 
> 
> >> +for (pagesz = 0; pagesz < 3; pagesz++)
> >> +{
> >> +uint64_t reg;
> >> +int nr_bytes;
> >> +
> >> +nr_bytes = ROUNDUP(nr_items * entry_size, BIT(pagesz * 2 + 12));
> >> +order = get_order_from_bytes(nr_bytes);
> >> +
> >> +if ( !buffer )
> >> +buffer = alloc_xenheap_pages(order, 0);
> >> +if ( !buffer )
> >> +return -ENOMEM;
> >> +
> >> +reg  = attr;
> >> +reg |= (pagesz << GITS_BASER_PAGE_SIZE_SHIFT);
> >> +reg |= nr_bytes >> (pagesz * 2 + 12);
> >> +reg |= regc & BASER_RO_MASK;
> >> +reg |= GITS_BASER_VALID;
> >> +

[Xen-devel] [xen-unstable-smoke test] 102095: tolerable all pass - PUSHED

[osstest service owner]

flight 102095 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102095/

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  0a34e43d0f74ecaf815bf094443925857b9e83a1
baseline version:
 xen  a0b4e3c0681a11b765fe218fba0ba4ebb9fa56c5

Last test of basis   102092  2016-11-10 16:02:26 Z0 days
Testing same since   102095  2016-11-10 19:02:20 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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=0a34e43d0f74ecaf815bf094443925857b9e83a1
+ . ./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 
0a34e43d0f74ecaf815bf094443925857b9e83a1
+ branch=xen-unstable-smoke
+ revision=0a34e43d0f74ecaf815bf094443925857b9e83a1
+ . ./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
+ '[' x0a34e43d0f74ecaf815bf094443925857b9e83a1 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/

Re: [Xen-devel] [RFC PATCH 02/24] ARM: GICv3: allocate LPI pending and property table

[Stefano Stabellini]

On Thu, 10 Nov 2016, Andre Przywara wrote:
> Hi,
> 
> On 26/10/16 02:10, Stefano Stabellini wrote:
> > Hi Andre,
> > 
> > Sorry for the late reply, I'll try to be faster for the next rounds of
> > review. The patch looks good for a first iteration. Some comments below.
> 
> No worries and thanks for the thorough review, much appreciated.
> As you can see I took my time to respond as well ;-)
> 
> > 
> > On Wed, 28 Sep 2016, Andre Przywara wrote:
> >> The ARM GICv3 ITS provides a new kind of interrupt called LPIs.
> >> The pending bits and the configuration data (priority, enable bits) for
> >> those LPIs are stored in tables in normal memory, which software has to
> >> provide to the hardware.
> >> Allocate the required memory, initialize it and hand it over to each
> >> ITS. We limit the number of LPIs we use with a compile time constant to
> >> avoid wasting memory.
> >>
> >> Signed-off-by: Andre Przywara 
> >> ---
> >>  xen/arch/arm/Kconfig  |  6 
> >>  xen/arch/arm/efi/efi-boot.h   |  1 -
> >>  xen/arch/arm/gic-its.c| 76 
> >> +++
> >>  xen/arch/arm/gic-v3.c | 27 ++
> >>  xen/include/asm-arm/cache.h   |  4 +++
> >>  xen/include/asm-arm/gic-its.h | 22 +++-
> >>  xen/include/asm-arm/gic_v3_defs.h | 48 -
> >>  7 files changed, 181 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> >> index 9fe3b8e..66e2bb8 100644
> >> --- a/xen/arch/arm/Kconfig
> >> +++ b/xen/arch/arm/Kconfig
> >> @@ -50,6 +50,12 @@ config HAS_ITS
> >>  depends on ARM_64
> >>  depends on HAS_GICV3
> >>  
> >> +config HOST_LPI_BITS
> >> +depends on HAS_ITS
> >> +int "Maximum bits for GICv3 host LPIs (14-32)"
> >> +range 14 32
> >> +default "20"
> >> +
> >>  config ALTERNATIVE
> >>bool
> >>  
> >> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> >> index 045d6ce..dc64aec 100644
> >> --- a/xen/arch/arm/efi/efi-boot.h
> >> +++ b/xen/arch/arm/efi/efi-boot.h
> >> @@ -10,7 +10,6 @@
> >>  #include "efi-dom0.h"
> >>  
> >>  void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
> >> -void __flush_dcache_area(const void *vaddr, unsigned long size);
> >>  
> >>  #define DEVICE_TREE_GUID \
> >>  {0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 
> >> 0xe0}}
> >> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> >> index 0f42a77..b52dff3 100644
> >> --- a/xen/arch/arm/gic-its.c
> >> +++ b/xen/arch/arm/gic-its.c
> >> @@ -20,10 +20,86 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>  
> >> +/* Global state */
> >> +static struct {
> >> +uint8_t *lpi_property;
> >> +int host_lpi_bits;
> >> +} lpi_data;
> >> +
> >> +/* Pending table for each redistributor */
> >> +static DEFINE_PER_CPU(void *, pending_table);
> >> +
> >> +#define MAX_HOST_LPI_BITS\
> > 
> > To avoid confusion, I would call this MAX_PHYS_LPI_BITS
> > 
> > 
> >> +min_t(unsigned int, lpi_data.host_lpi_bits, CONFIG_HOST_LPI_BITS)
> >> +#define MAX_HOST_LPIS   (BIT(MAX_HOST_LPI_BITS) - 8192)
> > 
> > And this MAX_PHYS_LPIS
> 
> Done.
> 
> >> +uint64_t gicv3_lpi_allocate_pendtable(void)
> >> +{
> >> +uint64_t reg, attr;
> >> +void *pendtable;
> > 
> > I would introduce a check to make sure that this_cpu(pending_table) == NULL.
> 
> Can do. So I return back this value then, though this should never happen.
> 
> > 
> >> +attr  = GIC_BASER_CACHE_RaWaWb << 
> >> GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
> >> +attr |= GIC_BASER_CACHE_SameAsInner << 
> >> GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
> >> +attr |= GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT;
> >> +
> >> +/*
> >> + * The pending table holds one bit per LPI, so we need three bits less
> >> + * than the number of LPI_BITs.
> > 
> > Why 3 bit less? Please add more info on how you came up with 3.
> 
> 3 bits as in 2 << 3 = 8 = BITS_PER_BYTES. We need to divide by that,
> which is shift by 3, which is ORDER - 3. Does that make sense?
> But this mayhem goes away anyway with _xmalloc.

Please add info to the in code comment (if it will still be there).


> > 
> >> But the alignment requirement from the
> >> + * ITS is 64K, so make order at least 16 (-12).
> > 
> > Does it need to be 64K aligned or does it need to be at least 64K in
> > size?
> 
> The first.
> 
> > That makes a big difference. If it just needs to be 64K aligned,
> > you can do that with xmalloc.
> 
> Well, not xmalloc (since I don't have a data structure of that size),
> but _xmalloc. I just saw that this is exported as well (I dismissed this
> before because of the leading underscore).
> Also "alloc pages" sounded more like what I had in mind, but I guess
> aligning it to 64K serves the same pu

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

[Stefano Stabellini]

On Thu, 10 Nov 2016, Julien Grall wrote:
> Hi,
> 
> On 10/11/16 00:21, Stefano Stabellini wrote:
> > On Fri, 4 Nov 2016, Andre Przywara wrote:
> > > On 24/10/16 16:32, Vijay Kilari wrote:
> > > > On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara
> > > >  wrote:
> > > > > The INVALL command instructs an ITS to invalidate the configuration
> > > > > data for all LPIs associated with a given redistributor (read: VCPU).
> > > > > To avoid iterating (and mapping!) all guest tables, we instead go
> > > > > through
> > > > > the host LPI table to find any LPIs targetting this VCPU. We then
> > > > > update
> > > > > the configuration bits for the connected virtual LPIs.
> > > > > 
> > > > > Signed-off-by: Andre Przywara 
> > > > > ---
> > > > >  xen/arch/arm/gic-its.c| 58
> > > > > +++
> > > > >  xen/arch/arm/vgic-its.c   | 30 ++
> > > > >  xen/include/asm-arm/gic-its.h |  2 ++
> > > > >  3 files changed, 90 insertions(+)
> > > > > 
> > > > > diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> > > > > index 6f4329f..5129d6e 100644
> > > > > --- a/xen/arch/arm/gic-its.c
> > > > > +++ b/xen/arch/arm/gic-its.c
> > > > > @@ -228,6 +228,18 @@ static int its_send_cmd_inv(struct host_its *its,
> > > > >  return its_send_command(its, cmd);
> > > > >  }
> > > > > 
> > > > > +static int its_send_cmd_invall(struct host_its *its, int cpu)
> > > > > +{
> > > > > +uint64_t cmd[4];
> > > > > +
> > > > > +cmd[0] = GITS_CMD_INVALL;
> > > > > +cmd[1] = 0x00;
> > > > > +cmd[2] = cpu & GENMASK(15, 0);
> > > > > +cmd[3] = 0x00;
> > > > > +
> > > > > +return its_send_command(its, cmd);
> > > > > +}
> > > > > +
> > > > >  int gicv3_its_map_device(struct host_its *hw_its, struct domain *d,
> > > > >   int devid, int bits, bool valid)
> > > > >  {
> > > > > @@ -668,6 +680,52 @@ uint32_t gicv3_lpi_lookup_lpi(struct domain *d,
> > > > > uint32_t host_lpi, int *vcpu_id)
> > > > >  return hlpi.virt_lpi;
> > > > >  }
> > > > > 
> > > > > +/* Iterate over all host LPIs, and updating the "enabled" state for a
> > > > > given
> > > > > + * guest redistributor (VCPU) given the respective state in the
> > > > > provided
> > > > > + * proptable. This proptable is indexed by the stored virtual LPI
> > > > > number.
> > > > > + * This is to implement a guest INVALL command.
> > > > > + */
> > > > > +void gicv3_lpi_update_configurations(struct vcpu *v, uint8_t
> > > > > *proptable)
> > > > > +{
> > > > > +int chunk, i;
> > > > > +struct host_its *its;
> > > > > +
> > > > > +for (chunk = 0; chunk < MAX_HOST_LPIS / HOST_LPIS_PER_PAGE;
> > > > > chunk++)
> > > > > +{
> > > > > +if ( !lpi_data.host_lpis[chunk] )
> > > > > +continue;
> > > > > +
> > > > > +for (i = 0; i < HOST_LPIS_PER_PAGE; i++)
> > > > > +{
> > > > > +union host_lpi *hlpip = &lpi_data.host_lpis[chunk][i],
> > > > > hlpi;
> > > > > +uint32_t hlpi_nr;
> > > > > +
> > > > > +hlpi.data = hlpip->data;
> > > > > +if ( !hlpi.virt_lpi )
> > > > > +continue;
> > > > > +
> > > > > +if ( hlpi.dom_id != v->domain->domain_id )
> > > > > +continue;
> > > > > +
> > > > > +if ( hlpi.vcpu_id != v->vcpu_id )
> > > > > +continue;
> > > > > +
> > > > > +hlpi_nr = chunk * HOST_LPIS_PER_PAGE + i;
> > > > > +
> > > > > +if ( proptable[hlpi.virt_lpi] & LPI_PROP_ENABLED )
> > > > > +lpi_data.lpi_property[hlpi_nr - 8192] |=
> > > > > LPI_PROP_ENABLED;
> > > > > +else
> > > > > +lpi_data.lpi_property[hlpi_nr - 8192] &=
> > > > > ~LPI_PROP_ENABLED;
> > > > > +}
> > > > > +}
> > > > AFAIK, the initial design is to use tasklet to update property
> > > > table as it consumes
> > > > lot of time to update the table.
> > > 
> > > This is a possible, but premature optimization.
> > > Linux (at the moment, at least) only calls INVALL _once_, just after
> > > initialising the collections. And at this point no LPI is mapped, so the
> > > whole routine does basically nothing - and that quite fast.
> > > We can later have any kind of fancy algorithm if there is a need for.
> > 
> > I understand, but as-is it's so expensive that could be a DOS vector.
> > Also other OSes could issue INVALL much more often than Linux.
> > 
> > Considering that we might support device assigment with ITS soon, I
> > think it might be best to parse per-domain virtual tables rather than
> > the full list of physical LPIs, which theoretically could be much
> > larger. Or alternatively we need to think about adding another field to
> > lpi_data, to link together all lpis assigned to the same domain, but
> > that would cost even more memory. Or we could rate-limit the INVALL
> > calls to one every few seconds or something. Or all of the above :-)
> 
> It is not

[Xen-devel] [xen-unstable test] 102084: trouble: blocked/broken/fail/pass

[osstest service owner]

flight 102084 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102084/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   3 host-install(3)broken REGR. vs. 102068

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102045
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102068
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102068
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102068
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102068
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102068
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102068
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102068
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 102068

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-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 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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

version targeted for testing:
 xen  420596c8685d2c413ef4fc11fc942739b856a049
baseline version:
 xen  bcb13635fa503113c981c6ea7423f930c1548452

Last test of basis   102068  2016-11-09 13:00:05 Z1 days
Testing same since   102084  2016-11-10 06:57:01 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  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  

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

[osstest service owner]

flight 102087 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102087/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf c52f00d6e1e14b9eaf5c5a58501f075d2a64920c
baseline version:
 ovmf faabc5d49700a5042535ff30a07e2c9577ed3cd8

Last test of basis   102076  2016-11-09 19:46:42 Z0 days
Testing same since   102087  2016-11-10 09:40:40 Z0 days1 attempts


People who touched revisions under test:
  Bi, Dandan 
  Dandan Bi 
  Hao Wu 
  Ruiyu Ni 

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=c52f00d6e1e14b9eaf5c5a58501f075d2a64920c
+ . ./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 
c52f00d6e1e14b9eaf5c5a58501f075d2a64920c
+ branch=ovmf
+ revision=c52f00d6e1e14b9eaf5c5a58501f075d2a64920c
+ . ./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
+ '[' xc52f00d6e1e14b9eaf5c5a58501f075d2a64920c = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Konrad Rzeszutek Wilk]

On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon
 wrote:
> 2016-11-07 07:38, Jianfeng Tan:
>> As some users are still using xen as the hypervisor, I suggest to
>> continue support for xen in DPDK. And from 16.11, I will be the
>> maintainer of all xen-related files.
>>
>> Signed-off-by: Jianfeng Tan 
>
> Applied
>
> Please Jianfeng, could you start your new role by sending a status
> of Xen dom0 support in DPDK? I think there are some issues in latest releases.
>

Pls also CC me and xen-de...@lists.xenproject.org if possible.

Thanks!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen like VirtualBox

[Jason Long]

I mean is a nice GUI like VirtualBox.

On Mon, 11/7/16, Jason Long  wrote:

 Subject: Xen like VirtualBox
 To: Xen-devel@lists.xen.org
 Date: Monday, November 7, 2016, 10:18 AM
 
 Hello.
 Why Xen developer never think about a product like
 VirtualBox? It is true that Xen is a type 1 hypervisor but
 is it possible to make a product like VirtualBox based on
 Xen?
 
 Thank you.
 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen like VirtualBox

[Jason Long]

I mean is a nice GUI like VirtualBox.

On Mon, 11/7/16, Jason Long  wrote:

 Subject: Xen like VirtualBox
 To: Xen-devel@lists.xen.org
 Date: Monday, November 7, 2016, 10:18 AM
 
 Hello.
 Why Xen developer never think about a product like
 VirtualBox? It is true that Xen is a type 1 hypervisor but
 is it possible to make a product like VirtualBox based on
 Xen?
 
 Thank you.
 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 102092: tolerable all pass - PUSHED

[osstest service owner]

flight 102092 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102092/

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  a0b4e3c0681a11b765fe218fba0ba4ebb9fa56c5
baseline version:
 xen  420596c8685d2c413ef4fc11fc942739b856a049

Last test of basis   102079  2016-11-09 23:01:39 Z0 days
Testing same since   102092  2016-11-10 16:02:26 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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=a0b4e3c0681a11b765fe218fba0ba4ebb9fa56c5
+ . ./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 
a0b4e3c0681a11b765fe218fba0ba4ebb9fa56c5
+ branch=xen-unstable-smoke
+ revision=a0b4e3c0681a11b765fe218fba0ba4ebb9fa56c5
+ . ./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
+ '[' xa0b4e3c0681a11b765fe218fba0ba4ebb9fa56c5 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmwar

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

[Boris Ostrovsky]

On 11/10/2016 12:49 PM, David Vrabel wrote:
> On 10/11/16 17:47, Olaf Hering wrote:
>> On Thu, Nov 10, Boris Ostrovsky wrote:
>>
>>> Are you sure it's this patch that causes the failure?
>>>
>>> I commented out '| VM_IO' and still unable to boot with this option.
>> Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based:

I've never tested on 4.4, this was added for 4.5 (with CC to stable#4.4)
and now I am testing on 4.7)

>>
>> +++ b/drivers/xen/gntdev.c
>> @@ -804,7 +804,7 @@ static int gntdev_mmap(struct file *flip, struct 
>> vm_area_struct *vma)
>>  
>> vma->vm_ops = &gntdev_vmops;
>>  
>> -   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
>> +   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP /*| VM_IO*/;
>>  
>> if (use_ptemod)
>> vma->vm_flags |= VM_DONTCOPY;
> I think we need a custom policy for this VMA with MPOL_F_MOF cleared.

I think you are right, I remember when I was looking at this adding a
policy was the other option. Let me look at this again.


-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/cpuid: Deal with broken firmware once more

[Boris Ostrovsky]

On 11/10/2016 12:13 PM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
>> On 11/10/2016 10:12 AM, Thomas Gleixner wrote:
>>> On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
 By firmware you mean ACPI? It is most likely not available to PV guests.
>>> You either have to provide ACPI or MP tables. And either of those has to
>>> provide the intial APIC ids for the CPUs. They are supposed to match the
>>> IDs which are in the CPUID leafs.
>>>
 How about returning cpu_data(cpu).initial_apicid?
>>> For a not yet brought up CPU. That's what the initial ACPI/MP table
>>> enumeration is for.
>> Unfortunately PV guests have neither. So we may need to emulate
>> something in xen_cpu_present_to_apicid().
> SFI does the same thing and according to the dmesg which was posted, this
> is using SFI. We also have devicetree based boot concept which provides the
> APICids in the CPU enumeration at boot time in a way which the whole x86
> machinery is expecting.
>
> So what kind of APICid is XEN handing in via SFI? None, or just an invalid
> one?

None, SFI is not used at all. Or device tree for that matter.

The (PV) guest currently assumes APIC ID (i.e. APIC[0x20]) to always be
zero (we just fixed a bug where CPUID may return an
inconsistent/non-zero initial APIC ID value, but that's a different
issue I think). There is no topology, really, everything is flat.

So this obviously is rather, ahem, fragile and we've been fixing bugs
there, especially with introduction of package map (a6a198bc60e6 that I
mentioned in the other message is one such example). There is work
scheduled on the hypervisor side to properly report initial APIC IDs in
CPUID and that may help with correctly dealing with this on Linux side.

(Longer term we would like to move to PVH where we will have "true" APIC
emulation, with ACPI, just like in HVM guests. You can do your part by
helping: http://marc.info/?l=linux-kernel&m=147791731414152&w=3  ;-))


-boris





___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

[David Vrabel]

On 10/11/16 17:47, Olaf Hering wrote:
> On Thu, Nov 10, Boris Ostrovsky wrote:
> 
>> Are you sure it's this patch that causes the failure?
>>
>> I commented out '| VM_IO' and still unable to boot with this option.
> 
> Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based:
> 
> +++ b/drivers/xen/gntdev.c
> @@ -804,7 +804,7 @@ static int gntdev_mmap(struct file *flip, struct 
> vm_area_struct *vma)
>  
> vma->vm_ops = &gntdev_vmops;
>  
> -   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
> +   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP /*| VM_IO*/;
>  
> if (use_ptemod)
> vma->vm_flags |= VM_DONTCOPY;

I think we need a custom policy for this VMA with MPOL_F_MOF cleared.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

[Olaf Hering]

On Thu, Nov 10, Boris Ostrovsky wrote:

> Are you sure it's this patch that causes the failure?
> 
> I commented out '| VM_IO' and still unable to boot with this option.

Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based:

+++ b/drivers/xen/gntdev.c
@@ -804,7 +804,7 @@ static int gntdev_mmap(struct file *flip, struct 
vm_area_struct *vma)
 
vma->vm_ops = &gntdev_vmops;
 
-   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
+   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP /*| VM_IO*/;
 
if (use_ptemod)
vma->vm_flags |= VM_DONTCOPY;

with this domU.cfg:

name="x"
memory=1024
serial="pty"
builder="hvm"
disk=[ 'vdev=xvda, direct-io-safe, backendtype=qdisk, target=x.raw', ]
vif=[ 'bridge=br0' ]
keymap="de"
cmdline="linemode=1 console=ttyS0,115200 ignore_loglevel 
install=http://host/sles_dvd1/ start_shell"
kernel= "/sles_dvd1/boot/x86_64/vmlinuz-xen"
ramdisk="/sles_dvd1/boot/x86_64/initrd-xen"


Without VM_IO 'fdisk -l /dev/xvda' works, with VM_IO 'fdisk -l
/dev/xvda' gives IO errors.

Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

[Boris Ostrovsky]

On 11/10/2016 11:42 AM, Olaf Hering wrote:
> On Thu, Nov 10, Boris Ostrovsky wrote:
>
>> Is this something new? Because this patch has been there for a year.
> It was just tested now, cycling through all the combinations for a
> disk=[]. Removing "direct-is-save" will use different code paths and the
> error is not seen.

Are you sure it's this patch that causes the failure?

I commented out '| VM_IO' and still unable to boot with this option.

-boris



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 06/24] ARM: GICv3 ITS: introduce host LPI array

[Andre Przywara]

Hi,

On 27/10/16 23:59, Stefano Stabellini wrote:
> On Wed, 28 Sep 2016, Andre Przywara wrote:
>> The number of LPIs on a host can be potentially huge (millions),
>> although in practise will be mostly reasonable. So prematurely allocating
>> an array of struct irq_desc's for each LPI is not an option.
>> However Xen itself does not care about LPIs, as every LPI will be injected
>> into a guest (Dom0 for now).
>> Create a dense data structure (8 Bytes) for each LPI which holds just
>> enough information to determine the virtual IRQ number and the VCPU into
>> which the LPI needs to be injected.
>> Also to not artificially limit the number of LPIs, we create a 2-level
>> table for holding those structures.
>> This patch introduces functions to initialize these tables and to
>> create, lookup and destroy entries for a given LPI.
>> We allocate and access LPI information in a way that does not require
>> a lock.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-its.c| 154 
>> ++
>>  xen/include/asm-arm/gic-its.h |  18 +
>>  2 files changed, 172 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
>> index 88397bc..2140e4a 100644
>> --- a/xen/arch/arm/gic-its.c
>> +++ b/xen/arch/arm/gic-its.c
>> @@ -18,18 +18,31 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  
>> +/* LPIs on the host always go to a guest, so no struct irq_desc for them. */
>> +union host_lpi {
>> +uint64_t data;
>> +struct {
>> +uint64_t virt_lpi:32;
>> +uint64_t dom_id:16;
>> +uint64_t vcpu_id:16;
>> +};
>> +};
> 
> Why not the following?
> 
>   union host_lpi {
>   uint64_t data;
>   struct {
>   uint32_t virt_lpi;
>   uint16_t dom_id;
>   uint16_t vcpu_id;
>   };
>   };

I am not sure that gives me a guarantee of stuffing everything into a
u64 (as per the C standard). It probably will on arm64 with gcc, but I
thought better safe than sorry.

>>  /* Global state */
>>  static struct {
>>  uint8_t *lpi_property;
>> +union host_lpi **host_lpis;
>>  int host_lpi_bits;
>>  } lpi_data;
>>  
>> @@ -43,6 +56,26 @@ static DEFINE_PER_CPU(void *, pending_table);
>>  #define MAX_HOST_LPI_BITS\
>>  min_t(unsigned int, lpi_data.host_lpi_bits, CONFIG_HOST_LPI_BITS)
>>  #define MAX_HOST_LPIS   (BIT(MAX_HOST_LPI_BITS) - 8192)
>> +#define HOST_LPIS_PER_PAGE  (PAGE_SIZE / sizeof(union host_lpi))
>> +
>> +static union host_lpi *gic_find_host_lpi(uint32_t lpi, struct domain *d)
> 
> I take "lpi" is the physical lpi here. Maybe we would rename it to "plpi"
> for clarity.

Indeed.

> 
>> +{
>> +union host_lpi *hlpi;
>> +
>> +if ( lpi < 8192 || lpi >= MAX_HOST_LPIS + 8192 )
>> +return NULL;
>> +
>> +lpi -= 8192;
>> +if ( !lpi_data.host_lpis[lpi / HOST_LPIS_PER_PAGE] )
>> +return NULL;
>> +
>> +hlpi = &lpi_data.host_lpis[lpi / HOST_LPIS_PER_PAGE][lpi % 
>> HOST_LPIS_PER_PAGE];
> 
> I realize I am sometimes obsessive about this, but division operations
> are expensive and this is on the hot path, so I would do:
> 
> #define HOST_LPIS_PER_PAGE  (PAGE_SIZE >> 3)

to replace
#define HOST_LPIS_PER_PAGE  (PAGE_SIZE / sizeof(union host_lpi))?

This should be computed by the compiler, as it's constant.

> unsigned int table = lpi / HOST_LPIS_PER_PAGE;

So I'd rather replace this by ">> (PAGE_SIZE - 3)".
But again the compiler would do this for us, as replacing "constant
divisions by power-of-two" with "right shifts" are a text book example
of easy optimization, if I remember this compiler class at uni correctly ;-)

> then use table throughout this function.

I see your point (though this is ARMv8, which always has udiv).
But to prove your paranoia wrong: I don't see any divisions in the
disassembly, but a lsr #3 and a lsr #9 and various other clever and
cheap ARMv8 instructions ;-)
Compilers have really come a long way in 2016 ...

> 
>> +if ( d && hlpi->dom_id != d->domain_id )
>> +return NULL;
> 
> I think this function is very useful so I would avoid making any domain
> checks here: one day we might want to retrieve hlpi even if hlpi->dom_id
> != d->domain_id. I would move the domain check outside.

That's why I have "d && ..." in front. If you pass in NULL for the
domain, it will skip this check. That saves us from coding the check in
every caller.
Is that not good enough?

> 
>> +return hlpi;
>> +}
>>  
>>  #define ITS_COMMAND_SIZE32
>>  
>> @@ -96,6 +129,33 @@ static int its_send_cmd_sync(struct host_its *its, int 
>> cpu)
>>  return its_send_command(its, cmd);
>>  }
>>  
>> +static int its_send_cmd_discard(struct host_its *its,
>> +uint32_t deviceid, uint32_t eventid)
>> +{
>> +uint64_t cmd[4];

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

[Konrad Rzeszutek Wilk]

On Thu, Nov 10, 2016 at 04:20:34PM +0100, Roger Pau Monné wrote:
> On Thu, Nov 10, 2016 at 08:53:05AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 10, 2016 at 11:39:08AM +0100, Roger Pau Monné wrote:
> > > On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
> > > > > In order to improve the mapping of device memory areas, Xen will have 
> > > > > to
> > > > > know of those devices in advance (before Dom0 tries to interact with 
> > > > > them)
> > > > > so that the memory BARs will be properly mapped into Dom0 memory map.
> > > > 
> > > > Oh, that is going to be a problem with SR-IOV. Those are created _after_
> > > > dom0 has booted. In fact they are done by the drivers themselves.
> > > > 
> > > > See xen_add_device in drivers/xen/pci.c how this is handled.
> > > 
> > > Is the process of creating those VF something standart? (In the sense 
> > > that 
> > > it can be detected by Xen, and proper mappings stablished)
> > 
> > Yes and no.
> > 
> > You can read from the PCI configuration that the device (Physical
> > function) has SR-IOV. But that information may be in the extended
> > configuration registers so you need MCFG. Anyhow the only thing the PF
> > will tell you is the BAR regions they will occupy (since they
> > are behind the bridge) but not the BDFs:
> 
> But just knowing the BARs position is enough for Xen to install the identity 
> mappings AFAICT?
> 
> Or are the more BARs that will only appear after the SR-IOV functionality 
> has been enabled?
> 
> >From the documentation that I've found, if you detect that the device has 
> PCI_EXT_CAP_ID_SRIOV, you can then read the BARs and map them into Dom0, but 
> maybe I'm missing something (and I have not been able to test this, although 
> my previous PVHv2 Dom0 series already contained code in order to perform 
> this):
> 
> http://xenbits.xen.org/gitweb/?p=people/royger/xen.git;a=commit;h=260cfd1e96e56ab4b58a414d544d92a77e210050
> 
> > Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
> > IOVCap: Migration-, Interrupt Message Number: 000
> > IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy+
> > IOVSta: Migration-
> > Initial VFs: 8, Total VFs: 8, Number of VFs: 0, Function 
> > Dependency Link: 00
> > VF offset: 128, stride: 2, Device ID: 10ca
> > Supported Page Size: 0553, System Page Size: 0001
> > Region 0: Memory at fbda (64-bit, 
> > non-prefetchable)
> > Region 3: Memory at fbd8 (64-bit, 
> > non-prefetchable)
> > VF Migration: offset: , BIR: 0
> > Kernel driver in use: igb
> > 
> > And if I enable SR-IOV on the PF I get:
> > 
> > 0a:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network 
> > Connection (rev 01)
> > 0a:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 
> > 01)
> > 0a:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 
> > 01)
> > 0a:10.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 
> > 01)
> > 0a:10.6 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 
> > 01)
> > 0a:11.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 
> > 01)
> > 0a:11.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 
> > 01)
> > 0a:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 
> > 01)
> > 
> > -bash-4.1# lspci -s 0a:10.0 -v
> > 0a:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function
> > (rev 01)
> > Subsystem: Super Micro Computer Inc Device 10c9
> > Flags: bus master, fast devsel, latency 0
> > [virtual] Memory at fbda (64-bit, non-prefetchable) [size=16K]
> > [virtual] Memory at fbd8 (64-bit, non-prefetchable) [size=16K]
> > Capabilities: [70] MSI-X: Enable+ Count=3 Masked-
> > Capabilities: [a0] Express Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
> > Kernel driver in use: igbvf
> > 
> > -bash-4.1# lspci -s 0a:11.4 -v
> > 0a:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function
> > (rev 01)
> > Subsystem: Super Micro Computer Inc Device 10c9
> > Flags: bus master, fast devsel, latency 0
> > [virtual] Memory at fbdb8000 (64-bit, non-prefetchable) [size=16K]
> > [virtual] Memory at fbd98000 (64-bit, non-prefetchable) [size=16K]
> > Capabilities: [70] MSI-X: Enable+ Count=3 Masked-
> > Capabilities: [a0] Express Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
> > Kernel driver in use: igbvf
> 
> So it seems that the memory for individual

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

[Konrad Rzeszutek Wilk]

On Thu, Nov 10, 2016 at 09:37:19AM -0700, Jan Beulich wrote:
> >>> On 10.11.16 at 11:39,  wrote:
> > On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
> >> > PCI memory BARs
> >> > ---
> >> > 
> >> > PCI devices discovered by Xen will have it's BARs scanned in order to 
> >> > detect
> >> > memory BARs, and those will be identity mapped to Dom0. Since BARs can be
> >> > freely moved by the Dom0 OS by writing to the appropriate PCI config 
> >> > space
> >> > register, Xen must trap those accesses and unmap the previous region and
> >> > map the new one as set by Dom0.
> >> 
> >> You can make that simpler - we have hypercalls to "notify" in Linux
> >> when a device is changing. Those can provide that information as well.
> >> (This is what PV dom0 does).
> >> 
> >> Also you are missing one important part - the MMCFG. That is required
> >> for Xen to be able to poke at the PCI configuration spaces (above the 256).
> >> And you can only get the MMCFG if the ACPI DSDT has been parsed.
> > 
> > Hm, I guess I'm missing something, but at least on my hardware Xen seems to 
> > be able to parse the MCFG ACPI table before Dom0 does anything with the 
> > DSDT:
> > 
> > (XEN) PCI: MCFG configuration 0: base f800 segment  buses 00 - 3f
> > (XEN) PCI: MCFG area at f800 reserved in E820
> 
> This is the crucial line: To guard against broken firmware, we - just
> like Linux - require that the area be reserved in at least one of E820
> or ACPI resources. We can check E820 ourselves, but we need
> Dom0's AML parser for the other mechanism.

And in fact I do have such box!

When it boots:
(XEN) PCI: MCFG configuration 0: base e000 segment  buses 00 - 3f^M^M
(XEN) PCI: Not using MCFG for segment  bus 00-3f^M^M

.. and then later:

[3.880750] NetLabel:  unlabeled traffic allowed by default^M^M^M
(XEN) PCI: Using MCFG for segment  bus 00-3f^M^M

(when it gets the hypercall)
This is Intel DQ67SW  with SWQ6710H.86A.0066.2012.1105.1504 BIOS

It is an SandyBridge motherboard.
> 
> >> So if you do the PCI bus scanning _before_ booting PVH dom0, you may
> >> need to update your view of PCI devices after the MMCFG locations
> >> have been provided to you.
> > 
> > I'm not opposed to keep the PHYSDEVOP_pci_mmcfg_reserved, but I still have 
> > to see hardware where this is actually needed. Also, AFAICT, FreeBSD at 

Here is the spec:
ttp://ark.intel.com/products/51997/Intel-Desktop-Board-DQ67SW


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/cpuid: Deal with broken firmware once more

[Thomas Gleixner]

On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
> On 11/10/2016 10:12 AM, Thomas Gleixner wrote:
> > On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
> >> By firmware you mean ACPI? It is most likely not available to PV guests.
> > You either have to provide ACPI or MP tables. And either of those has to
> > provide the intial APIC ids for the CPUs. They are supposed to match the
> > IDs which are in the CPUID leafs.
> >
> >> How about returning cpu_data(cpu).initial_apicid?
> > For a not yet brought up CPU. That's what the initial ACPI/MP table
> > enumeration is for.
> 
> Unfortunately PV guests have neither. So we may need to emulate
> something in xen_cpu_present_to_apicid().

SFI does the same thing and according to the dmesg which was posted, this
is using SFI. We also have devicetree based boot concept which provides the
APICids in the CPU enumeration at boot time in a way which the whole x86
machinery is expecting.

So what kind of APICid is XEN handing in via SFI? None, or just an invalid
one?

Thanks,

tglx

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf baseline-only test] 68021: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68021 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68021/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf c3c9892c3b4dafd1d0ccdc8e5e017d80e8c4361e
baseline version:
 ovmf 008e2ccf02e7be65b3a1b48a925f005115027d1c

Last test of basis68019  2016-11-09 10:17:59 Z1 days
Testing same since68021  2016-11-09 17:16:38 Z0 days1 attempts


People who touched revisions under test:
  Eric Dong 
  Feng Tian 
  Hao Wu 
  Jeff Fan 
  Laszlo Ersek 

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.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 c3c9892c3b4dafd1d0ccdc8e5e017d80e8c4361e
Author: Eric Dong 
Date:   Thu Oct 27 14:17:54 2016 +0800

MdePkg UefiDevicePathLib: Validate before touch input buffer.

Current code not validate the input buffer before touch.
it may touch the buffer outside the validate scope. This
patch validate the input size big enough to touch the
first node.

Cc: Ruiyu NI 
Reviewed-by: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 

commit fb9405f9583a6ecf2048cdcc2e8d5621a3e68c75
Author: Eric Dong 
Date:   Thu Oct 27 14:16:53 2016 +0800

MdePkg UefiDevicePathLib: Rollback former change.

Former patch still has some bugs, so rollback it and
enhance the original code.

Cc: Ruiyu NI 
Reviewed-by: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 

commit c0cba3d5ddec83e2bf09deb01a25140a71f8b7e6
Author: Eric Dong 
Date:   Thu Oct 27 11:08:37 2016 +0800

MdePkg DevicePathLib: Validate before touch input buffer.

Current code not validate the input buffer before touch.
it may touch the buffer outside the validate scope. This
patch validate the input size big enough to touch the
first node.

Cc: Ruiyu NI 
Reviewed-by: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 

commit 1420143f014a4c14bd7cb430aaacd6b2c4bc8043
Author: Eric Dong 
Date:   Thu Oct 27 11:05:51 2016 +0800

MdePkg DevicePathLib: Rollback former change.

Former patch still has some bugs, so rollback it and
enhance the original code.

Cc: Ruiyu NI 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
Reviewed-by: Jiewen Yao 

commit 49d8f534cc4280fa3f393dec5093b23b0c759c2c
Author: Hao Wu 
Date:   Wed Nov 9 12:06:29 2016 +0800

BaseTools/PeCoffLib: Check 'RelocDir' before finding relocation block

To match the code logics in MdePkg/Library/BasePeCoffLib, add checks for
'RelocDir' before finding the relocation block.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Liming Gao 

commit 14e8137c8223f6d78135af6180b5e3145351da17
Author: Jeff Fan 
Date:   Fri Nov 4 15:45:13 2016 +0800

UefiCpuPkg/MpInitLib: Do not wakeup AP if only one processor supported

If MaxLogicalProcessorNumber is only 1, we needn't to wake up APs at all
and needn't to register callback functions.

It could improve boot performance on single supported system.

https://bugzilla.tianocore.org/show_bug.cgi?id=204

Cc: Feng Tian 
Cc: Liming Gao 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
Acked-by: Laszlo Ersek 
Reviewed-by: Feng Tian 

commit b028c1021cdfbfaa0202711f2a008c801752917f
Author: Jeff Fan 
Date:   Fri Nov 4 10:01:21 2016 +0800

MdeModulePkg/DxeIplPeim: UINTN used wrongly for EFI_PHYSICAL_ADDRESS

PeiServicesAllocatePages ()

[Xen-devel] [PATCH v2] libxl: fix gentypes call in Makefile

[Cédric Bosdonnat]

From the make documentation:

"$* [...] If the target is `dir/a.foo.b' and the target pattern is
`a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
stem is part of the file name that matched the `%' in the target
pattern."

The rule generating the c types files from the idl ones is not
a static pattern rule, but rather an implicit rule. Thus the value
of $* is preceded by the file path, instead of only what matches %.

In order to get this fixed, drop the path using a $(notdir $*).

Signed-off-by: Cédric Bosdonnat 
---
  v2: use $(notdir $*) instead of $(shell basename $*)
---
 tools/libxl/Makefile | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index af0a3ad..4dbaa98 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -250,12 +250,13 @@ $(LIBXL_OBJS) $(LIBXL_TEST_OBJS) $(LIBXLU_OBJS) \
 $(LIBXL_OBJS) $(LIBXL_TEST_OBJS): libxl_internal.h
 
 _libxl_type%.h _libxl_type%_json.h _libxl_type%_private.h _libxl_type%.c: 
libxl_type%.idl gentypes.py idl.py
-   $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h 
__libxl_type$*_private.h \
-   __libxl_type$*_json.h  __libxl_type$*.c
-   $(call move-if-changed,__libxl_type$*.h,_libxl_type$*.h)
-   $(call move-if-changed,__libxl_type$*_private.h,_libxl_type$*_private.h)
-   $(call move-if-changed,__libxl_type$*_json.h,_libxl_type$*_json.h)
-   $(call move-if-changed,__libxl_type$*.c,_libxl_type$*.c)
+   $(eval stem = $(notdir $*))
+   $(PYTHON) gentypes.py libxl_type$(stem).idl __libxl_type$(stem).h 
__libxl_type$(stem)_private.h \
+   __libxl_type$(stem)_json.h  __libxl_type$(stem).c
+   $(call move-if-changed,__libxl_type$(stem).h,_libxl_type$(stem).h)
+   $(call 
move-if-changed,__libxl_type$(stem)_private.h,_libxl_type$(stem)_private.h)
+   $(call 
move-if-changed,__libxl_type$(stem)_json.h,_libxl_type$(stem)_json.h)
+   $(call move-if-changed,__libxl_type$(stem).c,_libxl_type$(stem).c)
 
 libxenlight.so: libxenlight.so.$(MAJOR)
$(SYMLINK_SHLIB) $< $@
-- 
2.10.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

[Olaf Hering]

On Thu, Nov 10, Boris Ostrovsky wrote:

> Is this something new? Because this patch has been there for a year.

It was just tested now, cycling through all the combinations for a
disk=[]. Removing "direct-is-save" will use different code paths and the
error is not seen.

Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

[Jan Beulich]

>>> On 10.11.16 at 11:39,  wrote:
> On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
>> > PCI memory BARs
>> > ---
>> > 
>> > PCI devices discovered by Xen will have it's BARs scanned in order to 
>> > detect
>> > memory BARs, and those will be identity mapped to Dom0. Since BARs can be
>> > freely moved by the Dom0 OS by writing to the appropriate PCI config space
>> > register, Xen must trap those accesses and unmap the previous region and
>> > map the new one as set by Dom0.
>> 
>> You can make that simpler - we have hypercalls to "notify" in Linux
>> when a device is changing. Those can provide that information as well.
>> (This is what PV dom0 does).
>> 
>> Also you are missing one important part - the MMCFG. That is required
>> for Xen to be able to poke at the PCI configuration spaces (above the 256).
>> And you can only get the MMCFG if the ACPI DSDT has been parsed.
> 
> Hm, I guess I'm missing something, but at least on my hardware Xen seems to 
> be able to parse the MCFG ACPI table before Dom0 does anything with the 
> DSDT:
> 
> (XEN) PCI: MCFG configuration 0: base f800 segment  buses 00 - 3f
> (XEN) PCI: MCFG area at f800 reserved in E820

This is the crucial line: To guard against broken firmware, we - just
like Linux - require that the area be reserved in at least one of E820
or ACPI resources. We can check E820 ourselves, but we need
Dom0's AML parser for the other mechanism.

>> So if you do the PCI bus scanning _before_ booting PVH dom0, you may
>> need to update your view of PCI devices after the MMCFG locations
>> have been provided to you.
> 
> I'm not opposed to keep the PHYSDEVOP_pci_mmcfg_reserved, but I still have 
> to see hardware where this is actually needed. Also, AFAICT, FreeBSD at 
> least is only able to detect MMCFG regions present in the MCFG ACPI table:
> 
> http://fxr.watson.org/fxr/source/dev/acpica/acpi.c?im=excerp#L1861 

Iirc the spec mandates only segment 0 to be represented in the
static table. Other segments may (and likely will) only have their
data available in AML.

>> > XXX: is it possible to have more than 256 GSIs?
>> 
>> Yeah. If you have enough of the IOAPICs you can have more than 256. But
>> I don't think any OS has taken that into account as the GSI value are
>> always uint8_t.
> 
> Right, so AFAICT providing a single IO APIC with enough pins should be fine.

No, let's not even start with such an approach. Having seen (not really
huge) systems with well beyond 100 GSIs, I don't think it makes sense
to try to (temporarily) ease our lives slightly by introducing an
implementation limit here.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

[Boris Ostrovsky]

On 11/10/2016 11:26 AM, Olaf Hering wrote:
> On Tue, Nov 10, Boris Ostrovsky wrote:

Perfect timing. This is from Nov. 10 2015.

>
>> Doing so will cause the grant to be unmapped and then, during
>> fault handling, the fault to be mistakenly treated as NUMA hint
>> fault.
>>
>> In addition, even if those maps could partcipate in NUMA
>> balancing, it wouldn't provide any benefit since we are unable
>> to determine physical page's node (even if/when VNUMA is
>> implemented).
>>
>> Marking grant maps' VMAs as VM_IO will exclude them from being
>> part of NUMA balancing.
> This breaks qdisk+aio because now such pages are rejected with -EFAULT:

Is this something new? Because this patch has been there for a year.

-boris

>
> check_vma_flags
> __get_user_pages
> __get_user_pages_locked
> __get_user_pages_unlocked
> get_user_pages_fast
> iov_iter_get_pages
> dio_refill_pages
> do_direct_IO
> do_blockdev_direct_IO
> do_blockdev_direct_IO
> ext4_direct_IO_read
> generic_file_read_iter
> aio_run_iocb
>
> domU.cfg:
> builder=hvm
> disk=['vdev=xvda, direct-io-safe, backendtype=qdisk, target=img.raw']
>
>> @@ -802,7 +802,7 @@ static int gntdev_mmap(struct file *flip, struct 
>> vm_area_struct *vma)
>> -vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
>> +vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
>
> Olaf




signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

[Olaf Hering]

On Tue, Nov 10, Boris Ostrovsky wrote:

> Doing so will cause the grant to be unmapped and then, during
> fault handling, the fault to be mistakenly treated as NUMA hint
> fault.
> 
> In addition, even if those maps could partcipate in NUMA
> balancing, it wouldn't provide any benefit since we are unable
> to determine physical page's node (even if/when VNUMA is
> implemented).
> 
> Marking grant maps' VMAs as VM_IO will exclude them from being
> part of NUMA balancing.

This breaks qdisk+aio because now such pages are rejected with -EFAULT:

check_vma_flags
__get_user_pages
__get_user_pages_locked
__get_user_pages_unlocked
get_user_pages_fast
iov_iter_get_pages
dio_refill_pages
do_direct_IO
do_blockdev_direct_IO
do_blockdev_direct_IO
ext4_direct_IO_read
generic_file_read_iter
aio_run_iocb

domU.cfg:
builder=hvm
disk=['vdev=xvda, direct-io-safe, backendtype=qdisk, target=img.raw']

> @@ -802,7 +802,7 @@ static int gntdev_mmap(struct file *flip, struct 
> vm_area_struct *vma)
> - vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
> + vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_IO;


Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] libxc/x86: Report consistent initial APIC value for PV guests

[Andrew Cooper]

On 10/11/16 16:24, Boris Ostrovsky wrote:
> On 11/10/2016 11:12 AM, Jan Beulich wrote:
> On 10.11.16 at 15:55,  wrote:
>>> On 10/11/16 14:50, Boris Ostrovsky wrote:
 Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
 APIC ID) with contents of that field on the processor that launched
 the guest. This results in the guest reporting different initial
 APIC IDs across runs.

 We should be consistent in how this value is reported, let's set
 it to 0 (which is also what Linux guests expect).

 Signed-off-by: Boris Ostrovsky 
>>> This surely wants to go along with:
>>>
>>> andrewcoop@andrewcoop:/local/xen.git/xen$ git diff
>>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>>> index b51b51b..bdf9339 100644
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -985,6 +985,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
>>>  uint32_t tmp, _ecx, _ebx;
>>>  
>>>  case 0x0001:
>>> +/* Fix up VLAPIC details. */
>>> +b &= 0x00FFu;
>>> +b |= (curr->vcpu_id * 2) << 24;
>>> +
>>>  c &= pv_featureset[FEATURESET_1c];
>>>  d &= pv_featureset[FEATURESET_1d];
>>>  
>>>
>>> Which brings the PV CPUID handling in line with HVM handling.  Otherwise
>>> a guest will see an APIC ID of 0 in all vcpus, which will surely confuse it.
>> Which will still result in multiple identical APIC IDs once there are
>> 128 or more vCPU-s in a PV guest.

You can already crash Xen with fewer PV vcpus than that, due to long
running for_each_vcpu() loops.

The current ABI limit of 8192 is implausible for production, as is the
current 128 limit for HVM guests.

>
> And this change (either with or without *2) makes Linux PV problem of
> mismatched APIC[0x20] vs CPUID(1).EBX[31:24] to be back (yes, because
> Linux is broken in that it currently makes APIC[0x20] return zero).
>
> You'd obviously be within your rights to say that it's up to Linux to
> deal with this but I will ask you to consider taking only the toolstack
> part of this for now.

If the toolstack along is sufficient duct tape, perhaps best to go with
just that for now.

I will have to change all of this for CPUID phase-2.  We can see about
fixing things more correctly then.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] libxc/x86: Report consistent initial APIC value for PV guests

[Boris Ostrovsky]

On 11/10/2016 11:12 AM, Jan Beulich wrote:
 On 10.11.16 at 15:55,  wrote:
>> On 10/11/16 14:50, Boris Ostrovsky wrote:
>>> Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
>>> APIC ID) with contents of that field on the processor that launched
>>> the guest. This results in the guest reporting different initial
>>> APIC IDs across runs.
>>>
>>> We should be consistent in how this value is reported, let's set
>>> it to 0 (which is also what Linux guests expect).
>>>
>>> Signed-off-by: Boris Ostrovsky 
>> This surely wants to go along with:
>>
>> andrewcoop@andrewcoop:/local/xen.git/xen$ git diff
>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>> index b51b51b..bdf9339 100644
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -985,6 +985,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
>>  uint32_t tmp, _ecx, _ebx;
>>  
>>  case 0x0001:
>> +/* Fix up VLAPIC details. */
>> +b &= 0x00FFu;
>> +b |= (curr->vcpu_id * 2) << 24;
>> +
>>  c &= pv_featureset[FEATURESET_1c];
>>  d &= pv_featureset[FEATURESET_1d];
>>  
>>
>> Which brings the PV CPUID handling in line with HVM handling.  Otherwise
>> a guest will see an APIC ID of 0 in all vcpus, which will surely confuse it.
> Which will still result in multiple identical APIC IDs once there are
> 128 or more vCPU-s in a PV guest.


And this change (either with or without *2) makes Linux PV problem of
mismatched APIC[0x20] vs CPUID(1).EBX[31:24] to be back (yes, because
Linux is broken in that it currently makes APIC[0x20] return zero).

You'd obviously be within your rights to say that it's up to Linux to
deal with this but I will ask you to consider taking only the toolstack
part of this for now.


-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Razvan Cojocaru]

On 11/10/2016 06:01 PM, Tamas K Lengyel wrote:
> 
> 
> On Thu, Nov 10, 2016 at 6:33 AM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
> 
> Hello Tamas, thanks for the review!
> 
> On 11/10/2016 03:11 PM, Tamas K Lengyel wrote:
> > diff --git a/xen/include/asm-x86/vm_event.h
> > b/xen/include/asm-x86/vm_event.h
> > index ca73f99..38c624c 100644
> > --- a/xen/include/asm-x86/vm_event.h
> > +++ b/xen/include/asm-x86/vm_event.h
> > @@ -27,6 +27,7 @@
> >   */
> >  struct arch_vm_event {
> >  uint32_t emulate_flags;
> > +bool monitor_next_interrupt;
> >
> >
> > This should be in domain.h with the rest of the monitor control bits (as
> > the name of the variable suggests as well).
> 
> Unfortunately that would alter the semantics of the patch, as this
> variable needs to be per-VCPU. Putting it in domain.h as you suggest
> would make it per-domain. Looking at places to put it so that it would
> serve this purpose, struct arch_vm_event felt like the most natural
> place.
> 
> 
> I see. I generally like to keep vm_event/monitor bits separate as to not
> end up in the spaghetti we were in a couple years ago. Maybe introducing
> a struct arch_monitor would be appropriate?

I've actually done this, to reflect the per-domain monitor bitfield:

diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index f6a40eb..faa7037 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -576,6 +576,10 @@ struct arch_vcpu
 XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;

 struct arch_vm_event *vm_event;
+
+struct {
+unsigned int next_interrupt_enabled : 1;
+} monitor;
 };

 smap_check_policy_t smap_policy_change(struct vcpu *v,

This is now accesible via v->arch.monitor.next_interrupt_enabled and
does indeed feel much cleaner (plus it removes the need for an ASSERT()
or if() that Jan has previously commented on). This will be extensible
in the future for whatever per-VCPU events we may want to add.

Is this OK?


Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxl: fix gentypes call in Makefile

[Juergen Gross]

On 10/11/16 17:14, Cedric Bosdonnat wrote:
> On Thu, 2016-11-10 at 15:49 +0100, Juergen Gross wrote:
>> On 10/11/16 14:11, Cédric Bosdonnat wrote:
>>> From the make documentation:
>>>
>>> "$* [...] If the target is `dir/a.foo.b' and the target pattern is
>>> `a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
>>> stem is part of the file name that matched the `%' in the target
>>> pattern."
>>>
>>> The rule generating the c types files from the idl ones is not
>>> a static pattern rule, but rather an implicit rule. Thus the value
>>> of $* is preceded by the file path, instead of only what matches %.
>>>
>>> In order to get this fixed, drop the path using a $(shell basename $*).
>>
>> Why not $(notdir $*) ?
> 
> Just because I wasn't aware of it. But of course, I can change to it:
> it's surely a more portable solution

And it spares two processes.


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxl: fix gentypes call in Makefile

[Cedric Bosdonnat]

On Thu, 2016-11-10 at 15:49 +0100, Juergen Gross wrote:
> On 10/11/16 14:11, Cédric Bosdonnat wrote:
> > From the make documentation:
> > 
> > "$* [...] If the target is `dir/a.foo.b' and the target pattern is
> > `a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
> > stem is part of the file name that matched the `%' in the target
> > pattern."
> > 
> > The rule generating the c types files from the idl ones is not
> > a static pattern rule, but rather an implicit rule. Thus the value
> > of $* is preceded by the file path, instead of only what matches %.
> > 
> > In order to get this fixed, drop the path using a $(shell basename $*).
> 
> Why not $(notdir $*) ?

Just because I wasn't aware of it. But of course, I can change to it:
it's surely a more portable solution

--
Cedric

> 
> Juergen
> 
> > 
> > Signed-off-by: Cédric Bosdonnat 
> > ---
> >  tools/libxl/Makefile | 13 +++--
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> > 
> > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> > index af0a3ad..78fede3 100644
> > --- a/tools/libxl/Makefile
> > +++ b/tools/libxl/Makefile
> > @@ -250,12 +250,13 @@ $(LIBXL_OBJS) $(LIBXL_TEST_OBJS) $(LIBXLU_OBJS) \
> >  $(LIBXL_OBJS) $(LIBXL_TEST_OBJS): libxl_internal.h
> >  
> >  _libxl_type%.h _libxl_type%_json.h _libxl_type%_private.h _libxl_type%.c: 
> > libxl_type%.idl gentypes.py idl.py
> > -   $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h 
> > __libxl_type$*_private.h \
> > -   __libxl_type$*_json.h  __libxl_type$*.c
> > -   $(call move-if-changed,__libxl_type$*.h,_libxl_type$*.h)
> > -   $(call move-if-changed,__libxl_type$*_private.h,_libxl_type$*_private.h)
> > -   $(call move-if-changed,__libxl_type$*_json.h,_libxl_type$*_json.h)
> > -   $(call move-if-changed,__libxl_type$*.c,_libxl_type$*.c)
> > +   $(eval stem = $(shell basename $*))
> > +   $(PYTHON) gentypes.py libxl_type$(stem).idl __libxl_type$(stem).h 
> > __libxl_type$(stem)_private.h \
> > +   __libxl_type$(stem)_json.h  __libxl_type$(stem).c
> > +   $(call move-if-changed,__libxl_type$(stem).h,_libxl_type$(stem).h)
> > +   $(call 
> > move-if-changed,__libxl_type$(stem)_private.h,_libxl_type$(stem)_private.h)
> > +   $(call 
> > move-if-changed,__libxl_type$(stem)_json.h,_libxl_type$(stem)_json.h)
> > +   $(call move-if-changed,__libxl_type$(stem).c,_libxl_type$(stem).c)
> >  
> >  libxenlight.so: libxenlight.so.$(MAJOR)
> >     $(SYMLINK_SHLIB) $< $@
> > 
> 
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] libxc/x86: Report consistent initial APIC value for PV guests

[Jan Beulich]

>>> On 10.11.16 at 15:55,  wrote:
> On 10/11/16 14:50, Boris Ostrovsky wrote:
>> Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
>> APIC ID) with contents of that field on the processor that launched
>> the guest. This results in the guest reporting different initial
>> APIC IDs across runs.
>>
>> We should be consistent in how this value is reported, let's set
>> it to 0 (which is also what Linux guests expect).
>>
>> Signed-off-by: Boris Ostrovsky 
> 
> This surely wants to go along with:
> 
> andrewcoop@andrewcoop:/local/xen.git/xen$ git diff
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index b51b51b..bdf9339 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -985,6 +985,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
>  uint32_t tmp, _ecx, _ebx;
>  
>  case 0x0001:
> +/* Fix up VLAPIC details. */
> +b &= 0x00FFu;
> +b |= (curr->vcpu_id * 2) << 24;
> +
>  c &= pv_featureset[FEATURESET_1c];
>  d &= pv_featureset[FEATURESET_1d];
>  
> 
> Which brings the PV CPUID handling in line with HVM handling.  Otherwise
> a guest will see an APIC ID of 0 in all vcpus, which will surely confuse it.

Which will still result in multiple identical APIC IDs once there are
128 or more vCPU-s in a PV guest.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Razvan Cojocaru]

On 11/10/2016 06:01 PM, Tamas K Lengyel wrote:
> On Thu, Nov 10, 2016 at 6:33 AM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
> 
> Hello Tamas, thanks for the review!
> 
> On 11/10/2016 03:11 PM, Tamas K Lengyel wrote:
> > diff --git a/xen/include/asm-x86/vm_event.h
> > b/xen/include/asm-x86/vm_event.h
> > index ca73f99..38c624c 100644
> > --- a/xen/include/asm-x86/vm_event.h
> > +++ b/xen/include/asm-x86/vm_event.h
> > @@ -27,6 +27,7 @@
> >   */
> >  struct arch_vm_event {
> >  uint32_t emulate_flags;
> > +bool monitor_next_interrupt;
> >
> >
> > This should be in domain.h with the rest of the monitor control bits (as
> > the name of the variable suggests as well).
> 
> Unfortunately that would alter the semantics of the patch, as this
> variable needs to be per-VCPU. Putting it in domain.h as you suggest
> would make it per-domain. Looking at places to put it so that it would
> serve this purpose, struct arch_vm_event felt like the most natural
> place.
> 
> 
> I see. I generally like to keep vm_event/monitor bits separate as to not
> end up in the spaghetti we were in a couple years ago. Maybe introducing
> a struct arch_monitor would be appropriate?

Yes, that's a reasonable request. I'll try that direction.


Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] x86/EFI: meet further spec requirements for runtime calls

[Jan Beulich]

So far we didn't guarantee 16-byte alignment of the stack: While (so
far) we don't tell the compiler to use smaller alignment, we also don't
guarantee 16-byte alignment when establishing stack pointers for new
vCPU-s. Runtime service functions using SSE instructions may end with
#GP(0) without that.

Note that -mpreferred-stack-boundary=3 is can be used only from gcc 4.8
onwards, and -mincoming-stack-boundary=3 only from 5.3 onwards. It is
for that reason that an alternative approach (using higher than
necessary alignment) is being used when building with such older
compilers.

Furthermore we should avoid #MF to be raised on the FLDCW we do.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -14,5 +14,10 @@ extra-$(efi) += boot.init.o relocs-dummy
 %.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
 
+cc-runtime.o := $(CC) -mno-sse
+$(call 
cc-option-add,cflags-runtime.o,cc-runtime.o,-mpreferred-stack-boundary=3)
+$(call cc-option-add,cflags-runtime.o,cc-runtime.o,-mincoming-stack-boundary=3)
+runtime.o: CFLAGS += $(cflags-runtime.o)
+
 stub.o: $(extra-y)
 nogcov-$(efi) += stub.o
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -59,12 +59,26 @@ unsigned long efi_rs_enter(void)
 static const u16 fcw = FCW_DEFAULT;
 static const u32 mxcsr = MXCSR_DEFAULT;
 unsigned long cr3 = read_cr3();
+#if __GNUC__ < 5 || (__GNUC__ == 5 && __GNUC_MINOR__ < 3)
+/*
+ * -mpreferred-stack-boundary=3 is can be used only from gcc 4.8 onwards,
+ * and -mincoming-stack-boundary=3 only from 5.3 onwards. Therefore higher
+ * than necessary alignment is being forced here in that case.
+ */
+# define FORCE_ALIGN 32
+#else
+# define FORCE_ALIGN 16
+#endif
+unsigned long __aligned(FORCE_ALIGN) placeholder[0];
+#undef FORCE_ALIGN
+
+asm volatile("" : "+m" (placeholder));
 
 if ( !efi_l4_pgtable )
 return 0;
 
 save_fpu_enable();
-asm volatile ( "fldcw %0" :: "m" (fcw) );
+asm volatile ( "fnclex; fldcw %0" :: "m" (fcw) );
 asm volatile ( "ldmxcsr %0" :: "m" (mxcsr) );
 
 spin_lock(&efi_rs_lock);



x86/EFI: meet further spec requirements for runtime calls

So far we didn't guarantee 16-byte alignment of the stack: While (so
far) we don't tell the compiler to use smaller alignment, we also don't
guarantee 16-byte alignment when establishing stack pointers for new
vCPU-s. Runtime service functions using SSE instructions may end with
#GP(0) without that.

Note that -mpreferred-stack-boundary=3 is can be used only from gcc 4.8
onwards, and -mincoming-stack-boundary=3 only from 5.3 onwards. It is
for that reason that an alternative approach (using higher than
necessary alignment) is being used when building with such older
compilers.

Furthermore we should avoid #MF to be raised on the FLDCW we do.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -14,5 +14,10 @@ extra-$(efi) += boot.init.o relocs-dummy
 %.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
 
+cc-runtime.o := $(CC) -mno-sse
+$(call 
cc-option-add,cflags-runtime.o,cc-runtime.o,-mpreferred-stack-boundary=3)
+$(call cc-option-add,cflags-runtime.o,cc-runtime.o,-mincoming-stack-boundary=3)
+runtime.o: CFLAGS += $(cflags-runtime.o)
+
 stub.o: $(extra-y)
 nogcov-$(efi) += stub.o
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -59,12 +59,26 @@ unsigned long efi_rs_enter(void)
 static const u16 fcw = FCW_DEFAULT;
 static const u32 mxcsr = MXCSR_DEFAULT;
 unsigned long cr3 = read_cr3();
+#if __GNUC__ < 5 || (__GNUC__ == 5 && __GNUC_MINOR__ < 3)
+/*
+ * -mpreferred-stack-boundary=3 is can be used only from gcc 4.8 onwards,
+ * and -mincoming-stack-boundary=3 only from 5.3 onwards. Therefore higher
+ * than necessary alignment is being forced here in that case.
+ */
+# define FORCE_ALIGN 32
+#else
+# define FORCE_ALIGN 16
+#endif
+unsigned long __aligned(FORCE_ALIGN) placeholder[0];
+#undef FORCE_ALIGN
+
+asm volatile("" : "+m" (placeholder));
 
 if ( !efi_l4_pgtable )
 return 0;
 
 save_fpu_enable();
-asm volatile ( "fldcw %0" :: "m" (fcw) );
+asm volatile ( "fnclex; fldcw %0" :: "m" (fcw) );
 asm volatile ( "ldmxcsr %0" :: "m" (mxcsr) );
 
 spin_lock(&efi_rs_lock);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 04/24] ARM: GICv3 ITS: map ITS command buffer

[Andre Przywara]

Hi,

On 27/10/16 00:03, Stefano Stabellini wrote:
> On Wed, 28 Sep 2016, Andre Przywara wrote:
>> Instead of directly manipulating the tables in memory, an ITS driver
>> sends commands via a ring buffer to the ITS h/w to create or alter the
>> LPI mappings.
>> Allocate memory for that buffer and tell the ITS about it to be able
>> to send ITS commands.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-its.c| 25 +
>>  xen/include/asm-arm/gic-its.h |  1 +
>>  2 files changed, 26 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
>> index 40238a2..c8a7a7e 100644
>> --- a/xen/arch/arm/gic-its.c
>> +++ b/xen/arch/arm/gic-its.c
>> @@ -18,6 +18,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -56,6 +57,26 @@ static uint64_t encode_phys_addr(paddr_t addr, int 
>> page_bits)
>>  return ret | (addr & GENMASK(51, 48)) >> (48 - 12);
>>  }
>>  
>> +static void *gicv3_map_cbaser(void __iomem *cbasereg)
> 
> Shouldn't it be its_map_cbaser?

Yes.

>> +{
>> +uint64_t attr, reg;
>> +void *buffer;
>> +
>> +attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
>> +attr |= GIC_BASER_CACHE_SameAsInner << 
>> GITS_BASER_OUTER_CACHEABILITY_SHIFT;
>> +attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
>> +
>> +buffer = alloc_xenheap_pages(0, 0);
>> +if ( !buffer )
>> +return ERR_PTR(-ENOMEM);
> 
> We haven't use much ERR_PTR on arm so far. In this case I'd just return
> NULL.

In this case I agree, though "we haven't uses it much" isn't really a
good argument ;-)

Cheers,
Andre.

>> +
>> +/* We use exactly one 4K page, so the "Size" field is 0. */
>> +reg = attr | BIT(63) | (virt_to_maddr(buffer) & GENMASK(51, 12));
> 
> Shouldn't the mask be GENMASK(47, 12)? Maybe I have an old spec
> version.
> 
> 
>> +writeq_relaxed(reg, cbasereg);
>> +
>> +return buffer;
>> +}
>> +
>>  static int gicv3_map_baser(void __iomem *basereg, uint64_t regc, int 
>> nr_items)
>>  {
>>  uint64_t attr;
>> @@ -149,6 +170,10 @@ int gicv3_its_init(struct host_its *hw_its)
>>  }
>>  }
>>  
>> +hw_its->cmd_buf = gicv3_map_cbaser(hw_its->its_base + GITS_CBASER);
>> +if ( IS_ERR(hw_its->cmd_buf) )
>> +return PTR_ERR(hw_its->cmd_buf);
>> +
>>  return 0;
>>  }
>>  
>> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
>> index 589b889..b2a003f 100644
>> --- a/xen/include/asm-arm/gic-its.h
>> +++ b/xen/include/asm-arm/gic-its.h
>> @@ -69,6 +69,7 @@ struct host_its {
>>  paddr_t addr;
>>  paddr_t size;
>>  void __iomem *its_base;
>> +void *cmd_buf;
>>  };
>>  
>>  extern struct list_head host_its_list;
>> -- 
>> 2.9.0
>>
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Razvan Cojocaru]

On 11/10/2016 05:59 PM, Andrew Cooper wrote:
 @ -259,6 +266,14 @@ struct vm_event_cpuid {
 >>>  uint32_t _pad;
 >>>  };
 >>>  
 >>> +struct vm_event_interrupt_x86 {
 >>> +uint32_t vector;
 >>> +uint32_t type;
 >>> +uint32_t error_code;
 >>> +uint64_t cr2;
 >>> +uint32_t _pad;
 >>> +};
>>> >> I'm pretty certain this is not what you want, as this make the layout
>>> >> vary between 32-bit (compat) and 64-bit (native) callers.
>> > I'll remove the _pad.
> You need to invert the pad and cr2, so cr2 starts at 16 bytes into the
> structure.
> 
> Remember that uint64_t has 8 byte alignment in 64bit, but only 4 byte
> alignment in 32bit.

Right, it's been a long day. :) Thanks, I'll do that.


Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Tamas K Lengyel]

On Thu, Nov 10, 2016 at 6:33 AM, Razvan Cojocaru 
wrote:

> Hello Tamas, thanks for the review!
>
> On 11/10/2016 03:11 PM, Tamas K Lengyel wrote:
> > diff --git a/xen/include/asm-x86/vm_event.h
> > b/xen/include/asm-x86/vm_event.h
> > index ca73f99..38c624c 100644
> > --- a/xen/include/asm-x86/vm_event.h
> > +++ b/xen/include/asm-x86/vm_event.h
> > @@ -27,6 +27,7 @@
> >   */
> >  struct arch_vm_event {
> >  uint32_t emulate_flags;
> > +bool monitor_next_interrupt;
> >
> >
> > This should be in domain.h with the rest of the monitor control bits (as
> > the name of the variable suggests as well).
>
> Unfortunately that would alter the semantics of the patch, as this
> variable needs to be per-VCPU. Putting it in domain.h as you suggest
> would make it per-domain. Looking at places to put it so that it would
> serve this purpose, struct arch_vm_event felt like the most natural place.
>

I see. I generally like to keep vm_event/monitor bits separate as to not
end up in the spaghetti we were in a couple years ago. Maybe introducing a
struct arch_monitor would be appropriate?


>
> >  union {
> >  struct vm_event_emul_read_data read;
> >  struct vm_event_emul_insn_data insn;
> > diff --git a/xen/include/public/domctl.h
> b/xen/include/public/domctl.h
> > index 177319d..85cbb7c 100644
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -1086,6 +1086,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_
> domctl_psr_cmt_op_t);
> >  #define XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION   5
> >  #define XEN_DOMCTL_MONITOR_EVENT_CPUID 6
> >  #define XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL   7
> > +#define XEN_DOMCTL_MONITOR_EVENT_INTERRUPT 8
> >
> >  struct xen_domctl_monitor_op {
> >  uint32_t op; /* XEN_DOMCTL_MONITOR_OP_* */
> > diff --git a/xen/include/public/vm_event.h
> > b/xen/include/public/vm_event.h
> > index c28be5a..ba9accf 100644
> > --- a/xen/include/public/vm_event.h
> > +++ b/xen/include/public/vm_event.h
> > @@ -105,6 +105,11 @@
> >   * if any of those flags are set, only those will be honored).
> >   */
> >  #define VM_EVENT_FLAG_SET_EMUL_INSN_DATA (1 << 9)
> >
> >
> > Just reading this comment it is not entirely clear whether the event
> > will be sent before or after the interrupt. Also, there is a typo in
> > spelling occurring.
> >
> >
> > +/*
> > + * Have a one-shot VM_EVENT_REASON_INTERRUPT event sent for the
> first
> > + * interrupt occuring after resuming the VCPU.
> > + */
> >
> > +#define VM_EVENT_FLAG_GET_NEXT_INTERRUPT (1 << 10)
>
> The event is sent before the actual interrupt effects, as is our
> convention for vm_events (the test is for pending interrupts so they had
> not had effects yet).
>
> I'm not sure about "occuring", the sources I've found online suggest my
> spelling is correct, but perhaps this is a case of a word that can be
> spelled in more ways, such as "color" and "colour":
> https://en.wiktionary.org/wiki/occuring
>
> I can send a V3 if you'd like me to clarify when the event is being sent
> with regards to interrupt delivery (in fact I think replacing the word
> "occuring" with "pending" would nicely solve both your objections here).
>

That would work, thanks.

Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Andrew Cooper]

On 10/11/16 15:53, Razvan Cojocaru wrote:
> On 11/10/2016 05:47 PM, Jan Beulich wrote:
> On 10.11.16 at 09:35,  wrote:
>>> Changes since V1:
>>>  - Modified the if() in hvm_do_resume() for readability.
>>>  - Replaced hard tab with spaces.
>>>  - Removed a local variable used only once.
>>>  - Moved cr2 assignment to the common part of the code.
>>>  - Now listing the new event in the x86 vm_event capability list.
>>>  - Moved struct variables for readability.
>> Hmm, looks like you've moved the field in the structure declaration,
>> but not the two initializers (in SVM and VMX code).
> I'll modify those as well.
>
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -535,9 +535,24 @@ void hvm_do_resume(struct vcpu *v)
>>>  /* Inject pending hw/sw trap */
>>>  if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>>>  {
>>> -hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
>>> +if ( !hvm_event_pending(v) )
>>> +hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
>>> +
>>>  v->arch.hvm_vcpu.inject_trap.vector = -1;
>>>  }
>>> +
>>> +if ( unlikely(v->arch.vm_event) &&
>>> + v->arch.vm_event->monitor_next_interrupt )
>>> +{
>>> +struct hvm_trap info;
>>> +
>>> +if ( hvm_get_pending_event(v, &info) )
>>> +{
>>> +hvm_monitor_interrupt(info.vector, info.type, info.error_code,
>>> +  info.cr2);
>>> +v->arch.vm_event->monitor_next_interrupt = false;
>>> +}
>>> +}
>>>  }
>>>  
>>>  static int hvm_print_line(
>>> @@ -6047,6 +6062,12 @@ void hvm_domain_soft_reset(struct domain *d)
>>>  hvm_destroy_all_ioreq_servers(d);
>>>  }
>>>  
>>> +bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>>> +{
>>> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
>>> +return hvm_funcs.get_pending_event(v, info);
>>> +}
>> Unless you expect more callers, I'm tempted to suggest to make this
>> static for now (and move it up ahead of its only caller).
> Will do.
>
>>> --- a/xen/arch/x86/vm_event.c
>>> +++ b/xen/arch/x86/vm_event.c
>>> @@ -134,6 +134,12 @@ void vm_event_set_registers(struct vcpu *v, 
>>> vm_event_response_t *rsp)
>>>  v->arch.user_regs.eip = rsp->data.regs.x86.rip;
>>>  }
>>>  
>>> +void vm_event_monitor_next_interrupt(struct vcpu *v)
>>> +{
>>> +ASSERT(v->arch.vm_event);
>>> +v->arch.vm_event->monitor_next_interrupt = true;
>>> +}
>> I think at this point we're determined to no longer permit ASSERT()s
>> like this: Either use a simple if() or a BUG_ON(). Andrew, please
>> correct me if I've misunderstood earlier discussions.
> I'll change it to a simple if().
>
>>> @@ -259,6 +266,14 @@ struct vm_event_cpuid {
>>>  uint32_t _pad;
>>>  };
>>>  
>>> +struct vm_event_interrupt_x86 {
>>> +uint32_t vector;
>>> +uint32_t type;
>>> +uint32_t error_code;
>>> +uint64_t cr2;
>>> +uint32_t _pad;
>>> +};
>> I'm pretty certain this is not what you want, as this make the layout
>> vary between 32-bit (compat) and 64-bit (native) callers.
> I'll remove the _pad.

You need to invert the pad and cr2, so cr2 starts at 16 bytes into the
structure.

Remember that uint64_t has 8 byte alignment in 64bit, but only 4 byte
alignment in 32bit.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 05/24] ARM: GICv3 ITS: introduce ITS command handling

[Andre Przywara]

Hi,

On 27/10/16 00:55, Stefano Stabellini wrote:
> On Wed, 28 Sep 2016, Andre Przywara wrote:
>> To be able to easily send commands to the ITS, create the respective
>> wrapper functions, which take care of the ring buffer.
>> The first two commands we implement provide methods to map a collection
>> to a redistributor (aka host core) and to flush the command queue (SYNC).
>> Start using these commands for mapping one collection to each host CPU.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-its.c| 101 
>> ++
>>  xen/arch/arm/gic-v3.c |  17 +++
>>  xen/include/asm-arm/gic-its.h |  32 +
>>  3 files changed, 150 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
>> index c8a7a7e..88397bc 100644
>> --- a/xen/arch/arm/gic-its.c
>> +++ b/xen/arch/arm/gic-its.c
>> @@ -33,6 +33,10 @@ static struct {
>>  int host_lpi_bits;
>>  } lpi_data;
>>  
>> +/* Physical redistributor address */
>> +static DEFINE_PER_CPU(uint64_t, rdist_addr);
>> +/* Redistributor ID */
>> +static DEFINE_PER_CPU(uint64_t, rdist_id);
>>  /* Pending table for each redistributor */
>>  static DEFINE_PER_CPU(void *, pending_table);
>>  
>> @@ -40,6 +44,86 @@ static DEFINE_PER_CPU(void *, pending_table);
>>  min_t(unsigned int, lpi_data.host_lpi_bits, CONFIG_HOST_LPI_BITS)
>>  #define MAX_HOST_LPIS   (BIT(MAX_HOST_LPI_BITS) - 8192)
>>  
>> +#define ITS_COMMAND_SIZE32
>> +
>> +static int its_send_command(struct host_its *hw_its, void *its_cmd)
>> +{
>> +int readp, writep;
> 
> uint64_t

A bit overkill, but probably right type-wise.

> 
>> +spin_lock(&hw_its->cmd_lock);
>> +
>> +readp = readl_relaxed(hw_its->its_base + GITS_CREADR) & GENMASK(19, 5);
>> +writep = readl_relaxed(hw_its->its_base + GITS_CWRITER) & GENMASK(19, 
>> 5);
> 
> It might be worth to
> 
>   #define ITS_CMD_RING_SIZE PAGE_SIZE
> 
> for clarity

Or revisit this to allow bigger queues than one page.

> 
>> +if ( ((writep + ITS_COMMAND_SIZE) % PAGE_SIZE) == readp )
>> +{
>> +spin_unlock(&hw_its->cmd_lock);
>> +return -EBUSY;
>> +}
>> +
>> +memcpy(hw_its->cmd_buf + writep, its_cmd, ITS_COMMAND_SIZE);
>> +__flush_dcache_area(hw_its->cmd_buf + writep, ITS_COMMAND_SIZE);
>> +writep = (writep + ITS_COMMAND_SIZE) % PAGE_SIZE;
>> +
>> +writeq_relaxed(writep & GENMASK(19, 5), hw_its->its_base + 
>> GITS_CWRITER);
>> +
>> +spin_unlock(&hw_its->cmd_lock);
>> +
>> +return 0;
>> +}
>> +
>> +static uint64_t encode_rdbase(struct host_its *hw_its, int cpu, uint64_t 
>> reg)
>> +{
>> +reg &= ~GENMASK(51, 16);
>> +
>> +if ( hw_its->pta )
>> +reg |= per_cpu(rdist_addr, cpu) & GENMASK(51, 16);
> 
> Again in my version of the spec is GENMASK(47, 16).
> 
> 
>> +else
>> +reg |= per_cpu(rdist_id, cpu) << 16;
>> +return reg;
>> +}
>> +
>> +static int its_send_cmd_sync(struct host_its *its, int cpu)
>> +{
>> +uint64_t cmd[4];
>> +
>> +cmd[0] = GITS_CMD_SYNC;
>> +cmd[1] = 0x00;
>> +cmd[2] = encode_rdbase(its, cpu, 0x0);
>> +cmd[3] = 0x00;
>> +
>> +return its_send_command(its, cmd);
>> +}
>> +
>> +static int its_send_cmd_mapc(struct host_its *its, int collection_id, int 
>> cpu)
>> +{
>> +uint64_t cmd[4];
>> +
>> +cmd[0] = GITS_CMD_MAPC;
>> +cmd[1] = 0x00;
>> +cmd[2] = encode_rdbase(its, cpu, (collection_id & GENMASK(15, 0)) | 
>> BIT(63));
>> +cmd[3] = 0x00;
>> +
>> +return its_send_command(its, cmd);
>> +}
>> +
>> +/* Set up the (1:1) collection mapping for the given host CPU. */
>> +void gicv3_its_setup_collection(int cpu)
>> +{
>> +struct host_its *its;
>> +
>> +list_for_each_entry(its, &host_its_list, entry)
>> +{
>> +/* Only send commands to ITS that have been initialized already. */
>> +if ( !its->cmd_buf )
>> +continue;
>> +
>> +its_send_cmd_mapc(its, cpu, cpu);
>> +its_send_cmd_sync(its, cpu);
>> +}
>> +}
>> +
>>  #define BASER_ATTR_MASK   \
>>  ((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
>>   (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
>> @@ -147,6 +231,13 @@ int gicv3_its_init(struct host_its *hw_its)
>>  if ( !hw_its->its_base )
>>  return -ENOMEM;
>>  
>> +/* Make sure the ITS is disabled before programming the BASE registers. 
>> */
>> +reg = readl_relaxed(hw_its->its_base + GITS_CTLR);
>> +writel_relaxed(reg & ~GITS_CTLR_ENABLE, hw_its->its_base + GITS_CTLR);
>> +
>> +reg = readq_relaxed(hw_its->its_base + GITS_TYPER);
>> +hw_its->pta = reg & GITS_TYPER_PTA;
> 
> To avoid problems:
> 
>   pta = !!(reg & GITS_TYPER_PTA);
> 
> 
>>  for (i = 0; i < 8; i++)
>>  {
>>  void __iomem *basereg = hw_its->its_base + GITS_BASER0 + i * 8;
>> @@ -174,9 +265,18 @@ int gicv3_its_init(struct host_its *hw_its)
>>  if ( IS_ERR(hw_it

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Jan Beulich]

>>> On 10.11.16 at 09:35,  wrote:
> Changes since V1:
>  - Modified the if() in hvm_do_resume() for readability.
>  - Replaced hard tab with spaces.
>  - Removed a local variable used only once.
>  - Moved cr2 assignment to the common part of the code.
>  - Now listing the new event in the x86 vm_event capability list.
>  - Moved struct variables for readability.

Hmm, looks like you've moved the field in the structure declaration,
but not the two initializers (in SVM and VMX code).

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -535,9 +535,24 @@ void hvm_do_resume(struct vcpu *v)
>  /* Inject pending hw/sw trap */
>  if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>  {
> -hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
> +if ( !hvm_event_pending(v) )
> +hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
> +
>  v->arch.hvm_vcpu.inject_trap.vector = -1;
>  }
> +
> +if ( unlikely(v->arch.vm_event) &&
> + v->arch.vm_event->monitor_next_interrupt )
> +{
> +struct hvm_trap info;
> +
> +if ( hvm_get_pending_event(v, &info) )
> +{
> +hvm_monitor_interrupt(info.vector, info.type, info.error_code,
> +  info.cr2);
> +v->arch.vm_event->monitor_next_interrupt = false;
> +}
> +}
>  }
>  
>  static int hvm_print_line(
> @@ -6047,6 +6062,12 @@ void hvm_domain_soft_reset(struct domain *d)
>  hvm_destroy_all_ioreq_servers(d);
>  }
>  
> +bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
> +{
> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
> +return hvm_funcs.get_pending_event(v, info);
> +}

Unless you expect more callers, I'm tempted to suggest to make this
static for now (and move it up ahead of its only caller).

> --- a/xen/arch/x86/vm_event.c
> +++ b/xen/arch/x86/vm_event.c
> @@ -134,6 +134,12 @@ void vm_event_set_registers(struct vcpu *v, 
> vm_event_response_t *rsp)
>  v->arch.user_regs.eip = rsp->data.regs.x86.rip;
>  }
>  
> +void vm_event_monitor_next_interrupt(struct vcpu *v)
> +{
> +ASSERT(v->arch.vm_event);
> +v->arch.vm_event->monitor_next_interrupt = true;
> +}

I think at this point we're determined to no longer permit ASSERT()s
like this: Either use a simple if() or a BUG_ON(). Andrew, please
correct me if I've misunderstood earlier discussions.

> @@ -259,6 +266,14 @@ struct vm_event_cpuid {
>  uint32_t _pad;
>  };
>  
> +struct vm_event_interrupt_x86 {
> +uint32_t vector;
> +uint32_t type;
> +uint32_t error_code;
> +uint64_t cr2;
> +uint32_t _pad;
> +};

I'm pretty certain this is not what you want, as this make the layout
vary between 32-bit (compat) and 64-bit (native) callers.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Razvan Cojocaru]

On 11/10/2016 05:47 PM, Jan Beulich wrote:
 On 10.11.16 at 09:35,  wrote:
>> Changes since V1:
>>  - Modified the if() in hvm_do_resume() for readability.
>>  - Replaced hard tab with spaces.
>>  - Removed a local variable used only once.
>>  - Moved cr2 assignment to the common part of the code.
>>  - Now listing the new event in the x86 vm_event capability list.
>>  - Moved struct variables for readability.
> 
> Hmm, looks like you've moved the field in the structure declaration,
> but not the two initializers (in SVM and VMX code).

I'll modify those as well.

>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -535,9 +535,24 @@ void hvm_do_resume(struct vcpu *v)
>>  /* Inject pending hw/sw trap */
>>  if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>>  {
>> -hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
>> +if ( !hvm_event_pending(v) )
>> +hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
>> +
>>  v->arch.hvm_vcpu.inject_trap.vector = -1;
>>  }
>> +
>> +if ( unlikely(v->arch.vm_event) &&
>> + v->arch.vm_event->monitor_next_interrupt )
>> +{
>> +struct hvm_trap info;
>> +
>> +if ( hvm_get_pending_event(v, &info) )
>> +{
>> +hvm_monitor_interrupt(info.vector, info.type, info.error_code,
>> +  info.cr2);
>> +v->arch.vm_event->monitor_next_interrupt = false;
>> +}
>> +}
>>  }
>>  
>>  static int hvm_print_line(
>> @@ -6047,6 +6062,12 @@ void hvm_domain_soft_reset(struct domain *d)
>>  hvm_destroy_all_ioreq_servers(d);
>>  }
>>  
>> +bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>> +{
>> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
>> +return hvm_funcs.get_pending_event(v, info);
>> +}
> 
> Unless you expect more callers, I'm tempted to suggest to make this
> static for now (and move it up ahead of its only caller).

Will do.

>> --- a/xen/arch/x86/vm_event.c
>> +++ b/xen/arch/x86/vm_event.c
>> @@ -134,6 +134,12 @@ void vm_event_set_registers(struct vcpu *v, 
>> vm_event_response_t *rsp)
>>  v->arch.user_regs.eip = rsp->data.regs.x86.rip;
>>  }
>>  
>> +void vm_event_monitor_next_interrupt(struct vcpu *v)
>> +{
>> +ASSERT(v->arch.vm_event);
>> +v->arch.vm_event->monitor_next_interrupt = true;
>> +}
> 
> I think at this point we're determined to no longer permit ASSERT()s
> like this: Either use a simple if() or a BUG_ON(). Andrew, please
> correct me if I've misunderstood earlier discussions.

I'll change it to a simple if().

>> @@ -259,6 +266,14 @@ struct vm_event_cpuid {
>>  uint32_t _pad;
>>  };
>>  
>> +struct vm_event_interrupt_x86 {
>> +uint32_t vector;
>> +uint32_t type;
>> +uint32_t error_code;
>> +uint64_t cr2;
>> +uint32_t _pad;
>> +};
> 
> I'm pretty certain this is not what you want, as this make the layout
> vary between 32-bit (compat) and 64-bit (native) callers.

I'll remove the _pad.


Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Jan Beulich]

>>> On 10.11.16 at 15:25,  wrote:
> On 11/10/2016 03:35 AM, Razvan Cojocaru wrote:
>>  
>> +bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>> +{
>> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
>> +return hvm_funcs.get_pending_event(v, info);
>> +}
> 
> I believe it was Jan who requested that cr2 update be factored out but I
> feel it's better to keep it in the hvm op and not break up
> initialization of the info structure across multiple routines. The code
> size may increase (by a few bytes) but I think it will be more readable.

This is not about code size, but about avoiding doing the same
thing in multiple places.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 03/24] ARM: GICv3 ITS: allocate device and collection table

[Andre Przywara]

Hi,

On 26/10/16 23:57, Stefano Stabellini wrote:
> On Wed, 28 Sep 2016, Andre Przywara wrote:
>> Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
>> an EventID (the MSI payload or interrupt ID) to a pair of LPI number
>> and collection ID, which points to the target CPU.
>> This mapping is stored in the device and collection tables, which software
>> has to provide for the ITS to use.
>> Allocate the required memory and hand it the ITS.
>> We limit the number of devices to cover 4 PCI busses for now.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-its.c| 114 
>> ++
>>  xen/arch/arm/gic-v3.c |   5 ++
>>  xen/include/asm-arm/gic-its.h |  49 +-
>>  3 files changed, 167 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
>> index b52dff3..40238a2 100644
>> --- a/xen/arch/arm/gic-its.c
>> +++ b/xen/arch/arm/gic-its.c
>> @@ -21,6 +21,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -38,6 +39,119 @@ static DEFINE_PER_CPU(void *, pending_table);
>>  min_t(unsigned int, lpi_data.host_lpi_bits, CONFIG_HOST_LPI_BITS)
>>  #define MAX_HOST_LPIS   (BIT(MAX_HOST_LPI_BITS) - 8192)
>>  
>> +#define BASER_ATTR_MASK   \
>> +((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
>> + (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
>> + (0x7UL << GITS_BASER_INNER_CACHEABILITY_SHIFT))
>> +#define BASER_RO_MASK   (GENMASK(52, 48) | GENMASK(58, 56))
>> +
>> +static uint64_t encode_phys_addr(paddr_t addr, int page_bits)
>> +{
>> +uint64_t ret;
>> +
>> +if ( page_bits < 16)
>> +return (uint64_t)addr & GENMASK(47, page_bits);
>> +
>> +ret = addr & GENMASK(47, 16);
>> +return ret | (addr & GENMASK(51, 48)) >> (48 - 12);
>> +}
>> +
>> +static int gicv3_map_baser(void __iomem *basereg, uint64_t regc, int 
>> nr_items)
> 
> Shouldn't this be called its_map_baser?

Yes, the BASER registers are an ITS property.

>> +{
>> +uint64_t attr;
>> +int entry_size = (regc >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0x1f;
> 
> The spec says "This field is read-only and specifies the number of
> bytes per entry, minus one." Do we need to increment it by 1?

Mmh, looks so. I guess it worked because the number gets dwarfed by the
page size round up below.

>> +int pagesz;
>> +int order;
>> +void *buffer = NULL;
>> +
>> +attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
>> +attr |= GIC_BASER_CACHE_SameAsInner << 
>> GITS_BASER_OUTER_CACHEABILITY_SHIFT;
>> +attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
>> +
>> +/*
>> + * Loop over the page sizes (4K, 16K, 64K) to find out what the host
>> + * supports.
>> + */
> 
> Is this really the best way to do it? Can't we assume ITS supports 4K,
> given that Xen requires 4K pages at the moment?

The ITS pages are totally independent from the core's MMU page size.
So the spec says: "If the GIC implementation supports only a single,
fixed page size, this field might be RO."
I take it that this means that the only implemented page size could be
64K, for instance. And in fact the KVM ITS emulation advertises exactly
this to a guest.

> Is it actually possible
> to find hardware that supports 4K but with an ITS that only support 64K
> or 16K pages? It seems insane to me. Otherwise can't we probe the page
> size somehow?

We can probe by writing and seeing if it sticks - that's what the code
does. Is it really so horrible? I agree it's nasty, but isn't it
basically a loop around the code needed anyway?

Yes to the rest of the comments.

Cheers,
Andre.

>> +for (pagesz = 0; pagesz < 3; pagesz++)
>> +{
>> +uint64_t reg;
>> +int nr_bytes;
>> +
>> +nr_bytes = ROUNDUP(nr_items * entry_size, BIT(pagesz * 2 + 12));
>> +order = get_order_from_bytes(nr_bytes);
>> +
>> +if ( !buffer )
>> +buffer = alloc_xenheap_pages(order, 0);
>> +if ( !buffer )
>> +return -ENOMEM;
>> +
>> +reg  = attr;
>> +reg |= (pagesz << GITS_BASER_PAGE_SIZE_SHIFT);
>> +reg |= nr_bytes >> (pagesz * 2 + 12);
>> +reg |= regc & BASER_RO_MASK;
>> +reg |= GITS_BASER_VALID;
>> +reg |= encode_phys_addr(virt_to_maddr(buffer), pagesz * 2 + 12);
>> +
>> +writeq_relaxed(reg, basereg);
>> +regc = readl_relaxed(basereg);
>> +
>> +/* The host didn't like our attributes, just use what it returned. 
>> */
>> +if ( (regc & BASER_ATTR_MASK) != attr )
>> +attr = regc & BASER_ATTR_MASK;
>> +
>> +/* If the host accepted our page size, we are done. */
>> +if ( (reg & (3UL << GITS_BASER_PAGE_SIZE_SHIFT)) == pagesz )
>> +return 0;
>> +
>> +/* Check whether our buffer is aligned

Re: [Xen-devel] [PATCH] x86/cpuid: Deal with broken firmware once more

[Boris Ostrovsky]

On 11/10/2016 10:12 AM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
>> On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
>>> On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
>>>
 I have found that your patch unfortunately does not improve the situation
 for me. Here is an excerpt obtained from the dmesg of a kernel compiled
 with this patch *as well as* Sebastian's patch:
 [0.002561] CPU: Physical Processor ID: 0
 [0.002566] CPU: Processor Core ID: 0
 [0.002572] [Firmware Bug]: CPU0: APIC id mismatch. Firmware:  
 CPUID: 2
>>> So apic->cpu_present_to_apicid() gives us a completely bogus APIC id which
>>> translates to a bogus package id. And looking at the XEN code:
>>>
>>>xen_pv_apic.cpu_present_to_apicid = xen_cpu_present_to_apicid,
>>>
>>> and xen_cpu_present_to_apicid does:
>>>
>>> static int xen_cpu_present_to_apicid(int cpu)
>>> {
>>> if (cpu_present(cpu))
>>> return xen_get_apic_id(xen_apic_read(APIC_ID));
>>> else
>>> return BAD_APICID;
>>> }
>>>
>>> So independent of which present CPU we query we get just some random
>>> information, in the above case we get BAD_APICID from xen_apic_read() not
>>> from the else path as this CPU _IS_ present.
>>>
>>> What's so wrong with storing the fricking firmware supplied APICid as
>>> everybody else does and report it back when queried?
>> By firmware you mean ACPI? It is most likely not available to PV guests.
> You either have to provide ACPI or MP tables. And either of those has to
> provide the intial APIC ids for the CPUs. They are supposed to match the
> IDs which are in the CPUID leafs.
>
>> How about returning cpu_data(cpu).initial_apicid?
> For a not yet brought up CPU. That's what the initial ACPI/MP table
> enumeration is for.

Unfortunately PV guests have neither. So we may need to emulate
something in xen_cpu_present_to_apicid().

-boris

(+xen-devel)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

[Roger Pau Monné]

On Thu, Nov 10, 2016 at 08:53:05AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 10, 2016 at 11:39:08AM +0100, Roger Pau Monné wrote:
> > On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
> > > > In order to improve the mapping of device memory areas, Xen will have to
> > > > know of those devices in advance (before Dom0 tries to interact with 
> > > > them)
> > > > so that the memory BARs will be properly mapped into Dom0 memory map.
> > > 
> > > Oh, that is going to be a problem with SR-IOV. Those are created _after_
> > > dom0 has booted. In fact they are done by the drivers themselves.
> > > 
> > > See xen_add_device in drivers/xen/pci.c how this is handled.
> > 
> > Is the process of creating those VF something standart? (In the sense that 
> > it can be detected by Xen, and proper mappings stablished)
> 
> Yes and no.
> 
> You can read from the PCI configuration that the device (Physical
> function) has SR-IOV. But that information may be in the extended
> configuration registers so you need MCFG. Anyhow the only thing the PF
> will tell you is the BAR regions they will occupy (since they
> are behind the bridge) but not the BDFs:

But just knowing the BARs position is enough for Xen to install the identity 
mappings AFAICT?

Or are the more BARs that will only appear after the SR-IOV functionality 
has been enabled?

From the documentation that I've found, if you detect that the device has 
PCI_EXT_CAP_ID_SRIOV, you can then read the BARs and map them into Dom0, but 
maybe I'm missing something (and I have not been able to test this, although 
my previous PVHv2 Dom0 series already contained code in order to perform 
this):

http://xenbits.xen.org/gitweb/?p=people/royger/xen.git;a=commit;h=260cfd1e96e56ab4b58a414d544d92a77e210050

> Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
> IOVCap: Migration-, Interrupt Message Number: 000
> IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy+
> IOVSta: Migration-
> Initial VFs: 8, Total VFs: 8, Number of VFs: 0, Function 
> Dependency Link: 00
> VF offset: 128, stride: 2, Device ID: 10ca
> Supported Page Size: 0553, System Page Size: 0001
> Region 0: Memory at fbda (64-bit, 
> non-prefetchable)
> Region 3: Memory at fbd8 (64-bit, 
> non-prefetchable)
> VF Migration: offset: , BIR: 0
> Kernel driver in use: igb
> 
> And if I enable SR-IOV on the PF I get:
> 
> 0a:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network 
> Connection (rev 01)
> 0a:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
> 0a:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
> 0a:10.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
> 0a:10.6 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
> 0a:11.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
> 0a:11.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
> 0a:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
> 
> -bash-4.1# lspci -s 0a:10.0 -v
> 0a:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function
> (rev 01)
> Subsystem: Super Micro Computer Inc Device 10c9
> Flags: bus master, fast devsel, latency 0
> [virtual] Memory at fbda (64-bit, non-prefetchable) [size=16K]
> [virtual] Memory at fbd8 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [70] MSI-X: Enable+ Count=3 Masked-
> Capabilities: [a0] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
> Kernel driver in use: igbvf
> 
> -bash-4.1# lspci -s 0a:11.4 -v
> 0a:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function
> (rev 01)
> Subsystem: Super Micro Computer Inc Device 10c9
> Flags: bus master, fast devsel, latency 0
> [virtual] Memory at fbdb8000 (64-bit, non-prefetchable) [size=16K]
> [virtual] Memory at fbd98000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [70] MSI-X: Enable+ Count=3 Masked-
> Capabilities: [a0] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
> Kernel driver in use: igbvf

So it seems that the memory for individual VFs is taken from the BARs listed 
inside of PCI_EXT_CAP_ID_SRIOV.

> > > > PCI memory BARs
> > > > ---
> > > > 
> > > > PCI devices discovered by Xen will have it's BARs scanned in order to 
> > > > detect
> > > > memory BARs, and those will be identity mapped to Dom0. Since BARs can 
> > >

Re: [Xen-devel] [RFC PATCH 02/24] ARM: GICv3: allocate LPI pending and property table

[Andre Przywara]

Hi,

On 26/10/16 02:10, Stefano Stabellini wrote:
> Hi Andre,
> 
> Sorry for the late reply, I'll try to be faster for the next rounds of
> review. The patch looks good for a first iteration. Some comments below.

No worries and thanks for the thorough review, much appreciated.
As you can see I took my time to respond as well ;-)

> 
> On Wed, 28 Sep 2016, Andre Przywara wrote:
>> The ARM GICv3 ITS provides a new kind of interrupt called LPIs.
>> The pending bits and the configuration data (priority, enable bits) for
>> those LPIs are stored in tables in normal memory, which software has to
>> provide to the hardware.
>> Allocate the required memory, initialize it and hand it over to each
>> ITS. We limit the number of LPIs we use with a compile time constant to
>> avoid wasting memory.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/Kconfig  |  6 
>>  xen/arch/arm/efi/efi-boot.h   |  1 -
>>  xen/arch/arm/gic-its.c| 76 
>> +++
>>  xen/arch/arm/gic-v3.c | 27 ++
>>  xen/include/asm-arm/cache.h   |  4 +++
>>  xen/include/asm-arm/gic-its.h | 22 +++-
>>  xen/include/asm-arm/gic_v3_defs.h | 48 -
>>  7 files changed, 181 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index 9fe3b8e..66e2bb8 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -50,6 +50,12 @@ config HAS_ITS
>>  depends on ARM_64
>>  depends on HAS_GICV3
>>  
>> +config HOST_LPI_BITS
>> +depends on HAS_ITS
>> +int "Maximum bits for GICv3 host LPIs (14-32)"
>> +range 14 32
>> +default "20"
>> +
>>  config ALTERNATIVE
>>  bool
>>  
>> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
>> index 045d6ce..dc64aec 100644
>> --- a/xen/arch/arm/efi/efi-boot.h
>> +++ b/xen/arch/arm/efi/efi-boot.h
>> @@ -10,7 +10,6 @@
>>  #include "efi-dom0.h"
>>  
>>  void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
>> -void __flush_dcache_area(const void *vaddr, unsigned long size);
>>  
>>  #define DEVICE_TREE_GUID \
>>  {0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 
>> 0xe0}}
>> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
>> index 0f42a77..b52dff3 100644
>> --- a/xen/arch/arm/gic-its.c
>> +++ b/xen/arch/arm/gic-its.c
>> @@ -20,10 +20,86 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  
>> +/* Global state */
>> +static struct {
>> +uint8_t *lpi_property;
>> +int host_lpi_bits;
>> +} lpi_data;
>> +
>> +/* Pending table for each redistributor */
>> +static DEFINE_PER_CPU(void *, pending_table);
>> +
>> +#define MAX_HOST_LPI_BITS\
> 
> To avoid confusion, I would call this MAX_PHYS_LPI_BITS
> 
> 
>> +min_t(unsigned int, lpi_data.host_lpi_bits, CONFIG_HOST_LPI_BITS)
>> +#define MAX_HOST_LPIS   (BIT(MAX_HOST_LPI_BITS) - 8192)
> 
> And this MAX_PHYS_LPIS

Done.

>> +uint64_t gicv3_lpi_allocate_pendtable(void)
>> +{
>> +uint64_t reg, attr;
>> +void *pendtable;
> 
> I would introduce a check to make sure that this_cpu(pending_table) == NULL.

Can do. So I return back this value then, though this should never happen.

> 
>> +attr  = GIC_BASER_CACHE_RaWaWb << 
>> GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
>> +attr |= GIC_BASER_CACHE_SameAsInner << 
>> GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
>> +attr |= GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT;
>> +
>> +/*
>> + * The pending table holds one bit per LPI, so we need three bits less
>> + * than the number of LPI_BITs.
> 
> Why 3 bit less? Please add more info on how you came up with 3.

3 bits as in 2 << 3 = 8 = BITS_PER_BYTES. We need to divide by that,
which is shift by 3, which is ORDER - 3. Does that make sense?
But this mayhem goes away anyway with _xmalloc.

> 
>> But the alignment requirement from the
>> + * ITS is 64K, so make order at least 16 (-12).
> 
> Does it need to be 64K aligned or does it need to be at least 64K in
> size?

The first.

> That makes a big difference. If it just needs to be 64K aligned,
> you can do that with xmalloc.

Well, not xmalloc (since I don't have a data structure of that size),
but _xmalloc. I just saw that this is exported as well (I dismissed this
before because of the leading underscore).
Also "alloc pages" sounded more like what I had in mind, but I guess
aligning it to 64K serves the same purpose.

>> + */
>> +pendtable = alloc_xenheap_pages(MAX(lpi_data.host_lpi_bits - 3, 16) - 
>> 12, 0);
> 
> Shouldn't we be using MAX_HOST_LPI_BITS instead of
> lpi_data.host_lpi_bits to make this calculation?

I was under the impression that the redistributors expect the pending
table to cover every possible LPI as reported in GICD_TYPER (because in
contrast to PROPBASER the PEN

Re: [Xen-devel] [PATCH for-4.8] libxc/x86: Report consistent initial APIC value for PV guests

[Boris Ostrovsky]

On 11/10/2016 10:08 AM, Andrew Cooper wrote:
> On 10/11/16 15:05, Boris Ostrovsky wrote:
>> On 11/10/2016 09:55 AM, Andrew Cooper wrote:
>>> On 10/11/16 14:50, Boris Ostrovsky wrote:
 Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
 APIC ID) with contents of that field on the processor that launched
 the guest. This results in the guest reporting different initial
 APIC IDs across runs.

 We should be consistent in how this value is reported, let's set
 it to 0 (which is also what Linux guests expect).

 Signed-off-by: Boris Ostrovsky 
>>> This surely wants to go along with:
>> Probably, although Linux PV always reports APIC ID as zero (whole PV
>> APIC is a mess there as it is tied to topology discovery and we don't do
>> this well, to put it charitably).
> If PV linux always overrides this to 0, why do you need the toolstack
> fix in the first place?

I meant that Linux overrides APICID read from APIC (which, of course, we
don't have) to zero, not CPUID.

>
>>> andrewcoop@andrewcoop:/local/xen.git/xen$ git diff
>>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>>> index b51b51b..bdf9339 100644
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -985,6 +985,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
>>>  uint32_t tmp, _ecx, _ebx;
>>>  
>>>  case 0x0001:
>>> +/* Fix up VLAPIC details. */
>>> +b &= 0x00FFu;
>>> +b |= (curr->vcpu_id * 2) << 24;
>> Do we also need to multiply by two for PV guests? Or is it just to be
>> consistent with HVM?
> Frankly, until I get CPUID phase 2 sorted, this is all held together
> with good wishes, rather than duck tape.  I am astounded it has held
> together this long.

It does not anymore. We are being yelled at by Linux x86 maintainers to
get our stuff in order.

>
> HVM chooses an even APIC ID to prevent the VM thinking it has hyperthreads.


Right, but it's not needed (I think) by PV. But we might do it that way
to keep the two in sync. Let me test it and see what breaks.

-boris



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Fix misleading indentation warnings

[Daniel De Graaf]

On 11/10/2016 04:23 AM, Cédric Bosdonnat wrote:

Gcc6 build reports misleading indentation as warnings. Fix a few
warnings in stubdom.

Signed-off-by: Cédric Bosdonnat 


Acked-by: Daniel De Graaf 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] libxc/x86: Report consistent initial APIC value for PV guests

[Andrew Cooper]

On 10/11/16 15:05, Boris Ostrovsky wrote:
> On 11/10/2016 09:55 AM, Andrew Cooper wrote:
>> On 10/11/16 14:50, Boris Ostrovsky wrote:
>>> Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
>>> APIC ID) with contents of that field on the processor that launched
>>> the guest. This results in the guest reporting different initial
>>> APIC IDs across runs.
>>>
>>> We should be consistent in how this value is reported, let's set
>>> it to 0 (which is also what Linux guests expect).
>>>
>>> Signed-off-by: Boris Ostrovsky 
>> This surely wants to go along with:
> Probably, although Linux PV always reports APIC ID as zero (whole PV
> APIC is a mess there as it is tied to topology discovery and we don't do
> this well, to put it charitably).

If PV linux always overrides this to 0, why do you need the toolstack
fix in the first place?

>
>> andrewcoop@andrewcoop:/local/xen.git/xen$ git diff
>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>> index b51b51b..bdf9339 100644
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -985,6 +985,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
>>  uint32_t tmp, _ecx, _ebx;
>>  
>>  case 0x0001:
>> +/* Fix up VLAPIC details. */
>> +b &= 0x00FFu;
>> +b |= (curr->vcpu_id * 2) << 24;
> Do we also need to multiply by two for PV guests? Or is it just to be
> consistent with HVM?

Frankly, until I get CPUID phase 2 sorted, this is all held together
with good wishes, rather than duck tape.  I am astounded it has held
together this long.

HVM chooses an even APIC ID to prevent the VM thinking it has hyperthreads.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] libxc/x86: Report consistent initial APIC value for PV guests

[Andrew Cooper]

On 10/11/16 14:50, Boris Ostrovsky wrote:
> Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
> APIC ID) with contents of that field on the processor that launched
> the guest. This results in the guest reporting different initial
> APIC IDs across runs.
>
> We should be consistent in how this value is reported, let's set
> it to 0 (which is also what Linux guests expect).
>
> Signed-off-by: Boris Ostrovsky 

This surely wants to go along with:

andrewcoop@andrewcoop:/local/xen.git/xen$ git diff
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index b51b51b..bdf9339 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -985,6 +985,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
 uint32_t tmp, _ecx, _ebx;
 
 case 0x0001:
+/* Fix up VLAPIC details. */
+b &= 0x00FFu;
+b |= (curr->vcpu_id * 2) << 24;
+
 c &= pv_featureset[FEATURESET_1c];
 d &= pv_featureset[FEATURESET_1d];
 

Which brings the PV CPUID handling in line with HVM handling.  Otherwise
a guest will see an APIC ID of 0 in all vcpus, which will surely confuse it.

~Andrew

> ---
>
> I think this should go to stable branches as well. This has been causing
> problems lately in Linux with introduction of topology maps.
>
>
>  tools/libxc/xc_cpuid_x86.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> index d761805..1f26294 100644
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -618,6 +618,12 @@ static void xc_cpuid_pv_policy(xc_interface *xch,
>  /* Host topology exposed to PV guest.  Provide host value. */
>  bool host_htt = regs[3] & bitmaskof(X86_FEATURE_HTT);
>  
> +/*
> + * Don't pick host's Initial APIC ID which can change from run
> + * to run. 
> + */
> +regs[1] &= 0x00ffu;
> +
>  regs[2] = info->featureset[featureword_of(X86_FEATURE_SSE3)];
>  regs[3] = (info->featureset[featureword_of(X86_FEATURE_FPU)] &
> ~bitmaskof(X86_FEATURE_HTT));


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] libxc/x86: Report consistent initial APIC value for PV guests

[Boris Ostrovsky]

On 11/10/2016 09:55 AM, Andrew Cooper wrote:
> On 10/11/16 14:50, Boris Ostrovsky wrote:
>> Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
>> APIC ID) with contents of that field on the processor that launched
>> the guest. This results in the guest reporting different initial
>> APIC IDs across runs.
>>
>> We should be consistent in how this value is reported, let's set
>> it to 0 (which is also what Linux guests expect).
>>
>> Signed-off-by: Boris Ostrovsky 
> This surely wants to go along with:

Probably, although Linux PV always reports APIC ID as zero (whole PV
APIC is a mess there as it is tied to topology discovery and we don't do
this well, to put it charitably).

> andrewcoop@andrewcoop:/local/xen.git/xen$ git diff
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index b51b51b..bdf9339 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -985,6 +985,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
>  uint32_t tmp, _ecx, _ebx;
>  
>  case 0x0001:
> +/* Fix up VLAPIC details. */
> +b &= 0x00FFu;
> +b |= (curr->vcpu_id * 2) << 24;

Do we also need to multiply by two for PV guests? Or is it just to be
consistent with HVM?


-boris

> +
>  c &= pv_featureset[FEATURESET_1c];
>  d &= pv_featureset[FEATURESET_1d];
>  
>
> Which brings the PV CPUID handling in line with HVM handling.  Otherwise
> a guest will see an APIC ID of 0 in all vcpus, which will surely confuse it.
>
> ~Andrew
>
>> ---
>>
>> I think this should go to stable branches as well. This has been causing
>> problems lately in Linux with introduction of topology maps.
>>
>>
>>  tools/libxc/xc_cpuid_x86.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
>> index d761805..1f26294 100644
>> --- a/tools/libxc/xc_cpuid_x86.c
>> +++ b/tools/libxc/xc_cpuid_x86.c
>> @@ -618,6 +618,12 @@ static void xc_cpuid_pv_policy(xc_interface *xch,
>>  /* Host topology exposed to PV guest.  Provide host value. */
>>  bool host_htt = regs[3] & bitmaskof(X86_FEATURE_HTT);
>>  
>> +/*
>> + * Don't pick host's Initial APIC ID which can change from run
>> + * to run. 
>> + */
>> +regs[1] &= 0x00ffu;
>> +
>>  regs[2] = info->featureset[featureword_of(X86_FEATURE_SSE3)];
>>  regs[3] = (info->featureset[featureword_of(X86_FEATURE_FPU)] &
>> ~bitmaskof(X86_FEATURE_HTT));


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH for-4.8] libxc/x86: Report consistent initial APIC value for PV guests

[Boris Ostrovsky]

Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
APIC ID) with contents of that field on the processor that launched
the guest. This results in the guest reporting different initial
APIC IDs across runs.

We should be consistent in how this value is reported, let's set
it to 0 (which is also what Linux guests expect).

Signed-off-by: Boris Ostrovsky 
---

I think this should go to stable branches as well. This has been causing
problems lately in Linux with introduction of topology maps.


 tools/libxc/xc_cpuid_x86.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index d761805..1f26294 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -618,6 +618,12 @@ static void xc_cpuid_pv_policy(xc_interface *xch,
 /* Host topology exposed to PV guest.  Provide host value. */
 bool host_htt = regs[3] & bitmaskof(X86_FEATURE_HTT);
 
+/*
+ * Don't pick host's Initial APIC ID which can change from run
+ * to run. 
+ */
+regs[1] &= 0x00ffu;
+
 regs[2] = info->featureset[featureword_of(X86_FEATURE_SSE3)];
 regs[3] = (info->featureset[featureword_of(X86_FEATURE_FPU)] &
~bitmaskof(X86_FEATURE_HTT));
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-3.10 test] 102077: tolerable FAIL - PUSHED

[osstest service owner]

flight 102077 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102077/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl   6 xen-boot fail in 101958 pass in 102077
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail in 101958 pass in 102077
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail in 101958 pass in 
102077
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail in 101958 pass in 102077
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail in 101958 pass in 102077
 test-amd64-i386-libvirt   6 xen-boot fail in 101958 pass in 102077
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail in 101958 
pass in 102077
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail in 101958 
pass in 102077
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail in 101958 
pass in 102077
 test-amd64-amd64-xl-xsm   6 xen-boot fail in 101958 pass in 102077
 test-amd64-i386-freebsd10-amd64  6 xen-boot  fail in 101958 pass in 102077
 test-amd64-amd64-xl-multivcpu  6 xen-bootfail in 101958 pass in 102077
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot   fail in 101958 pass in 102077
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot  fail in 101958 pass in 102077
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail in 101958 pass in 102077
 test-amd64-i386-pair 9 xen-boot/src_host fail in 101958 pass in 102077
 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail in 101958 pass in 
102077
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot fail in 101958 pass in 102077
 test-amd64-amd64-xl-credit2   6 xen-boot fail in 101958 pass in 102077
 test-amd64-i386-pair10 xen-boot/dst_host fail in 101958 pass in 102077
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail in 101958 pass 
in 102077
 test-amd64-i386-libvirt-pair 9 xen-boot/src_host fail in 101958 pass in 102077
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail in 101958 pass in 102077
 test-amd64-i386-xl-xsm6 xen-boot fail in 101958 pass in 102077
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-bootfail in 101958 pass in 102077
 test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail in 101958 pass in 
102077
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot fail in 101958 pass in 102077
 test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail in 101958 pass in 102077
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail in 101958 pass in 
102077
 test-amd64-i386-xl6 xen-boot fail in 101958 pass in 102077
 test-amd64-amd64-pair9 xen-boot/src_host fail in 101958 pass in 102077
 test-amd64-amd64-pair   10 xen-boot/dst_host fail in 101958 pass in 102077
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail in 101975 pass 
in 102077
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail pass in 101594
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 101958
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 101975

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumprun   5 rumprun-build fail in 101594 baseline untested
 build-i386-rumprun5 rumprun-build fail in 101594 baseline untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 101594 like 100646
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100648
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100648

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linux7828a9658951301a3fd83daa4ed0a607d370399e
baseline version:
 linux2ecaf1d025af0f481d00b3701ffbcc600dcab076

Re: [Xen-devel] [PATCH] libxl: fix gentypes call in Makefile

[Juergen Gross]

On 10/11/16 14:11, Cédric Bosdonnat wrote:
> From the make documentation:
> 
> "$* [...] If the target is `dir/a.foo.b' and the target pattern is
> `a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
> stem is part of the file name that matched the `%' in the target
> pattern."
> 
> The rule generating the c types files from the idl ones is not
> a static pattern rule, but rather an implicit rule. Thus the value
> of $* is preceded by the file path, instead of only what matches %.
> 
> In order to get this fixed, drop the path using a $(shell basename $*).

Why not $(notdir $*) ?


Juergen

> 
> Signed-off-by: Cédric Bosdonnat 
> ---
>  tools/libxl/Makefile | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index af0a3ad..78fede3 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -250,12 +250,13 @@ $(LIBXL_OBJS) $(LIBXL_TEST_OBJS) $(LIBXLU_OBJS) \
>  $(LIBXL_OBJS) $(LIBXL_TEST_OBJS): libxl_internal.h
>  
>  _libxl_type%.h _libxl_type%_json.h _libxl_type%_private.h _libxl_type%.c: 
> libxl_type%.idl gentypes.py idl.py
> - $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h 
> __libxl_type$*_private.h \
> - __libxl_type$*_json.h  __libxl_type$*.c
> - $(call move-if-changed,__libxl_type$*.h,_libxl_type$*.h)
> - $(call move-if-changed,__libxl_type$*_private.h,_libxl_type$*_private.h)
> - $(call move-if-changed,__libxl_type$*_json.h,_libxl_type$*_json.h)
> - $(call move-if-changed,__libxl_type$*.c,_libxl_type$*.c)
> + $(eval stem = $(shell basename $*))
> + $(PYTHON) gentypes.py libxl_type$(stem).idl __libxl_type$(stem).h 
> __libxl_type$(stem)_private.h \
> + __libxl_type$(stem)_json.h  __libxl_type$(stem).c
> + $(call move-if-changed,__libxl_type$(stem).h,_libxl_type$(stem).h)
> + $(call 
> move-if-changed,__libxl_type$(stem)_private.h,_libxl_type$(stem)_private.h)
> + $(call 
> move-if-changed,__libxl_type$(stem)_json.h,_libxl_type$(stem)_json.h)
> + $(call move-if-changed,__libxl_type$(stem).c,_libxl_type$(stem).c)
>  
>  libxenlight.so: libxenlight.so.$(MAJOR)
>   $(SYMLINK_SHLIB) $< $@
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Razvan Cojocaru]

On 11/10/2016 04:25 PM, Boris Ostrovsky wrote:
> On 11/10/2016 03:35 AM, Razvan Cojocaru wrote:
>>  
>> +bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>> +{
>> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
>> +return hvm_funcs.get_pending_event(v, info);
>> +}
> 
> I believe it was Jan who requested that cr2 update be factored out but I
> feel it's better to keep it in the hvm op and not break up
> initialization of the info structure across multiple routines. The code
> size may increase (by a few bytes) but I think it will be more readable.

I am fine with either approach, though obviously I had originally
favoured your preference for the same reasons.

Jan, would it be OK to switch back to the original code here?


Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Boris Ostrovsky]

On 11/10/2016 03:35 AM, Razvan Cojocaru wrote:
>  
> +bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
> +{
> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
> +return hvm_funcs.get_pending_event(v, info);
> +}

I believe it was Jan who requested that cr2 update be factored out but I
feel it's better to keep it in the hvm op and not break up
initialization of the info structure across multiple routines. The code
size may increase (by a few bytes) but I think it will be more readable.

-boris




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] x86/svm: Don't clobber eax and edx if an RDMSR intercept fails

[Wei Liu]

On Wed, Nov 09, 2016 at 12:28:27PM +, Andrew Cooper wrote:
> The original code has a bug; eax and edx get unconditionally updated even when
> hvm_msr_read_intercept() doesn't return X86EMUL_OKAY.
> 
> It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content
> pointer) that this isn't an information leak into guests.
> 
> While fixing this bug, reduce the scope of msr_content and initialise it to 0.
> This makes it obvious that a stack leak won't occur, even if there were to be
> a buggy codepath in hvm_msr_read_intercept().
> 
> Also make some non-functional improvements.  Make the insn_len calculation
> common, and reduce the quantity of explicit casting by making better use of
> the existing register names.
> 
> Signed-off-by: Andrew Cooper 

Release-acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86emul: correct direction of FPU insn emulations

[Wei Liu]

On Wed, Nov 09, 2016 at 01:25:20AM -0700, Jan Beulich wrote:
> There are two cases where this was wrong, albeit in a benign way (the
> compiler - according to my checking - didn't leverage the wrongness
> for any optimizations affecting overall outcome).
> 
> Signed-off-by: Jan Beulich 

Release-acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

[Konrad Rzeszutek Wilk]

On Thu, Nov 10, 2016 at 11:39:08AM +0100, Roger Pau Monné wrote:
> On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
> > > Hello,
> > > 
> > > I'm attaching a draft of how a PVHv2 Dom0 is supposed to interact with 
> > > physical devices, and what needs to be done inside of Xen in order to 
> > > achieve it. Current draft is RFC because I'm quite sure I'm missing bits 
> > > that should be written down here. So far I've tried to describe what my 
> > > previous series attempted to do by adding a bunch of IO and memory space 
> > > handlers.
> > > 
> > > Please note that this document only applies to PVHv2 Dom0, it is not 
> > > applicable to untrusted domains that will need more handlers in order to 
> > > secure Xen and other domains running on the same system. The idea is that 
> > > this can be expanded to untrusted domains also in the long term, thus 
> > > having 
> > > a single set of IO and memory handlers for passed-through devices.
> > > 
> > > Roger.
> > > 
> > > ---8<---
> > > 
> > > This document describes how a PVHv2 Dom0 is supposed to interact with 
> > > physical
> > > devices.
> > > 
> > > Architecture
> > > 
> > > 
> > > Purpose
> > > ---
> > > 
> > > Previous Dom0 implementations have always used PIRQs (physical interrupts
> > > routed over event channels) in order to receive events from physical 
> > > devices.
> > > This prevents Dom0 form taking advantage of new hardware virtualization
> > > features, like posted interrupts or hardware virtualized local APIC. Also 
> > > the
> > > current device memory management in the PVH Dom0 implementation is 
> > > lacking,
> > > and might not support devices that have memory regions past the 4GB 
> > > boundary.
> > 
> > memory regions meaning BAR regions?
> 
> Yes.
>  
> > > 
> > > The new PVH implementation (PVHv2) should overcome the interrupt 
> > > limitations by
> > > providing the same interface that's used on bare metal (a local and IO 
> > > APICs)
> > > thus allowing the usage of advanced hardware assisted virtualization
> > > techniques. This also aligns with the trend on the hardware industry to
> > > move part of the emulation into the silicon itself.
> > 
> > What if the hardware PVH2 runs on does not have vAPIC?
> 
> The emulated local APIC provided by Xen will be used.
> 
> > > 
> > > In order to improve the mapping of device memory areas, Xen will have to
> > > know of those devices in advance (before Dom0 tries to interact with them)
> > > so that the memory BARs will be properly mapped into Dom0 memory map.
> > 
> > Oh, that is going to be a problem with SR-IOV. Those are created _after_
> > dom0 has booted. In fact they are done by the drivers themselves.
> > 
> > See xen_add_device in drivers/xen/pci.c how this is handled.
> 
> Is the process of creating those VF something standart? (In the sense that 
> it can be detected by Xen, and proper mappings stablished)

Yes and no.

You can read from the PCI configuration that the device (Physical
function) has SR-IOV. But that information may be in the extended
configuration registers so you need MCFG. Anyhow the only thing the PF
will tell you is the BAR regions they will occupy (since they
are behind the bridge) but not the BDFs:

Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
IOVCap: Migration-, Interrupt Message Number: 000
IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy+
IOVSta: Migration-
Initial VFs: 8, Total VFs: 8, Number of VFs: 0, Function 
Dependency Link: 00
VF offset: 128, stride: 2, Device ID: 10ca
Supported Page Size: 0553, System Page Size: 0001
Region 0: Memory at fbda (64-bit, non-prefetchable)
Region 3: Memory at fbd8 (64-bit, non-prefetchable)
VF Migration: offset: , BIR: 0
Kernel driver in use: igb

And if I enable SR-IOV on the PF I get:

0a:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection 
(rev 01)
0a:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0a:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0a:10.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0a:10.6 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0a:11.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0a:11.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0a:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)

-bash-4.1# lspci -s 0a:10.0 -v
0a:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function
(rev 01)
Subsystem: Super Micro Computer Inc Device 10c9
Flags: bus master, fast devsel, latency 0
[virtual] Memory at fbda (64-bit, non-pre

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Razvan Cojocaru]

On 11/10/2016 03:41 PM, Julien Grall wrote:
> On 10/11/16 13:33, Razvan Cojocaru wrote:
>> I'm not sure about "occuring", the sources I've found online suggest my
>> spelling is correct, but perhaps this is a case of a word that can be
>> spelled in more ways, such as "color" and "colour":
>> https://en.wiktionary.org/wiki/occuring
> 
> From the link:
> 
> "Misspelling of occurring, the present participle of occur."
> 
> So it is a common misspelling and should be avoided ;). If you look at
> color/coulor, wiktionary will mention that alternative form (e.g US/UK).

Indeed, thanks for the clarification. Will change the comment.


Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Julien Grall]

On 10/11/16 13:33, Razvan Cojocaru wrote:

I'm not sure about "occuring", the sources I've found online suggest my
spelling is correct, but perhaps this is a case of a word that can be
spelled in more ways, such as "color" and "colour":
https://en.wiktionary.org/wiki/occuring


From the link:

"Misspelling of occurring, the present participle of occur."

So it is a common misspelling and should be avoided ;). If you look at 
color/coulor, wiktionary will mention that alternative form (e.g US/UK).



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Razvan Cojocaru]

Hello Tamas, thanks for the review!

On 11/10/2016 03:11 PM, Tamas K Lengyel wrote:
> diff --git a/xen/include/asm-x86/vm_event.h
> b/xen/include/asm-x86/vm_event.h
> index ca73f99..38c624c 100644
> --- a/xen/include/asm-x86/vm_event.h
> +++ b/xen/include/asm-x86/vm_event.h
> @@ -27,6 +27,7 @@
>   */
>  struct arch_vm_event {
>  uint32_t emulate_flags;
> +bool monitor_next_interrupt;
> 
> 
> This should be in domain.h with the rest of the monitor control bits (as
> the name of the variable suggests as well).

Unfortunately that would alter the semantics of the patch, as this
variable needs to be per-VCPU. Putting it in domain.h as you suggest
would make it per-domain. Looking at places to put it so that it would
serve this purpose, struct arch_vm_event felt like the most natural place.

>  union {
>  struct vm_event_emul_read_data read;
>  struct vm_event_emul_insn_data insn;
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 177319d..85cbb7c 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1086,6 +1086,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
>  #define XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION   5
>  #define XEN_DOMCTL_MONITOR_EVENT_CPUID 6
>  #define XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL   7
> +#define XEN_DOMCTL_MONITOR_EVENT_INTERRUPT 8
> 
>  struct xen_domctl_monitor_op {
>  uint32_t op; /* XEN_DOMCTL_MONITOR_OP_* */
> diff --git a/xen/include/public/vm_event.h
> b/xen/include/public/vm_event.h
> index c28be5a..ba9accf 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -105,6 +105,11 @@
>   * if any of those flags are set, only those will be honored).
>   */
>  #define VM_EVENT_FLAG_SET_EMUL_INSN_DATA (1 << 9)
> 
> 
> Just reading this comment it is not entirely clear whether the event
> will be sent before or after the interrupt. Also, there is a typo in
> spelling occurring.
>  
> 
> +/*
> + * Have a one-shot VM_EVENT_REASON_INTERRUPT event sent for the first
> + * interrupt occuring after resuming the VCPU.
> + */
> 
> +#define VM_EVENT_FLAG_GET_NEXT_INTERRUPT (1 << 10)

The event is sent before the actual interrupt effects, as is our
convention for vm_events (the test is for pending interrupts so they had
not had effects yet).

I'm not sure about "occuring", the sources I've found online suggest my
spelling is correct, but perhaps this is a case of a word that can be
spelled in more ways, such as "color" and "colour":
https://en.wiktionary.org/wiki/occuring

I can send a V3 if you'd like me to clarify when the event is being sent
with regards to interrupt delivery (in fact I think replacing the word
"occuring" with "pending" would nicely solve both your objections here).


Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] libxl: fix gentypes call in Makefile

[Cédric Bosdonnat]

From the make documentation:

"$* [...] If the target is `dir/a.foo.b' and the target pattern is
`a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
stem is part of the file name that matched the `%' in the target
pattern."

The rule generating the c types files from the idl ones is not
a static pattern rule, but rather an implicit rule. Thus the value
of $* is preceded by the file path, instead of only what matches %.

In order to get this fixed, drop the path using a $(shell basename $*).

Signed-off-by: Cédric Bosdonnat 
---
 tools/libxl/Makefile | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index af0a3ad..78fede3 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -250,12 +250,13 @@ $(LIBXL_OBJS) $(LIBXL_TEST_OBJS) $(LIBXLU_OBJS) \
 $(LIBXL_OBJS) $(LIBXL_TEST_OBJS): libxl_internal.h
 
 _libxl_type%.h _libxl_type%_json.h _libxl_type%_private.h _libxl_type%.c: 
libxl_type%.idl gentypes.py idl.py
-   $(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h 
__libxl_type$*_private.h \
-   __libxl_type$*_json.h  __libxl_type$*.c
-   $(call move-if-changed,__libxl_type$*.h,_libxl_type$*.h)
-   $(call move-if-changed,__libxl_type$*_private.h,_libxl_type$*_private.h)
-   $(call move-if-changed,__libxl_type$*_json.h,_libxl_type$*_json.h)
-   $(call move-if-changed,__libxl_type$*.c,_libxl_type$*.c)
+   $(eval stem = $(shell basename $*))
+   $(PYTHON) gentypes.py libxl_type$(stem).idl __libxl_type$(stem).h 
__libxl_type$(stem)_private.h \
+   __libxl_type$(stem)_json.h  __libxl_type$(stem).c
+   $(call move-if-changed,__libxl_type$(stem).h,_libxl_type$(stem).h)
+   $(call 
move-if-changed,__libxl_type$(stem)_private.h,_libxl_type$(stem)_private.h)
+   $(call 
move-if-changed,__libxl_type$(stem)_json.h,_libxl_type$(stem)_json.h)
+   $(call move-if-changed,__libxl_type$(stem).c,_libxl_type$(stem).c)
 
 libxenlight.so: libxenlight.so.$(MAJOR)
$(SYMLINK_SHLIB) $< $@
-- 
2.10.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

[Tamas K Lengyel]

diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
> index ca73f99..38c624c 100644
> --- a/xen/include/asm-x86/vm_event.h
> +++ b/xen/include/asm-x86/vm_event.h
> @@ -27,6 +27,7 @@
>   */
>  struct arch_vm_event {
>  uint32_t emulate_flags;
> +bool monitor_next_interrupt;
>

This should be in domain.h with the rest of the monitor control bits (as
the name of the variable suggests as well).


>  union {
>  struct vm_event_emul_read_data read;
>  struct vm_event_emul_insn_data insn;
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 177319d..85cbb7c 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1086,6 +1086,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
>  #define XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION   5
>  #define XEN_DOMCTL_MONITOR_EVENT_CPUID 6
>  #define XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL   7
> +#define XEN_DOMCTL_MONITOR_EVENT_INTERRUPT 8
>
>  struct xen_domctl_monitor_op {
>  uint32_t op; /* XEN_DOMCTL_MONITOR_OP_* */
> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index c28be5a..ba9accf 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -105,6 +105,11 @@
>   * if any of those flags are set, only those will be honored).
>   */
>  #define VM_EVENT_FLAG_SET_EMUL_INSN_DATA (1 << 9)
>

Just reading this comment it is not entirely clear whether the event will
be sent before or after the interrupt. Also, there is a typo in spelling
occurring.


> +/*
> + * Have a one-shot VM_EVENT_REASON_INTERRUPT event sent for the first
> + * interrupt occuring after resuming the VCPU.
> + */
>
+#define VM_EVENT_FLAG_GET_NEXT_INTERRUPT (1 << 10)
>
>
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

[Julien Grall]

(CC Wei as release manager)

On 10/11/16 08:30, Peng Fan wrote:

Hi Julien,


Hi Peng,


On Tue, Nov 01, 2016 at 02:42:06PM +, Julien Grall wrote:

Hi Peng,

Sorry for the late answer.

On 23/09/2016 03:55, Peng Fan wrote:

On AArch64 SoCs, some IPs may only have the capability to access
32 bits address space. The physical memory assigned for Dom0 maybe
not in 4GB address space, then the IPs will not work properly.
So need to allocate memory under 4GB for Dom0.

There is no restriction that how much lowmem needs to be allocated for
Dom0 ,so allocate lowmem as much as possible for Dom0.

This patch does not affect 32-bit domain, because Variable "lowmem" is
set to true at the beginning. If failed to allocate bank0 under 4GB,
need to panic for 32-bit domain, because 32-bit domain requires bank0
be allocated under 4GB.

For 64-bit domain, set "lowmem" to false, and continue allocating
memory from above 4GB.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 


Reviewed-by: Julien Grall 

I am undecided whether this should be considered as a bug fix for Xen 4.8.
Are you aware of any ARM64 platform we currently support requiring allocation
of memory below 4GB?


I have no idea about this (:, but I think this is a bug fix. Alought current
supported platforms works well, users may choose 4.8 to support their
new platform which has the limitation to access 64bit address.


We are already late in the release process (rc5) for Xen 4.8. So we need 
to be careful when including a bug fix and evaluate the pros and cons.


This patch is modifying the DOM0 memory layout for all 64-bit platforms. 
So it could potentially break one of the platform we  officially support 
(see [1] for a non-exhaustive list). We don't have a test suite running 
automatically for ARM64 at the moment (it is been working on), this 
means that manual testing needs to be done. I am not aware of any 
platform, in the list we supports, having this issue so I prefer to stay 
on the safe side and defer this patch for Xen 4.9.


If a user cares about Xen 4.8 for their platforms, then they could 
request the patch to be backported in Xen 4.8 after the release and 
after extensive testing in staging.


Regards,

[1] 
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#Hardware




Regards,
Peng.



Regards,

--
Julien Grall


--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] x86: always supply .cpuid() handler to x86_emulate()

[Jan Beulich]

With us incremementally adding proper CPUID checks to x86_emulate()
(see commit de05bd965a ["x86emul: correct {,F}CMOV and F{,U}COMI{,P}
emulation"]) it is no longer appropriate to invoke the function with
that hook being NULL, as long as respective instructions may get used
in that case.

Signed-off-by: Jan Beulich 
---
I've noticed the problem first with a not yet submitted patch checking
cx8 (PV 32-bit kernels occasionally use cmpxchg8b for page table
accesses), and I think we don't strictly need the change here for 4.8,
but then again it may be better to handle this properly right away.

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1542,7 +1542,7 @@ static int hvmemul_wbinvd(
 return X86EMUL_OKAY;
 }
 
-static int hvmemul_cpuid(
+int hvmemul_cpuid(
 unsigned int *eax,
 unsigned int *ebx,
 unsigned int *ecx,
@@ -1892,11 +1892,13 @@ int hvm_emulate_one_mmio(unsigned long m
 .read   = x86emul_unhandleable_rw,
 .insn_fetch = hvmemul_insn_fetch,
 .write  = mmcfg_intercept_write,
+.cpuid  = hvmemul_cpuid,
 };
 static const struct x86_emulate_ops hvm_ro_emulate_ops_mmio = {
 .read   = x86emul_unhandleable_rw,
 .insn_fetch = hvmemul_insn_fetch,
-.write  = mmio_ro_emulated_write
+.write  = mmio_ro_emulated_write,
+.cpuid  = hvmemul_cpuid,
 };
 struct mmio_ro_emulate_ctxt mmio_ro_ctxt = { .cr2 = gla };
 struct hvm_emulate_ctxt ctxt;
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5327,6 +5327,7 @@ static const struct x86_emulate_ops ptwr
 .insn_fetch = ptwr_emulated_read,
 .write  = ptwr_emulated_write,
 .cmpxchg= ptwr_emulated_cmpxchg,
+.cpuid  = pv_emul_cpuid,
 };
 
 /* Write page fault handler: check if guest is trying to modify a PTE. */
@@ -5414,6 +5415,7 @@ static const struct x86_emulate_ops mmio
 .read   = x86emul_unhandleable_rw,
 .insn_fetch = ptwr_emulated_read,
 .write  = mmio_ro_emulated_write,
+.cpuid  = pv_emul_cpuid,
 };
 
 int mmcfg_intercept_write(
@@ -5451,6 +5453,7 @@ static const struct x86_emulate_ops mmcf
 .read   = x86emul_unhandleable_rw,
 .insn_fetch = ptwr_emulated_read,
 .write  = mmcfg_intercept_write,
+.cpuid  = pv_emul_cpuid,
 };
 
 /* Check if guest is trying to modify a r/o MMIO page. */
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -306,6 +306,7 @@ static const struct x86_emulate_ops hvm_
 .insn_fetch = hvm_emulate_insn_fetch,
 .write  = hvm_emulate_write,
 .cmpxchg= hvm_emulate_cmpxchg,
+.cpuid  = hvmemul_cpuid,
 };
 
 static int
@@ -374,6 +375,7 @@ static const struct x86_emulate_ops pv_s
 .insn_fetch = pv_emulate_read,
 .write  = pv_emulate_write,
 .cmpxchg= pv_emulate_cmpxchg,
+.cpuid  = pv_emul_cpuid,
 };
 
 const struct x86_emulate_ops *shadow_init_emulation(
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2755,6 +2755,24 @@ static int priv_op_write_msr(unsigned in
 return X86EMUL_UNHANDLEABLE;
 }
 
+int pv_emul_cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
+  unsigned int *edx, struct x86_emulate_ctxt *ctxt)
+{
+struct cpu_user_regs regs = *ctxt->regs;
+
+regs._eax = *eax;
+regs._ecx = *ecx;
+
+pv_cpuid(®s);
+
+*eax = regs._eax;
+*ebx = regs._ebx;
+*ecx = regs._ecx;
+*edx = regs._edx;
+
+return X86EMUL_OKAY;
+}
+
 /* Instruction fetch with error handling. */
 #define insn_fetch(type, base, eip, limit)  \
 ({  unsigned long _rc, _ptr = (base) + (eip);   \
--- a/xen/include/asm-x86/hvm/emulate.h
+++ b/xen/include/asm-x86/hvm/emulate.h
@@ -60,6 +60,12 @@ void hvm_emulate_init(
 unsigned int insn_bytes);
 void hvm_emulate_writeback(
 struct hvm_emulate_ctxt *hvmemul_ctxt);
+int hvmemul_cpuid(
+unsigned int *eax,
+unsigned int *ebx,
+unsigned int *ecx,
+unsigned int *edx,
+struct x86_emulate_ctxt *ctxt);
 struct segment_register *hvmemul_get_seg_reg(
 enum x86_segment seg,
 struct hvm_emulate_ctxt *hvmemul_ctxt);
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -504,6 +504,8 @@ extern int mmcfg_intercept_write(enum x8
  void *p_data,
  unsigned int bytes,
  struct x86_emulate_ctxt *ctxt);
+int pv_emul_cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
+  unsigned int *edx, struct x86_emulate_ctxt *ctxt);
 
 int  ptwr_do_page_fault(struct vcpu *, unsigned long,
 struct cpu_user_regs *);


x86: always supply .cpuid() handler to x86_emulate()

With us incremementally adding proper CPUID checks to x86_emulate()
(see commit de05bd965a ["x86emul: correct {,F}CMOV and F{,U}COMI{,P}
emulation"]) it is no longer appro

[Xen-devel] [PATCH] x86emul: suppress alignment check for {, v}mov{d, q}

[Jan Beulich]

When introducing support for these instructions, adjustment for the
alignment check logic (generating #GP(0)) was overlooked.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4940,7 +4940,7 @@ x86_emulate(
 {
 uint32_t mxcsr = 0;
 
-if ( vex.pfx != vex_66 )
+if ( ea.bytes < 16 || vex.pfx == vex_f3 )
 mxcsr = MXCSR_MM;
 else if ( vcpu_has_misalignsse() )
 asm ( "stmxcsr %0" : "=m" (mxcsr) );



x86emul: suppress alignment check for {,v}mov{d,q}

When introducing support for these instructions, adjustment for the
alignment check logic (generating #GP(0)) was overlooked.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4940,7 +4940,7 @@ x86_emulate(
 {
 uint32_t mxcsr = 0;
 
-if ( vex.pfx != vex_66 )
+if ( ea.bytes < 16 || vex.pfx == vex_f3 )
 mxcsr = MXCSR_MM;
 else if ( vcpu_has_misalignsse() )
 asm ( "stmxcsr %0" : "=m" (mxcsr) );
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Julien Grall]

(CC Stefano and change the title)

Hello,

On 10/11/16 12:13, casionwoo wrote:

I’m pleased about your reply and you have a lot of code to clean-up.

As you mentioned, It’s really huge to digest at once. Thank you for 
understanding me.

And that’s why i need a small fix up and todo list.

I feel familiar with ARM and c language and there’s no specific area yet.

I think that i can find interesting area with following up the codes.

I’m looking forward to being stuck on Xen.

Then it would be easier for me to understand about Xen on ARM.

Please let me know the TODO and bug-fix lists.


Stefano, before giving a list of code clean-up, do you have any small 
TODO on ARM in mind?


Cheers,





2016. 11. 10. 오후 8:17, Julien Grall  작성:

On 09/11/16 14:16, 유정우 wrote:

Hello, I'm a newbie in Xen. (Actually I have commited once)


Hello,


In the future, can you CC xen-devel? So you can get more feedback from the 
community.


I started to study about Xen on ARM.

As i watch the source codes, it's getting difficult.


I understand, lot of code to digest?



So I thought that if i study with small bug fixs, it would be more
easier than just studing without anything.


Do you have a specific area you would be interested to look at it?


I found only todo list about ARM in here
(https://wiki.xen.org/wiki/Xen_ARM_TODO)

but it looks like a big problem. So is there any small todo or bug list?
about ARM?


I have a lot of code clean-up in mind, would you be happy with that?


--
JeungWoo, Yoo


--
Julien Grall




--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Xen Question]

[casionwoo]

I’m pleased about your reply and you have a lot of code to clean-up.

As you mentioned, It’s really huge to digest at once. Thank you for 
understanding me.

And that’s why i need a small fix up and todo list. 

I feel familiar with ARM and c language and there’s no specific area yet.

I think that i can find interesting area with following up the codes.

I’m looking forward to being stuck on Xen.

Then it would be easier for me to understand about Xen on ARM.

Please let me know the TODO and bug-fix lists.


> 2016. 11. 10. 오후 8:17, Julien Grall  작성:
> 
> On 09/11/16 14:16, 유정우 wrote:
>> Hello, I'm a newbie in Xen. (Actually I have commited once)
> 
> Hello,
> 
> 
> In the future, can you CC xen-devel? So you can get more feedback from the 
> community.
> 
>> I started to study about Xen on ARM.
>> 
>> As i watch the source codes, it's getting difficult.
> 
> I understand, lot of code to digest?
> 
>> 
>> So I thought that if i study with small bug fixs, it would be more
>> easier than just studing without anything.
> 
> Do you have a specific area you would be interested to look at it?
> 
>> I found only todo list about ARM in here
>> (https://wiki.xen.org/wiki/Xen_ARM_TODO)
>> 
>> but it looks like a big problem. So is there any small todo or bug list?
>> about ARM?
> 
> I have a lot of code clean-up in mind, would you be happy with that?
> 
>> --
>> JeungWoo, Yoo
> 
> -- 
> Julien Grall


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [libvirt test] 102082: tolerable all pass - PUSHED

[osstest service owner]

flight 102082 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102082/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102058
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102058
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102058
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102058

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   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-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  c5492563dad1a30701a085b63566dd835fac6bf0
baseline version:
 libvirt  f694f3ff6bd8a94d71582adab669b0dcd1f7bfe5

Last test of basis   102058  2016-11-09 04:33:12 Z1 days
Testing same since   102082  2016-11-10 04:21:45 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Martin Kletzander 
  Michal Privoznik 
  Pavel Hrdina 
  Peter Krempa 
  Prasanna Kumar Kalever 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=c5492563dad1a30701a085b63566dd835fac6bf0
+ . ./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
++ exe

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

[Julien Grall]

Hi,

On 10/11/16 00:21, Stefano Stabellini wrote:

On Fri, 4 Nov 2016, Andre Przywara wrote:

On 24/10/16 16:32, Vijay Kilari wrote:

On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara  wrote:

The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a given redistributor (read: VCPU).
To avoid iterating (and mapping!) all guest tables, we instead go through
the host LPI table to find any LPIs targetting this VCPU. We then update
the configuration bits for the connected virtual LPIs.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c| 58 +++
 xen/arch/arm/vgic-its.c   | 30 ++
 xen/include/asm-arm/gic-its.h |  2 ++
 3 files changed, 90 insertions(+)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index 6f4329f..5129d6e 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -228,6 +228,18 @@ static int its_send_cmd_inv(struct host_its *its,
 return its_send_command(its, cmd);
 }

+static int its_send_cmd_invall(struct host_its *its, int cpu)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_INVALL;
+cmd[1] = 0x00;
+cmd[2] = cpu & GENMASK(15, 0);
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
 int gicv3_its_map_device(struct host_its *hw_its, struct domain *d,
  int devid, int bits, bool valid)
 {
@@ -668,6 +680,52 @@ uint32_t gicv3_lpi_lookup_lpi(struct domain *d, uint32_t 
host_lpi, int *vcpu_id)
 return hlpi.virt_lpi;
 }

+/* Iterate over all host LPIs, and updating the "enabled" state for a given
+ * guest redistributor (VCPU) given the respective state in the provided
+ * proptable. This proptable is indexed by the stored virtual LPI number.
+ * This is to implement a guest INVALL command.
+ */
+void gicv3_lpi_update_configurations(struct vcpu *v, uint8_t *proptable)
+{
+int chunk, i;
+struct host_its *its;
+
+for (chunk = 0; chunk < MAX_HOST_LPIS / HOST_LPIS_PER_PAGE; chunk++)
+{
+if ( !lpi_data.host_lpis[chunk] )
+continue;
+
+for (i = 0; i < HOST_LPIS_PER_PAGE; i++)
+{
+union host_lpi *hlpip = &lpi_data.host_lpis[chunk][i], hlpi;
+uint32_t hlpi_nr;
+
+hlpi.data = hlpip->data;
+if ( !hlpi.virt_lpi )
+continue;
+
+if ( hlpi.dom_id != v->domain->domain_id )
+continue;
+
+if ( hlpi.vcpu_id != v->vcpu_id )
+continue;
+
+hlpi_nr = chunk * HOST_LPIS_PER_PAGE + i;
+
+if ( proptable[hlpi.virt_lpi] & LPI_PROP_ENABLED )
+lpi_data.lpi_property[hlpi_nr - 8192] |= LPI_PROP_ENABLED;
+else
+lpi_data.lpi_property[hlpi_nr - 8192] &= ~LPI_PROP_ENABLED;
+}
+}

AFAIK, the initial design is to use tasklet to update property
table as it consumes
lot of time to update the table.


This is a possible, but premature optimization.
Linux (at the moment, at least) only calls INVALL _once_, just after
initialising the collections. And at this point no LPI is mapped, so the
whole routine does basically nothing - and that quite fast.
We can later have any kind of fancy algorithm if there is a need for.


I understand, but as-is it's so expensive that could be a DOS vector.
Also other OSes could issue INVALL much more often than Linux.

Considering that we might support device assigment with ITS soon, I
think it might be best to parse per-domain virtual tables rather than
the full list of physical LPIs, which theoretically could be much
larger. Or alternatively we need to think about adding another field to
lpi_data, to link together all lpis assigned to the same domain, but
that would cost even more memory. Or we could rate-limit the INVALL
calls to one every few seconds or something. Or all of the above :-)


It is not necessary for an ITS implementation to wait until an 
INVALL/INV command is issued to take into account the change of the LPI 
configuration tables (aka property table in this thread).


So how about trapping the property table? We would still have to go 
through the property table the first time (i.e when writing into the 
GICR_PROPBASER), but INVALL would be a nop.


The idea would be unmapping the region when GICR_PROPBASER is written. 
So any read/write access would be trapped. For a write access, Xen will 
update the LPIs internal data structures and write the value in the 
guest page unmapped. If we don't want to have an overhead for the read 
access, we could just write-protect the page in stage-2 page table. So 
only write access would be trapped.


Going further, for the ITS, Xen is using the guest memory to store the 
ITS information. This means Xen has to validate the information at every 
access. So how about restricting the access in stage-2 page table? That 
would remove the overhead of validating data.


Any thoughts?

Regards,

--
Julien 

Re: [Xen-devel] Xen, EFI and kexec

[Daniel Kiper]

On Wed, Nov 09, 2016 at 11:24:44AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 09, 2016 at 03:13:16PM +0100, Sylvain Munaut wrote:
> > Hi,
> >
> >
> > A bit of background: What I'm currently trying to do is to network
> > boot a first linux image in EFI mode (using UEFI network boot), then
> > from that image, kexec into Xen in EFI mode as well.
> >
> > It's not working.
> >
> > When you kexec into another linux in EFI mode, kexec actually passes
> > some more infos to the kernel to allow it to use EFI mode properly.
> > IIUC Linux also maps the various EFI ranges at deterministic addresses
> > because the seting up EFI virtual address mode is only allowed once
> > per boot and so both the old and new kernel have to use the same
> > mappings.
> >
> > I have seen the patch series by Daniel Kiper to add support for
> > multiboot2 protocol and EFI support for it. This seems like a good
> > step toward what I'd like to do. Adding multiboot2 support to kexec
> > user tools seems like something I could do. This should allow Xen to
> > get the info it needs.
> >
> > However I don't think that'll be sufficient.
> >
> > By the time kexec will launch Xen, the first kernel will have done an
> > "ExitBootServices". And looking at Daniel's patch, that seems to be an
>
> CC-ing Daniel.
> > issue.

Looks interesting. I thought about that a bit but not much, so, just
hand waving. I have a feeling that in that situation we should skip
whole code in Xen which refers to EFI boot services. We just need to
pass essential info (taken during first boot) to Xen. Probably we can
use some of multiboot2 existing features. However, I have a feeling
that we need also some extensions that would enable us to say that
Xen boots on EFI platform but without access to boot services (kexecing).
This should not be very big issue. If you wish to work on this I am
able to review some design and patches for kexec, multiboot2 and GRUB
if needed. Just CC me.

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

[Andrew Cooper]

On 10/11/16 10:54, Roger Pau Monné wrote:
> On Wed, Nov 09, 2016 at 06:51:49PM +, Andrew Cooper wrote:
>> On 09/11/16 15:59, Roger Pau Monné wrote:
>>> Low 1MB
>>> ---
>>>
>>> When booted with a legacy BIOS, the low 1MB contains firmware related data
>>> that should be identity mapped to the Dom0. This include the EBDA, video
>>> memory and possibly ROMs. All non RAM regions below 1MB will be identity
>>> mapped to the Dom0 so that it can access this data freely.
>> Are you proposing a unilateral identity map of the first 1MB, or just
>> the interesting regions?
> The current approach identity maps the first 1MB except for RAM regions, 
> that are populated in the p2m, and the data in the original pages is copied 
> over. This is done because the AP boot trampoline is placed in the RAM 
> regions below 1MB, and the emulator is not able to execute code from pages 
> marked as p2m_mmio_direct.
>  
>> One thing to remember is the iBVT, for iscsi boot, which lives in
>> regular RAM and needs searching for.
> And I guess this is not static data that just needs to be read by the OS? 
> Then I will have to look into fixing the emulator to deal with 
> p2m_mmio_direct regions.

It lives in plain RAM, but is static iirc.  It should just need copying
into dom0's view.

>
>>> ACPI regions
>>> 
>>>
>>> ACPI regions will be identity mapped to the Dom0, this implies regions with
>>> type 3 and 4 in the e820 memory map. Also, since some BIOS report incorrect
>>> memory maps, the top-level tables discovered by Xen (as listed in the
>>> {X/R}SDT) that are not on RAM regions will be mapped to Dom0.
>>>
>>> PCI memory BARs
>>> ---
>>>
>>> PCI devices discovered by Xen will have it's BARs scanned in order to detect
>>> memory BARs, and those will be identity mapped to Dom0. Since BARs can be
>>> freely moved by the Dom0 OS by writing to the appropriate PCI config space
>>> register, Xen must trap those accesses and unmap the previous region and
>>> map the new one as set by Dom0.
>>>
>>> Limitations
>>> ---
>>>
>>>  - Xen needs to be aware of any PCI device before Dom0 tries to interact 
>>> with
>>>it, so that the MMIO regions are properly mapped.
>>>
>>> Interrupt management
>>> 
>>>
>>> Overview
>>> 
>>>
>>> On x86 systems there are tree different mechanisms that can be used in order
>>> to deliver interrupts: IO APIC, MSI and MSI-X. Note that each device might
>>> support different methods, but those are never active at the same time.
>>>
>>> Legacy PCI interrupts
>>> -
>>>
>>> The only way to deliver legacy PCI interrupts to PVHv2 guests is using the
>>> IO APIC, PVHv2 domains don't have an emulated PIC. As a consequence the ACPI
>>> _PIC method must be set to APIC mode by the Dom0 OS.
>>>
>>> Xen will always provide a single IO APIC, that will match the number of
>>> possible GSIs of the underlying hardware. This is possible because ACPI
>>> uses a system cookie in order to name interrupts, so the IO APIC device ID
>>> or pin number is not used in _PTR methods.
>>>
>>> XXX: is it possible to have more than 256 GSIs?
>> Yes.  There is no restriction on the number of IO-APIC in a system, and
>> no restriction on the number of PCI bridges these IO-APICs serve.
>>
>> However, I would suggest it would be better to offer one a 1-to-1 view
>> of system IO-APICs to vIO-APICs in PVHv2 dom0, or the pin mappings are
>> going to get confused when reading the ACPI tables.
> Hm, I've been searching for this, but it seems to me that ACPI tables will 
> always use GSIs in APIC mode in order to describe interrupts, so it doesn't 
> seem to matter whether those GSIs are scattered across multiple IO APICs or 
> just a single one.

I will not be surprised if this plan turns out to cause problems.

Perhaps we can start out with just a single vIOAPIC and see if that
works in reality.

>
>>> The following registers reside in memory, and are pointed out by the Table 
>>> and
>>> PBA fields found in the PCI configuration space:
>>>
>>>  - Message address and data: writes and reads to those registers are trapped
>>>by Xen, and the value is stored into an internal structure. This is later
>>>used by Xen in order to configure the interrupt injected to the guest.
>>>Writes to those registers with MSI-X already enabled will not cause a
>>>reconfiguration of the interrupt.
>>>
>>>  - Vector control: writes and reads are trapped, clearing the mask bit (bit 
>>> 0)
>>>will cause Xen to setup the configured interrupt if MSI-X is globally
>>>enabled in the message control field.
>>>
>>>  - Pending bits array: writes and reads to this register are not trapped by
>>>Xen.
>>>
>>> Limitations
>>> ---
>>>
>>>  - Due to the fact that Dom0 is not able to parse dynamic ACPI tables,
>>>some UART devices might only function in polling mode, because Xen
>>>will be unable to properly configure the interrupt pins without Dom0
>>>

Re: [Xen-devel] [RFC PATCH 24/24] ARM: vGIC: advertising LPI support

[Julien Grall]

On 10/11/16 00:49, Stefano Stabellini wrote:

On Wed, 28 Sep 2016, Andre Przywara wrote:

To let a guest know about the availability of virtual LPIs, set the
respective bits in the virtual GIC registers and let a guest control
the LPI enable bit.
Only report the LPI capability if the host has initialized at least
one ITS.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index d230a1f..61c97a2 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -168,8 +168,10 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 switch ( gicr_reg )
 {
 case VREG32(GICR_CTLR):
-/* We have not implemented LPI's, read zero */
-goto read_as_zero_32;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+*r = vgic_reg32_extract(!!(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED),
+info);


I don't think it is useful to call vgic_reg32_extract in this case.
vgic.flags is not a register.


All the emulation is using vgic_reg*_extract and construct a register 
when necessary. So I would keep the vgic_reg32_extract.


However, it would be more readable to have:

uint32_t ctlr;

ctlr = !!(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED);
*r = vgic_reg32_extract(ctlr, info);

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

[Roger Pau Monné]

On Wed, Nov 09, 2016 at 06:51:49PM +, Andrew Cooper wrote:
> On 09/11/16 15:59, Roger Pau Monné wrote:
> > Low 1MB
> > ---
> >
> > When booted with a legacy BIOS, the low 1MB contains firmware related data
> > that should be identity mapped to the Dom0. This include the EBDA, video
> > memory and possibly ROMs. All non RAM regions below 1MB will be identity
> > mapped to the Dom0 so that it can access this data freely.
> 
> Are you proposing a unilateral identity map of the first 1MB, or just
> the interesting regions?

The current approach identity maps the first 1MB except for RAM regions, 
that are populated in the p2m, and the data in the original pages is copied 
over. This is done because the AP boot trampoline is placed in the RAM 
regions below 1MB, and the emulator is not able to execute code from pages 
marked as p2m_mmio_direct.
 
> One thing to remember is the iBVT, for iscsi boot, which lives in
> regular RAM and needs searching for.

And I guess this is not static data that just needs to be read by the OS? 
Then I will have to look into fixing the emulator to deal with 
p2m_mmio_direct regions.

> >
> > ACPI regions
> > 
> >
> > ACPI regions will be identity mapped to the Dom0, this implies regions with
> > type 3 and 4 in the e820 memory map. Also, since some BIOS report incorrect
> > memory maps, the top-level tables discovered by Xen (as listed in the
> > {X/R}SDT) that are not on RAM regions will be mapped to Dom0.
> >
> > PCI memory BARs
> > ---
> >
> > PCI devices discovered by Xen will have it's BARs scanned in order to detect
> > memory BARs, and those will be identity mapped to Dom0. Since BARs can be
> > freely moved by the Dom0 OS by writing to the appropriate PCI config space
> > register, Xen must trap those accesses and unmap the previous region and
> > map the new one as set by Dom0.
> >
> > Limitations
> > ---
> >
> >  - Xen needs to be aware of any PCI device before Dom0 tries to interact 
> > with
> >it, so that the MMIO regions are properly mapped.
> >
> > Interrupt management
> > 
> >
> > Overview
> > 
> >
> > On x86 systems there are tree different mechanisms that can be used in order
> > to deliver interrupts: IO APIC, MSI and MSI-X. Note that each device might
> > support different methods, but those are never active at the same time.
> >
> > Legacy PCI interrupts
> > -
> >
> > The only way to deliver legacy PCI interrupts to PVHv2 guests is using the
> > IO APIC, PVHv2 domains don't have an emulated PIC. As a consequence the ACPI
> > _PIC method must be set to APIC mode by the Dom0 OS.
> >
> > Xen will always provide a single IO APIC, that will match the number of
> > possible GSIs of the underlying hardware. This is possible because ACPI
> > uses a system cookie in order to name interrupts, so the IO APIC device ID
> > or pin number is not used in _PTR methods.
> >
> > XXX: is it possible to have more than 256 GSIs?
> 
> Yes.  There is no restriction on the number of IO-APIC in a system, and
> no restriction on the number of PCI bridges these IO-APICs serve.
> 
> However, I would suggest it would be better to offer one a 1-to-1 view
> of system IO-APICs to vIO-APICs in PVHv2 dom0, or the pin mappings are
> going to get confused when reading the ACPI tables.

Hm, I've been searching for this, but it seems to me that ACPI tables will 
always use GSIs in APIC mode in order to describe interrupts, so it doesn't 
seem to matter whether those GSIs are scattered across multiple IO APICs or 
just a single one.

> >
> > The binding between the underlying physical interrupt and the emulated
> > interrupt is performed when unmasking an IO APIC PIN, so writes to the
> > IOREDTBL registers that unset the mask bit will trigger this binding
> > and enable the interrupt.
> >
> > MSI Interrupts
> > --
> >
> > MSI interrupts are setup using the PCI config space, either the IO ports
> > or the memory mapped configuration area. This means that both spaces should
> > be trapped by Xen, in order to detect accesses to these registers and
> > properly emulate them.
> 
> cfc/cf8 need trapping unconditionally, and the MMCFG region can only be
> intercepted in units of 4k.  As a result, Xen will unconditionally see
> all config accesses anyway.

Yes, that's right (however it might decide to just pass-through some of 
them).

> >
> > Since the offset of the MSI registers is not fixed, Xen has to query the
> > PCI configuration space in order to find the offset of the PCI_CAP_ID_MSI,
> > and then setup the correct traps, which also vary depending on the
> > capabilities of the device.
> 
> Although only once at start-of-day.  The layout of capabilities in
> config space for a particular device is static.

Yes, the MSI capabilities offset is fetched at the start-if-day and then 
stored.

> >  The following list contains the set of MSI
> > registers that Xen will trap, please take into account th

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

[Andrew Cooper]

On 09/11/16 20:47, Pasi Kärkkäinen wrote:
> On Wed, Nov 09, 2016 at 06:51:49PM +, Andrew Cooper wrote:
>>> Low 1MB
>>> ---
>>>
>>> When booted with a legacy BIOS, the low 1MB contains firmware related data
>>> that should be identity mapped to the Dom0. This include the EBDA, video
>>> memory and possibly ROMs. All non RAM regions below 1MB will be identity
>>> mapped to the Dom0 so that it can access this data freely.
>> Are you proposing a unilateral identity map of the first 1MB, or just
>> the interesting regions?
>>
>> One thing to remember is the iBVT, for iscsi boot, which lives in
>> regular RAM and needs searching for.
>>
> I think you mean iBFT = iSCSI Boot Firmware Table.

I did indeed.  Sorry - BVT is a commonly used internal acronym, and is
clearly ingrained into my muscle memory.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

[Roger Pau Monné]

On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
> > Hello,
> > 
> > I'm attaching a draft of how a PVHv2 Dom0 is supposed to interact with 
> > physical devices, and what needs to be done inside of Xen in order to 
> > achieve it. Current draft is RFC because I'm quite sure I'm missing bits 
> > that should be written down here. So far I've tried to describe what my 
> > previous series attempted to do by adding a bunch of IO and memory space 
> > handlers.
> > 
> > Please note that this document only applies to PVHv2 Dom0, it is not 
> > applicable to untrusted domains that will need more handlers in order to 
> > secure Xen and other domains running on the same system. The idea is that 
> > this can be expanded to untrusted domains also in the long term, thus 
> > having 
> > a single set of IO and memory handlers for passed-through devices.
> > 
> > Roger.
> > 
> > ---8<---
> > 
> > This document describes how a PVHv2 Dom0 is supposed to interact with 
> > physical
> > devices.
> > 
> > Architecture
> > 
> > 
> > Purpose
> > ---
> > 
> > Previous Dom0 implementations have always used PIRQs (physical interrupts
> > routed over event channels) in order to receive events from physical 
> > devices.
> > This prevents Dom0 form taking advantage of new hardware virtualization
> > features, like posted interrupts or hardware virtualized local APIC. Also 
> > the
> > current device memory management in the PVH Dom0 implementation is lacking,
> > and might not support devices that have memory regions past the 4GB 
> > boundary.
> 
> memory regions meaning BAR regions?

Yes.
 
> > 
> > The new PVH implementation (PVHv2) should overcome the interrupt 
> > limitations by
> > providing the same interface that's used on bare metal (a local and IO 
> > APICs)
> > thus allowing the usage of advanced hardware assisted virtualization
> > techniques. This also aligns with the trend on the hardware industry to
> > move part of the emulation into the silicon itself.
> 
> What if the hardware PVH2 runs on does not have vAPIC?

The emulated local APIC provided by Xen will be used.

> > 
> > In order to improve the mapping of device memory areas, Xen will have to
> > know of those devices in advance (before Dom0 tries to interact with them)
> > so that the memory BARs will be properly mapped into Dom0 memory map.
> 
> Oh, that is going to be a problem with SR-IOV. Those are created _after_
> dom0 has booted. In fact they are done by the drivers themselves.
> 
> See xen_add_device in drivers/xen/pci.c how this is handled.

Is the process of creating those VF something standart? (In the sense that 
it can be detected by Xen, and proper mappings stablished)

> > 
> > The following document describes the proposed interface and implementation
> > of all the logic needed in order to achieve the functionality described 
> > above.
> > 
> > MMIO areas
> > ==
> > 
> > Overview
> > 
> > 
> > On x86 systems certain regions of memory might be used in order to manage
> > physical devices on the system. Access to this areas is critical for a
> > PVH Dom0 in order to operate properly. Unlike previous PVH Dom0 
> > implementation
> > (PVHv1) that was setup with identity mappings of all the holes and reserved
> > regions found in the memory map, this new implementation intents to map only
> > what's actually needed by the Dom0.
> 
> And why was the previous approach not working?

Previous PVHv1 implementation would only identity map holes and reserved 
areas in the guest memory map, or up to the 4GB boundary if the guest memory 
map is smaller than 4GB. If a device has a BAR past the 4GB boundary for 
example, it would not be identity mapped in the p2m. 

> > 
> > Low 1MB
> > ---
> > 
> > When booted with a legacy BIOS, the low 1MB contains firmware related data
> > that should be identity mapped to the Dom0. This include the EBDA, video
> > memory and possibly ROMs. All non RAM regions below 1MB will be identity
> > mapped to the Dom0 so that it can access this data freely.
> > 
> > ACPI regions
> > 
> > 
> > ACPI regions will be identity mapped to the Dom0, this implies regions with
> > type 3 and 4 in the e820 memory map. Also, since some BIOS report incorrect
> > memory maps, the top-level tables discovered by Xen (as listed in the
> > {X/R}SDT) that are not on RAM regions will be mapped to Dom0.
> > 
> > PCI memory BARs
> > ---
> > 
> > PCI devices discovered by Xen will have it's BARs scanned in order to detect
> > memory BARs, and those will be identity mapped to Dom0. Since BARs can be
> > freely moved by the Dom0 OS by writing to the appropriate PCI config space
> > register, Xen must trap those accesses and unmap the previous region and
> > map the new one as set by Dom0.
> 
> You can make that simpler - we have hypercalls to "notify" in Linux
> when a device is changing. Those can prov

Re: [Xen-devel] Help regarding bringing up dom0 for lager board

[Julien Grall]

Hello George,

On 09/11/16 14:47, George John wrote:

Thanks it was really the problem of dts. I just followed the proceedings
of Ferger in Mailing lists who tried to bring up Dom0 in lager, and I
got it booted up. But now the problem is with rootfs. I am checking on
that..


May I ask you to update the wikipage? So future users will not get 
caught with the same problem :).


Regards,



Thanks and regards,
George

On Tue, Nov 8, 2016 at 5:20 PM, Julien Grall mailto:julien.gr...@arm.com>> wrote:



On 07/11/2016 16:39, George John wrote:

Hi,


Hello,

(XEN) Freed 276kB init memory.
(XEN) traps.c:2505:d0v0 HSR=0x93820007 pc=0xc001d084 gva=0xe7804060
gpa=0x00e6160060


Looking at the log, DOM0 is trying to access an region that is not
mapped (0x00e6160060).

When booting Xen is going through the device tree and mapping to
dom0 all the regions described. So it seems that this region is not
present in the device tree.

Which Linux kernel are you using? I would recommend you to try the
latest as possible and use the device-tree provided in
arch/arm/boot/dts/ to see if it solves the problem.

Cheers,

--
Julien Grall




--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v9 06/13] efi: create new early memory allocator

[Daniel Kiper]

On Thu, Nov 03, 2016 at 02:48:26PM +0100, Daniel Kiper wrote:
> On Mon, Oct 24, 2016 at 03:57:22AM -0600, Jan Beulich wrote:
> > >>> On 24.10.16 at 11:03,  wrote:
>
> [...]
>
> > > It looks that it is last thing which blocks whole patch series.
> >
> > I don't think so - Andrew has (not via mail) already indicated he'd
> > like to comment on the not insignificant amount of assembly code
> > getting added, some of which presumably could (and hence should)
> > better be done in C. I've specifically avoided so far to respond with
> > any R-b or ack on the two main (in this regard) patches.
>
> Andrew, ping? Could you send me your comments?

Ping?

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

[Dirk Behme]

On 10.11.2016 10:25, Iurii Mykhalskyi wrote:

Hello Dirk,

On Thu, Nov 10, 2016 at 8:54 AM, Dirk Behme mailto:dirk.be...@de.bosch.com>> wrote:

On 09.11.2016 13:14, Julien Grall wrote:

Hello,

On 09/11/16 07:14, Dirk Behme wrote:

On 08.11.2016 16:41, Iurii Mykhalskyi wrote:

Hello Dirk,

I have made only single change - I recompile ATF to
leave CPU in EL2
mode and reflash it.



Yes, this is what I meant with 'modifying firmware' ;)

You are loading Xen with U-Boot running in EL2, then?

With this modification, do all other use cases still work?
E.g. load and
boot U-Boot and native Linux kernel without Xen?


Yes, when Linux is booting from EL2, it will drop to EL1 (see
el2_setup). As Andre mentioned on the previous thread, U-boot is
running
at EL2 on various board (e.g pine64, juno).

Modifying the firmware was the right way to go as there is no
solution
go boot at EL2 from EL1.



Yes, correct, from general point of view :)

My question to Iurii is more focused to this concrete board, if
there everything works fine, too. You know, sometimes the
implementation on a board might have bugs while it should work well
in theory ;)

So I'm just interested if everything works fine for him switching
ATF to exit in EL2, or if additional fixes/patches are needed for
this board.


Looks like all basic functions working normally - I have successfully
load linux & rootfs without any additional patches for linux kernel.



Ok, thanks for this info :)



As you ok with this - I will create Salvator-X board related page on Xen
wiki.
But first of all, I will update yocto layer mentioned by Andrii with
minimal setup, based on the latest Renesas & Xen releases.
This should be helpful for easier out of box board setup.



Ack

Best regards

Dirk



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

flight 102076 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102076/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf faabc5d49700a5042535ff30a07e2c9577ed3cd8
baseline version:
 ovmf c3c9892c3b4dafd1d0ccdc8e5e017d80e8c4361e

Last test of basis   102065  2016-11-09 10:17:52 Z0 days
Testing same since   102076  2016-11-09 19:46:42 Z0 days1 attempts


People who touched revisions under test:
  Maurice Ma 

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=faabc5d49700a5042535ff30a07e2c9577ed3cd8
+ . ./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 
faabc5d49700a5042535ff30a07e2c9577ed3cd8
+ branch=ovmf
+ revision=faabc5d49700a5042535ff30a07e2c9577ed3cd8
+ . ./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
+ '[' xfaabc5d49700a5042535ff30a07e2c9577ed3cd8 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.g

Re: [Xen-devel] [PATCH] Fix misleading indentation warnings

[Cedric Bosdonnat]

Hi Juergen,

Just resent the patch with the missing Signed-off-By and --cc-cmd 
'./scripts/get_maintainers.pl'

--
Cedric

On Thu, 2016-11-10 at 09:42 +0100, Juergen Gross wrote:
> On 10/11/16 09:37, Cédric Bosdonnat wrote:
> > Gcc6 build reports misleading indentation as warnings. Fix a few
> > warnings in stubdom.
> 
> You should CC: the maintainers. Calling
> 
> ./scripts/get_maintainer.pl 
> 
> will show them. Added them for now.
> 
> 
> Juergen
> 
> > ---
> >  stubdom/vtpmmgr/disk_read.c | 8 
> >  stubdom/vtpmmgr/log.c   | 2 +-
> >  2 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
> > index 944d3ff..48cfbfe 100644
> > --- a/stubdom/vtpmmgr/disk_read.c
> > +++ b/stubdom/vtpmmgr/disk_read.c
> > @@ -123,10 +123,10 @@ static int parse_root_key(struct mem_tpm_mgr *dst, 
> > struct disk_seal_entry *src)
> >     struct disk_root_sealed_data sealed;
> >  
> >  /*TPM 2.0 unbind | TPM 1.x unseal*/
> > -if (hw_is_tpm2())
> > -rc = TPM2_disk_unbind(&sealed, &olen, src);
> > -else
> > -rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
> > +   if (hw_is_tpm2())
> > +   rc = TPM2_disk_unbind(&sealed, &olen, src);
> > +   else
> > +   rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
> >  
> >     if (rc)
> >     return rc;
> > diff --git a/stubdom/vtpmmgr/log.c b/stubdom/vtpmmgr/log.c
> > index a82c913..c1bc8f3 100644
> > --- a/stubdom/vtpmmgr/log.c
> > +++ b/stubdom/vtpmmgr/log.c
> > @@ -147,5 +147,5 @@ const char* tpm_get_error_name (TPM_RESULT code) {
> >  if (code == error_msgs[i].code)
> >    return error_msgs[i].code_name;
> >  
> > -return("Unknown Error Code");
> > +  return("Unknown Error Code");
> >  }
> > 
> 
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel