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

[osstest service owner]

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

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

Last test of basis   122362  2018-04-23 11:18:13 Z2 days
Testing same since   122396  2018-04-24 18:04:23 Z1 days1 attempts


People who touched revisions under test:
  Evan Lloyd 
  Gary Lin 
  Girish Pathak 
  Girish Pathak 
  Laszlo Ersek 
  Leif Lindholm 

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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   ee4dc24f57..d3180516f3  d3180516f31b93f3dc14ebb0191cd78bcfc052d9 -> 
xen-tested-master

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

[Xen-devel] [xen-4.10-testing test] 122391: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-raw   broken
 test-amd64-amd64-xl-qemut-ws16-amd64 broken
 test-amd64-i386-freebsd10-i386 broken

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-ws16-amd64  4 host-install(4)  broken pass in 122356
 test-amd64-i386-freebsd10-i386  4 host-install(4)broken pass in 122356
 test-amd64-i386-xl-raw4 host-install(4)  broken pass in 122356
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail in 122356 pass in 122391
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 122356 pass in 122391
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 
122356 pass in 122391

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail in 122356 never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 

[Xen-devel] [qemu-mainline test] 122394: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122357
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122357
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122357
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122357
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122357
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122357
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuu4743c23509a51bd4ee85cc272287a41917d1be35
baseline version:
 qemuu27e757e29cc79f3f104d2a84d17cdb3b4c11c8ff

Last test of basis   122357  2018-04-23 11:07:12 Z2 days
Testing same since   122394  2018-04-24 16:40:23 Z1 days1 attempts


People who touched revisions under test:
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass   

[Xen-devel] [linux-3.18 test] 122388: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
REGR. vs. 122286
 test-armhf-armhf-xl-xsm 16 guest-start/debian.repeat fail REGR. vs. 122286

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail like 122286
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122286
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122286
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122286
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122286
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122286
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122286
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122286
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux915b8f498b1a2dacc4f81dc949e310915c7374f2
baseline version:
 linux78db2bbfa06cc39707054093fbbc5e573a643d3e

Last test of basis   122286  2018-04-14 16:36:32 Z   11 days
Testing same since   122388  2018-04-24 07:40:13 Z1 days1 attempts


People who touched 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  67c632e38a9894269babd854e122c47a8fbf545c
baseline version:
 xen  82fed8530d8832a9a7b99554dfc49b041351785a

Last test of basis   122416  2018-04-25 15:03:27 Z0 days
Testing same since   122421  2018-04-25 17:00:32 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  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 :

To xenbits.xen.org:/home/xen/git/xen.git
   82fed8530d..67c632e38a  67c632e38a9894269babd854e122c47a8fbf545c -> smoke

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

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Dongwon Kim]

On Wed, Apr 25, 2018 at 08:34:55AM +0200, Daniel Vetter wrote:
> On Wed, Apr 25, 2018 at 09:07:07AM +0300, Oleksandr Andrushchenko wrote:
> > On 04/24/2018 11:35 PM, Dongwon Kim wrote:
> > > Had a meeting with Daniel and talked about bringing out generic
> > > part of hyper-dmabuf to the userspace, which means we most likely
> > > reuse IOCTLs defined in xen-zcopy for our use-case if we follow
> > > his suggestion.
> > I will still have kernel side API, so backends/frontends implemented
> > in the kernel can access that functionality as well.
> > > 
> > > So assuming we use these IOCTLs as they are,
> > > Several things I would like you to double-check..
> > > 
> > > 1. returning gref as is to the user space is still unsafe because
> > > it is a constant, easy to guess and any process that hijacks it can easily
> > > exploit the buffer. So I am wondering if it's possible to keep dmabuf-to
> > > -gref or gref-to-dmabuf in kernel space and add other layers on top
> > > of those in actual IOCTLs to add some safety.. We introduced flink like
> > > hyper_dmabuf_id including random number but many says even that is still
> > > not safe.
> > Yes, it is generally unsafe. But even if we have implemented
> > the approach you have in hyper-dmabuf or similar, what stops
> > malicious software from doing the same with the existing gntdev UAPI?
> > No need to brute force new UAPI if there is a simpler one.
> > That being said, I'll put security aside at the first stage,
> > but of course we can start investigating ways to improve
> > (I assume you already have use-cases where security issues must
> > be considered, so, probably you can tell more on what was investigated
> > so far).

Yeah, although we think we lowered the chance of guessing the right id
by adding random number to it, the security hole is still there as far
as we use a constant id across VMs. We understood this from the beginning
but couldn't find a better way. So what we proposed is to make sure our
customer understand this and prepare very secure way to handle this id
in the userspace (mattrope however recently proposed a "hyper-pipe" which
FD-type id can be converted and exchanged safely through. So we are looking
into this now.)

And another approach we have proposed is to use event-polling, that lets
the privileged userapp in importing guest to know about a new exported
DMABUF so that it can retrieve it from the queue then redistribute to
other applications. This method is not very flexible however, is one way
to hide ID from userspace completely.

Anyway, yes, we can continue to investigate the possible way to make it
more secure. 

> 
> Maybe a bit more context here:
> 
> So in graphics we have this old flink approach for buffer sharing with
> processes, and it's unsafe because way too easy to guess the buffer
> handles. And anyone with access to the graphics driver can then import
> that buffer object. We switched to file descriptor passing to make sure
> only the intended recipient can import a buffer.
> 
> So at the vm->vm level it sounds like grefs are safe, because they're only
> for a specific other guest (or sets of guests, not sure about). That means
> security is only within the OS. For that you need to make sure that
> unpriviledge userspace simply can't ever access a gref. If that doesn't
> work out, then I guess we should improve the xen gref stuff to have a more
> secure cookie.
> 
> > > 2. maybe we could take hypervisor-independent process (e.g. SGT<->page)
> > > out of xen-zcopy and put those in a new helper library.
> > I believe this can be done, but at the first stage I would go without
> > that helper library, so it is clearly seen what can be moved to it later
> > (I know that you want to run ACRN as well, but can I run it on ARM? ;)
> 
> There's already helpers for walking sgtables and adding pages/enumerating
> pages. I don't think we need more.

ok, where would that helpers be located? If we consider we will use these
with other hypervisor drivers, maybe it's better to place those in some
common area?

> 
> > > 3. please consider the case where original DMA-BUF's first offset
> > > and last length are not 0 and PAGE_SIZE respectively. I assume current
> > > xen-zcopy only supports page-aligned buffer with PAGE_SIZE x n big.
> > Hm, what is the use-case for that?

Just in general use-case.. I was just considering the case (might be corner
case..) where sg->offset != 0 or sg->length != PAGE_SIZE. Hyper dmabuf sends
this information (first offset and last length) together with references for
pages. So I was wondering if we should so similar thing in zcopy since your
goal is now to cover general dma-buf use-cases (however, danvet mentioned
hard constaint of dma-buf below.. so if this can't happen according to the
spec, then we can ignore it..)

> 
> dma-buf is always page-aligned. That's a hard constraint of the linux
> dma-buf interface spec.
> -Daniel

Hmm.. I am little bit confused..
So does it mean dmabuf->size is always 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  82fed8530d8832a9a7b99554dfc49b041351785a
baseline version:
 xen  5a5c368faf45ced8a8c6235f4fbf5cdb38ec939f

Last test of basis   122412  2018-04-25 13:00:34 Z0 days
Testing same since   122416  2018-04-25 15:03:27 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  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 :

To xenbits.xen.org:/home/xen/git/xen.git
   5a5c368faf..82fed8530d  82fed8530d8832a9a7b99554dfc49b041351785a -> smoke

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

Re: [Xen-devel] [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]

[Juergen Gross]

On 25/04/18 17:58, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support 
> matrix generation [and 4 more messages]"):
>> Thanks everyone.  I have pushed this to staging-4.10, including the
>> patch 10/9.
> 
> The first cut of the cron job is now running.  So far it is only
> running off staging, and the output is here:
> 
>   http://xenbits.xen.org/docs/unstable-staging/support-matrix.html
> 
> It's labelled DRAFT because it's from staging, not because it's
> hand-edited or anything.
> 
> When we get pushes of all the relevant branches to the corresponding
> stable branches, I think the non-DRAFT version is ready to go.
> 
> Ian.
> 

The links to the 4.10 SUPPORT.html aren't working:

https://xenbits.xen.org/docs/4.10-testing/SUPPORT.html


Juergen

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

Re: [Xen-devel] [PATCH] docs/support-matrix-generate: use `git log' not `git-log'

[Juergen Gross]

On 25/04/18 17:56, Ian Jackson wrote:
> I found this bug when trying to set up the cron job.
> 
> Signed-off-by: Ian Jackson 

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]

[Ian Jackson]

