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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf b41ef32518095f783d0c2343b496cc857c6f3dff
baseline version:
 ovmf 05b2f9c94e0c0b663ff2d2fb55397d8215eeb3f5

Last test of basis94503  2016-05-17 08:16:00 Z0 days
Testing same since94519  2016-05-17 14:41:41 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Laszlo Ersek 
  Maurice Ma 
  Zenith432 

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=b41ef32518095f783d0c2343b496cc857c6f3dff
+ . ./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 
b41ef32518095f783d0c2343b496cc857c6f3dff
+ branch=ovmf
+ revision=b41ef32518095f783d0c2343b496cc857c6f3dff
+ . ./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.6-testing
+ '[' xb41ef32518095f783d0c2343b496cc857c6f3dff = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ 

[Xen-devel] [xen-4.4-testing test] 94515: tolerable FAIL - PUSHED

[osstest service owner]

flight 94515 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94515/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-install fail like 94038
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94065
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94065
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94065

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   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-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  09f9f792b5af8023c95e445aeba94cb9bffcc45f
baseline version:
 xen  ab6f8993136a10fee4336e0cbb90f491ce505212

Last test of basis94065  2016-05-12 21:56:42 Z5 days
Testing same since94515  2016-05-17 13:12:36 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 

[Xen-devel] [qemu-mainline baseline-only test] 44425: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44425 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44425/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]
 test-amd64-amd64-xl-pvh-amd   6 xen-boot  fail REGR. vs. 44417
 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 44417

Regressions which are regarded as allowable (not blocking):
 build-armhf-xsm   3 host-install(3)  broken like 44417
 build-armhf-pvops 3 host-install(3)  broken like 44417
 build-armhf   3 host-install(3)  broken like 44417
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 44417
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 44417

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuuc98e7937119503d06dbb494b7e4806ec66a27df0
baseline version:
 qemuu70f87e0f0aa04f764dabaeb3ed71ff195748076a

Last test of basis44417  2016-05-14 23:28:33 Z3 days
Testing same since44425  2016-05-17 23:20:21 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 
  Samuel Thibault 
  Thomas Huth 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

[Tamas K Lengyel]

On Tue, May 17, 2016 at 8:43 PM, Big Strong  wrote:
> Should the VMFUNC and #VE must run in kernel mode? I.E. as a linux kernel
> module or windows driver? if it is, how to invoke hypercall from the domU
> kernel, by ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall) or directly issue
> 0x82 interrupt?

The idea with #VE is that it converts the EPT violation to a specific
in-guest interrupt. Interrupts are handled by the kernel, so you will
need a kernel module that is handling that interrupt. Also, you can
take a look at the xen-privcmd kernel module in the Linux kernel to
get an idea on how to issue hypercalls.

Tamas

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

[Xen-devel] [xen-unstable test] 94507: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 94487

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm  5 xen-installfail in 94495 pass in 94507
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail pass in 
94495

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-install  fail in 94495 blocked in 94487
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 94495 like 94487
 build-i386-rumpuserxen6 xen-buildfail   like 94487
 build-amd64-rumpuserxen   6 xen-buildfail   like 94487
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94487
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94487
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94487
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 94487
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94487

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

version targeted for testing:
 xen  2c86f0e1ac35b4c9e9502d969693f3264d3eda1e
baseline version:
 xen  ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83

Last test of basis94487  2016-05-16 15:18:47 Z1 days
Testing same since94495  2016-05-17 00:15:00 Z1 days2 attempts


People who touched revisions under test:
  Peng Fan 

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

Should the VMFUNC and #VE must run in kernel mode? I.E. as a linux kernel
module or windows driver? if it is, how to invoke hypercall from the domU
kernel, by ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall) or directly issue
0x82 interrupt?

2016-05-17 20:05 GMT+08:00 Big Strong :

> I just set the domid to DOMID_SELF to pass the check, but another problem
> is how to assign the gfn used to store #ve infomation. As I'm doing all the
> things in user space, directly assign a new physical page seems impossible.
> While LKM can do that with kmalloc and virt_to_phys, it cannot call user
> space functions of libxc. Is there a libxc function to translate the
> virtual address of malloc() to physical address?
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 3/6] build: convert verbose to Kconfig

[Doug Goldstein]

On 5/12/16 4:04 AM, Jan Beulich wrote:
 On 11.05.16 at 19:37,  wrote:
>> On 5/11/16 4:45 AM, Jan Beulich wrote:
>> On 10.05.16 at 23:05,  wrote:
 --- a/xen/Kconfig.debug
 +++ b/xen/Kconfig.debug
 @@ -15,4 +15,11 @@ config DEBUG
  option is intended for development purposes only, and not for
  production use.
  
 +config VERBOSE_DEBUG
 +  bool "Verbose debug messages"
 +  default DEBUG
 +  ---help---
 +Guest output from HYPERVISOR_console_io and hypervisor parsing
 +ELF images (dom0) is logged in the Xen ring buffer.
>>>
>>> The "depends on DEBUG || EXPERT" did get lost here (or, looking at
>>> the following patch, a respective "if" framing them all).
>>
>> This option is always visible to someone and is not dependent on DEBUG
>> due to the if not being possible in the form you asked. So I adjusted it
>> to "default DEBUG" as you had asked. I can make this option dependent on
>> DEBUG or EXPERT.
> 
> Same here - with the menuconfig gone, I don't see why.
> 
> Jan
> 

So no change? From the first email I gather that it should be "depends
on DEBUG || EXPERT" but from the last one I gather no change.

-- 
Doug Goldstein



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

[Xen-devel] [qemu-upstream-4.3-testing test] 94525: trouble: blocked/broken

[osstest service owner]

flight 94525 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94525/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  101 days
Testing same since93977  2016-05-10 11:09:16 Z7 days   20 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [PATCH v3 2/6] build: convert crash_debug to Kconfig

[Doug Goldstein]

On 5/12/16 4:03 AM, Jan Beulich wrote:
 On 11.05.16 at 19:35,  wrote:
>> On 5/11/16 4:47 AM, Jan Beulich wrote:
>> On 10.05.16 at 23:05,  wrote:
 --- a/xen/Kconfig.debug
 +++ b/xen/Kconfig.debug
 @@ -1,6 +1,13 @@
  
  menu "Debugging Options"
  
 +config CRASH_DEBUG
 +  bool "Crash Debugging Support"
 +  depends on X86
 +  ---help---
 +If you want to be able to attach gdb to Xen to be able to debug
 +Xen if it crashes then say Y.
 +
  config DEBUG
bool "Developer Checks"
---help---
>>>
>>> Is this really meant to be independent of DEBUG (or EXPERT), as it's
>>> being placed ahead of DEBUG?
>>
>> That's what we talked about with v2. You wanted it to be independent if
>> EXPERT was set but when you have something defined as "menuconfig "
>> you cannot then have a rule "if  || EXPERT" as you asked for in v2.
>> So I needed to make them independent always which is what I did.
>>
>> Let me restate more generically, if things are dependent on a menu for
>> the sub-menu items to be displayed (as in v2) then the menu must be
>> enabled and cannot be conditionally displayed on another option.
>>
>> Roughly think of it this way:
>>
>> menuconfig SOME_STATE
>>
>> if SOME_STATE || EXPERT
>>
>> config OTHER
>>
>> endif
>>
>>
>> is the following code:
>>
>>
>> if (SOME_STATE) {
>>   if (SOME_STATE or EXPERT) {
>> printf("got here\n");
>>   }
>> }
> 
> But there's no menuconfig anymore, for precisely that reason (aiui).
> 
> Jan
> 

Right. That's what I was trying to get across. What I gathered from past
reviews is that it should to be independent of DEBUG correct?

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH RFC] Tmem cleanups for 4.7 (hopefully?).

[Doug Goldstein]

On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> These four little cleanups move the bulk of tmem control ops
> from tmem.c to tmem_control.c.
> 
> Last release I moved the control tmem ops from being part of tmem
> hypercall to be part of the syscall subops - and this is the next
> step in this cleanup. (See
> http://lists.xen.org/archives/html/xen-devel/2015-10/msg03313.html)
> which will allow me to follow up on the other steps:
>  b) Fix the toolstack (cleanup)
>  c) tmem tze, dedup, and zlib code drop
> 
> Anyhow sorry for this being so tardy - xSplice had more attention :-)
> 
> Regression tests show no problems.
> 
> The patches themselves have no functionality changes thought I was itching
> to remove most of the counters. I will do that going forward, but need
> to figure out which ones make sense or if some of them can be coalesced.
> 
>  xen/common/Makefile|   2 +-
>  xen/common/tmem.c  | 618 
> +
>  xen/common/tmem_control.c  | 443 +
>  xen/include/xen/tmem_control.h |  33 +++
>  xen/include/xen/tmem_xen.h | 128 +
>  5 files changed, 672 insertions(+), 552 deletions(-)
> 
> Konrad Rzeszutek Wilk (4):
>   tmem: Move global stats in a tmem_statistics structure
>   tmem: Wrap atomic_t in struct tmem_statistics as well.
>   tmem: Move global_ individual variables in a global structure.
>   tmem: Move bulk of tmem control functions in its own file.
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

So overall applying all 4 patches results in something that I think is
better. I think some improvement on the bisect-ability of the patches
and I'll toss my Reviewed-by: Doug Goldstein  on the
series.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH RFC 1/4] tmem: Move global stats in a tmem_statistics structure

[Doug Goldstein]

On 5/17/16 8:57 PM, Doug Goldstein wrote:
> On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
>> And adjust the macro: atomic_inc_and_max to update the structure.
>>
>> Sadly one entry: pool->pgp_count cannot use this macro anymore
>> so unroll the macro for this instance.
>>
>> No functional change. The name has the 'tmem_stats' as it will
>> be eventually non-local.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk 
>> ---
>>  xen/common/tmem.c | 135 
>> +-
>>  1 file changed, 73 insertions(+), 62 deletions(-)
>>
>> diff --git a/xen/common/tmem.c b/xen/common/tmem.c
>> index 16e249a..d362eae 100644
>> --- a/xen/common/tmem.c
>> +++ b/xen/common/tmem.c
>> @@ -28,25 +28,32 @@
>>  #define TMEM_SPEC_VERSION 1
>>  
>>  /* Global statistics (none need to be locked). */
>> -static unsigned long total_tmem_ops = 0;
>> -static unsigned long errored_tmem_ops = 0;
>> -static unsigned long total_flush_pool = 0;
>> -static unsigned long alloc_failed = 0, alloc_page_failed = 0;
>> -static unsigned long evicted_pgs = 0, evict_attempts = 0;
>> -static unsigned long relinq_pgs = 0, relinq_attempts = 0;
>> -static unsigned long max_evicts_per_relinq = 0;
>> -static unsigned long low_on_memory = 0;
>> -static unsigned long deduped_puts = 0;
>> -static unsigned long tot_good_eph_puts = 0;
>> -static int global_obj_count_max = 0;
>> -static int global_pgp_count_max = 0;
>> -static int global_pcd_count_max = 0;
>> -static int global_page_count_max = 0;
>> -static int global_rtree_node_count_max = 0;
>> -static long global_eph_count_max = 0;
>> -static unsigned long failed_copies;
>> -static unsigned long pcd_tot_tze_size = 0;
>> -static unsigned long pcd_tot_csize = 0;
>> +struct tmem_statistics {
>> +unsigned long total_tmem_ops;
>> +unsigned long errored_tmem_ops;
>> +unsigned long total_flush_pool;
>> +unsigned long alloc_failed;
>> +unsigned long alloc_page_failed;
>> +unsigned long evicted_pgs;
>> +unsigned long evict_attempts;
>> +unsigned long relinq_pgs;
>> +unsigned long relinq_attempts;
>> +unsigned long max_evicts_per_relinq;
>> +unsigned long low_on_memory;
>> +unsigned long deduped_puts;
>> +unsigned long tot_good_eph_puts;
>> +int global_obj_count_max;
>> +int global_pgp_count_max;
>> +int global_pcd_count_max;
>> +int global_page_count_max;
>> +int global_rtree_node_count_max;
>> +long global_eph_count_max;
>> +unsigned long failed_copies;
>> +unsigned long pcd_tot_tze_size;
>> +unsigned long pcd_tot_csize;
>> +};
>> +
>> +static struct tmem_statistics tmem_stats;
>>  
>>  / CORE DATA STRUCTURES /
>>  
>> @@ -225,8 +232,8 @@ static atomic_t global_rtree_node_count = ATOMIC_INIT(0);
>>  
>>  #define atomic_inc_and_max(_c) do { \
>>  atomic_inc(&_c); \
>> -if ( _atomic_read(_c) > _c##_max ) \
>> -_c##_max = _atomic_read(_c); \
>> +if ( _atomic_read(_c) > tmem_stats._c##_max ) \
>> +tmem_stats._c##_max = _atomic_read(_c); \
>>  } while (0)
>>  
>>  #define atomic_dec_and_assert(_c) do { \
>> @@ -273,7 +280,7 @@ static void *tmem_malloc(size_t size, struct tmem_pool 
>> *pool)
>>  v = xmem_pool_alloc(size, tmem_mempool);
>>  }
>>  if ( v == NULL )
>> -alloc_failed++;
>> +tmem_stats.alloc_failed++;
>>  return v;
>>  }
>>  
>> @@ -300,7 +307,7 @@ static struct page_info *tmem_alloc_page(struct 
>> tmem_pool *pool)
>>  else
>>  pfp = __tmem_alloc_page();
>>  if ( pfp == NULL )
>> -alloc_page_failed++;
>> +tmem_stats.alloc_page_failed++;
>>  else
>>  atomic_inc_and_max(global_page_count);
> 
> So the code was previously like this but this change made me notice
> this. How come tmem_stats.global_page_count needs to be atomically
> incremented but not tmem_stats.alloc_page_failed? Its also a little
> weird that global_page_count is in the struct now but not really visible
> here while alloc_page_count is in the struct but has to be explicitly
> called out.
> 
> 

Actually I just realized "global_page_count" but this patch actually
deals with "global_page_count_max". So ignore the original email.

But does this patch compile (for bisect-ability) due to the change to
atomic_inc_and_max() but not moving "global_page_count" into the structure?

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH RFC 1/4] tmem: Move global stats in a tmem_statistics structure

[Doug Goldstein]

On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
> And adjust the macro: atomic_inc_and_max to update the structure.
> 
> Sadly one entry: pool->pgp_count cannot use this macro anymore
> so unroll the macro for this instance.
> 
> No functional change. The name has the 'tmem_stats' as it will
> be eventually non-local.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  xen/common/tmem.c | 135 
> +-
>  1 file changed, 73 insertions(+), 62 deletions(-)
> 
> diff --git a/xen/common/tmem.c b/xen/common/tmem.c
> index 16e249a..d362eae 100644
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -28,25 +28,32 @@
>  #define TMEM_SPEC_VERSION 1
>  
>  /* Global statistics (none need to be locked). */
> -static unsigned long total_tmem_ops = 0;
> -static unsigned long errored_tmem_ops = 0;
> -static unsigned long total_flush_pool = 0;
> -static unsigned long alloc_failed = 0, alloc_page_failed = 0;
> -static unsigned long evicted_pgs = 0, evict_attempts = 0;
> -static unsigned long relinq_pgs = 0, relinq_attempts = 0;
> -static unsigned long max_evicts_per_relinq = 0;
> -static unsigned long low_on_memory = 0;
> -static unsigned long deduped_puts = 0;
> -static unsigned long tot_good_eph_puts = 0;
> -static int global_obj_count_max = 0;
> -static int global_pgp_count_max = 0;
> -static int global_pcd_count_max = 0;
> -static int global_page_count_max = 0;
> -static int global_rtree_node_count_max = 0;
> -static long global_eph_count_max = 0;
> -static unsigned long failed_copies;
> -static unsigned long pcd_tot_tze_size = 0;
> -static unsigned long pcd_tot_csize = 0;
> +struct tmem_statistics {
> +unsigned long total_tmem_ops;
> +unsigned long errored_tmem_ops;
> +unsigned long total_flush_pool;
> +unsigned long alloc_failed;
> +unsigned long alloc_page_failed;
> +unsigned long evicted_pgs;
> +unsigned long evict_attempts;
> +unsigned long relinq_pgs;
> +unsigned long relinq_attempts;
> +unsigned long max_evicts_per_relinq;
> +unsigned long low_on_memory;
> +unsigned long deduped_puts;
> +unsigned long tot_good_eph_puts;
> +int global_obj_count_max;
> +int global_pgp_count_max;
> +int global_pcd_count_max;
> +int global_page_count_max;
> +int global_rtree_node_count_max;
> +long global_eph_count_max;
> +unsigned long failed_copies;
> +unsigned long pcd_tot_tze_size;
> +unsigned long pcd_tot_csize;
> +};
> +
> +static struct tmem_statistics tmem_stats;
>  
>  / CORE DATA STRUCTURES /
>  
> @@ -225,8 +232,8 @@ static atomic_t global_rtree_node_count = ATOMIC_INIT(0);
>  
>  #define atomic_inc_and_max(_c) do { \
>  atomic_inc(&_c); \
> -if ( _atomic_read(_c) > _c##_max ) \
> -_c##_max = _atomic_read(_c); \
> +if ( _atomic_read(_c) > tmem_stats._c##_max ) \
> +tmem_stats._c##_max = _atomic_read(_c); \
>  } while (0)
>  
>  #define atomic_dec_and_assert(_c) do { \
> @@ -273,7 +280,7 @@ static void *tmem_malloc(size_t size, struct tmem_pool 
> *pool)
>  v = xmem_pool_alloc(size, tmem_mempool);
>  }
>  if ( v == NULL )
> -alloc_failed++;
> +tmem_stats.alloc_failed++;
>  return v;
>  }
>  
> @@ -300,7 +307,7 @@ static struct page_info *tmem_alloc_page(struct tmem_pool 
> *pool)
>  else
>  pfp = __tmem_alloc_page();
>  if ( pfp == NULL )
> -alloc_page_failed++;
> +tmem_stats.alloc_page_failed++;
>  else
>  atomic_inc_and_max(global_page_count);

So the code was previously like this but this change made me notice
this. How come tmem_stats.global_page_count needs to be atomically
incremented but not tmem_stats.alloc_page_failed? Its also a little
weird that global_page_count is in the struct now but not really visible
here while alloc_page_count is in the struct but has to be explicitly
called out.


-- 
Doug Goldstein



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

[Xen-devel] [qemu-mainline test] 94506: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94248
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94248

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-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
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuuc98e7937119503d06dbb494b7e4806ec66a27df0
baseline version:
 qemuu70f87e0f0aa04f764dabaeb3ed71ff195748076a

Last test of basis94248  2016-05-14 10:22:33 Z3 days
Testing same since94506  2016-05-17 09:48:40 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 
  Samuel Thibault 
  Thomas Huth 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 

Re: [Xen-devel] [sh_eth.c] Problem in dma_map_single()

[Konrad Rzeszutek Wilk]

On Fri, Apr 15, 2016 at 12:39:42PM +0900, Wonseok Ko wrote:
> ​Hi Konrad,​
> 
> Finally, I can use ethernet :D. It was my mistake. I thought the
> SET_NETDEV_DEV() makes ndev == pdev->dev, but it's not true.
> 
> So I changed the dma configuration from:
> 
> dma_coerce_mask_and_coherent(*>dev*, DMA_BIT_MASK(32));
> SET_NETDEV_DEV(ndev, >dev);
> 
> 
> to:
> 
> dma_coerce_mask_and_coherent(*>dev*, DMA_BIT_MASK(32));
> SET_NETDEV_DEV(ndev, >dev);
> 
> 
> and then sh_eth works.
> 
> However I wanted to set dma_mask in pdev, I just thought about the original
> data have a mask bit.
> Do you know how do I set dma_mask in pdev?

That is some weird propogation. Is the pdev->dev the same as ndev->dev?

> Thank you for your help!
> 
> Thanks,
> Wonseok.
> 
> 
> Thanks,
> Wonseok.
> 
> 2016-04-14 22:52 GMT+09:00 Konrad Rzeszutek Wilk :
> 
> > On Wed, Apr 13, 2016 at 02:18:09PM +0900, Wonseok Ko wrote:
> > > Hi Konrad,
> > >
> > > In dma_capable(), it checks that mask, size and address of device.
> > >
> > > Currently, it dosen't pass to first condition code as below:
> > >
> > > if (!dev->dma_mask)
> > >
> > > return 0;
> > >
> > > It shows the device doesn't have dma_mask bit. So I tried to set the
> > > dma_mask bit in sh_eth.c
> > >
> > > My approaches:
> > > 1. I tried to set a mask bit(dev->dma_mask) to use
> > > dma_coerce_mask_and_coherent()
> > > in sh_eth_drv_probe(), but it doesn't work.
> >
> > Are there any errors? What does dma_mask end up being?
> > > 2. forced set dev->dma_mask without kernel api. I passed to dma_capable()
> > > but driver cannot work.
> >
> > Aha, what did you set it to? Do you have a diff?
> > >
> > > sh_eth driver want to get valid DMA descriptor to set DMA descriptor
> > > address for Rx and Tx.
> >
> > Right, which it would plug in its driver registers so the card
> > can pick it up.
> > > I tried to set the some bits(such as dma_mask) to get valid dma address
> > > forcibly, in this configuration sh_eth cannot work.
> >
> > Uh, not sure I understand. Or are you repeating what you mentioned
> > earlier?
> > >
> > > My question is if I want to get valid dma address with xen swiotlb(suchas
> > > map_page, set_dma_mask and so on)?
> >
> > Well it all should work just fine - perhaps if you provide some
> > diff's and such I can help you along?
> >
> > >
> > >
> > >
> > >
> > > Thanks,
> > > Wonseok.
> > >
> > > 2016-04-13 2:10 GMT+09:00 Konrad Rzeszutek Wilk  > >:
> > >
> > > > On Tue, Apr 12, 2016 at 04:54:55PM +0900, Wonseok Ko wrote:
> > > > > Hi,
> > > > >
> > > > > I'm trying to enable ethernet driver in Domain0 for R-Car H2, but it
> > > > > doesn't work. The root cause of the problem is that driver cannot
> > satisfy
> > > > > the condition of dma_capable(). I found the same problem in the
> > mailing
> > > >
> > > > So what can be done about making it dma_capable() ?
> > > >
> > > > > list, but the problem is still remaining I guess. previous mail: (
> > > > > http://lists.xen.org/archives/html/xen-devel/2014-10/msg03170.html)
> > > > >
> > > > > Does anyone give me advise?
> > > > >
> > > > > My environment as below:
> > > > > - dom0 linux version: 4.3
> > > > > - xen version: 4.6 commit(40d7a7454835c2f7c639c78f6c09e7b6f0e4a4e2)
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Wonseok.
> > > >
> > > > > ___
> > > > > Xen-devel mailing list
> > > > > Xen-devel@lists.xen.org
> > > > > http://lists.xen.org/xen-devel
> > > >
> > > >
> >

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

Re: [Xen-devel] [Hackathon 16] Notes from Security Session

[Konrad Rzeszutek Wilk]

On Tue, Apr 26, 2016 at 09:57:12AM +0100, Lars Kurth wrote:
> Also adding Steve Maresca to the thread, who has been using XSM extensively 
> and also documenting XSM and can provide some user perspective 
> Lars
> 
> > On 25 Apr 2016, at 20:51, Daniel De Graaf  wrote:
> > 
> > On 04/25/2016 02:32 PM, Konrad Rzeszutek Wilk wrote:
> >> On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:
> >>> On 19/04/16 10:02, Doug Goldstein wrote:
>  On 4/18/16 12:20 PM, Lars Kurth wrote:
> > Hi all,
> >> 
> >> CC-ing XSM maintainer :-)
> > 
> > Thanks. I'm going to comment on this and the wiki.
> > 
> > [...]
> > === Enabling XSM By default ===
> > Andrew: There are some issues which we need to work through; a lot of 
> > little paper cuts
> > Rich: Could we create a list of issues on the wiki?
> > Lars: Definitely
> > Doug: Could we not have a policy which is equivalent to XSM being 
> > compiled out
> > Andrew: Could make policy more modular instead of one big global policy
> > 
> > Re-apply policy of guest after running
> > 
> > ACTION: Need a wiki page, Konrad can start one and we can 
> > collaboratively flesh it out
> > Lars: See http://wiki.xenproject.org/wiki/XSMAsDefault_TODO_List
> > 
> > ACTION: Konrad and others to add detail to it
> > 
> > 
>  It was pointed out to me that I did not get my comments about XSM across
>  clearly. I believe we need to improve the default policy to be
>  equivalent to disabling XSM and/or create a policy called "dummy" that
>  is the same as XSM disabled. To make XSM usage more smooth I propose we
>  bake the default policy into .initdata so that when you boot Xen
>  compiled with XSM you are no worse off than compiling XSM out.
>  
>  The rationale here is that prior to a recent commit when you compiled
>  Xen with XSM enabled but did not provide a default policy then any domUs
>  that you ran had as much access as dom0. The recent commit changed it so
>  that Xen by default does not boot without a policy.
>  
>  With my proposed change we would have "dummy" that would compile in and
>  if you provided another policy it would be used instead or you could
>  late load a replacement policy. Basically filling the gap of turning on
>  XSM and having a system less secure than XSM off until you developed
>  your policy.
> >>> 
> >>> +1.  It also avoids needing to play around loading an extra file as a grub
> >>> module, which makes distro-integration easer.
> >>> 
> >>> ~Andrew
> > 
> > This should be doable, though it will require moving the rest of
> > tools/flask/policy under xen/ for proper dependencies. Beyond that, it
> > would need either a script or a careful invocation of objcopy to convert
> > the policy output to an array in initdata, and then that policy would be
> > used if the bootloader one is not present.

OK, let me take a stab at that. Unless somebody else is already looking
at this?

> > 
> > From the wiki:
> >> XSM with default policy will have:
> >> 
> >>  - Same functionality exposed to guests without regressions
> >>  - Have at minimum the same security as we have without XSM enabled.
> >>  - Have set of policies for device driver domains vs control domains.
> > 
> > The first two bullets should be true with the current policy. The third
> > needs to be more precisely defined: any operation on a group it
> > controls, or limited operations (such as adjusting memory size) on all
> > guests?  The latter will probably need a custom policy (module) for
> > exactly what the control domain does.

Hm. I would have thought that device driver domains would have
limited operations. As in they can do grant maps, PCIe access, etc.
But they cannot do the operations that dom0 has done.

Doug, didn't you do some of this already?
> > 
> >> Known Issues
> >> 
> >>  - Cannot re-apply a new policy after guests have been running.
> > 
> > This is possible via "xl loadpolicy".  There is no (exposed) way to
> > re-label existing domains, but you can create new domains using new
> > types in the policy.  The new policy rules will be enforced immediately
> > on existing domains, but this may not fully tighten restrictions: for
> > example, if a passthrough device is newly disallowed but already mapped
> > by a domain, it will not be unmapped.

Would the audit code mention this? Ah I presume not as the operation
has already been completed and the IOMMU access and such do not do XSM
checks.

But it is good to know that you can relable existing domains.
I was under the mistaken impression you couldn't!

> > 
> >> TODO List
> >> 
> >>  - Could initial build of Xen hypervisor include a built-in (inside 
> >> .init.data) policy file?
> > (Above).
> >>  - Can we make policies modularized? A core (perhaps built-in?) with 
> >> amendments loaded later?
> > 
> > There is already some support for modules in the XSM 

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

[osstest service owner]

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

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  c32381352cce9744e640bf239d2704dae4af4fc7
baseline version:
 xen  46699c7393bd991234b5642763c5c24b6b39a6c4

Last test of basis94514  2016-05-17 13:01:58 Z0 days
Failing since 94521  2016-05-17 15:03:04 Z0 days3 attempts
Testing same since94529  2016-05-17 19:02:33 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Edgar E. Iglesias 
  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=c32381352cce9744e640bf239d2704dae4af4fc7
+ . ./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 
c32381352cce9744e640bf239d2704dae4af4fc7
+ branch=xen-unstable-smoke
+ revision=c32381352cce9744e640bf239d2704dae4af4fc7
+ . ./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.6-testing
+ '[' xc32381352cce9744e640bf239d2704dae4af4fc7 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Kevin Moraga]

On 05/17/2016 09:11 AM, David Vrabel wrote:
> On 11/05/16 11:16, David Vrabel wrote:
>> Why don't we get the RW bits correct when making the pteval when we
>> already have the pfn, instead trying to fix it up afterwards.
> Kevin, can you try this patch.
Yes :D. The patch is working fine.

I only got this warning while compiling:

WARNING: arch/x86/xen/built-in.o(.text+0x257d): Section mismatch in
reference from the variable __raw_callee_save_xen_make_pte_init to the
function .init.text:xen_make_pte_init()
The function __raw_callee_save_xen_make_pte_init() references
the function __init xen_make_pte_init().
This is often because __raw_callee_save_xen_make_pte_init lacks a __init
annotation or the annotation of xen_make_pte_init is wrong.


>
> David
>
> 8<-
> x86/xen: avoid m2p lookup when setting early page table entries
>
> When page tables entries are set using xen_set_pte_init() during early
> boot there is no page fault handler that could handle a fault when
> performing an M2P lookup.
>
> In 64 guest (usually dom0) early_ioremap() would fault in
> xen_set_pte_init() because an M2P lookup faults because the MFN is in
> MMIO space and not mapped in the M2P.  This lookup is done to see if
> the PFN in in the range used for the initial page table pages, so that
> the PTE may be set as read-only.
>
> The M2P lookup can be avoided by moving the check (and clear of RW)
> earlier when the PFN is still available.
>
> [ Not entirely happy with this as the 32/64 bit paths diverge even
>   more. Is there some way to unify them instead? ]
>
> Signed-off-by: David Vrabel 
> ---
>  arch/x86/xen/mmu.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 478a2de..897fad4 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1562,7 +1562,7 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t
> pte)
>   return pte;
>  }
>  #else /* CONFIG_X86_64 */
> -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
> +static pteval_t __init mask_rw_pte(pteval_t pte)
>  {
>   unsigned long pfn;
>
> @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
> pte_t pte)
>* page tables for mapping the p2m list, too, and page tables MUST be
>* mapped read-only.
>*/
> - pfn = pte_pfn(pte);
> + pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
>   if (pfn >= xen_start_info->first_p2m_pfn &&
>   pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
> - pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
> + pte &= ~_PAGE_RW;
>
>   return pte;
>  }
> @@ -1600,13 +1600,26 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
> pte_t pte)
>   * so always write the PTE directly and rely on Xen trapping and
>   * emulating any updates as necessary.
>   */
> +__visible __init pte_t xen_make_pte_init(pteval_t pte)
> +{
> +#ifdef CONFIG_X86_64
> + pte = mask_rw_pte(pte);
> +#endif
> + pte = pte_pfn_to_mfn(pte);
> +
> + if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
> + pte = 0;
> +
> + return native_make_pte(pte);
> +}
> +PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_init);
> +
>  static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>  {
> +#ifdef CONFIG_X86_32
>   if (pte_mfn(pte) != INVALID_P2M_ENTRY)
>   pte = mask_rw_pte(ptep, pte);
> - else
> - pte = __pte_ma(0);
> -
> +#endif
>   native_set_pte(ptep, pte);
>  }
>
> @@ -2407,6 +2420,7 @@ static void __init xen_post_allocator_init(void)
>   pv_mmu_ops.alloc_pud = xen_alloc_pud;
>   pv_mmu_ops.release_pud = xen_release_pud;
>  #endif
> + pv_mmu_ops.make_pte = PV_CALLEE_SAVE(xen_make_pte);
>
>  #ifdef CONFIG_X86_64
>   pv_mmu_ops.write_cr3 = _write_cr3;
> @@ -2455,7 +2469,7 @@ static const struct pv_mmu_ops xen_mmu_ops
> __initconst = {
>   .pte_val = PV_CALLEE_SAVE(xen_pte_val),
>   .pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
>
> - .make_pte = PV_CALLEE_SAVE(xen_make_pte),
> + .make_pte = PV_CALLEE_SAVE(xen_make_pte_init),
>   .make_pgd = PV_CALLEE_SAVE(xen_make_pgd),
>
>  #ifdef CONFIG_X86_PAE

-- 
Sincerely,
Kevin Moraga
PGP: F258EDCB
Fingerprint: 3915 A5A9 959C D18F 0A89 B47E FB4B 55F5 F258 EDCB




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

Re: [Xen-devel] Linux 4.4 boot crash on xen 4.5.3 with dom0_mem == max

[Ed Swierk]

I added some more instrumentation and discovered that the result of
xen_count_remap_pages() (0x85dea) is one less than the actual number
of pages remapped by xen_set_identity_and_remap() (0x85deb).

The two functions differ in their handling of a xen_e820_map entry
whose size is not a multiple of the page size.  The entry starting at
0x68000 has size 0x33400.  xen_count_remap_pages() rounds up when
computing the end_pfn (to 0x9c), while xen_set_identity_and_remap()
rounds down (to 0x9b).  Thus xen_count_remap_pages() counts the
remapped space following the entry as one page smaller than the other
function does.

(Confusingly, the "BIOS-provided physical RAM map" shows both the
start and end addresses rounded down to page boundaries, rather than
the addresses actually provided by the BIOS.)

[0.00] xen_count_remap_pages i=0 addr=0x0 size=0x6 start_pfn=0x0 
end_pfn=0x0
[0.00] xen_count_remap_pages i=0 plus end_pfn=0x60 type=0x1
[0.00] xen_count_remap_pages i=1 addr=0x6 size=0x8000 
start_pfn=0x60 end_pfn=0x60
[0.00] xen_count_remap_pages i=1 plus end_pfn=0x68 type=0x2
[0.00] xen_count_remap_pages i=2 addr=0x68000 size=0x33400 
start_pfn=0x68 end_pfn=0x68
[0.00] xen_count_remap_pages i=2 plus end_pfn=0x9c type=0x1
[0.00] xen_count_remap_pages i=3 addr=0x10 size=0x759fe000 
start_pfn=0x100 end_pfn=0x9c
[0.00] xen_count_remap_pages i=3 plus end_pfn=0x75afe type=0x1
[0.00] xen_count_remap_pages i=4 addr=0x75bab000 size=0x464b000 
start_pfn=0x75bab end_pfn=0x75afe
[0.00] xen_count_remap_pages i=4 plus end_pfn=0x7a1f6 type=0x1
[0.00] xen_count_remap_pages i=5 addr=0x7b7d7000 size=0x29000 
start_pfn=0x7b7d7 end_pfn=0x7a1f6
[0.00] xen_count_remap_pages i=5 plus end_pfn=0x7b800 type=0x1
[0.00] xen_count_remap_pages i=6 addr=0x7bf0 size=0x10 
start_pfn=0x7bf00 end_pfn=0x7b800
[0.00] xen_count_remap_pages i=6 plus end_pfn=0x7c000 type=0x1
[0.00] xen_count_remap_pages i=7 addr=0xc7ffc000 size=0x1000 
start_pfn=0xc7ffc end_pfn=0x7c000
[0.00] xen_count_remap_pages i=7 plus end_pfn=0xc7ffd type=0x2
[0.00] xen_count_remap_pages i=8 addr=0xfbffc000 size=0x1000 
start_pfn=0xfbffc end_pfn=0xc7ffd
[0.00] xen_count_remap_pages i=8 plus end_pfn=0xfbffd type=0x2
[0.00] xen_count_remap_pages i=9 addr=0xfec0 size=0x2000 
start_pfn=0xfec00 end_pfn=0xfbffd
[0.00] xen_count_remap_pages i=9 plus end_pfn=0xfec02 type=0x2
[0.00] xen_count_remap_pages i=10 addr=0xfec4 size=0x1000 
start_pfn=0xfec40 end_pfn=0xfec02
[0.00] xen_count_remap_pages i=10 plus end_pfn=0xfec41 type=0x2
[0.00] xen_count_remap_pages i=11 addr=0xfed2 size=0x1 
start_pfn=0xfed20 end_pfn=0xfec41
[0.00] xen_count_remap_pages i=11 plus end_pfn=0xfed30 type=0x1
[0.00] xen_count_remap_pages i=12 addr=0xfee0 size=0x10 
start_pfn=0xfee00 end_pfn=0xfed30
[0.00] xen_count_remap_pages i=12 plus end_pfn=0xfef00 type=0x2
[0.00] xen_count_remap_pages i=13 addr=0x1 size=0x1f8000 
start_pfn=0x10 end_pfn=0xfef00
[0.00] xen_count_remap_pages i=13 plus end_pfn=0x48 type=0x1
[0.00] xen_count_remap_pages(max_pfn=0x48) == 0x85dea
[0.00] max_pages 0x505dea
[0.00] xen_add_extra_mem(48, 85dea)
[0.00] memblock_reserve(0x48000, 0x85dea000)
[0.00] xen_set_identity_and_remap i=0 addr=0x0 size=0x6 type=0x1
[0.00] xen_set_identity_and_remap i=1 addr=0x6 size=0x8000 type=0x2
[0.00] xen_set_identity_and_remap i=2 addr=0x68000 size=0x33400 type=0x1
[0.00] xen_set_identity_and_remap_chunk start_pfn=0x60 end_pfn=0x68 
nr_pages=0x48 remap_pfn=0x48
[0.00] xen_set_identity_and_remap_chunk i=0x0 cur_pfn=0x60 left=0x8 
size=0x8 remap_range_size=0x1c0
[0.00] xen_set_identity_and_remap i=3 addr=0x10 size=0x759fe000 
type=0x1
[0.00] xen_set_identity_and_remap_chunk start_pfn=0x9b end_pfn=0x100 
nr_pages=0x48 remap_pfn=0x480008
[0.00] xen_set_identity_and_remap_chunk i=0x0 cur_pfn=0x9b left=0x65 
size=0x65 remap_range_size=0x1b8
[0.00] xen_set_identity_and_remap i=4 addr=0x75bab000 size=0x464b000 
type=0x1
[0.00] xen_set_identity_and_remap_chunk start_pfn=0x75afe 
end_pfn=0x75bab nr_pages=0x48 remap_pfn=0x48006d
[0.00] xen_set_identity_and_remap_chunk i=0x0 cur_pfn=0x75afe left=0xad 
size=0xad remap_range_size=0x1bfff93
[0.00] xen_set_identity_and_remap i=5 addr=0x7b7d7000 size=0x29000 
type=0x1
[0.00] xen_set_identity_and_remap_chunk start_pfn=0x7a1f6 
end_pfn=0x7b7d7 nr_pages=0x48 remap_pfn=0x48011a
[0.00] xen_set_identity_and_remap_chunk i=0x0 cur_pfn=0x7a1f6 
left=0x15e1 size=0x15e1 remap_range_size=0x1bffee6
[0.00] xen_set_identity_and_remap i=6 addr=0x7bf0 size=0x10 
type=0x1
[0.00] 

Re: [Xen-devel] Question about running Xen on NVIDIA Jetson-TK1

[Konrad Rzeszutek Wilk]

On Tue, May 17, 2016 at 12:31:10PM -0400, Chris Patterson wrote:
> On Tue, May 17, 2016 at 9:37 AM, Konrad Rzeszutek Wilk
>  wrote:
> >> - The serial controller on the Tegra SoCs doesn't behave in the same
> >> was as most NS16550-compatibles; it actually adheres to the NS16550
> >> spec a little more rigidly than most compatible controllers. A
> >> coworker (Chris Patterson, cc'd) figured out what was going on; from
> >> what I understand, most 16550s generate the "transmit ready" interrupt
> >> once, when the device first can accept new FIFO entries. Both the
> >> original 16550 and the Tegra implementation generate the "transmit
> >> ready" interrupt /continuously/ when there's space available in the
> >> FIFO, slewing the CPU with a stream of constant interrupts.
> >
> > That may also be an issue on x86 I would think.
> >
> 
> On the x86 serial I have tested, it appears that the THRE interrupt
> goes low after the IIR read reset, and doesn't re-assert until
> UART_IER is flipped (or data is transmitted).  On the Tegra, the
> interrupt persists (or immediately re-asserts) after the IIR read
> reset.  I suppose this could be a problem on x86 if this behaviour
> exists in another uart.
> 
> > Is there some simple 16550 'fix' for this? As in reprogram it
> > to not be soo ready?
> 
> Yes, I do have a patch in my queue to address this. It simply
> implements the start_tx and stop_tx hooks and sets or masks
> UART_IER_ETHREI accordingly.  I believe this behaviour is consistent
> with the Linux kernel.  I have done some limited testing on it with
> both x86 and the Tegra (with additional patches for Tegra support) and
> things appear to work well. I can RFC it when our employer gives us
> approval.  Apologies for the delay.

Awesome! Looking forward to them and reviewing them!
> 
> Have a good day!
> -Chris

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

[Xen-devel] [xen-unstable-smoke test] 94528: regressions - trouble: blocked/broken/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   3 host-install(3) broken REGR. vs. 94514
 build-amd64   5 xen-build fail REGR. vs. 94514

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1) blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  a5adcee740df2679cf6828535279d8f8cbe2eff1
baseline version:
 xen  46699c7393bd991234b5642763c5c24b6b39a6c4

Last test of basis94514  2016-05-17 13:01:58 Z0 days
Failing since 94521  2016-05-17 15:03:04 Z0 days2 attempts
Testing same since94528  2016-05-17 17:01:23 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64  fail
 build-armhf  broken  
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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

broken-step build-armhf host-install(3)

Not pushing.


commit a5adcee740df2679cf6828535279d8f8cbe2eff1
Author: Andrew Cooper 
Date:   Fri May 13 19:38:41 2016 +0100

x86/cpuid: Avoid unconditionally clobbering ITSC for guests

In general, Invariant TSC is not a feature which can be advertised to 
guests,
because it cannot be guaranteed across migrate.  domain_cpuid() goes so far 
as
to deliberately clobber the feature flag under a number of circumstances.

Because ITSC is absent from the static {pv,hvm}_featureset masks, c/s 
b648feff
"xen/x86: Improvements to in-hypervisor cpuid sanity checks" caused ITSC to 
be
unconditionally masked out.

As an interim solution, include the hosts idea of ITSC along with the static
{pv,hvm}_featureset when restricting the guests view of features.  This 
causes
the hardware domain, and VMs explicitly configured with ITSC and no-migrate 
to
be offered ITSC (subject to hardware availability).

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Release-acked-by: Wei Liu 

commit 9e28baf22ec98a64f68757eff39df72173d5f1bb
Author: Jan Beulich 
Date:   Tue May 17 16:42:15 2016 +0200

x86: make SMEP/SMAP suppression tolerate NMI/MCE at the "wrong" time

There is one instruction boundary where any kind of interruption would
break the assumptions cr4_pv32_restore's debug mode checking makes on
the correlation between the CR4 register value and its in-memory cache.
Correct this (see the code comment) even in non-debug mode, or else
a subsequent cr4_pv32_restore would also be misguided into thinking the
features are enabled when they really aren't.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Release-acked-by: Wei Liu 

commit e5e73163ec40b409151f2170d8e406a72b515ff2
Author: Jan Beulich 
Date:   Tue May 17 16:41:35 2016 +0200

x86: refine debugging of SMEP/SMAP fix

Instead of just latching cr4_pv32_mask into %rdx, correct the found
wrong value in %cr4 (to avoid triggering another BUG). The value left
in %rdx should be sufficient for deducing cr4_pv32_mask from the
register dump.

Also there is one more place for XEN_CR4_PV32_BITS to be used.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Release-acked-by: Wei Liu 
(qemu 

[Xen-devel] [ANNOUNCEMENT] Xen 4.7 RC3

[Wei Liu]

Hi all

Xen 4.7 RC3 is tagged. You can check that out from xen.git:

  git://xenbits.xen.org/xen.git 4.7.0-rc3

For you convenience there is also tarball at:
http://bits.xensource.com/oss-xen/release/4.7.0-rc3/xen-4.7.0-rc3.tar.gz

And the signature is at:
http://bits.xensource.com/oss-xen/release/4.7.0-rc3/xen-4.7.0-rc3.tar.gz.sig

Please send bug reports and test reports to
xen-de...@lists.xenproject.org. When sending bug reports, please CC
relevant maintainers and me (wei.l...@citrix.com).

Thanks
Wei.


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

Re: [Xen-devel] [PATCH RFC] Tmem cleanups for 4.7 (hopefully?).

[Wei Liu]

On Mon, May 16, 2016 at 11:58:27AM -0400, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> These four little cleanups move the bulk of tmem control ops
> from tmem.c to tmem_control.c.
> 
> Last release I moved the control tmem ops from being part of tmem
> hypercall to be part of the syscall subops - and this is the next

This needs review or ack from other HV maintainers.

Since TMEM is still experimental and pretty well isolated  so I don't
mind having some code churns in it at this stage.

Wei.

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 05b2f9c94e0c0b663ff2d2fb55397d8215eeb3f5
baseline version:
 ovmf 7b13510f2a0a2a118cdafdaa67720ca8e3fe37de

Last test of basis44423  2016-05-17 08:20:41 Z0 days
Testing same since44424  2016-05-17 14:50:00 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 

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 05b2f9c94e0c0b663ff2d2fb55397d8215eeb3f5
Author: Dandan Bi 
Date:   Tue May 10 18:51:44 2016 +0800

MdeModulePkg/SetupBrowser: Clean the BufferValue for string before use

When copy new string content to BufferValue, need to clean the
BufferValue firstly, or the BufferValue may contain some
content that doesn't belong to the new string.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
Reviewed-by: Liming Gao 

commit fa209e8c20d787c35dbb90c3c33f6db959aa1252
Author: Dandan Bi 
Date:   Wed May 11 10:04:19 2016 +0800

MdeModulePkg/SetupBrowser: Should free ConfigResp when it no longer be used

When submit form fail, the progress point to the first fail part
in ConfigResp, so should free the ConfigResp after Progrss has
been processed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 

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

Re: [Xen-devel] Bug in x86 instruction emulator?

[Andrew Cooper]

On 17/05/16 17:53, William Z. wrote:
> On 2016-05-04 18:02, Jan Beulich wrote:
> On 06.04.16 at 01:38,  wrote:
>>> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
>>> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
>>> Linux distros have been tested and Xorg segfaults in all.
>>
>> So I've been wanting to make an attempt to repro this, but qemu
>> keeps telling me
>>
>> qemu-system-i386: -device qxl-vga,vram_size_mb=64,ram_size_mb=64:
>> 'qxl-vga' is not a valid device model name
>>
>> when I pass vga="qxl" upon guest creation. My knowledge on
>> qemu is limited, so I have no idea what I might be doing wrong.
>>
>> Jan
>
> When the HVM is able to boot, it should be very easy to repo, but
> I can create a LiveCD that will repo, if necessary.

I am terribly sorry - I keep on getting diverted onto other things.

A LiveCD with qxl already configured would be fantastically helpful.

~Andrew

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

[Xen-devel] [xen-unstable-smoke test] 94521: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 94514

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 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  9e28baf22ec98a64f68757eff39df72173d5f1bb
baseline version:
 xen  46699c7393bd991234b5642763c5c24b6b39a6c4

Last test of basis94514  2016-05-17 13:01:58 Z0 days
Testing same since94521  2016-05-17 15:03:04 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  fail
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 9e28baf22ec98a64f68757eff39df72173d5f1bb
Author: Jan Beulich 
Date:   Tue May 17 16:42:15 2016 +0200

x86: make SMEP/SMAP suppression tolerate NMI/MCE at the "wrong" time

There is one instruction boundary where any kind of interruption would
break the assumptions cr4_pv32_restore's debug mode checking makes on
the correlation between the CR4 register value and its in-memory cache.
Correct this (see the code comment) even in non-debug mode, or else
a subsequent cr4_pv32_restore would also be misguided into thinking the
features are enabled when they really aren't.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Release-acked-by: Wei Liu 

commit e5e73163ec40b409151f2170d8e406a72b515ff2
Author: Jan Beulich 
Date:   Tue May 17 16:41:35 2016 +0200

x86: refine debugging of SMEP/SMAP fix

Instead of just latching cr4_pv32_mask into %rdx, correct the found
wrong value in %cr4 (to avoid triggering another BUG). The value left
in %rdx should be sufficient for deducing cr4_pv32_mask from the
register dump.

Also there is one more place for XEN_CR4_PV32_BITS to be used.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Release-acked-by: Wei Liu 
(qemu changes not included)

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

Re: [Xen-devel] Bug in x86 instruction emulator?

[William Z.]

On 2016-05-04 18:02, Jan Beulich wrote:

On 06.04.16 at 01:38,  wrote:

I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
with vga="qxl", Xorg will segfault instantly if tried started. 
Multiple

Linux distros have been tested and Xorg segfaults in all.


So I've been wanting to make an attempt to repro this, but qemu
keeps telling me

qemu-system-i386: -device qxl-vga,vram_size_mb=64,ram_size_mb=64:
'qxl-vga' is not a valid device model name

when I pass vga="qxl" upon guest creation. My knowledge on
qemu is limited, so I have no idea what I might be doing wrong.

Jan


When the HVM is able to boot, it should be very easy to repo, but
I can create a LiveCD that will repo, if necessary.

William Z.

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

Re: [Xen-devel] xen-netback: add control protocol implementation

[Paul Durrant]

> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: 17 May 2016 17:32
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org
> Subject: re: xen-netback: add control protocol implementation
> 
> Hello Paul Durrant,
> 
> The patch 40d8abdee806: "xen-netback: add control protocol
> implementation" from May 13, 2016, leads to the following static
> checker warning:
> 
>   drivers/net/xen-netback/hash.c:362 xenvif_set_hash_mapping()
>   warn: should this be 'len == -1'
> 
> drivers/net/xen-netback/hash.c
>341  u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, u32 len,
>342  u32 off)
>343  {
>344  u32 *mapping = >hash.mapping[off];
>345  struct gnttab_copy copy_op = {
>346  .source.u.ref = gref,
>347  .source.domid = vif->domid,
>348  .dest.u.gmfn = virt_to_gfn(mapping),
>349  .dest.domid = DOMID_SELF,
>350  .dest.offset = xen_offset_in_page(mapping),
>351  .len = len * sizeof(u32),
>352  .flags = GNTCOPY_source_gref
>353  };
>354
>355  if ((off + len > vif->hash.size) || copy_op.len > 
> XEN_PAGE_SIZE)
>356  return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
>357
>358  while (len-- != 0)
>359  if (mapping[off++] >= vif->num_queues)
>360  return 
> XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
>361
>362  if (len != 0) {
> 
> We know that "len" is always UINT_MAX here meaning this is always true.
> What are trying to test?
> 

Yes, that's clearly bogus. The test is supposed to be checking whether the 
copy_op actually does something so it should be:

If (copy_op.len != 0)

I'll send a patch.

  Paul

>363  gnttab_batch_copy(_op, 1);
>364
>365  if (copy_op.status != GNTST_okay)
>366  return 
> XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
>367  }
>368
>369  return XEN_NETIF_CTRL_STATUS_SUCCESS;
>370  }
> 
> regards,
> dan carpenter

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

Re: [Xen-devel] xen-netback: add control protocol implementation

[Dan Carpenter]

Hello Paul Durrant,

The patch 40d8abdee806: "xen-netback: add control protocol
implementation" from May 13, 2016, leads to the following static
checker warning:

drivers/net/xen-netback/hash.c:362 xenvif_set_hash_mapping()
warn: should this be 'len == -1'

drivers/net/xen-netback/hash.c
   341  u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, u32 len,
   342  u32 off)
   343  {
   344  u32 *mapping = >hash.mapping[off];
   345  struct gnttab_copy copy_op = {
   346  .source.u.ref = gref,
   347  .source.domid = vif->domid,
   348  .dest.u.gmfn = virt_to_gfn(mapping),
   349  .dest.domid = DOMID_SELF,
   350  .dest.offset = xen_offset_in_page(mapping),
   351  .len = len * sizeof(u32),
   352  .flags = GNTCOPY_source_gref
   353  };
   354  
   355  if ((off + len > vif->hash.size) || copy_op.len > XEN_PAGE_SIZE)
   356  return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
   357  
   358  while (len-- != 0)
   359  if (mapping[off++] >= vif->num_queues)
   360  return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
   361  
   362  if (len != 0) {

We know that "len" is always UINT_MAX here meaning this is always true.
What are trying to test?

   363  gnttab_batch_copy(_op, 1);
   364  
   365  if (copy_op.status != GNTST_okay)
   366  return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
   367  }
   368  
   369  return XEN_NETIF_CTRL_STATUS_SUCCESS;
   370  }