Ian Jackson writes ("Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support 
matrix generation [and 4 more messages]"):
> Thanks everyone.  I have pushed this to staging-4.10, including the
> patch 10/9.

The first cut of the cron job is now running.  So far it is only
running off staging, and the output is here:

  http://xenbits.xen.org/docs/unstable-staging/support-matrix.html

It's labelled DRAFT because it's from staging, not because it's
hand-edited or anything.

When we get pushes of all the relevant branches to the corresponding
stable branches, I think the non-DRAFT version is ready to go.

Ian.

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

Re: [Xen-devel] 4.11.0 RC1 panic

[Manuel Bouyer]

On Wed, Apr 25, 2018 at 09:28:03AM -0600, Jan Beulich wrote:
> >>> On 25.04.18 at 16:42,  wrote:
> > On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
> >> > Without line numbers associated with at least the top stack trace entry
> >> > I can only guess what it might be - could you give the patch below a try?
> >> > (This may not be the final patch, as I'm afraid there may be some race
> >> > here, but I'd have to work this out later.)
> >> 
> >> Yes, this works. thanks !
> >> I'll now put this version on the NetBSD testbed I'm running.
> >> This should put some pressure on it.
> > 
> > Running NetBSD tests in several guests I got:
> > (XEN) 
> > (XEN) 
> > (XEN) Panic on CPU 1:
> > (XEN) Assertion 'oc > 0' failed at mm.c:628
> > (XEN) 
> > (see attached file for complete report).
> 
> Do you know what exactly the guest was doing at that time?

Unfortunably no. It was running the NetBSD test benchs, but as this
is automated I don't even know what version of NetBSD was running
in the guests.
BTW there doesn't seem to be a domain number in the panic message ...

> IOW do
> you have any information on how to repro (preferably without having
> to run NetBSD)?

Unfortunably no, and it's not reliably reproductible either.
A cron job starts running the tests for available builds daily,
and the panic occurs once in a while.

You may be able to reproduce it with a linux dom0:
install anita from http://www.gson.org/netbsd/anita/download/
this is a set of python script; so you should be able to
extract the tar.gz and run the anita script in there.

Then run:
./anita --test-timeout 14400 --vmm xl --vmm-args vcpus=4 --disk-size 2G 
--memory-size 256M test 
http://ftp.fr.netbsd.org/pub/NetBSD-daily/HEAD/201804210730Z/amd64/
you will have to adjust the URLs: these are daily builds, and older versions
are deleted when newer ones are build. You can also use other branches
instead of HEAD.

Eventually Xen will panic (but only once in a while).


> Did these failures start occurring recently (your
> mention of 4.8 seems to suggest otherwise)?

Looking at the server's log, the first time I've seen them was with
Xen 4.6.6, with patches up to XSA244. Before that it was running 4.6.5
with patch for XSA-212. It looks like the ASSERT() was added as part of
XSA240.

Then I upgraded to Xen 4.8.x (also with the security patches) but this
didn't fix the problem. I still had it with 4.8.3, and now with 4.11 too
(I didn't try anything else between 4.8 and 4.11)

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

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

[Xen-devel] [PATCH] docs/support-matrix-generate: use `git log' not `git-log'

[Ian Jackson]

I found this bug when trying to set up the cron job.

Signed-off-by: Ian Jackson 
---
 docs/support-matrix-generate | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/support-matrix-generate b/docs/support-matrix-generate
index b5ce3f4..a3d9332 100755
--- a/docs/support-matrix-generate
+++ b/docs/support-matrix-generate
@@ -139,7 +139,7 @@ END
 # find previous version
 search_commit="$current_ref"
 while true; do
-search_commit=$(git-log --pretty=format:%H -n1 \
+search_commit=$(git log --pretty=format:%H -n1 \
 -G 'XEN.*VERSION' $search_commit -- $versionfile)
 if ! [ "$search_commit" ]; then search_version=''; break; fi
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 0/2] Add Designated Reviewer (R:) to MAINTAINERS (plus a test case)

[Wei Liu]

On Tue, Apr 24, 2018 at 04:56:21PM +0100, Lars Kurth wrote:
> This follows up from a conversation after the April x86 community call, in 
> which I had
> the following action: Lars to propose fixing CC issue in xen.git:MAINTAINERS 
> copying 
> the R section entries from Linux.git:MAINTAINERS (will need changes to 
> get_maintainers.pl also)
> 
> Lars Kurth (2):
>   Add Designated Reviewer (R:) to MAINTAINERS file and add support for
> it in get_maintainer.pl
>   Add Brian Woods as Designated reviewer to AMD IOMMU and AMD SVM

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11

[Jan Beulich]

>>> On 25.04.18 at 17:26,  wrote:
> Juergen Gross writes ("[PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11"):
>> Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
>> order to produce an easier to read support HTML table.
> 
> Reviwed-by: Ian Jackson 
> 
> An example of the resulting output is here:
>   https://xenbits.xen.org/people/iwj/2018/support-matrix-example-D/t.html 
> 
> Jan, are you happy for this to go into 4.10 now ?

Yes.

Jan



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

Re: [Xen-devel] 4.11.0 RC1 panic

[Jan Beulich]

>>> On 25.04.18 at 16:42,  wrote:
> On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
>> > Without line numbers associated with at least the top stack trace entry
>> > I can only guess what it might be - could you give the patch below a try?
>> > (This may not be the final patch, as I'm afraid there may be some race
>> > here, but I'd have to work this out later.)
>> 
>> Yes, this works. thanks !
>> I'll now put this version on the NetBSD testbed I'm running.
>> This should put some pressure on it.
> 
> Running NetBSD tests in several guests I got:
> (XEN) 
> (XEN) 
> (XEN) Panic on CPU 1:
> (XEN) Assertion 'oc > 0' failed at mm.c:628
> (XEN) 
> (see attached file for complete report).

Do you know what exactly the guest was doing at that time? IOW do
you have any information on how to repro (preferably without having
to run NetBSD)? Did these failures start occurring recently (your
mention of 4.8 seems to suggest otherwise)?

Jan



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

Re: [Xen-devel] [PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11

[Ian Jackson]

Juergen Gross writes ("[PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11"):
> Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
> order to produce an easier to read support HTML table.

Reviwed-by: Ian Jackson 

An example of the resulting output is here:
  https://xenbits.xen.org/people/iwj/2018/support-matrix-example-D/t.html

Jan, are you happy for this to go into 4.10 now ?

Ian.

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

[Xen-devel] [PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11

[Juergen Gross]

Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
order to produce an easier to read support HTML table.

Signed-off-by: Juergen Gross 
---
 SUPPORT.md | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index f85dda8933..96002ea661 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -78,9 +78,9 @@ Fully virtualised guest using hardware virtualisation 
extensions
 
 Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
-Status: Supported
+Status, domU: Supported
 
-### x86/PVH guest
+### x86/PVH
 
 PVH is a next-generation paravirtualized mode
 designed to take advantage of hardware virtualization support when possible.
@@ -88,9 +88,9 @@ During development this was sometimes called HVMLite or PVHv2.
 
 Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
-Status: Supported
+Status, domU: Supported
 
-### ARM guest
+### ARM
 
 ARM only has one guest type at the moment
 
-- 
2.13.6


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

Re: [Xen-devel] [PATCH v2 10/10] xen/arm: Call check_local_cpu_errata for secondary CPU only on boot

[Mirela Simonovic]

Hi Julien,

On Mon, Apr 23, 2018 at 1:46 PM, Julien Grall  wrote:
> Hi,
>
> On 20/04/18 13:25, Mirela Simonovic wrote:
>>
>> Checking CPU errata should be done only when a CPU is initially booted.
>> It is assumed that the CPU which is hotplugged after the system/Xen boots,
>> was initially hotplugged during the system/Xen boot, so errata is checked
>> by each CPU only once, on boot.
>
>
> It is a good idea to document the assumption in the code. This will help to
> know what is missing for other use case.
>
>>
>> Signed-off-by: Mirela Simonovic 
>>
>> ---
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>> ---
>>   xen/arch/arm/smpboot.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
>> index d01b51592d..5d6c6cadec 100644
>> --- a/xen/arch/arm/smpboot.c
>> +++ b/xen/arch/arm/smpboot.c
>> @@ -366,8 +366,8 @@ void start_secondary(unsigned long boot_phys_offset,
>> if ( system_state != SYS_STATE_boot )
>>   setup_virt_paging_secondary();
>> -
>> -check_local_cpu_errata();
>> +else
>> +check_local_cpu_errata();
>
>
> No, check_local_cpu_errata should be called for everyone. This check should

Could you please clarify what you meant with "for everyone"? My
understanding is that you suggested this in
https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00979.html
Did something change meanwhile?

> be moved in the function with a TODO explaining what needs to be done.
> Likely this will be go over the CPU errata and see if there are any issue
> with the one currently selected.

Please clarify, I don't follow this.

>
> Also, I just realized that any "cpu capability" (e.g spectre workaround)
> that requires to be enabled will not be done on hotplugged CPU. You likely
> need to implement a version of enable_errata_workaround for them.
>

Could you please point me to a place where this is done on boot?

Thanks,
Mirela

> Cheers,
>
>
>> printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id());
>>
>
>
> --
> Julien Grall

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

Re: [Xen-devel] [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]

[Ian Jackson]

Ian Jackson writes ("[PATCH for-4.10 0/9] SUPPORT.md backports to support 
matrix generation"):
> This is a backport of my two recent series to fix bugs in SUPPORT.md,
> format it as part of the published docs, and use relative position of
> the `Status' stanza compared to descriptive text to indicate whether
> the text is a caveat that deserves a footnote.

Thanks everyone.  I have pushed this to staging-4.10, including the
patch 10/9.

Ian.

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

[Xen-devel] [xen-4.9-testing test] 122386: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken
 build-armhf   4 host-install(4)broken REGR. vs. 121761

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 4 host-install(4) broken pass in 
122355
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken pass in 
122355
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 122355 
pass in 122386
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 122355 
pass in 122386
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 122355
 test-amd64-i386-xl-qemut-ws16-amd64 14 guest-localmigrate  fail pass in 122355

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   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-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 122355 
like 121728
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 122355 like 
121761
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 122355 
like 121761
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop   fail in 122355 like 121761
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 122355 
like 121761
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 122355 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 122355 never 
pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 122355 never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 122355 never 
pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 122355 never 
pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 122355 
never pass
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 122355 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 122355 never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 122355 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 122355 
never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 122355 never pass
 test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 122355 never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 122355 never 
pass
 test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 122355 never 
pass
 test-armhf-armhf-xl 13 migrate-support-check fail in 122355 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 122355 never pass
 test-armhf-armhf-libvirt13 migrate-support-check fail in 122355 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 122355 never pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 122355 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 122355 never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 121704
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 121704
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 121728
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 121761
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 121761
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 121761
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 121761
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   

Re: [Xen-devel] [PATCH 8/9] SUPPORT.md: Move descriptions up before Status info

[George Dunlap]

> On Apr 25, 2018, at 2:00 PM, Ian Jackson  wrote:
> 
> This turns all the things which were treated as caveats, but which
> don't need to be footnoted in the matrix, into descriptions.
> 
> For the benefit of the support matrix generator, this patch (or a
> version of it) should be backported to 4.10.
> 
> Signed-off-by: Ian Jackson 
> Release-acked-by: Juergen Gross 
> (cherry picked from commit 67b46e14cb943e27134e9c6d7b41b27bdd8c6ae9)
> 
> Merge conflicts resolved:
>  - x86/HVM: 4.11 talks about "Status, domU"
>  - x86/PVH: 4.11 mentions domO so heading is different too
>  - ARM: Heading in 4.11 says just "ARM", in 4.10 "ARM guest”

Reviewed-by: George Dunlap 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  5a5c368faf45ced8a8c6235f4fbf5cdb38ec939f
baseline version:
 xen  27170adb54a558e11defcd51989326a9beb95afe

Last test of basis   122392  2018-04-24 13:00:34 Z1 days
Testing same since   122412  2018-04-25 13:00:34 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Ian Jackson 
  Jan Beulich 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  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 :

To xenbits.xen.org:/home/xen/git/xen.git
   27170adb54..5a5c368faf  5a5c368faf45ced8a8c6235f4fbf5cdb38ec939f -> smoke

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

Re: [Xen-devel] 4.11.0 RC1 panic

[Manuel Bouyer]

On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
> > Without line numbers associated with at least the top stack trace entry
> > I can only guess what it might be - could you give the patch below a try?
> > (This may not be the final patch, as I'm afraid there may be some race
> > here, but I'd have to work this out later.)
> 
> Yes, this works. thanks !
> I'll now put this version on the NetBSD testbed I'm running.
> This should put some pressure on it.

Running NetBSD tests in several guests I got:
(XEN) 
(XEN) 
(XEN) Panic on CPU 1:
(XEN) Assertion 'oc > 0' failed at mm.c:628
(XEN) 
(see attached file for complete report).

I got similar panics on Xen 4.8 after patching for meltdown 
(XSA-254).
I'll try the patch from XSA-259

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--
(XEN) Assertion 'oc > 0' failed at mm.c:628
(XEN) [ Xen-4.11-rcnb0  x86_64  debug=y   Not tainted ]
(XEN) CPU:1
(XEN) RIP:e008:[] mm.c#dec_linear_entries+0x12/0x20
(XEN) RFLAGS: 00010246   CONTEXT: hypervisor (d14v3)
(XEN) rax:    rbx: 4401   rcx: 00189b0d
(XEN) rdx: 0400   rsi: 0008   rdi: 82e0031349c0
(XEN) rbp: 82e0031361a0   rsp: 8301bf15fc08   r8:  
(XEN) r9:  0200   r10:    r11: 
(XEN) r12: 82e0031349c0   r13:    r14: 10ff
(XEN) r15: 1000   cr0: 80050033   cr4: 26e4
(XEN) cr3: 0001b98de000   cr2: cd9ffe80
(XEN) fsb: c0e02000   gsb:    gss: 
(XEN) ds: 0011   es: 0011   fs: 0031   gs: 0011   ss:    cs: e008
(XEN) Xen code around  (mm.c#dec_linear_entries+0x12/0x20):
(XEN)  c1 47 1e 66 85 c0 7f 02 <0f> 0b c3 66 66 2e 0f 1f 84 00 00 00 00 00 41 54
(XEN) Xen stack trace from rsp=8301bf15fc08:
(XEN)82d080288e3e 00800063 8301bf15 4c02
(XEN)82e0031361a0 82e0031349c0 8301b970e000 0001
(XEN)82004000b000 0200 82d08028945f 01fd
(XEN)82e0031349c0 82d080288869 00189a4e 
(XEN)8301bf15 4401 82e0031349c0 
(XEN)00ff 10ff 1000 82d080288e07
(XEN)000101000206 8301bf15 4402 00189a4e
(XEN)82e0031349c0  8301b970e000 82008000c000
(XEN) 82d08028949f 82d0802906cd 8300bf9be000
(XEN)0001802a7eb2 8301b970e000  8301b970e000
(XEN)0007 8300bf9be000 7ff0 
(XEN)8301b970e000 82e0031ab060 82d0804b0058 82d0804b0060
(XEN)0018d583 0018d583 0004 00189a4e
(XEN)cd9c9ce4 82008000c018 0001 cd9c9af4
(XEN)82d080386b30 0001 8301bf15 82d080295190
(XEN)8301bf15fe14 0001 82008000c000 
(XEN)7ff0 00048036b1d8 cd7cc0189a4e 8301bf15fef8
(XEN)8300bf9be000 01a0 deadf00d 0004
(XEN)deadf00d 82d0803672fa 82d07ff0 82d0
(XEN)82d1 82d0cd9c9ae8 82d08036b1e4 82d08036b1d8
(XEN) Xen call trace:
(XEN)[] mm.c#dec_linear_entries+0x12/0x20
(XEN)[] mm.c#_put_page_type+0x13e/0x340
(XEN)[] mm.c#put_page_from_l2e+0xdf/0x110
(XEN)[] free_page_type+0x2f9/0x790
(XEN)[] mm.c#_put_page_type+0x107/0x340
(XEN)[] put_page_type_preemptible+0xf/0x10
(XEN)[] do_mmuext_op+0x73d/0x1810
(XEN)[] compat_mmuext_op+0x430/0x450
(XEN)[] pv_hypercall+0x3aa/0x430
(XEN)[] entry_int82+0x74/0xc0
(XEN)[] entry_int82+0x68/0xc0
(XEN)[] entry_int82+0x74/0xc0
(XEN)[] entry_int82+0x68/0xc0
(XEN)[] entry_int82+0x74/0xc0
(XEN)[] entry_int82+0x68/0xc0
(XEN)[] entry_int82+0x74/0xc0
(XEN)[] do_entry_int82+0x1e/0x20
(XEN)[] entry_int82+0xb1/0xc0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged

[Mirela Simonovic]

Hi Julien,


On Wed, Apr 25, 2018 at 3:23 PM, Julien Grall  wrote:
> Hi,
>
>
> On 25/04/18 14:09, Mirela Simonovic wrote:
>>
>> On Mon, Apr 23, 2018 at 1:33 PM, Julien Grall 
>> wrote:
>>>
>>> Hi Mirela,
>>>
>>>
>>> On 20/04/18 13:25, Mirela Simonovic wrote:


 When a CPU is hot-unplugged the maintenance interrupt has to be
 released in order to free the memory that was allocated when the CPU
 was hotplugged and interrupt requested. The interrupt was requested
 using request_irq() which is called from start_secondary->
 init_maintenance_interrupt.

 Signed-off-by: Mirela Simonovic 

 ---
 CC: Stefano Stabellini 
 CC: Julien Grall 
 ---
xen/arch/arm/gic.c| 5 +
xen/arch/arm/smpboot.c| 7 +++
xen/include/asm-arm/gic.h | 1 +
3 files changed, 13 insertions(+)

 diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
 index 653a815127..e536b99e84 100644
 --- a/xen/arch/arm/gic.c
 +++ b/xen/arch/arm/gic.c
 @@ -431,6 +431,11 @@ void init_maintenance_interrupt(void)
"irq-maintenance", NULL);
}
+void deinit_maintenance_interrupt(void)
 +{
 +release_irq(gic_hw_ops->info->maintenance_irq, NULL);
 +}
 +
int gic_make_hwdom_dt_node(const struct domain *d,
   const struct dt_device_node *gic,
   void *fdt)
 diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
 index abc642804f..449fefc77d 100644
 --- a/xen/arch/arm/smpboot.c
 +++ b/xen/arch/arm/smpboot.c
 @@ -375,11 +375,18 @@ void __cpu_disable(void)
  local_irq_disable();
gic_disable_cpu();
 +
>>>
>>>
>>>
>>> Spurious change.
>>>
/* Allow any queued timer interrupts to get serviced */
local_irq_enable();
mdelay(1);
local_irq_disable();
+/*
 + * Deinitialize interrupts (this will free the memory that was
 allocated
 + * in respective init interrupt functions called from
 start_secondary)
 + */
 +deinit_maintenance_interrupt();
>>>
>>>
>>>
>>> Can you have a look at using a notifier (see CPU_DIYING)? This would
>>> avoid
>>> exporting too much new function.
>>
>>
>> I believe releasing of maintenance irq should happen after the dying
>> CPU's GIC interface is disabled.
>
>
> Why? The maintenance interrupt will only be fired when running in guest
> context. Furthermore, it is initialized after the GIC has been initialized,
> so it makes sense to disable before hand.
>
>> To make such ordering using notifiers I would need to move these lines
>> from __cpu_disable into the notifier callback under the CPU_DYING
>> case:
>>  local_irq_disable();
>>  gic_disable_cpu();
>>  local_irq_enable();
>
>
> This looks a bit weird. AFAIU, if you disable the CPU interface, then you
> should never receive interrupt after. So why would you re-enable them?
>
> I realize the code in __cpu_disbale do that, but this looks quite wrong to
> me. There are no way to receive queued timer interrupt afterwards.
>

That is what I took as a reference, but I asked myself the same.
There is (extremely small, but it exists) time window between
disabling irq locally and disabling CPU interface. An interrupt
received in that time window would propagate to the CPU but I'm not
sure would happen after the GIC CPU interface is disabled and
interrupts are locally enabled. That is the only explanation I can
come up with, although I believe the answer is nothing. Since you're
at ARM you could check this internally.

Anyway, since we're taking the notifier approach the timer interrupt
would be disabled before the GIC CPU interface, so I believe the
mdelay and the surrounding local_irq_enable/disable will not be
needed.
Please lets do such a cleanup out of this series.

>> then below these lines in the callback I would add
>>  release_irq(gic_hw_ops->info->maintenance_irq, NULL);
>>
>> This would have to be done because CPU_DYING notifiers execute before
>> __cpu_disable().
>> How that sounds? If it's ok, should these changes be split into 2
>> patches (1) notifier based call to gic_disable_cpu + 2) release
>> maintenance irq, I believe this is better) or should I merge them?
>
> I am not sure this is right to do. We want to disable the CPU interface very
> late (imagine we need to service interrupt).
>

This doesn't mean that the gic_disable_cpu can't be done using
notifiers, we would just first disable maintenance irq and then gic
cpu interface.
However, moving gic_disable_cpu in notifier would mean that interrupts
should be disabled using notifiers (whose priority is higher than gic
notifier's priority) as well.
Please lets finalize the discussion and make 

Re: [Xen-devel] [PATCH-for-4.10] adapt SUPPORT.md to match 4.11

[Juergen Gross]

On 25/04/18 16:09, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH-for-4.10] adapt SUPPORT.md to match 4.11"):
>> Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
>> order to produce an easier to read support HTML table.
> 
> This does not seem to appply on top of my own 4.10 series.

Oh, my bad. I built it on top of staging-4.10.

I'll resend as soon as your series has been applied.


Juergen

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

Re: [Xen-devel] [PATCH-for-4.10] adapt SUPPORT.md to match 4.11

[Ian Jackson]

Juergen Gross writes ("[PATCH-for-4.10] adapt SUPPORT.md to match 4.11"):
> Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
> order to produce an easier to read support HTML table.

This does not seem to appply on top of my own 4.10 series.

Ian.

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

Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series 
"C")"):
> Aah, so on ARM we have no dom0 support?

No, that is a mistake.

Ian.

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

[Xen-devel] [PATCH-for-4.10] adapt SUPPORT.md to match 4.11

[Juergen Gross]

Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
order to produce an easier to read support HTML table.

Signed-off-by: Juergen Gross 
---
 SUPPORT.md | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index cb862b538d..2b0d58feb3 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -74,15 +74,15 @@ No hardware requirements
 
 ### x86/HVM
 
-Status: Supported
+Status, domU: Supported
 
 Fully virtualised guest using hardware virtualisation extensions
 
 Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
-### x86/PVH guest
+### x86/PVH
 
-Status: Supported
+Status, domU: Supported
 
 PVH is a next-generation paravirtualized mode
 designed to take advantage of hardware virtualization support when possible.
@@ -90,7 +90,7 @@ During development this was sometimes called HVMLite or PVHv2.
 
 Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
-### ARM guest
+### ARM
 
 Status: Supported
 
-- 
2.13.6


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

Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Juergen Gross]

On 25/04/18 15:54, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes 
> (series "C")"):
>> On 25/04/18 15:43, George Dunlap wrote:
>>> 2. Backport all renames / reorganizations to all supported versions
>>
>> +1
>>
>> As this will only be more specific it is a win. Again above example:
>> How would you read the 4.10 PVH support? Is dom0 supported? Its a guest
>> after all...
> 
> I think "guest" excludes dom0.  dom0 is a domain but not a guest.

Aah, so on ARM we have no dom0 support?


Juergen


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

Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series 
"C")"):
> On 25/04/18 15:43, George Dunlap wrote:
> > 2. Backport all renames / reorganizations to all supported versions
> 
> +1
> 
> As this will only be more specific it is a win. Again above example:
> How would you read the 4.10 PVH support? Is dom0 supported? Its a guest
> after all...

I think "guest" excludes dom0.  dom0 is a domain but not a guest.

Ian.

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

Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

Ian Jackson writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series 
"C")"):
> George Dunlap writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes 
> (series "C")"):
> > 2. Backport all renames / reorganizations to all supported versions
...
> > I was initially opposed to #2, but I think the idea is growing on
> > me.  It does mean SUPPORT.md may end up being reorganized or renamed
> > in point releases, however.  It’s a bit hard for me to tell how
> > disruptive that would be.
...
> If someone wants to send a patch (on top of my backport series,
> please) that renames "PVH guest" to "PVH" in 4.10, and changes
> "Status:" to "Status, domU:", to match 4.11 that would be fine by me.

Oh, and, if we contemplate doing #2 occasionally then we should ask
people to not send mixed patches which do both
(i) renaming/reorganising features (ii) changing the support status.

Ian.

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

Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

George Dunlap writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series 
"C")"):
> Right, so there are four options:
> 
> 1. Never rename / reorganize SUPPORT.md categories

This is clearly unworkable.

> 3. Introduce some sort of “mapping” of options so that the table
> generator can correctly construct rows

I think this would be quite annoying.  It would have to be maintained
separately, probably in the branch for the next version.  It would
also make the table generator more complicated and it's quite bad
enough already.

> 2. Backport all renames / reorganizations to all supported versions
> 4. Tolerate duplicate rows for renamed / reorganized features

So it has to be one of these.  IMO either of these is fine.

> I was initially opposed to #2, but I think the idea is growing on
> me.  It does mean SUPPORT.md may end up being reorganized or renamed
> in point releases, however.  It’s a bit hard for me to tell how
> disruptive that would be.

We don't have to make this decision the same way for every feature.

If someone wants to send a patch (on top of my backport series,
please) that renames "PVH guest" to "PVH" in 4.10, and changes
"Status:" to "Status, domU:", to match 4.11 that would be fine by me.

Ian.

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

Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Juergen Gross]

On 25/04/18 15:43, George Dunlap wrote:
> 
> 
>> On Apr 25, 2018, at 2:32 PM, Juergen Gross  wrote:
>>
>> On 25/04/18 15:21, Ian Jackson wrote:
>>> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes 
>>> (series "C")"):
 Not related to these patches, but:

 SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
 want to change those? This might result in a more readable table.

 e.g.:

 4.10: ### x86/PVH guest
  Status: Supported

 4.11: ### x86/PVH
  Status, domU: Supported
  Status, dom0: Experimental
>>>
>>> Indeed.  I noticed this when I was backporting my reformatting.
>>> I considered changing this but I think TBH that this slight deviation
>>> in naming is going to occur occasionally.
>>
>> The resulting table is rather hard to read, don't you think?
>>
>> Especially the supported guest types are difficult to compare between
>> 4.10 and 4.11.
> 
> Right, so there are four options:
> 
> 1. Never rename / reorganize SUPPORT.md categories

As we can see in the example above this won't work very well.

> 2. Backport all renames / reorganizations to all supported versions

+1

As this will only be more specific it is a win. Again above example:
How would you read the 4.10 PVH support? Is dom0 supported? Its a guest
after all...

> 3. Introduce some sort of “mapping” of options so that the table generator 
> can correctly construct rows

Seems to be rather complex, e.g. in above example

> 4. Tolerate duplicate rows for renamed / reorganized features

This might grow rather ugly results after some more versions.


Juergen


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

Re: [Xen-devel] Should PV frontend drivers trust the backends?

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Juergen Gross
> Sent: 25 April 2018 13:43
> To: xen-devel 
> Subject: [Xen-devel] Should PV frontend drivers trust the backends?
> 
> This is a followup of a discussion on IRC:
> 
> The main question of the discussion was: "Should frontend drivers
> trust their backends not doing malicious actions?"
> 
> This IMO includes:
> 
> 1. The data put by the backend on the ring page(s) is sane and
>consistent, meaning that e.g. the response producer index is always
>ahead of the consumer index.
> 
> 2. Response data won't be modified by the backend after the producer
>index has been incremented signaling the response is valid.
> 
> 3. Response data is sane, e.g. an I/O data length is not larger than
>the buffer originally was.
> 
> 4. When a response has been sent all grants belonging to the request
>have been unmapped again by the backend, meaning that the frontend
>can assume the grants can be removed without conflict.
> 
> Today most frontend drivers (at least in the Linux kernel) seem to
> assume all of the above is true (there are some exceptions, but never
> for all items):
> 
> - they don't check sanity of ring index values
> - they don't copy response data into local memory before looking at it
> - they don't verify returned data length (or do so via BUG_ON())
> - they BUG() in case of a conflict when trying to remove a grant
> 
> So the basic question is: should all Linux frontend drivers be modified
> in order to be able to tolerate buggy or malicious backends? Or is the
> list of trust above fine?
> 
> IMO even in case the frontends do trust the backends to behave sane this
> doesn't mean driver domains don't make sense. Driver domains still make
> a Xen host more robust as they e.g. protect the host against driver
> failures normally leading to a crash of dom0.
> 

I see the general question as being analogous to 'should a Linux device driver 
trust its hardware' and I think the answer for a general purpose OS like linux 
is 'yes'.

Now, having worked on fault tolerant systems in a past life, there are 
definitely cases where you want your OS not to implicitly trust its peripheral 
hardware and hence special device drivers are used. I think the same would 
apply for virtual machines in situations where a driver domain is not wholly 
controlled by a host administrator or is not trusted to the same extent as dom0 
for other reasons; i.e. they should have specialist frontends.

  Paul

> 
> Juergen
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] xen/hvm: correct reporting of modified memory under physmap during migration

[Igor Druzhinin]

When global_log_dirty is enabled VRAM modification tracking never
worked correctly. The address that is passed to xen_hvm_modified_memory()
is not the effective PFN but RAM block address which is not the same
for VRAM.

We need to make a translation for this address into PFN using
physmap. Since there is no way to access physmap properly inside
xen_hvm_modified_memory() let's make it a global structure.

Signed-off-by: Igor Druzhinin 
---
 hw/i386/xen/xen-hvm.c | 37 +++--
 hw/i386/xen/xen-mapcache.c|  2 +-
 include/sysemu/xen-mapcache.h |  5 ++---
 3 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index cb85541..0cc0124 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -89,6 +89,8 @@ typedef struct XenPhysmap {
 QLIST_ENTRY(XenPhysmap) list;
 } XenPhysmap;
 
+static QLIST_HEAD(, XenPhysmap) xen_physmap;
+
 typedef struct XenIOState {
 ioservid_t ioservid;
 shared_iopage_t *shared_page;
@@ -109,7 +111,6 @@ typedef struct XenIOState {
 MemoryListener memory_listener;
 MemoryListener io_listener;
 DeviceListener device_listener;
-QLIST_HEAD(, XenPhysmap) physmap;
 hwaddr free_phys_offset;
 const XenPhysmap *log_for_dirtybit;
 
@@ -276,14 +277,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, 
MemoryRegion *mr,
 g_free(pfn_list);
 }
 
-static XenPhysmap *get_physmapping(XenIOState *state,
-   hwaddr start_addr, ram_addr_t size)
+static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size)
 {
 XenPhysmap *physmap = NULL;
 
 start_addr &= TARGET_PAGE_MASK;
 
-QLIST_FOREACH(physmap, >physmap, list) {
+QLIST_FOREACH(physmap, _physmap, list) {
 if (range_covers_byte(physmap->start_addr, physmap->size, start_addr)) 
{
 return physmap;
 }
@@ -291,23 +291,21 @@ static XenPhysmap *get_physmapping(XenIOState *state,
 return NULL;
 }
 
-#ifdef XEN_COMPAT_PHYSMAP
-static hwaddr xen_phys_offset_to_gaddr(hwaddr start_addr,
-   ram_addr_t size, void 
*opaque)
+static hwaddr xen_phys_offset_to_gaddr(hwaddr phys_offset, ram_addr_t size)
 {
-hwaddr addr = start_addr & TARGET_PAGE_MASK;
-XenIOState *xen_io_state = opaque;
+hwaddr addr = phys_offset & TARGET_PAGE_MASK;
 XenPhysmap *physmap = NULL;
 
-QLIST_FOREACH(physmap, _io_state->physmap, list) {
+QLIST_FOREACH(physmap, _physmap, list) {
 if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
-return physmap->start_addr;
+return physmap->start_addr + (phys_offset - physmap->phys_offset);
 }
 }
 
-return start_addr;
+return phys_offset;
 }
 
+#ifdef XEN_COMPAT_PHYSMAP
 static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap)
 {
 char path[80], value[17];
@@ -357,7 +355,7 @@ static int xen_add_to_physmap(XenIOState *state,
 hwaddr phys_offset = memory_region_get_ram_addr(mr);
 const char *mr_name;
 
-if (get_physmapping(state, start_addr, size)) {
+if (get_physmapping(start_addr, size)) {
 return 0;
 }
 if (size <= 0) {
@@ -386,7 +384,7 @@ go_physmap:
 physmap->name = mr_name;
 physmap->phys_offset = phys_offset;
 
-QLIST_INSERT_HEAD(>physmap, physmap, list);
+QLIST_INSERT_HEAD(_physmap, physmap, list);
 
 if (runstate_check(RUN_STATE_INMIGRATE)) {
 /* Now when we have a physmap entry we can replace a dummy mapping with
@@ -425,7 +423,7 @@ static int xen_remove_from_physmap(XenIOState *state,
 XenPhysmap *physmap = NULL;
 hwaddr phys_offset = 0;
 
-physmap = get_physmapping(state, start_addr, size);
+physmap = get_physmapping(start_addr, size);
 if (physmap == NULL) {
 return -1;
 }
@@ -593,7 +591,7 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
 int rc, i, j;
 const XenPhysmap *physmap = NULL;
 
-physmap = get_physmapping(state, start_addr, size);
+physmap = get_physmapping(start_addr, size);
 if (physmap == NULL) {
 /* not handled */
 return;
@@ -1219,7 +1217,7 @@ static void xen_read_physmap(XenIOState *state)
 xen_domid, entries[i]);
 physmap->name = xs_read(state->xenstore, 0, path, );
 
-QLIST_INSERT_HEAD(>physmap, physmap, list);
+QLIST_INSERT_HEAD(_physmap, physmap, list);
 }
 free(entries);
 }
@@ -1356,7 +1354,6 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
 
 state->memory_listener = xen_memory_listener;
-QLIST_INIT(>physmap);
 memory_listener_register(>memory_listener, _space_memory);
 state->log_for_dirtybit = NULL;
 
@@ -1372,6 +1369,8 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 goto err;
 }
   

Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[George Dunlap]

> On Apr 25, 2018, at 2:32 PM, Juergen Gross  wrote:
> 
> On 25/04/18 15:21, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes 
>> (series "C")"):
>>> Not related to these patches, but:
>>> 
>>> SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
>>> want to change those? This might result in a more readable table.
>>> 
>>> e.g.:
>>> 
>>> 4.10: ### x86/PVH guest
>>>  Status: Supported
>>> 
>>> 4.11: ### x86/PVH
>>>  Status, domU: Supported
>>>  Status, dom0: Experimental
>> 
>> Indeed.  I noticed this when I was backporting my reformatting.
>> I considered changing this but I think TBH that this slight deviation
>> in naming is going to occur occasionally.
> 
> The resulting table is rather hard to read, don't you think?
> 
> Especially the supported guest types are difficult to compare between
> 4.10 and 4.11.

Right, so there are four options:

1. Never rename / reorganize SUPPORT.md categories
2. Backport all renames / reorganizations to all supported versions
3. Introduce some sort of “mapping” of options so that the table generator can 
correctly construct rows
4. Tolerate duplicate rows for renamed / reorganized features

I was initially opposed to #2, but I think the idea is growing on me.  It does 
mean SUPPORT.md may end up being reorganized or renamed in point releases, 
however.  It’s a bit hard for me to tell how disruptive that would be.

 -George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Should PV frontend drivers trust the backends?

[Andrew Cooper]

On 25/04/18 13:42, Juergen Gross wrote:
> This is a followup of a discussion on IRC:
>
> The main question of the discussion was: "Should frontend drivers
> trust their backends not doing malicious actions?"
>
> This IMO includes:
>
> 1. The data put by the backend on the ring page(s) is sane and
>consistent, meaning that e.g. the response producer index is always
>ahead of the consumer index.
>
> 2. Response data won't be modified by the backend after the producer
>index has been incremented signaling the response is valid.
>
> 3. Response data is sane, e.g. an I/O data length is not larger than
>the buffer originally was.
>
> 4. When a response has been sent all grants belonging to the request
>have been unmapped again by the backend, meaning that the frontend
>can assume the grants can be removed without conflict.
>
> Today most frontend drivers (at least in the Linux kernel) seem to
> assume all of the above is true (there are some exceptions, but never
> for all items):
>
> - they don't check sanity of ring index values
> - they don't copy response data into local memory before looking at it
> - they don't verify returned data length (or do so via BUG_ON())
> - they BUG() in case of a conflict when trying to remove a grant
>
> So the basic question is: should all Linux frontend drivers be modified
> in order to be able to tolerate buggy or malicious backends? Or is the
> list of trust above fine?
>
> IMO even in case the frontends do trust the backends to behave sane this
> doesn't mean driver domains don't make sense. Driver domains still make
> a Xen host more robust as they e.g. protect the host against driver
> failures normally leading to a crash of dom0.

I think the issue here is that "trust" is actually two different thing here.

If we consider "the ring" as an opaque transport layer, then I expect
both sides to be resilient to a buggy/malicious other end.  I realise
this is not currently the case, but I think it should be reasonable to
hook either side up to AFL and not have the other side crash. 
(Declaring the other half insane and transitioning to closed is an
entirely reasonable action.)

When it comes to the data content served by "the opaque ring", then
trust is far more complicated thing.

If blkback is serving /, then the default case has little option but to
trust the other end.  This is clearly how the frontends have been developed.

However, non-default cases might include using an encrypted filesystem,
at which point the domU isn't in the position of having to trust the
driver domain serving its filesystem, and therefore shouldn't be forced
into trusting the backend simply because it doesn't protect itself
against pitfalls which inherently come from using shared memory interfaces.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.10 10/9] SUPPORT.md: Fix a typo

[Juergen Gross]

On 25/04/18 15:23, Ian Jackson wrote:
> Reported-by: Juergen Gross 
> Signed-off-by: Ian Jackson 

Reviewed-by: Juergen Gross 


Juergen


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

Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Juergen Gross]

On 25/04/18 15:21, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes 
> (series "C")"):
>> Not related to these patches, but:
>>
>> SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
>> want to change those? This might result in a more readable table.
>>
>> e.g.:
>>
>> 4.10: ### x86/PVH guest
>>   Status: Supported
>>
>> 4.11: ### x86/PVH
>>   Status, domU: Supported
>>   Status, dom0: Experimental
> 
> Indeed.  I noticed this when I was backporting my reformatting.
> I considered changing this but I think TBH that this slight deviation
> in naming is going to occur occasionally.

The resulting table is rather hard to read, don't you think?

Especially the supported guest types are difficult to compare between
4.10 and 4.11.


Juergen

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

[Xen-devel] [PATCH for-4.10 10/9] SUPPORT.md: Fix a typo

[Ian Jackson]

Reported-by: Juergen Gross 
Signed-off-by: Ian Jackson 
---
 SUPPORT.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 0d2db1f..f85dda8 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -653,7 +653,7 @@ See the section **Blkback** for image formats supported by 
QEMU.
 ### x86/Emulated graphics (QEMU):
 
 Status, cirrus-vga: Supported
-Status, stgvga: Supported
+Status, stdvga: Supported
 
 ### x86/Emulated audio (QEMU):
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged

[Julien Grall]

Hi,

On 25/04/18 14:09, Mirela Simonovic wrote:

On Mon, Apr 23, 2018 at 1:33 PM, Julien Grall  wrote:

Hi Mirela,


On 20/04/18 13:25, Mirela Simonovic wrote:


When a CPU is hot-unplugged the maintenance interrupt has to be
released in order to free the memory that was allocated when the CPU
was hotplugged and interrupt requested. The interrupt was requested
using request_irq() which is called from start_secondary->
init_maintenance_interrupt.

Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
   xen/arch/arm/gic.c| 5 +
   xen/arch/arm/smpboot.c| 7 +++
   xen/include/asm-arm/gic.h | 1 +
   3 files changed, 13 insertions(+)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 653a815127..e536b99e84 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -431,6 +431,11 @@ void init_maintenance_interrupt(void)
   "irq-maintenance", NULL);
   }
   +void deinit_maintenance_interrupt(void)
+{
+release_irq(gic_hw_ops->info->maintenance_irq, NULL);
+}
+
   int gic_make_hwdom_dt_node(const struct domain *d,
  const struct dt_device_node *gic,
  void *fdt)
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index abc642804f..449fefc77d 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -375,11 +375,18 @@ void __cpu_disable(void)
 local_irq_disable();
   gic_disable_cpu();
+



Spurious change.


   /* Allow any queued timer interrupts to get serviced */
   local_irq_enable();
   mdelay(1);
   local_irq_disable();
   +/*
+ * Deinitialize interrupts (this will free the memory that was
allocated
+ * in respective init interrupt functions called from
start_secondary)
+ */
+deinit_maintenance_interrupt();



Can you have a look at using a notifier (see CPU_DIYING)? This would avoid
exporting too much new function.


I believe releasing of maintenance irq should happen after the dying
CPU's GIC interface is disabled.


Why? The maintenance interrupt will only be fired when running in guest 
context. Furthermore, it is initialized after the GIC has been 
initialized, so it makes sense to disable before hand.



To make such ordering using notifiers I would need to move these lines
from __cpu_disable into the notifier callback under the CPU_DYING
case:
 local_irq_disable();
 gic_disable_cpu();
 local_irq_enable();


This looks a bit weird. AFAIU, if you disable the CPU interface, then 
you should never receive interrupt after. So why would you re-enable them?


I realize the code in __cpu_disbale do that, but this looks quite wrong 
to me. There are no way to receive queued timer interrupt afterwards.



then below these lines in the callback I would add
 release_irq(gic_hw_ops->info->maintenance_irq, NULL);

This would have to be done because CPU_DYING notifiers execute before
__cpu_disable().
How that sounds? If it's ok, should these changes be split into 2
patches (1) notifier based call to gic_disable_cpu + 2) release
maintenance irq, I believe this is better) or should I merge them?
I am not sure this is right to do. We want to disable the CPU interface 
very late (imagine we need to service interrupt).


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation

[Jan Beulich]

>>> On 25.04.18 at 14:59,  wrote:
> This is a backport of my two recent series to fix bugs in SUPPORT.md,
> format it as part of the published docs, and use relative position of
> the `Status' stanza compared to descriptive text to indicate whether
> the text is a caveat that deserves a footnote.
> 
> Most of this is uncontroversial and I have run the build and checked
> that the resulting index.html is good.
> 
> It would be good if someone could review particularly the way I
> resolved the conflicts in the big patch to SUPPORT.md, ie in
>   [PATCH 8/9] SUPPORT.md: Move descriptions up before Status info
> 
> The result for 4.10's
> SUPPORT.md is here:
>   
> https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/SUPPORT.html 
> 
> I have also checked that (with the patch I am about to send for
> staging's parse-support-md) that this generates a sensible-looking
> support matrix.  The resulting support matrix can be found here:
>   https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html 
> (The hyperlink references for staging are to the live xenbits version;
> the references for 4.10 are to the example output file mentioned above.)
> 
> I have squashed the fix to not depend on HTML::TreeBuilder::XPath into
> the patch that introduces the dependency.

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series 
"C")"):
> Not related to these patches, but:
> 
> SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
> want to change those? This might result in a more readable table.
> 
> e.g.:
> 
> 4.10: ### x86/PVH guest
>   Status: Supported
> 
> 4.11: ### x86/PVH
>   Status, domU: Supported
>   Status, dom0: Experimental

Indeed.  I noticed this when I was backporting my reformatting.
I considered changing this but I think TBH that this slight deviation
in naming is going to occur occasionally.

There's a paragraph about it in the intro and everything.

> 4.10: ### x86/Emulated graphics (QEMU):
>   Status, stgvga: Supported <- note the typo in "stgvga"
> 4.11: ### x86/Emulated graphics (QEMU):
>   Status, stdvga: Supported

This should be fixed.  I'll send a followup patch.

Ian.

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

[Xen-devel] [xen-4.8-testing test] 122385: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  broken  in 122354
 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 122161

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl  4 host-install(4) broken in 122354 pass in 122385
 test-armhf-armhf-xl-rtds 12 guest-start  fail in 122354 pass in 122385
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-saverestore   fail pass in 122354
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail pass in 122354

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail in 122354 like 122161
 test-xtf-amd64-amd64-2  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122132
 test-xtf-amd64-amd64-5  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122161
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122161
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 122161
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122161
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122161
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122161
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122161
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122161
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122161
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 

Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Juergen Gross]

On 25/04/18 15:04, Ian Jackson wrote:
> I was just testing the results of my backports of the SUPPORT.md
> series to 4.10 - just sent, under the Subject line:
> [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation
> 
> I found a bug in the support matrix generator.  Sadly the bug was not
> evident without the backported changes to SUPPORT.md.  These two
> patches fix this bug.
> 
> Example output can be found here:
>   https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html
> (The hyperlink references for staging are to the live xenbits version;
> the references for 4.10 are to the example SUPPORT.html output file
> from the 4.10 backport series, as discussed above.)
> 
> For my reference, this was made as follows:
>   docs/support-matrix-generate -D HEAD 
> https://xenbits.xen.org/docs/unstable-staging/SUPPORT.html 
> refs/heads/wip.support-stmt-NN-2 SUPPORT.html 2>&1 >docs/html/t.html |less
>   rsync -LvP docs/html/{t,SUPPORT}.html 
> xenbits:public_html/2018/support-matrix-example-C
> 
> Thanks,
> Ian.
> 

For the series:

Release-acked-by: Juergen Gross 


Not related to these patches, but:

SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
want to change those? This might result in a more readable table.

e.g.:

4.10: ### x86/PVH guest
  Status: Supported

4.11: ### x86/PVH
  Status, domU: Supported
  Status, dom0: Experimental

4.10: ### x86/Emulated graphics (QEMU):
  Status, stgvga: Supported <- note the typo in "stgvga"

4.11: ### x86/Emulated graphics (QEMU):
  Status, stdvga: Supported


Juergen

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

Re: [Xen-devel] [PATCH v2 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged

[Mirela Simonovic]

Hi Julien,

On Mon, Apr 23, 2018 at 1:33 PM, Julien Grall  wrote:
> Hi Mirela,
>
>
> On 20/04/18 13:25, Mirela Simonovic wrote:
>>
>> When a CPU is hot-unplugged the maintenance interrupt has to be
>> released in order to free the memory that was allocated when the CPU
>> was hotplugged and interrupt requested. The interrupt was requested
>> using request_irq() which is called from start_secondary->
>> init_maintenance_interrupt.
>>
>> Signed-off-by: Mirela Simonovic 
>>
>> ---
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>> ---
>>   xen/arch/arm/gic.c| 5 +
>>   xen/arch/arm/smpboot.c| 7 +++
>>   xen/include/asm-arm/gic.h | 1 +
>>   3 files changed, 13 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 653a815127..e536b99e84 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -431,6 +431,11 @@ void init_maintenance_interrupt(void)
>>   "irq-maintenance", NULL);
>>   }
>>   +void deinit_maintenance_interrupt(void)
>> +{
>> +release_irq(gic_hw_ops->info->maintenance_irq, NULL);
>> +}
>> +
>>   int gic_make_hwdom_dt_node(const struct domain *d,
>>  const struct dt_device_node *gic,
>>  void *fdt)
>> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
>> index abc642804f..449fefc77d 100644
>> --- a/xen/arch/arm/smpboot.c
>> +++ b/xen/arch/arm/smpboot.c
>> @@ -375,11 +375,18 @@ void __cpu_disable(void)
>> local_irq_disable();
>>   gic_disable_cpu();
>> +
>
>
> Spurious change.
>
>>   /* Allow any queued timer interrupts to get serviced */
>>   local_irq_enable();
>>   mdelay(1);
>>   local_irq_disable();
>>   +/*
>> + * Deinitialize interrupts (this will free the memory that was
>> allocated
>> + * in respective init interrupt functions called from
>> start_secondary)
>> + */
>> +deinit_maintenance_interrupt();
>
>
> Can you have a look at using a notifier (see CPU_DIYING)? This would avoid
> exporting too much new function.

I believe releasing of maintenance irq should happen after the dying
CPU's GIC interface is disabled.
To make such ordering using notifiers I would need to move these lines
from __cpu_disable into the notifier callback under the CPU_DYING
case:
local_irq_disable();
gic_disable_cpu();
local_irq_enable();
then below these lines in the callback I would add
release_irq(gic_hw_ops->info->maintenance_irq, NULL);

This would have to be done because CPU_DYING notifiers execute before
__cpu_disable().
How that sounds? If it's ok, should these changes be split into 2
patches (1) notifier based call to gic_disable_cpu + 2) release
maintenance irq, I believe this is better) or should I merge them?

Thanks,
Mirela

>
>> +
>>   /* It's now safe to remove this processor from the online map */
>>   cpumask_clear_cpu(cpu, _online_map);
>>   diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
>> index 58b910fe6a..0db42e6cce 100644
>> --- a/xen/include/asm-arm/gic.h
>> +++ b/xen/include/asm-arm/gic.h
>> @@ -254,6 +254,7 @@ extern void gic_clear_pending_irqs(struct vcpu *v);
>>   extern int vgic_vcpu_pending_irq(struct vcpu *v);
>> extern void init_maintenance_interrupt(void);
>> +extern void deinit_maintenance_interrupt(void);
>>   extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq,
>>   unsigned int priority);
>>   extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int
>> virtual_irq);
>>
>
> Cheers,
>
> --
> Julien Grall

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

[Xen-devel] [PATCH 1/2] docs/parse-support-md: Break out find_current_sectnode

[Ian Jackson]

We are going to want to add a call site for this.

No functional change.

Signed-off-by: Ian Jackson 
---
 docs/parse-support-md | 48 +++-
 1 file changed, 27 insertions(+), 21 deletions(-)

diff --git a/docs/parse-support-md b/docs/parse-support-md
index 218e12b..f0b4c25 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -67,6 +67,32 @@ our $had_feature;
 
 #-- parsing --
 
+sub find_current_sectnode () {
+die unless @insections;
+
+my $sectnode;
+my $realsect;
+foreach my $s (@insections) {
+my $sectlist = $sectnode
+? $sectnode->{Children} : $toplevel_sectlist;
+my $key = $s->{Key};
+$realsect = $s if $s->{Anchor};
+tie %$sectlist, 'Tie::IxHash' unless tied %$sectlist;
+#print STDERR "FIND_CURRENT_SECTNODE ", Dumper($s);
+$sectlist->{$key} //=
+{
+ Children => new_sectlist(),
+ Headline => $s->{Headline},
+ Key => $key,
+ RealSect => $realsect,
+ HasCaveat => [],
+};
+$sectnode = $sectlist->{$key};
+}
+die unless $sectnode;
+return $sectnode;
+}
+
 sub ri_Header {
 my ($c) = @_;
 my ($level, $infos, $hl) = @$c;
@@ -100,29 +126,9 @@ sub ri_Para {
 
 sub parse_feature_entry ($) {
 my ($value) = @_;
-die unless @insections;
 
 $had_feature = 1;
-
-my $sectnode;
-my $realsect;
-foreach my $s (@insections) {
-my $sectlist = $sectnode
-? $sectnode->{Children} : $toplevel_sectlist;
-my $key = $s->{Key};
-$realsect = $s if $s->{Anchor};
-tie %$sectlist, 'Tie::IxHash' unless tied %$sectlist;
-#print STDERR "PARSE_FEATURE_ENTRY ", Dumper($s);
-$sectlist->{$key} //=
-{
- Children => new_sectlist(),
- Headline => $s->{Headline},
- Key => $key,
- RealSect => $realsect,
-};
-$sectnode = $sectlist->{$key};
-}
-die unless $sectnode;
+my $sectnode = find_current_sectnode();
 $sectnode->{Status}[$version_index] = $value;
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

I was just testing the results of my backports of the SUPPORT.md
series to 4.10 - just sent, under the Subject line:
[PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation

I found a bug in the support matrix generator.  Sadly the bug was not
evident without the backported changes to SUPPORT.md.  These two
patches fix this bug.

Example output can be found here:
  https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html
(The hyperlink references for staging are to the live xenbits version;
the references for 4.10 are to the example SUPPORT.html output file
from the 4.10 backport series, as discussed above.)

For my reference, this was made as follows:
  docs/support-matrix-generate -D HEAD 
https://xenbits.xen.org/docs/unstable-staging/SUPPORT.html 
refs/heads/wip.support-stmt-NN-2 SUPPORT.html 2>&1 >docs/html/t.html |less
  rsync -LvP docs/html/{t,SUPPORT}.html 
xenbits:public_html/2018/support-matrix-example-C

Thanks,
Ian.

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

[Xen-devel] [PATCH 2/2] docs/parse-support-md: Do caveats properly (!)

[Ian Jackson]

Each document has its own objects in @insections.  Only the first
RealSect encountered ends up in the main $toplevel_sectlist tree.

This means that trying to unify the Caveats information for all
version in the RealSect (the $insection) does not work.  The caveats
for all versions that aren't the first one where this section was seen
end up in the @insections array during parsing of that version, but
not recorded in the main tree.

The result was that footnotes would only appear in the output for
versions which were the most recent version where that feature row or
category appeared.  The other footnotes would be lost.

Instead, store HasCaveat in the sectnode.  That means ri_Para needs to
find the sectnode.

Signed-off-by: Ian Jackson 
---
 docs/parse-support-md | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/docs/parse-support-md b/docs/parse-support-md
index f0b4c25..1c82f56 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -33,8 +33,8 @@ our $toplevel_sectlist = new_sectlist();
 # $sectlist->{KEY}{Status}[VI] = absent or markdown content
 # $sectlist->{KEY}{Children} = a further $sectlist
 # $sectlist->{KEY}{Key} = KEY
+# $sectlist->{KEY}{HasCaveat}[VI] = trueish iff other in a Para
 # $sectlist->{KEY}{RealSect} = containing real section in @insections, so
-# $sectlist->{KEY}{RealSect}{HasCaveat}[VI] = trueish iff other in a Para
 # $sectlist->{KEY}{RealSect}{HasDescription} = VI for some Emph in Para
 # $sectlist->{KEY}{RealSect}{Anchor} = value for < id="" > in the pandoc html
 # A $sectnode represents a single section from the original markdown
@@ -58,7 +58,6 @@ our @insections;
 # $insections[]{Headline} = markdown content
 # these next are only defined for real sections, not Status elements
 # $insections[]{Anchor} = string
-# $insections[]{HasCaveat} = array, $sectlist->{HasCaveat} will refer to this
 # $insections[]{HasDescription} VI, likewise
 
 our $had_unknown;
@@ -106,7 +105,6 @@ sub ri_Header {
  Key => $id,
  Anchor => $id,
  Headline => $hl,
- HasCaveat => [],
  HasDescription => undef,
 };
 #print STDERR Dumper(\@insections);
@@ -116,9 +114,12 @@ sub ri_Header {
 sub ri_Para {
 return unless @insections;
 my $insection = $insections[$#insections];
+#print STDERR "ri_Para $version_index $had_feature ".
+#$insection->{HasCaveat}." $insection->{Key}\n";
 
 if ($had_feature) {
-$insection->{HasCaveat}[$version_index] = 1;
+my $sectnode = find_current_sectnode();
+$sectnode->{HasCaveat}[$version_index] = 1;
 } else {
 $insection->{HasDescription} //= $version_index;
 }
@@ -397,7 +398,7 @@ sub write_output_row ($) {
 my $nextcell = '';
 if (!defined $colspan) { # first row of this RealSect
 $colspan= ' colspan="2"';
-if ($sectnode->{RealSect}{HasCaveat}[$i] && $st
+if ($sectnode->{HasCaveat}[$i] && $st
 && $sectnode->{RealSect}{Anchor}) {
 my $rows = $sectnode->{RealSect}{OwnRows};
 $nextcell = '

[Xen-devel] [PATCH v2] x86/cpu: Add supports for zhaoxin x86 platform

[Davidwang]

From: DavidWang 

Zhaoxin is a x86 IC designer. Its SOC products support both CPU
virtualization and I/O virtualization, which are compatible with Intel
VMX and VT-d respectively. Zhaoxin has 'Shanghai' CPU vendor ID.

Signed-off-by: DavidWang 
---
 xen/arch/x86/cpu/Makefile  |  1 +
 xen/arch/x86/cpu/common.c  |  1 +
 xen/arch/x86/cpu/intel_cacheinfo.c |  2 +-
 xen/arch/x86/cpu/shanghai.c| 90 ++
 xen/include/asm-x86/cpufeature.h   |  1 +
 xen/include/asm-x86/iommu.h|  2 +
 xen/include/asm-x86/setup.h|  1 +
 xen/include/asm-x86/x86-vendors.h  |  3 +-
 8 files changed, 99 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/x86/cpu/shanghai.c

diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index 74f23ae..34a01ca 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -7,4 +7,5 @@ obj-y += common.o
 obj-y += intel.o
 obj-y += intel_cacheinfo.o
 obj-y += mwait-idle.o
+obj-y += shanghai.o
 obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 0a452ae..02863c9 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -709,6 +709,7 @@ void __init early_cpu_init(void)
intel_cpu_init();
amd_init_cpu();
centaur_init_cpu();
+   shanghai_init_cpu();
early_cpu_detect();
 }
 
diff --git a/xen/arch/x86/cpu/intel_cacheinfo.c 
b/xen/arch/x86/cpu/intel_cacheinfo.c
index 101e297..a3aec13 100644
--- a/xen/arch/x86/cpu/intel_cacheinfo.c
+++ b/xen/arch/x86/cpu/intel_cacheinfo.c
@@ -103,7 +103,7 @@ int cpuid4_cache_lookup(int index, struct cpuid4_info 
*this_leaf)
return 0;
 }
 
-static int find_num_cache_leaves(void)
+int find_num_cache_leaves(void)
 {
unsigned inteax, ebx, ecx, edx;
union _cpuid4_leaf_eax  cache_eax;
diff --git a/xen/arch/x86/cpu/shanghai.c b/xen/arch/x86/cpu/shanghai.c
new file mode 100644
index 000..ac12ba3
--- /dev/null
+++ b/xen/arch/x86/cpu/shanghai.c
@@ -0,0 +1,90 @@
+#include 
+#include 
+#include 
+#include "cpu.h"
+
+void init_shanghai_cache(struct cpuinfo_x86 *c)
+{
+   unsigned int i = 0, l1d = 0, l1i = 0, l2 = 0, l3 = 0;
+struct cpuid4_info leaf;
+   static bool is_initialized = false;
+   static unsigned int cache_leaves = 0;
+
+   if ( (!is_initialized) && (c->cpuid_level > 0x0003) )
+{
+   /* Init cache_leaves from boot CPU */
+   cache_leaves = find_num_cache_leaves();
+   is_initialized = true;
+   }
+
+   /* Use cpuid:0x0004 to find the cache details */
+   for (i = 0; i < cache_leaves; i++)
+{
+   if( c->cpuid_level <= 0x0003 )
+   break;
+
+   if ( !cpuid4_cache_lookup(i, ) )
+{
+   switch( leaf.eax.split.level )
+   {
+   case 1:
+   if ( leaf.eax.split.type == 
CACHE_TYPE_DATA )
+   l1d = leaf.size/1024;
+   else if ( leaf.eax.split.type == 
CACHE_TYPE_INST )
+   l1i = leaf.size/1024;
+   break;
+   case 2:
+   l2 = leaf.size/1024;
+   break;
+   case 3:
+   l3 = leaf.size/1024;
+   break;
+   default:
+   break;
+   }
+   }
+   }
+
+   if ( opt_cpu_info )
+   {
+   if ( l1i )
+   printk("CPU: L1 I cache: %dK", l1i);
+
+   if ( l1d )
+   printk(", L1 D cache: %dK\n", l1d);
+   else
+   printk("\n");
+
+   if ( l2 )
+   printk("CPU: L2 cache: %dK\n", l2);
+
+   if ( l3 )
+   printk("CPU: L3 cache: %dK\n", l3);
+   }
+
+   c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i + l1d));
+}
+
+static void init_shanghai(struct cpuinfo_x86 *c)
+{
+   if ( cpu_has(c, X86_FEATURE_ITSC) )
+   {
+   __set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
+   __set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability);
+   __set_bit(X86_FEATURE_TSC_RELIABLE, c->x86_capability);
+   }
+
+   init_shanghai_cache(c);
+}
+
+static const struct cpu_dev shanghai_cpu_dev = {
+   .c_vendor   = "  Shang",
+   .c_ident= {"  Shanghai  "},
+   .c_init = init_shanghai,
+};
+
+int __init shanghai_init_cpu(void)
+{
+   cpu_devs[X86_VENDOR_SHANGHAI] = _cpu_dev;
+   return 0;
+}

[Xen-devel] [PATCH 8/9] SUPPORT.md: Move descriptions up before Status info

[Ian Jackson]

This turns all the things which were treated as caveats, but which
don't need to be footnoted in the matrix, into descriptions.

For the benefit of the support matrix generator, this patch (or a
version of it) should be backported to 4.10.

Signed-off-by: Ian Jackson 
Release-acked-by: Juergen Gross 
(cherry picked from commit 67b46e14cb943e27134e9c6d7b41b27bdd8c6ae9)

Merge conflicts resolved:
  - x86/HVM: 4.11 talks about "Status, domU"
  - x86/PVH: 4.11 mentions domO so heading is different too
  - ARM: Heading in 4.11 says just "ARM", in 4.10 "ARM guest"

Signed-off-by: Ian Jackson 
---
 SUPPORT.md | 211 -
 1 file changed, 110 insertions(+), 101 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 201e5a3..3429afb 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -58,44 +58,44 @@ for the definitions of the support status levels etc.
 
 ### ARM/GICv3 ITS
 
-Status: Experimental
-
 Extension to the GICv3 interrupt controller to support MSI.
 
+Status: Experimental
+
 ## Guest Type
 
 ### x86/PV
 
-Status: Supported
-
 Traditional Xen PV guest
 
 No hardware requirements
 
-### x86/HVM
-
 Status: Supported
 
+### x86/HVM
+
 Fully virtualised guest using hardware virtualisation extensions
 
 Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
-### x86/PVH guest
-
 Status: Supported
 
+### x86/PVH guest
+
 PVH is a next-generation paravirtualized mode
 designed to take advantage of hardware virtualization support when possible.
 During development this was sometimes called HVMLite or PVHv2.
 
 Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
-### ARM guest
-
 Status: Supported
 
+### ARM guest
+
 ARM only has one guest type at the moment
 
+Status: Supported
+
 ## Toolstack
 
 ### xl
@@ -104,12 +104,12 @@ ARM only has one guest type at the moment
 
 ### Direct-boot kernel image format
 
+Format which the toolstack accepts for direct-boot kernels
+
 Supported, x86: bzImage, ELF
 Supported, ARM32: zImage
 Supported, ARM64: Image
 
-Format which the toolstack accepts for direct-boot kernels
-
 ### Dom0 init support for xl
 
 Status, SysV: Supported
@@ -118,10 +118,10 @@ Format which the toolstack accepts for direct-boot kernels
 
 ### JSON output support for xl
 
-Status: Experimental
-
 Output of information in machine-parseable JSON format
 
+Status: Experimental
+
 ### Open vSwitch integration for xl
 
 Status, Linux: Supported
@@ -154,17 +154,18 @@ Output of information in machine-parseable JSON format
 
 ### Hypervisor 'debug keys'
 
-Status: Supported, not security supported
-
 These are functions triggered either from the host serial console,
 or via the xl 'debug-keys' command,
 which cause Xen to dump various hypervisor state to the console.
 
+Status: Supported, not security supported
+
 ### Hypervisor synchronous console output (sync_console)
 
+Xen command-line flag to force synchronous console output.
+
 Status: Supported, not security supported
 
-Xen command-line flag to force synchronous console output.
 Useful for debugging, but not suitable for production environments
 due to incurred overhead.
 
@@ -176,56 +177,54 @@ Debugger to debug ELF guests
 
 ### Soft-reset for PV guests
 
-Status: Supported
-
 Soft-reset allows a new kernel to start 'from scratch' with a fresh VM state,
 but with all the memory from the previous state of the VM intact.
 This is primarily designed to allow "crash kernels",
 which can do core dumps of memory to help with debugging in the event of a 
crash.
 
-### xentrace
+Status: Supported
 
-Status, x86: Supported
+### xentrace
 
 Tool to capture Xen trace buffer data
 
-### gcov
+Status, x86: Supported
 
-Status: Supported, Not security supported
+### gcov
 
 Export hypervisor coverage data suitable for analysis by gcov or lcov.
 
+Status: Supported, Not security supported
+
 ## Memory Management
 
 ### Dynamic memory control
 
-Status: Supported
-
 Allows a guest to add or remove memory after boot-time.
 This is typically done by a guest kernel agent known as a "balloon driver".
 
-### Populate-on-demand memory
+Status: Supported
 
-Status, x86 HVM: Supported
+### Populate-on-demand memory
 
 This is a mechanism that allows normal operating systems with only a balloon 
driver
 to boot with memory < maxmem.
 
-### Memory Sharing
+Status, x86 HVM: Supported
 
-Status, x86 HVM: Expermental
+### Memory Sharing
 
 Allow sharing of identical pages between guests
 
-### Memory Paging
+Status, x86 HVM: Expermental
 
-Status, x86 HVM: Experimenal
+### Memory Paging
 
 Allow pages belonging to guests to be paged to disk
 
-### Transcendent Memory
+Status, x86 HVM: Experimenal
 
-Status: Experimental
+### Transcendent Memory
 
 Transcendent Memory (tmem) allows the creation of hypervisor memory 

[Xen-devel] [PATCH 6/9] docs/Makefile: Introduce GENERATE_PANDOC_RULE_RAW

[Ian Jackson]

We are going to want to format SUPPORT.md which does not match the
filename patterns in docs/.  So provide a way to make an ad-hoc rule
using pandoc with the standard options.

No functional change in this patch.

Signed-off-by: Ian Jackson 
Release-acked-by: Juergen Gross 
Acked-by: Lars Kurth 
(cherry picked from commit 539f93945cad06fd90784716be1dc8d2624b6f66)
---
 docs/Makefile | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index 6743fa3..d82463f 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -237,17 +237,18 @@ txt/%.txt: %.markdown
$(INSTALL_DATA) $< $@
 
 # Metarule for generating pandoc rules.
-define GENERATE_PANDOC_RULE
-# $(1) is the target documentation format. $(2) is the source format.
-
-$(1)/%.$(1): %.$(2)
+define GENERATE_PANDOC_RULE_RAW
+$(1): $(2)
 ifneq ($(PANDOC),)
@$(INSTALL_DIR) $$(@D)
$(PANDOC) --number-sections --toc --standalone $$< --output $$@
 else
@echo "pandoc not installed; skipping $$@"
 endif
-
+endef
+define GENERATE_PANDOC_RULE
+# $(1) is the target documentation format. $(2) is the source format.
+$(call GENERATE_PANDOC_RULE_RAW,$(1)/%.$(1),%.$(2))
 endef
 $(eval $(call GENERATE_PANDOC_RULE,pdf,pandoc))   # pdf/%.pdf: %.pandoc
 $(eval $(call GENERATE_PANDOC_RULE,txt,pandoc))   # txt/%.txt: %.pandoc
-- 
2.1.4


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

[Xen-devel] [PATCH 2/9] SUPPORT.md: Syntax: Fix a typo "States"

[Ian Jackson]

Signed-off-by: Ian Jackson 
Release-acked-by: Juergen Gross 
Acked-by: George Dunlap 
Acked-by: Lars Kurth 
(cherry picked from commit ebbd0299089a698c39d4ced966df5831944b4305)
---
 SUPPORT.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 4f69ed6..92c6a2c 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -357,7 +357,7 @@ Guest-side driver capable of speaking the Xen PV block 
protocol
 Status, FreeBSD: Supported, Security support external
 Status, NetBSD: Supported, Security support external
 Status, OpenBSD: Supported, Security support external
-States, Windows: Supported
+Status, Windows: Supported
 
 Guest-side driver capable of speaking the Xen PV networking protocol
 
-- 
2.1.4


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

[Xen-devel] [PATCH 1/9] SUPPORT.md: Syntax: Fix some bullet lists

[Ian Jackson]

Continuations of bullet list items must be indented by exactly 4
spaces (according to pandoc_markdown(5) on Debian jessie).

This is most easily achieved by making the bullet list items have two
spaces before the `*'.

Signed-off-by: Ian Jackson 
Release-acked-by: Juergen Gross 
Acked-by: George Dunlap 
Acked-by: Lars Kurth 
(cherry picked from commit 01143b6273bc35a35afde154b2bb2415941bea89)
---
 SUPPORT.md | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index cb862b5..4f69ed6 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -770,40 +770,40 @@ What is the risk of it exhibiting bugs?
 
 General answers to the above:
 
- * **Here be dragons**
+  * **Here be dragons**
 
-   Pretty likely to still crash / fail to work.
-   Not recommended unless you like life on the bleeding edge.
+Pretty likely to still crash / fail to work.
+Not recommended unless you like life on the bleeding edge.
 
- * **Quirky**
+  * **Quirky**
 
-   Mostly works but may have odd behavior here and there.
-   Recommended for playing around or for non-production use cases.
+Mostly works but may have odd behavior here and there.
+Recommended for playing around or for non-production use cases.
 
- * **Normal**
+  * **Normal**
 
-   Ready for production use
+Ready for production use
 
 ### Interface stability
 
 If I build a system based on the current interfaces,
 will they still work when I upgrade to the next version?
 
- * **Not stable**
+  * **Not stable**
 
-   Interface is still in the early stages and
-   still fairly likely to be broken in future updates.
+Interface is still in the early stages and
+still fairly likely to be broken in future updates.
 
- * **Provisionally stable**
+  * **Provisionally stable**
 
-   We're not yet promising backwards compatibility,
-   but we think this is probably the final form of the interface.
-   It may still require some tweaks.
+We're not yet promising backwards compatibility,
+but we think this is probably the final form of the interface.
+It may still require some tweaks.
 
- * **Stable**
+  * **Stable**
 
-   We will try very hard to avoid breaking backwards  compatibility,
-   and to fix any regressions that are reported.
+We will try very hard to avoid breaking backwards  compatibility,
+and to fix any regressions that are reported.
 
 ### Security supported
 
-- 
2.1.4


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

[Xen-devel] [PATCH 9/9] SUPPORT.md: Document the new text ordering rule

[Ian Jackson]

Signed-off-by: Ian Jackson 
Release-acked-by: Juergen Gross 
(cherry picked from commit 2e9aeb6f40eaf13c20231ec91301be74a19152ad)
---
 SUPPORT.md | 5 +
 1 file changed, 5 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index 3429afb..0d2db1f 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -712,6 +712,11 @@ The file is in markdown format.
 The machine-readable fragments are markdown literals
 containing RFC-822-like (deb822-like) data.
 
+In each case, descriptions which expand on the name of a feature as
+provided in the section heading, precede the Status indications.
+Any paragraphs which follow the Status indication are caveats or
+qualifications of the information provided in Status fields.
+
 ## Keys found in the Feature Support subsections
 
 ### Status
-- 
2.1.4


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

[Xen-devel] [PATCH 4/9] docs/gen-html-index: Extract titles from HTML documents

[Ian Jackson]

Signed-off-by: Ian Jackson 
Release-acked-by: Juergen Gross 
Acked-by: Lars Kurth 
(cherry picked from commit 7782db9260d4c6499458de4e8d9866bc0427e143)

[ Combined with: ]

docs/gen-html-index: Make HTML::TreeBuilder::XPath optional again

7782db9260d4 "docs/gen-html-index: Extract titles from HTML documents"
requires HTML::TreeBuilder::XPath.

This is sadly not as widely available as I had hoped.  Work around
this problem by making the use of this module optional: instead of
`use'ing at the toplevel, we `require' it in the eval.  If it's not
present, then the title is simply not extracted and the filename is
used as before, which is tolerable.

Also add some debugging.

Reported-by: Doug Goldstein 
Signed-off-by: Ian Jackson 
Reviewed-by: Doug Goldstein 
Tested-by: Doug Goldstein 
(cherry picked from commit 16fb4b5a9a79f95df17f10ba62e9f44d21cf89b5)
---
 docs/gen-html-index | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/docs/gen-html-index b/docs/gen-html-index
index e9792bf..410674e 100644
--- a/docs/gen-html-index
+++ b/docs/gen-html-index
@@ -20,8 +20,10 @@ our @dirs;
 our %index;
 
 our $outdir;
+our $debug;
 
-GetOptions("i=s" => sub { read_index(@_);} )
+GetOptions("i=s" => sub { read_index(@_);},
+   "D" => \$debug)
 or die;
 
 ($outdir,@docs) = @ARGV;
@@ -64,6 +66,20 @@ sub make_linktext ($) {
 return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
 $l =~ s/.(?:html|txt)$//g;
 return $index{$l} if exists $index{$l};
+
+my $from_html;
+eval {
+require HTML::TreeBuilder::XPath;
+my $tree = new HTML::TreeBuilder::XPath;
+my $f = "$outdir/$l.html";
+open F, '<', $f or die "$l $f $!";
+$tree->parse_file(\*F) or die;
+close F;
+$from_html = $tree->findvalue("/html/head/title");
+};
+print "$l: get title: $@" if $@ && $debug;
+return $from_html if $from_html;
+
 return basename($l);
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH 7/9] docs/Makefile: Format SUPPORT.md into the toplevel

[Ian Jackson]

Signed-off-by: Ian Jackson 
Release-acked-by: Juergen Gross 
Acked-by: Lars Kurth 
(cherry picked from commit f246d42665a6023c248c5b3e374da5691df63f6f)
---
 docs/Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/docs/Makefile b/docs/Makefile
index d82463f..b300bb6 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -28,7 +28,8 @@ DOC_MAN7 := $(patsubst man/%.pod.7,man7/%.7,$(MAN7SRC-y)) \
$(patsubst man/%.markdown.7,man7/%.7,$(MAN7SRC-y))
 DOC_MAN8 := $(patsubst man/%.pod.8,man8/%.8,$(MAN8SRC-y)) \
$(patsubst man/%.markdown.8,man8/%.8,$(MAN8SRC-y))
-DOC_HTML := $(patsubst %.markdown,html/%.html,$(MARKDOWNSRC-y)) \
+DOC_HTML := html/SUPPORT.html \
+$(patsubst %.markdown,html/%.html,$(MARKDOWNSRC-y)) \
 $(patsubst %.pandoc,html/%.html,$(PANDOCSRC-y)) \
 $(patsubst man/%.markdown.1,html/man/%.1.html,$(MAN1SRC-y)) \
 $(patsubst man/%.markdown.5,html/man/%.5.html,$(MAN5SRC-y)) \
@@ -255,6 +256,8 @@ $(eval $(call GENERATE_PANDOC_RULE,txt,pandoc))   # 
txt/%.txt: %.pandoc
 $(eval $(call GENERATE_PANDOC_RULE,html,pandoc))  # html/%.html: %.pandoc
 $(eval $(call GENERATE_PANDOC_RULE,pdf,markdown)) # pdf/%.pdf: %.markdown
 
+$(eval $(call 
GENERATE_PANDOC_RULE_RAW,html/SUPPORT.html,$(XEN_ROOT)/SUPPORT.md)) # 
pdf/%.pdf: %.markdown
+
 ifeq (,$(findstring clean,$(MAKECMDGOALS)))
 $(XEN_ROOT)/config/Docs.mk:
$(error You have to run ./configure before building docs)
-- 
2.1.4


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

[Xen-devel] [PATCH 5/9] docs/gen-html-index: Support documents at the toplevel

[Ian Jackson]

There are none yet.

Signed-off-by: Ian Jackson 
Release-acked-by: Juergen Gross 
Acked-by: Lars Kurth 
(cherry picked from commit 1e4a834a8f5d970e68cff6d9c16710194bc46537)
---
 docs/gen-html-index | 4 
 1 file changed, 4 insertions(+)

diff --git a/docs/gen-html-index b/docs/gen-html-index
index 410674e..4fad6db 100644
--- a/docs/gen-html-index
+++ b/docs/gen-html-index
@@ -140,6 +140,10 @@ sub dirs($)
 return @dirs;
 }
 
+foreach my $of (grep { !m{/} } @docs) {
+$top .= make_link($of,'');
+}
+
 foreach my $od (sort { $a cmp $b } uniq map { dirs($_) } @docs) {
 my @d = (grep /^\Q$od\E/, @docs);
 if ( @d == 1 and $d[0] eq "$od/index.html" )
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation

[Ian Jackson]

This is a backport of my two recent series to fix bugs in SUPPORT.md,
format it as part of the published docs, and use relative position of
the `Status' stanza compared to descriptive text to indicate whether
the text is a caveat that deserves a footnote.

Most of this is uncontroversial and I have run the build and checked
that the resulting index.html is good.

It would be good if someone could review particularly the way I
resolved the conflicts in the big patch to SUPPORT.md, ie in
  [PATCH 8/9] SUPPORT.md: Move descriptions up before Status info

The result for 4.10's
SUPPORT.md is here:
  https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/SUPPORT.html

I have also checked that (with the patch I am about to send for
staging's parse-support-md) that this generates a sensible-looking
support matrix.  The resulting support matrix can be found here:
  https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html
(The hyperlink references for staging are to the live xenbits version;
the references for 4.10 are to the example output file mentioned above.)

I have squashed the fix to not depend on HTML::TreeBuilder::XPath into
the patch that introduces the dependency.

For my reference, this was made as follows:
  docs/support-matrix-generate -D HEAD 
https://xenbits.xen.org/docs/unstable-staging/SUPPORT.html 
refs/heads/wip.support-stmt-NN-2 SUPPORT.html 2>&1 >docs/html/t.html |less
  rsync -LvP docs/html/{t,SUPPORT}.html 
xenbits:public_html/2018/support-matrix-example-C

Thanks,
Ian.

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

[Xen-devel] [PATCH 3/9] SUPPORT.md: Syntax: Provide a title rather than a spurious empty section

[Ian Jackson]

This commits (more or less) this file to be processed with pandoc,
rather than other markdown processors.  There is, unfortunately, no
widely-accepted way to declare a title for the document.

I tested feeding the document to markdown(1) on Debian jessie and it
reproduced the % line as if it were simple text.  I guess many other
markdown processors will do something similarly tolerable.  My
internet searches did not discover a markdown processor that used
lines starting with % for something else.

Signed-off-by: Ian Jackson 
Release-acked-by: Juergen Gross 
Acked-by: George Dunlap 
Acked-by: Lars Kurth 
(cherry picked from commit a569c6f815fb6a18c64b8f122f5e2bbecd32)
---
 SUPPORT.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 92c6a2c..201e5a3 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -1,4 +1,4 @@
-# Support statement for this release
+% Support statement for this release
 
 This document describes the support status
 and in particular the security support status of the Xen branch
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] x86: Do not reserve a crash kernel region if booted on Xen PV

[Juergen Gross]

On 25/04/18 12:08, Petr Tesarik wrote:
> Xen PV domains cannot shut down and start a crash kernel. Instead,
> the crashing kernel makes a SCHEDOP_shutdown hypercall with the
> reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in
> arch/x86/xen/enlighten_pv.c.
> 
> A crash kernel reservation is merely a waste of RAM in this case. It
> may also confuse users of kexec_load(2) and/or kexec_file_load(2).
> When flags include KEXEC_ON_CRASH or KEXEC_FILE_ON_CRASH,
> respectively, these syscalls return success, which is technically
> correct, but the crash kexec image will never be actually used.
> 
> Signed-off-by: Petr Tesarik 

Reviewed-by: Juergen Gross 


Juergen

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

[Xen-devel] [distros-debian-squeeze test] 74641: tolerable FAIL

[Platform Team regression test user]

flight 74641 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74641/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 
74632
 test-amd64-i386-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 
74632
 test-amd64-amd64-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 
74632
 test-amd64-i386-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 
74632

baseline version:
 flight   74632

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubfail
 test-amd64-i386-amd64-squeeze-netboot-pygrub fail
 test-amd64-amd64-i386-squeeze-netboot-pygrub fail
 test-amd64-i386-i386-squeeze-netboot-pygrub  fail



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.


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

[Xen-devel] Should PV frontend drivers trust the backends?

[Juergen Gross]

This is a followup of a discussion on IRC:

The main question of the discussion was: "Should frontend drivers
trust their backends not doing malicious actions?"

This IMO includes:

1. The data put by the backend on the ring page(s) is sane and
   consistent, meaning that e.g. the response producer index is always
   ahead of the consumer index.

2. Response data won't be modified by the backend after the producer
   index has been incremented signaling the response is valid.

3. Response data is sane, e.g. an I/O data length is not larger than
   the buffer originally was.

4. When a response has been sent all grants belonging to the request
   have been unmapped again by the backend, meaning that the frontend
   can assume the grants can be removed without conflict.

Today most frontend drivers (at least in the Linux kernel) seem to
assume all of the above is true (there are some exceptions, but never
for all items):

- they don't check sanity of ring index values
- they don't copy response data into local memory before looking at it
- they don't verify returned data length (or do so via BUG_ON())
- they BUG() in case of a conflict when trying to remove a grant

So the basic question is: should all Linux frontend drivers be modified
in order to be able to tolerate buggy or malicious backends? Or is the
list of trust above fine?

IMO even in case the frontends do trust the backends to behave sane this
doesn't mean driver domains don't make sense. Driver domains still make
a Xen host more robust as they e.g. protect the host against driver
failures normally leading to a crash of dom0.


Juergen

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

[Xen-devel] Xen Security Advisory 259 - x86: PV guest may crash Xen with XPTI

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-259
  version 2

 x86: PV guest may crash Xen with XPTI

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

The workaround for the Meltdown vulnerability (XSA-254) failed to deal
with an error code path connecting the INT 80 handling with general
exception handling.  This results in an unconditional write attempt of
the value zero to an address near 2^64, in cases where a PV guest has no
handler installed for INT 80 on one of its vCPU-s.

IMPACT
==

A malicious or buggy guest may cause a hypervisor crash, resulting in
a Denial of Service (DoS) affecting the entire host.

VULNERABLE SYSTEMS
==

All Xen versions which the XSA-254 fixes were applied to are vulnerable.

Only x86 systems are vulnerable.  ARM systems are not vulnerable.

Only x86 PV guests can exploit the vulnerability.  x86 PVH and HVM
guests cannot exploit the vulnerability.

MITIGATION
==

Running only PVH or HVM guests avoids the vulnerability.

CREDITS
===

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa259.patch  xen-unstable, Xen 4.10.x ... xen 4.7.x
xsa259-4.6.patch  Xen 4.6.x

$ sha256sum xsa259*
5c14a90af066c952974324b361e2a428c280f876b854f0c85a78e8579054a4d1  xsa259.meta
ff2efb5eb2502ded988d0aa15351030a15494a9e2223eafbb88377a8e4d39dcb  xsa259.patch
c40bc8802077cf73f8393fb50574b7c7efbc4d127e202b0ebd757d34aa07aac3  
xsa259-4.6.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

iQEcBAEBCAAGBQJa4G58AAoJEIP+FMlX6CvZrqIH+QFfC5NOoFhVZAChTU0WQ7U6
UwP7yEyLeY15VrGb4YvwzKhvTNwsRRiYTbTNB/QjAkrUkMRhBiUIz7mQqBl0Vc/N
4zblt+YNdDMjhCllTjvtYU6OJzbsqvEBByB4mFrz6fxfZiuXIbOnMUOxLHRRdXLR
6JR8+4RrheKNl9DF6lmLj50d3G/fKrNLY9id8VcDG1TGIB6E1CbJ6gibw7FiYDSq
PETa5O1szo2FO2yY+xcMzzGLHv+oVeKZnmuq9KYtP7Q+G823Twz1RE6rTBEjwhs9
sDGUlgZ48QVfSzer10syzyeX0p9hLHyKhlJnCrmCiywvKq68/uVexZFNcOKRPtE=
=n+01
-END PGP SIGNATURE-


xsa259.meta
Description: Binary data


xsa259.patch
Description: Binary data


xsa259-4.6.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Security Advisory 258 - Information leak via crafted user-supplied CDROM

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-258
  version 2

   Information leak via crafted user-supplied CDROM

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

QEMU handles many different file formats for virtual disks (e.g., raw,
qcow2, vhd, ).  Some of these formats are "snapshots" that specify
"patches" to an alternate disk image, whose filename is included in
the snapshot file.

When qemu is given a disk but the type is not specified, it attempts
to guess the file format by reading it.  If a disk image is intended
to be 'raw', but the image is entirely controlled by an attacker, the
attacker could write a header to the image, describing one of these
"snapshot" formats, and pointing to an arbitrary file as the "backing"
file.

When attaching disks via command-line parameters at boot time
(including both "normal" disks and CDROMs), libxl specifies the
format; however, when inserting a CDROM live via QMP, the format was
not specified.

IMPACT
==

An attacker supplying a crafted CDROM image can read any file (or
device node) on the dom0 filesystem with the permissions of the qemu
devicemodel process.  (The virtual CDROM device is read-only, so
no data can be written.)

VULNERABLE SYSTEMS
==

Only x86 HVM guests with a virtual CDROM device are affected.  ARM
guests, x86 PV guests, x86 PVH guests, and x86 HVM guests without a
virtual CDROM device are not affected.

Only systems with qemu running in dom0 are affected; systems running
stub domains are not affected.  Only systems using qemu-xen (aka
"qemu-upstream" are affected; systems running qemu-xen-traditional
are not affected.

Only systems in which an attacker can provide a raw CDROM image, and
cause that image to be virtually inserted while the guest is running,
are affected.  Systems which only have host administrator-supplied
CDROM images, or systems which allow images to be added only at boot
time, are not affected.

MITIGATION
==

One workaround is to "wrap" the guest-supplied image in a specific
format; i.e., accept a raw image from the untrusted user, and convert
it into qcow2 format; for example:

qemu-img convert -f raw -O qcow2 untrusted.raw wrapped.qcow2

WARNING: Make sure to specify `-f raw` if you do this, or qemu will
"guess" the format of "untrusted.raw" (which the attacker may have
crafted to look like a qcow2 snapshot image with an alternativee base).

Another workaround is to allow guests to only change CDROMs at boot
time, not while the guest is running.

CREDITS
===

This issue was discovered by Anthony Perard of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa258.patch   xen-unstable, Xen 4.10.x, Xen 4.9.x
xsa258-4.8.patch   Xen 4.8.x, Xen 4.7.x
xsa258-4.6.patch   Xen 4.6.x

$ sha256sum xsa258*
2c35a77eeca5579b5c32517c5ba511c836fa70f8b824ca8883fc6e1a7e608405  xsa258.meta
7e8014deae4fa19464fe6570d0719f8f0d7730dd153d58b2fa38b0cd5ed2e459  xsa258.patch
2c58060a42dafbf65563941dd8c737732124b49eb47007cc60f647553227f557  
xsa258-4.6.patch
ebba2f1f084249cd1e1c2f59e338412161884c31c83dbba03fc1e10bf4ba57a1  
xsa258-4.8.patch
$

DEPLOYMENT DURING EMBARGO
=

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

However, deploying the "only allow guests to change CDROMs at boot
time" is NOT permitted (except where all the affected systems and VMs
are administered and used only by organisations which are members of
the Xen Project Security Issues Predisclosure List).  Specifically,
deployment on public cloud systems is NOT permitted.  This is because
it may give attackers a hint of where to look for the vulnerability.
Deployment of this mitigation is permitted only AFTER the embargo
ends.

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

iQEcBAEBCAAGBQJa4G55AAoJEIP+FMlX6CvZHjYIAJEtdHT5yPyQuSjh8ATOYN/s
DrpUSw65EvvgbuGJTcmWZMc335AvyoMDtYVtk+Ouy5dMlfuUXcwjimoLWC6FfEDg
aJ19puvjVaA8JcRzimlWQjru8Eqyso1+uNjuvsv1RCSkhN6qGBGCx6xlyWJL0tGk

[Xen-devel] [PATCH v2] x86/microcode: Synchronize late microcode loading

[Chao Gao]

From: Gao Chao 

This patch ports microcode improvement patches from linux kernel.

Before you read any further: the early loading method is still the
preferred one and you should always do that. The following patch is
improving the late loading mechanism for long running jobs and cloud use
cases.

Gather all cores and serialize the microcode update on them by doing it
one-by-one to make the late update process as reliable as possible and
avoid potential issues caused by the microcode update.

This patch is also in accord with Andrew's suggestion,
"Rendezvous all online cpus in an IPI to apply the patch, and keep the
processors in until all have completed the patch.", in [1].

[1]:https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update#Run_time_microcode_updates

Signed-off-by: Chao Gao 
Tested-by: Chao Gao 
[linux commit: a5321aec6412b20b5ad15db2d6b916c05349dbff]
[linux commit: bb8c13d61a629276a162c1d2b1a20a815cbcfbb7]
Cc: Kevin Tian 
Cc: Jun Nakajima 
Cc: Ashok Raj 
Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Andrew Cooper 
Cc: Jan Beulich 
---
Resend for I forgot to send it to maillist.

v2:
 - Reduce the timeout from 1s to 30ms
 - update microcode with better parallelism; only one logical thread of each
 core tries to take lock and do the update.
 - remove 'error' field from struct microcode_info
 - correct coding style issues
---
 xen/arch/x86/microcode.c | 117 ---
 1 file changed, 91 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index 4163f50..fddce1e 100644
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -22,6 +22,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,15 +31,21 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+/* By default, wait for 3us */
+#define MICROCODE_DEFAULT_TIMEOUT 3
+
 static module_t __initdata ucode_mod;
 static signed int __initdata ucode_mod_idx;
 static bool_t __initdata ucode_mod_forced;
@@ -187,9 +194,9 @@ static DEFINE_SPINLOCK(microcode_mutex);
 DEFINE_PER_CPU(struct ucode_cpu_info, ucode_cpu_info);
 
 struct microcode_info {
-unsigned int cpu;
+cpumask_t cpus;
+atomic_t cpu_in, cpu_out;
 uint32_t buffer_size;
-int error;
 char buffer[1];
 };
 
@@ -281,24 +288,56 @@ static int microcode_update_cpu(const void *buf, size_t 
size)
 return err;
 }
 
-static long do_microcode_update(void *_info)
+/* Wait for all CPUs to rendezvous with a timeout (us) */
+static int wait_for_cpus(atomic_t *cnt, int timeout)
 {
-struct microcode_info *info = _info;
-int error;
+unsigned int cpus = num_online_cpus();
 
-BUG_ON(info->cpu != smp_processor_id());
+atomic_inc(cnt);
 
-error = microcode_update_cpu(info->buffer, info->buffer_size);
-if ( error )
-info->error = error;
+while ( atomic_read(cnt) != cpus )
+{
+if ( timeout <= 0 )
+{
+printk("Timeout when waiting for CPUs calling in\n");
+return -EBUSY;
+}
+udelay(1);
+timeout--;
+}
 
-info->cpu = cpumask_next(info->cpu, _online_map);
-if ( info->cpu < nr_cpu_ids )
-return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
+return 0;
+}
 
-error = info->error;
-xfree(info);
-return error;
+static int do_microcode_update(void *_info)
+{
+struct microcode_info *info = _info;
+unsigned int cpu = smp_processor_id();
+int ret;
+
+ret = wait_for_cpus(>cpu_in, MICROCODE_DEFAULT_TIMEOUT);
+if ( ret )
+return ret;
+
+/*
+ * Logical threads which set the first bit in cpu_sibling_mask can do
+ * the update. Other sibling threads just await the completion of
+ * microcode update.
+ */
+if ( cpumask_test_and_set_cpu(
+cpumask_first(per_cpu(cpu_sibling_mask, cpu)), >cpus) )
+ret = microcode_update_cpu(info->buffer, info->buffer_size);
+/*
+ * Increase the wait timeout to a safe value here since we're serializing
+ * the microcode update and that could take a while on a large number of
+ * CPUs. And that is fine as the *actual* timeout will be determined by
+ * the last CPU finished updating and thus cut short
+ */
+if ( wait_for_cpus(>cpu_out, MICROCODE_DEFAULT_TIMEOUT *
+   num_online_cpus()) )
+panic("Timeout when finishing updating microcode");
+
+return ret;
 }
 
 int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len)
@@ -318,26 +357,52 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) 
buf, unsigned long len)
 
 ret = 

Re: [Xen-devel] Graduation Review: Windows PV Driver

[George Dunlap]

On Mon, Apr 23, 2018 at 6:14 PM, Lars Kurth  wrote:
> ## Summary/Recommendation
>
> Assessment by Lars Kurth, Community Manager:
>
> _Given the maturity of the drivers and thus limited need to fix issues or 
> develop new features,
> I would recommend to graduate the project. The project has shown increased 
> user
> engagement, adoption and delivered several releases which is consistent with 
> a mature
> project . I have no objections on grounds of process adherence, values and 
> developer
> community diversity and propose to the project leadership teams of other 
> mature
> projects to agree to graduate the Windows PV Driver subproject._
>
> _Recommendations: Given that Windows PV Drivers development today depends on 
> 3rd
> party testing, I would like to recommend a public discussion whether some 
> testing of
> Windows PV Drivers in OSSTEST is feasible and desirable._

+1 from me.  I think if this project doesn't make the cut, nothing will. :-)

 -George

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

Re: [Xen-devel] 4.11.0 RC1 panic

[Manuel Bouyer]

On Wed, Apr 25, 2018 at 09:16:59AM +0100, Andrew Cooper wrote:
> Manuel: As a tangentially related question, does NetBSD ever try to page
> out its LDT?

AFAIK no, LDTs are allocated as kernel wired memory

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

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

Re: [Xen-devel] bogus wrap check in xen-netback

[Wei Liu]

On Wed, Apr 25, 2018 at 12:35:11PM +0200, Olaf Hering wrote:
> Am Wed, 25 Apr 2018 11:31:25 +0100
> schrieb Wei Liu :
> 
> > My bad. Yes, they are converted to int, not unsigned int.
> 
> Hopefully that happens only if the target is int, not if all involved 
> variables are short.
> 
> Unless there are objections I will prepare a patch to deal with RING_IDX 
> being u16.
> 

RING_IDX is a type defined in the public header -- I don't think you can
change that at all. You don't know what third party drivers rely on
that.

If you want to change the type locally in netback, then why? Aren't you
just debugging?

In that light, I don't see a point having a patch to deal with u16.

Wei.


> Olaf



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

Re: [Xen-devel] 4.11.0 RC1 panic

[Manuel Bouyer]

On Wed, Apr 25, 2018 at 12:58:47AM -0600, Jan Beulich wrote:
> >>> On 24.04.18 at 18:06,  wrote:
> > Hello,
> > I tested xen 4.11.0 rc1 with NetBSD as dom0.
> > I could boot a NetBSD PV domU without problem, but at shutdown time 
> > (poweroff
> > in the domU), I got a Xen panic:
> > (XEN) Assertion 'cpu < nr_cpu_ids' failed at 
> > ...1/work/xen-4.11.0-rc1/xen/include/xen/cpumask.h:97
> > 
> > A xl destroy instead of poweroff gives the same result.
> > 
> > This happens with both 32bitsPAE and 64bits domU. This doens't seem to
> > happen with HVM domUs.
> > 
> > Attached are a cut-n-paste of the panic, and the output of xl demsg.
> 
> Without line numbers associated with at least the top stack trace entry
> I can only guess what it might be - could you give the patch below a try?
> (This may not be the final patch, as I'm afraid there may be some race
> here, but I'd have to work this out later.)

Yes, this works. thanks !
I'll now put this version on the NetBSD testbed I'm running.
This should put some pressure on it.

thanks !

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

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

Re: [Xen-devel] [PATCH v2 08/10] xen/arm: Release timer interrupts when CPU is hot-unplugged

[Julien Grall]

On 25/04/18 11:34, Mirela Simonovic wrote:

Hi Julien,

You may have missed this one. Should we try using notifiers here as well?


Yes, I assumed this was implied by my comments previously, so I skipped 
the patch. Sorry for that.


Cheers,



Thanks,
Mirela

On Fri, Apr 20, 2018 at 2:25 PM, Mirela Simonovic
 wrote:

When a CPU is hot-unplugged timer interrupts have to be released
in order to free the memory that was allocated when the interrupts
were requested (using request_irq()). The request_irq is called
for each timer interrupt when the CPU gets hotplugged
(start_secondary->init_timer_interrupt->request_irq).

Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
  xen/arch/arm/smpboot.c | 1 +
  xen/arch/arm/time.c| 7 +++
  xen/include/asm-arm/time.h | 6 ++
  3 files changed, 14 insertions(+)

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 449fefc77d..b4ed479dc6 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -386,6 +386,7 @@ void __cpu_disable(void)
   * in respective init interrupt functions called from start_secondary)
   */
  deinit_maintenance_interrupt();
+deinit_timer_interrupt();

  /* It's now safe to remove this processor from the online map */
  cpumask_clear_cpu(cpu, _online_map);
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index c11fcfeadd..1d9dc16f89 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -312,6 +312,13 @@ void init_timer_interrupt(void)
  check_timer_irq_cfg(timer_irq[TIMER_PHYS_NONSECURE_PPI], "NS-physical");
  }

+void deinit_timer_interrupt(void)
+{
+release_irq(timer_irq[TIMER_HYP_PPI], NULL);
+release_irq(timer_irq[TIMER_VIRT_PPI], NULL);
+release_irq(timer_irq[TIMER_PHYS_NONSECURE_PPI], NULL);
+}
+
  /* Wait a set number of microseconds */
  void udelay(unsigned long usecs)
  {
diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
index 5b9a31de91..6fa4c47532 100644
--- a/xen/include/asm-arm/time.h
+++ b/xen/include/asm-arm/time.h
@@ -34,6 +34,12 @@ unsigned int timer_get_irq(enum timer_ppi ppi);
  /* Set up the timer interrupt on this CPU */
  extern void init_timer_interrupt(void);

+/*
+ * Revert actions done in init_timer_interrupt that are required to properly
+ * disable this CPU.
+ */
+extern void deinit_timer_interrupt(void);
+
  /* Counter value at boot time */
  extern uint64_t boot_count;

--
2.13.0



--
Julien Grall

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

Re: [Xen-devel] bogus wrap check in xen-netback

[Olaf Hering]

Am Wed, 25 Apr 2018 11:31:25 +0100
schrieb Wei Liu :

> My bad. Yes, they are converted to int, not unsigned int.

Hopefully that happens only if the target is int, not if all involved variables 
are short.

Unless there are objections I will prepare a patch to deal with RING_IDX being 
u16.

Olaf


pgpKZjIyrez3i.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 08/10] xen/arm: Release timer interrupts when CPU is hot-unplugged

[Mirela Simonovic]

Hi Julien,

You may have missed this one. Should we try using notifiers here as well?

Thanks,
Mirela

On Fri, Apr 20, 2018 at 2:25 PM, Mirela Simonovic
 wrote:
> When a CPU is hot-unplugged timer interrupts have to be released
> in order to free the memory that was allocated when the interrupts
> were requested (using request_irq()). The request_irq is called
> for each timer interrupt when the CPU gets hotplugged
> (start_secondary->init_timer_interrupt->request_irq).
>
> Signed-off-by: Mirela Simonovic 
>
> ---
> CC: Stefano Stabellini 
> CC: Julien Grall 
> ---
>  xen/arch/arm/smpboot.c | 1 +
>  xen/arch/arm/time.c| 7 +++
>  xen/include/asm-arm/time.h | 6 ++
>  3 files changed, 14 insertions(+)
>
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index 449fefc77d..b4ed479dc6 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -386,6 +386,7 @@ void __cpu_disable(void)
>   * in respective init interrupt functions called from start_secondary)
>   */
>  deinit_maintenance_interrupt();
> +deinit_timer_interrupt();
>
>  /* It's now safe to remove this processor from the online map */
>  cpumask_clear_cpu(cpu, _online_map);
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index c11fcfeadd..1d9dc16f89 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -312,6 +312,13 @@ void init_timer_interrupt(void)
>  check_timer_irq_cfg(timer_irq[TIMER_PHYS_NONSECURE_PPI], "NS-physical");
>  }
>
> +void deinit_timer_interrupt(void)
> +{
> +release_irq(timer_irq[TIMER_HYP_PPI], NULL);
> +release_irq(timer_irq[TIMER_VIRT_PPI], NULL);
> +release_irq(timer_irq[TIMER_PHYS_NONSECURE_PPI], NULL);
> +}
> +
>  /* Wait a set number of microseconds */
>  void udelay(unsigned long usecs)
>  {
> diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
> index 5b9a31de91..6fa4c47532 100644
> --- a/xen/include/asm-arm/time.h
> +++ b/xen/include/asm-arm/time.h
> @@ -34,6 +34,12 @@ unsigned int timer_get_irq(enum timer_ppi ppi);
>  /* Set up the timer interrupt on this CPU */
>  extern void init_timer_interrupt(void);
>
> +/*
> + * Revert actions done in init_timer_interrupt that are required to properly
> + * disable this CPU.
> + */
> +extern void deinit_timer_interrupt(void);
> +
>  /* Counter value at boot time */
>  extern uint64_t boot_count;
>
> --
> 2.13.0
>

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

Re: [Xen-devel] bogus wrap check in xen-netback

[Wei Liu]

On Wed, Apr 25, 2018 at 04:26:06AM -0600, Jan Beulich wrote:
> >>> On 25.04.18 at 12:06,  wrote:
> > On Wed, Apr 25, 2018 at 11:04:26AM +0200, Olaf Hering wrote:
> >> Am Wed, 25 Apr 2018 09:59:23 +0100
> >> schrieb Wei Liu :
> >> 
> >> > Do you have the full diff of your changes? 
> >> 
> >> Not right now. But without 'val', or val being uint, the same error 
> >> happens 
> > in f():
> >> 
> >> #include 
> >> void f(void)
> >> {
> >> unsigned short req_prod = 0, req_cons = 65400;
> >> unsigned short val;
> >> val = req_prod - req_cons;
> >> printf("req_prod - req_cons %u\n", val);
> >> printf("req_prod - req_cons %x\n", val);
> >> }
> > 
> > What Jan said.
> > 
> > Integer promotion makes unsigned short into unsigned int first then do
> > the calculation.
> 
> Not exactly - it promotes to plain (i.e. signed) int.

My bad. Yes, they are converted to int, not unsigned int.

Wei.

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

Re: [Xen-devel] bogus wrap check in xen-netback

[Jan Beulich]

>>> On 25.04.18 at 12:06,  wrote:
> On Wed, Apr 25, 2018 at 11:04:26AM +0200, Olaf Hering wrote:
>> Am Wed, 25 Apr 2018 09:59:23 +0100
>> schrieb Wei Liu :
>> 
>> > Do you have the full diff of your changes? 
>> 
>> Not right now. But without 'val', or val being uint, the same error happens 
> in f():
>> 
>> #include 
>> void f(void)
>> {
>> unsigned short req_prod = 0, req_cons = 65400;
>> unsigned short val;
>> val = req_prod - req_cons;
>> printf("req_prod - req_cons %u\n", val);
>> printf("req_prod - req_cons %x\n", val);
>> }
> 
> What Jan said.
> 
> Integer promotion makes unsigned short into unsigned int first then do
> the calculation.

Not exactly - it promotes to plain (i.e. signed) int.

Jan



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

[Xen-devel] [xen-unstable-coverity test] 122409: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  27170adb54a558e11defcd51989326a9beb95afe
baseline version:
 xen  16fb4b5a9a79f95df17f10ba62e9f44d21cf89b5

Last test of basis   122308  2018-04-15 09:38:37 Z   10 days
Testing same since   122409  2018-04-25 09:18:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  David Wang 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Oleksandr Tyshchenko 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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

To xenbits.xen.org:/home/xen/git/xen.git
   16fb4b5a9a..27170adb54  27170adb54a558e11defcd51989326a9beb95afe -> 
coverity-tested/smoke

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

[Xen-devel] [PATCH] x86: Do not reserve a crash kernel region if booted on Xen PV

[Petr Tesarik]

Xen PV domains cannot shut down and start a crash kernel. Instead,
the crashing kernel makes a SCHEDOP_shutdown hypercall with the
reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in
arch/x86/xen/enlighten_pv.c.

A crash kernel reservation is merely a waste of RAM in this case. It
may also confuse users of kexec_load(2) and/or kexec_file_load(2).
When flags include KEXEC_ON_CRASH or KEXEC_FILE_ON_CRASH,
respectively, these syscalls return success, which is technically
correct, but the crash kexec image will never be actually used.

Signed-off-by: Petr Tesarik 
---
 arch/x86/kernel/setup.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 6285697b6e56..5c623dfe39d1 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -534,6 +535,11 @@ static void __init reserve_crashkernel(void)
high = true;
}
 
+   if (xen_pv_domain()) {
+   pr_info("Ignoring crashkernel for a Xen PV domain\n");
+   return;
+   }
+
/* 0 means: find the address automatically */
if (crash_base <= 0) {
/*
-- 
2.13.6

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

Re: [Xen-devel] bogus wrap check in xen-netback

[Wei Liu]

On Wed, Apr 25, 2018 at 11:04:26AM +0200, Olaf Hering wrote:
> Am Wed, 25 Apr 2018 09:59:23 +0100
> schrieb Wei Liu :
> 
> > Do you have the full diff of your changes? 
> 
> Not right now. But without 'val', or val being uint, the same error happens 
> in f():
> 
> #include 
> void f(void)
> {
> unsigned short req_prod = 0, req_cons = 65400;
> unsigned short val;
> val = req_prod - req_cons;
> printf("req_prod - req_cons %u\n", val);
> printf("req_prod - req_cons %x\n", val);
> }

What Jan said.

Integer promotion makes unsigned short into unsigned int first then do
the calculation. Assigning the result to val truncates it back to
unsigned short.

For the original code, idx is of type unsigned int. No promotion or
truncation is needed so the end result is correct.

Wei.

> 
> int main(void)
> {
> #if 1
> unsigned nr_ents = 0x100U, req_prod_pvt = 0x14U, rsp_cons = 
> 0xffeeU, req_prod = 0xfffeU;
> unsigned rx_target = 0x40U, qlen = 0x1aU;
> #else
> unsigned nr_ents = 0x100U, req_prod_pvt = 0x00U, rsp_cons = 
> 0xffeeU, req_prod = 0xfffeU;
> unsigned rx_target = 0x40U, qlen = 0x1aU;
> #endif
> printf("batch_target %u, skb_queue_len %u, rx_target %u\n", rx_target 
> - (req_prod_pvt - rsp_cons), qlen, rx_target);
> printf("nr_ents %u\n", nr_ents);
> printf("req_prod_pvt - rsp_cons %u\n", req_prod_pvt - rsp_cons);
> printf("req_prod_pvt - req_prod %u\n", req_prod_pvt - req_prod);
> printf("%u\n", nr_ents - (req_prod_pvt - rsp_cons));
> printf("%u\n", nr_ents - (req_prod_pvt - rsp_cons));
> f();
> return 0;
> }



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

Re: [Xen-devel] bogus wrap check in xen-netback

[Jan Beulich]

>>> On 25.04.18 at 11:04,  wrote:
> Am Wed, 25 Apr 2018 09:59:23 +0100
> schrieb Wei Liu :
> 
>> Do you have the full diff of your changes? 
> 
> Not right now. But without 'val', or val being uint, the same error happens 
> in f():
> 
> #include 
> void f(void)
> {
> unsigned short req_prod = 0, req_cons = 65400;
> unsigned short val;
> val = req_prod - req_cons;
> printf("req_prod - req_cons %u\n", val);
> printf("req_prod - req_cons %x\n", val);
> }

Well, of course - anything more narrow than int will be promoted to int first.

Jan



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

Re: [Xen-devel] [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

[Oleksandr Andrushchenko]

On 04/25/2018 12:02 PM, Takashi Iwai wrote:

On Wed, 25 Apr 2018 10:26:34 +0200,
Oleksandr Andrushchenko wrote:

On 04/24/2018 07:23 PM, Oleksandr Andrushchenko wrote:

On 04/24/2018 06:02 PM, Takashi Iwai wrote:

On Tue, 24 Apr 2018 16:58:43 +0200,
Oleksandr Andrushchenko wrote:

On 04/24/2018 05:35 PM, Takashi Iwai wrote:

On Tue, 24 Apr 2018 16:29:15 +0200,
Oleksandr Andrushchenko wrote:

On 04/24/2018 05:20 PM, Takashi Iwai wrote:

On Mon, 16 Apr 2018 08:24:51 +0200,
Oleksandr Andrushchenko wrote:

+static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id)
+{
+    struct xen_snd_front_evtchnl *channel = dev_id;
+    struct xen_snd_front_info *front_info = channel->front_info;
+    struct xensnd_resp *resp;
+    RING_IDX i, rp;
+    unsigned long flags;
+
+    if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED))
+    return IRQ_HANDLED;
+
+    spin_lock_irqsave(_info->io_lock, flags);
+
+again:
+    rp = channel->u.req.ring.sring->rsp_prod;
+    /* ensure we see queued responses up to rp */
+    rmb();
+
+    for (i = channel->u.req.ring.rsp_cons; i != rp; i++) {

I'm not familiar with Xen stuff in general, but through a quick
glance, this kind of code worries me a bit.

If channel->u.req.ring.rsp_cons has a bogus number, this may
lead to a
very long loop, no?  Better to have a sanity check of the ring
buffer
size.

In this loop I have:
resp = RING_GET_RESPONSE(>u.req.ring, i);
and the RING_GET_RESPONSE macro is designed in the way that
it wraps around when *i* in the question gets bigger than
the ring size:

#define RING_GET_REQUEST(_r, _idx)                    \
       (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req))

So, even if the counter has a bogus number it will not last long

Hm, this prevents from accessing outside the ring buffer, but does it
change the loop behavior?

no, it doesn't

Suppose channel->u.req.ring_rsp_cons = 1, and rp = 0, the loop below
would still consume the whole 32bit counts, no?

 for (i = channel->u.req.ring.rsp_cons; i != rp; i++) {
     resp = RING_GET_RESPONSE(>u.req.ring, i);
     ...
 }

You are right here and the comment is totally valid.
I'll put an additional check like here [1] and here [2]
Will this address your comment?

Yep, this kind of sanity checks should work.


Great, will implement the checks this way then

Well, after thinking a bit more on that and chatting on #xendevel IRC
with Juergen (he is on CC list), it seems that the way the code is now
it is all fine without the checks: the assumption here is that
the backend is trusted to always write sane values to the ring counters,
thus no overflow checks on frontend side are required.
Even if I implement the checks then I have no means to recover, but
just print
an error message and bail out not handling any responses.
This is probably why the checks [1] and [2] are only implemented for the
backend side and there are no such macros for the frontend side.

Takashi, please let me know if the above sounds reasonable and
addresses your comments.

If it's guaranteed to work, that's OK.
But maybe it's worth to comment for readers.

ok, will put a comment on that


thanks,

Takashi

Thank you,
Oleksandr

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

Re: [Xen-devel] bogus wrap check in xen-netback

[Olaf Hering]

Am Wed, 25 Apr 2018 09:59:23 +0100
schrieb Wei Liu :

> Do you have the full diff of your changes? 

Not right now. But without 'val', or val being uint, the same error happens in 
f():

#include 
void f(void)
{
unsigned short req_prod = 0, req_cons = 65400;
unsigned short val;
val = req_prod - req_cons;
printf("req_prod - req_cons %u\n", val);
printf("req_prod - req_cons %x\n", val);
}

int main(void)
{
#if 1
unsigned nr_ents = 0x100U, req_prod_pvt = 0x14U, rsp_cons = 
0xffeeU, req_prod = 0xfffeU;
unsigned rx_target = 0x40U, qlen = 0x1aU;
#else
unsigned nr_ents = 0x100U, req_prod_pvt = 0x00U, rsp_cons = 
0xffeeU, req_prod = 0xfffeU;
unsigned rx_target = 0x40U, qlen = 0x1aU;
#endif
printf("batch_target %u, skb_queue_len %u, rx_target %u\n", rx_target - 
(req_prod_pvt - rsp_cons), qlen, rx_target);
printf("nr_ents %u\n", nr_ents);
printf("req_prod_pvt - rsp_cons %u\n", req_prod_pvt - rsp_cons);
printf("req_prod_pvt - req_prod %u\n", req_prod_pvt - req_prod);
printf("%u\n", nr_ents - (req_prod_pvt - rsp_cons));
printf("%u\n", nr_ents - (req_prod_pvt - rsp_cons));
f();
return 0;
}


pgpUg7lnDX9qJ.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

[Takashi Iwai]

On Wed, 25 Apr 2018 10:26:34 +0200,
Oleksandr Andrushchenko wrote:
> 
> On 04/24/2018 07:23 PM, Oleksandr Andrushchenko wrote:
> > On 04/24/2018 06:02 PM, Takashi Iwai wrote:
> >> On Tue, 24 Apr 2018 16:58:43 +0200,
> >> Oleksandr Andrushchenko wrote:
> >>> On 04/24/2018 05:35 PM, Takashi Iwai wrote:
>  On Tue, 24 Apr 2018 16:29:15 +0200,
>  Oleksandr Andrushchenko wrote:
> > On 04/24/2018 05:20 PM, Takashi Iwai wrote:
> >> On Mon, 16 Apr 2018 08:24:51 +0200,
> >> Oleksandr Andrushchenko wrote:
> >>> +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id)
> >>> +{
> >>> +    struct xen_snd_front_evtchnl *channel = dev_id;
> >>> +    struct xen_snd_front_info *front_info = channel->front_info;
> >>> +    struct xensnd_resp *resp;
> >>> +    RING_IDX i, rp;
> >>> +    unsigned long flags;
> >>> +
> >>> +    if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED))
> >>> +    return IRQ_HANDLED;
> >>> +
> >>> +    spin_lock_irqsave(_info->io_lock, flags);
> >>> +
> >>> +again:
> >>> +    rp = channel->u.req.ring.sring->rsp_prod;
> >>> +    /* ensure we see queued responses up to rp */
> >>> +    rmb();
> >>> +
> >>> +    for (i = channel->u.req.ring.rsp_cons; i != rp; i++) {
> >> I'm not familiar with Xen stuff in general, but through a quick
> >> glance, this kind of code worries me a bit.
> >>
> >> If channel->u.req.ring.rsp_cons has a bogus number, this may
> >> lead to a
> >> very long loop, no?  Better to have a sanity check of the ring
> >> buffer
> >> size.
> > In this loop I have:
> > resp = RING_GET_RESPONSE(>u.req.ring, i);
> > and the RING_GET_RESPONSE macro is designed in the way that
> > it wraps around when *i* in the question gets bigger than
> > the ring size:
> >
> > #define RING_GET_REQUEST(_r, _idx)                    \
> >       (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req))
> >
> > So, even if the counter has a bogus number it will not last long
>  Hm, this prevents from accessing outside the ring buffer, but does it
>  change the loop behavior?
> >>> no, it doesn't
>  Suppose channel->u.req.ring_rsp_cons = 1, and rp = 0, the loop below
>  would still consume the whole 32bit counts, no?
> 
>  for (i = channel->u.req.ring.rsp_cons; i != rp; i++) {
>      resp = RING_GET_RESPONSE(>u.req.ring, i);
>      ...
>  }
> >>> You are right here and the comment is totally valid.
> >>> I'll put an additional check like here [1] and here [2]
> >>> Will this address your comment?
> >> Yep, this kind of sanity checks should work.
> >>
> > Great, will implement the checks this way then
> Well, after thinking a bit more on that and chatting on #xendevel IRC
> with Juergen (he is on CC list), it seems that the way the code is now
> it is all fine without the checks: the assumption here is that
> the backend is trusted to always write sane values to the ring counters,
> thus no overflow checks on frontend side are required.
> Even if I implement the checks then I have no means to recover, but
> just print
> an error message and bail out not handling any responses.
> This is probably why the checks [1] and [2] are only implemented for the
> backend side and there are no such macros for the frontend side.
> 
> Takashi, please let me know if the above sounds reasonable and
> addresses your comments.

If it's guaranteed to work, that's OK.
But maybe it's worth to comment for readers.


thanks,

Takashi

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

Re: [Xen-devel] bogus wrap check in xen-netback

[Wei Liu]

On Wed, Apr 25, 2018 at 09:39:24AM +0200, Olaf Hering wrote:
> Am Wed, 25 Apr 2018 09:28:38 +0200
> schrieb Juergen Gross :
> 
> > Why? (u16)0 - (u16)65400 == 136
> 
> My helloworld.c shows that ushort gets promoted to uint, unless it is done 
> like that:
> 
> -   if (queue->tx.sring->req_prod - queue->tx.req_cons >
> -   XEN_NETIF_TX_RING_SIZE) {
> +   idx = queue->tx.sring->req_prod - queue->tx.req_cons; 
> +   if ( idx > XEN_NETIF_TX_RING_SIZE) {

Do you have the full diff of your changes? I don't follow why integer
conversion works differently if you write the code like this. As far as
I can tell the type of LHS didn't change.

Wei.

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

Re: [Xen-devel] [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

[Oleksandr Andrushchenko]

On 04/24/2018 07:23 PM, Oleksandr Andrushchenko wrote:

On 04/24/2018 06:02 PM, Takashi Iwai wrote:

On Tue, 24 Apr 2018 16:58:43 +0200,
Oleksandr Andrushchenko wrote:

On 04/24/2018 05:35 PM, Takashi Iwai wrote:

On Tue, 24 Apr 2018 16:29:15 +0200,
Oleksandr Andrushchenko wrote:

On 04/24/2018 05:20 PM, Takashi Iwai wrote:

On Mon, 16 Apr 2018 08:24:51 +0200,
Oleksandr Andrushchenko wrote:

+static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id)
+{
+    struct xen_snd_front_evtchnl *channel = dev_id;
+    struct xen_snd_front_info *front_info = channel->front_info;
+    struct xensnd_resp *resp;
+    RING_IDX i, rp;
+    unsigned long flags;
+
+    if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED))
+    return IRQ_HANDLED;
+
+    spin_lock_irqsave(_info->io_lock, flags);
+
+again:
+    rp = channel->u.req.ring.sring->rsp_prod;
+    /* ensure we see queued responses up to rp */
+    rmb();
+
+    for (i = channel->u.req.ring.rsp_cons; i != rp; i++) {

I'm not familiar with Xen stuff in general, but through a quick
glance, this kind of code worries me a bit.

If channel->u.req.ring.rsp_cons has a bogus number, this may lead 
to a
very long loop, no?  Better to have a sanity check of the ring 
buffer

size.

In this loop I have:
resp = RING_GET_RESPONSE(>u.req.ring, i);
and the RING_GET_RESPONSE macro is designed in the way that
it wraps around when *i* in the question gets bigger than
the ring size:

#define RING_GET_REQUEST(_r, _idx)                    \
      (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req))

So, even if the counter has a bogus number it will not last long

Hm, this prevents from accessing outside the ring buffer, but does it
change the loop behavior?

no, it doesn't

Suppose channel->u.req.ring_rsp_cons = 1, and rp = 0, the loop below
would still consume the whole 32bit counts, no?

for (i = channel->u.req.ring.rsp_cons; i != rp; i++) {
    resp = RING_GET_RESPONSE(>u.req.ring, i);
    ...
}

You are right here and the comment is totally valid.
I'll put an additional check like here [1] and here [2]
Will this address your comment?

Yep, this kind of sanity checks should work.


Great, will implement the checks this way then

Well, after thinking a bit more on that and chatting on #xendevel IRC
with Juergen (he is on CC list), it seems that the way the code is now
it is all fine without the checks: the assumption here is that
the backend is trusted to always write sane values to the ring counters,
thus no overflow checks on frontend side are required.
Even if I implement the checks then I have no means to recover, but just 
print

an error message and bail out not handling any responses.
This is probably why the checks [1] and [2] are only implemented for the
backend side and there are no such macros for the frontend side.

Takashi, please let me know if the above sounds reasonable and
addresses your comments.

thanks,

Takashi

Thank you,
Oleksandr

Takashi

Thank you,
Oleksandr

[1]
https://elixir.bootlin.com/linux/v4.17-rc2/source/drivers/block/xen-blkback/blkback.c#L1127 


[2]
https://elixir.bootlin.com/linux/v4.17-rc2/source/drivers/block/xen-blkback/blkback.c#L1135 








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

Re: [Xen-devel] [PATCH v2 05/10] xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume

[Julien Grall]

On 04/24/2018 03:50 PM, Mirela Simonovic wrote:

Hi Julien,


Hi,

Sorry I forgot to answer to some part of the e-mail.


On Mon, Apr 23, 2018 at 1:28 PM, Julien Grall  wrote:

Hi Mirela,
On 20/04/18 13:25, Mirela Simonovic wrote:

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d43c3aa896..9bb62c13cd 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1451,13 +1451,21 @@ err:
   return page;
   }
   -static void __init setup_virt_paging_one(void *data)
+static void setup_virt_paging_one(void *data)
   {
   unsigned long val = (unsigned long)data;
   WRITE_SYSREG32(val, VTCR_EL2);
   isb();
   }
   +/* VTCR value to be configured by all CPUs. Set only once by the boot
CPU */
+static unsigned long __read_mostly vtcr_value;



VTCR is a register, so the type should be represented in term of bits (i.e
uint*_t).


I followed the type used in setup_virt_paging() and it's unsigned
long. However, the spec says the VTCR_EL2 is 32-bit register, meaning
that in the current implementation the type is not correct.
If I want the type to be correct in this patch Xen will not compile.
Are you suggesting to fix the type in existing implementation?


The unsigned long is just a workaround to avoid an extra variable for 
the cast. As you introduce a static variable, then the cast become 
unnecessary.







+
+void setup_virt_paging_secondary(void)
+{
+setup_virt_paging_one((void *)vtcr_value);



That's fairly ugly. Is there any way to rework the interface? For instance,
because you have a static variable which contain the VTCR, you could just
use the variable in setup_virt_paging one.

 I 
If the argument provided to setup_virt_paging_one() is NULL within the

setup_virt_paging_one() I configure saved static vtcr_value? If that
is what you meant it was submitted in previous version of this patch
:)
Are you suggesting to revert the change to v1?


I would suggest a mix between v1 and v2. Something like:

static uint64_t vtcr;

static setup_init_paging_one(void *data)
{
   WRITE_SYSREG(vtcr, VTRC_EL2);
   [...]
}
r

void __init setup_virt_paging(...)
{
vtcr = val;
}

Potentially, you could drop val and use vtcr everywhere in 
setup_virt_paging().


Cheers,

--
Julien Grall

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

Re: [Xen-devel] 4.11.0 RC1 panic

[Andrew Cooper]

On 25/04/2018 07:58, Jan Beulich wrote:
 On 24.04.18 at 18:06,  wrote:
>> Hello,
>> I tested xen 4.11.0 rc1 with NetBSD as dom0.
>> I could boot a NetBSD PV domU without problem, but at shutdown time 
>> (poweroff
>> in the domU), I got a Xen panic:
>> (XEN) Assertion 'cpu < nr_cpu_ids' failed at 
>> ...1/work/xen-4.11.0-rc1/xen/include/xen/cpumask.h:97
>>
>> A xl destroy instead of poweroff gives the same result.
>>
>> This happens with both 32bitsPAE and 64bits domU. This doens't seem to
>> happen with HVM domUs.
>>
>> Attached are a cut-n-paste of the panic, and the output of xl demsg.
> Without line numbers associated with at least the top stack trace entry
> I can only guess what it might be - could you give the patch below a try?
> (This may not be the final patch, as I'm afraid there may be some race
> here, but I'd have to work this out later.)
>
> Jan
>
> --- unstable.orig/xen/arch/x86/mm.c
> +++ unstable/xen/arch/x86/mm.c
> @@ -1255,7 +1255,7 @@ void put_page_from_l1e(l1_pgentry_t l1e,
>  {
>  for_each_vcpu ( pg_owner, v )
>  {
> -if ( pv_destroy_ldt(v) )
> +if ( pv_destroy_ldt(v) && v->dirty_cpu != VCPU_CPU_CLEAN )
>  flush_tlb_mask(cpumask_of(v->dirty_cpu));
>  }
>  }
>

Manuel: As a tangentially related question, does NetBSD ever try to page
out its LDT?

I'm fairly sure this particular bit of code exists solely for the
Windows XP port to PV guests.  The code itself is broken as far as the
"feature" goes (as it only works on present => not present PTE changes,
and not for other PTE permissions changes which would also drop the
segdesc typeref), and dropping it would remove one vcpu scalability
limitation for PV guests.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.11] x86/SVM: Fix intercepted {RD, WR}MSR for the SYS{CALL, ENTER} MSRs

[Razvan Cojocaru]

On 04/25/2018 09:49 AM, Jan Beulich wrote:
 On 24.04.18 at 20:51,  wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr, 
>> uint64_t *msr_content)
>>  switch ( msr )
>>  {
>>  case MSR_IA32_SYSENTER_CS:
>> +case MSR_IA32_SYSENTER_ESP:
>> +case MSR_IA32_SYSENTER_EIP:
> 
> These three do not require sync-ing, as their values aren't read from the 
> VMCB.
> (They do require sync-ing on the write path).
> 
> I also don't think this is going to fully resolve Razvan's issue (not the 
> least
> because the code paths you adjust aren't involved in his scenario): As
> pointed out in a private mail, I think vmcb_in_sync needs to start out as
> true for a vCPU, and may need setting to true upon context set and/or
> reset/init emulation.

Doing arch_svm->vmcb_in_sync = 1; in construct_vmcb() does solve the
issue. I can't unfortunately test if it also needs setting in other
places as our internal patches still need some work so introspection is
not yet fully functional on SVM (mem_access events specifically are a
bit of a problem).


Thanks,
Razvan

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

[Xen-devel] [xen-4.7-testing test] 122382: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  broken
 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 122131
 build-armhf   5 host-build-prep  fail REGR. vs. 122131

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  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-vhd   1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122131
 test-xtf-amd64-amd64-5  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122131
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122131
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122131
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122131
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122131
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122131
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122131
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122131
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122131
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  2fbc00615061d8931acfd2908426ba5fa0132ca3
baseline version:
 xen  9680710bed1c174ced7a170cb94e30b4ae4fff5e

Last test of basis   122131  2018-04-09 10:53:16 Z   15 days
Testing same since   122353  2018-04-23 11:05:56 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Kevin Tian 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  broken  
 

Re: [Xen-devel] [PATCH for-4.11] x86/SVM: Fix intercepted {RD, WR}MSR for the SYS{CALL, ENTER} MSRs

[Andrew Cooper]

On 25/04/2018 07:49, Jan Beulich wrote:
 On 24.04.18 at 20:51,  wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr, 
>> uint64_t *msr_content)
>>  switch ( msr )
>>  {
>>  case MSR_IA32_SYSENTER_CS:
>> +case MSR_IA32_SYSENTER_ESP:
>> +case MSR_IA32_SYSENTER_EIP:
> These three do not require sync-ing, as their values aren't read from the 
> VMCB.
> (They do require sync-ing on the write path).

See the TODO list in the patch comment.  This is a quirk of cross-vendor
logic being used unnecessarily in the common case, and isn't going to
remain like this.

> I also don't think this is going to fully resolve Razvan's issue (not the 
> least
> because the code paths you adjust aren't involved in his scenario): As
> pointed out in a private mail, I think vmcb_in_sync needs to start out as
> true for a vCPU, and may need setting to true upon context set and/or
> reset/init emulation.

No - it wont, but its obviously broken and will be the second bug to be
hit by introspection, when interception of these MSRs is active.

It just so happened that it was the easier issue to get started with.

~Andrew

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

Re: [Xen-devel] bogus wrap check in xen-netback

[Olaf Hering]

Am Wed, 25 Apr 2018 09:28:38 +0200
schrieb Juergen Gross :

> Why? (u16)0 - (u16)65400 == 136

My helloworld.c shows that ushort gets promoted to uint, unless it is done like 
that:

-   if (queue->tx.sring->req_prod - queue->tx.req_cons >
-   XEN_NETIF_TX_RING_SIZE) {
+   idx = queue->tx.sring->req_prod - queue->tx.req_cons; 
+   if ( idx > XEN_NETIF_TX_RING_SIZE) {

Olaf


pgpAzwssvPxQm.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] bogus wrap check in xen-netback

[Juergen Gross]

On 25/04/18 09:19, Olaf Hering wrote:
> With commit 48856286b64e ("xen/netback: shutdown the ring if it contains 
> garbage.") a new check was added to xen-netback, which triggers for me.
> 
> Since there are bugs in ring buffer handling I tried to trigger them earlier 
> by changing RING_IDX from u32 to u16. Now I found another one, and I wonder 
> if the error below could potentially also hit with u32:
> 
> ...
> [  624.186492] br0: port 3(vif2.0) entered forwarding state
> [  624.186522] br0: port 3(vif2.0) entered forwarding state
> [  680.865398] vif vif-1-0 vif1.0: Impossible number of requests. req_prod 0, 
> req_cons 65400, size 256
> [  680.865402] vif vif-1-0 vif1.0: fatal error; disabling device
> [  680.865495] br0: port 2(vif1.0) entered disabled state
> [  689.433849] vif vif-2-0 vif2.0: Impossible number of requests. req_prod 0, 
> req_cons 65527, size 256
> [  689.433857] vif vif-2-0 vif2.0: fatal error; disabling device
> [  689.433945] br0: port 3(vif2.0) entered disabled state
> [  690.930512] pktgen: Packet Generator for packet performance testing. 
> Version: 2.75
> ...
> 
> What exactly is that check in xenvif_tx_build_gops trying to achieve? 
> Subtracting a non-zero value from zero will always create something larger 
> than XEN_NETIF_TX_RING_SIZE.

Why? (u16)0 - (u16)65400 == 136


Juergen

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

Re: [Xen-devel] [PATCH for-4.11] x86/SVM: Fix intercepted {RD, WR}MSR for the SYS{CALL, ENTER} MSRs

[Jan Beulich]

>>> On 24.04.18 at 20:51,  wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr, 
> uint64_t *msr_content)
>  switch ( msr )
>  {
>  case MSR_IA32_SYSENTER_CS:
> +case MSR_IA32_SYSENTER_ESP:
> +case MSR_IA32_SYSENTER_EIP:

These three do not require sync-ing, as their values aren't read from the VMCB.
(They do require sync-ing on the write path).

I also don't think this is going to fully resolve Razvan's issue (not the least
because the code paths you adjust aren't involved in his scenario): As
pointed out in a private mail, I think vmcb_in_sync needs to start out as
true for a vCPU, and may need setting to true upon context set and/or
reset/init emulation.

Jan



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

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Daniel Vetter]

On Wed, Apr 25, 2018 at 09:07:07AM +0300, Oleksandr Andrushchenko wrote:
> On 04/24/2018 11:35 PM, Dongwon Kim wrote:
> > Had a meeting with Daniel and talked about bringing out generic
> > part of hyper-dmabuf to the userspace, which means we most likely
> > reuse IOCTLs defined in xen-zcopy for our use-case if we follow
> > his suggestion.
> I will still have kernel side API, so backends/frontends implemented
> in the kernel can access that functionality as well.
> > 
> > So assuming we use these IOCTLs as they are,
> > Several things I would like you to double-check..
> > 
> > 1. returning gref as is to the user space is still unsafe because
> > it is a constant, easy to guess and any process that hijacks it can easily
> > exploit the buffer. So I am wondering if it's possible to keep dmabuf-to
> > -gref or gref-to-dmabuf in kernel space and add other layers on top
> > of those in actual IOCTLs to add some safety.. We introduced flink like
> > hyper_dmabuf_id including random number but many says even that is still
> > not safe.
> Yes, it is generally unsafe. But even if we have implemented
> the approach you have in hyper-dmabuf or similar, what stops
> malicious software from doing the same with the existing gntdev UAPI?
> No need to brute force new UAPI if there is a simpler one.
> That being said, I'll put security aside at the first stage,
> but of course we can start investigating ways to improve
> (I assume you already have use-cases where security issues must
> be considered, so, probably you can tell more on what was investigated
> so far).

Maybe a bit more context here:

So in graphics we have this old flink approach for buffer sharing with
processes, and it's unsafe because way too easy to guess the buffer
handles. And anyone with access to the graphics driver can then import
that buffer object. We switched to file descriptor passing to make sure
only the intended recipient can import a buffer.

So at the vm->vm level it sounds like grefs are safe, because they're only
for a specific other guest (or sets of guests, not sure about). That means
security is only within the OS. For that you need to make sure that
unpriviledge userspace simply can't ever access a gref. If that doesn't
work out, then I guess we should improve the xen gref stuff to have a more
secure cookie.

> > 2. maybe we could take hypervisor-independent process (e.g. SGT<->page)
> > out of xen-zcopy and put those in a new helper library.
> I believe this can be done, but at the first stage I would go without
> that helper library, so it is clearly seen what can be moved to it later
> (I know that you want to run ACRN as well, but can I run it on ARM? ;)

There's already helpers for walking sgtables and adding pages/enumerating
pages. I don't think we need more.

> > 3. please consider the case where original DMA-BUF's first offset
> > and last length are not 0 and PAGE_SIZE respectively. I assume current
> > xen-zcopy only supports page-aligned buffer with PAGE_SIZE x n big.
> Hm, what is the use-case for that?

dma-buf is always page-aligned. That's a hard constraint of the linux
dma-buf interface spec.
-Daniel

> > thanks,
> > DW
> Thank you,
> Oleksandr
> > On Tue, Apr 24, 2018 at 02:59:39PM +0300, Oleksandr Andrushchenko wrote:
> > > On 04/24/2018 02:54 PM, Daniel Vetter wrote:
> > > > On Mon, Apr 23, 2018 at 03:10:35PM +0300, Oleksandr Andrushchenko wrote:
> > > > > On 04/23/2018 02:52 PM, Wei Liu wrote:
> > > > > > On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko 
> > > > > > wrote:
> > > > > > > > >   the gntdev.
> > > > > > > > > 
> > > > > > > > > I think this is generic enough that it could be implemented 
> > > > > > > > > by a
> > > > > > > > > device not tied to Xen. AFAICT the hyper_dma guys also wanted
> > > > > > > > > something similar to this.
> > > > > > > > You can't just wrap random userspace memory into a dma-buf. 
> > > > > > > > We've just had
> > > > > > > > this discussion with kvm/qemu folks, who proposed just that, 
> > > > > > > > and after a
> > > > > > > > bit of discussion they'll now try to have a driver which just 
> > > > > > > > wraps a
> > > > > > > > memfd into a dma-buf.
> > > > > > > So, we have to decide either we introduce a new driver
> > > > > > > (say, under drivers/xen/xen-dma-buf) or extend the existing
> > > > > > > gntdev/balloon to support dma-buf use-cases.
> > > > > > > 
> > > > > > > Can anybody from Xen community express their preference here?
> > > > > > > 
> > > > > > Oleksandr talked to me on IRC about this, he said a few IOCTLs need 
> > > > > > to
> > > > > > be added to either existing drivers or a new driver.
> > > > > > 
> > > > > > I went through this thread twice and skimmed through the relevant
> > > > > > documents, but I couldn't see any obvious pros and cons for either
> > > > > > approach. So I don't really have an opinion on this.
> > > > > > 
> > > > > > But, assuming if implemented in existing drivers, those IOCTLs need 
> > > > > > 

[Xen-devel] [libvirt test] 122383: trouble: broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw broken
 test-armhf-armhf-libvirt-raw  4 host-install(4)broken REGR. vs. 122344

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122344
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122344
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass

version targeted for testing:
 libvirt  6009d5124f1045b38bc499b8a171e5fd7f304a8a
baseline version:
 libvirt  4ac43975d514fca900896ddb3e54ef9f145920fe

Last test of basis   122344  2018-04-17 04:20:20 Z8 days
Testing same since   122383  2018-04-24 04:19:50 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Clementine Hayat 
  Daniel P. Berrangé 
  Erik Skultety 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Marek Marczykowski-Górecki 
  Martin Kletzander 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Peter Krempa 
  Pino Toscano 
  Rainer Müller 
  Richard W.M. Jones 
  Sukrit Bhatnagar 
  Viktor Mihajlovski 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-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-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

On 04/24/2018 11:35 PM, Dongwon Kim wrote:

Had a meeting with Daniel and talked about bringing out generic
part of hyper-dmabuf to the userspace, which means we most likely
reuse IOCTLs defined in xen-zcopy for our use-case if we follow
his suggestion.

I will still have kernel side API, so backends/frontends implemented
in the kernel can access that functionality as well.


So assuming we use these IOCTLs as they are,
Several things I would like you to double-check..

1. returning gref as is to the user space is still unsafe because
it is a constant, easy to guess and any process that hijacks it can easily
exploit the buffer. So I am wondering if it's possible to keep dmabuf-to
-gref or gref-to-dmabuf in kernel space and add other layers on top
of those in actual IOCTLs to add some safety.. We introduced flink like
hyper_dmabuf_id including random number but many says even that is still
not safe.

Yes, it is generally unsafe. But even if we have implemented
the approach you have in hyper-dmabuf or similar, what stops
malicious software from doing the same with the existing gntdev UAPI?
No need to brute force new UAPI if there is a simpler one.
That being said, I'll put security aside at the first stage,
but of course we can start investigating ways to improve
(I assume you already have use-cases where security issues must
be considered, so, probably you can tell more on what was investigated
so far).


2. maybe we could take hypervisor-independent process (e.g. SGT<->page)
out of xen-zcopy and put those in a new helper library.

I believe this can be done, but at the first stage I would go without
that helper library, so it is clearly seen what can be moved to it later
(I know that you want to run ACRN as well, but can I run it on ARM? ;)


3. please consider the case where original DMA-BUF's first offset
and last length are not 0 and PAGE_SIZE respectively. I assume current
xen-zcopy only supports page-aligned buffer with PAGE_SIZE x n big.

Hm, what is the use-case for that?

thanks,
DW

Thank you,
Oleksandr

On Tue, Apr 24, 2018 at 02:59:39PM +0300, Oleksandr Andrushchenko wrote:

On 04/24/2018 02:54 PM, Daniel Vetter wrote:

On Mon, Apr 23, 2018 at 03:10:35PM +0300, Oleksandr Andrushchenko wrote:

On 04/23/2018 02:52 PM, Wei Liu wrote:

On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote:

  the gntdev.

I think this is generic enough that it could be implemented by a
device not tied to Xen. AFAICT the hyper_dma guys also wanted
something similar to this.

You can't just wrap random userspace memory into a dma-buf. We've just had
this discussion with kvm/qemu folks, who proposed just that, and after a
bit of discussion they'll now try to have a driver which just wraps a
memfd into a dma-buf.

So, we have to decide either we introduce a new driver
(say, under drivers/xen/xen-dma-buf) or extend the existing
gntdev/balloon to support dma-buf use-cases.

Can anybody from Xen community express their preference here?


Oleksandr talked to me on IRC about this, he said a few IOCTLs need to
be added to either existing drivers or a new driver.

I went through this thread twice and skimmed through the relevant
documents, but I couldn't see any obvious pros and cons for either
approach. So I don't really have an opinion on this.

But, assuming if implemented in existing drivers, those IOCTLs need to
be added to different drivers, which means userspace program needs to
write more code and get more handles, it would be slightly better to
implement a new driver from that perspective.

If gntdev/balloon extension is still considered:

All the IOCTLs will be in gntdev driver (in current xen-zcopy terminology):

I was lazy to change dumb to dma-buf, so put this notice ;)

  - DRM_ICOTL_XEN_ZCOPY_DUMB_FROM_REFS
  - DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS
  - DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE

s/DUMB/DMA_BUF/ please. This is generic dma-buf, it has nothing to do with
the dumb scanout buffer support in the drm/gfx subsystem. This here can be
used for any zcopy sharing among guests (as long as your endpoints
understands dma-buf, which most relevant drivers do).

Of course, please see above

-Daniel


Balloon driver extension, which is needed for contiguous/DMA
buffers, will be to provide new *kernel API*, no UAPI is needed.


Wei.

Thank you,
Oleksandr
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



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