regards,
dan carpenter

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

Re: [Xen-devel] Question about running Xen on NVIDIA Jetson-TK1

[Chris Patterson]

On Tue, May 17, 2016 at 9:37 AM, Konrad Rzeszutek Wilk
 wrote:
>> - The serial controller on the Tegra SoCs doesn't behave in the same
>> was as most NS16550-compatibles; it actually adheres to the NS16550
>> spec a little more rigidly than most compatible controllers. A
>> coworker (Chris Patterson, cc'd) figured out what was going on; from
>> what I understand, most 16550s generate the "transmit ready" interrupt
>> once, when the device first can accept new FIFO entries. Both the
>> original 16550 and the Tegra implementation generate the "transmit
>> ready" interrupt /continuously/ when there's space available in the
>> FIFO, slewing the CPU with a stream of constant interrupts.
>
> That may also be an issue on x86 I would think.
>

On the x86 serial I have tested, it appears that the THRE interrupt
goes low after the IIR read reset, and doesn't re-assert until
UART_IER is flipped (or data is transmitted).  On the Tegra, the
interrupt persists (or immediately re-asserts) after the IIR read
reset.  I suppose this could be a problem on x86 if this behaviour
exists in another uart.

> Is there some simple 16550 'fix' for this? As in reprogram it
> to not be soo ready?

Yes, I do have a patch in my queue to address this. It simply
implements the start_tx and stop_tx hooks and sets or masks
UART_IER_ETHREI accordingly.  I believe this behaviour is consistent
with the Linux kernel.  I have done some limited testing on it with
both x86 and the Tegra (with additional patches for Tegra support) and
things appear to work well. I can RFC it when our employer gives us
approval.  Apologies for the delay.

Have a good day!
-Chris

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

Re: [Xen-devel] [BUG] Bugs existing Xen's credit scheduler cause long tail latency issues

[Tony S]

On Tue, May 17, 2016 at 3:27 AM, George Dunlap  wrote:
> On Sun, May 15, 2016 at 5:11 AM, Tony S  wrote:
>> Hi all,
>>
>> When I was running latency-sensitive applications in VMs on Xen, I
>> found some bugs in the credit scheduler which will cause long tail
>> latency in I/O-intensive VMs.
>>
>>
>> (1) Problem description
>>
>> Description
>> My test environment is as follows: Hypervisor(Xen 4.5.0), Dom 0(Linux
>> 3.18.21), Dom U(Linux 3.18.21).
>>
>> Environment setup:
>> We created two 1-vCPU, 4GB-memory VMs and pinned them onto one
>> physical CPU core. One VM(denoted as I/O-VM) ran Sockperf server
>> program; the other VM ran a compute-bound task, e.g., SPECCPU 2006 or
>> simply a loop(denoted as CPU-VM). A client on another physical machine
>> sent UDP requests to the I/O-VM.
>>
>> Here are my tail latency results (micro-second):
>> Case   Avg  90%   99%99.9%  99.99%
>> #1 108   &  114&  128 &  129 &  130
>> #2 7811  &  13892  &  14874   &  15315   &  16383
>> #3 943   &  131&  21755   &  26453   &  26553
>> #4 116   &  96 &  105 &  8217&  13472
>> #5 116   &  117&  129 &  131 &  132
>>
>> Bug 1, 2, and 3 will be discussed below.
>>
>> Case #1:
>> I/O-VM was processing Sockperf requests from clients; CPU-VM was
>> idling (no processes running).
>>
>> Case #2:
>> I/O-VM was processing Sockperf requests from clients; CPU-VM was
>> running a compute-bound task.
>> Hypervisor is the native Xen 4.5.0
>>
>> Case #3:
>> I/O-VM was processing Sockperf requests from clients; CPU-VM was
>> running a compute-bound task.
>> Hypervisor is the native Xen 4.5.0 with bug 1 fixed
>>
>> Case #4:
>> I/O-VM was processing Sockperf requests from clients; CPU-VM was
>> running a compute-bound task.
>> Hypervisor is the native Xen 4.5.0 with bug 1 & 2 fixed
>>
>> Case #5:
>> I/O-VM was processing Sockperf requests from clients; CPU-VM was
>> running a compute-bound task.
>> Hypervisor is the native Xen 4.5.0 with bug 1 & 2 & 3 fixed
>>
>> ---
>>
>>
>> (2) Problem analysis
>
> Hey Tony,
>
> Thanks for looking at this.  These issues in the credit1 algorithm are
> essentially exactly the reason that I started work on the credit2
> scheduler several years ago.  We meant credit2 to have replaced
> credit1 by now, but we ran out of time to test it properly; we're in
> the process of doing that right now, and are hoping it will be the
> default scheduler for the 4.8 release.
>
> So if I could make two suggestions that would help your effort be more
> helpful to us:
>
> 1. Use cpupools for testing rather than pinning. A lot of the
> algorithms are designed with the assumption that they have all the
> cpus to run on, and the credit allocation / priority algorithms fail
> to work properly when they are only pinned.  Cpupools was specifically
> designed to allow the scheduler algorithms to work as designed with a
> smaller number of cpus than the system had.
>
> 2. Test credit2. :-)
>

Hi George,

Thank you for reply. I will try cpupools and credit2 later. :-)


> One comment about your analysis here...
>
>> [Bug2]: In csched_acct() (by default every 30ms), a VCPU stops earning
>> credits and is removed from the active CPU list(in
>> __csched_vcpu_acct_stop_locked) if its credit is larger than the upper
>> bound. Because the domain has only one VCPU and the VM will also be
>> removed from the active domain list.
>>
>> Every 10ms, csched_tick() --> csched_vcpu_acct() -->
>> __csched_vcpu_acct_start() will be executed and tries to put inactive
>> VCPUs back to the active list. However, __csched_vcpu_acct_start()
>> will only put the current VCPU back to the active list. If an
>> I/O-bound VCPU is not the current VCPU at the csched_tick(), it will
>> not be put back to the active VCPU list. If so, the I/O-bound VCPU
>> will likely miss the next credit refill in csched_acct() and can
>> easily enter the OVER state. As such, the I/O-bound VM will be unable
>> to be boosted and have very long latency. It takes at least one time
>> slice (e.g., 30ms) before the I/O VM is activated and starts to
>> receive credits.
>>
>> [Possible Solution] Try to activate any inactive VCPUs back to active
>> before next credit refill, instead of just the current VCPU.
>
> When we stop accounting, we divide the credits in half, so that when
> it starts out, it should have a reasonable amount of credit (15ms
> worth).  Is this not taking effect for some reason?
>

Actually, for bug 2, dividing the credits in half to have a reasonable
credit is not the issue. The problem here is that the VCPU will be
removed from active VCPU list(in __csched_vcpu_acct_stop_locked) and
will not be put back to active list in time sometimes(as I explained
in the first thread). If the VCPU is not active, next time the
csched_acct will not allocate new credits to this VCPU. If many rounds
happened, the 

[Xen-devel] [xen-4.6-testing test] 94501: regressions - FAIL

[osstest service owner]

flight 94501 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94501/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93932
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93932
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93932

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair 21 guest-migrate/src_host/dst_host fail pass in 94491

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 94491 blocked in 
93932
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93932
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93932
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 93932
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93932

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 94491 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 94491 never pass
 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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  426783e661da942f8b7871613479db4daa6a16c3
baseline version:
 xen  39546d1360d954c2d0e2ff71dc74851e7081f61f

Last test of basis93932  2016-05-09 21:11:10 Z7 days
Failing since 94000  2016-05-10 18:10:33 Z6 days   11 attempts
Testing same since94036  2016-05-11 15:51:26 Z6 days   10 attempts


People who touched revisions under test:
  Ian Jackson 

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  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-prev pass
 build-i386-prev  

[Xen-devel] [PATCH for-4.6] Config.mk: update mini-os changeset

[Wei Liu]

Patches pulled in:
lib/sys.c: enclose file_types in define guards
build: change MINI-OS_ROOT to MINIOS_ROOT

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Ian Jackson 

One of the patches is required to build stubdom on Ubuntu 16.04.

Samuel has confirmed it's fine to backport both.

http://lists.xen.org/archives/html/minios-devel/2016-05/msg00018.html
---
 Config.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Config.mk b/Config.mk
index e529513..513467b 100644
--- a/Config.mk
+++ b/Config.mk
@@ -255,9 +255,9 @@ MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
 endif
 OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
 QEMU_UPSTREAM_REVISION ?= qemu-xen-4.6.1
-MINIOS_UPSTREAM_REVISION ?= 6aadd46e0927763861b19eacce2f2aeac9f17835
-# Sat, 9 Apr 2016 23:46:32 +0100 (00:46 +0200)
-# Fix time update
+MINIOS_UPSTREAM_REVISION ?= e1cca557c64272d33da7bafc0ad25399267563d0
+# Fri May 13 15:21:10 2016 +0100
+# lib/sys.c: enclose file_types in define guards
 
 SEABIOS_UPSTREAM_REVISION ?= rel-1.8.2
 # Tue Mar 17 10:52:16 2015 -0400
-- 
2.1.4


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

Re: [Xen-devel] state of xenified SUSE kernel

[Jan Beulich]

>>> On 17.05.16 at 17:10,  wrote:
> We use xenified kernels based on kernel 3.4 for years and benchmarks 
> showed that they are faster than the pvops (vanilla) kernels.
> But what is the current state in terms of performance and features?

I'm not sure what you expect here. Up to openSUSE 42.1 and
SLE 12 SP1 they are fully maintained, i.e. you can get quite a
bit newer than 3.4 based kernels. There's not a lot of
performance analysis that I would be aware of, so I can't
answer that part anyway. And them being release branches
rather than development ones, there's not going to be any
new feature work.

> Related question is if they have a future (at SUSE) at all? The repo 
> does not have Xen patches for SLE12-SP2. Still coming? Or dropped forever?

Dropped. For the stable-xen branch I'll be maintaining the patches
for a little while, but eventually that'll stop too unless we encounter
a fatal issue on the branches that have got switched to pv-ops.

Jan


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

[Xen-devel] [qemu-upstream-4.3-testing test] 94504: trouble: blocked/broken

[osstest service owner]

flight 94504 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94504/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  101 days
Testing same since93977  2016-05-10 11:09:16 Z7 days   19 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] Expose RUNstate_blocked, offline, runnable in xentop?

[Dario Faggioli]

On Tue, 2016-05-17 at 11:07 -0400, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> I was wondering if there is an interest in exposing those
> via xentop?
> 
> I wrote a hack patch (see attached) that expose this which helped
> me figure out what guests are doing when their CPU consumption
> time is low. As in whether they are truly 'halted' or
> if they are preempted by the hypervisor or other guests
> (b/c I may have pinned _ALL_ guest VCPUs on the same pCPU).
> 
Yes, IMO, this is something that could well be interesting!

> Of course I am not proposing the patches as they are.
> 
Cc me when you do.

I'm a little busy for a couple of days, but I'll do my best to help
this to get in (for 4.8, of course).

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[David Vrabel]

On 11/05/16 11:16, David Vrabel wrote:
> 
> Why don't we get the RW bits correct when making the pteval when we
> already have the pfn, instead trying to fix it up afterwards.

Kevin, can you try this patch.

David

8<-
x86/xen: avoid m2p lookup when setting early page table entries

When page tables entries are set using xen_set_pte_init() during early
boot there is no page fault handler that could handle a fault when
performing an M2P lookup.

In 64 guest (usually dom0) early_ioremap() would fault in
xen_set_pte_init() because an M2P lookup faults because the MFN is in
MMIO space and not mapped in the M2P.  This lookup is done to see if
the PFN in in the range used for the initial page table pages, so that
the PTE may be set as read-only.

The M2P lookup can be avoided by moving the check (and clear of RW)
earlier when the PFN is still available.

[ Not entirely happy with this as the 32/64 bit paths diverge even
  more. Is there some way to unify them instead? ]

Signed-off-by: David Vrabel 
---
 arch/x86/xen/mmu.c | 28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 478a2de..897fad4 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1562,7 +1562,7 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t
pte)
return pte;
 }
 #else /* CONFIG_X86_64 */
-static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
+static pteval_t __init mask_rw_pte(pteval_t pte)
 {
unsigned long pfn;

@@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
pte_t pte)
 * page tables for mapping the p2m list, too, and page tables MUST be
 * mapped read-only.
 */
-   pfn = pte_pfn(pte);
+   pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
if (pfn >= xen_start_info->first_p2m_pfn &&
pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
-   pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
+   pte &= ~_PAGE_RW;

return pte;
 }
@@ -1600,13 +1600,26 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
pte_t pte)
  * so always write the PTE directly and rely on Xen trapping and
  * emulating any updates as necessary.
  */
+__visible __init pte_t xen_make_pte_init(pteval_t pte)
+{
+#ifdef CONFIG_X86_64
+   pte = mask_rw_pte(pte);
+#endif
+   pte = pte_pfn_to_mfn(pte);
+
+   if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
+   pte = 0;
+
+   return native_make_pte(pte);
+}
+PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_init);
+
 static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 {
+#ifdef CONFIG_X86_32
if (pte_mfn(pte) != INVALID_P2M_ENTRY)
pte = mask_rw_pte(ptep, pte);
-   else
-   pte = __pte_ma(0);
-
+#endif
native_set_pte(ptep, pte);
 }

@@ -2407,6 +2420,7 @@ static void __init xen_post_allocator_init(void)
pv_mmu_ops.alloc_pud = xen_alloc_pud;
pv_mmu_ops.release_pud = xen_release_pud;
 #endif
+   pv_mmu_ops.make_pte = PV_CALLEE_SAVE(xen_make_pte);

 #ifdef CONFIG_X86_64
pv_mmu_ops.write_cr3 = _write_cr3;
@@ -2455,7 +2469,7 @@ static const struct pv_mmu_ops xen_mmu_ops
__initconst = {
.pte_val = PV_CALLEE_SAVE(xen_pte_val),
.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),

-   .make_pte = PV_CALLEE_SAVE(xen_make_pte),
+   .make_pte = PV_CALLEE_SAVE(xen_make_pte_init),
.make_pgd = PV_CALLEE_SAVE(xen_make_pgd),

 #ifdef CONFIG_X86_PAE
-- 
2.1.4




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

[Xen-devel] state of xenified SUSE kernel

[Andreas Kinzler]

Hello Jan,

perhaps you can shed some light on the state of the xenfied SUSE kernels 
(http://kernel.opensuse.org/cgit/kernel-source).


We use xenified kernels based on kernel 3.4 for years and benchmarks 
showed that they are faster than the pvops (vanilla) kernels.

But what is the current state in terms of performance and features?

Related question is if they have a future (at SUSE) at all? The repo 
does not have Xen patches for SLE12-SP2. Still coming? Or dropped forever?


Regards Andreas

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

Re: [Xen-devel] [PATCH 2/2] xen: sched: rtds: use non-atomic bit-ops

[Meng Xu]

On Sun, May 15, 2016 at 7:54 PM, Tianyang Chen  wrote:
> Vcpu flags are checked and cleared atomically. Performance can be
> improved with corresponding non-atomic versions since schedule.c
> already has spin_locks in place.
>
> Signed-off-by: Tianyang Chen 

Reviewed-by: Meng Xu 

Thanks,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

[Xen-devel] Expose RUNstate_blocked,offline,runnable in xentop?

[Konrad Rzeszutek Wilk]

Hey,

I was wondering if there is an interest in exposing those
via xentop?

I wrote a hack patch (see attached) that expose this which helped
me figure out what guests are doing when their CPU consumption
time is low. As in whether they are truly 'halted' or
if they are preempted by the hypervisor or other guests
(b/c I may have pinned _ALL_ guest VCPUs on the same pCPU).

Of course I am not proposing the patches as they are.

>From ee7abce84ea4e4fbaad9c03793d9b75e07e15ca3 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Fri, 4 Apr 2014 15:24:22 -0400
Subject: [PATCH 1/2] xen/xentop: Include RUNNABLE, OFFLINE, and BLOCKED stats

Signed-off-by: Konrad Rzeszutek Wilk 
---
 tools/libxc/xc_domain.c |  26 ++
 tools/libxc/xenctrl.h   |   6 ++
 tools/xenstat/libxenstat/src/xenstat.c  |  24 +-
 tools/xenstat/libxenstat/src/xenstat.h  |   3 +
 tools/xenstat/libxenstat/src/xenstat_priv.h |   3 +
 tools/xenstat/xentop/xentop.c   | 129 ++--
 xen/common/domctl.c |  63 ++
 xen/common/sysctl.c |  43 ++
 xen/include/public/domctl.h |  47 ++
 xen/include/public/sysctl.h |  13 +++
 xen/include/xen/domain.h|   2 +
 11 files changed, 332 insertions(+), 27 deletions(-)

diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 369c3f3..028eb4f 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -281,6 +281,32 @@ int xc_vcpu_getaffinity(xc_interface *xch,
 out:
 return ret;
 }
+int xc_domain_getinfolist2(xc_interface *xch,
+  uint32_t first_domain,
+  unsigned int max_domains,
+  xc_domaininfo2_t *info)
+{
+int ret = 0;
+DECLARE_SYSCTL;
+DECLARE_HYPERCALL_BOUNCE(info, max_domains*sizeof(*info), 
XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+if ( xc_hypercall_bounce_pre(xch, info) )
+return -1;
+
+sysctl.cmd = XEN_SYSCTL_getdomaininfolist2;
+sysctl.u.getdomaininfolist.first_domain = first_domain;
+sysctl.u.getdomaininfolist.max_domains  = max_domains;
+set_xen_guest_handle(sysctl.u.getdomaininfolist.buffer, info);
+
+if ( xc_sysctl(xch, ) < 0 )
+ret = -1;
+else
+ret = sysctl.u.getdomaininfolist.num_domains;
+
+xc_hypercall_bounce_post(xch, info);
+
+return ret;
+}
 
 int xc_domain_get_guest_width(xc_interface *xch, uint32_t domid,
   unsigned int *guest_width)
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 42d3133..2100e8f 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -420,6 +420,7 @@ typedef struct xc_dominfo {
 } xc_dominfo_t;
 
 typedef xen_domctl_getdomaininfo_t xc_domaininfo_t;
+typedef xen_domctl_getdomaininfo2_t xc_domaininfo2_t;
 
 typedef union 
 {
@@ -625,6 +626,11 @@ int xc_domain_getinfo(xc_interface *xch,
   xc_dominfo_t *info);
 
 
+int xc_domain_getinfolist2(xc_interface *xch,
+  uint32_t first_domain,
+  unsigned int max_domains,
+  xc_domaininfo2_t *info);
+
 /**
  * This function will set the execution context for the specified vcpu.
  *
diff --git a/tools/xenstat/libxenstat/src/xenstat.c 
b/tools/xenstat/libxenstat/src/xenstat.c
index e5facb8..936cb02 100644
--- a/tools/xenstat/libxenstat/src/xenstat.c
+++ b/tools/xenstat/libxenstat/src/xenstat.c
@@ -163,7 +163,7 @@ xenstat_node *xenstat_get_node(xenstat_handle * handle, 
unsigned int flags)
 #define DOMAIN_CHUNK_SIZE 256
xenstat_node *node;
xc_physinfo_t physinfo = { 0 };
-   xc_domaininfo_t domaininfo[DOMAIN_CHUNK_SIZE];
+   xc_domaininfo2_t domaininfo[DOMAIN_CHUNK_SIZE];
unsigned int new_domains;
unsigned int i;
 
@@ -204,7 +204,7 @@ xenstat_node *xenstat_get_node(xenstat_handle * handle, 
unsigned int flags)
do {
xenstat_domain *domain, *tmp;
 
-   new_domains = xc_domain_getinfolist(handle->xc_handle,
+   new_domains = xc_domain_getinfolist2(handle->xc_handle,
node->num_domains, 
DOMAIN_CHUNK_SIZE, 
domaininfo);
@@ -244,6 +244,9 @@ xenstat_node *xenstat_get_node(xenstat_handle * handle, 
unsigned int flags)
}
domain->state = domaininfo[i].flags;
domain->cpu_ns = domaininfo[i].cpu_time;
+   domain->cpu_blocked_ns = domaininfo[i].cpu_time_blocked;
+   domain->cpu_offline_ns = domaininfo[i].cpu_time_offline;
+   domain->cpu_runnable_ns = 
domaininfo[i].cpu_time_runnable;

Re: [Xen-devel] [PATCH 1/2] xen: sched: rtds refactor code

[Meng Xu]

On Sun, May 15, 2016 at 7:54 PM, Tianyang Chen  wrote:
> No functional change:
>  -Various coding style fix
>  -Added comments for UPDATE_LIMIT_SHIFT.
>
> Signed-off-by: Tianyang Chen 

Reviewed-by: Meng Xu 

---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH 0/2] xen: sched: rtds refactor code

[Meng Xu]

On Sun, May 15, 2016 at 7:54 PM, Tianyang Chen  wrote:
> The first part of this patch series aims at fixing coding syle issue
> for control structures. Because locks are grabbed in schedule.c before
> hooks are called, underscores in front of function names are removed.
>
> The second part replaces atomic bit-ops with non-atomic ones since locks
> are grabbed in schedule.c.
>
> Discussions:
> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01528.html
> http://www.gossamer-threads.com/lists/xen/devel/431251?do=post_view_threaded#431251
>
> Tianyang Chen (2):
>   xen: sched: rtds refactor code
>   xen: sched: rtds: use non-atomic bit-ops
>
>  xen/common/sched_rt.c |  122 
> ++---
>  1 file changed, 64 insertions(+), 58 deletions(-)
>

Tianyang,

Thanks for the patch!
One comment for the future: please add the version number into the
title so that we can easily tell it is a new patch. :-)

Best,

Meng

---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

[Xen-devel] [seabios test] 94508: regressions - FAIL

[osstest service owner]

flight 94508 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94508/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 92452
 build-i386-libvirt5 libvirt-build fail REGR. vs. 92452
 build-amd64-pvops 5 kernel-build  fail REGR. vs. 92452
 build-i386-pvops  5 kernel-build  fail REGR. vs. 92452

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a

version targeted for testing:
 seabios  1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98
baseline version:
 seabios  c8e105a4d5e52e8e7539ab1f2cd07ebe0ae9033a

Last test of basis92452  2016-04-23 11:37:00 Z   24 days
Testing same since94496  2016-05-17 01:12:44 Z0 days2 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Paul Menzel 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopsfail
 build-i386-pvops fail
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked 
 test-amd64-amd64-qemuu-nested-amdblocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-qemuu-nested-intel  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   blocked 
 test-amd64-i386-xl-qemuu-winxpsp3blocked 



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

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

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

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


Not pushing.


commit 1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98
Author: Kevin O'Connor 
Date:   Mon May 16 20:51:17 2016 -0400

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

[osstest service owner]

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

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  46699c7393bd991234b5642763c5c24b6b39a6c4
baseline version:
 xen  2c86f0e1ac35b4c9e9502d969693f3264d3eda1e

Last test of basis94489  2016-05-16 16:00:59 Z0 days
Testing same since94514  2016-05-17 13:01:58 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  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=46699c7393bd991234b5642763c5c24b6b39a6c4
+ . ./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 
46699c7393bd991234b5642763c5c24b6b39a6c4
+ branch=xen-unstable-smoke
+ revision=46699c7393bd991234b5642763c5c24b6b39a6c4
+ . ./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.6-testing
+ '[' x46699c7393bd991234b5642763c5c24b6b39a6c4 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 05b2f9c94e0c0b663ff2d2fb55397d8215eeb3f5
baseline version:
 ovmf 7b13510f2a0a2a118cdafdaa67720ca8e3fe37de

Last test of basis94498  2016-05-17 02:53:53 Z0 days
Testing same since94503  2016-05-17 08:16:00 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 

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=05b2f9c94e0c0b663ff2d2fb55397d8215eeb3f5
+ . ./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 
05b2f9c94e0c0b663ff2d2fb55397d8215eeb3f5
+ branch=ovmf
+ revision=05b2f9c94e0c0b663ff2d2fb55397d8215eeb3f5
+ . ./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.6-testing
+ '[' x05b2f9c94e0c0b663ff2d2fb55397d8215eeb3f5 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 

Re: [Xen-devel] [PATCH] AMD IOMMU: Introduce support for IVHD block type 11h

[Jan Beulich]

>>> On 13.05.16 at 21:54,  wrote:
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -821,13 +821,23 @@ static u16 __init parse_ivhd_device_special(
>  return dev_length;
>  }
>  
> +static inline int get_ivhd_header_size(const struct acpi_ivrs_hardware 
> *ivhd_block)
> +{
> +if ( ivhd_block->header.type == ACPI_IVRS_TYPE_HARDWARE)
> +return 24;
> +if ( ivhd_block->header.type == ACPI_IVRS_TYPE_HARDWARE_11H)
> +return 40;

Can these become some sizeof() or offsetof() please?

Also both if()-s are lacking a blank before the closing paren. Perhaps
better to be made a switch() anyway.

And the function's return type should be an unsigned one.

>  static int __init parse_ivhd_block(const struct acpi_ivrs_hardware 
> *ivhd_block)
>  {
>  const union acpi_ivhd_device *ivhd_device;
>  u16 block_length, dev_length;
> +int hdr_size = get_ivhd_header_size(ivhd_block) ;

As should be this variable's.

> @@ -901,7 +911,7 @@ static int __init parse_ivhd_block(const struct 
> acpi_ivrs_hardware *ivhd_block)
>  ivhd_block->header.length, block_length, iommu);
>  break;
>  default:
> -AMD_IOMMU_DEBUG("IVHD Error: Invalid Device Type!\n");
> +AMD_IOMMU_DEBUG("IVHD Error: %s: Invalid Device Type!\n", 
> __func__);

Why?

> @@ -978,6 +960,21 @@ static void __init dump_acpi_table_header(struct 
> acpi_table_header *table)
>  
>  }
>  
> +#define to_ivhd_block(hdr) \
> +( container_of(hdr, const struct acpi_ivrs_hardware, header) )
> +#define to_ivmd_block(hdr) \
> +(container_of(hdr, const struct acpi_ivrs_memory, header) )

Pointless parentheses (and mixed use of blanks). But thanks for
using container_of() here instead of casts.

> +#define is_ivhd_block(x) \
> +( x == ACPI_IVRS_TYPE_HARDWARE || \
> +  x == ACPI_IVRS_TYPE_HARDWARE_11H )
> +
> +#define is_ivmd_block(x) \
> +( x == ACPI_IVRS_TYPE_MEMORY_ALL || \
> +  x == ACPI_IVRS_TYPE_MEMORY_ONE || \
> +  x == ACPI_IVRS_TYPE_MEMORY_RANGE || \
> +  x == ACPI_IVRS_TYPE_MEMORY_IOMMU )

All instances of x should get properly parenthesized.

> @@ -1177,12 +1176,9 @@ static int __init get_last_bdf_acpi(struct 
> acpi_table_header *table)
>  ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
>  if ( table->length < (length + ivrs_block->length) )
>  return -ENODEV;
> -if ( ivrs_block->type == ACPI_IVRS_TYPE_HARDWARE )
> +if ( ivrs_block->type == ivhd_type )
>  {
> -int ret = get_last_bdf_ivhd(
> - container_of(ivrs_block, const struct acpi_ivrs_hardware,
> -  header));
> -
> +int ret = get_last_bdf_ivhd(to_ivhd_block(ivrs_block));
>  if ( ret < 0 )

Stray deletion of a blank line.

> +static int __init
> +get_supported_ivhd_type(struct acpi_table_header *table)
> +{
> +unsigned long length = sizeof(struct acpi_table_ivrs);
> +const struct acpi_ivrs_header *ivrs_block, *blk = NULL;
> +
> +while ( table->length > (length + sizeof(*ivrs_block)) )
> +{
> +ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
> +
> +if ( table->length < (length + ivrs_block->length) )
> +{
> +AMD_IOMMU_DEBUG("IVRS Error: "
> +"Table Length Exceeded: %#x -> %#lx\n",
> +table->length,
> +(length + ivrs_block->length));
> +return -ENODEV;
> +}
> +
> +if ( is_ivhd_block (ivrs_block->type) )

Stray blank before inner opening paren.

> +{
> +AMD_IOMMU_DEBUG("IVRS Block: Found type %#x flags %#x len %#x id 
> %#x\n",
> +ivrs_block->type, ivrs_block->flags,
> +ivrs_block->length, ivrs_block->device_id);
> +if ( ivrs_block->type > IVHD_HIGHEST_SUPPORT_TYPE )
> +break;

Is there a requirement for the table elements to appear in numerical
order? And anyway - this if() appears to be redundant with the
enclosing one.

> +int __init amd_iommu_get_supported_ivhd_type(void)
> +{
> +if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )
> +return -EPERM;

This check appears out of the blue, and isn't being mentioned in
the description. Best would probably be to split it out, but at the
very least it needs to be (briefly) explained.

> @@ -1233,8 +1234,11 @@ int __init amd_iommu_init(void)
>   amd_sp5100_erratum28() )
>  goto error_out;
>  
> -ivrs_bdf_entries = amd_iommu_get_ivrs_dev_entries();
> +ivhd_type = amd_iommu_get_supported_ivhd_type();
> +if ( !ivhd_type )
> +goto error_out;

Is the ! here meant to catch errors? The function returns -E...
values to indicate errors ...

Jan

___

Re: [Xen-devel] unable to create domain after enabling XSM

[Big Strong]

Thanks very much, it turns out to be the problem of modules.conf. I turn
the xen module off for mistake, I'm very sorry for the time you spend.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v10 3/3] vt-d: fix vt-d Device-TLB flush timeout issue

[Jan Beulich]

>>> On 22.04.16 at 12:54,  wrote:
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -206,10 +206,71 @@ static int invalidate_sync(struct iommu *iommu)
>  return 0;
>  }
>  
> +static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
> + u16 seg, u8 bus, u8 devfn)
> +{
> +struct domain *d = NULL;
> +struct pci_dev *pdev;
> +
> +if ( test_bit(did, iommu->domid_bitmap) )
> +d = rcu_lock_domain_by_id(iommu->domid_map[did]);
> +
> +/*
> + * In case the domain has been freed or the IOMMU domid bitmap is
> + * not valid, the device no longer belongs to this domain.
> + */
> +if ( d == NULL )
> +return;
> +
> +pcidevs_lock();
> +
> +for_each_pdev(d, pdev)
> +{
> +if ( (pdev->seg == seg) &&
> + (pdev->bus == bus) &&
> + (pdev->devfn == devfn) )
> +{
> +ASSERT(pdev->domain);
> +list_del(>domain_list);
> +pdev->domain = NULL;
> +pci_hide_existing_device(pdev);
> +break;
> +}
> +}

A loop like this is of course not ideal (especially for Dom0, which may
have many devices). And I wonder why you, ...

> @@ -134,8 +133,9 @@ int dev_invalidate_iotlb(struct iommu *iommu, u16 did,
>  /* invalidate all translations: sbit=1,bit_63=0,bit[62:12]=1 */
>  sbit = 1;
>  addr = (~0UL << PAGE_SHIFT_4K) & 0x7FFF;
> -rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth,
> -  sid, sbit, addr);
> +rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth, did,
> +  pdev->seg, pdev->bus, pdev->devfn,
> +  sbit, addr);
>  break;
>  case DMA_TLB_PSI_FLUSH:
>  if ( !device_in_domain(iommu, pdev, did) )
> @@ -154,8 +154,9 @@ int dev_invalidate_iotlb(struct iommu *iommu, u16 did,
>  addr |= (((u64)1 << (size_order - 1)) - 1) << PAGE_SHIFT_4K;
>  }
>  
> -rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth,
> -  sid, sbit, addr);
> +rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth, did,
> +  pdev->seg, pdev->bus, pdev->devfn,
> +  sbit, addr);
>  break;

... holding pdev in your hands here, don't just pass it down (which
at once would make the function signature less convoluted: you
could even eliminate the currently 2nd parameter that way).

Jan


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

Re: [Xen-devel] [HACKATHON 2016] ARM Status

[Konrad Rzeszutek Wilk]

On Tue, May 17, 2016 at 10:57:12AM +0100, Julien Grall wrote:
> Hi Konrad,
> 
> On 16/05/16 20:43, Konrad Rzeszutek Wilk wrote:
> >On Thu, May 05, 2016 at 04:41:51PM +0100, Steve Capper wrote:
> >>[Apologies for the late send]
> >>
> >>Xen - ARM Status
> >>
> >>There was discussion on the following items:
> >>
> >>*) Booting Xen on 64-bit ARM SoC
> >>   o) Unfortunately Xen was executed in EL1.
> >>   o) Advice was given that the firmware should boot the Xen in EL2.
> >>   o) The ARMv7 secure mode switch to Hyp trick is not valid on AArch64.
> >>
> >>*) ARMv7 Cubietruck bringup was also discussed
> >>   o) One pain point mentioned was debugging the DomU guest
> >>   o) There are no debug capabilities for a Xen guest, but
> >>   o) There are a set of hyp calls that can be placed in the guest to
> >>  aid with debugging.
> >>   o) The documentation on these hyp calls needs refreshing in a wiki
> >>  somewhere?
> >>   o) Details of these can be found at: xen/arch/arm/traps.c
> >>
> >>*) There is no list of names/ownership for HW platforms
> >>   o) This is due to it being non-trivial to deduce a name from wiki
> >>  activity.
> >>   o) If people care about a board, they should make themselves known.
> >
> >I care about the CubieBoard5. I hadn't actually been able to do
> >much on it as the default loaded firmware does not seem to be
> >able to read any microSD card so I am afraid to update the uboot.
> 
> I haven't played with the CubieBoard5 before. From my understanding, the
> firmware/bootloader resides at the beginning of the SD-card.
> 
> So if you backup your SD-card you will be able to revert any non-working
> change. For more details see [1].

But that is the problem - the SD-card is built-in.

Oh, but it mentions TFTP! That may do it.
Let me try that. Thanks.

> 
> Regards,
> 
> [1] https://linux-sunxi.org/Bootable_SD_card#Bootloader
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH] x86: make SMEP/SMAP suppression tolerate NMI/MCE at the "wrong" time

[Wei Liu]

On Tue, May 17, 2016 at 07:43:34AM -0600, Jan Beulich wrote:
> There is one instruction boundary where any kind of interruption would
> break the assumptions cr4_pv32_restore's debug mode checking makes on
> the correlation between the CR4 register value and its in-memory cache.
> Correct this (see the code comment) even in non-debug mode, or else
> a subsequent cr4_pv32_restore would also be misguided into thinking the
> features are enabled when they really aren't.
> 
> Signed-off-by: Jan Beulich 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86: make SMEP/SMAP suppression tolerate NMI/MCE at the "wrong" time

[Andrew Cooper]

On 17/05/16 14:43, Jan Beulich wrote:
> There is one instruction boundary where any kind of interruption would
> break the assumptions cr4_pv32_restore's debug mode checking makes on
> the correlation between the CR4 register value and its in-memory cache.
> Correct this (see the code comment) even in non-debug mode, or else
> a subsequent cr4_pv32_restore would also be misguided into thinking the
> features are enabled when they really aren't.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH] x86: make SMEP/SMAP suppression tolerate NMI/MCE at the "wrong" time

[Jan Beulich]

There is one instruction boundary where any kind of interruption would
break the assumptions cr4_pv32_restore's debug mode checking makes on
the correlation between the CR4 register value and its in-memory cache.
Correct this (see the code comment) even in non-debug mode, or else
a subsequent cr4_pv32_restore would also be misguided into thinking the
features are enabled when they really aren't.

Signed-off-by: Jan Beulich 
---
This will only apply on top of "x86: refine debugging of SMEP/SMAP
fix", despite being functionally independent.

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -183,8 +183,21 @@ ENTRY(compat_restore_all_guest)
 jpe   .Lcr4_alt_end
 mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
 and   $~XEN_CR4_PV32_BITS, %rax
+1:
 mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
 mov   %rax, %cr4
+/*
+ * An NMI or MCE may have occurred between the previous two
+ * instructions, leaving register and cache in a state where
+ * the next exit from the guest would trigger the BUG in
+ * cr4_pv32_restore. If this happened, the cached value is no
+ * longer what we just set it to, which we can utilize to
+ * correct that state. Note that we do not have to fear this
+ * loop to cause a live lock: If NMIs/MCEs occurred at that
+ * high a rate, we'd be live locked anyway.
+ */
+cmp   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
+jne   1b
 .Lcr4_alt_end:
 .section .altinstructions, "a"
 altinstruction_entry .Lcr4_orig, .Lcr4_orig, X86_FEATURE_ALWAYS, 12, 0



x86: make SMEP/SMAP suppression tolerate NMI/MCE at the "wrong" time

There is one instruction boundary where any kind of interruption would
break the assumptions cr4_pv32_restore's debug mode checking makes on
the correlation between the CR4 register value and its in-memory cache.
Correct this (see the code comment) even in non-debug mode, or else
a subsequent cr4_pv32_restore would also be misguided into thinking the
features are enabled when they really aren't.

Signed-off-by: Jan Beulich 
---
This will only apply on top of "x86: refine debugging of SMEP/SMAP
fix", despite being functionally independent.

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -183,8 +183,21 @@ ENTRY(compat_restore_all_guest)
 jpe   .Lcr4_alt_end
 mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
 and   $~XEN_CR4_PV32_BITS, %rax
+1:
 mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
 mov   %rax, %cr4
+/*
+ * An NMI or MCE may have occurred between the previous two
+ * instructions, leaving register and cache in a state where
+ * the next exit from the guest would trigger the BUG in
+ * cr4_pv32_restore. If this happened, the cached value is no
+ * longer what we just set it to, which we can utilize to
+ * correct that state. Note that we do not have to fear this
+ * loop to cause a live lock: If NMIs/MCEs occurred at that
+ * high a rate, we'd be live locked anyway.
+ */
+cmp   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
+jne   1b
 .Lcr4_alt_end:
 .section .altinstructions, "a"
 altinstruction_entry .Lcr4_orig, .Lcr4_orig, X86_FEATURE_ALWAYS, 12, 0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [Vote Results] Minor change to governance document at http://www.xenproject.org/developers/governance.html (Vote before May 16th)

[Lars Kurth]

Hi all,

please find below the tally of the following vote 
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00801.html
covering the attached change to our governance

5 votes (3 from Hypervisor Committers, 2 from XAPI committers), all with +1, so 
it carries

Best Regards
Lars

---
The modified section will look like

...
Committer Elections

Developers who have earned the trust of committers in their project 
can through election be promoted to Committer. A two stage mechanism 
is used

* Nomination: Community members should nominate candidates by posting 
  a proposal to appointments at xenproject dot org  
   
  explaining the candidate's contributions to the project 
  and thus why they should be elected to become a Committer 
  of the project. The nomination should cite evidence such 
  as patches and other contributions where the case is not 
  obvious. Existing Committers will review all proposals, 
  check whether the nominee would be willing to accept the 
  nomination and publish suitable nominations on the project's 
  public mailing list for wider community input.

...

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

Re: [Xen-devel] unable to create domain after enabling XSM

[Konrad Rzeszutek Wilk]

On Tue, May 17, 2016 at 04:58:03PM +0800, Big Strong wrote:
> I should add the xsm=policy option to the end of the xen.cfg instead of as
> an option. Sorry for the fault.
> 
> However, another problem is that when I modified the policy and reload it
> using '*xl loadpolicy*', the policy seemed not working.
> 
> The policy I add is *'allow domU_t security_t:security check_context; allow
> domU_t domU_t_self:hvm gethvmc;*', and it is successfully loaded.
> 
> But executing XEN_DOMCTL_gethvmcontext_partial in domU_t would still cause
> the following violations:
> 
> *(XEN) avc:  denied  { gethvmc } for domid=1
> scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
> tclass=hvm*
> 
> Rebooting xen with the new policy doesn't work too. BTW, the domU_t I
> created is a HVM, I hope that is not the problem.

Rebootin meaning you put the policy on the boot partition and your xen.cfg
has xsm=?

And it loads the policy? You can see that Xen has loaded it?

I am going to assume that the policy is loaded just fine - it just that the
policy you wrote is not doing what it is expected.

And oddly enough, you did not CC the XSM maintainer here. He may
be able to help.

> 
> 2016-05-17 16:33 GMT+08:00 Jan Beulich :
> 
> > >>> On 16.05.16 at 17:00,  wrote:
> > > Actually I did that, but the policy is not loaded at all. 'xl list -Z'
> > show
> > > no lable on guests. It seems like that the option 'xsm=xen-policy-4.6.0'
> > is
> > > ingnored during booting. (the policy file is moved to the same directory
> > as
> > > xen.cfg)
> >
> > If you suspect it to be ignored, then please provide logs so we
> > can identify _where_ it gets ignored: The early EFI loader should
> > be pulling it into memory (note that the respective messages will
> > only be visible in a serial log if you also enable serial output for
> > EFI itself), and then XSM should be consuming it. Which of the
> > two goes wrong would be quite helpful to know, the more that it
> > looks like this works for others (e.g. Konrad).
> >
> > Jan
> >
> >

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

Re: [Xen-devel] Linux 4.4 boot crash on xen 4.5.3 with dom0_mem == max

[Ed Swierk]

Here is the instrumented output with dom0_mem=18432M,max:18432M.

...
[0.00] xen_count_remap_pages(max_pfn=0x48) == 0x85dea
[0.00] max_pages 0x505dea
[0.00] xen_add_extra_mem(48, 85dea)
[0.00] memblock_reserve(0x48000, 0x85dea000)
[0.00] Released 0 page(s)
[0.00] e820: BIOS-provided physical RAM map:
[0.00] Xen: [mem 0x-0x0005] usable
[0.00] Xen: [mem 0x0006-0x00067fff] reserved
[0.00] Xen: [mem 0x00068000-0x0009afff] usable
[0.00] Xen: [mem 0x000a-0x000f] reserved
[0.00] Xen: [mem 0x0010-0x75afdfff] usable
[0.00] Xen: [mem 0x75bab000-0x7a1f5fff] usable
[0.00] Xen: [mem 0x7b7d7000-0x7b7f] usable
[0.00] Xen: [mem 0x7bf0-0x7bff] usable
[0.00] Xen: [mem 0xc7ffc000-0xc7ffcfff] reserved
[0.00] Xen: [mem 0xfbffc000-0xfbffcfff] reserved
[0.00] Xen: [mem 0xfec0-0xfec01fff] reserved
[0.00] Xen: [mem 0xfec4-0xfec40fff] reserved
[0.00] Xen: [mem 0xfed2-0xfed2] usable
[0.00] Xen: [mem 0xfee0-0xfeef] reserved
[0.00] Xen: [mem 0x0001-0x000505de9fff] usable
[0.00] bootconsole [xenboot0] enabled
[0.00] debug: ignoring loglevel setting.
[0.00] NX (Execute Disable) protection: active
[0.00] e820: user-defined physical RAM map:
[0.00] user: [mem 0x-0x0005] usable
[0.00] user: [mem 0x0006-0x00067fff] reserved
[0.00] user: [mem 0x00068000-0x0009afff] usable
[0.00] user: [mem 0x000a-0x000f] reserved
[0.00] user: [mem 0x0010-0x75afdfff] usable
[0.00] user: [mem 0x75bab000-0x7a1f5fff] usable
[0.00] user: [mem 0x7b7d7000-0x7b7f] usable
[0.00] user: [mem 0x7bf0-0x7bff] usable
[0.00] user: [mem 0x8000-0x8fff] reserved
[0.00] user: [mem 0xc7ffc000-0xc7ffcfff] reserved
[0.00] user: [mem 0xfbffc000-0xfbffcfff] reserved
[0.00] user: [mem 0xfec0-0xfec01fff] reserved
[0.00] user: [mem 0xfec4-0xfec40fff] reserved
[0.00] user: [mem 0xfed2-0xfed2] usable
[0.00] user: [mem 0xfee0-0xfeef] reserved
[0.00] user: [mem 0x0001-0x000505de9fff] usable
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Skyport Systems CloudDock/S2600WTT, BIOS 
SE5C610.86B.01.01.0009.C1.060120151350 06/01/2015
[0.00] Hypervisor detected: Xen
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x505dea max_arch_pfn = 0x4
[0.00] MTRR: Disabled
[0.00] e820: last_pfn = 0xfed30 max_arch_pfn = 0x4
[0.00] Scanning 1 areas for low memory corruption
[0.00] Base memory trampoline at [88095000] 95000 size 24576
[0.00] BRK [0x02f67000, 0x02f67fff] PGTABLE
[0.00] BRK [0x02f68000, 0x02f68fff] PGTABLE
[0.00] BRK [0x02f69000, 0x02f69fff] PGTABLE
[0.00] BRK [0x02f6a000, 0x02f6afff] PGTABLE
[0.00] BRK [0x02f6b000, 0x02f6bfff] PGTABLE
[0.00] BRK [0x02f6c000, 0x02f6cfff] PGTABLE
[0.00] RAMDISK: [mem 0x0400-0x14afefff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F0460 24 (v02 INTEL )
[0.00] ACPI: XSDT 0x7B78D188 CC (v01 INTEL  S2600WT  
 INTL 0113)
[0.00] ACPI: FACP 0x7B7D2000 F4 (v04 INTEL  S2600WT  
 INTL 20091013)
[0.00] ACPI: DSDT 0x7B798000 0313B2 (v02 INTEL  S2600WT  
0003 INTL 20091013)
[0.00] ACPI: FACS 0x7B6FC000 40
[0.00] ACPI: HPET 0x7B7D1000 38 (v01 INTEL  S2600WT  
0001 INTL 20091013)
[0.00] ACPI: APIC 0x7B7D 00085C (v03 INTEL  S2600WT  
 INTL 20091013)
[0.00] ACPI: MCFG 0x7B7CF000 3C (v01 INTEL  S2600WT  
0001 INTL 20091013)
[0.00] ACPI: MSCT 0x7B7CE000 90 (v01 INTEL  S2600WT  
0001 INTL 20091013)
[0.00] ACPI: SLIT 0x7B7CD000 6C (v01 INTEL  S2600WT  
0001 INTL 20091013)
[0.00] ACPI: SRAT 0x7B7CC000 000730 (v03 INTEL  S2600WT  
0001 INTL 20091013)
[0.00] ACPI: SPMI 0x7B7CB000 41 (v05 INTEL  S2600WT  
0001 INTL 20091013)
[0.00] ACPI: WDDT 

Re: [Xen-devel] Question about running Xen on NVIDIA Jetson-TK1

[Konrad Rzeszutek Wilk]

> - The serial controller on the Tegra SoCs doesn't behave in the same
> was as most NS16550-compatibles; it actually adheres to the NS16550
> spec a little more rigidly than most compatible controllers. A
> coworker (Chris Patterson, cc'd) figured out what was going on; from
> what I understand, most 16550s generate the "transmit ready" interrupt
> once, when the device first can accept new FIFO entries. Both the
> original 16550 and the Tegra implementation generate the "transmit
> ready" interrupt /continuously/ when there's space available in the
> FIFO, slewing the CPU with a stream of constant interrupts.

That may also be an issue on x86 I would think.

Is there some simple 16550 'fix' for this? As in reprogram it
to not be soo ready?

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

Re: [Xen-devel] [PATCH v2] x86: refine debugging of SMEP/SMAP fix

[Andrew Cooper]

On 17/05/16 14:35, Jan Beulich wrote:
> Instead of just latching cr4_pv32_mask into %rdx, correct the found
> wrong value in %cr4 (to avoid triggering another BUG). The value left
> in %rdx should be sufficient for deducing cr4_pv32_mask from the
> register dump.
>
> Also there is one more place for XEN_CR4_PV32_BITS to be used.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2] x86: refine debugging of SMEP/SMAP fix

[Wei Liu]

On Tue, May 17, 2016 at 02:37:16PM +0100, Andrew Cooper wrote:
> On 17/05/16 14:35, Jan Beulich wrote:
> > Instead of just latching cr4_pv32_mask into %rdx, correct the found
> > wrong value in %cr4 (to avoid triggering another BUG). The value left
> > in %rdx should be sufficient for deducing cr4_pv32_mask from the
> > register dump.
> >
> > Also there is one more place for XEN_CR4_PV32_BITS to be used.
> >
> > Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Andrew Cooper 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] 4.6.2 preparations

[Wei Liu]

On Tue, May 17, 2016 at 07:35:16AM -0600, Jan Beulich wrote:
> >>> On 17.05.16 at 15:23,  wrote:
> > I would like to propose backporting some mini-os patches to mini-os.git
> > stable-4.6 branch and update Config.mk in 4.6.
> 
> On top of the recently backported ones?

Yes.

> 
> > I guess I will bring that up with Samuel and then post patch here?
> 
> Yes please.
> 

OK. Will do.

Wei.

> Jan
> 

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

[Xen-devel] [PATCH v2] x86: refine debugging of SMEP/SMAP fix

[Jan Beulich]

Instead of just latching cr4_pv32_mask into %rdx, correct the found
wrong value in %cr4 (to avoid triggering another BUG). The value left
in %rdx should be sufficient for deducing cr4_pv32_mask from the
register dump.

Also there is one more place for XEN_CR4_PV32_BITS to be used.

Signed-off-by: Jan Beulich 
---
v2: Preserve cr4_pv32_mask value in a register.

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -182,7 +182,7 @@ ENTRY(compat_restore_all_guest)
 testb $3,UREGS_cs(%rsp)
 jpe   .Lcr4_alt_end
 mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
-and   $~(X86_CR4_SMEP|X86_CR4_SMAP), %rax
+and   $~XEN_CR4_PV32_BITS, %rax
 mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
 mov   %rax, %cr4
 .Lcr4_alt_end:
@@ -220,6 +220,10 @@ ENTRY(cr4_pv32_restore)
 je1f
 /* Cause cr4_pv32_mask to be visible in the BUG register dump. */
 mov   cr4_pv32_mask(%rip), %rdx
+/* Avoid coming back here while handling the #UD we cause below. */
+mov   %cr4, %rcx
+or%rdx, %rcx
+mov   %rcx, %cr4
 BUG
 1:
 #endif



x86: refine debugging of SMEP/SMAP fix

Instead of just latching cr4_pv32_mask into %rdx, correct the found
wrong value in %cr4 (to avoid triggering another BUG). The value left
in %rdx should be sufficient for deducing cr4_pv32_mask from the
register dump.

Also there is one more place for XEN_CR4_PV32_BITS to be used.

Signed-off-by: Jan Beulich 
---
v2: Preserve cr4_pv32_mask value in a register.

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -182,7 +182,7 @@ ENTRY(compat_restore_all_guest)
 testb $3,UREGS_cs(%rsp)
 jpe   .Lcr4_alt_end
 mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
-and   $~(X86_CR4_SMEP|X86_CR4_SMAP), %rax
+and   $~XEN_CR4_PV32_BITS, %rax
 mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
 mov   %rax, %cr4
 .Lcr4_alt_end:
@@ -220,6 +220,10 @@ ENTRY(cr4_pv32_restore)
 je1f
 /* Cause cr4_pv32_mask to be visible in the BUG register dump. */
 mov   cr4_pv32_mask(%rip), %rdx
+/* Avoid coming back here while handling the #UD we cause below. */
+mov   %cr4, %rcx
+or%rdx, %rcx
+mov   %rcx, %cr4
 BUG
 1:
 #endif
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] 4.6.2 preparations

[Jan Beulich]

>>> On 17.05.16 at 15:23,  wrote:
> I would like to propose backporting some mini-os patches to mini-os.git
> stable-4.6 branch and update Config.mk in 4.6.

On top of the recently backported ones?

> I guess I will bring that up with Samuel and then post patch here?

Yes please.

Jan


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

[Xen-devel] [xen-4.5-testing test] 94499: regressions - FAIL

[osstest service owner]

flight 94499 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94499/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93989
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93989
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93989

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 94469

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 93989
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93989
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93989
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 93989

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

version targeted for testing:
 xen  1334fa937ad269e9f476fc6a69fd895f5fc99864
baseline version:
 xen  2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3

Last test of basis93989  2016-05-10 14:43:18 Z6 days
Testing same since94030  2016-05-11 13:08:55 Z6 days   10 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64

Re: [Xen-devel] vmx: VT-d posted-interrupt core logic handling

[Konrad Rzeszutek Wilk]

On Thu, Mar 10, 2016 at 01:36:34PM +, Wu, Feng wrote:
> 
> 
> > -Original Message-
> > From: Tian, Kevin
> > Sent: Thursday, March 10, 2016 6:06 PM
> > To: Jan Beulich 
> > Cc: Andrew Cooper ; Dario Faggioli
> > ; David Vrabel ;
> > GeorgeDunlap ; Lars Kurth ;
> > George Dunlap ; Ian Jackson
> > ; Wu, Feng ; xen-
> > de...@lists.xen.org; Konrad Rzeszutek Wilk 
> > Subject: RE: vmx: VT-d posted-interrupt core logic handling
> > 
> > 
> > Hi, Jan,
> > 
> > I'm thinking your earlier idea about evenly distributed list:
> > 
> > --
> > Ah, right, I think that limitation was named before, yet I've
> > forgotten about it again. But that only slightly alters the
> > suggestion: To distribute vCPU-s evenly would then require to
> > change their placement on the pCPU in the course of entering
> > blocked state.
> > --
> > 
> > Actually after more thinking, there is no hard requirement that
> > the vcpu must block on the pcpu which is configured in 'NDST'
> > of that vcpu's PI descriptor. What really matters, is that the
> > vcpu is added to the linked list of the very pcpu, then when PI
> > notification comes we can always find out the vcpu struct from
> > that pcpu's linked list. Of course one drawback of such placement
> > is additional IPI incurred in wake up path.
> > 
> > Then one possible optimized policy within vmx_vcpu_block could
> > be:
> > 
> > (Say PCPU1 which VCPU1 is currently blocked on)
> > - As long as the #vcpus in the linked list on PCPU1 is below a
> > threshold (say 16), add VCPU1 to the list. NDST set to PCPU1;
> > Upon PI notification on PCPU1, local linked list is searched to
> > find VCPU1 and then VCPU1 will be unblocked on PCPU1;
> > 
> > - Otherwise, add VCPU1 to PCPU2 based on a simple distribution
> > algorithm (based on vcpu_id/vm_id). VCPU1 still blocks on PCPU1
> > but NDST set to PCPU2. Upon notification on PCPU2, local linked
> > list is searched to find VCPU1 and then an IPI is sent to PCPU1 to
> > unblock VCPU1;
> > 
> > Feng, do you see any overlook here? :-)
> 
> Kevin, thanks for the suggestion, it sounds a good idea, I will think
> it a bit more and do some trials based on it.

Hey!

I am curious how the trials went? This feature is pretty awesome and
I am wondering what the next step is?

Thanks!

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

Re: [Xen-devel] 4.6.2 preparations

[Wei Liu]

On Tue, May 17, 2016 at 05:33:48AM -0600, Jan Beulich wrote:
> All,
> 
> with this due in about three weeks, please indicate backports you find
> missing from its staging tree but you deem necessary in the release.
> I already have commit 556c69f4ef ("x86/PoD: skip eager reclaim when
> possible") queued, and I'm undecided about af07377007 ("IOMMU/x86:
> per-domain control structure is not HVM-specific") as well as the
> SMEP/SMAP fix (which first needs at least one more adjustment on
> master anyway).
> 
> Thanks, Jan
> 

I would like to propose backporting some mini-os patches to mini-os.git
stable-4.6 branch and update Config.mk in 4.6.

I guess I will bring that up with Samuel and then post patch here?

Wei.

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

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

Re: [Xen-devel] [PATCH v3 1/1] xen/device-tree: Do not remap IRQs for secondary IRQ controllers

[Wei Liu]

On Tue, May 17, 2016 at 02:15:50PM +0200, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Do not remap IRQs connected to secondary interrupt controllers.
> These IRQs have no meaning to us until they connect to the
> primary controller.
> 
> Secondary IRQ controllers will at some point connect to the
> primary controller (possibly via other IRQ controllers). We
> map the IRQs at that last connection point.
> 
> Reviewed-by: Julien Grall 
> Signed-off-by: Edgar E. Iglesias 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86/cpuid: Avoid unconditionally clobbering ITSC for guests

[Wei Liu]

On Mon, May 16, 2016 at 05:59:15PM +0100, Andrew Cooper wrote:
> In general, Invariant TSC is not a feature which can be advertised to guests,
> because it cannot be guaranteed across migrate.  domain_cpuid() goes so far as
> to deliberately clobber the feature flag under a number of circumstances.
> 
> Because ITSC is absent from the static {pv,hvm}_featureset masks, c/s b648feff
> "xen/x86: Improvements to in-hypervisor cpuid sanity checks" caused ITSC to be
> unconditionally masked out.
> 
> As an interim solution, include the hosts idea of ITSC along with the static
> {pv,hvm}_featureset when restricting the guests view of features.  This causes
> the hardware domain, and VMs explicitly configured with ITSC and no-migrate to
> be offered ITSC (subject to hardware availability).
> 
> Signed-off-by: Andrew Cooper 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [xen-unstable test] 94442: regressions - FAIL

[Andrew Cooper]

On 17/05/16 11:57, Jan Beulich wrote:
 On 16.05.16 at 11:24,  wrote:
>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
>>> flight 94442 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/94442/ 
>> [...]
>>>  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
>>> 94368
>> The changes in this flight shouldn't cause failure like this. See below.
>>
>> It is more likely to be caused by SMEP/SMAP fix, which are now in
>> master. It seems that previous run didn't discover this.
>>
>> Log file at:
>>
>> http://logs.test-lab.xenproject.org/osstest/logs/94442/test-amd64-i386-qemuu-rhel
>>  
>> 6hvm-intel/serial-italia0.log
>>
>> May 15 22:07:44.023500 (XEN) Xen BUG at entry.S:221
>> May 15 22:07:47.455549 (XEN) [ Xen-4.7.0-rc  x86_64  debug=y  Not 
>> tainted ]
>> May 15 22:07:47.463500 (XEN) CPU:0
>> May 15 22:07:47.463531 (XEN) RIP:e008:[] 
>> cr4_pv32_restore+0x37/0x40
>> May 15 22:07:47.463567 (XEN) RFLAGS: 00010287   CONTEXT: hypervisor 
>> (d0v3)
>> May 15 22:07:47.471503 (XEN) rax:    rbx: cf195e50   
>> rcx: 0001
>> May 15 22:07:47.479496 (XEN) rdx: 8300be907ff8   rsi: 7ff0   
>> rdi: 0022287e
>> May 15 22:07:47.487498 (XEN) rbp: 7cff416f80c7   rsp: 8300be907f08   
>> r8:  83023df8a000
>> May 15 22:07:47.495498 (XEN) r9:  83023df8a000   r10: deadbeef   
>> r11: 0080
>> May 15 22:07:47.503510 (XEN) r12: 8300bed32000   r13: 83023df8a000   
>> r14: 
>> May 15 22:07:47.503549 (XEN) r15: 83023df72000   cr0: 80050033   
>> cr4: 001526e0
>> May 15 22:07:47.511501 (XEN) cr3: 0002383d7000   cr2: b71ff000
>> May 15 22:07:47.519493 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0033   ss: 
>>    cs: e008
>> May 15 22:07:47.527520 (XEN) Xen code around  
>> (cr4_pv32_restore+0x37/0x40):
>> May 15 22:07:47.535491 (XEN)  3b 05 03 87 0a 00 74 02 <0f> 0b 5a 31 c0 c3 0f 
>> 1f 00 f6 42 04 01 0f 84 26
>> May 15 22:07:47.535531 (XEN) Xen stack trace from rsp=8300be907f08:
>> May 15 22:07:47.543502 (XEN) 82d080240f22 
>> 83023df72000 
>> May 15 22:07:47.551559 (XEN)83023df8a000 8300bed32000 
>> cf195e6c cf195e50
>> May 15 22:07:47.559494 (XEN)0080 deadbeef 
>> 83023df8a000 0206
>> May 15 22:07:47.567496 (XEN)0001 0001 
>>  7ff0
>> May 15 22:07:47.575503 (XEN)0022287e 0100 
>> c1001027 0061
>> May 15 22:07:47.575543 (XEN)0246 cf195e44 
>> 0069 beef
>> May 15 22:07:47.583508 (XEN)beef beef 
>> beef 
>> May 15 22:07:47.591503 (XEN)8300bed3  
>> 001526e0
>> May 15 22:07:47.599493 (XEN) Xen call trace:
>> May 15 22:07:47.599522 (XEN)[] 
>> cr4_pv32_restore+0x37/0x40
> I think I see the problem the introduction of caching in v3 introduced:
> In compat_restore_all_guest we have (getting patched in by altinsn
> patching):
>
> .Lcr4_alt:
> testb $3,UREGS_cs(%rsp)
> jpe   .Lcr4_alt_end
> mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
> and   $~XEN_CR4_PV32_BITS, %rax
> mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
> mov   %rax, %cr4
> .Lcr4_alt_end:
>
> If an NMI occurs between the updating og the cached value and the
> actual CR4 write, the NMI handling will cause the cached value to get
> SMEP+SMAP enabled again (in both cache and CR4), and once we
> get back here, we will clear it in just CR4.
>
> We don't want to undo the caching, as that gave us performance back
> at least for 64-bit PV guests.
>
> We also can't simply swap the two instructions: If we did, an NMI
> between the two would itself trigger the BUG in cr4_pv32_restore
> (as the check there assumes that CR4 always has no less of the
> bits of interest set than the cached value).
>
> The options I see are:
>
> 1) Ditch the debug check altogether, for being false positive in
> exactly one corner case.
>
> 2) Make the NMI handler recognize the single critical pair of
> instructions.
>
> 3) Change the code sequence above to
>
> .Lcr4_alt:
> testb $3,UREGS_cs(%rsp)
> jpe   .Lcr4_alt_end
> mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
> and   $~XEN_CR4_PV32_BITS, %rax
> 1:
> mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
> mov   %rax, %cr4
> /* (suitable comment goes here) */
> cmp   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
> jne   1b
> .Lcr4_alt_end:
>
> (assuming that an insane flood of NMIs not allowing this loop to
> be exited would be sufficiently problematic in other ways).

Re: [Xen-devel] [PATCH] x86: refine debugging of SMEP/SMAP fix

[Jan Beulich]

>>> On 17.05.16 at 14:56,  wrote:
> On 17/05/16 11:42, Jan Beulich wrote:
> On 17.05.16 at 12:28,  wrote:
>>> On 17/05/16 10:54, Jan Beulich wrote:
 Instead of just latching cr4_pv32_mask into %rdx, correct the found
 wrong value in %cr4 (to avoid triggering another BUG). The value left
 in %rdx should be sufficient for deducing cr4_pv32_mask from the
 register dump.
>>> Alternatively, you can reuse %rax (as its value is useless by this
>>> point) and leave %rdx as exactly cr4_pv32_mask.  This avoids needing a
>>> subsequent step to reverse engineer cr4_pv32_mask.
>> I don't view the value in %rax as useless - that's the set of bits
>> we have found set, which didn't match our expectation. Hence I
>> specifically don't want to re-use that register.
> 
> Ok.  We don't need to preserve any registers from the caller, so using a
> different one such as %rbx or %rcx would be fine.

Well, I can certainly (yet hesitantly) do that (and I see no harm in
clobbering another register), but ...

> The issue is that it is important to see precisely what cr4_pv32_mask is.

... it's not really clear to me what case you see where the value
just written to CR4 won't give you all the information you need.
After all cr4_pv32_mask doesn't have an awful lot of possible
values.

Jan


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

Re: [Xen-devel] 4.6.2 preparations

[Jan Beulich]

>>> On 17.05.16 at 14:45,  wrote:
> Should we backport something like
> 013396f93ee2d4ec416f701ae420c683b7327230 to help users avoid the
> deadlock present when using a domU with a Linux kernel 3.14 or newer?
> 
> If yes then you might want the init script fixes to make the daemons use
> that as well which were 1367e9e5ba4d1612e303123ec0bbf961100fcfa1 and
> 9ec6859322fc148742d9aa85596e03c3c2be.

Both tools side changes, so I'll defer to Ian.

Jan


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

Re: [Xen-devel] [GIT PULL] EFI ARM Xen support

[Stefano Stabellini]

On Tue, 17 May 2016, David Vrabel wrote:
> On 17/05/16 11:12, Stefano Stabellini wrote:
> > On Sat, 14 May 2016, Matt Fleming wrote:
> >> Folks,
> >>
> >> Please pull the following branch which contains support for Xen on ARM
> >> EFI platforms.
> >>
> >> This merge includes a merge of Stefano's xen/linux-next branch to pull
> >> in the prerequisites required for Shannon's commit:
> >>
> >>   11ee5491e5ff ("Xen: EFI: Parse DT parameters for Xen specific UEFI")
> >>
> >> as it needs both the latest changes in the EFI 'next' branch (now
> >> tip/efi/core) and xen/linux-next.
> >>
> >> I have intentionally not included the individual patches as I would
> >> normally do in a pull request, so that commit history created by my
> >> merging of Stefano's branch is preserved, and so that there's no way
> >> to accidentally apply the patches individually.
> >>
> >> The following changes since commit 
> >> 6c5450ef66816216e574885cf8d3ddb31ef77428:
> >>
> >>   efivarfs: Make efivarfs_file_ioctl() static (2016-05-07 07:06:13 +0200)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git 
> >> efi/arm-xen
> >>
> >> for you to fetch changes up to 11ee5491e5ff519e0d3a7018eb21351cb6955a98:
> >>
> >>   Xen: EFI: Parse DT parameters for Xen specific UEFI (2016-05-14 19:31:01 
> >> +0100)
> > 
> > Is this arrangement working for everybody, in particular the tip
> > maintainers?
> 
> Yes.

I meant the x86 tip maintainers (Thomas, Peter and Ingo).

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

[Xen-devel] [libvirt test] 94502: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  0e8a72a5ef16c093181af2c22e632ae639808a1b
baseline version:
 libvirt  4b3a46ca6a8e836b75801bd27198c28cfe33f698

Last test of basis94465  2016-05-16 04:20:01 Z1 days
Testing same since94502  2016-05-17 04:21:18 Z0 days1 attempts


People who touched revisions under test:
  Alexander Burluka 
  Andrea Bolognani 
  Cole Robinson 
  Erik Skultety 
  Fabian Freyer 
  Jiri Denemark 
  John Ferlan 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 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=0e8a72a5ef16c093181af2c22e632ae639808a1b
+ . ./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

Re: [Xen-devel] [PATCH] x86: refine debugging of SMEP/SMAP fix

[Andrew Cooper]

On 17/05/16 11:42, Jan Beulich wrote:
 On 17.05.16 at 12:28,  wrote:
>> On 17/05/16 10:54, Jan Beulich wrote:
>>> Instead of just latching cr4_pv32_mask into %rdx, correct the found
>>> wrong value in %cr4 (to avoid triggering another BUG). The value left
>>> in %rdx should be sufficient for deducing cr4_pv32_mask from the
>>> register dump.
>> Alternatively, you can reuse %rax (as its value is useless by this
>> point) and leave %rdx as exactly cr4_pv32_mask.  This avoids needing a
>> subsequent step to reverse engineer cr4_pv32_mask.
> I don't view the value in %rax as useless - that's the set of bits
> we have found set, which didn't match our expectation. Hence I
> specifically don't want to re-use that register.

Ok.  We don't need to preserve any registers from the caller, so using a
different one such as %rbx or %rcx would be fine.

The issue is that it is important to see precisely what cr4_pv32_mask is.

~Andrew

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

Re: [Xen-devel] 4.6.2 preparations

[Doug Goldstein]

On 5/17/16 6:33 AM, Jan Beulich wrote:
> All,
> 
> with this due in about three weeks, please indicate backports you find
> missing from its staging tree but you deem necessary in the release.
> I already have commit 556c69f4ef ("x86/PoD: skip eager reclaim when
> possible") queued, and I'm undecided about af07377007 ("IOMMU/x86:
> per-domain control structure is not HVM-specific") as well as the
> SMEP/SMAP fix (which first needs at least one more adjustment on
> master anyway).
> 
> Thanks, Jan
> 

Should we backport something like
013396f93ee2d4ec416f701ae420c683b7327230 to help users avoid the
deadlock present when using a domU with a Linux kernel 3.14 or newer?

If yes then you might want the init script fixes to make the daemons use
that as well which were 1367e9e5ba4d1612e303123ec0bbf961100fcfa1 and
9ec6859322fc148742d9aa85596e03c3c2be.

A no is ok.
-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH v10 2/3] vt-d: synchronize for Device-TLB flush one by one

[Jan Beulich]

>>> On 22.04.16 at 12:54,  wrote:
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -33,6 +33,8 @@ integer_param("vtd_qi_timeout", vtd_qi_timeout);
>  
>  #define IOMMU_QI_TIMEOUT (vtd_qi_timeout * MILLISECS(1))
>  
> +static int invalidate_sync(struct iommu *iommu);

__must_check?

> -static void queue_invalidate_iotlb(struct iommu *iommu,
> -u8 granu, u8 dr, u8 dw, u16 did, u8 am, u8 ih, u64 addr)
> +static int __must_check queue_invalidate_iotlb_sync(struct iommu *iommu,
> +u8 granu, u8 dr, u8 dw,
> +u16 did, u8 am, u8 ih,
> +u64 addr)
>  {
>  unsigned long flags;
>  unsigned int index;
> @@ -133,10 +141,12 @@ static void queue_invalidate_iotlb(struct iommu *iommu,
>  unmap_vtd_domain_page(qinval_entries);
>  qinval_update_qtail(iommu, index);
>  spin_unlock_irqrestore(>register_lock, flags);
> +
> +return invalidate_sync(iommu);
>  }

With this, ...

> @@ -346,9 +353,13 @@ static int flush_iotlb_qi(
>  if (cap_read_drain(iommu->cap))
>  dr = 1;
>  /* Need to conside the ih bit later */
> -queue_invalidate_iotlb(iommu,
> -   type >> DMA_TLB_FLUSH_GRANU_OFFSET, dr,
> -   dw, did, size_order, 0, addr);
> +ret = queue_invalidate_iotlb_sync(iommu,
> +  type >> DMA_TLB_FLUSH_GRANU_OFFSET,
> +  dr, dw, did, size_order, 0, addr);
> +
> +if ( ret )
> +return ret;
> +
>  if ( flush_dev_iotlb )
>  ret = dev_invalidate_iotlb(iommu, did, addr, size_order, type);
>  rc = invalidate_sync(iommu);

... why does this invalidate_sync() not go away?

Jan


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

Re: [Xen-devel] [for-4.7 2/2] xen/arm: p2m: Release the p2m lock before undoing the mappings

[Stefano Stabellini]

On Tue, 17 May 2016, Julien Grall wrote:
> Hi Stefano and Wei,
> 
> On 17/05/16 12:24, Stefano Stabellini wrote:
> > I think you are right. Especially with backports in mind, it would be
> > better to introduce an __apply_p2m_changes function which assumes that
> > the p2m lock has already been taken by the caller. Then you can base the
> > implementation of apply_p2m_changes on it.
> 
> > On Tue, 17 May 2016, Wei Chen wrote:
> > > Hi Julien,
> > > 
> > > I have some concern about this patch. Because we released the spinlock
> > > before remove the mapped memory. If somebody acquires the spinlock
> > > before we remove the mapped memory, this mapped memory region can be
> > > accessed by guest.
> > > 
> > > The apply_p2m_changes is no longer atomic. Is it a security risk?
> 
> Accesses to the page table have never been atomic, as soon as an entry is
> written in the page tables, the guest vCPUs or a prefetcher could read it.
> 
> The spinlock is only here to protect the page tables against concurrent
> modifications. Releasing the lock is not an issue as Xen does not promise any
> ordering for the p2m changes.

I understand that. However I am wondering whether it might be possible
for the guest to run commands which cause concurrent p2m change requests
on purpose, inserting something else between the first phase and the
second phase of apply_p2m_changes, causing problems to the hypervisor.
Or maybe not even on purpose, but causing problem to itself nonetheless.

Honestly it is true that it doesn't look like Xen could run into
troubles. But still this is a change in behaviour compared to the
current code (which I know doesn't actually work) and I wanted to flag
it.

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

Re: [Xen-devel] [PATCH v2 1/1] xen/device-tree: Do not remap IRQs for secondary IRQ controllers

[Edgar E. Iglesias]

On Tue, May 17, 2016 at 12:20:43PM +0100, Julien Grall wrote:
> Hi Edgar,
> 
> On 16/05/16 16:03, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias" 
> >
> >Do not remap IRQs connected to secondary interrupt controllers.
> >These IRQs have no meaning to us until they connect to the
> >primary controller.
> >
> >Secondary IRQ controllers will at some point connect to the
> >primary controller (possibly via other IRQ controllers). We
> >map the IRQs at that last connection point.
> >
> >Signed-off-by: Edgar E. Iglesias 
> 
> With the change mention below:
> 
> Reviewed-by:  Julien Grall 

Thanks Julien,

I've fixed the style and posted a v3.

Cheers,
Edgar


> 
> >---
> >  xen/common/device_tree.c | 16 
> >  1 file changed, 16 insertions(+)
> >
> >diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> >index 0ed86a7..02a7ede 100644
> >--- a/xen/common/device_tree.c
> >+++ b/xen/common/device_tree.c
> >@@ -1176,6 +1176,22 @@ int dt_for_each_irq_map(const struct dt_device_node 
> >*dev,
> >  for ( i = 0; i < pintsize; i++ )
> >  dt_raw_irq.specifier[i] = dt_read_number(imap + i, 1);
> >
> >+if ( dt_raw_irq.controller != dt_interrupt_controller )
> >+{
> >+/* We don't map IRQs connected to secondary IRQ controllers as
> 
> The comments in Xen looks like:
> 
> /*
>  * Foo
>  * Bart
>  */
> 
> >+ * these IRQs have no meaning to us until they connect to the
> >+ * primary controller.
> >+ *
> >+ * Secondary IRQ controllers will at some point connect to
> >+ * the primary controller (possibly via other IRQ controllers).
> >+ * We map the IRQs at that last connection point.
> >+ */
> >+imap += pintsize;
> >+imaplen -= pintsize;
> >+dt_dprintk(" -> Skipped IRQ for secondary IRQ controller\n");
> >+continue;
> >+}
> >+
> >  ret = dt_irq_translate(_raw_irq, _irq);
> >  if ( ret )
> >  {
> >
> 
> Regards,
> 
> -- 
> Julien Grall

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

[Xen-devel] Xen Security Advisory 176 (CVE-2016-4480) - x86 software guest page walk PS bit handling flaw

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 Xen Security Advisory CVE-2016-4480 / XSA-176
   version 3

   x86 software guest page walk PS bit handling flaw

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

The Page Size (PS) page table entry bit exists at all page table levels
other than L1.  Its meaning is reserved in L4, and conditionally
reserved in L3 and L2 (depending on hardware capabilities).  The
software page table walker in the hypervisor, however, so far ignored
that bit in L4 and (on respective hardware) L3 entries, resulting in
pages to be treated as page tables which the guest OS may not have
designated as such.  If the page in question is writable by an
unprivileged user, then that user will be able to map arbitrary guest
memory.

IMPACT
==

On vulnerable OSes, guest user mode code may be able to establish
mappings of arbitrary memory inside the guest, allowing it to elevate
its privileges inside the guest.

VULNERABLE SYSTEMS
==

All Xen versions expose the vulnerability.

ARM systems are not vulnerable.  x86 PV guests are not vulnerable.

To be vulnerable, a system must have both a vulnerable hypervisor, and
a vulnerable guest operating system, i.e. ones which make non-standard
use of the PS bit.  We are not aware of any vulnerable guest operating
systems, but we cannot rule it out.  We have checked with maintainers
of the following operating systems, all of whom have said that to the
best of their knowledge their operating system is not vulnerable:
Linux, FreeBSD, NetBSD, OpenBSD, and Solaris.  Nor has it been observed
in common proprietary operating systems.

MITIGATION
==

Running only PV guests will avoid this issue.

CREDITS
===

This issue was discovered by Jan Beulich from SUSE.

RESOLUTION
==

Applying the attached patch resolves this issue.

Note, however, that on hosts supporting 1Gb page mappings, for guests
which get this capability hidden via CPUID override in their config
file, fully correct behavior cannot be provided when using HAP paging.
This is a result of hardware behavior, which software cannot mitigate.
If that is a concern, such guests would need to be run in shadow paging
mode.

xsa176.patch  xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x

$ sha256sum xsa176*
e61c52477a8d8aa79111d686b103202ff8a558d8b3356635288c1290789b7eb3  xsa176.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJXOvhuAAoJEIP+FMlX6CvZ8JgH/A7YU+62hV5ayIx77AEwHeIJ
6nqf6B1k+Y0aEtiSbupHDIMwSw13FoR+LluaZjTXpBd251Ut1cwXkDvC6yiPHxq0
rWlb1/ka0rnOT3/rx0SgUjx02HbBzOFyyhZgR6W/gXV/S5fQhE26KbhEWvVaYCXO
QeryIsi9WBV/AWbx4fis4ecREhyEWPYkJ/bQq867P6YJLXQ1btc/CyZ7ahBjna68
VB9WE8czSs2x5QjJfKad5ksRAixdvaLFtVNOhnqJuJBickO3dd/IZPRxcSmazjdl
sIiSMfKU9nPb56MIgZxTWCLpvYLe8yarnvjiVOivaHl2cBT01UOjVJv/dSQEyrw=
=uQdJ
-END PGP SIGNATURE-


xsa176.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

I just set the domid to DOMID_SELF to pass the check, but another problem
is how to assign the gfn used to store #ve infomation. As I'm doing all the
things in user space, directly assign a new physical page seems impossible.
While LKM can do that with kmalloc and virt_to_phys, it cannot call user
space functions of libxc. Is there a libxc function to translate the
virtual address of malloc() to physical address?

2016-05-16 23:05 GMT+08:00 Big Strong :

> To solve that, I install xen and tools in the guest, so as to access its
> domain id and vcpu info to overcome the 'domain is null' error. Now the
> problem is solved, but errors comes at 'domain != DOMID_SELF' checking
> .
> The DOMID_SELF is always 32752 (0x7FF0), while a.domain is the domid of the
> guest, which induce the checking failed and exit. Any helps?
>
>
> 2016-05-16 17:06 GMT+08:00 Big Strong :
>
>> Your opinion is inspiring. During the past days, I've tried to directly
>> call HVMOP_altp2m_vcpu_enable_notify in guest by ioctl, this time it fails
>> for "domain is null" checking.
>> 
>>  I
>> thought it might because the guest is not able to achieve the vcpu info
>> of its current state
>> .
>> While in dom0, this is not a problem. But dom0 is unable to
>> call  HVMOP_altp2m_vcpu_enable_notify for the guest. How can I solve this
>> contradiction?
>>
>> 2016-05-12 23:17 GMT+08:00 Wei Liu :
>>
>>> On Thu, May 12, 2016 at 09:00:12PM +0800, Big Strong wrote:
>>> > I'm still not very clear why would do_altp2m_op change the domain to
>>> > current domain (which is dom0 in my case) when the cmd is
>>> > HVMOP_altp2m_vcpu_enable_notify
>>> > <
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;hb=743289d0296268fe6bad64531a24d8053afeb062#l6198
>>> >.
>>> > As to my case, it would prevent the dom0 to set the #ve info page for
>>> other
>>> > domUs because the check of is_hvm_domain would fail
>>> > <
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;hb=743289d0296268fe6bad64531a24d8053afeb062#l6204
>>> >and
>>> > the function will returns directly.
>>> >
>>>
>>> Maybe the intent of that HVMOP is to get called directly by the guest
>>> that is interested in such event?
>>>
>>> I looks like a natural restriction to me because the vcpu needs to set
>>> up handler for #ve AIUI. It's not likely that Dom0 can do this for
>>> arbitrary guest.
>>>
>>> Wei.
>>>
>>
>>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [for-4.7 2/2] xen/arm: p2m: Release the p2m lock before undoing the mappings

[Julien Grall]

Hi Stefano and Wei,

On 17/05/16 12:24, Stefano Stabellini wrote:

I think you are right. Especially with backports in mind, it would be
better to introduce an __apply_p2m_changes function which assumes that
the p2m lock has already been taken by the caller. Then you can base the
implementation of apply_p2m_changes on it.



On Tue, 17 May 2016, Wei Chen wrote:

Hi Julien,

I have some concern about this patch. Because we released the spinlock
before remove the mapped memory. If somebody acquires the spinlock
before we remove the mapped memory, this mapped memory region can be
accessed by guest.

The apply_p2m_changes is no longer atomic. Is it a security risk?


Accesses to the page table have never been atomic, as soon as an entry 
is written in the page tables, the guest vCPUs or a prefetcher could 
read it.


The spinlock is only here to protect the page tables against concurrent 
modifications. Releasing the lock is not an issue as Xen does not 
promise any ordering for the p2m changes.


Regards,

--
Julien Grall

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

[Xen-devel] 4.6.2 preparations

[Jan Beulich]

All,

with this due in about three weeks, please indicate backports you find
missing from its staging tree but you deem necessary in the release.
I already have commit 556c69f4ef ("x86/PoD: skip eager reclaim when
possible") queued, and I'm undecided about af07377007 ("IOMMU/x86:
per-domain control structure is not HVM-specific") as well as the
SMEP/SMAP fix (which first needs at least one more adjustment on
master anyway).

Thanks, Jan


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

Re: [Xen-devel] [for-4.7 2/2] xen/arm: p2m: Release the p2m lock before undoing the mappings

[Stefano Stabellini]

I think you are right. Especially with backports in mind, it would be
better to introduce an __apply_p2m_changes function which assumes that
the p2m lock has already been taken by the caller. Then you can base the
implementation of apply_p2m_changes on it.

Wei,
It might be best for you to give two tags in the future: Reviewed-by and
Tested-by separately. Lars uses scripts to parse git logs for tags and
generate stats. If you use non-standard tags, they won't be accounted
for correctly.


On Tue, 17 May 2016, Wei Chen wrote:
> Hi Julien,
> 
> I have some concern about this patch. Because we released the spinlock
> before remove the mapped memory. If somebody acquires the spinlock
> before we remove the mapped memory, this mapped memory region can be
> accessed by guest.
> 
> The apply_p2m_changes is no longer atomic. Is it a security risk?
> 
> On 2016/5/17 13:45, Wei Chen wrote:
> > Hi Julien,
> > 
> > This code looks good to me, and I have tested that
> > the deadlock is fixed by this patch.
> > 
> > Reviewed-and-Tested-by: Wei Chen 
> > 
> > Original:
> > (XEN) smmu: /smb/smmu@e080: P2M IPA size not supported (P2M=44
> > SMMU=40)!
> > (XEN) I/O virtualisation disabled
> > (XEN) Request p2m Spinlock...
> > (XEN) Request p2m Spinlock...OK
> > (XEN) apply_p2m_changes failed! rollback! call apply_p2m_changes
> > recursively!
> > (XEN) Request p2m Spinlock...
> > 
> > Patched:
> > (XEN) smmu: /smb/smmu@e080: P2M IPA size not supported (P2M=44
> > SMMU=40)!
> > (XEN) I/O virtualisation disabled
> > (XEN) Request p2m Spinlock...
> > (XEN) Request p2m Spinlock...OK
> > (XEN) apply_p2m_changes failed! rollback! call apply_p2m_changes
> > recursively!
> > (XEN) Request p2m Spinlock...
> > (XEN) Request p2m Spinlock...OK
> > 
> > 
> > On 2016/5/16 22:08, Julien Grall wrote:
> > > Since commit 4b25423a "arch/arm: unmap partially-mapped memory regions",
> > > Xen has been undoing the P2M mappings when an error occurred during
> > > insertion or memory allocation.
> > > 
> > > This is done by calling recursively apply_p2m_changes, however the
> > > second call is done with the p2m lock taken which will result in a
> > > deadlock for the current processor.
> > > 
> > > Fix it by moving the recursive call after the lock has been released.
> > > 
> > > Signed-off-by: Julien Grall 
> > > 
> > > ---
> > > I think we could unlock the p2m lock before freeing the temporary
> > > mapping. Although, I played safe as this is a bug fix for Xen 4.7
> > > and to be backported up to Xen 4.5.
> > > ---
> > >  xen/arch/arm/p2m.c | 16 
> > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > index 68c67b0..838d004 100644
> > > --- a/xen/arch/arm/p2m.c
> > > +++ b/xen/arch/arm/p2m.c
> > > @@ -1184,6 +1184,14 @@ out:
> > >  while ( (pg = page_list_remove_head(_pages)) )
> > >  free_domheap_page(pg);
> > > 
> > > +for ( level = P2M_ROOT_LEVEL; level < 4; level ++ )
> > > +{
> > > +if ( mappings[level] )
> > > +unmap_domain_page(mappings[level]);
> > > +}
> > > +
> > > +spin_unlock(>lock);
> > > +
> > >  if ( rc < 0 && ( op == INSERT || op == ALLOCATE ) &&
> > >   addr != start_gpaddr )
> > >  {
> > > @@ -1196,14 +1204,6 @@ out:
> > >mattr, 0, p2m_invalid,
> > > d->arch.p2m.default_access);
> > >  }
> > > 
> > > -for ( level = P2M_ROOT_LEVEL; level < 4; level ++ )
> > > -{
> > > -if ( mappings[level] )
> > > -unmap_domain_page(mappings[level]);
> > > -}
> > > -
> > > -spin_unlock(>lock);
> > > -
> > >  return rc;
> > >  }
> > > 
> > > 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> 

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

Re: [Xen-devel] [PATCH v5 0/6] Support calling functions on dedicated physical cpu

[Juergen Gross]

On 13/04/16 10:49, Juergen Gross wrote:
> On 06/04/16 16:17, Juergen Gross wrote:
>> Some hardware (e.g. Dell Studio laptops) require special functions to
>> be called on physical cpu 0 in order to avoid occasional hangs. When
>> running as dom0 under Xen this could be achieved only via special boot
>> parameters (vcpu pinning) limiting the hypervisor in it's scheduling
>> decisions.
>>
>> This patch series is adding a generic function to be able to temporarily
>> pin a (virtual) cpu to a dedicated physical cpu for executing above
>> mentioned functions on that specific cpu. The drivers (dcdbas and i8k)
>> requiring this functionality are modified accordingly.
>>
>> Changes in V5:
>> - patch 3: rename and reshuffle parameters of smp_call_on_cpu() as requested
>>   by Peter Zijlstra
>> - patch 3: test target cpu to be online as requested by Peter Zijlstra
>> - patch 4: less wordy messages as requested by David Vrabel
>>
>> Changes in V4:
>> - move patches 5 and 6 further up in the series
>> - patch 2 (was 5): WARN_ONCE in case platform doesn't support pinning
>>   as requested by Peter Zijlstra
>> - patch 3 (was 2): change return value in case of illegal cpu as
>>   requested by Peter Zijlstra
>> - patch 3 (was 2): make pinning of vcpu an option as suggested by
>>   Peter Zijlstra
>> - patches 5 and 6 (were 3 and 4): add call to get_online_cpus()
>>
>> Changes in V3:
>> - use get_cpu()/put_cpu() as suggested by David Vrabel
>>
>> Changes in V2:
>> - instead of manipulating the allowed set of cpus use cpu specific
>>   workqueue as requested by Peter Zijlstra
>> - add include/linux/hypervisor.h to hide architecture specific stuff
>>   from generic kernel code
>>
>> Juergen Gross (6):
>>   xen: sync xen header
>>   virt, sched: add generic vcpu pinning support
>>   smp: add function to execute a function synchronously on a cpu
>>   xen: add xen_pin_vcpu() to support calling functions on a dedicated
>> pcpu
>>   dcdbas: make use of smp_call_on_cpu()
>>   hwmon: use smp_call_on_cpu() for dell-smm i8k
>>
>>  MAINTAINERS   |   1 +
>>  arch/x86/include/asm/hypervisor.h |   4 ++
>>  arch/x86/kernel/cpu/hypervisor.c  |  11 +
>>  arch/x86/xen/enlighten.c  |  40 +++
>>  drivers/firmware/dcdbas.c |  51 +--
>>  drivers/hwmon/dell-smm-hwmon.c|  35 +++--
>>  include/linux/hypervisor.h|  17 +++
>>  include/linux/smp.h   |   3 ++
>>  include/xen/interface/sched.h | 100 
>> +++---
>>  kernel/smp.c  |  51 +++
>>  kernel/up.c   |  18 +++
>>  11 files changed, 273 insertions(+), 58 deletions(-)
>>  create mode 100644 include/linux/hypervisor.h
>>
> 
> So patches 1, 3 and 4 are acked. Any comments regarding patches 2, 5
> and 6?

Patch 6 gained another Ack. What about 2 and 5?


Juergen

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

Re: [Xen-devel] [PATCH v2 1/1] xen/device-tree: Do not remap IRQs for secondary IRQ controllers

[Julien Grall]

Hi Edgar,

On 16/05/16 16:03, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

Do not remap IRQs connected to secondary interrupt controllers.
These IRQs have no meaning to us until they connect to the
primary controller.

Secondary IRQ controllers will at some point connect to the
primary controller (possibly via other IRQ controllers). We
map the IRQs at that last connection point.

Signed-off-by: Edgar E. Iglesias 


With the change mention below:

Reviewed-by:  Julien Grall 


---
  xen/common/device_tree.c | 16 
  1 file changed, 16 insertions(+)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 0ed86a7..02a7ede 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1176,6 +1176,22 @@ int dt_for_each_irq_map(const struct dt_device_node *dev,
  for ( i = 0; i < pintsize; i++ )
  dt_raw_irq.specifier[i] = dt_read_number(imap + i, 1);

+if ( dt_raw_irq.controller != dt_interrupt_controller )
+{
+/* We don't map IRQs connected to secondary IRQ controllers as


The comments in Xen looks like:

/*
 * Foo
 * Bart
 */


+ * these IRQs have no meaning to us until they connect to the
+ * primary controller.
+ *
+ * Secondary IRQ controllers will at some point connect to
+ * the primary controller (possibly via other IRQ controllers).
+ * We map the IRQs at that last connection point.
+ */
+imap += pintsize;
+imaplen -= pintsize;
+dt_dprintk(" -> Skipped IRQ for secondary IRQ controller\n");
+continue;
+}
+
  ret = dt_irq_translate(_raw_irq, _irq);
  if ( ret )
  {



Regards,

--
Julien Grall

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

Re: [Xen-devel] [for-4.7 1/2] xen/arm: p2m: apply_p2m_changes: Do not undo more than necessary

[Stefano Stabellini]

On Mon, 16 May 2016, Julien Grall wrote:
> Since commit 4b25423a "arch/arm: unmap partially-mapped memory regions",
> Xen has been undoing the P2M mappings when an error occurred during
> insertion or memory allocation.
> 
> The function apply_p2m_changes can work with region not-aligned to a
> block size (2MB, 1G) or page size (4K). The mapping will be done by
> splitting the region in a set of regions aligned to the size supported
> by the page table.
> 
> The mapping of a region could fail when it is not possible to allocate
> memory for an intermediate table (i.e a new or when shattering a block).
> 
> When the mapping is undone, the end of the region is computed using the
> base address of the current region and the size of the failing level.
> However the failing level may not be the leaf one, therefore unrelated
> entries will be removed.
> 
> Fix it by removing the mapping from the start address up to the last
> region that has been successfully mapped.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> This patch is a bug fix for Xen 4.7 and candidate for backporting
> up to Xen 4.5. Without this patch, Xen may undo mapping which are
> not part of the region mapped when memory allocation has failed.
> 
> Note that Xen 4.7 has code to remove empty translation table (see
> commit de5162b "xen/arm: p2m: Remove translation table when it's
> empty"), however with this patch those tables will not be removed
> in case of failure. This will be fixed after the release as
> the change will be too intrusive for Xen 4.7.
> ---
>  xen/arch/arm/p2m.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index db21433..68c67b0 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1189,13 +1189,10 @@ out:
>  {
>  BUG_ON(addr == end_gpaddr);
>  /*
> - * addr keeps the address of the last successfully-inserted mapping,
> - * while apply_p2m_changes() considers an address range which is
> - * exclusive of end_gpaddr: add level_size to addr to obtain the
> - * right end of the range
> + * addr keeps the address of the end of the last 
> successfully-inserted
> + * mapping.
>   */
> -apply_p2m_changes(d, REMOVE,
> -  start_gpaddr, addr + level_sizes[level], 
> orig_maddr,
> +apply_p2m_changes(d, REMOVE, start_gpaddr, addr, orig_maddr,
>mattr, 0, p2m_invalid, d->arch.p2m.default_access);
>  }
>  
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] Backport requests to stable for Xen ARM

[Jan Beulich]

>>> On 17.05.16 at 12:49,  wrote:
> On Tue, 17 May 2016, Jan Beulich wrote:
>> >>> On 16.05.16 at 17:40,  wrote:
>> > On Mon, 16 May 2016, Julien Grall wrote:
>> >> It has been a while without any ARM backport request. Ian Campbell
>> >> used to keep a list of backport fixes for Xen ARM and apply them
>> >> to stable. Now that he left, I am not sure who will do it.
>> >> 
>> >> I would be fine to keep the list of patches, although I am not
>> >> a committer. Stefano do you plan to apply the backport?
>> > 
>> > I would be fine with doing that, but I am not sure who is responsible
>> > for backporting commits to stable trees. Any committer can do that, or
>> > do we have a set of stable maintainers? 
>> 
>> Formally I am the stable tree maintainer, but just like for tools
>> backports (which I have always been deferring to the tools
>> maintainers, and IanJ has been taking care of those mostly),
>> ARM backports have also mostly been taken care of by an
>> ARM maintainer who is also committer (used to be IanC). I'd
>> be glad if we could transition that arrangement onto your
>> shoulders.
> 
> All right. I made the backports.

Thanks!

Jan


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

Re: [Xen-devel] [xen-unstable test] 94442: regressions - FAIL

[Jan Beulich]

>>> On 16.05.16 at 11:24,  wrote:
> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
>> flight 94442 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/94442/ 
> [...]
>> 
>>  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
>> 94368
> 
> The changes in this flight shouldn't cause failure like this. See below.
> 
> It is more likely to be caused by SMEP/SMAP fix, which are now in
> master. It seems that previous run didn't discover this.
> 
> Log file at:
> 
> http://logs.test-lab.xenproject.org/osstest/logs/94442/test-amd64-i386-qemuu-rhel
>  
> 6hvm-intel/serial-italia0.log
> 
> May 15 22:07:44.023500 (XEN) Xen BUG at entry.S:221
> May 15 22:07:47.455549 (XEN) [ Xen-4.7.0-rc  x86_64  debug=y  Not tainted 
> ]
> May 15 22:07:47.463500 (XEN) CPU:0
> May 15 22:07:47.463531 (XEN) RIP:e008:[] 
> cr4_pv32_restore+0x37/0x40
> May 15 22:07:47.463567 (XEN) RFLAGS: 00010287   CONTEXT: hypervisor 
> (d0v3)
> May 15 22:07:47.471503 (XEN) rax:    rbx: cf195e50   
> rcx: 0001
> May 15 22:07:47.479496 (XEN) rdx: 8300be907ff8   rsi: 7ff0   
> rdi: 0022287e
> May 15 22:07:47.487498 (XEN) rbp: 7cff416f80c7   rsp: 8300be907f08   
> r8:  83023df8a000
> May 15 22:07:47.495498 (XEN) r9:  83023df8a000   r10: deadbeef   
> r11: 0080
> May 15 22:07:47.503510 (XEN) r12: 8300bed32000   r13: 83023df8a000   
> r14: 
> May 15 22:07:47.503549 (XEN) r15: 83023df72000   cr0: 80050033   
> cr4: 001526e0
> May 15 22:07:47.511501 (XEN) cr3: 0002383d7000   cr2: b71ff000
> May 15 22:07:47.519493 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0033   ss: 
>    cs: e008
> May 15 22:07:47.527520 (XEN) Xen code around  
> (cr4_pv32_restore+0x37/0x40):
> May 15 22:07:47.535491 (XEN)  3b 05 03 87 0a 00 74 02 <0f> 0b 5a 31 c0 c3 0f 
> 1f 00 f6 42 04 01 0f 84 26
> May 15 22:07:47.535531 (XEN) Xen stack trace from rsp=8300be907f08:
> May 15 22:07:47.543502 (XEN) 82d080240f22 
> 83023df72000 
> May 15 22:07:47.551559 (XEN)83023df8a000 8300bed32000 
> cf195e6c cf195e50
> May 15 22:07:47.559494 (XEN)0080 deadbeef 
> 83023df8a000 0206
> May 15 22:07:47.567496 (XEN)0001 0001 
>  7ff0
> May 15 22:07:47.575503 (XEN)0022287e 0100 
> c1001027 0061
> May 15 22:07:47.575543 (XEN)0246 cf195e44 
> 0069 beef
> May 15 22:07:47.583508 (XEN)beef beef 
> beef 
> May 15 22:07:47.591503 (XEN)8300bed3  
> 001526e0
> May 15 22:07:47.599493 (XEN) Xen call trace:
> May 15 22:07:47.599522 (XEN)[] 
> cr4_pv32_restore+0x37/0x40

I think I see the problem the introduction of caching in v3 introduced:
In compat_restore_all_guest we have (getting patched in by altinsn
patching):

.Lcr4_alt:
testb $3,UREGS_cs(%rsp)
jpe   .Lcr4_alt_end
mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
and   $~XEN_CR4_PV32_BITS, %rax
mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
mov   %rax, %cr4
.Lcr4_alt_end:

If an NMI occurs between the updating og the cached value and the
actual CR4 write, the NMI handling will cause the cached value to get
SMEP+SMAP enabled again (in both cache and CR4), and once we
get back here, we will clear it in just CR4.

We don't want to undo the caching, as that gave us performance back
at least for 64-bit PV guests.

We also can't simply swap the two instructions: If we did, an NMI
between the two would itself trigger the BUG in cr4_pv32_restore
(as the check there assumes that CR4 always has no less of the
bits of interest set than the cached value).

The options I see are:

1) Ditch the debug check altogether, for being false positive in
exactly one corner case.

2) Make the NMI handler recognize the single critical pair of
instructions.

3) Change the code sequence above to

.Lcr4_alt:
testb $3,UREGS_cs(%rsp)
jpe   .Lcr4_alt_end
mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
and   $~XEN_CR4_PV32_BITS, %rax
1:
mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
mov   %rax, %cr4
/* (suitable comment goes here) */
cmp   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
jne   1b
.Lcr4_alt_end:

(assuming that an insane flood of NMIs not allowing this loop to
be exited would be sufficiently problematic in other ways).

I dislike 1, and between 2 and 3 I think I'd prefer the latter, unless
someone else sees something wrong with such an approach.

> May 15 22:07:47.607524 (XEN) Xen BUG at 

Re: [Xen-devel] Backport requests to stable for Xen ARM

[Stefano Stabellini]

On Tue, 17 May 2016, Jan Beulich wrote:
> >>> On 16.05.16 at 17:40,  wrote:
> > On Mon, 16 May 2016, Julien Grall wrote:
> >> It has been a while without any ARM backport request. Ian Campbell
> >> used to keep a list of backport fixes for Xen ARM and apply them
> >> to stable. Now that he left, I am not sure who will do it.
> >> 
> >> I would be fine to keep the list of patches, although I am not
> >> a committer. Stefano do you plan to apply the backport?
> > 
> > I would be fine with doing that, but I am not sure who is responsible
> > for backporting commits to stable trees. Any committer can do that, or
> > do we have a set of stable maintainers? 
> 
> Formally I am the stable tree maintainer, but just like for tools
> backports (which I have always been deferring to the tools
> maintainers, and IanJ has been taking care of those mostly),
> ARM backports have also mostly been taken care of by an
> ARM maintainer who is also committer (used to be IanC). I'd
> be glad if we could transition that arrangement onto your
> shoulders.

All right. I made the backports.

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH] x86: refine debugging of SMEP/SMAP fix

[Jan Beulich]

>>> On 17.05.16 at 12:28,  wrote:
> On 17/05/16 10:54, Jan Beulich wrote:
>> Instead of just latching cr4_pv32_mask into %rdx, correct the found
>> wrong value in %cr4 (to avoid triggering another BUG). The value left
>> in %rdx should be sufficient for deducing cr4_pv32_mask from the
>> register dump.
> 
> Alternatively, you can reuse %rax (as its value is useless by this
> point) and leave %rdx as exactly cr4_pv32_mask.  This avoids needing a
> subsequent step to reverse engineer cr4_pv32_mask.

I don't view the value in %rax as useless - that's the set of bits
we have found set, which didn't match our expectation. Hence I
specifically don't want to re-use that register.

Jan


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

Re: [Xen-devel] [GIT PULL] EFI ARM Xen support

[David Vrabel]

On 17/05/16 11:12, Stefano Stabellini wrote:
> On Sat, 14 May 2016, Matt Fleming wrote:
>> Folks,
>>
>> Please pull the following branch which contains support for Xen on ARM
>> EFI platforms.
>>
>> This merge includes a merge of Stefano's xen/linux-next branch to pull
>> in the prerequisites required for Shannon's commit:
>>
>>   11ee5491e5ff ("Xen: EFI: Parse DT parameters for Xen specific UEFI")
>>
>> as it needs both the latest changes in the EFI 'next' branch (now
>> tip/efi/core) and xen/linux-next.
>>
>> I have intentionally not included the individual patches as I would
>> normally do in a pull request, so that commit history created by my
>> merging of Stefano's branch is preserved, and so that there's no way
>> to accidentally apply the patches individually.
>>
>> The following changes since commit 6c5450ef66816216e574885cf8d3ddb31ef77428:
>>
>>   efivarfs: Make efivarfs_file_ioctl() static (2016-05-07 07:06:13 +0200)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git efi/arm-xen
>>
>> for you to fetch changes up to 11ee5491e5ff519e0d3a7018eb21351cb6955a98:
>>
>>   Xen: EFI: Parse DT parameters for Xen specific UEFI (2016-05-14 19:31:01 
>> +0100)
> 
> Is this arrangement working for everybody, in particular the tip
> maintainers?

Yes.

David

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 7b13510f2a0a2a118cdafdaa67720ca8e3fe37de
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis38467  2015-12-08 23:22:45 Z  160 days
Testing same since44423  2016-05-17 08:20:41 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  chenzhihui 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hegde, Nagaraj P nagaraj-p.he...@hpe.com
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  Linn Crosetto 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Maurice Ma 
  Michael Brown 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michael Zimmermann <[mailto:sigmaepsilo...@gmail.com]>
  Michael Zimmermann 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Pedroa Liu 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Sunny Wang 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 

[Xen-devel] libfs,xenfs: replace /proc/xen/xenbus with a symlink

[David Vrabel]

Using /proc/xen/xenbus can cause deadlocks on the atomic file position
mutex since this file should behave like a character device and not a
regular file.  This is easiest to achive by making it a symlink to the
existing /dev/xen/xenbus device.

This requires extending simple_fill_super() to add symlinks as well as
regular files.

David


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

Re: [Xen-devel] [PATCH] x86: refine debugging of SMEP/SMAP fix

[Andrew Cooper]

On 17/05/16 10:54, Jan Beulich wrote:
> Instead of just latching cr4_pv32_mask into %rdx, correct the found
> wrong value in %cr4 (to avoid triggering another BUG). The value left
> in %rdx should be sufficient for deducing cr4_pv32_mask from the
> register dump.

Alternatively, you can reuse %rax (as its value is useless by this
point) and leave %rdx as exactly cr4_pv32_mask.  This avoids needing a
subsequent step to reverse engineer cr4_pv32_mask.

>
> Also there is one more place for XEN_CR4_PV32_BITS to be used.

So there is.  Sorry for missing it.

~Andrew

>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -182,7 +182,7 @@ ENTRY(compat_restore_all_guest)
>  testb $3,UREGS_cs(%rsp)
>  jpe   .Lcr4_alt_end
>  mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
> -and   $~(X86_CR4_SMEP|X86_CR4_SMAP), %rax
> +and   $~XEN_CR4_PV32_BITS, %rax
>  mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
>  mov   %rax, %cr4
>  .Lcr4_alt_end:
> @@ -218,8 +218,10 @@ ENTRY(cr4_pv32_restore)
>  and   cr4_pv32_mask(%rip), %rax
>  cmp   cr4_pv32_mask(%rip), %rax
>  je1f
> -/* Cause cr4_pv32_mask to be visible in the BUG register dump. */
> -mov   cr4_pv32_mask(%rip), %rdx
> +/* Avoid coming back here while handling the #UD we cause below. */
> +mov   %cr4, %rdx
> +orcr4_pv32_mask(%rip), %rdx
> +mov   %rdx, %cr4
>  BUG
>  1:
>  #endif
>
>
>
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Xen-devel] [PATCHv1 2/2] xenfs: replace xenbus and privcmd with symlinks

[David Vrabel]

/proc/xen/xenbus does not work correctly.  A read blocked waiting for
a xenstore message holds the mutex needed for atomic file position
updates.  This blocks any writes on the same file handle, which can
deadlock if the write is needed to unblock the read.

/proc/xen/xenbus is supposed to be identical to the character device
/dev/xen/xenbus so replace the file with a symlink.

Similarly, replace /proc/xen/privcmd with a symlink since it should be
the same as /dev/xen/privcmd.

Signed-off-by: David Vrabel 
---
v2:
- remove unneeded includes
---
 drivers/xen/xenfs/super.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 8559a71..0f2e2cd 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -18,8 +18,6 @@
 #include 
 
 #include "xenfs.h"
-#include "../privcmd.h"
-#include "../xenbus/xenbus_comms.h"
 
 #include 
 
@@ -45,16 +43,16 @@ static const struct file_operations capabilities_file_ops = 
{
 static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
static struct tree_descr xenfs_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{""},
};
 
static struct tree_descr xenfs_init_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{ "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
{ "xsd_port", _port_file_ops, S_IRUSR|S_IWUSR},
 #ifdef CONFIG_XEN_SYMS
-- 
2.1.4


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

[Xen-devel] [PATCHv1 1/2] libfs: allow simple_fill_super() to add symlinks

[David Vrabel]

simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
The target is provided in the new "link" field.

Signed-off-by: David Vrabel 
---
v2:
- simplified.
---
 fs/libfs.c | 15 +--
 include/linux/fs.h |  2 +-
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/fs/libfs.c b/fs/libfs.c
index f3fa82c..5b3a391 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -517,9 +517,20 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
dput(dentry);
goto out;
}
-   inode->i_mode = S_IFREG | files->mode;
+   if (files->mode & S_IFLNK) {
+   inode->i_mode = files->mode;
+   inode->i_op = _symlink_inode_operations;
+   inode->i_link = kstrdup(files->link, GFP_KERNEL);
+   if (!inode->i_link) {
+   iput(inode);
+   dput(dentry);
+   goto out;
+   }
+   } else {
+   inode->i_mode = S_IFREG | files->mode;
+   inode->i_fop = files->ops;
+   }
inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
-   inode->i_fop = files->ops;
inode->i_ino = i;
d_add(dentry, inode);
}
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 70e61b5..8a09998 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2897,7 +2897,7 @@ extern const struct file_operations simple_dir_operations;
 extern const struct inode_operations simple_dir_inode_operations;
 extern void make_empty_dir_inode(struct inode *inode);
 extern bool is_empty_dir_inode(struct inode *inode);
-struct tree_descr { char *name; const struct file_operations *ops; int mode; };
+struct tree_descr { char *name; const struct file_operations *ops; int mode; 
char *link; };
 struct dentry *d_alloc_name(struct dentry *, const char *);
 extern int simple_fill_super(struct super_block *, unsigned long, struct 
tree_descr *);
 extern int simple_pin_fs(struct file_system_type *, struct vfsmount **mount, 
int *count);
-- 
2.1.4


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

Re: [Xen-devel] [GIT PULL] EFI ARM Xen support

[Stefano Stabellini]

On Sat, 14 May 2016, Matt Fleming wrote:
> Folks,
> 
> Please pull the following branch which contains support for Xen on ARM
> EFI platforms.
> 
> This merge includes a merge of Stefano's xen/linux-next branch to pull
> in the prerequisites required for Shannon's commit:
> 
>   11ee5491e5ff ("Xen: EFI: Parse DT parameters for Xen specific UEFI")
> 
> as it needs both the latest changes in the EFI 'next' branch (now
> tip/efi/core) and xen/linux-next.
> 
> I have intentionally not included the individual patches as I would
> normally do in a pull request, so that commit history created by my
> merging of Stefano's branch is preserved, and so that there's no way
> to accidentally apply the patches individually.
> 
> The following changes since commit 6c5450ef66816216e574885cf8d3ddb31ef77428:
> 
>   efivarfs: Make efivarfs_file_ioctl() static (2016-05-07 07:06:13 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git efi/arm-xen
> 
> for you to fetch changes up to 11ee5491e5ff519e0d3a7018eb21351cb6955a98:
> 
>   Xen: EFI: Parse DT parameters for Xen specific UEFI (2016-05-14 19:31:01 
> +0100)

Is this arrangement working for everybody, in particular the tip
maintainers?

I am asking because I didn't receive any replies to this or to
http://marc.info/?l=linux-kernel=146317737928595=2.



> David Vrabel (1):
>   xen/gntdev: reduce copy batch size to 16
> 
> Matt Fleming (1):
>   Merge branch 'xen/linux-next' into efi/arm-xen
> 
> Shannon Zhao (16):
>   Xen: ACPI: Hide UART used by Xen
>   xen/grant-table: Move xlated_setup_gnttab_pages to common place
>   Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
>   arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
>   xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
>   Xen: ARM: Add support for mapping platform device mmio
>   Xen: ARM: Add support for mapping AMBA device mmio
>   Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
>   xen/hvm/params: Add a new delivery type for event-channel in 
> HVM_PARAM_CALLBACK_IRQ
>   arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
>   ARM: XEN: Move xen_early_init() before efi_init()
>   ARM: Xen: Document UEFI support on Xen ARM virtual platforms
>   XEN: EFI: Move x86 specific codes to architecture directory
>   ARM64: XEN: Add a function to initialize Xen specific UEFI runtime 
> services
>   FDT: Add a helper to get the subnode by given name
>   Xen: EFI: Parse DT parameters for Xen specific UEFI
> 
> Stefano Stabellini (1):
>   xen/x86: don't lose event interrupts
> 
>  Documentation/devicetree/bindings/arm/xen.txt |  35 +
>  arch/arm/include/asm/xen/xen-ops.h|   6 +
>  arch/arm/kernel/setup.c   |   2 +-
>  arch/arm/xen/Makefile |   1 +
>  arch/arm/xen/efi.c|  40 ++
>  arch/arm/xen/enlighten.c  | 125 
>  arch/arm64/include/asm/xen/xen-ops.h  |   6 +
>  arch/arm64/kernel/setup.c |   2 +-
>  arch/arm64/xen/Makefile   |   1 +
>  arch/x86/xen/efi.c| 111 +++
>  arch/x86/xen/grant-table.c|  57 +---
>  arch/x86/xen/time.c   |   6 +-
>  drivers/acpi/scan.c   |  74 ++
>  drivers/firmware/efi/arm-runtime.c|   5 +
>  drivers/firmware/efi/efi.c|  81 ---
>  drivers/of/fdt.c  |  13 ++
>  drivers/xen/Kconfig   |   2 +-
>  drivers/xen/Makefile  |   1 +
>  drivers/xen/arm-device.c  | 196 
> ++
>  drivers/xen/efi.c | 173 +--
>  drivers/xen/gntdev.c  |   2 +-
>  drivers/xen/xlate_mmu.c   |  77 ++
>  include/linux/of_fdt.h|   2 +
>  include/xen/interface/hvm/params.h|  40 +-
>  include/xen/interface/memory.h|   1 +
>  include/xen/xen-ops.h |  32 +++--
>  26 files changed, 840 insertions(+), 251 deletions(-)
>  create mode 100644 arch/arm/include/asm/xen/xen-ops.h
>  create mode 100644 arch/arm/xen/efi.c
>  create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
>  create mode 100644 drivers/xen/arm-device.c
> 

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

[Xen-devel] [xen-unstable baseline-only test] 44421: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44421 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44421/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 44420
 test-amd64-amd64-pygrub   9 debian-di-install fail REGR. vs. 44420

Regressions which are regarded as allowable (not blocking):
 build-armhf-xsm   3 host-install(3)  broken like 44420
 build-armhf-pvops 3 host-install(3)  broken like 44420
 build-armhf   3 host-install(3)  broken like 44420
 build-amd64-rumpuserxen   6 xen-buildfail   like 44420
 build-i386-rumpuserxen6 xen-buildfail   like 44420
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44420
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44420

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83
baseline version:
 xen  fcab4cec98ae1f56312744c19f608856261b20cf

Last test of basis44420  2016-05-16 12:49:49 Z0 days
Testing same since44421  2016-05-16 23:52:04 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 

Re: [Xen-devel] [HACKATHON 2016] ARM Status

[Julien Grall]

Hi Konrad,

On 16/05/16 20:43, Konrad Rzeszutek Wilk wrote:

On Thu, May 05, 2016 at 04:41:51PM +0100, Steve Capper wrote:

[Apologies for the late send]

Xen - ARM Status

There was discussion on the following items:

*) Booting Xen on 64-bit ARM SoC
   o) Unfortunately Xen was executed in EL1.
   o) Advice was given that the firmware should boot the Xen in EL2.
   o) The ARMv7 secure mode switch to Hyp trick is not valid on AArch64.

*) ARMv7 Cubietruck bringup was also discussed
   o) One pain point mentioned was debugging the DomU guest
   o) There are no debug capabilities for a Xen guest, but
   o) There are a set of hyp calls that can be placed in the guest to
  aid with debugging.
   o) The documentation on these hyp calls needs refreshing in a wiki
  somewhere?
   o) Details of these can be found at: xen/arch/arm/traps.c

*) There is no list of names/ownership for HW platforms
   o) This is due to it being non-trivial to deduce a name from wiki
  activity.
   o) If people care about a board, they should make themselves known.


I care about the CubieBoard5. I hadn't actually been able to do
much on it as the default loaded firmware does not seem to be
able to read any microSD card so I am afraid to update the uboot.


I haven't played with the CubieBoard5 before. From my understanding, the 
firmware/bootloader resides at the beginning of the SD-card.


So if you backup your SD-card you will be able to revert any non-working 
change. For more details see [1].


Regards,

[1] https://linux-sunxi.org/Bootable_SD_card#Bootloader

--
Julien Grall

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

Re: [Xen-devel] question about xl migrate

[Zhang, Chunyu]

hi Andrew
>
 2. line 125
 in hvm mode,would not be a balloon page.
 gfn would not be INVALID_MFN.
 mfn would be INVALID_MFN.
 right?
>>> I don't understand what you asking here.
>> i think those code should delete:
 125 /* Likely a ballooned page. */
>> if page is ballooed, gfns is not  INVALID_MFN, but mormal.
>
>Perhaps for HVM guests.  Definitely not for PV guests however.
get it.
>
 126 if ( mfns[i] == INVALID_MFN )
 127 {
 128 set_bit(ctx->save.batch_pfns[i], ctx->save.deferred_pages);
 129 ++ctx->save.nr_deferred_pages;
 130 }
>> those code is not for balloon.
>>
>> when xc_get_pfn_type_batch is called,
>> ballooned page type is XEN_DOMCTL_PFINFO_XTAB
>> XEN_DOMCTL_PFINFO_XTAB is for ballooned pages.
>
>That is covered by the later check.  This code needs to work for PV
>guests as well as HVM guests.  You absolutely can't go deleting this
>clause, or you will break migration for PV guests.
get it.
thanks..
>
>~Andrew
>
>

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

[Xen-devel] [PATCH] x86: refine debugging of SMEP/SMAP fix

[Jan Beulich]

Instead of just latching cr4_pv32_mask into %rdx, correct the found
wrong value in %cr4 (to avoid triggering another BUG). The value left
in %rdx should be sufficient for deducing cr4_pv32_mask from the
register dump.

Also there is one more place for XEN_CR4_PV32_BITS to be used.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -182,7 +182,7 @@ ENTRY(compat_restore_all_guest)
 testb $3,UREGS_cs(%rsp)
 jpe   .Lcr4_alt_end
 mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
-and   $~(X86_CR4_SMEP|X86_CR4_SMAP), %rax
+and   $~XEN_CR4_PV32_BITS, %rax
 mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
 mov   %rax, %cr4
 .Lcr4_alt_end:
@@ -218,8 +218,10 @@ ENTRY(cr4_pv32_restore)
 and   cr4_pv32_mask(%rip), %rax
 cmp   cr4_pv32_mask(%rip), %rax
 je1f
-/* Cause cr4_pv32_mask to be visible in the BUG register dump. */
-mov   cr4_pv32_mask(%rip), %rdx
+/* Avoid coming back here while handling the #UD we cause below. */
+mov   %cr4, %rdx
+orcr4_pv32_mask(%rip), %rdx
+mov   %rdx, %cr4
 BUG
 1:
 #endif



x86: refine debugging of SMEP/SMAP fix

Instead of just latching cr4_pv32_mask into %rdx, correct the found
wrong value in %cr4 (to avoid triggering another BUG). The value left
in %rdx should be sufficient for deducing cr4_pv32_mask from the
register dump.

Also there is one more place for XEN_CR4_PV32_BITS to be used.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -182,7 +182,7 @@ ENTRY(compat_restore_all_guest)
 testb $3,UREGS_cs(%rsp)
 jpe   .Lcr4_alt_end
 mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
-and   $~(X86_CR4_SMEP|X86_CR4_SMAP), %rax
+and   $~XEN_CR4_PV32_BITS, %rax
 mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
 mov   %rax, %cr4
 .Lcr4_alt_end:
@@ -218,8 +218,10 @@ ENTRY(cr4_pv32_restore)
 and   cr4_pv32_mask(%rip), %rax
 cmp   cr4_pv32_mask(%rip), %rax
 je1f
-/* Cause cr4_pv32_mask to be visible in the BUG register dump. */
-mov   cr4_pv32_mask(%rip), %rdx
+/* Avoid coming back here while handling the #UD we cause below. */
+mov   %cr4, %rdx
+orcr4_pv32_mask(%rip), %rdx
+mov   %rdx, %cr4
 BUG
 1:
 #endif
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [seabios test] 94496: regressions - FAIL

[osstest service owner]

flight 94496 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94496/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
92452

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92452
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92452

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

version targeted for testing:
 seabios  1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98
baseline version:
 seabios  c8e105a4d5e52e8e7539ab1f2cd07ebe0ae9033a

Last test of basis92452  2016-04-23 11:37:00 Z   23 days
Testing same since94496  2016-05-17 01:12:44 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Paul Menzel 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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

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

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

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


Not pushing.


commit 1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98
Author: Kevin O'Connor 
Date:   Mon May 16 20:51:17 2016 -0400

tcgbios: Remove unused const variable

Remove the unused array `PhysicalPresence_CMD_DISABLE` to fix GCC 6
warnings.

Signed-off-by: Paul Menzel 
Signed-off-by: Kevin O'Connor 

commit 0024cd77f88a38036a228fb885217ff06e97464c
Author: Kevin O'Connor 
Date:   Mon May 16 20:50:28 2016 -0400

usb-xhci: Remove unused const variables

Remove the unused arrays `eptype_to_xhci_in` and `eptype_to_xhci_out` to
fix GCC 6 warnings.

Signed-off-by: Paul Menzel 
Signed-off-by: Kevin O'Connor 

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

Re: [Xen-devel] question about xl migrate

[Andrew Cooper]

>>> 2. line 125
>>> in hvm mode,would not be a balloon page.
>>> gfn would not be INVALID_MFN.
>>> mfn would be INVALID_MFN.
>>> right?
>> I don't understand what you asking here.
> i think those code should delete:
>>> 125 /* Likely a ballooned page. */
> if page is ballooed, gfns is not  INVALID_MFN, but mormal.

Perhaps for HVM guests.  Definitely not for PV guests however.

>>> 126 if ( mfns[i] == INVALID_MFN )
>>> 127 {
>>> 128 set_bit(ctx->save.batch_pfns[i], ctx->save.deferred_pages);
>>> 129 ++ctx->save.nr_deferred_pages;
>>> 130 }
> those code is not for balloon.
>
> when xc_get_pfn_type_batch is called,
> ballooned page type is XEN_DOMCTL_PFINFO_XTAB
> XEN_DOMCTL_PFINFO_XTAB is for ballooned pages.

That is covered by the later check.  This code needs to work for PV
guests as well as HVM guests.  You absolutely can't go deleting this
clause, or you will break migration for PV guests.

~Andrew

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