[Xen-devel] [ovmf test] 94104: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

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

version targeted for testing:
 ovmf 08222019067e168c7f9b2b378b01eac9705e9187
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  157 days
Failing since 65593  2015-12-08 23:44:51 Z  157 days  256 attempts
Testing same since94104  2016-05-13 15:32:17 Z0 days1 attempts


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93989
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93989
 build-armhf   5 xen-build fail REGR. vs. 93989
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail in 94030 REGR. vs. 93989
 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 94055 REGR. 
vs. 93989
 build-armhf-libvirt   5 libvirt-buildfail in 94055 REGR. vs. 93989

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qcow2 3 host-install(3)  broken in 94055 pass in 94079
 test-amd64-amd64-pygrub   3 host-install(3)  broken in 94055 pass in 94079
 test-armhf-armhf-xl-arndale   6 xen-boot   fail in 94030 pass in 94055
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 94030 pass in 94079
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 94030
 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail pass in 
94055

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

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

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

[Meng Xu]

Hi Julien and Dushyant,

>>>
 (XEN) DOM0: [0.00] irq: no irq domain found for
 /interrupt-controller !
 (XEN) DOM0: [0.00] irq: no irq domain found for
 /interrupt-controller !
 (XEN) DOM0: [0.00] irq: no irq domain found for
 /interrupt-controller !
 (XEN) DOM0: [0.00] arch_timer: No interrupt available, giving up
>>>
>>>
>>>
>>> It looks like to me that Xen is not recreating the device-tree correctly.
>>> I
>>> would look into the kernel to find what is expected.
>>
>>
>> This looks like a possible bug (or some missing feature) in Xen's
>> device tree creation which could
>> take some time to handle, so if I could be of any more help to you
>> with this issue please let me know.
>
>
> There was a conversation on #xen-arm few days ago about this problem.

Is there a way that we can see the conversation on #xen-arm?
I hope to better understand the problem.

> Xen doesn't correctly recreate the GIC node which result in a loop between
> the interrupt controller. Can you try the below patch?
>
> http://dev.ktemkin.com/misc/xenarm-gic-parents.patch

It seems this link is invalid now...
Has this patch been upstreamed?

Hi Dushyant,
Could you help repost this patch in this email if it's not that large?
(Since we used the same repo, which is IanC's, it may be even better
if you could kindly share the patch based on the tegra-tk1-jetson-v1
branch of Ian's repo.?)


Hi Julien,
Do you have some suggestions on how we can debug and fix the issue
related to the device tree?

I saw that there may still be some issues with the NVIDIA devices as
Dushyant described after he applied the patch.
Right now, I have the exact same board as Dushyant has. I think I may
encounter the exact same issue as he did. So I'm wondering if there is
some documentation/tutorial/notes that we can learn about how to debug
the issues.

Thank you both very much for your help and time!

Best Regards,

Meng

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

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  cd2cd109e7db3a7e689c20b8991d41115ed5bea6
baseline version:
 xen  c79fc6c4bee28b40948838a760b4aaadf6b5cd47

Last test of basis94021  2016-05-11 07:32:40 Z2 days
Failing since 94050  2016-05-12 02:19:56 Z1 days2 attempts
Testing same since94070  2016-05-13 03:24:04 Z0 days1 attempts


People who touched revisions under test:
  Doug Goldstein 
  George Dunlap 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Olaf Hering 
  Paul Durrant 
  Wei Liu 

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

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

[osstest service owner]

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

Failures and problems with tests :-(

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

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

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z   97 days
Testing same since93977  2016-05-10 11:09:16 Z3 days5 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

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

[Xen-devel] [xen-4.4-testing baseline-only test] 44413: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44413 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44413/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44355
 build-armhf   3 host-install(3) broken REGR. vs. 44355
 test-amd64-amd64-pv  17 guest-localmigrate/x10fail REGR. vs. 44355
 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 44355
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-installfail REGR. vs. 44355

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl  19 guest-start/debian.repeatfail   like 44355
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 44355
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 44355
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 44355

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

version targeted for testing:
 xen  ab6f8993136a10fee4336e0cbb90f491ce505212
baseline version:
 xen  24ebffa9f57a14b6f20376ae422b941715af9a4e

Last test of basis44355  2016-04-22 12:50:11 Z   21 days
Testing same since44413  2016-05-13 17:17:58 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

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

Re: [Xen-devel] [PATCH v2] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Matt Fleming]

(Including more folks, quoting entire patch)

On Thu, 12 May, at 08:19:54PM, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> The EFI DT parameters for bare metal are located under /chosen node,
> while for Xen Dom0 they are located under /hyperviosr/uefi node. These
> parameters under /chosen and /hyperviosr/uefi are not expected to appear
> at the same time.
> Parse these EFI parameters and initialize EFI like the way for bare
> metal except the runtime services because the runtime services for Xen
> Dom0 are available through hypercalls and they are always enabled. So it
> sets the EFI_RUNTIME_SERVICES flag if it finds /hyperviosr/uefi node and
> bails out in arm_enable_runtime_services() when EFI_RUNTIME_SERVICES
> flag is set already.
> 
> CC: Matt Fleming 
> Signed-off-by: Shannon Zhao 
> ---
> v2: rebase it on top of EFI and Xen next branch, add some comments to
> explain the codes. 
> ---
>  arch/arm/xen/enlighten.c   | 22 +++
>  drivers/firmware/efi/arm-runtime.c |  5 +++
>  drivers/firmware/efi/efi.c | 81 
> ++
>  3 files changed, 92 insertions(+), 16 deletions(-)
 
This looks good to me. Thanks for all the work Shannon.

Stefan, OK, let's figure out how to deal with this.

What I've done is merge xen/linux-next into the 'efi/xen-arm' topic
branch and applied this patch here,

  
https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen

Yes, the merge includes some Xen patches that are not actually needed
for any of the EFI patches, but Linus has complained about picking
random commits of a tree to merge. At least this way this is all the
Xen linux-next material.

If you're OK with this, and assuming no one else has any preferred
methods, I'll send out a pull request to tip over the weekend.

> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 13e3e9f..d4f36eb 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -15,7 +15,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -261,6 +263,19 @@ static int __init fdt_find_hyper_node(unsigned long 
> node, const char *uname,
>   !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
>   hyper_node.version = s + strlen(hyper_node.prefix);
>  
> + /*
> +  * Check if Xen supports EFI by checking whether there is the
> +  * "/hypervisor/uefi" node in DT. If so, runtime services are available
> +  * through proxy functions (e.g. in case of Xen dom0 EFI implementation
> +  * they call special hypercall which executes relevant EFI functions)
> +  * and that is why they are always enabled.
> +  */
> + if (IS_ENABLED(CONFIG_XEN_EFI)) {
> + if ((of_get_flat_dt_subnode_by_name(node, "uefi") > 0) &&
> + !efi_runtime_disabled())
> + set_bit(EFI_RUNTIME_SERVICES, );
> + }
> +
>   return 0;
>  }
>  
> @@ -352,6 +367,13 @@ static int __init xen_guest_init(void)
>   return -ENODEV;
>   }
>  
> + /*
> +  * The fdt parsing codes have set EFI_RUNTIME_SERVICES if Xen EFI
> +  * parameters are found. Force enable runtime services.
> +  */
> + if (efi_enabled(EFI_RUNTIME_SERVICES))
> + xen_efi_runtime_setup();
> +
>   shared_info_page = (struct shared_info *)get_zeroed_page(GFP_KERNEL);
>  
>   if (!shared_info_page) {
> diff --git a/drivers/firmware/efi/arm-runtime.c 
> b/drivers/firmware/efi/arm-runtime.c
> index 17ccf0a..c394b81 100644
> --- a/drivers/firmware/efi/arm-runtime.c
> +++ b/drivers/firmware/efi/arm-runtime.c
> @@ -107,6 +107,11 @@ static int __init arm_enable_runtime_services(void)
>   return 0;
>   }
>  
> + if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> + pr_info("EFI runtime services access via paravirt.\n");
> + return 0;
> + }
> +
>   pr_info("Remapping and enabling EFI services.\n");
>  
>   mapsize = efi.memmap.map_end - efi.memmap.map;
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 05509f3..1c6f9dd 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -472,12 +472,14 @@ device_initcall(efi_load_efivars);
>   FIELD_SIZEOF(struct efi_fdt_params, field) \
>   }
>  
> -static __initdata struct {
> +struct params {
>   const char name[32];
>   const char propname[32];
>   int offset;
>   int size;
> -} dt_params[] = {
> +};
> +
> +static __initdata struct params fdt_params[] = {
>   UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
>   UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
>   UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
> @@ -485,44 +487,91 @@ static __initdata struct {
>   UEFI_PARAM("MemMap Desc. 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  677b94f48763efd703cb80ea5e7badeff857de5d
baseline version:
 libvirt  e5aecc2f800e8e14edd561dc5af4f763f040d842

Last test of basis94018  2016-05-11 04:21:08 Z2 days
Failing since 94052  2016-05-12 04:23:09 Z1 days2 attempts
Testing same since94073  2016-05-13 04:20:16 Z0 days1 attempts


People who touched revisions under test:
  Christophe Fergeau 
  Daniel P. Berrange 
  Erik Skultety 
  John Ferlan 
  Ján Tomko 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=677b94f48763efd703cb80ea5e7badeff857de5d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' 

Re: [Xen-devel] [RFC 11/16] xen/arm: Detect silicon revision and set cap bits accordingly

[Konrad Rzeszutek Wilk]

> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 7a1b56b..aa7c5b1 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -24,6 +24,22 @@
>  
>  DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
>  
> +void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
> + const char *info)
> +{
> +int i;
> +
> +for ( i = 0; caps[i].matches; i++ )
> +{
> +if ( !caps[i].matches([i]) )
> +continue;
> +
> +if ( !cpus_have_cap(caps[i].capability) && caps[i].desc )
> +printk("%s: %s\n", info, caps[i].desc);

dprintk?


> +cpus_set_cap(caps[i].capability);
> +}
> +}
> +
>  /*
>   * Local variables:
>   * mode: C

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

Re: [Xen-devel] [PATCH V2] libxl: don't add cache mode for qdisk cdrom drives

[Jim Fehlig]

On 05/10/2016 04:06 AM, Stefano Stabellini wrote:
> On Mon, 9 May 2016, Wei Liu wrote:
>> On Thu, Apr 28, 2016 at 03:20:46PM -0600, Jim Fehlig wrote:
>>> qemu commit 91a097e7 forbids specifying cache mode for empty
>>> drives. Attempting to create a domain with an empty qdisk cdrom
>>> drive results in
>>>
>>> qemu-system-x86_64: -drive if=ide,index=1,readonly=on,media=cdrom,
>>>cache=writeback,id=ide-832: Must specify either driver or file
>>>
>> We need to fix this one way or another.
>>
>>> libxl only allows an empty 'target=' for cdroms. By default, cdroms
>>> are readonly (see the 'access' parameter in xl-disk-configuration.txt)
>>> and forced to readonly by any tools (e.g. xl) using libxlutil's
>>> xlu_disk_parse() function. With cdroms always marked readonly,
>>> explicitly specifying the cache mode for cdrom drives can be dropped.
>>> The drive's 'readonly=on' option can also be set unconditionally.
>>>
>>> Signed-off-by: Jim Fehlig 
>> CC Stefano who made the change to use writeback in
>> e9a327bbbcab127625b0917a2780cb3601a81d01 . Also CC Anthony.
>>
>> Ian, Stefano and Anthony, do you have opinion on this patch?
> It looks good to me. We could consider to backport it, given that we
> only have a loose relationship with QEMU and older versions of Xen could
> end up running with newer versions of QEMU.

Wei,

Will this patch make 4.7? It allows empty cdroms with freshly released QEMU 2.6 
:-).

Regards,
Jim


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

[Xen-devel] [TESTDAY] Test report

[Edgar E. Iglesias]

* Hardware: ZCU102 ZynqMP board
* Software: Rolled my own dom0 linux
* Tested: Start dom0

The test fails with the following error:
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 0008
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x002000-0x004000 (512MB)
(XEN) Grant table range: 0x007fe0-0x007fe5f000
(XEN) smmu: /amba/smmu@fd80: d0: p2maddr 0x7ff64000
(XEN) Device tree generation failed (-22).

It's the PCIe node that is causing trouble, the bindings are here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt

It's that inner interrupt-controller node that is causing problems as
Xen/ARM only supports one interrupt-controller node (IIUC).

Disabling the pcie node for zynqmp boards gets dom0 to boot (obviously
without PCIe support).

Does it make sense to try to fix this problem this late inte the
release cycle? (I can have a closer look and propose a possible fix
for discussion)

Or should we disable the PCIe for ZynqMP for now and try to fix this
properly for 4.8?

Any ideas/suggestions?

Best regards,
Edgar

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

Re: [Xen-devel] [RFC 09/16] xen/arm: arm64: Add helpers to decode and encode branch instructions

[Konrad Rzeszutek Wilk]

> diff --git a/xen/include/asm-arm/arm64/insn.h 
> b/xen/include/asm-arm/arm64/insn.h
> new file mode 100644
> index 000..cfcdbe9
> --- /dev/null
> +++ b/xen/include/asm-arm/arm64/insn.h
> @@ -0,0 +1,72 @@
> +/*
> + * Copyright (C) 2013 Huawei Ltd.
> + * Author: Jiang Liu 
> + *
> + * Copyright (C) 2014 Zi Shen Lim 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +#ifndef __ARCH_ARM_ARM64_INSN
> +#define __ARCH_ARM_ARM64_INSN
> +
> +#include 
> +#include 
> +#include 
> +
> +enum aarch64_insn_imm_type {
> + AARCH64_INSN_IMM_ADR,
> + AARCH64_INSN_IMM_26,
> + AARCH64_INSN_IMM_19,
> + AARCH64_INSN_IMM_16,
> + AARCH64_INSN_IMM_14,
> + AARCH64_INSN_IMM_12,
> + AARCH64_INSN_IMM_9,
> + AARCH64_INSN_IMM_7,
> + AARCH64_INSN_IMM_6,
> + AARCH64_INSN_IMM_S,
> + AARCH64_INSN_IMM_R,
> + AARCH64_INSN_IMM_MAX
> +};
> +
> +#define  __AARCH64_INSN_FUNCS(abbr, mask, val)   \
> +static always_inline bool_t aarch64_insn_is_##abbr(u32 code) \
> +{ return (code & (mask)) == (val); } \
> +static always_inline u32 aarch64_insn_get_##abbr##_value(void) \
> +{ return (val); }
> +
> +__AARCH64_INSN_FUNCS(b,  0xFC00, 0x1400)

This looks odd here but in the file the aligment is OK.
> +__AARCH64_INSN_FUNCS(bl, 0xFC00, 0x9400)
> +__AARCH64_INSN_FUNCS(cbz,0x7F00, 0x3400)
> +__AARCH64_INSN_FUNCS(cbnz,   0x7F00, 0x3500)
> +__AARCH64_INSN_FUNCS(tbz,0x7F00, 0x3600)
> +__AARCH64_INSN_FUNCS(tbnz,   0x7F00, 0x3700)
> +__AARCH64_INSN_FUNCS(bcond,  0xFF10, 0x5400)
> +
> +bool aarch64_insn_is_branch_imm(u32 insn);
> +
> +u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn);
> +u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
> +   u32 insn, u64 imm);

While this is off. I think you have tabs here instead of spaces?
> +
> +s32 aarch64_get_branch_offset(u32 insn);
> +u32 aarch64_set_branch_offset(u32 insn, s32 offset);
> +

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

Re: [Xen-devel] [RFC 10/16] xen/arm: Introduce alternative runtime patching

[Konrad Rzeszutek Wilk]

On Thu, May 05, 2016 at 05:34:19PM +0100, Julien Grall wrote:
> Some of the processor erratum will require to modify code sequence.
> As those modifications may impact the performance, they should only
> be enabled on affected cores. Furthermore, Xen may also want to take
> advantage of new hardware features coming up with v8.1 and v8.2.
> 
> This patch adds an infrastructure to patch Xen during boot time
> depending on the "features" available on the platform.
> 
> This code is based on the file arch/arm64/kernel/alternative.c in
> Linux 4.6-rc3. Any references to arm64 have been dropped to make the
> code as generic as possible.
> 
> Furthermore, in Xen the executable sections (.text and .init.text)
> are always mapped read-only and enforced by SCTLR.WNX. So it is not
> possible to directly patch Xen.

Is it not possible to temporarily 'unenforce' the SCTLR.WNX?

> 
> To by-pass this restriction, a temporary writeable mapping is made with
> vmap. This mapping will be used to write the new instructions.
> 
> Lastly, runtime patching is currently not necessary for ARM32. So the
> code is only enabled for ARM64.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/Kconfig  |   5 +
>  xen/arch/arm/Makefile |   1 +
>  xen/arch/arm/alternative.c| 217 
> ++
>  xen/arch/arm/setup.c  |   8 ++
>  xen/arch/arm/xen.lds.S|   7 ++
>  xen/include/asm-arm/alternative.h | 165 +
>  xen/include/asm-arm/arm64/insn.h  |  16 +++
>  7 files changed, 419 insertions(+)
>  create mode 100644 xen/arch/arm/alternative.c
>  create mode 100644 xen/include/asm-arm/alternative.h
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 6231cd5..9b3e66b 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -14,6 +14,7 @@ config ARM_64
>   def_bool y
>   depends on 64BIT
>   select HAS_GICV3
> +select ALTERNATIVE

Hard tabs, not spaces.
>  
>  config ARM
>   def_bool y
> @@ -46,6 +47,10 @@ config ACPI
>  config HAS_GICV3
>   bool
>  
> +# Select ALTERNATIVE if the architecture supports runtime patching
> +config ALTERNATIVE
> +bool

Ditto. 
> +
>  endmenu
>  
>  source "common/Kconfig"
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 9122f78..2d330aa 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -4,6 +4,7 @@ subdir-y += platforms
>  subdir-$(CONFIG_ARM_64) += efi
>  subdir-$(CONFIG_ACPI) += acpi
>  
> +obj-$(CONFIG_ALTERNATIVE) += alternative.o

This probably needs to be alternative.init.o ?
>  obj-y += bootfdt.o
>  obj-y += cpu.o
>  obj-y += cpufeature.o
> diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> new file mode 100644
> index 000..0a5d1c8
> --- /dev/null
> +++ b/xen/arch/arm/alternative.c
> @@ -0,0 +1,217 @@
> +/*
> + * alternative runtime patching
> + * inspired by the x86 version
> + *
> + * Copyright (C) 2014 ARM Ltd.

Not 2016?

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define __ALT_PTR(a,f)  (u32 *)((void *)&(a)->f + (a)->f)
> +#define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset)
> +#define ALT_REPL_PTR(a) __ALT_PTR(a, alt_offset)
> +
> +extern const struct alt_instr __alt_instructions[], __alt_instructions_end[];
> +
> +struct alt_region {
> +const struct alt_instr *begin;
> +const struct alt_instr *end;
> +};
> +
> +/*
> + * Check if the target PC is within an alternative block.
> + */
> +static bool_t branch_insn_requires_update(const struct alt_instr *alt,

__init?
> +  unsigned long pc)
> +{
> +unsigned long replptr;
> +
> +if ( is_active_kernel_text(pc) )
> +return 1;
> +
> +replptr = (unsigned long)ALT_REPL_PTR(alt);
> +if ( pc >= replptr && pc <= (replptr + alt->alt_len) )
> +return 0;
> +
> +/*
> + * Branching into *another* alternate sequence is doomed, and
> + * we're not even trying to fix it up.
> + */
> +BUG();
> +}
> +
> +static u32 get_alt_insn(const struct alt_instr *alt,
> +const u32 *insnptr, const u32 *altinsnptr)
> +{
> +u32 insn;
> +
> 

Re: [Xen-devel] [PATCH v4 0/4] arm64, xen: add xen_boot support into grup-mkconfig

[Konrad Rzeszutek Wilk]

On Tue, May 10, 2016 at 10:03:22PM +0800, fu@linaro.org wrote:
> From: Fu Wei 
> 
> This patchset add xen_boot support into grup-mkconfig for
> generating xen boot entrances automatically
> 

All of them look good to me.

Thanks!
> Also update the docs/grub.texi for new xen_boot commands.
> 
> This patchset has been tested on Foudation model with a bug fix:
> http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html
> 
> ChangeLog:
> v4: http://lists.gnu.org/archive/html/grub-devel/2016-05/
> according to the XSM loading mechanism of Xen(upstreamed),
> update the introduction of xen_module commands in docs/grub.texi
> 
> v3: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00314.html
> reorder the patches
> update the introduction of xen_module commands in docs/grub.texi
> 
> v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html
> add "--nounzip" option support in xen_module
> use "feature_xen_boot" instead of "grub_xen_boot"
> update the introduction of xen boot commands in docs/grub.texi
> 
> v1 :first upstream patchset:
> http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html
> 
> Fu Wei (4):
>   i386,xen: Add xen_hypervisor and xen_module aliases for i386
>   arm64: add "--nounzip" option support in xen_module command
>   * util/grub.d/20_linux_xen.in: Add xen_boot command support
>   arm64: update the introduction of xen boot commands in docs/grub.texi
> 
>  docs/grub.texi| 33 ++---
>  grub-core/loader/arm64/xen_boot.c | 17 +
>  grub-core/loader/i386/xen.c   |  7 +++
>  grub-core/normal/main.c   |  2 +-
>  util/grub.d/20_linux_xen.in   | 13 ++---
>  5 files changed, 45 insertions(+), 27 deletions(-)
> 
> -- 
> 2.5.5
> 
> 
> ___
> Grub-devel mailing list
> grub-de...@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

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

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

Along with the IVHD block type 10h, newer AMD platforms also come with
types 11h, which is a superset of the older one. Having multiple IVHD
block types in the same platform allows backward compatibility of newer
systems to work with existing drivers.  The driver should only parse
the highest-level (newest) type of IVHD block that it can support.
However, the current driver returns error when encounters with unknown
IVHD block type. This causes existing driver to unnecessarily fail IOMMU
initialization on new systems.

This patch introduces a new logic, which scans through IVRS table looking
for the highest-level supporsted IVHD block type. It also adds support
for the new IVHD block type 11h. More information about the IVHD type 11h
can be found in the AMD I/O Virtualization Technology (IOMMU) Specification
rev 2.62.

http://support.amd.com/TechDocs/48882_IOMMU.pdf

Signed-off-by: Suravee Suthikulpanit 
---
 xen/drivers/passthrough/amd/iommu_acpi.c  | 133 +-
 xen/drivers/passthrough/amd/iommu_init.c  |   6 +-
 xen/include/acpi/actbl2.h |   7 +-
 xen/include/asm-x86/amd-iommu.h   |   1 +
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |   1 +
 5 files changed, 103 insertions(+), 45 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c 
b/xen/drivers/passthrough/amd/iommu_acpi.c
index 79c1f8c..2a2d61b 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -821,13 +821,23 @@ static u16 __init parse_ivhd_device_special(
 return dev_length;
 }
 
+static inline int get_ivhd_header_size(const struct acpi_ivrs_hardware 
*ivhd_block)
+{
+if ( ivhd_block->header.type == ACPI_IVRS_TYPE_HARDWARE)
+return 24;
+if ( ivhd_block->header.type == ACPI_IVRS_TYPE_HARDWARE_11H)
+return 40;
+return 0;
+}
+
 static int __init parse_ivhd_block(const struct acpi_ivrs_hardware *ivhd_block)
 {
 const union acpi_ivhd_device *ivhd_device;
 u16 block_length, dev_length;
+int hdr_size = get_ivhd_header_size(ivhd_block) ;
 struct amd_iommu *iommu;
 
-if ( ivhd_block->header.length < sizeof(*ivhd_block) )
+if ( ivhd_block->header.length < hdr_size )
 {
 AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");
 return -ENODEV;
@@ -845,7 +855,7 @@ static int __init parse_ivhd_block(const struct 
acpi_ivrs_hardware *ivhd_block)
 }
 
 /* parse Device Entries */
-block_length = sizeof(*ivhd_block);
+block_length = hdr_size;
 while ( ivhd_block->header.length >=
 (block_length + sizeof(struct acpi_ivrs_de_header)) )
 {
@@ -901,7 +911,7 @@ static int __init parse_ivhd_block(const struct 
acpi_ivrs_hardware *ivhd_block)
 ivhd_block->header.length, block_length, iommu);
 break;
 default:
-AMD_IOMMU_DEBUG("IVHD Error: Invalid Device Type!\n");
+AMD_IOMMU_DEBUG("IVHD Error: %s: Invalid Device Type!\n", 
__func__);
 dev_length = 0;
 break;
 }
@@ -914,34 +924,6 @@ static int __init parse_ivhd_block(const struct 
acpi_ivrs_hardware *ivhd_block)
 return 0;
 }
 
-static int __init parse_ivrs_block(const struct acpi_ivrs_header *ivrs_block)
-{
-const struct acpi_ivrs_hardware *ivhd_block;
-const struct acpi_ivrs_memory *ivmd_block;
-
-switch ( ivrs_block->type )
-{
-case ACPI_IVRS_TYPE_HARDWARE:
-ivhd_block = container_of(ivrs_block, const struct acpi_ivrs_hardware,
-  header);
-return parse_ivhd_block(ivhd_block);
-
-case ACPI_IVRS_TYPE_MEMORY_ALL:
-case ACPI_IVRS_TYPE_MEMORY_ONE:
-case ACPI_IVRS_TYPE_MEMORY_RANGE:
-case ACPI_IVRS_TYPE_MEMORY_IOMMU:
-ivmd_block = container_of(ivrs_block, const struct acpi_ivrs_memory,
-  header);
-return parse_ivmd_block(ivmd_block);
-
-default:
-AMD_IOMMU_DEBUG("IVRS Error: Invalid Block Type!\n");
-return -ENODEV;
-}
-
-return 0;
-}
-
 static void __init dump_acpi_table_header(struct acpi_table_header *table)
 {
 int i;
@@ -978,6 +960,21 @@ static void __init dump_acpi_table_header(struct 
acpi_table_header *table)
 
 }
 
+#define to_ivhd_block(hdr) \
+( container_of(hdr, const struct acpi_ivrs_hardware, header) )
+#define to_ivmd_block(hdr) \
+(container_of(hdr, const struct acpi_ivrs_memory, header) )
+
+#define is_ivhd_block(x) \
+( x == ACPI_IVRS_TYPE_HARDWARE || \
+  x == ACPI_IVRS_TYPE_HARDWARE_11H )
+
+#define is_ivmd_block(x) \
+( x == ACPI_IVRS_TYPE_MEMORY_ALL || \
+  x == ACPI_IVRS_TYPE_MEMORY_ONE || \
+  x == ACPI_IVRS_TYPE_MEMORY_RANGE || \
+  x == ACPI_IVRS_TYPE_MEMORY_IOMMU )
+
 static int __init parse_ivrs_table(struct acpi_table_header *table)
 {
 const struct acpi_ivrs_header 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  4f6aea066fe2cf3bf4929d6dac1e558071566f73
baseline version:
 xen  cd2cd109e7db3a7e689c20b8991d41115ed5bea6

Last test of basis94060  2016-05-12 17:02:40 Z1 days
Testing same since94112  2016-05-13 18:02:38 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=4f6aea066fe2cf3bf4929d6dac1e558071566f73
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
4f6aea066fe2cf3bf4929d6dac1e558071566f73
+ branch=xen-unstable-smoke
+ revision=4f6aea066fe2cf3bf4929d6dac1e558071566f73
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x4f6aea066fe2cf3bf4929d6dac1e558071566f73 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

[Xen-devel] [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after initialized HVM domain

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

The guest_iommu_init() is currently called by the following code path:

arch/x86/domain.c: arch_domain_create()
  ]- drivers/passthrough/iommu.c: iommu_domain_init()
|- drivers/passthrough/amd/pci_amd_iommu.c: amd_iommu_domain_init();
  |- drivers/passthrough/amd/iommu_guest.c: guest_iommu_init()

At this point, the hvm_domain_initialised() has not been
called. So register_mmio_handler(), in guest_iommu_init(), silently fails.
This patch moves the call to guest_iommu_init/destroy() into
the svm_domain_intialise/_destroy() instead.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/svm.c  | 10 ++
 xen/drivers/passthrough/amd/iommu_guest.c   |  6 ++
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  4 
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index e62dfa1..0c4affc 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1176,11 +1177,20 @@ void svm_host_osvw_init()
 
 static int svm_domain_initialise(struct domain *d)
 {
+if ( is_hvm_domain(d) )
+/*
+ * This requires the hvm domain to be
+ * initialized first.
+ */
+return guest_iommu_init(d);
+
 return 0;
 }
 
 static void svm_domain_destroy(struct domain *d)
 {
+if ( is_hvm_domain(d) )
+guest_iommu_destroy(d);
 }
 
 static int svm_vcpu_initialise(struct vcpu *v)
diff --git a/xen/drivers/passthrough/amd/iommu_guest.c 
b/xen/drivers/passthrough/amd/iommu_guest.c
index b4e75ac..9f26765 100644
--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++ b/xen/drivers/passthrough/amd/iommu_guest.c
@@ -891,6 +891,12 @@ int guest_iommu_init(struct domain* d)
  !has_viommu(d) )
 return 0;
 
+if ( d->arch.hvm_domain.io_handler == NULL )
+{
+AMD_IOMMU_DEBUG("Error: uninitalized hvm io handler\n");
+return 1;
+}
+
 iommu = xzalloc(struct guest_iommu);
 if ( !iommu )
 {
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c 
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index c1c0b6b..f791618 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -274,9 +274,6 @@ static int amd_iommu_domain_init(struct domain *d)
 hd->arch.paging_mode = is_hvm_domain(d) ?
   IOMMU_PAGING_MODE_LEVEL_2 :
   get_paging_mode(max_page);
-
-guest_iommu_init(d);
-
 return 0;
 }
 
@@ -476,7 +473,6 @@ static void deallocate_iommu_page_tables(struct domain *d)
 
 static void amd_iommu_domain_destroy(struct domain *d)
 {
-guest_iommu_destroy(d);
 deallocate_iommu_page_tables(d);
 amd_iommu_flush_all_pages(d);
 }
-- 
1.9.1


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

[Xen-devel] [PATCH V2 0/2] Fix xen crash when starting HVM guest due to missing io handler

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

Hi All,

On systems with iommu v2 enabled, the hypervisor crashes when trying
to start up an HVM guest. 

Investigating shows that the guest_iommu_init() is called before the
HVM domain is initialized. It then tries to register_mmio_handler()
causing the hvm_next_io_handler() to increment the io_handler_count.
However, the registration fails silently and left the I/O handler
uninitialized.

At later time, hvm_find_io_handler() is called and iterate through
the registered handlered, but then resulting in referencing NULL
pointers.

This patch series proposes fix for this issue.

NOTE: For patch 2, since guest IOMMU emulation is still incompleted,
this change is tentative and will be verified in the future. Alterantively,
I can just simply remove the guest_iommu_init()/destroy() for now.
I will be also looking at re-enabling this feature in Xen.

Changes from V1:
  * Fix upper bound NR_IO_HANDLERS check for in patch 1.

Thanks,
Suravee

Suravee Suthikulpanit (2):
  x86/hvm: Add check when register io handler
  svm: iommu: Only call guest_iommu_init() after initialized HVM domain

 xen/arch/x86/hvm/intercept.c|  6 +-
 xen/arch/x86/hvm/svm/svm.c  | 10 ++
 xen/drivers/passthrough/amd/iommu_guest.c   |  6 ++
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  4 
 4 files changed, 21 insertions(+), 5 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH V2 1/2] x86/hvm: Add check when register io handler

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

At the time of registering HVM I/O handler, the HVM domain might
not have been initialized, which means the hvm_domain.io_handler
would be NULL. In the hvm_next_io_handler(), this should be checked
before returning and referencing the array. Also, the io_handler_count
should only be incremented on success.

So, this patch adds error handling in hvm_next_io_handler.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/intercept.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/intercept.c b/xen/arch/x86/hvm/intercept.c
index 7096d74..b837f5f 100644
--- a/xen/arch/x86/hvm/intercept.c
+++ b/xen/arch/x86/hvm/intercept.c
@@ -248,7 +248,10 @@ int hvm_io_intercept(ioreq_t *p)
 
 struct hvm_io_handler *hvm_next_io_handler(struct domain *d)
 {
-unsigned int i = d->arch.hvm_domain.io_handler_count++;
+unsigned int i = d->arch.hvm_domain.io_handler_count;
+
+if ( !d->arch.hvm_domain.io_handler )
+return NULL;
 
 if ( i == NR_IO_HANDLERS )
 {
@@ -256,6 +259,7 @@ struct hvm_io_handler *hvm_next_io_handler(struct domain *d)
 return NULL;
 }
 
+d->arch.hvm_domain.io_handler_count++;
 return >arch.hvm_domain.io_handler[i];
 }
 
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v3 1/6] build: add debug menu to Kconfig

[Konrad Rzeszutek Wilk]

On Tue, May 10, 2016 at 04:05:24PM -0500, Doug Goldstein wrote:
> There are a number of debugging options for Xen so the idea is to have a
> menu to group them all together. Enabling this menu item will also
> disable NDEBUG which will result in more debug prints. This was
> previously wired into the 'debug=y' command line option.
> 
> Signed-off-by: Doug Goldstein 
> ---
> CC: Andrew Cooper 
> CC: George Dunlap 
> CC: Ian Jackson 
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Tim Deegan 
> CC: Wei Liu 
> ---
>  xen/Kconfig  |  2 ++
>  xen/Kconfig.debug| 11 +++
>  xen/Rules.mk |  2 --
>  xen/include/xen/config.h |  4 
>  4 files changed, 17 insertions(+), 2 deletions(-)
>  create mode 100644 xen/Kconfig.debug
> 
> diff --git a/xen/Kconfig b/xen/Kconfig
> index fa8b27c..0fe7a1a 100644
> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -26,3 +26,5 @@ config DEFCONFIG_LIST
>  config EXPERT
>   string
>   option env="XEN_CONFIG_EXPERT"
> +
> +source "Kconfig.debug"
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> new file mode 100644
> index 000..47dc885
> --- /dev/null
> +++ b/xen/Kconfig.debug
> @@ -0,0 +1,11 @@
> +
> +menu "Debugging Options"
> +
> +config DEBUG
> + bool "Developer Checks"
> + ---help---
> +   Enables developer checks such as asserts and extra printks, this
> +   option is intended for development purposes only, and not for
> +   production use.

"You probably want to say 'N' here."


Otherwise it looks good to me.
> +
> +endmenu
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 961d533..f73d86e 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -20,8 +20,6 @@ include $(XEN_ROOT)/Config.mk
>  ifeq ($(debug),y)
>  verbose   := y
>  frame_pointer := y
> -else
> -CFLAGS += -DNDEBUG
>  endif
>  ifeq ($(perfc_arrays),y)
>  perfc := y
> diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
> index ef6e5ee..473c5e8 100644
> --- a/xen/include/xen/config.h
> +++ b/xen/include/xen/config.h
> @@ -81,4 +81,8 @@
>  /* allow existing code to work with Kconfig variable */
>  #define NR_CPUS CONFIG_NR_CPUS
>  
> +#ifndef CONFIG_DEBUG
> +#define NDEBUG
> +#endif
> +
>  #endif /* __XEN_CONFIG_H__ */
> -- 
> 2.7.3
> 

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

[Xen-devel] [PATCH v2 for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

[Andrew Cooper]

hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a
general L1 p2m walk.  It is fine for AMD as NPT share the same format as
normal pagetables.  For Intel EPT however, it is wrong.

The translation ends up correct (as the formats are sufficiently similar), but
the control bits in lower 12 bits differ in meaning.  A plain PT walker sets
A/D bits (bits 5 and 6) as it walks, but in EPT tables, these are the IPAT and
top bit of EMT (caching type).  This in turn causes problem when the EPT
tables are subsequently used.

Replace hostmode->p2m_ga_to_gfn() with nestedhap_walk_L1_p2m() in
paging_gva_to_gfn(), which is the correct function for the task.  This
involves making nestedhap_walk_L1_p2m() non-static, and adding
vmx_vmcs_enter/exit() pairs to nvmx_hap_walk_L1_p2m() as it is now reachable
from contexts other than v == current.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: George Dunlap 
CC: Tim Deegan 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Wei Liu 

v2:
 * ASSERT() that the translation doesn't go wrong with superpages
---
 xen/arch/x86/hvm/vmx/vvmx.c |  4 
 xen/arch/x86/mm/hap/nested_hap.c|  2 +-
 xen/arch/x86/mm/p2m.c   | 29 -
 xen/include/asm-x86/hvm/nestedhvm.h |  4 
 4 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 35f3687..faa8b69 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2036,6 +2036,8 @@ nvmx_hap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, 
paddr_t *L1_gpa,
 uint32_t rwx_rights = (access_x << 2) | (access_w << 1) | access_r;
 struct nestedvmx *nvmx = _2_nvmx(v);
 
+vmx_vmcs_enter(v);
+
 __vmread(EXIT_QUALIFICATION, _qual);
 rc = nept_translate_l2ga(v, L2_gpa, page_order, rwx_rights, , p2m_acc,
  _qual, _reason);
@@ -2060,6 +2062,8 @@ nvmx_hap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, 
paddr_t *L1_gpa,
 break;
 }
 
+vmx_vmcs_exit(v);
+
 return rc;
 }
 
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index 9cee5a0..d41bb09 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m,
  * walk is successful, the translated value is returned in
  * L1_gpa. The result value tells what to do next.
  */
-static int
+int
 nestedhap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa,
   unsigned int *page_order, uint8_t *p2m_acc,
   bool_t access_r, bool_t access_w, bool_t access_x)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 94eabf6..9b19769 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2081,20 +2081,39 @@ unsigned long paging_gva_to_gfn(struct vcpu *v,
 
 if ( is_hvm_vcpu(v) && paging_mode_hap(v->domain) && nestedhvm_is_n2(v) )
 {
-unsigned long gfn;
+unsigned long l2_gfn, l1_gfn;
 struct p2m_domain *p2m;
 const struct paging_mode *mode;
-uint32_t pfec_21 = *pfec;
 uint64_t np2m_base = nhvm_vcpu_p2m_base(v);
+uint8_t l1_p2ma;
+unsigned int l1_page_order;
+int rv;
 
 /* translate l2 guest va into l2 guest gfn */
 p2m = p2m_get_nestedp2m(v, np2m_base);
 mode = paging_get_nestedmode(v);
-gfn = mode->gva_to_gfn(v, p2m, va, pfec);
+l2_gfn = mode->gva_to_gfn(v, p2m, va, pfec);
+
+if ( l2_gfn == INVALID_GFN )
+return INVALID_GFN;
 
 /* translate l2 guest gfn into l1 guest gfn */
-return hostmode->p2m_ga_to_gfn(v, hostp2m, np2m_base,
-   gfn << PAGE_SHIFT, _21, NULL);
+rv = nestedhap_walk_L1_p2m(v, l2_gfn, _gfn, _page_order, 
_p2ma,
+   1,
+   !!(*pfec & PFEC_write_access),
+   !!(*pfec & PFEC_insn_fetch));
+
+if ( rv != NESTEDHVM_PAGEFAULT_DONE )
+return INVALID_GFN;
+
+/*
+ * Sanity check that l1_gfn can be used properly as a 4K mapping, even
+ * if it mapped by a nested superpage.
+ */
+ASSERT((l2_gfn & ((1ul << l1_page_order) - 1)) ==
+   (l1_gfn & ((1ul << l1_page_order) - 1)));
+
+return l1_gfn;
 }
 
 return hostmode->gva_to_gfn(v, hostp2m, va, pfec);
diff --git a/xen/include/asm-x86/hvm/nestedhvm.h 
b/xen/include/asm-x86/hvm/nestedhvm.h
index cf1a8f4..bc82425 100644
--- a/xen/include/asm-x86/hvm/nestedhvm.h
+++ b/xen/include/asm-x86/hvm/nestedhvm.h
@@ -56,6 +56,10 @@ bool_t nestedhvm_vcpu_in_guestmode(struct vcpu *v);
 int nestedhvm_hap_nested_page_fault(struct vcpu *v, paddr_t 

Re: [Xen-devel] [PATCH v3 0/4] x86: accommodate 32-bit PV guests with SMEP/SMAP handling

[Andrew Cooper]

On 13/05/16 18:02, Wei Liu wrote:
> On Thu, Mar 17, 2016 at 01:50:39AM -0600, Jan Beulich wrote:
>> As has been explained previously[1], SMAP (and with less relevance
>> also SMEP) is not compatible with 32-bit PV guests which aren't
>> aware/prepared to be run with that feature enabled. Andrew's
>> original approach either sacrificed architectural correctness for
>> making 32-bit guests work again, or disabled SMAP also for not
>> insignificant portions of hypervisor code, both by allowing to control
>> the workaround mode via command line option.
>>
>> This alternative approach disables SMEP and SMAP only while
>> running 32-bit PV guest code plus a few hypervisor instructions
>> early after entering hypervisor context from or late before exiting
>> to such guests. Those few instructions (in assembly source) are of
>> course much easier to prove not to perform undue memory
>> accesses than code paths reaching deep into C sources.
>>
>> The 4th patch really is unrelated except for not applying cleanly
>> without the earlier ones, and the potential having been noticed
>> while putting together the 2nd one.
>>
>> 1: move cached CR4 value to struct cpu_info
>> 2: suppress SMEP and SMAP while running 32-bit PV guest code
>> 3: use optimal NOPs to fill the SMEP/SMAP placeholders
>> 4: use 32-bit loads for 32-bit PV guest state reload
>>
>> Signed-off-by: Jan Beulich 
> Release-acked-by: Wei Liu 

And applied.

~Andrew

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

[Xen-devel] [PATCH 0/2] Fix xen crash when starting HVM guest due to missing io handler

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

Hi All,

On systems with iommu v2 enabled, the hypervisor crashes when trying
to start up an HVM guest. 

Investigating shows that the guest_iommu_init() is called before the
HVM domain is initialized. It then tries to register_mmio_handler()
causing the hvm_next_io_handler() to increment the io_handler_count.
However, the registration fails silently and left the I/O handler
uninitialized.

At later time, hvm_find_io_handler() is called and iterate through
the registered handlered, but then resulting in referencing NULL
pointers.

This patch series proposes fix for this issue.

NOTE: For patch 2, since guest IOMMU emulation is still incompleted,
this change is tentative and will be verified in the future. Alterantively,
I can just simply remove the guest_iommu_init()/destroy() for now.
I will be also looking at re-enabling this feature in Xen.

Thanks,
Suravee

Suravee Suthikulpanit (2):
  x86/hvm: Add check when register io handler
  svm: iommu: Only call guest_iommu_init() after initialized HVM domain

 xen/arch/x86/hvm/intercept.c|  8 ++--
 xen/arch/x86/hvm/svm/svm.c  | 10 ++
 xen/drivers/passthrough/amd/iommu_guest.c   |  6 ++
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  4 
 4 files changed, 22 insertions(+), 6 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH 2/2] svm: iommu: Only call guest_iommu_init() after initialized HVM domain

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

The guest_iommu_init() is currently called by the following code path:

arch/x86/domain.c: arch_domain_create()
  ]- drivers/passthrough/iommu.c: iommu_domain_init()
|- drivers/passthrough/amd/pci_amd_iommu.c: amd_iommu_domain_init();
  |- drivers/passthrough/amd/iommu_guest.c: guest_iommu_init()

At this point, the hvm_domain_initialised() has not been
called. So register_mmio_handler(), in guest_iommu_init(), silently fails.
This patch moves the call to guest_iommu_init/destroy() into
the svm_domain_intialise/_destroy() instead.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/svm.c  | 10 ++
 xen/drivers/passthrough/amd/iommu_guest.c   |  6 ++
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  4 
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index e62dfa1..0c4affc 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1176,11 +1177,20 @@ void svm_host_osvw_init()
 
 static int svm_domain_initialise(struct domain *d)
 {
+if ( is_hvm_domain(d) )
+/*
+ * This requires the hvm domain to be
+ * initialized first.
+ */
+return guest_iommu_init(d);
+
 return 0;
 }
 
 static void svm_domain_destroy(struct domain *d)
 {
+if ( is_hvm_domain(d) )
+guest_iommu_destroy(d);
 }
 
 static int svm_vcpu_initialise(struct vcpu *v)
diff --git a/xen/drivers/passthrough/amd/iommu_guest.c 
b/xen/drivers/passthrough/amd/iommu_guest.c
index b4e75ac..9f26765 100644
--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++ b/xen/drivers/passthrough/amd/iommu_guest.c
@@ -891,6 +891,12 @@ int guest_iommu_init(struct domain* d)
  !has_viommu(d) )
 return 0;
 
+if ( d->arch.hvm_domain.io_handler == NULL )
+{
+AMD_IOMMU_DEBUG("Error: uninitalized hvm io handler\n");
+return 1;
+}
+
 iommu = xzalloc(struct guest_iommu);
 if ( !iommu )
 {
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c 
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index c1c0b6b..f791618 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -274,9 +274,6 @@ static int amd_iommu_domain_init(struct domain *d)
 hd->arch.paging_mode = is_hvm_domain(d) ?
   IOMMU_PAGING_MODE_LEVEL_2 :
   get_paging_mode(max_page);
-
-guest_iommu_init(d);
-
 return 0;
 }
 
@@ -476,7 +473,6 @@ static void deallocate_iommu_page_tables(struct domain *d)
 
 static void amd_iommu_domain_destroy(struct domain *d)
 {
-guest_iommu_destroy(d);
 deallocate_iommu_page_tables(d);
 amd_iommu_flush_all_pages(d);
 }
-- 
1.9.1


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

[Xen-devel] [PATCH 1/2] x86/hvm: Add check when register io handler

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

At the time of registering HVM I/O handler, the HVM domain might
not have been initialized, which means the hvm_domain.io_handler
would be NULL. In the hvm_next_io_handler(), this should be checked
before returning and referencing the array. Also, the io_handler_count
should only be incremented on success.

So, this patch adds error handling in hvm_next_io_handler.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/intercept.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/intercept.c b/xen/arch/x86/hvm/intercept.c
index 7096d74..13b81c9 100644
--- a/xen/arch/x86/hvm/intercept.c
+++ b/xen/arch/x86/hvm/intercept.c
@@ -248,14 +248,18 @@ int hvm_io_intercept(ioreq_t *p)
 
 struct hvm_io_handler *hvm_next_io_handler(struct domain *d)
 {
-unsigned int i = d->arch.hvm_domain.io_handler_count++;
+unsigned int i = d->arch.hvm_domain.io_handler_count;
 
-if ( i == NR_IO_HANDLERS )
+if ( !d->arch.hvm_domain.io_handler )
+return NULL;
+
+if ( i == NR_IO_HANDLERS - 1 )
 {
 domain_crash(d);
 return NULL;
 }
 
+d->arch.hvm_domain.io_handler_count++;
 return >arch.hvm_domain.io_handler[i];
 }
 
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v3 0/4] x86: accommodate 32-bit PV guests with SMEP/SMAP handling

[Wei Liu]

On Thu, Mar 17, 2016 at 01:50:39AM -0600, Jan Beulich wrote:
> As has been explained previously[1], SMAP (and with less relevance
> also SMEP) is not compatible with 32-bit PV guests which aren't
> aware/prepared to be run with that feature enabled. Andrew's
> original approach either sacrificed architectural correctness for
> making 32-bit guests work again, or disabled SMAP also for not
> insignificant portions of hypervisor code, both by allowing to control
> the workaround mode via command line option.
> 
> This alternative approach disables SMEP and SMAP only while
> running 32-bit PV guest code plus a few hypervisor instructions
> early after entering hypervisor context from or late before exiting
> to such guests. Those few instructions (in assembly source) are of
> course much easier to prove not to perform undue memory
> accesses than code paths reaching deep into C sources.
> 
> The 4th patch really is unrelated except for not applying cleanly
> without the earlier ones, and the potential having been noticed
> while putting together the 2nd one.
> 
> 1: move cached CR4 value to struct cpu_info
> 2: suppress SMEP and SMAP while running 32-bit PV guest code
> 3: use optimal NOPs to fill the SMEP/SMAP placeholders
> 4: use 32-bit loads for 32-bit PV guest state reload
> 
> Signed-off-by: Jan Beulich 

Release-acked-by: Wei Liu 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-qemut-winxpsp3 9 windows-install fail in 94038 pass in 
94065
 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail pass 
in 94038
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail pass in 
94038
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat   fail pass in 94038

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

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

version targeted for testing:
 xen  ab6f8993136a10fee4336e0cbb90f491ce505212
baseline version:
 xen  24ebffa9f57a14b6f20376ae422b941715af9a4e

Last test of basis92242  2016-04-21 08:21:20 Z   22 days
Testing same since94001  2016-05-10 18:47:20 Z2 days3 attempts


People who touched revisions under test:
  Ian Jackson 

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

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Tamas K Lengyel]

On Fri, May 13, 2016 at 10:12 AM, Jan Beulich  wrote:
 On 13.05.16 at 17:31,  wrote:
>> On Fri, May 13, 2016 at 9:09 AM, Jan Beulich  wrote:
>> On 13.05.16 at 16:50,  wrote:
 On Fri, May 13, 2016 at 6:00 AM, Jan Beulich  wrote:
 On 12.05.16 at 17:25,  wrote:
>> @@ -1468,6 +1505,69 @@ int
>> +if ( rc )
>> +{
>> +rcu_unlock_domain(cd);
>> +goto out;
>> +}
>> +
>> +if ( !mem_sharing_enabled(cd) )
>> +{
>> +rcu_unlock_domain(cd);
>> +rc = -EINVAL;
>> +goto out;
>> +}
>> +
>> +if ( !atomic_read(>pause_count) ||
>> + !atomic_read(>pause_count) )
>> +{
>> +rcu_unlock_domain(cd);
>> +rc = -EINVAL;
>> +goto out;
>> +}
>> +
>> +max_sgfn = domain_get_maximum_gpfn(d);
>> +max_cgfn = domain_get_maximum_gpfn(cd);
>> +
>> +if ( max_sgfn != max_cgfn || max_sgfn < mso.u.bulk.start )
>
> Why would the two domains need to agree in their maximum
> GPFN? There's nothing similar in this file so far. Nor does the
> right side of the || match anything pre-existing...

 The use-case for this function is to deduplicate identical VMs, not to
 blindly share pages across arbitrary domains. So this is a safety
 check to avoid accidentally running this function on domains that
 obviously are not identical. The right hand size is a safety check
 against not properly initialized input structs where the start point
 is obviously outside the memory of the domain.
>>>
>>> Is that use case the only possible one, or merely the one you care
>>> about? In the former case, I'd be okay as long as a respctive
>>> comment got added.
>>
>> I would say "blind" sharing like this only makes sense for identical
>> VMs. Replacing the memory of the VM with that of another one not in
>> the same state will lead to some spectacular crash for sure, so we
>> should do at least some sanity checking before.
>
> Crash? Pages would be shared only if their contents match (and
> unshared when they're about to diverge), and once that's
> guaranteed, I don't see how it matters whether the two involved
> guests are identical. I agree that between dissimilar guests the
> potential for sharing is likely much lower, but that's about all.

No, that's not how it works. Xen's mem_sharing doesn't do _any_ checks
on the contents of the pages before sharing. It's up to the user to
know what he is doing.

>
>> @@ -488,7 +489,18 @@ struct xen_mem_sharing_op {
>>  uint64_aligned_t client_gfn;/* IN: the client gfn */
>>  uint64_aligned_t client_handle; /* IN: handle to the client 
>> page */
>>  domid_t  client_domain; /* IN: the client domain id */
>> -} share;
>> +} share;
>> +struct mem_sharing_op_bulk { /* OP_BULK_SHARE */
>> +uint64_aligned_t start;  /* IN: start gfn. Set to 0 
>> for
>> +full deduplication. 
>> Field is
>> +used internally and may 
>> change
>> +when the hypercall 
>> returns. */
>> +uint64_aligned_t shared; /* OUT: the number of gfns
>> +that are shared after 
>> this
>> +operation including 
>> pages
>> +already shared before */
>> +domid_t client_domain;   /* IN: the client domain 
>> id */
>> +} bulk;
>
> Let's not repeat pre-existing mistakes: There is explicit padding
> missing here, which then also ought to be checked to be zero on
> input.

 This struct is part of a union and is smaller then largest struct in
 the union, even with padding. So how would padding have any effect on
 anything?
>>>
>>> Being able to use the space for future extensions without having
>>> to bump the interface version. In domctl-s it's not as important
>>> due to them being separately versioned, but anyway.
>>
>> I don't really follow, we are not growing the union here. This struct
>> is still smaller then the space available in the union, so what would
>> prevent us from later on expending this struct to the size of the
>> union without padding?
>
> If a future hypervisor expects some value in a field that's now
> (anonymous) padding, and a caller written 

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Jan Beulich]

>>> On 13.05.16 at 17:35,  wrote:
> On 05/13/2016 11:09 AM, Jan Beulich wrote:
> On 13.05.16 at 16:50,  wrote:
> [...]
> @@ -1468,6 +1505,69 @@ int 
> mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>   }
>   break;
>
> +case XENMEM_sharing_op_bulk_share:
> +{
> +unsigned long max_sgfn, max_cgfn;
> +struct domain *cd;
> +
> +rc = -EINVAL;
> +if ( !mem_sharing_enabled(d) )
> +goto out;
> +
> +rc = 
> rcu_lock_live_remote_domain_by_id(mso.u.bulk.client_domain,
> +   );
> +if ( rc )
> +goto out;
> +
> +rc = xsm_mem_sharing_op(XSM_DM_PRIV, d, cd, mso.op);

 Either you pass XENMEM_sharing_op_share here, or you need to
 update xen/xsm/flask/policy/access_vectors (even if it's only a
 comment which needs updating).
>>>
>>> Right, it should actually be sharing_op_share here.
>>>

 That said - are this and the similar pre-existing XSM checks actually
 correct? I.e. is one of the two domains here really controlling the
 other? I would have expected that a tool stack domain initiates the
 sharing between two domains it controls...
>>>
>>> Not sure what was the original rationale behind it either.
>>
>> Daniel - any opinion on this one?
> 
> This hook checks two permissions; the primary check is that current (which
> is not either argument) can perform HVM__MEM_SHARING on (cd).  When XSM is
> disabled, this is checked as device model permissions.  I don't think this
> is what you were asking about, because this is actually a control operation.
> 
> The other permission check invoked by this hook, only when XSM is enabled,
> is a check for HVM__SHARE_MEM between (d) and (cd).  This is to allow a
> security policy to be written that forbids memory sharing between different
> users but allow it between VMs belonging to a single user (as an example).

Ah, I see - I missed the use of current->domain. But the asymmetry
still seems odd: In a sharing operation, both domains are equally
affected, and hence current->domain should have control over both,
and the second check should be done both ways (unless
domain_has_perm()'s first two arguments are treated equally, which
it doesn't look like is the case).

Jan


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

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

[Dario Faggioli]

On Fri, 2016-05-13 at 10:23 +0100, Andrew Cooper wrote:
> On 13/05/16 09:55, Jan Beulich wrote:
> > 
> > But anyway, L2 or L3 - I can't see how this context switching would
> > DTRT when there are vCPU-s of different domains on the same
> > socket (or core, if L2s and MSRs were per-core): The one getting
> > scheduled later onto a socket (core) would simply overwrite what
> > got written for the one which had been scheduled earlier.
> PSR_ASSOC is a per-thread MSR which selects the CLOS to use.  CLOS is
> currently managed per-domain in Xen, and context switched with vcpu.
> 
Yep, exactly. I did look a bit into this for CMT (so, not L3 CAT, but
it's not that different).

Doing things on a per-vcpu basis could be interesting, and that's even
more the case if we get to do L2 stuff, but there are two few RMIDs
available for such a configuration to be really useful.

> Xen programs different capacity bitmaps into IA32_L2_QOS_MASK_0 ...
> IA32_L2_QOS_MASK_n, and the CLOS selects which bitmap is enforced.
> 
So, basically, just to figure out if I understood (i.e., this is for He
Chen).

If we have a 2 sockets, with socket 0 containing cores 0,1,2,3 and
socket 1 containing cores 4,5,6,7, it will be possible to specify two
different "L2 reservation values" (in the form of CBMs, of course), for
a domain:
 - one would be how much L2 cache the domain will be able to use (say 
   X) when running on socket 1, which means on cores 0,1,2 or 3
 - another would be how much L2 cache the domain will be able to (say, 
   Y use when running on socket 2, which means on cores 4,5,6, or 7

Which in turn means, in case L2 is per core, the domain will get X of
core 0's L2, X of core 1's L2, X of core 2's L2 and X of core 3's L2.
On socket 1, it will get Y of core 4' L2, Y of core 5's L2 cache etc.
etc.

And so, in summary what we would not be able to specify is a different
value for the L2 reservations of, for instance, core 1 and core 3
(i.e., of cores that are part of the same socket).

Does this summary make sense?

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



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

Re: [Xen-devel] [PATCH v3 5/4] x86: reduce code size of struct cpu_info member accesses

[Andrew Cooper]

On 17/03/16 16:14, Jan Beulich wrote:
> Instead of addressing these fields via the base of the stack (which
> uniformly requires 4-byte displacements), address them from the end
> (which for everything other than guest_cpu_user_regs requires just
> 1-byte ones). This yields a code size reduction somewhere between 8k
> and 12k in my builds.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Jan Beulich]

>>> On 13.05.16 at 17:31,  wrote:
> On Fri, May 13, 2016 at 9:09 AM, Jan Beulich  wrote:
> On 13.05.16 at 16:50,  wrote:
>>> On Fri, May 13, 2016 at 6:00 AM, Jan Beulich  wrote:
>>> On 12.05.16 at 17:25,  wrote:
> @@ -1468,6 +1505,69 @@ int 
> +if ( rc )
> +{
> +rcu_unlock_domain(cd);
> +goto out;
> +}
> +
> +if ( !mem_sharing_enabled(cd) )
> +{
> +rcu_unlock_domain(cd);
> +rc = -EINVAL;
> +goto out;
> +}
> +
> +if ( !atomic_read(>pause_count) ||
> + !atomic_read(>pause_count) )
> +{
> +rcu_unlock_domain(cd);
> +rc = -EINVAL;
> +goto out;
> +}
> +
> +max_sgfn = domain_get_maximum_gpfn(d);
> +max_cgfn = domain_get_maximum_gpfn(cd);
> +
> +if ( max_sgfn != max_cgfn || max_sgfn < mso.u.bulk.start )

 Why would the two domains need to agree in their maximum
 GPFN? There's nothing similar in this file so far. Nor does the
 right side of the || match anything pre-existing...
>>>
>>> The use-case for this function is to deduplicate identical VMs, not to
>>> blindly share pages across arbitrary domains. So this is a safety
>>> check to avoid accidentally running this function on domains that
>>> obviously are not identical. The right hand size is a safety check
>>> against not properly initialized input structs where the start point
>>> is obviously outside the memory of the domain.
>>
>> Is that use case the only possible one, or merely the one you care
>> about? In the former case, I'd be okay as long as a respctive
>> comment got added.
> 
> I would say "blind" sharing like this only makes sense for identical
> VMs. Replacing the memory of the VM with that of another one not in
> the same state will lead to some spectacular crash for sure, so we
> should do at least some sanity checking before.

Crash? Pages would be shared only if their contents match (and
unshared when they're about to diverge), and once that's
guaranteed, I don't see how it matters whether the two involved
guests are identical. I agree that between dissimilar guests the
potential for sharing is likely much lower, but that's about all.

> @@ -488,7 +489,18 @@ struct xen_mem_sharing_op {
>  uint64_aligned_t client_gfn;/* IN: the client gfn */
>  uint64_aligned_t client_handle; /* IN: handle to the client 
> page */
>  domid_t  client_domain; /* IN: the client domain id */
> -} share;
> +} share;
> +struct mem_sharing_op_bulk { /* OP_BULK_SHARE */
> +uint64_aligned_t start;  /* IN: start gfn. Set to 0 
> for
> +full deduplication. 
> Field is
> +used internally and may 
> change
> +when the hypercall 
> returns. */
> +uint64_aligned_t shared; /* OUT: the number of gfns
> +that are shared after 
> this
> +operation including pages
> +already shared before */
> +domid_t client_domain;   /* IN: the client domain id 
> */
> +} bulk;

 Let's not repeat pre-existing mistakes: There is explicit padding
 missing here, which then also ought to be checked to be zero on
 input.
>>>
>>> This struct is part of a union and is smaller then largest struct in
>>> the union, even with padding. So how would padding have any effect on
>>> anything?
>>
>> Being able to use the space for future extensions without having
>> to bump the interface version. In domctl-s it's not as important
>> due to them being separately versioned, but anyway.
> 
> I don't really follow, we are not growing the union here. This struct
> is still smaller then the space available in the union, so what would
> prevent us from later on expending this struct to the size of the
> union without padding?

If a future hypervisor expects some value in a field that's now
(anonymous) padding, and a caller written against the headers
with just your patch applied passes a structure with random
data in those padding fields to that new hypervisor, what do
you expect to happen?

Jan

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

Re: [Xen-devel] [PATCH v3 3/4] x86: use optimal NOPs to fill the SMEP/SMAP placeholders

[Jan Beulich]

>>> On 13.05.16 at 17:57,  wrote:
> On 17/03/16 08:03, Jan Beulich wrote:
>> Alternatives patching code picks the most suitable NOPs for the
>> running system, so simply use it to replace the pre-populated ones.
>>
>> Use an arbitrary, always available feature to key off from, but
>> hide this behind the new X86_FEATURE_ALWAYS.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> v3: Re-base.
>> v2: Introduce and use X86_FEATURE_ALWAYS.
>>
>> --- a/xen/arch/x86/x86_64/compat/entry.S
>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>> @@ -175,12 +175,7 @@ compat_bad_hypercall:
>>  ENTRY(compat_restore_all_guest)
>>  ASSERT_INTERRUPTS_DISABLED
>>  .Lcr4_orig:
>> -ASM_NOP8 /* testb $3,UREGS_cs(%rsp) */
>> -ASM_NOP2 /* jpe   .Lcr4_alt_end */
>> -ASM_NOP8 /* mov   CPUINFO_cr4...(%rsp), %rax */
>> -ASM_NOP6 /* and   $..., %rax */
>> -ASM_NOP8 /* mov   %rax, CPUINFO_cr4...(%rsp) */
>> -ASM_NOP3 /* mov   %rax, %cr4 */
>> +.skip (.Lcr4_alt_end - .Lcr4_alt) - (. - .Lcr4_orig), 0x90
>>  .Lcr4_orig_end:
>>  .pushsection .altinstr_replacement, "ax"
>>  .Lcr4_alt:
> 
> This hunk should live in patch 2.

No. In patch 2 we want to leverage multi-byte NOPs. Here, knowing
they're going to be replaced anyway, we are fine with using the
simpler .fill (producing many single byte ones).

> Reviewed-by: Andrew Cooper 

Does this stand nevertheless?

Jan


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

Re: [Xen-devel] [PATCH v3 3/4] x86: use optimal NOPs to fill the SMEP/SMAP placeholders

[Andrew Cooper]

On 13/05/16 17:06, Jan Beulich wrote:
 On 13.05.16 at 17:57,  wrote:
>> On 17/03/16 08:03, Jan Beulich wrote:
>>> Alternatives patching code picks the most suitable NOPs for the
>>> running system, so simply use it to replace the pre-populated ones.
>>>
>>> Use an arbitrary, always available feature to key off from, but
>>> hide this behind the new X86_FEATURE_ALWAYS.
>>>
>>> Signed-off-by: Jan Beulich 
>>> ---
>>> v3: Re-base.
>>> v2: Introduce and use X86_FEATURE_ALWAYS.
>>>
>>> --- a/xen/arch/x86/x86_64/compat/entry.S
>>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>>> @@ -175,12 +175,7 @@ compat_bad_hypercall:
>>>  ENTRY(compat_restore_all_guest)
>>>  ASSERT_INTERRUPTS_DISABLED
>>>  .Lcr4_orig:
>>> -ASM_NOP8 /* testb $3,UREGS_cs(%rsp) */
>>> -ASM_NOP2 /* jpe   .Lcr4_alt_end */
>>> -ASM_NOP8 /* mov   CPUINFO_cr4...(%rsp), %rax */
>>> -ASM_NOP6 /* and   $..., %rax */
>>> -ASM_NOP8 /* mov   %rax, CPUINFO_cr4...(%rsp) */
>>> -ASM_NOP3 /* mov   %rax, %cr4 */
>>> +.skip (.Lcr4_alt_end - .Lcr4_alt) - (. - .Lcr4_orig), 0x90
>>>  .Lcr4_orig_end:
>>>  .pushsection .altinstr_replacement, "ax"
>>>  .Lcr4_alt:
>> This hunk should live in patch 2.
> No. In patch 2 we want to leverage multi-byte NOPs. Here, knowing
> they're going to be replaced anyway, we are fine with using the
> simpler .fill (producing many single byte ones).
>
>> Reviewed-by: Andrew Cooper 
> Does this stand nevertheless?

Yes.

~Andrew

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

Re: [Xen-devel] [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

[Andrew Cooper]

On 17/03/16 08:03, Jan Beulich wrote:
> Since such guests' kernel code runs in ring 1, their memory accesses,
> at the paging layer, are supervisor mode ones, and hence subject to
> SMAP/SMEP checks. Such guests cannot be expected to be aware of those
> two features though (and so far we also don't expose the respective
> feature flags), and hence may suffer page faults they cannot deal with.
>
> While the placement of the re-enabling slightly weakens the intended
> protection, it was selected such that 64-bit paths would remain
> unaffected where possible. At the expense of a further performance hit
> the re-enabling could be put right next to the CLACs.
>
> Note that this introduces a number of extra TLB flushes - CR4.SMEP
> transitioning from 0 to 1 always causes a flush, and it transitioning
> from 1 to 0 may also do.
>
> Signed-off-by: Jan Beulich 

Sorry - I reviewed the v3 code, and replied to the v2 email.

For clarity sake, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v3 3/4] x86: use optimal NOPs to fill the SMEP/SMAP placeholders

[Andrew Cooper]

On 17/03/16 08:03, Jan Beulich wrote:
> Alternatives patching code picks the most suitable NOPs for the
> running system, so simply use it to replace the pre-populated ones.
>
> Use an arbitrary, always available feature to key off from, but
> hide this behind the new X86_FEATURE_ALWAYS.
>
> Signed-off-by: Jan Beulich 
> ---
> v3: Re-base.
> v2: Introduce and use X86_FEATURE_ALWAYS.
>
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -175,12 +175,7 @@ compat_bad_hypercall:
>  ENTRY(compat_restore_all_guest)
>  ASSERT_INTERRUPTS_DISABLED
>  .Lcr4_orig:
> -ASM_NOP8 /* testb $3,UREGS_cs(%rsp) */
> -ASM_NOP2 /* jpe   .Lcr4_alt_end */
> -ASM_NOP8 /* mov   CPUINFO_cr4...(%rsp), %rax */
> -ASM_NOP6 /* and   $..., %rax */
> -ASM_NOP8 /* mov   %rax, CPUINFO_cr4...(%rsp) */
> -ASM_NOP3 /* mov   %rax, %cr4 */
> +.skip (.Lcr4_alt_end - .Lcr4_alt) - (. - .Lcr4_orig), 0x90
>  .Lcr4_orig_end:
>  .pushsection .altinstr_replacement, "ax"
>  .Lcr4_alt:

This hunk should live in patch 2.

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 1/3] x86: suppress SMEP and SMAP while running 32-bit PV guest code

[Andrew Cooper]

On 10/03/16 09:53, Jan Beulich wrote:
> Since such guests' kernel code runs in ring 1, their memory accesses,
> at the paging layer, are supervisor mode ones, and hence subject to
> SMAP/SMEP checks. Such guests cannot be expected to be aware of those
> two features though (and so far we also don't expose the respective
> feature flags), and hence may suffer page faults they cannot deal with.
>
> While the placement of the re-enabling slightly weakens the intended
> protection, it was selected such that 64-bit paths would remain
> unaffected where possible. At the expense of a further performance hit
> the re-enabling could be put right next to the CLACs.
>
> Note that this introduces a number of extra TLB flushes - CR4.SMEP
> transitioning from 0 to 1 always causes a flush, and it transitioning
> from 1 to 0 may also do.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Jan Beulich]

>>> On 13.05.16 at 17:27,  wrote:
> We're approaching the release date so I would like to wrap this up.
> 
> As I understand it, there is indeed an issue in the emulator, but a
> proper fix that take into consideration all cases has not been proposed.
> 
> Should we make this a blocker for the release? I'm inclined to say no
> because it has been like this for a long time and doesn't seem to cause
> trouble for our main use case.
> 
> Thoughts?

I agree.

Jan


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

Re: [Xen-devel] potential problem with qdisk backend

[Jan Beulich]

>>> On 06.05.16 at 13:41,  wrote:
> Looking at the qdisk backend implementation I wondered whether
> blkif_get_x86_32_req() is really correct, especially for the
> BLKIF_OP_DISCARD case. The Linux kernel based blk backend seems to
> distinguish 32- and 64-bit layouts of blkif_request_discard while
> qemu treats them to be the same.

I agree, this can't work well.

Jan


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

Re: [Xen-devel] [PATCH v2 2/3] x86: use optimal NOPs to fill the SMEP/SMAP placeholders

[Andrew Cooper]

On 10/03/16 09:54, Jan Beulich wrote:
> Alternatives patching code picks the most suitable NOPs for the
> running system, so simply use it to replace the pre-populated ones.
>
> Use an arbitrary, always available feature to key off from, but
> hide this behind the new X86_FEATURE_ALWAYS.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Daniel De Graaf]

On 05/13/2016 11:09 AM, Jan Beulich wrote:

On 13.05.16 at 16:50,  wrote:

[...]

@@ -1468,6 +1505,69 @@ int 
mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
  }
  break;

+case XENMEM_sharing_op_bulk_share:
+{
+unsigned long max_sgfn, max_cgfn;
+struct domain *cd;
+
+rc = -EINVAL;
+if ( !mem_sharing_enabled(d) )
+goto out;
+
+rc = rcu_lock_live_remote_domain_by_id(mso.u.bulk.client_domain,
+   );
+if ( rc )
+goto out;
+
+rc = xsm_mem_sharing_op(XSM_DM_PRIV, d, cd, mso.op);


Either you pass XENMEM_sharing_op_share here, or you need to
update xen/xsm/flask/policy/access_vectors (even if it's only a
comment which needs updating).


Right, it should actually be sharing_op_share here.



That said - are this and the similar pre-existing XSM checks actually
correct? I.e. is one of the two domains here really controlling the
other? I would have expected that a tool stack domain initiates the
sharing between two domains it controls...


Not sure what was the original rationale behind it either.


Daniel - any opinion on this one?


This hook checks two permissions; the primary check is that current (which
is not either argument) can perform HVM__MEM_SHARING on (cd).  When XSM is
disabled, this is checked as device model permissions.  I don't think this
is what you were asking about, because this is actually a control operation.

The other permission check invoked by this hook, only when XSM is enabled,
is a check for HVM__SHARE_MEM between (d) and (cd).  This is to allow a
security policy to be written that forbids memory sharing between different
users but allow it between VMs belonging to a single user (as an example).

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

Re: [Xen-devel] Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

[Wei Liu]

On Fri, May 13, 2016 at 09:30:23AM -0600, Jan Beulich wrote:
> >>> On 13.05.16 at 17:21,  wrote:
> > On Tue, May 03, 2016 at 07:58:58AM -0600, Jan Beulich wrote:
> >> >>> On 17.03.16 at 09:03,  wrote:
> >> > Since such guests' kernel code runs in ring 1, their memory accesses,
> >> > at the paging layer, are supervisor mode ones, and hence subject to
> >> > SMAP/SMEP checks. Such guests cannot be expected to be aware of those
> >> > two features though (and so far we also don't expose the respective
> >> > feature flags), and hence may suffer page faults they cannot deal with.
> >> > 
> >> > While the placement of the re-enabling slightly weakens the intended
> >> > protection, it was selected such that 64-bit paths would remain
> >> > unaffected where possible. At the expense of a further performance hit
> >> > the re-enabling could be put right next to the CLACs.
> >> > 
> >> > Note that this introduces a number of extra TLB flushes - CR4.SMEP
> >> > transitioning from 0 to 1 always causes a flush, and it transitioning
> >> > from 1 to 0 may also do.
> >> > 
> >> > Signed-off-by: Jan Beulich 
> >> 
> >> So I think we need to take some decision here, and I'm afraid
> >> Andrew and I won't be able to settle this between us. He's
> >> validly concerned about the performance impact this got proven
> >> to have (for 32-bit PV guests), yet I continue to think that correct
> >> behavior is more relevant than performance. Hence I think we
> >> should bite the bullet and take the change. For those who value
> >> performance more than security, they can always disable the use
> >> of SMEP and SMAP via command line option.
> >> 
> >> Of course I'm also concerned that Intel, who did introduce the
> >> functional regression in the first place, so far didn't participate at
> >> all in finding an acceptable solution to the problem at hand...
> >> 
> > 
> > So this thread has not produced a conclusion. What do we need to do
> > about this issue?
> 
> Andrew privately agreed to no longer object, but of course
> subject to him doing (another) proper review.
> 
> > Do we have a set of patches that make things behave correctly
> > (regardless of its performance impact)?
> 
> Yes, this one.
> 

OK. I will wait for him to review this series.

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

[Jan Beulich]

>>> On 13.05.16 at 17:24,  wrote:
> On 13/05/16 16:00, Andrew Cooper wrote:
>> On 13/05/16 15:13, Jan Beulich wrote:
>> On 13.05.16 at 15:33,  wrote:
 --- a/xen/arch/x86/mm/hap/nested_hap.c
 +++ b/xen/arch/x86/mm/hap/nested_hap.c
 @@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain 
> *p2m,
   * walk is successful, the translated value is returned in
   * L1_gpa. The result value tells what to do next.
   */
 -static int
 +int
  nestedhap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa,
unsigned int *page_order, uint8_t *p2m_acc,
>>> The function becoming non-static widens the visibility of the bogus
>>> uint8_t here (should be p2m_access_t afaics). Granted this isn't an
>>> issue the patch introduces, but I would prefer this to be adjusted
>>> prior to dropping the static here...
>>>
 --- a/xen/arch/x86/mm/p2m.c
 +++ b/xen/arch/x86/mm/p2m.c
 @@ -2081,20 +2081,29 @@ unsigned long paging_gva_to_gfn(struct vcpu *v,
  
  if ( is_hvm_vcpu(v) && paging_mode_hap(v->domain) && 
 nestedhvm_is_n2(v) )
  {
 -unsigned long gfn;
 +unsigned long l2_gfn, l1_gfn;
  struct p2m_domain *p2m;
  const struct paging_mode *mode;
 -uint32_t pfec_21 = *pfec;
  uint64_t np2m_base = nhvm_vcpu_p2m_base(v);
 +uint8_t l1_p2ma;
>>> ... avoiding proliferation of the quirkiness.
>> Will do.
> 
> It turns out that this is currently hard, due to a tangle of header files.

And I withdraw the request then.

> I will put this on my TODO list, but this point, I have more important
> things to do for 4.7.

Thanks, understood.

Jan


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

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Tamas K Lengyel]

On Fri, May 13, 2016 at 9:09 AM, Jan Beulich  wrote:
 On 13.05.16 at 16:50,  wrote:
>> On Fri, May 13, 2016 at 6:00 AM, Jan Beulich  wrote:
>> On 12.05.16 at 17:25,  wrote:
 +if ( !rc )
 +mem_sharing_share_pages(d, bulk->start, sh, cd, 
 bulk->start, ch);
>>>
>>> You shouldn't be ignoring errors here.
>>
>> The only error this function returns is if the sh/ch handles are
>> invalid. However we obtained those just now from successful
>> nominations, so we are guaranteed to have valid handles. This error
>> checking is only important when nominations/sharing happen
>> independently where the handle may go stale in-between. Here that is
>> not possible.
>
> You describe the state of things right now. What if someone
> adds an error path to that function without inspecting all callers,
> as it is clear that the function could have returned errors before.
> Ignoring errors is plain bad. If you're sure there can't be errors,
> at least add a respective ASSERT().
>

Sure, that sounds like a reasonable middle ground.

 +}
 +
 +++(bulk->start);
>>>
>>> Pointless parentheses.
>>
>> Pointless but I prefer this style.
>
> But it's in contrast to what we do almost everywhere else ...
>

Alright..

 +/* Check for continuation if it's not the last iteration. */
 +if ( bulk->start < max && hypercall_preempt_check() )
>>>
>>> The loop head has <=; why < here?
>>
>> Because we only do preempt check if there are more then one pages left
>> (as the comment states).
>
> No, the comment says "last iteration", whereas the check is for
> "next to last" (as the increment has already happened). And I
> also don't see when between any two iterations preemption is
> possible, just not between the second from last and the last one.
>

Ah I see, yes you are right.

 +break;
 +}
 +}
 +
 +/* We only propagate -ENOMEM so reset rc here */
 +if ( rc < 0 && rc != -ENOMEM )
 +rc = 0;
>>>
>>> What's the rationale for discarding all other errors? At least the
>>> patch description, but perhaps even the comment (which btw
>>> is lacking a full stop) should be explaining this.
>>
>> The reason we swallow errors here other then ENOMEM is that it's quite
>> possible that max_gpfn page is unsharable for example, thus rc would
>> have an EINVAL final error value. However, we don't care about the
>> success/fail of individual pages, we only care about the overall
>> state. For that only ENOMEM is critical.
>
> And you think no possible caller would care about the hypercall
> reporting success yet not everything having got done that was
> requested? Sounds strange to me, but as said - at least a bold
> comment please.

The user has no way of knowing what pages will be sharable to begin
with, nor does he has any recourse when something doesn't share. The
request is thus not to "share everything" but to share "as much as
possible". I'll state this explicitly in a comment.

>
 @@ -1468,6 +1505,69 @@ int 
 mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
  }
  break;

 +case XENMEM_sharing_op_bulk_share:
 +{
 +unsigned long max_sgfn, max_cgfn;
 +struct domain *cd;
 +
 +rc = -EINVAL;
 +if ( !mem_sharing_enabled(d) )
 +goto out;
 +
 +rc = 
 rcu_lock_live_remote_domain_by_id(mso.u.bulk.client_domain,
 +   );
 +if ( rc )
 +goto out;
 +
 +rc = xsm_mem_sharing_op(XSM_DM_PRIV, d, cd, mso.op);
>>>
>>> Either you pass XENMEM_sharing_op_share here, or you need to
>>> update xen/xsm/flask/policy/access_vectors (even if it's only a
>>> comment which needs updating).
>>
>> Right, it should actually be sharing_op_share here.
>>
>>>
>>> That said - are this and the similar pre-existing XSM checks actually
>>> correct? I.e. is one of the two domains here really controlling the
>>> other? I would have expected that a tool stack domain initiates the
>>> sharing between two domains it controls...
>>
>> Not sure what was the original rationale behind it either.
>
> Daniel - any opinion on this one?
>
 +if ( rc )
 +{
 +rcu_unlock_domain(cd);
 +goto out;
 +}
 +
 +if ( !mem_sharing_enabled(cd) )
 +{
 +rcu_unlock_domain(cd);
 +rc = -EINVAL;
 +goto out;
 +}
 +
 +if ( !atomic_read(>pause_count) ||
 + !atomic_read(>pause_count) )
 +{
 +rcu_unlock_domain(cd);
 +   

Re: [Xen-devel] Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

[Jan Beulich]

>>> On 13.05.16 at 17:21,  wrote:
> On Tue, May 03, 2016 at 07:58:58AM -0600, Jan Beulich wrote:
>> >>> On 17.03.16 at 09:03,  wrote:
>> > Since such guests' kernel code runs in ring 1, their memory accesses,
>> > at the paging layer, are supervisor mode ones, and hence subject to
>> > SMAP/SMEP checks. Such guests cannot be expected to be aware of those
>> > two features though (and so far we also don't expose the respective
>> > feature flags), and hence may suffer page faults they cannot deal with.
>> > 
>> > While the placement of the re-enabling slightly weakens the intended
>> > protection, it was selected such that 64-bit paths would remain
>> > unaffected where possible. At the expense of a further performance hit
>> > the re-enabling could be put right next to the CLACs.
>> > 
>> > Note that this introduces a number of extra TLB flushes - CR4.SMEP
>> > transitioning from 0 to 1 always causes a flush, and it transitioning
>> > from 1 to 0 may also do.
>> > 
>> > Signed-off-by: Jan Beulich 
>> 
>> So I think we need to take some decision here, and I'm afraid
>> Andrew and I won't be able to settle this between us. He's
>> validly concerned about the performance impact this got proven
>> to have (for 32-bit PV guests), yet I continue to think that correct
>> behavior is more relevant than performance. Hence I think we
>> should bite the bullet and take the change. For those who value
>> performance more than security, they can always disable the use
>> of SMEP and SMAP via command line option.
>> 
>> Of course I'm also concerned that Intel, who did introduce the
>> functional regression in the first place, so far didn't participate at
>> all in finding an acceptable solution to the problem at hand...
>> 
> 
> So this thread has not produced a conclusion. What do we need to do
> about this issue?

Andrew privately agreed to no longer object, but of course
subject to him doing (another) proper review.

> Do we have a set of patches that make things behave correctly
> (regardless of its performance impact)?

Yes, this one.

Jan


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

[Xen-devel] [ovmf test] 94064: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 1fee349aeb4e80f29780963daf2621d4514f5299
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  157 days
Failing since 65593  2015-12-08 23:44:51 Z  156 days  255 attempts
Testing same since94064  2016-05-12 21:26:57 Z0 days1 attempts


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

Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

[Jan Beulich]

>>> On 22.04.16 at 12:54,  wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is also specified 
> vpmu will be turned off.
>  As the virtualisation is not 100% safe, don't use the vpmu flag on
>  production systems (see http://xenbits.xen.org/xsa/advisory-163.html)! 
>  
> +### vtd\_qi\_timeout (VT-d)
> +> `= `
> +
> +> Default: `1`
> +
> +Specify the timeout of the VT-d Queued Invalidation in milliseconds.
> +
> +By default, the timeout is 1ms. When you see error 'Queue invalidate wait
> +descriptor timed out', try increasing this value.

So when someone enables ATS, will the 1ms timeout apply to the
dev iotlb invalidations too? If so, that's surely too short, and would
ideally be adjusted automatically, but the need for a higher timeout
in that case should in any event be mentioned here.

Apart from that aspect this patch seems to be ready, but will clearly
need a VT-d maintainer's ack.

Jan


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

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Wei Liu]

We're approaching the release date so I would like to wrap this up.

As I understand it, there is indeed an issue in the emulator, but a
proper fix that take into consideration all cases has not been proposed.

Should we make this a blocker for the release? I'm inclined to say no
because it has been like this for a long time and doesn't seem to cause
trouble for our main use case.

Thoughts?

Wei.

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

Re: [Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

[Andrew Cooper]

On 13/05/16 16:00, Andrew Cooper wrote:
> On 13/05/16 15:13, Jan Beulich wrote:
> On 13.05.16 at 15:33,  wrote:
>>> --- a/xen/arch/x86/mm/hap/nested_hap.c
>>> +++ b/xen/arch/x86/mm/hap/nested_hap.c
>>> @@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain 
>>> *p2m,
>>>   * walk is successful, the translated value is returned in
>>>   * L1_gpa. The result value tells what to do next.
>>>   */
>>> -static int
>>> +int
>>>  nestedhap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa,
>>>unsigned int *page_order, uint8_t *p2m_acc,
>> The function becoming non-static widens the visibility of the bogus
>> uint8_t here (should be p2m_access_t afaics). Granted this isn't an
>> issue the patch introduces, but I would prefer this to be adjusted
>> prior to dropping the static here...
>>
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -2081,20 +2081,29 @@ unsigned long paging_gva_to_gfn(struct vcpu *v,
>>>  
>>>  if ( is_hvm_vcpu(v) && paging_mode_hap(v->domain) && 
>>> nestedhvm_is_n2(v) )
>>>  {
>>> -unsigned long gfn;
>>> +unsigned long l2_gfn, l1_gfn;
>>>  struct p2m_domain *p2m;
>>>  const struct paging_mode *mode;
>>> -uint32_t pfec_21 = *pfec;
>>>  uint64_t np2m_base = nhvm_vcpu_p2m_base(v);
>>> +uint8_t l1_p2ma;
>> ... avoiding proliferation of the quirkiness.
> Will do.

It turns out that this is currently hard, due to a tangle of header files.

I will put this on my TODO list, but this point, I have more important
things to do for 4.7.

~Andrew

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

Re: [Xen-devel] Build problems with xen 4.7

[Konrad Rzeszutek Wilk]

On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote:
> On Fri, 13 May 2016, Jan Beulich wrote:
> 
> > >>> On 13.05.16 at 15:49,  wrote:
> > > ...
> > > 
> > > Still an issue - with 4.7.0-rc1.
> > 
> > And I don't recall anyone having contributed a fix/workaround.
> > 
> > > If I do:
> > > 
> > > $export CFLAGS=" "'
> > > $make
> > > 
> > > I end up with:
> > > gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g 
> > > -fno-strict-aliasing -std=gnu99 
> > >[...]
> > > :0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> > > :0:0: note: this is the location of the previous definition
> > > :0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
> > > :0:0: note: this is the location of the previous definition
> > > cc1: all warnings being treated as errors
> > > Makefile:62: recipe for target 'compat/callback.i' failed
> > 
> > My previous recommendation stands: Then just don't do this.
> 
> I hacked around it for my test builds (eg. see my test build at
> https://copr.fedorainfracloud.org/coprs/myoung/xentest/build/204111/
> ) by not setting CFLAGS in the environment, but by instead adding the 
> recommended Fedora RPM settings into config/StdGNU.mk via a different 
> environment variable.

ah:

--- xen-4.7.0/config/StdGNU.mk.orig 2016-04-15 22:56:52.191227591 +0100
+++ xen-4.7.0/config/StdGNU.mk  2016-04-15 23:01:40.978829756 +0100
@@ -37,6 +37,12 @@
 
 ifneq ($(debug),y)
 CFLAGS += -O2 -fomit-frame-pointer -fno-tree-coalesce-vars
+ifeq ($(XEN_TARGET_ARCH),x86_64)
+#might be cross-compiling so strip out possible x86_32 options
+CFLAGS += $(shell echo $(CFLAGS_EXTRA) | sed -e 's/-m32//g' -e 
's/-march=i686//g' -e 's/-mtune=atom//g')
+else
+CFLAGS += $(CFLAGS_EXTRA)
+endif
 else
 # Less than -O1 produces bad code and large stack frames
 CFLAGS += -O1 -fno-omit-frame-pointer


And in the spec file:
export CFLAGS_EXTRA="$RPM_OPT_FLAGS"
make %{?_smp_mflags} %{?efi_flags} prefix=/usr dist-xen


> 
> Another thing you might need to know if you are building xen on Fedora 24 
> is that you need to add -fno-tree-coalesce-vars if you are on a gcc-6.0.0 
> package (it may be fixed in gcc-6.1.1-2.fc24 which has just come out but I 
> haven't tested it yet).
> 
>   Michael Young

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

Re: [Xen-devel] Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

[Wei Liu]

On Tue, May 03, 2016 at 07:58:58AM -0600, Jan Beulich wrote:
> >>> On 17.03.16 at 09:03,  wrote:
> > Since such guests' kernel code runs in ring 1, their memory accesses,
> > at the paging layer, are supervisor mode ones, and hence subject to
> > SMAP/SMEP checks. Such guests cannot be expected to be aware of those
> > two features though (and so far we also don't expose the respective
> > feature flags), and hence may suffer page faults they cannot deal with.
> > 
> > While the placement of the re-enabling slightly weakens the intended
> > protection, it was selected such that 64-bit paths would remain
> > unaffected where possible. At the expense of a further performance hit
> > the re-enabling could be put right next to the CLACs.
> > 
> > Note that this introduces a number of extra TLB flushes - CR4.SMEP
> > transitioning from 0 to 1 always causes a flush, and it transitioning
> > from 1 to 0 may also do.
> > 
> > Signed-off-by: Jan Beulich 
> 
> So I think we need to take some decision here, and I'm afraid
> Andrew and I won't be able to settle this between us. He's
> validly concerned about the performance impact this got proven
> to have (for 32-bit PV guests), yet I continue to think that correct
> behavior is more relevant than performance. Hence I think we
> should bite the bullet and take the change. For those who value
> performance more than security, they can always disable the use
> of SMEP and SMAP via command line option.
> 
> Of course I'm also concerned that Intel, who did introduce the
> functional regression in the first place, so far didn't participate at
> all in finding an acceptable solution to the problem at hand...
> 

So this thread has not produced a conclusion. What do we need to do
about this issue?

Do we have a set of patches that make things behave correctly
(regardless of its performance impact)?

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

[Jan Beulich]

>>> On 13.05.16 at 17:00,  wrote:
> On 13/05/16 15:13, Jan Beulich wrote:
> On 13.05.16 at 15:33,  wrote:
>>> +unsigned int l1_page_order;
>>> +int rv;
>>>  
>>>  /* translate l2 guest va into l2 guest gfn */
>>>  p2m = p2m_get_nestedp2m(v, np2m_base);
>>>  mode = paging_get_nestedmode(v);
>>> -gfn = mode->gva_to_gfn(v, p2m, va, pfec);
>>> +l2_gfn = mode->gva_to_gfn(v, p2m, va, pfec);
>>> +
>>> +if ( l2_gfn == INVALID_GFN )
>>> +return INVALID_GFN;
>>>  
>>>  /* translate l2 guest gfn into l1 guest gfn */
>>> -return hostmode->p2m_ga_to_gfn(v, hostp2m, np2m_base,
>>> -   gfn << PAGE_SHIFT, _21, NULL);
>>> +rv = nestedhap_walk_L1_p2m(v, l2_gfn, _gfn, _page_order, 
>>> _p2ma,
>>> +   1,
>>> +   !!(*pfec & PFEC_write_access),
>>> +   !!(*pfec & PFEC_insn_fetch));
>>> +
>>> +return rv == NESTEDHVM_PAGEFAULT_DONE ? l1_gfn : INVALID_GFN;
>>>  }
>> I'm really happy to see this getting cleaned up - I've stumbled across
>> the apparent brokenness here more than once, without ever finding
>> the time to help the situation. One question though: Is the return
>> value here correct even for l1_page_order > 0?
> 
> Not completely sure.  This code is messy, and my current testing is "it
> now doesn't crash where it used to crash before".
> 
> The specific path being tripped over was __hvm_copy() performing an
> instruction fetch for emulation from the L2 guest.
> 
> Looking at the code, if your caller only cares about 4K mappings, you
> will get the correct translation, due to the adjustment
> nept_walk_tables() makes.

Ah, indeed. But very odd for it to be done there, the more that "all
callers" is exactly one afaics. In that case may I suggest adding an
assertion to check that the respective bits in L1 and L2 GFN match?

Jan


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

[Xen-devel] [TESTDAY] Test report

[Tamas K Lengyel]

* Hardware: Intel(R) Xeon(R) CPU E5-2430
* Sofware: Debian Jessie dom0
* Functionality tested:
xl save/resume
vm_event/mem_access/monitor/altp2m

Comment: everything works as expected.

Cheers,
Tamas

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

[Xen-devel] [PATCH] mm, frontswap: convert frontswap_enabled to static key

[Vlastimil Babka]

I have noticed that frontswap.h first declares "frontswap_enabled" as extern
bool variable, and then overrides it with "#define frontswap_enabled (1)" for
CONFIG_FRONTSWAP=Y or (0) when disabled. The bool variable isn't actually
instantiated anywhere.

This all looks like an unfinished attempt to make frontswap_enabled reflect
whether a backend is instantiated. But in the current state, all frontswap
hooks call unconditionally into frontswap.c just to check if frontswap_ops is
non-NULL. This should at least be checked inline, but we can further eliminate
the overhead when CONFIG_FRONTSWAP is enabled and no backend registered, using
a static key that is initially disabled, and gets enabled only upon first
backend registration.

Thus, checks for "frontswap_enabled" are replaced with "frontswap_enabled()"
wrapping the static key check. There are two exceptions:

- xen's selfballoon_process() was testing frontswap_enabled in code guarded
  by #ifdef CONFIG_FRONTSWAP, which was effectively always true when reachable.
  The patch just removes this check. Using frontswap_enabled() does not sound
  correct here, as this can be true even without xen's own backend being
  registered.

- in SYSCALL_DEFINE2(swapon), change the check to IS_ENABLED(CONFIG_FRONTSWAP)
  as it seems the bitmap allocation cannot currently be postponed until a
  backend is registered. This means that frontswap will still have some
  memory overhead by being configured, but without a backend.

After the patch, we can expect that some functions in frontswap.c are called
only when frontswap_ops is non-NULL. Change the checks there to VM_BUG_ONs.
While at it, convert other BUG_ONs to VM_BUG_ONs as frontswap has been stable
for some time.

Signed-off-by: Vlastimil Babka 
---
 drivers/xen/xen-selfballoon.c |  4 ++--
 include/linux/frontswap.h | 34 --
 mm/frontswap.c| 35 +++
 mm/swapfile.c |  2 +-
 4 files changed, 38 insertions(+), 37 deletions(-)

diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c
index 53a085fca00c..66620713242a 100644
--- a/drivers/xen/xen-selfballoon.c
+++ b/drivers/xen/xen-selfballoon.c
@@ -195,7 +195,7 @@ static void selfballoon_process(struct work_struct *work)
MB2PAGES(selfballoon_reserved_mb);
 #ifdef CONFIG_FRONTSWAP
/* allow space for frontswap pages to be repatriated */
-   if (frontswap_selfshrinking && frontswap_enabled)
+   if (frontswap_selfshrinking)
goal_pages += frontswap_curr_pages();
 #endif
if (cur_pages > goal_pages)
@@ -230,7 +230,7 @@ static void selfballoon_process(struct work_struct *work)
reset_timer = true;
}
 #ifdef CONFIG_FRONTSWAP
-   if (frontswap_selfshrinking && frontswap_enabled) {
+   if (frontswap_selfshrinking) {
frontswap_selfshrink();
reset_timer = true;
}
diff --git a/include/linux/frontswap.h b/include/linux/frontswap.h
index e65ef959546c..c46d2aa16d81 100644
--- a/include/linux/frontswap.h
+++ b/include/linux/frontswap.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct frontswap_ops {
void (*init)(unsigned); /* this swap type was just swapon'ed */
@@ -14,7 +15,6 @@ struct frontswap_ops {
struct frontswap_ops *next; /* private pointer to next ops */
 };
 
-extern bool frontswap_enabled;
 extern void frontswap_register_ops(struct frontswap_ops *ops);
 extern void frontswap_shrink(unsigned long);
 extern unsigned long frontswap_curr_pages(void);
@@ -30,7 +30,12 @@ extern void __frontswap_invalidate_page(unsigned, pgoff_t);
 extern void __frontswap_invalidate_area(unsigned);
 
 #ifdef CONFIG_FRONTSWAP
-#define frontswap_enabled (1)
+extern struct static_key_false frontswap_enabled_key;
+
+static inline bool frontswap_enabled(void)
+{
+   return static_branch_unlikely(_enabled_key);
+}
 
 static inline bool frontswap_test(struct swap_info_struct *sis, pgoff_t offset)
 {
@@ -50,7 +55,10 @@ static inline unsigned long *frontswap_map_get(struct 
swap_info_struct *p)
 #else
 /* all inline routines become no-ops and all externs are ignored */
 
-#define frontswap_enabled (0)
+static inline bool frontswap_enabled(void)
+{
+   return false;
+}
 
 static inline bool frontswap_test(struct swap_info_struct *sis, pgoff_t offset)
 {
@@ -70,37 +78,35 @@ static inline unsigned long *frontswap_map_get(struct 
swap_info_struct *p)
 
 static inline int frontswap_store(struct page *page)
 {
-   int ret = -1;
+   if (frontswap_enabled())
+   return __frontswap_store(page);
 
-   if (frontswap_enabled)
-   ret = __frontswap_store(page);
-   return ret;
+   return -1;
 }
 
 static inline int frontswap_load(struct page *page)
 {
-   int ret = -1;
+   if (frontswap_enabled())
+   return 

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Jan Beulich]

>>> On 13.05.16 at 16:50,  wrote:
> On Fri, May 13, 2016 at 6:00 AM, Jan Beulich  wrote:
> On 12.05.16 at 17:25,  wrote:
>>> +if ( !rc )
>>> +mem_sharing_share_pages(d, bulk->start, sh, cd, 
>>> bulk->start, ch);
>>
>> You shouldn't be ignoring errors here.
> 
> The only error this function returns is if the sh/ch handles are
> invalid. However we obtained those just now from successful
> nominations, so we are guaranteed to have valid handles. This error
> checking is only important when nominations/sharing happen
> independently where the handle may go stale in-between. Here that is
> not possible.

You describe the state of things right now. What if someone
adds an error path to that function without inspecting all callers,
as it is clear that the function could have returned errors before.
Ignoring errors is plain bad. If you're sure there can't be errors,
at least add a respective ASSERT().

>>> +}
>>> +
>>> +++(bulk->start);
>>
>> Pointless parentheses.
> 
> Pointless but I prefer this style.

But it's in contrast to what we do almost everywhere else ...

>>> +/* Check for continuation if it's not the last iteration. */
>>> +if ( bulk->start < max && hypercall_preempt_check() )
>>
>> The loop head has <=; why < here?
> 
> Because we only do preempt check if there are more then one pages left
> (as the comment states).

No, the comment says "last iteration", whereas the check is for
"next to last" (as the increment has already happened). And I
also don't see when between any two iterations preemption is
possible, just not between the second from last and the last one.

>>> +break;
>>> +}
>>> +}
>>> +
>>> +/* We only propagate -ENOMEM so reset rc here */
>>> +if ( rc < 0 && rc != -ENOMEM )
>>> +rc = 0;
>>
>> What's the rationale for discarding all other errors? At least the
>> patch description, but perhaps even the comment (which btw
>> is lacking a full stop) should be explaining this.
> 
> The reason we swallow errors here other then ENOMEM is that it's quite
> possible that max_gpfn page is unsharable for example, thus rc would
> have an EINVAL final error value. However, we don't care about the
> success/fail of individual pages, we only care about the overall
> state. For that only ENOMEM is critical.

And you think no possible caller would care about the hypercall
reporting success yet not everything having got done that was
requested? Sounds strange to me, but as said - at least a bold
comment please.

>>> @@ -1468,6 +1505,69 @@ int 
>>> mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>>>  }
>>>  break;
>>>
>>> +case XENMEM_sharing_op_bulk_share:
>>> +{
>>> +unsigned long max_sgfn, max_cgfn;
>>> +struct domain *cd;
>>> +
>>> +rc = -EINVAL;
>>> +if ( !mem_sharing_enabled(d) )
>>> +goto out;
>>> +
>>> +rc = 
>>> rcu_lock_live_remote_domain_by_id(mso.u.bulk.client_domain,
>>> +   );
>>> +if ( rc )
>>> +goto out;
>>> +
>>> +rc = xsm_mem_sharing_op(XSM_DM_PRIV, d, cd, mso.op);
>>
>> Either you pass XENMEM_sharing_op_share here, or you need to
>> update xen/xsm/flask/policy/access_vectors (even if it's only a
>> comment which needs updating).
> 
> Right, it should actually be sharing_op_share here.
> 
>>
>> That said - are this and the similar pre-existing XSM checks actually
>> correct? I.e. is one of the two domains here really controlling the
>> other? I would have expected that a tool stack domain initiates the
>> sharing between two domains it controls...
> 
> Not sure what was the original rationale behind it either.

Daniel - any opinion on this one?

>>> +if ( rc )
>>> +{
>>> +rcu_unlock_domain(cd);
>>> +goto out;
>>> +}
>>> +
>>> +if ( !mem_sharing_enabled(cd) )
>>> +{
>>> +rcu_unlock_domain(cd);
>>> +rc = -EINVAL;
>>> +goto out;
>>> +}
>>> +
>>> +if ( !atomic_read(>pause_count) ||
>>> + !atomic_read(>pause_count) )
>>> +{
>>> +rcu_unlock_domain(cd);
>>> +rc = -EINVAL;
>>> +goto out;
>>> +}
>>> +
>>> +max_sgfn = domain_get_maximum_gpfn(d);
>>> +max_cgfn = domain_get_maximum_gpfn(cd);
>>> +
>>> +if ( max_sgfn != max_cgfn || max_sgfn < mso.u.bulk.start )
>>
>> Why would the two domains need to agree in their maximum
>> GPFN? There's nothing similar in this file so far. Nor does the
>> right side of the || match anything pre-existing...
> 
> The use-case for this function is to deduplicate identical VMs, not to
> blindly share pages 

Re: [Xen-devel] [TESTDAY] Test report - xl sched-rtds

[Meng Xu]

On Fri, May 13, 2016 at 5:31 AM, Wei Liu  wrote:
> On Thu, May 12, 2016 at 02:00:06PM -0500, Chong Li wrote:
>> * Hardware:
>> CPU: Intel Core2 Quad Q9400
>> Total Memory: 2791088 kB
>>
>> * Software:
>> Ubuntu 14.04
>> Linux kernel: 3.13.0-68
>>
>> * Guest operating systems:
>> Ubuntu 14.04 (PV)
>>
>> * Functionality tested:
>> xl sched-rtds (for set/get per-VCPU parameters)
>>
>> * Comments:
>> All examples about "xl sched-rtds" in xl mannual page
>> 
>> have been tested,
>> and all run successfully.
>>
>> If users type in wrong parameters (e.g., budget > period), the
>> error/warnning messages
>> are returned correctly as well.
>>
>
> Good, so RTDS works as expected. Thanks for your report.

Hi Wei,

I'd like to share some of my experience with the improved RTDS scheduler.
It is not a formal report. But hopefully it is some useful information.

I have been using the improved RTDS in the staging for a while. I
haven't seen any weird issue. Because I also modify the other parts of
Xen a bit, so the test is not for xen 4.7-rc2 though. That's why we
have Chong test the xen 4.7-rc2. Thank you very much, Chong, for your
nice test report! :-)

The workload types I run are:
1) Compile linux or xen kernels in parallel. The number of compiling
jobs is usually double the number of cores allocated for dom0.
2) Run cpu-intensive task or memory-intensive task,which access a large array.

Best,

Meng

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

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

Re: [Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

[Andrew Cooper]

On 13/05/16 15:13, Jan Beulich wrote:
 On 13.05.16 at 15:33,  wrote:
>> --- a/xen/arch/x86/mm/hap/nested_hap.c
>> +++ b/xen/arch/x86/mm/hap/nested_hap.c
>> @@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m,
>>   * walk is successful, the translated value is returned in
>>   * L1_gpa. The result value tells what to do next.
>>   */
>> -static int
>> +int
>>  nestedhap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa,
>>unsigned int *page_order, uint8_t *p2m_acc,
> The function becoming non-static widens the visibility of the bogus
> uint8_t here (should be p2m_access_t afaics). Granted this isn't an
> issue the patch introduces, but I would prefer this to be adjusted
> prior to dropping the static here...
>
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2081,20 +2081,29 @@ unsigned long paging_gva_to_gfn(struct vcpu *v,
>>  
>>  if ( is_hvm_vcpu(v) && paging_mode_hap(v->domain) && nestedhvm_is_n2(v) 
>> )
>>  {
>> -unsigned long gfn;
>> +unsigned long l2_gfn, l1_gfn;
>>  struct p2m_domain *p2m;
>>  const struct paging_mode *mode;
>> -uint32_t pfec_21 = *pfec;
>>  uint64_t np2m_base = nhvm_vcpu_p2m_base(v);
>> +uint8_t l1_p2ma;
> ... avoiding proliferation of the quirkiness.

Will do.

>
>> +unsigned int l1_page_order;
>> +int rv;
>>  
>>  /* translate l2 guest va into l2 guest gfn */
>>  p2m = p2m_get_nestedp2m(v, np2m_base);
>>  mode = paging_get_nestedmode(v);
>> -gfn = mode->gva_to_gfn(v, p2m, va, pfec);
>> +l2_gfn = mode->gva_to_gfn(v, p2m, va, pfec);
>> +
>> +if ( l2_gfn == INVALID_GFN )
>> +return INVALID_GFN;
>>  
>>  /* translate l2 guest gfn into l1 guest gfn */
>> -return hostmode->p2m_ga_to_gfn(v, hostp2m, np2m_base,
>> -   gfn << PAGE_SHIFT, _21, NULL);
>> +rv = nestedhap_walk_L1_p2m(v, l2_gfn, _gfn, _page_order, 
>> _p2ma,
>> +   1,
>> +   !!(*pfec & PFEC_write_access),
>> +   !!(*pfec & PFEC_insn_fetch));
>> +
>> +return rv == NESTEDHVM_PAGEFAULT_DONE ? l1_gfn : INVALID_GFN;
>>  }
> I'm really happy to see this getting cleaned up - I've stumbled across
> the apparent brokenness here more than once, without ever finding
> the time to help the situation. One question though: Is the return
> value here correct even for l1_page_order > 0?

Not completely sure.  This code is messy, and my current testing is "it
now doesn't crash where it used to crash before".

The specific path being tripped over was __hvm_copy() performing an
instruction fetch for emulation from the L2 guest.

Looking at the code, if your caller only cares about 4K mappings, you
will get the correct translation, due to the adjustment
nept_walk_tables() makes.

~Andrew

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

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Tamas K Lengyel]

On Fri, May 13, 2016 at 6:00 AM, Jan Beulich  wrote:
 On 12.05.16 at 17:25,  wrote:
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -1294,6 +1294,43 @@ int relinquish_shared_pages(struct domain *d)
>>  return rc;
>>  }
>>
>> +static int bulk_share(struct domain *d, struct domain *cd, unsigned long 
>> max,
>> +  struct mem_sharing_op_bulk *bulk)
>> +{
>> +int rc;
>> +shr_handle_t sh, ch;
>> +
>> +while( bulk->start <= max )
>> +{
>> +rc = mem_sharing_nominate_page(d, bulk->start, 0, );
>> +if ( rc == -ENOMEM )
>> +break;
>> +if ( !rc )
>> +{
>> +rc = mem_sharing_nominate_page(cd, bulk->start, 0, );
>> +if ( rc == -ENOMEM )
>> +break;
>
> If we get to this break, how will the caller know that the first
> nomination succeeded but the second didn't? Or perhaps there
> is some undo logic missing here?

No, there is not. There really is no "unnominate" feature of memshare.
So even if the user is calling nominate manually from userspace it
won't have the option to unnominate the page so that error condition
is currently useless for the user.

>
>> +if ( !rc )
>> +mem_sharing_share_pages(d, bulk->start, sh, cd, 
>> bulk->start, ch);
>
> You shouldn't be ignoring errors here.

The only error this function returns is if the sh/ch handles are
invalid. However we obtained those just now from successful
nominations, so we are guaranteed to have valid handles. This error
checking is only important when nominations/sharing happen
independently where the handle may go stale in-between. Here that is
not possible.

>
>> +}
>> +
>> +++(bulk->start);
>
> Pointless parentheses.

Pointless but I prefer this style.

>
>> +/* Check for continuation if it's not the last iteration. */
>> +if ( bulk->start < max && hypercall_preempt_check() )
>
> The loop head has <=; why < here?

Because we only do preempt check if there are more then one pages left
(as the comment states).

>> +{
>> +rc = 1;
>
> I'd recommend using -ERESTART here, as we do elsewhere.
>

Ack.

>> +break;
>> +}
>> +}
>> +
>> +/* We only propagate -ENOMEM so reset rc here */
>> +if ( rc < 0 && rc != -ENOMEM )
>> +rc = 0;
>
> What's the rationale for discarding all other errors? At least the
> patch description, but perhaps even the comment (which btw
> is lacking a full stop) should be explaining this.

The reason we swallow errors here other then ENOMEM is that it's quite
possible that max_gpfn page is unsharable for example, thus rc would
have an EINVAL final error value. However, we don't care about the
success/fail of individual pages, we only care about the overall
state. For that only ENOMEM is critical.

>
>> @@ -1468,6 +1505,69 @@ int 
>> mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>>  }
>>  break;
>>
>> +case XENMEM_sharing_op_bulk_share:
>> +{
>> +unsigned long max_sgfn, max_cgfn;
>> +struct domain *cd;
>> +
>> +rc = -EINVAL;
>> +if ( !mem_sharing_enabled(d) )
>> +goto out;
>> +
>> +rc = rcu_lock_live_remote_domain_by_id(mso.u.bulk.client_domain,
>> +   );
>> +if ( rc )
>> +goto out;
>> +
>> +rc = xsm_mem_sharing_op(XSM_DM_PRIV, d, cd, mso.op);
>
> Either you pass XENMEM_sharing_op_share here, or you need to
> update xen/xsm/flask/policy/access_vectors (even if it's only a
> comment which needs updating).

Right, it should actually be sharing_op_share here.

>
> That said - are this and the similar pre-existing XSM checks actually
> correct? I.e. is one of the two domains here really controlling the
> other? I would have expected that a tool stack domain initiates the
> sharing between two domains it controls...

Not sure what was the original rationale behind it either.

>
>> +if ( rc )
>> +{
>> +rcu_unlock_domain(cd);
>> +goto out;
>> +}
>> +
>> +if ( !mem_sharing_enabled(cd) )
>> +{
>> +rcu_unlock_domain(cd);
>> +rc = -EINVAL;
>> +goto out;
>> +}
>> +
>> +if ( !atomic_read(>pause_count) ||
>> + !atomic_read(>pause_count) )
>> +{
>> +rcu_unlock_domain(cd);
>> +rc = -EINVAL;
>> +goto out;
>> +}
>> +
>> +max_sgfn = domain_get_maximum_gpfn(d);
>> +max_cgfn = domain_get_maximum_gpfn(cd);
>> +
>> +if ( max_sgfn != max_cgfn || max_sgfn < mso.u.bulk.start )
>
> Why would the two domains need to agree in their maximum
> GPFN? There's nothing 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  9 debian-installfail REGR. vs. 93937

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 93937
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93937
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93937

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuuf68419eee9a966f5a915314c43cda6778f976a77
baseline version:
 qemuu860a3b34854d8abe9af9f1eb584691de926ce897

Last test of basis93937  2016-05-09 23:45:45 Z3 days
Failing since 94037  2016-05-11 16:12:23 Z1 days2 attempts
Testing same since94061  2016-05-12 17:30:52 Z0 days1 attempts


People who touched revisions under test:
  Changlong Xie 
  Daniel P. Berrange 
  David Gibson 
  Denis V. Lunev 
  Edgar E. Iglesias 
  Eric Blake 
  Fam Zheng 
  Gerd Hoffmann 
  Gonglei 
  Isaac Lozano <109loza...@gmail.com>
  Janne Karhunen 
  Jean-Christophe Dubois 
  Kevin Wolf 
  Markus Armbruster 
  Max Reitz 
  Paolo Bonzini 
  Peter Maydell 
  Pooja Dhannawat 
  Ren Kimura 
  Roman Kagan 
  Sascha Silbe 
  Sergey Sorokin 
  Shannon Zhao 
  Stefan Hajnoczi 
  Stefan Weil 
  Sylvain Garrigues 
  Wei Jiangang 
  Wen Congyang 
  xiaoqiang zhao 
  xiaoqiang.zhao 
  zhanghailiang 
  Zhou Jie 

jobs:
 

Re: [Xen-devel] Build problems with xen 4.7

[M A Young]

On Fri, 13 May 2016, Jan Beulich wrote:

> >>> On 13.05.16 at 15:49,  wrote:
> > ...
> > 
> > Still an issue - with 4.7.0-rc1.
> 
> And I don't recall anyone having contributed a fix/workaround.
> 
> > If I do:
> > 
> > $export CFLAGS=" "'
> > $make
> > 
> > I end up with:
> > gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing 
> > -std=gnu99 
> >[...]
> > :0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> > :0:0: note: this is the location of the previous definition
> > :0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
> > :0:0: note: this is the location of the previous definition
> > cc1: all warnings being treated as errors
> > Makefile:62: recipe for target 'compat/callback.i' failed
> 
> My previous recommendation stands: Then just don't do this.

I hacked around it for my test builds (eg. see my test build at
https://copr.fedorainfracloud.org/coprs/myoung/xentest/build/204111/
) by not setting CFLAGS in the environment, but by instead adding the 
recommended Fedora RPM settings into config/StdGNU.mk via a different 
environment variable.

Another thing you might need to know if you are building xen on Fedora 24 
is that you need to add -fno-tree-coalesce-vars if you are on a gcc-6.0.0 
package (it may be fixed in gcc-6.1.1-2.fc24 which has just come out but I 
haven't tested it yet).

Michael Young

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

Re: [Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

[Jan Beulich]

>>> On 13.05.16 at 15:33,  wrote:
> --- a/xen/arch/x86/mm/hap/nested_hap.c
> +++ b/xen/arch/x86/mm/hap/nested_hap.c
> @@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m,
>   * walk is successful, the translated value is returned in
>   * L1_gpa. The result value tells what to do next.
>   */
> -static int
> +int
>  nestedhap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa,
>unsigned int *page_order, uint8_t *p2m_acc,

The function becoming non-static widens the visibility of the bogus
uint8_t here (should be p2m_access_t afaics). Granted this isn't an
issue the patch introduces, but I would prefer this to be adjusted
prior to dropping the static here...

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2081,20 +2081,29 @@ unsigned long paging_gva_to_gfn(struct vcpu *v,
>  
>  if ( is_hvm_vcpu(v) && paging_mode_hap(v->domain) && nestedhvm_is_n2(v) )
>  {
> -unsigned long gfn;
> +unsigned long l2_gfn, l1_gfn;
>  struct p2m_domain *p2m;
>  const struct paging_mode *mode;
> -uint32_t pfec_21 = *pfec;
>  uint64_t np2m_base = nhvm_vcpu_p2m_base(v);
> +uint8_t l1_p2ma;

... avoiding proliferation of the quirkiness.

> +unsigned int l1_page_order;
> +int rv;
>  
>  /* translate l2 guest va into l2 guest gfn */
>  p2m = p2m_get_nestedp2m(v, np2m_base);
>  mode = paging_get_nestedmode(v);
> -gfn = mode->gva_to_gfn(v, p2m, va, pfec);
> +l2_gfn = mode->gva_to_gfn(v, p2m, va, pfec);
> +
> +if ( l2_gfn == INVALID_GFN )
> +return INVALID_GFN;
>  
>  /* translate l2 guest gfn into l1 guest gfn */
> -return hostmode->p2m_ga_to_gfn(v, hostp2m, np2m_base,
> -   gfn << PAGE_SHIFT, _21, NULL);
> +rv = nestedhap_walk_L1_p2m(v, l2_gfn, _gfn, _page_order, 
> _p2ma,
> +   1,
> +   !!(*pfec & PFEC_write_access),
> +   !!(*pfec & PFEC_insn_fetch));
> +
> +return rv == NESTEDHVM_PAGEFAULT_DONE ? l1_gfn : INVALID_GFN;
>  }

I'm really happy to see this getting cleaned up - I've stumbled across
the apparent brokenness here more than once, without ever finding
the time to help the situation. One question though: Is the return
value here correct even for l1_page_order > 0?

Jan


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

Re: [Xen-devel] Build problems with xen 4.7

[Jan Beulich]

>>> On 13.05.16 at 15:49,  wrote:
> On Tue, Dec 01, 2015 at 10:59:41AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue, Dec 01, 2015 at 08:56:03AM -0700, Jan Beulich wrote:
>> > >>> On 01.12.15 at 15:36,  wrote:
>> > > On December 1, 2015 8:19:32 AM EST, Jan Beulich  
>> > > wrote:
>> > > On 01.12.15 at 00:37,  wrote:
>> > >>> When I try to build the current xen 4.7 master I get the following
>> > >>error
>> > >>> 
>> > >>> :0:0: error: "__OBJECT_FILE__" redefined [-Werror]
>> > >>> :0:0: note: this is the location of the previous
>> > >>definition
>> > >>> cc1: all warnings being treated as errors
>> > >>> 
>> > >>> The problem seems to be that -D__OBJECT_FILE__= is set each time 
>> > >>> xen/Rules.mk is called, which happens more than once because of
>> > >>nested 
>> > >>> makes resulting in multiple diffent values for -D__OBJECT_FILE__=
>> > >>
>> > >>Considering you're the first one to have such a problem, I think the
>> > >>precise compiler version you use matters here. Also the redundant
>> > >>definitions shouldn't be different, and identical re-definition should
>> > >>not yield a diagnostic. So I think there's a little more data you need
>> > >>to supply in order to determine whether we need to adjust something.
>> > >>
>> > > 
>> > > Ccing Marcos who also saw this. Marcos do you remember the git commit 
>> > > that 
> 
>> > > caused this?
>> > 
>> > There's no question about when this got introduced. What we need
>> > to understand is why this is an issue only for very few people.
>> 
>> It is only an issue when doing rpmbuilds.
>> 
> 
> Still an issue - with 4.7.0-rc1.

And I don't recall anyone having contributed a fix/workaround.

> If I do:
> 
> $export CFLAGS=" "'
> $make
> 
> I end up with:
> gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing 
> -std=gnu99 
>[...]
> :0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> :0:0: note: this is the location of the previous definition
> :0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
> :0:0: note: this is the location of the previous definition
> cc1: all warnings being treated as errors
> Makefile:62: recipe for target 'compat/callback.i' failed

My previous recommendation stands: Then just don't do this.

Jan


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

Re: [Xen-devel] Build problems with xen 4.7

[Konrad Rzeszutek Wilk]

On Tue, Dec 01, 2015 at 10:59:41AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 01, 2015 at 08:56:03AM -0700, Jan Beulich wrote:
> > >>> On 01.12.15 at 15:36,  wrote:
> > > On December 1, 2015 8:19:32 AM EST, Jan Beulich  wrote:
> > > On 01.12.15 at 00:37,  wrote:
> > >>> When I try to build the current xen 4.7 master I get the following
> > >>error
> > >>> 
> > >>> :0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> > >>> :0:0: note: this is the location of the previous
> > >>definition
> > >>> cc1: all warnings being treated as errors
> > >>> 
> > >>> The problem seems to be that -D__OBJECT_FILE__= is set each time 
> > >>> xen/Rules.mk is called, which happens more than once because of
> > >>nested 
> > >>> makes resulting in multiple diffent values for -D__OBJECT_FILE__=
> > >>
> > >>Considering you're the first one to have such a problem, I think the
> > >>precise compiler version you use matters here. Also the redundant
> > >>definitions shouldn't be different, and identical re-definition should
> > >>not yield a diagnostic. So I think there's a little more data you need
> > >>to supply in order to determine whether we need to adjust something.
> > >>
> > > 
> > > Ccing Marcos who also saw this. Marcos do you remember the git commit 
> > > that 
> > > caused this?
> > 
> > There's no question about when this got introduced. What we need
> > to understand is why this is an issue only for very few people.
> 
> It is only an issue when doing rpmbuilds.
> 

Still an issue - with 4.7.0-rc1.

If I do:

$export CFLAGS=" "'
$make

I end up with:
gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing 
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement 
-Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 
-fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 
-Wall -Wstrict-prototypes -Wdeclaration-after-statement 
-Wno-unused-but-set-variable -Wno-unused-local-typedefs -nostdinc -fno-builtin 
-fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ 
'-D__OBJECT_FILE__="/home/konrad/ssd/konrad/xen/xen/xen"' 
-Wa,--strip-local-absolute -fno-optimize-sibling-calls -DVERBOSE 
-fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -fno-optimize-sibling-calls 
-I/home/konrad/ssd/konrad/xen/xen/include 
-I/home/konrad/ssd/konrad/xen/xen/include/asm-x86/mach-generic 
-I/home/konrad/ssd/konrad/xen/xen/include/asm-x86/mach-default 
'-D__OBJECT_LABEL__=omeonradsdonradenen$homeonradsdonradenenen' -msoft-float 
-fno-stack-protector -fno-exceptions -Wnested-externs -mno-red-zone -mno-sse 
-fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -O1 
-fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 
-Wall -Wstrict-prototypes -Wdeclaration-after-statement 
-Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 
-fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 
-Wall -Wstrict-prototypes -Wdeclaration-after-statement 
-Wno-unused-but-set-variable -Wno-unused-local-typedefs -nostdinc -fno-builtin 
-fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ 
'-D__OBJECT_FILE__="compat/callback.i"' -Wa,--strip-local-absolute 
-fno-optimize-sibling-calls -DVERBOSE -fno-omit-frame-pointer 
-DCONFIG_FRAME_POINTER -fno-optimize-sibling-calls 
-I/home/konrad/ssd/konrad/xen/xen/include 
-I/home/konrad/ssd/konrad/xen/xen/include/asm-x86/mach-generic 
-I/home/konrad/ssd/konrad/xen/xen/include/asm-x86/mach-default 
'-D__OBJECT_LABEL__=include$compat$callback.i' -msoft-float 
-fno-stack-protector -fno-exceptions -Wnested-externs -mno-red-zone -mno-sse 
-fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -O1 
-fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 
-Wall -Wstrict-prototypes -Wdeclaration-after-statement 
-Wno-unused-but-set-variable -Wno-unused-local-typedefs -include 
public/xen-compat.h -m32 -o compat/callback.i compat/callback.c
:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
:0:0: note: this is the location of the previous definition
:0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
:0:0: note: this is the location of the previous definition
cc1: all warnings being treated as errors
Makefile:62: recipe for target 'compat/callback.i' failed


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

Re: [Xen-devel] Stubdom compilation failure on Fedora 24 beta

[Wei Liu]

Hi Marek

On Fri, May 13, 2016 at 02:35:21PM +0200, Marek Marczykowski-Górecki wrote:
> Hi,
> 
> I'm trying to build Xen 4.6.1 on Fedora 24 beta. Since gcc 6, I need to pull
> some patches from unstable, but then I hit some strange problem:
> 
> During configure run in stubdom/gmp-x86_64 I've got:
> 
> checking size of unsigned short... configure: error: cannot compute 
> sizeof (unsigned short)
> See `config.log' for more details.
> 
> It turned out the failing line in conftest is:
> 
> return ferror (f) || fclose (f) != 0;
> 
> ferror(f) returned 1.
> That's strange, when running under gdb, manually checking ferror(f) (`p
> ferror(f)`) returns 0. So I've looked at code produced (after slight
> modification to have "if (ferror(f)) ..."), ferror(f) was turned to:
> 
> 0x0040063d <+55>:testb  $0x40,0x10(%rbx)
> 
> This doesn't look like ferror from glibc. And 0x40 is not _IO_ERR_SEEN (0x20).
> 
> This looks like ferror from newlib 
> (stubdom/newlib-1.16.0/newlib/libc/include/stdio.h):
> 
> #define __SERR  0x0040  /* found error */
> #define __sferror(p)(((p)->_flags & __SERR) != 0)
> #define ferror(p)   __sferror(p)
> 

Yes, it should be from newlib. This is expected because stubdom uses
newlib after all.

> 
> Configure is called this way (stubdom/Makefile):
> cd $@; CPPFLAGS="-isystem 
> $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include $(TARGET_CPPFLAGS)" 
> CFLAGS="$(TARGET_CFLAGS)" CC=$(CC) $(GMPEXT) ./configure --disable-shared 
> --enable-static --disable-fft --without-readline 
> --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf
> 
> And indeed $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include contains headers
> from newlib.
> 
> Any idea how to fix this? And why it was working before?
> 

You're not the first one that got bitten by this.

Search for

Error compiling Xen in configuring stubdom/gmp with glibc-2.23 on Arch Linux

or message-id

<1457311127.3237075.541322218.485cf...@webmail.messagingengine.com>

in xen-users@ archive.

The thread contains some analysis, but it's not yet complete.

There are two possibilities that I can think of off the top of my head:
1. the cross-build environment is buggy 2. newlib bit-rots too much.

The first requires fixing the build environment, the second requires
patching newlib (preferable imo) or upgrading it to a newer version.

It's on our radar but Ian and I are working on other things at the
moment.

Wei.

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

[Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

[Andrew Cooper]

hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a
general L1 p2m walk.  It is fine for AMD as NPT share the same format as
normal pagetables.  For Intel EPT however, it is wrong.

The translation ends up correct (as the formats are sufficiently similar), but
the control bits in lower 12 bits differ in meaning.  A plain PT walker sets
A/D bits (bits 5 and 6) as it walks, but in EPT tables, these are the IPAT and
top bit of EMT (caching type).  This in turn causes problem when the EPT
tables are subsequently used.

Replace hostmode->p2m_ga_to_gfn() with nestedhap_walk_L1_p2m() in
paging_gva_to_gfn(), which is the correct function for the task.  This
involves making nestedhap_walk_L1_p2m() non-static, and adding
vmx_vmcs_enter/exit() pairs to nvmx_hap_walk_L1_p2m() as it is now reachable
from contexts other than v == current.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: George Dunlap 
CC: Tim Deegan 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Wei Liu 
---
 xen/arch/x86/hvm/vmx/vvmx.c |  4 
 xen/arch/x86/mm/hap/nested_hap.c|  2 +-
 xen/arch/x86/mm/p2m.c   | 19 ++-
 xen/include/asm-x86/hvm/nestedhvm.h |  4 
 4 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 35f3687..faa8b69 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2036,6 +2036,8 @@ nvmx_hap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, 
paddr_t *L1_gpa,
 uint32_t rwx_rights = (access_x << 2) | (access_w << 1) | access_r;
 struct nestedvmx *nvmx = _2_nvmx(v);
 
+vmx_vmcs_enter(v);
+
 __vmread(EXIT_QUALIFICATION, _qual);
 rc = nept_translate_l2ga(v, L2_gpa, page_order, rwx_rights, , p2m_acc,
  _qual, _reason);
@@ -2060,6 +2062,8 @@ nvmx_hap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, 
paddr_t *L1_gpa,
 break;
 }
 
+vmx_vmcs_exit(v);
+
 return rc;
 }
 
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index 9cee5a0..d41bb09 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m,
  * walk is successful, the translated value is returned in
  * L1_gpa. The result value tells what to do next.
  */
-static int
+int
 nestedhap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa,
   unsigned int *page_order, uint8_t *p2m_acc,
   bool_t access_r, bool_t access_w, bool_t access_x)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 94eabf6..de5791b 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2081,20 +2081,29 @@ unsigned long paging_gva_to_gfn(struct vcpu *v,
 
 if ( is_hvm_vcpu(v) && paging_mode_hap(v->domain) && nestedhvm_is_n2(v) )
 {
-unsigned long gfn;
+unsigned long l2_gfn, l1_gfn;
 struct p2m_domain *p2m;
 const struct paging_mode *mode;
-uint32_t pfec_21 = *pfec;
 uint64_t np2m_base = nhvm_vcpu_p2m_base(v);
+uint8_t l1_p2ma;
+unsigned int l1_page_order;
+int rv;
 
 /* translate l2 guest va into l2 guest gfn */
 p2m = p2m_get_nestedp2m(v, np2m_base);
 mode = paging_get_nestedmode(v);
-gfn = mode->gva_to_gfn(v, p2m, va, pfec);
+l2_gfn = mode->gva_to_gfn(v, p2m, va, pfec);
+
+if ( l2_gfn == INVALID_GFN )
+return INVALID_GFN;
 
 /* translate l2 guest gfn into l1 guest gfn */
-return hostmode->p2m_ga_to_gfn(v, hostp2m, np2m_base,
-   gfn << PAGE_SHIFT, _21, NULL);
+rv = nestedhap_walk_L1_p2m(v, l2_gfn, _gfn, _page_order, 
_p2ma,
+   1,
+   !!(*pfec & PFEC_write_access),
+   !!(*pfec & PFEC_insn_fetch));
+
+return rv == NESTEDHVM_PAGEFAULT_DONE ? l1_gfn : INVALID_GFN;
 }
 
 return hostmode->gva_to_gfn(v, hostp2m, va, pfec);
diff --git a/xen/include/asm-x86/hvm/nestedhvm.h 
b/xen/include/asm-x86/hvm/nestedhvm.h
index cf1a8f4..bc82425 100644
--- a/xen/include/asm-x86/hvm/nestedhvm.h
+++ b/xen/include/asm-x86/hvm/nestedhvm.h
@@ -56,6 +56,10 @@ bool_t nestedhvm_vcpu_in_guestmode(struct vcpu *v);
 int nestedhvm_hap_nested_page_fault(struct vcpu *v, paddr_t *L2_gpa,
 bool_t access_r, bool_t access_w, bool_t access_x);
 
+int nestedhap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa,
+  unsigned int *page_order, uint8_t *p2m_acc,
+  bool_t access_r, bool_t access_w, bool_t access_x);
+
 /* IO permission map */
 unsigned long *nestedhvm_vcpu_iomap_get(bool_t ioport_80, bool_t 

[Xen-devel] Stubdom compilation failure on Fedora 24 beta

[Marek Marczykowski-Górecki]

Hi,

I'm trying to build Xen 4.6.1 on Fedora 24 beta. Since gcc 6, I need to pull
some patches from unstable, but then I hit some strange problem:

During configure run in stubdom/gmp-x86_64 I've got:

checking size of unsigned short... configure: error: cannot compute sizeof 
(unsigned short)
See `config.log' for more details.

It turned out the failing line in conftest is:

return ferror (f) || fclose (f) != 0;

ferror(f) returned 1.
That's strange, when running under gdb, manually checking ferror(f) (`p
ferror(f)`) returns 0. So I've looked at code produced (after slight
modification to have "if (ferror(f)) ..."), ferror(f) was turned to:

0x0040063d <+55>:testb  $0x40,0x10(%rbx)

This doesn't look like ferror from glibc. And 0x40 is not _IO_ERR_SEEN (0x20).

This looks like ferror from newlib 
(stubdom/newlib-1.16.0/newlib/libc/include/stdio.h):

#define __SERR  0x0040  /* found error */
#define __sferror(p)(((p)->_flags & __SERR) != 0)
#define ferror(p)   __sferror(p)


Configure is called this way (stubdom/Makefile):
cd $@; CPPFLAGS="-isystem 
$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include $(TARGET_CPPFLAGS)" 
CFLAGS="$(TARGET_CFLAGS)" CC=$(CC) $(GMPEXT) ./configure --disable-shared 
--enable-static --disable-fft --without-readline 
--prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf

And indeed $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include contains headers
from newlib.

Any idea how to fix this? And why it was working before?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] panic("queue invalidate wait descriptor was not executed\n")

[Wu, Feng]

> > > >This is what I've been remembering:
> > > >
> > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=84c340ba4c3eb9
> > > 927
> > > > 8b6ba885616bb183b88ad67
> > >
> > > The comment on this link describes exactly what I am experiencing.
> > > Thanks so much.
> >
> > Thanks Jan for providing the information above. Kelly, if you still met the 
> > same
> > issue after applying the patches, let us know, maybe I can consult some
> > hardware expert internally.
> 
> Turns out this was exactly my problem.  The description matched my symptoms
> and when I applied the patch the problem has gone away.
> Thanks,
> Kelly
> 

Good to hear this! :)

Thanks,
Feng

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

Re: [Xen-devel] panic("queue invalidate wait descriptor was not executed\n")

[Zytaruk, Kelly]

> -Original Message-
> From: Wu, Feng [mailto:feng...@intel.com]
> Sent: Friday, May 13, 2016 3:11 AM
> To: Zytaruk, Kelly; Jan Beulich
> Cc: Tian, Kevin; xen-devel@lists.xen.org; Wu, Feng
> Subject: RE: [Xen-devel] panic("queue invalidate wait descriptor was not
> executed\n")
> 
> 
> 
> > -Original Message-
> > From: Zytaruk, Kelly [mailto:kelly.zyta...@amd.com]
> > Sent: Thursday, May 12, 2016 10:21 PM
> > To: Jan Beulich 
> > Cc: Wu, Feng ; Tian, Kevin ;
> > xen- de...@lists.xen.org
> > Subject: RE: [Xen-devel] panic("queue invalidate wait descriptor was
> > not
> > executed\n")
> >
> >
> >
> > > -Original Message-
> > > From: Jan Beulich [mailto:jbeul...@suse.com]
> > > Sent: Thursday, May 12, 2016 9:51 AM
> > > To: Zytaruk, Kelly
> > > Cc: Feng Wu; Kevin Tian; xen-devel@lists.xen.org
> > > Subject: RE: [Xen-devel] panic("queue invalidate wait descriptor was
> > > not
> > > executed\n")
> > >
> > > >>> On 12.05.16 at 14:36,  wrote:
> > > >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > > >> Sent: Thursday, May 12, 2016 5:49 AM
> > > >> >>> On 11.05.16 at 15:51,  wrote:
> > > >> > During Xen boot I am seeing the panic in the subject line from
> > > >> > .../xen/drivers/passthrough/vgt/qinval.c
> > > >>
> > > >> And this is with current staging, or some much older version of Xen?
> > > >> (ISTR some issue with the invalidation request getting sent to
> > > >> the wrong IOMMU, leading to a timeout.)
> > > >
> > > > No this is not current Xen, it is with 4.2.
> > > >
> > > > Can you tell me more about the invalidation request getting sent
> > > > to the wrong IOMMU problem and approximately when it was fixed?
> > > > If you could identify the patch I could back port it into my copy of 
> > > > Xen for
> testing.
> > >
> > > Note that 4.2.5 has said change, and also note that you could have
> > > done
> > exactly
> > > what I have done now - go through the list of commits altering files
> > > in the vtd/ subtree.
> >
> > Unfortunately GIT is not my strong suit :( I am still learning to
> > navigate with it. I guess part of my problem with GIT is that I don't yet 
> > know
> what I don't know.
> >
> > >This is what I've been remembering:
> > >
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=84c340ba4c3eb9
> > 927
> > > 8b6ba885616bb183b88ad67
> >
> > The comment on this link describes exactly what I am experiencing.
> > Thanks so much.
> 
> Thanks Jan for providing the information above. Kelly, if you still met the 
> same
> issue after applying the patches, let us know, maybe I can consult some
> hardware expert internally.

Turns out this was exactly my problem.  The description matched my symptoms and 
when I applied the patch the problem has gone away.
Thanks,
Kelly

> 
> Thanks,
> Feng
> 
> >
> > >
> > > Jan


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

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Jan Beulich]

>>> On 12.05.16 at 17:25,  wrote:
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1294,6 +1294,43 @@ int relinquish_shared_pages(struct domain *d)
>  return rc;
>  }
>  
> +static int bulk_share(struct domain *d, struct domain *cd, unsigned long max,
> +  struct mem_sharing_op_bulk *bulk)
> +{
> +int rc;
> +shr_handle_t sh, ch;
> +
> +while( bulk->start <= max )
> +{
> +rc = mem_sharing_nominate_page(d, bulk->start, 0, );
> +if ( rc == -ENOMEM )
> +break;
> +if ( !rc )
> +{
> +rc = mem_sharing_nominate_page(cd, bulk->start, 0, );
> +if ( rc == -ENOMEM )
> +break;

If we get to this break, how will the caller know that the first
nomination succeeded but the second didn't? Or perhaps there
is some undo logic missing here?

> +if ( !rc )
> +mem_sharing_share_pages(d, bulk->start, sh, cd, bulk->start, 
> ch);

You shouldn't be ignoring errors here.

> +}
> +
> +++(bulk->start);

Pointless parentheses.

> +/* Check for continuation if it's not the last iteration. */
> +if ( bulk->start < max && hypercall_preempt_check() )

The loop head has <=; why < here?

> +{
> +rc = 1;

I'd recommend using -ERESTART here, as we do elsewhere.

> +break;
> +}
> +}
> +
> +/* We only propagate -ENOMEM so reset rc here */
> +if ( rc < 0 && rc != -ENOMEM )
> +rc = 0;

What's the rationale for discarding all other errors? At least the
patch description, but perhaps even the comment (which btw
is lacking a full stop) should be explaining this.

> @@ -1468,6 +1505,69 @@ int 
> mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>  }
>  break;
>  
> +case XENMEM_sharing_op_bulk_share:
> +{
> +unsigned long max_sgfn, max_cgfn;
> +struct domain *cd;
> +
> +rc = -EINVAL;
> +if ( !mem_sharing_enabled(d) )
> +goto out;
> +
> +rc = rcu_lock_live_remote_domain_by_id(mso.u.bulk.client_domain,
> +   );
> +if ( rc )
> +goto out;
> +
> +rc = xsm_mem_sharing_op(XSM_DM_PRIV, d, cd, mso.op);

Either you pass XENMEM_sharing_op_share here, or you need to
update xen/xsm/flask/policy/access_vectors (even if it's only a
comment which needs updating).

That said - are this and the similar pre-existing XSM checks actually
correct? I.e. is one of the two domains here really controlling the
other? I would have expected that a tool stack domain initiates the
sharing between two domains it controls...

> +if ( rc )
> +{
> +rcu_unlock_domain(cd);
> +goto out;
> +}
> +
> +if ( !mem_sharing_enabled(cd) )
> +{
> +rcu_unlock_domain(cd);
> +rc = -EINVAL;
> +goto out;
> +}
> +
> +if ( !atomic_read(>pause_count) ||
> + !atomic_read(>pause_count) )
> +{
> +rcu_unlock_domain(cd);
> +rc = -EINVAL;
> +goto out;
> +}
> +
> +max_sgfn = domain_get_maximum_gpfn(d);
> +max_cgfn = domain_get_maximum_gpfn(cd);
> +
> +if ( max_sgfn != max_cgfn || max_sgfn < mso.u.bulk.start )

Why would the two domains need to agree in their maximum
GPFN? There's nothing similar in this file so far. Nor does the
right side of the || match anything pre-existing...

> @@ -488,7 +489,18 @@ struct xen_mem_sharing_op {
>  uint64_aligned_t client_gfn;/* IN: the client gfn */
>  uint64_aligned_t client_handle; /* IN: handle to the client page 
> */
>  domid_t  client_domain; /* IN: the client domain id */
> -} share; 
> +} share;
> +struct mem_sharing_op_bulk { /* OP_BULK_SHARE */
> +uint64_aligned_t start;  /* IN: start gfn. Set to 0 for
> +full deduplication. Field is
> +used internally and may 
> change
> +when the hypercall returns. 
> */
> +uint64_aligned_t shared; /* OUT: the number of gfns
> +that are shared after this
> +operation including pages
> +already shared before */
> +domid_t client_domain;   /* IN: the client domain id */
> +} bulk;

Let's not repeat pre-existing mistakes: There is explicit padding
missing here, which then also ought to be checked to be zero on
input.

Jan

Re: [Xen-devel] [PATCH V9] vm_event: Allow subscribing to write events for specific MSR-s

[Jan Beulich]

>>> On 06.05.16 at 16:33,  wrote:
> Previously, subscribing to MSR write events was an all-or-none
> approach, with special cases for introspection MSR-s. This patch
> allows the vm_event consumer to specify exactly what MSR-s it is
> interested in, and as a side-effect gets rid of the
> vmx_introspection_force_enabled_msrs[] special case.
> The patch also introduces arch_monitor_init_domain() and
> arch_monitor_cleanup_domain(), to do monitor-specific work
> (as opposed to the previous way of doing all the setup in
> vm_event_init_domain() / vm_event_cleanup_domain()).
> This replaces the previously posted "xen: Filter out MSR write
> events" patch.
> 
> Signed-off-by: Razvan Cojocaru 
> Acked-by: Wei Liu 
> Acked-by: Kevin Tian 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] Xen Security Advisory 173 (CVE-2016-3960) - x86 shadow pagetables: address width overflow

[Jan Beulich]

>>> On 13.05.16 at 12:55,  wrote:
> Am 18.04.2016 um 15:31 schrieb Xen.org security team:
>> +/*
>> + * Bit 24 of a 24-bit flag mask!  This is not any bit of a real pte,
>> + * and is only used for signalling in variables that contain flags.
>> + */
>> +#define _PAGE_INVALID_BIT (1U<<24)
>> +
>>  #endif /* __X86_64_PAGE_H__ */
> 
> I guess using bit 24 is okay for 32 bit, too.
> 
> Can someone confirm that please?

Yes, that should be fine.

Jan


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

Re: [Xen-devel] [PATCH net-next v4 2/4] xen-netback: add control protocol implementation

[Wei Liu]

On Fri, May 13, 2016 at 09:37:27AM +0100, Paul Durrant wrote:
> My recent patch to include/xen/interface/io/netif.h defines a new shared
> ring (in addition to the rx and tx rings) for passing control messages
> from a VM frontend driver to a backend driver.
> 
> A previous patch added the necessary boilerplate for mapping the control
> ring from the frontend, should it be created. This patch adds
> implementations for each of the defined protocol messages.
> 
> Signed-off-by: Paul Durrant 
> Cc: Wei Liu 

Acked-by: Wei Liu 

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

Re: [Xen-devel] Xen Security Advisory 173 (CVE-2016-3960) - x86 shadow pagetables: address width overflow

[Philipp Hahn]

Hi,


Am 18.04.2016 um 15:31 schrieb Xen.org security team:
> Xen Security Advisory CVE-2016-3960 / XSA-173
>   version 3
> 
>  x86 shadow pagetables: address width overflow
...
> ISSUE DESCRIPTION
> =
> In the x86 shadow pagetable code, the guest frame number of a
> superpage mapping is stored in a 32-bit field.  If a shadowed guest
> can cause a superpage mapping of a guest-physical address at or above
> 2^44 to be shadowed, the top bits of the address will be lost, causing
> an assertion failure or NULL dereference later on, in code that
> removes the shadow.
...
> VULNERABLE SYSTEMS
> ==
> Xen versions from 3.4 onwards are affected.
> 
> Only x86 variants of Xen are susceptible.  ARM variants are not
> affected.
...
> RESOLUTION
> ==
> Applying the appropriate attached patch resolves this issue.
...
> xsa173-4.3.patch   Xen 4.3.x

As Xen-4.2 and xen-4.1 are also vulnerable, I'm trying to backport this.
The 4.3 patch applies mostly, but compilation fails as x86-32-bit
support was dropped with Xen-4.3 and  _PAGE_INVALID_BIT remains
undefined for x86-32:
> guest_walk.c: In function 'mandatory_flags':
> guest_walk.c:66:40: error: '_PAGE_INVALID_BIT' undeclared (first use in this 
> function)
> guest_walk.c:66:40: note: each undeclared identifier is reported only once 
> for each function it appears in
> guest_walk.c: In function 'guest_walk_tables_2_levels':
> guest_walk.c:146:30: error: '_PAGE_INVALID_BIT' undeclared (first use in this 
> function)
> guest_walk.c: In function 'mandatory_flags':
> guest_walk.c:67:1: error: control reaches end of non-void function 
> [-Werror=return-type]

It's only defined for x86-64:
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
...
> +/*
> + * Bit 24 of a 24-bit flag mask!  This is not any bit of a real pte,
> + * and is only used for signalling in variables that contain flags.
> + */
> +#define _PAGE_INVALID_BIT (1U<<24)
> +
>  #endif /* __X86_64_PAGE_H__ */

I guess using bit 24 is okay for 32 bit, too.

Can someone confirm that please?

Philipp

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

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

[Wei Liu]

On Fri, May 13, 2016 at 04:52:43AM -0600, Jan Beulich wrote:
> >>> On 13.05.16 at 12:41,  wrote:
> > On Fri, May 13, 2016 at 10:33:08AM +, osstest service owner wrote:
> >> flight 94059 xen-4.6-testing real [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/94059/ 
> >> 
> >> Regressions :-(
> >> 
> >> Tests which did not succeed and are blocking,
> >> including tests which could not be run:
> >>  build-i386-libvirt5 libvirt-build fail REGR. vs. 
> > 93932
> >>  build-amd64-libvirt   5 libvirt-build fail REGR. vs. 
> > 93932
> >>  build-armhf-libvirt   5 libvirt-build fail REGR. vs. 
> > 93932
> > 
> > This is fixed by d5b6844942f7b21b24e92bccd85c1249592315c8 in
> > xen-unstable.
> 
> Well, the change looks harmless enough (albeit not like something
> we would normally backport), but why are these old declarations
> causing problems all of the sudden in the first place?
> 

Libvirt changed to explicitly require a specific version of libxl.
Previously another snippet of code was built.

So I would say this is a latent problem exposed by libvirt change.

Wei.

> Jan
> 

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

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

[Jan Beulich]

>>> On 13.05.16 at 12:41,  wrote:
> On Fri, May 13, 2016 at 10:33:08AM +, osstest service owner wrote:
>> flight 94059 xen-4.6-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/94059/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  build-i386-libvirt5 libvirt-build fail REGR. vs. 
> 93932
>>  build-amd64-libvirt   5 libvirt-build fail REGR. vs. 
> 93932
>>  build-armhf-libvirt   5 libvirt-build fail REGR. vs. 
> 93932
> 
> This is fixed by d5b6844942f7b21b24e92bccd85c1249592315c8 in
> xen-unstable.

Well, the change looks harmless enough (albeit not like something
we would normally backport), but why are these old declarations
causing problems all of the sudden in the first place?

Jan


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

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

[Jan Beulich]

>>> On 13.05.16 at 12:33,  wrote:
> flight 94059 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/94059/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-libvirt5 libvirt-build fail REGR. vs. 
> 93932
>  build-amd64-libvirt   5 libvirt-build fail REGR. vs. 
> 93932
>  build-armhf-libvirt   5 libvirt-build fail REGR. vs. 
> 93932

Since what is under test are just qemu updates, I'm puzzled by

In file included from 
/home/osstest/build.94059.build-amd64-libvirt/xendist/usr/local/include/libxl.h:426:0,
 from libxl/libxl_domain.h:27,
 from libxl/libxl_domain.c:28:
/home/osstest/build.94059.build-amd64-libvirt/xendist/usr/local/include/libxl_uuid.h:64:1:
 error: 'static' is not at beginning of declaration 
[-Werror=old-style-declaration]
 void static inline libxl_uuid_copy_0x040400(libxl_uuid *dst,
 ^
/home/osstest/build.94059.build-amd64-libvirt/xendist/usr/local/include/libxl_uuid.h:64:1:
 error: 'inline' is not at beginning of declaration 
[-Werror=old-style-declaration]
cc1: all warnings being treated as errors
Makefile:8547: recipe for target 
'libxl/libvirt_driver_libxl_impl_la-libxl_domain.lo' failed
make[3]: *** [libxl/libvirt_driver_libxl_impl_la-libxl_domain.lo] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from 
/home/osstest/build.94059.build-amd64-libvirt/xendist/usr/local/include/libxl.h:426:0,
 from libxl/libxl_conf.c:30:
/home/osstest/build.94059.build-amd64-libvirt/xendist/usr/local/include/libxl_uuid.h:64:1:
 error: 'static' is not at beginning of declaration 
[-Werror=old-style-declaration]
 void static inline libxl_uuid_copy_0x040400(libxl_uuid *dst,
 ^
/home/osstest/build.94059.build-amd64-libvirt/xendist/usr/local/include/libxl_uuid.h:64:1:
 error: 'inline' is not at beginning of declaration 
[-Werror=old-style-declaration]
cc1: all warnings being treated as errors
Makefile:8540: recipe for target 
'libxl/libvirt_driver_libxl_impl_la-libxl_conf.lo' failed
make[3]: *** [libxl/libvirt_driver_libxl_impl_la-libxl_conf.lo] Error 1
In file included from 
/home/osstest/build.94059.build-amd64-libvirt/xendist/usr/local/include/libxl.h:426:0,
 from libxl/libxl_driver.c:31:
/home/osstest/build.94059.build-amd64-libvirt/xendist/usr/local/include/libxl_uuid.h:64:1:
 error: 'static' is not at beginning of declaration 
[-Werror=old-style-declaration]
 void static inline libxl_uuid_copy_0x040400(libxl_uuid *dst,
 ^
/home/osstest/build.94059.build-amd64-libvirt/xendist/usr/local/include/libxl_uuid.h:64:1:
 error: 'inline' is not at beginning of declaration 
[-Werror=old-style-declaration]
cc1: all warnings being treated as errors

suggesting some build setting changed on the libvirt side, or the
compiler got updated on the build host. The declarations indeed look
odd, but this must have been building fine before...

Jan


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

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

[osstest service owner]

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

Failures and problems with tests :-(

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

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

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z   96 days
Testing same since93977  2016-05-10 11:09:16 Z2 days4 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

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

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

[Wei Liu]

On Fri, May 13, 2016 at 10:33:08AM +, osstest service owner wrote:
> flight 94059 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/94059/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-libvirt5 libvirt-build fail REGR. vs. 
> 93932
>  build-amd64-libvirt   5 libvirt-build fail REGR. vs. 
> 93932
>  build-armhf-libvirt   5 libvirt-build fail REGR. vs. 
> 93932

This is fixed by d5b6844942f7b21b24e92bccd85c1249592315c8 in
xen-unstable.

Wei.

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

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93932
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 93932
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93932

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

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

Last test of basis93932  2016-05-09 21:11:10 Z3 days
Failing since 94000  2016-05-10 18:10:33 Z2 days3 attempts
Testing same since94036  2016-05-11 15:51:26 Z1 days2 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  

Re: [Xen-devel] live migrating hvm from 4.4 to 4.5 fails due to kvmvapic

[Wei Liu]

On Thu, May 12, 2016 at 05:48:13PM +0200, Olaf Hering wrote:
> Migrating a HVM guest from staging-4.4 to staging-4.5 fails:
> 
> # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> char device redirected to /dev/pts/4 (label serial0)
> xen_ram_alloc: do not alloc f80 bytes of ram at 0 when runstate is 
> INMIGRATE
> xen_ram_alloc: do not alloc 80 bytes of ram at f80 when runstate is 
> INMIGRATE
> xen_ram_alloc: do not alloc 1 bytes of ram at 1000 when runstate is 
> INMIGRATE
> xen_ram_alloc: do not alloc 4 bytes of ram at 1001 when runstate is 
> INMIGRATE
> Unknown savevm section or instance 'kvm-tpr-opt' 0
> qemu-system-i386: load of migration failed: Invalid argument
> 
> 
> Initially I thought we broke our sles12 xen, but for some reason xen.git fails
> in the very same way. In 4.4 kvmvapic gets enabled, it gets migrated in the
> "kvm-tpr-opt" VMStateDescription. The 4.5 qemu does not know about it because
> 'kvmvapic' is not enabled. As a result the entire savevm stream is rejected.
> 
> One thing to fix it in staging-4.5 is to introduce a dummy device which
> handles a section named "kvm-tpr-opt". I already have a hack which does
> that, and the migration proceeds. I will propose a patch to deal with
> this part of the bug.
> 
> Unfortunately later the VM appears to be alive, but nothing happens in
> it. I assume it gets no further interrupts. Guess I need help with this
> part of the bug.
> 
> 

My fear is that the VM might actually be poking at that device. That
explains why the migration is successful but the VM is not functioning.
I think the first thing would be to confirm whether the guest is
actually using that device.

For newly created guest on xen 4.4, you will need some rune in guest cfg
file to explicitly disable that device. There is device_model_args=
option for you to do that.

For guests that are already running, you can try to massage the guest
cfg before sending, post receiving but before creating, or hack libxl to
add that kvm device.

But all things said above are just workaround. Unfortunately I don't see
an easy way of solving this off the top of my head.

Wei.

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

Re: [Xen-devel] live migrating hvm from 4.4 to 4.5 fails due to kvmvapic

[Stefano Stabellini]

On Thu, 12 May 2016, Olaf Hering wrote:
> On Thu, May 12, Olaf Hering wrote:
> 
> > One thing to fix it in staging-4.5 is to introduce a dummy device which
> > handles a section named "kvm-tpr-opt". I already have a hack which does
> > that, and the migration proceeds. I will propose a patch to deal with
> > this part of the bug.
> 
> Something like shown below.

Thanks for looking into this. I don't think that adding a dummy device
in QEMU is acceptable. This kind of problems is usually solved with
versioning the PC machine in QEMU, see all the pc_machine_* in
hw/i386/pc_piix.c. One specific version of the machine is supposed to
remain identical over multiple QEMU releases. In this case xenfv (or the
pc machine you are using, if you are not using xenfv) has to be always
identical. That's why I think we need to add kvmapic back to it for
compatibility. I know it sucks. But we can choose a different PC machine
with accel=xen for new VMs. 


> > Unfortunately later the VM appears to be alive, but nothing happens in
> > it. I assume it gets no further interrupts. Guess I need help with this
> > part of the bug.
> 
> 
>
> 
> ---
>  hw/i386/Makefile.objs|1 
>  hw/i386/xen44_kvmvapic.c |  147 
> +++
>  xen-hvm.c|3 
>  3 files changed, 151 insertions(+)
> 
> --- a/hw/i386/Makefile.objs
> +++ b/hw/i386/Makefile.objs
> @@ -5,6 +5,7 @@ obj-y += pc_sysfw.o
>  obj-$(CONFIG_XEN) += ../xenpv/ xen/
>  
>  obj-y += kvmvapic.o
> +obj-y += xen44_kvmvapic.o
>  obj-y += acpi-build.o
>  obj-y += bios-linker-loader.o
>  hw/i386/acpi-build.o: hw/i386/acpi-build.c hw/i386/acpi-dsdt.hex \
> --- /dev/null
> +++ b/hw/i386/xen44_kvmvapic.c
> @@ -0,0 +1,147 @@
> +/*
> + * Copy of kvmvapic to allow migration from xen-4.4 qemu-xen with 
> "kvm-tpr-opt"
> + *
> + * Copyright (C) 2007-2008 Qumranet Technologies
> + * Copyright (C) 2012  Jan Kiszka, Siemens AG
> + *
> + * This work is licensed under the terms of the GNU GPL version 2, or
> + * (at your option) any later version. See the COPYING file in the
> + * top-level directory.
> + */
> +#include "sysemu/sysemu.h"
> +#include "sysemu/cpus.h"
> +#include "sysemu/kvm.h"
> +#include "hw/i386/apic_internal.h"
> +#include "hw/sysbus.h"
> +#include "hw/xen/xen.h"
> +
> +typedef struct VAPICHandlers {
> +uint32_t set_tpr;
> +uint32_t set_tpr_eax;
> +uint32_t get_tpr[8];
> +uint32_t get_tpr_stack;
> +} QEMU_PACKED VAPICHandlers;
> +
> +typedef struct GuestROMState {
> +char signature[8];
> +uint32_t vaddr;
> +uint32_t fixup_start;
> +uint32_t fixup_end;
> +uint32_t vapic_vaddr;
> +uint32_t vapic_size;
> +uint32_t vcpu_shift;
> +uint32_t real_tpr_addr;
> +VAPICHandlers up;
> +VAPICHandlers mp;
> +} QEMU_PACKED GuestROMState;
> +
> +typedef struct VAPICROMState {
> +SysBusDevice busdev;
> +MemoryRegion io;
> +MemoryRegion rom;
> +uint32_t state;
> +uint32_t rom_state_paddr;
> +uint32_t rom_state_vaddr;
> +uint32_t vapic_paddr;
> +uint32_t real_tpr_addr;
> +GuestROMState rom_state;
> +size_t rom_size;
> +bool rom_mapped_writable;
> +} VAPICROMState;
> +
> +#define TYPE_XEN_KVMVAPIC "xen_kvmvapic" /* copy of "kvmvapic" */
> +
> +static void xen44_vapic_realize(DeviceState *dev, Error **errp)
> +{
> +fprintf(stderr, "%s(%u) dev %p\n", __func__, __LINE__, dev);
> +}
> +
> +static int xen44_vapic_post_load(void *opaque, int version_id)
> +{
> +if (xen_enabled()) {
> +int i;
> +fprintf(stderr, "%s(%u) %p 0x%x\n", __func__, __LINE__, opaque, 
> version_id);
> +for (i = 12; i > 0; i--) {
> + sleep(1);
> +fprintf(stderr, "%s(%u) sleep %d %ld\n", __func__, __LINE__, i, 
> (long)getpid());
> + }
> +}
> +return 0;
> +}
> +
> +static const VMStateDescription vmstate_handlers = {
> +.name = "kvmvapic-handlers",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.minimum_version_id_old = 1,
> +.fields = (VMStateField[]) {
> +VMSTATE_UINT32(set_tpr, VAPICHandlers),
> +VMSTATE_UINT32(set_tpr_eax, VAPICHandlers),
> +VMSTATE_UINT32_ARRAY(get_tpr, VAPICHandlers, 8),
> +VMSTATE_UINT32(get_tpr_stack, VAPICHandlers),
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +
> +static const VMStateDescription vmstate_guest_rom = {
> +.name = "kvmvapic-guest-rom",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.minimum_version_id_old = 1,
> +.fields = (VMStateField[]) {
> +VMSTATE_UNUSED(8), /* signature */
> +VMSTATE_UINT32(vaddr, GuestROMState),
> +VMSTATE_UINT32(fixup_start, GuestROMState),
> +VMSTATE_UINT32(fixup_end, GuestROMState),
> +VMSTATE_UINT32(vapic_vaddr, GuestROMState),
> +VMSTATE_UINT32(vapic_size, GuestROMState),
> +VMSTATE_UINT32(vcpu_shift, GuestROMState),
> +VMSTATE_UINT32(real_tpr_addr, GuestROMState),
> +

[Xen-devel] 2nd opinion on backportability of c35eefded2

[Jan Beulich]

Hi George,

after quite a bit of debugging on 4.6.1 I learned that said commit
("x86/P2M: consolidate handling of types not requiring a valid MFN")
is more than just cleanup: Since p2m_set_entry() happily performs
arithmetic on the passed in MFN, shadow mode guests (verified) as
well as HAP ones when 1Gb / 2Mb mappings are unavailable (not
verified), if any of the MFNs below 1Gb are invalid (reported with
e.g. "crashkernel=512M@16M"), p2m_pt_set_entry() would (in
the context of guest_physmap_mark_populate_on_demand())
produce invalid instead of PoD entries, resulting in subsequent
attempts by the guest to use (e.g. balloon out) these pages to
fail (the balloon failure results in a crash during boot).

Now, while the backport to 4.6 is straightforward, I'm having the
vague feeling that this change might depend on some earlier one,
but I can't pinpoint anything. Hence I would appreciate if you
could take a look and provide your judgment.

Thanks, Jan


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

Re: [Xen-devel] [TESTDAY] Test report - xl sched-rtds

[Wei Liu]

On Thu, May 12, 2016 at 02:00:06PM -0500, Chong Li wrote:
> * Hardware:
> CPU: Intel Core2 Quad Q9400
> Total Memory: 2791088 kB
> 
> * Software:
> Ubuntu 14.04
> Linux kernel: 3.13.0-68
> 
> * Guest operating systems:
> Ubuntu 14.04 (PV)
> 
> * Functionality tested:
> xl sched-rtds (for set/get per-VCPU parameters)
> 
> * Comments:
> All examples about "xl sched-rtds" in xl mannual page
> 
> have been tested,
> and all run successfully.
> 
> If users type in wrong parameters (e.g., budget > period), the
> error/warnning messages
> are returned correctly as well.
> 

Good, so RTDS works as expected. Thanks for your report.

Wei.

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

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

[Andrew Cooper]

On 13/05/16 09:55, Jan Beulich wrote:
 On 13.05.16 at 09:43,  wrote:
>> On 13/05/2016 07:48, Jan Beulich wrote:
>> On 13.05.16 at 08:26,  wrote:
 On Thu, May 12, 2016 at 04:05:36AM -0600, Jan Beulich wrote:
 On 12.05.16 at 11:40,  wrote:
>> We plan to bring new PQoS feature called Intel L2 Cache Allocation
>> Technology (L2 CAT) to Xen.
>>
>> L2 CAT is supported on Atom codename Goldmont and beyond. “Big-core”
>> Xeon does not support L2 CAT in current generations.
> Looks mostly like a direct (and hence reasonable) extension of what
> we have for L3 right now. One immediate question I have is whether
> tying this to per-socket information is a good idea. As soon as Xeon-s
> would also gain such functionality, things would (aiui) need to become
> per-core (as L2 is per core there iirc).
>
 L2 Cache capability keeps the same through all cores in a socket, so we
 make it per-socket to balance code complexity and accessibility.

 I am not a expert in scheduler, do you mean in some cases, a domain
 would apply different L2 cache access pattern when it is scheduled on
 different cores even though the cores are in the same socket?
>>> No, I mean different domains may be running on different cores,
>>> and hence different policies may be needed to accommodate them
>>> all.
>> From the description, it sounds like L2 behaves almost exactly like L3. 
>> There is one set of capacity bitmaps which apply to all L2 caches in the
>> socket, and the specific capacity bitmap in effect is specified by
>> PSR_ASSOC CLOS, which is context switched with the vcpu.
> Well, I suppose the description is implying per-socket L2s. For per-
> core L2s I'd expect the MSRs to also become per-core.
>
> But anyway, L2 or L3 - I can't see how this context switching would
> DTRT when there are vCPU-s of different domains on the same
> socket (or core, if L2s and MSRs were per-core): The one getting
> scheduled later onto a socket (core) would simply overwrite what
> got written for the one which had been scheduled earlier.

PSR_ASSOC is a per-thread MSR which selects the CLOS to use.  CLOS is
currently managed per-domain in Xen, and context switched with vcpu.

Xen programs different capacity bitmaps into IA32_L2_QOS_MASK_0 ...
IA32_L2_QOS_MASK_n, and the CLOS selects which bitmap is enforced.

~Andrew

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

Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures

[Xu, Quan]

On May 13, 2016 5:09 PM, Jan Beulich  wrote:
> >>> On 13.05.16 at 10:04,  wrote:
> > On May 12, 2016 11:06 PM, Jan Beulich  wrote:
> >> >>> On 12.05.16 at 16:28,  wrote:
> >> > On May 10, 2016 2:54 PM, Jan Beulich  wrote:
> >> >> >>> On 10.05.16 at 05:41,  wrote:
> >> >> > On May 10, 2016 12:14 AM, Jan Beulich  wrote:
> >> >> >> >>> On 06.05.16 at 10:54,  wrote:
> What I think might at least come close to what Kevin and I would like to see 
> is
> something like
> 
>   if ( !d->is_shutting_down && printk_ratelimit() )
>   printk(...);
>   if ( !is_hardware_domain(d) )
>   domain_crash(d);
> 
> For Dom0 that'll still be more verbose than we'd really like, but it at least
> wouldn't outright flood the console.
> 

Thanks!!
It is really better to come close to Kevin's previous suggestion. I'll follow 
it for v5.

Quan

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

Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures

[Jan Beulich]

>>> On 13.05.16 at 10:04,  wrote:
> On May 12, 2016 11:06 PM, Jan Beulich  wrote:
>> >>> On 12.05.16 at 16:28,  wrote:
>> > On May 10, 2016 2:54 PM, Jan Beulich  wrote:
>> >> >>> On 10.05.16 at 05:41,  wrote:
>> >> > On May 10, 2016 12:14 AM, Jan Beulich  wrote:
>> >> >> >>> On 06.05.16 at 10:54,  wrote:
> Try it again, I hope I have got it. If not, could you write some sample code 
> for me as an exception? :)

Well, this would be acceptable (albeit not ideal) to me as a first
cut (and instead of continuing this apparently fruitless discussion
I'd then see to provide a follow-up patch improving it), but won't
(I'm afraid) please Kevin: You now again don't log anything for
DomU-s. That's one half of the "not ideal" part; the other is that
of two far apart events for Dom0, only the first one would get
logged.

In any event there's stylistic cleanup necessary:

> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -240,21 +240,63 @@ int iommu_map_page(struct domain *d, unsigned long gfn, 
> unsigned long mfn,
> unsigned int flags)
>  {
>  const struct domain_iommu *hd = dom_iommu(d);
> +static int printed = 0;

This doesn't need an initializer, should be bool_t, and should get
moved ...

> +int rc;
> 
>  if ( !iommu_enabled || !hd->platform_ops )
>  return 0;
> 
> -return hd->platform_ops->map_page(d, gfn, mfn, flags);
> +rc = hd->platform_ops->map_page(d, gfn, mfn, flags);
> +
> +if ( unlikely(rc) )
> +{
> +if ( is_hardware_domain(d) )
> +{

... here.

> +if ( !printed )
> +{
> +printk(XENLOG_ERR
> +   "d%d: IOMMU mapping gfn %#lx mfn %#lx failed %d.",
> +   d->domain_id, gfn, mfn, rc);
> +
> +printed = 1;
> +}
> +}
> +else
> +domain_crash(d);
> +}

What I think might at least come close to what Kevin and I would
like to see is something like

if ( !d->is_shutting_down && printk_ratelimit() )
printk(...);
if ( !is_hardware_domain(d) )
domain_crash(d);

For Dom0 that'll still be more verbose than we'd really like, but it
at least wouldn't outright flood the console.

Jan


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

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

[Jan Beulich]

>>> On 13.05.16 at 09:43,  wrote:
> On 13/05/2016 07:48, Jan Beulich wrote:
> On 13.05.16 at 08:26,  wrote:
>>> On Thu, May 12, 2016 at 04:05:36AM -0600, Jan Beulich wrote:
>>> On 12.05.16 at 11:40,  wrote:
> We plan to bring new PQoS feature called Intel L2 Cache Allocation
> Technology (L2 CAT) to Xen.
>
> L2 CAT is supported on Atom codename Goldmont and beyond. “Big-core”
> Xeon does not support L2 CAT in current generations.
 Looks mostly like a direct (and hence reasonable) extension of what
 we have for L3 right now. One immediate question I have is whether
 tying this to per-socket information is a good idea. As soon as Xeon-s
 would also gain such functionality, things would (aiui) need to become
 per-core (as L2 is per core there iirc).

>>> L2 Cache capability keeps the same through all cores in a socket, so we
>>> make it per-socket to balance code complexity and accessibility.
>>>
>>> I am not a expert in scheduler, do you mean in some cases, a domain
>>> would apply different L2 cache access pattern when it is scheduled on
>>> different cores even though the cores are in the same socket?
>> No, I mean different domains may be running on different cores,
>> and hence different policies may be needed to accommodate them
>> all.
> 
> From the description, it sounds like L2 behaves almost exactly like L3. 
> There is one set of capacity bitmaps which apply to all L2 caches in the
> socket, and the specific capacity bitmap in effect is specified by
> PSR_ASSOC CLOS, which is context switched with the vcpu.

Well, I suppose the description is implying per-socket L2s. For per-
core L2s I'd expect the MSRs to also become per-core.

But anyway, L2 or L3 - I can't see how this context switching would
DTRT when there are vCPU-s of different domains on the same
socket (or core, if L2s and MSRs were per-core): The one getting
scheduled later onto a socket (core) would simply overwrite what
got written for the one which had been scheduled earlier.

Jan

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

[Xen-devel] [PATCH net-next v4 0/4] xen-netback: support for control ring

[Paul Durrant]

My recent patch to import an up-to-date include/xen/interface/io/netif.h
from the Xen Project brought in the necessary definitions to support the
new control shared ring and protocol. This patch series updates xen-netback
to support the new ring.

Patch #1 adds the necessary boilerplate to map the control ring and handle
messages. No implementation of the new protocol is included in this patch
so that it can be kept to a reasonable size.

Patch #2 adds the protocol implementation.

Patch #3 adds support for passing has values calculated by xen-netback to
capable frontends.

Patch #4 adds support for accepting hash values calculated by capable
frontends and using them the set the socket buffer hash.

Paul Durrant (4):
  xen-netback: add control ring boilerplate
  xen-netback: add control protocol implementation
  xen-netback: pass hash value to the frontend
  xen-netback: use hash value from the frontend

 drivers/net/xen-netback/Makefile|   2 +-
 drivers/net/xen-netback/common.h|  74 ++-
 drivers/net/xen-netback/hash.c  | 384 
 drivers/net/xen-netback/interface.c | 134 -
 drivers/net/xen-netback/netback.c   | 249 +--
 drivers/net/xen-netback/xenbus.c|  79 +++-
 6 files changed, 879 insertions(+), 43 deletions(-)
 create mode 100644 drivers/net/xen-netback/hash.c

-- 
2.1.4


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

[Xen-devel] [PATCH net-next v4 1/4] xen-netback: add control ring boilerplate

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.

This patch adds the necessary code to xen-netback to map this new shared
ring, should it be created by a frontend, but does not add implementations
for any of the defined protocol messages. These are added in a subsequent
patch for clarity.

Signed-off-by: Paul Durrant 
Acked-by: Wei Liu 
---

v2:
 - Changed error handling style in connect_ctrl_ring()
---
 drivers/net/xen-netback/common.h|  28 +++---
 drivers/net/xen-netback/interface.c | 101 +---
 drivers/net/xen-netback/netback.c   |  99 +--
 drivers/net/xen-netback/xenbus.c|  79 
 4 files changed, 277 insertions(+), 30 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index f44b388..093a12a 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -260,6 +260,11 @@ struct xenvif {
struct dentry *xenvif_dbg_root;
 #endif
 
+   struct xen_netif_ctrl_back_ring ctrl;
+   struct task_struct *ctrl_task;
+   wait_queue_head_t ctrl_wq;
+   unsigned int ctrl_irq;
+
/* Miscellaneous private stuff. */
struct net_device *dev;
 };
@@ -285,10 +290,15 @@ struct xenvif *xenvif_alloc(struct device *parent,
 int xenvif_init_queue(struct xenvif_queue *queue);
 void xenvif_deinit_queue(struct xenvif_queue *queue);
 
-int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
-  unsigned long rx_ring_ref, unsigned int tx_evtchn,
-  unsigned int rx_evtchn);
-void xenvif_disconnect(struct xenvif *vif);
+int xenvif_connect_data(struct xenvif_queue *queue,
+   unsigned long tx_ring_ref,
+   unsigned long rx_ring_ref,
+   unsigned int tx_evtchn,
+   unsigned int rx_evtchn);
+void xenvif_disconnect_data(struct xenvif *vif);
+int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t ring_ref,
+   unsigned int evtchn);
+void xenvif_disconnect_ctrl(struct xenvif *vif);
 void xenvif_free(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
@@ -300,10 +310,10 @@ int xenvif_queue_stopped(struct xenvif_queue *queue);
 void xenvif_wake_queue(struct xenvif_queue *queue);
 
 /* (Un)Map communication rings. */
-void xenvif_unmap_frontend_rings(struct xenvif_queue *queue);
-int xenvif_map_frontend_rings(struct xenvif_queue *queue,
- grant_ref_t tx_ring_ref,
- grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_data_rings(struct xenvif_queue *queue);
+int xenvif_map_frontend_data_rings(struct xenvif_queue *queue,
+  grant_ref_t tx_ring_ref,
+  grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
 void xenvif_napi_schedule_or_enable_events(struct xenvif_queue *queue);
@@ -318,6 +328,8 @@ void xenvif_kick_thread(struct xenvif_queue *queue);
 
 int xenvif_dealloc_kthread(void *data);
 
+int xenvif_ctrl_kthread(void *data);
+
 void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
 
 void xenvif_carrier_on(struct xenvif *vif);
diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index f5231a2..78a10d2 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -128,6 +128,15 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+irqreturn_t xenvif_ctrl_interrupt(int irq, void *dev_id)
+{
+   struct xenvif *vif = dev_id;
+
+   wake_up(>ctrl_wq);
+
+   return IRQ_HANDLED;
+}
+
 int xenvif_queue_stopped(struct xenvif_queue *queue)
 {
struct net_device *dev = queue->vif->dev;
@@ -527,9 +536,66 @@ void xenvif_carrier_on(struct xenvif *vif)
rtnl_unlock();
 }
 
-int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
-  unsigned long rx_ring_ref, unsigned int tx_evtchn,
-  unsigned int rx_evtchn)
+int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t ring_ref,
+   unsigned int evtchn)
+{
+   struct net_device *dev = vif->dev;
+   void *addr;
+   struct xen_netif_ctrl_sring *shared;
+   struct task_struct *task;
+   int err = -ENOMEM;
+
+   err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
+_ref, 1, );
+   if (err)
+   goto err;
+
+   shared = (struct xen_netif_ctrl_sring *)addr;
+   BACK_RING_INIT(>ctrl, shared, XEN_PAGE_SIZE);
+
+   init_waitqueue_head(>ctrl_wq);
+
+   err = bind_interdomain_evtchn_to_irqhandler(vif->domid, 

[Xen-devel] [PATCH net-next v4 2/4] xen-netback: add control protocol implementation

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.

A previous patch added the necessary boilerplate for mapping the control
ring from the frontend, should it be created. This patch adds
implementations for each of the defined protocol messages.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---

v4:
 - Remove calls to init_rcu_head() and destroy_rcu_head()

v3:
 - Remove unintentional label rename

v2:
 - Use RCU list for hash cache
---
 drivers/net/xen-netback/Makefile|   2 +-
 drivers/net/xen-netback/common.h|  46 +
 drivers/net/xen-netback/hash.c  | 384 
 drivers/net/xen-netback/interface.c |  24 +++
 drivers/net/xen-netback/netback.c   |  49 -
 5 files changed, 502 insertions(+), 3 deletions(-)
 create mode 100644 drivers/net/xen-netback/hash.c

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..11e02be 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o hash.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 093a12a..84d6cbd 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -220,6 +220,35 @@ struct xenvif_mcast_addr {
 
 #define XEN_NETBK_MCAST_MAX 64
 
+#define XEN_NETBK_MAX_HASH_KEY_SIZE 40
+#define XEN_NETBK_MAX_HASH_MAPPING_SIZE 128
+#define XEN_NETBK_HASH_TAG_SIZE 40
+
+struct xenvif_hash_cache_entry {
+   struct list_head link;
+   struct rcu_head rcu;
+   u8 tag[XEN_NETBK_HASH_TAG_SIZE];
+   unsigned int len;
+   u32 val;
+   int seq;
+};
+
+struct xenvif_hash_cache {
+   spinlock_t lock;
+   struct list_head list;
+   unsigned int count;
+   atomic_t seq;
+};
+
+struct xenvif_hash {
+   unsigned int alg;
+   u32 flags;
+   u8 key[XEN_NETBK_MAX_HASH_KEY_SIZE];
+   u32 mapping[XEN_NETBK_MAX_HASH_MAPPING_SIZE];
+   unsigned int size;
+   struct xenvif_hash_cache cache;
+};
+
 struct xenvif {
/* Unique identifier for this interface. */
domid_t  domid;
@@ -251,6 +280,8 @@ struct xenvif {
unsigned int num_queues; /* active queues, resource allocated */
unsigned int stalled_queues;
 
+   struct xenvif_hash hash;
+
struct xenbus_watch credit_watch;
struct xenbus_watch mcast_ctrl_watch;
 
@@ -353,6 +384,7 @@ extern bool separate_tx_rx_irq;
 extern unsigned int rx_drain_timeout_msecs;
 extern unsigned int rx_stall_timeout_msecs;
 extern unsigned int xenvif_max_queues;
+extern unsigned int xenvif_hash_cache_size;
 
 #ifdef CONFIG_DEBUG_FS
 extern struct dentry *xen_netback_dbg_root;
@@ -366,4 +398,18 @@ void xenvif_skb_zerocopy_complete(struct xenvif_queue 
*queue);
 bool xenvif_mcast_match(struct xenvif *vif, const u8 *addr);
 void xenvif_mcast_addr_list_free(struct xenvif *vif);
 
+/* Hash */
+void xenvif_init_hash(struct xenvif *vif);
+void xenvif_deinit_hash(struct xenvif *vif);
+
+u32 xenvif_set_hash_alg(struct xenvif *vif, u32 alg);
+u32 xenvif_get_hash_flags(struct xenvif *vif, u32 *flags);
+u32 xenvif_set_hash_flags(struct xenvif *vif, u32 flags);
+u32 xenvif_set_hash_key(struct xenvif *vif, u32 gref, u32 len);
+u32 xenvif_set_hash_mapping_size(struct xenvif *vif, u32 size);
+u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, u32 len,
+   u32 off);
+
+void xenvif_set_skb_hash(struct xenvif *vif, struct sk_buff *skb);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/hash.c b/drivers/net/xen-netback/hash.c
new file mode 100644
index 000..392e392
--- /dev/null
+++ b/drivers/net/xen-netback/hash.c
@@ -0,0 +1,384 @@
+/*
+ * Copyright (c) 2016 Citrix Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Softare Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE 

[Xen-devel] [PATCH net-next v4 3/4] xen-netback: pass hash value to the frontend

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.

This patch adds code to xen-netback to pass hash values calculated for
guest receive-side packets (i.e. netback transmit side) to the frontend.

Signed-off-by: Paul Durrant 
Acked-by: Wei Liu 
---
 drivers/net/xen-netback/interface.c | 13 ++-
 drivers/net/xen-netback/netback.c   | 78 +++--
 2 files changed, 77 insertions(+), 14 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 5a39cdb..1c7f49b 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -158,8 +158,17 @@ static u16 xenvif_select_queue(struct net_device *dev, 
struct sk_buff *skb,
struct xenvif *vif = netdev_priv(dev);
unsigned int size = vif->hash.size;
 
-   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE)
-   return fallback(dev, skb) % dev->real_num_tx_queues;
+   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE) {
+   u16 index = fallback(dev, skb) % dev->real_num_tx_queues;
+
+   /* Make sure there is no hash information in the socket
+* buffer otherwise it would be incorrectly forwarded
+* to the frontend.
+*/
+   skb_clear_hash(skb);
+
+   return index;
+   }
 
xenvif_set_skb_hash(vif, skb);
 
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 6509d11..7c72510 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -168,6 +168,8 @@ static bool xenvif_rx_ring_slots_available(struct 
xenvif_queue *queue)
needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
if (skb_is_gso(skb))
needed++;
+   if (skb->sw_hash)
+   needed++;
 
do {
prod = queue->rx.sring->req_prod;
@@ -285,6 +287,8 @@ struct gop_frag_copy {
struct xenvif_rx_meta *meta;
int head;
int gso_type;
+   int protocol;
+   int hash_present;
 
struct page *page;
 };
@@ -331,8 +335,15 @@ static void xenvif_setup_copy_gop(unsigned long gfn,
npo->copy_off += *len;
info->meta->size += *len;
 
+   if (!info->head)
+   return;
+
/* Leave a gap for the GSO descriptor. */
-   if (info->head && ((1 << info->gso_type) & queue->vif->gso_mask))
+   if ((1 << info->gso_type) & queue->vif->gso_mask)
+   queue->rx.req_cons++;
+
+   /* Leave a gap for the hash extra segment. */
+   if (info->hash_present)
queue->rx.req_cons++;
 
info->head = 0; /* There must be something in this buffer now */
@@ -367,6 +378,11 @@ static void xenvif_gop_frag_copy(struct xenvif_queue 
*queue, struct sk_buff *skb
.npo = npo,
.head = *head,
.gso_type = XEN_NETIF_GSO_TYPE_NONE,
+   /* xenvif_set_skb_hash() will have either set a s/w
+* hash or cleared the hash depending on
+* whether the the frontend wants a hash for this skb.
+*/
+   .hash_present = skb->sw_hash,
};
unsigned long bytes;
 
@@ -555,6 +571,7 @@ void xenvif_kick_thread(struct xenvif_queue *queue)
 
 static void xenvif_rx_action(struct xenvif_queue *queue)
 {
+   struct xenvif *vif = queue->vif;
s8 status;
u16 flags;
struct xen_netif_rx_response *resp;
@@ -590,9 +607,10 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
gnttab_batch_copy(queue->grant_copy_op, npo.copy_prod);
 
while ((skb = __skb_dequeue()) != NULL) {
+   struct xen_netif_extra_info *extra = NULL;
 
if ((1 << queue->meta[npo.meta_cons].gso_type) &
-   queue->vif->gso_prefix_mask) {
+   vif->gso_prefix_mask) {
resp = RING_GET_RESPONSE(>rx,
 queue->rx.rsp_prod_pvt++);
 
@@ -610,7 +628,7 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
queue->stats.tx_bytes += skb->len;
queue->stats.tx_packets++;
 
-   status = xenvif_check_gop(queue->vif,
+   status = xenvif_check_gop(vif,
  XENVIF_RX_CB(skb)->meta_slots_used,
  );
 
@@ -632,21 +650,57 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
flags);
 
if ((1 << queue->meta[npo.meta_cons].gso_type) &
-   queue->vif->gso_mask) {
-   struct xen_netif_extra_info *gso =
-   (struct xen_netif_extra_info *)
+  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 94035 REGR. vs. 
92982

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 fail in 
94035 pass in 94056
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 94035 pass 
in 94056
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail in 94035 pass in 94056
 test-armhf-armhf-xl-xsm   6 xen-bootfail pass in 94035
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail pass in 
94035

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 92982
 build-amd64-rumpuserxen   6 xen-buildfail   like 92982
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92982
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 92982

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

version targeted for testing:
 linux6b12ebc0ecce75d7bd3660cd85f8b47a615c2071
baseline version:
 linux834125557e0a4e5afafee3caf79696078d0820ae

Last test of basis92982  2016-04-27 16:21:58 Z   15 days
Testing same since94035  2016-05-11 15:51:18 Z1 days2 attempts


People who touched revisions under test:
  Alex Deucher 
  Andrew Morton 
  Aneesh Kumar K.V 
  Anton Blanchard 
  Dave Airlie 
  Dmitry Ivanov 
  Dmitry Ivanov 
  Dmitry Torokhov 
  Dominik Dingel 
  Herbert Xu 
  Huacai Chen 
  Ingo Molnar 

Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures

[Xu, Quan]

On May 12, 2016 11:06 PM, Jan Beulich  wrote:
> >>> On 12.05.16 at 16:28,  wrote:
> > On May 10, 2016 2:54 PM, Jan Beulich  wrote:
> >> >>> On 10.05.16 at 05:41,  wrote:
> >> > On May 10, 2016 12:14 AM, Jan Beulich  wrote:
> >> >> >>> On 06.05.16 at 10:54,  wrote:

Jan,

Try it again, I hope I have got it. If not, could you write some sample code 
for me as an exception? :)

--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -240,21 +240,63 @@ int iommu_map_page(struct domain *d, unsigned long gfn, 
unsigned long mfn,
unsigned int flags)
 {
 const struct domain_iommu *hd = dom_iommu(d);
+static int printed = 0;
+int rc;

 if ( !iommu_enabled || !hd->platform_ops )
 return 0;

-return hd->platform_ops->map_page(d, gfn, mfn, flags);
+rc = hd->platform_ops->map_page(d, gfn, mfn, flags);
+
+if ( unlikely(rc) )
+{
+if ( is_hardware_domain(d) )
+{
+if ( !printed )
+{
+printk(XENLOG_ERR
+   "d%d: IOMMU mapping gfn %#lx mfn %#lx failed %d.",
+   d->domain_id, gfn, mfn, rc);
+
+printed = 1;
+}
+}
+else
+domain_crash(d);
+}
+
+return rc;
 }

 int iommu_unmap_page(struct domain *d, unsigned long gfn)
 {
 const struct domain_iommu *hd = dom_iommu(d);
+static int printed = 0;
+int rc;

 if ( !iommu_enabled || !hd->platform_ops )
 return 0;

-return hd->platform_ops->unmap_page(d, gfn);
+rc = hd->platform_ops->unmap_page(d, gfn);
+
+if ( unlikely(rc) )
+{
+if ( is_hardware_domain(d) )
+{
+if ( !printed )
+{
+printk(XENLOG_ERR
+   "d%d: IOMMU unmapping gfn %#lx failed %d.",
+   d->domain_id, gfn, rc);
+
+printed = 1;
+}
+}
+else
+domain_crash(d);
+}
+
+return rc;
 }


Thanks again!!
Quan

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

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

[Andrew Cooper]

On 13/05/2016 07:48, Jan Beulich wrote:
 On 13.05.16 at 08:26,  wrote:
>> On Thu, May 12, 2016 at 04:05:36AM -0600, Jan Beulich wrote:
>> On 12.05.16 at 11:40,  wrote:
 We plan to bring new PQoS feature called Intel L2 Cache Allocation
 Technology (L2 CAT) to Xen.

 L2 CAT is supported on Atom codename Goldmont and beyond. “Big-core”
 Xeon does not support L2 CAT in current generations.
>>> Looks mostly like a direct (and hence reasonable) extension of what
>>> we have for L3 right now. One immediate question I have is whether
>>> tying this to per-socket information is a good idea. As soon as Xeon-s
>>> would also gain such functionality, things would (aiui) need to become
>>> per-core (as L2 is per core there iirc).
>>>
>> L2 Cache capability keeps the same through all cores in a socket, so we
>> make it per-socket to balance code complexity and accessibility.
>>
>> I am not a expert in scheduler, do you mean in some cases, a domain
>> would apply different L2 cache access pattern when it is scheduled on
>> different cores even though the cores are in the same socket?
> No, I mean different domains may be running on different cores,
> and hence different policies may be needed to accommodate them
> all.

From the description, it sounds like L2 behaves almost exactly like L3. 
There is one set of capacity bitmaps which apply to all L2 caches in the
socket, and the specific capacity bitmap in effect is specified by
PSR_ASSOC CLOS, which is context switched with the vcpu.

~Andrew

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

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

[Dario Faggioli]

On Thu, 2016-05-12 at 23:34 -0400, Meng Xu wrote:
> On Wed, May 11, 2016 at 11:20 AM, Tianyang Chen  > wrote:
> > 
> > No functional change:
> >  -Various coding style fix
> >  -Added comments for UPDATE_LIMIT_SHIFT.
> > 
Hey, Tianyang, thanks for this.

> > Use non-atomic bit-ops:
> >  -Vcpu flags are checked and cleared atomically. Performance can be
> >   improved with corresponding non-atomic versions since schedule.c
> >   already has spin_locks in place.
> > 
And this too. However, I think the patch should be split at least in
two, one doing the style/comments cleanups, the other doing the
atomic/non-atomic switch.

> > Suggested-by: Dario Faggioli 
> It's better to add the link to the thread that has the suggestion.
> 
Yes, suggested-by tags are not especially useful, IMHO. I'm fine with
you using it, but as Meng says, a link would be more helpful. If you
send a series, which will have a cover letter, put the link(s) in the
cover letter rather than in the changelog, as that's an important
information when reviewing, much less when looking at git-log in 5
years time. :-)

> > @@ -930,7 +936,7 @@ burn_budget(const struct scheduler *ops, struct
> > rt_vcpu *svc, s_time_t now)
> >  if ( svc->cur_budget <= 0 )
> >  {
> >  svc->cur_budget = 0;
> > -set_bit(__RTDS_depleted, >flags);
> > +__set_bit(__RTDS_depleted, >flags);
> >  }
> > 
> >  /* TRACE */
> > @@ -955,7 +961,7 @@ burn_budget(const struct scheduler *ops, struct
> > rt_vcpu *svc, s_time_t now)
> >   * lock is grabbed before calling this function
> The comment says "lock is grabbed before calling this function".
> IIRC,  we use __ to represent that we grab the lock before call this
> function.
> Then this change violates the convention.
> 
Yeah, but it was a bad convention, IMO, at least for sched_*.c files. 

In fact, it is debatable whether one or two underscore is what should
really be used.

Also, that's not the only convention that lead to the introduction of
this king of prefix (for example, I've seen many times '__' used for
indicating some sort of 'raw' part of the operation... there are
examples of this in Xen too)... Which means one never knows which one
is the valid convention at some point, about '__'! :-O

But even if we leave this aside, and consider at the '__'==>locked
rule, well, pretty much all functions in sched_rt.c are called with the
proper locks held already. Basically, since in many occasione, the lock
has been taken in schedule.c before calling the hook, all the functions
eve called by an hook --end maybe even the hook itself-- should have
the '__' prefix, which defeats the purpose of the convention itself!

So, on this, I agree with Tianyang, and I think removing the '__' is a
good thing for this source file.

If there are places where we want to particularly stress the fact that
locks should have be taken already, then either add a comment or a
'_locked' suffix to the function name. But that should be the exception
rather than the rule and, out of the top of my head, I don't recall any
cases in sched_rt.c where that would be tremendously helpful...

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



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

Re: [Xen-devel] [PATCH v5 0/3] usb, xen: add pvUSB backend

[Gerd Hoffmann]

On Do, 2016-05-12 at 16:13 +0200, Juergen Gross wrote:
> This series adds a Xen pvUSB backend driver to qemu. USB devices
> connected to the host can be passed through to a Xen guest. The
> devices are specified via Xenstore. Access to the devices is done
> via host-libusb.c
> 
> I've tested the backend with various USB devices (memory sticks,
> keyboard, ...).
> 
> Changes in V5:
> - patch 2: silence checkpatch errors/warnings
> 

Added to usb patch queue.

thanks,
  Gerd

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

Re: [Xen-devel] panic("queue invalidate wait descriptor was not executed\n")

[Wu, Feng]

> -Original Message-
> From: Zytaruk, Kelly [mailto:kelly.zyta...@amd.com]
> Sent: Thursday, May 12, 2016 10:21 PM
> To: Jan Beulich 
> Cc: Wu, Feng ; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: RE: [Xen-devel] panic("queue invalidate wait descriptor was not
> executed\n")
> 
> 
> 
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Thursday, May 12, 2016 9:51 AM
> > To: Zytaruk, Kelly
> > Cc: Feng Wu; Kevin Tian; xen-devel@lists.xen.org
> > Subject: RE: [Xen-devel] panic("queue invalidate wait descriptor was not
> > executed\n")
> >
> > >>> On 12.05.16 at 14:36,  wrote:
> > >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> Sent: Thursday, May 12, 2016 5:49 AM
> > >> >>> On 11.05.16 at 15:51,  wrote:
> > >> > During Xen boot I am seeing the panic in the subject line from
> > >> > .../xen/drivers/passthrough/vgt/qinval.c
> > >>
> > >> And this is with current staging, or some much older version of Xen?
> > >> (ISTR some issue with the invalidation request getting sent to the
> > >> wrong IOMMU, leading to a timeout.)
> > >
> > > No this is not current Xen, it is with 4.2.
> > >
> > > Can you tell me more about the invalidation request getting sent to
> > > the wrong IOMMU problem and approximately when it was fixed?  If you
> > > could identify the patch I could back port it into my copy of Xen for 
> > > testing.
> >
> > Note that 4.2.5 has said change, and also note that you could have done
> exactly
> > what I have done now - go through the list of commits altering files in the 
> > vtd/
> > subtree.
> 
> Unfortunately GIT is not my strong suit :( I am still learning to navigate 
> with it. I
> guess part of my problem with GIT is that I don't yet know what I don't know.
> 
> >This is what I've been remembering:
> >
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=84c340ba4c3eb9927
> > 8b6ba885616bb183b88ad67
> 
> The comment on this link describes exactly what I am experiencing.
> Thanks so much.

Thanks Jan for providing the information above. Kelly, if you still met the same
issue after applying the patches, let us know, maybe I can consult some hardware
expert internally.

Thanks,
Feng

> 
> >
> > Jan


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

[Xen-devel] [distros-debian-jessie test] 44412: trouble: blocked/broken

[Platform Team regression test user]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]

Regressions which are regarded as allowable (not blocking):
 build-armhf-pvops 3 host-install(3)  broken like 44393
 build-armhf   3 host-install(3)  broken like 44393
 build-i3863 host-install(3)  broken like 44393
 build-amd64-pvops 3 host-install(3)  broken like 44393
 build-i386-pvops  3 host-install(3)  broken like 44393
 build-amd64   3 host-install(3)  broken like 44393

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-i386-jessie-netboot-pvgrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-jessie-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-jessie-netboot-pvgrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-jessie-netboot-pygrub  1 build-check(1)  blocked n/a

baseline version:
 flight   44393

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-jessie-netboot-pvgrub blocked 
 test-amd64-i386-i386-jessie-netboot-pvgrub   blocked 
 test-amd64-i386-amd64-jessie-netboot-pygrub  blocked 
 test-armhf-armhf-armhf-jessie-netboot-pygrub blocked 
 test-amd64-amd64-i386-jessie-netboot-pygrub  blocked 



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

[Jan Beulich]

>>> On 13.05.16 at 08:26,  wrote:
> On Thu, May 12, 2016 at 04:05:36AM -0600, Jan Beulich wrote:
>> >>> On 12.05.16 at 11:40,  wrote:
>> > We plan to bring new PQoS feature called Intel L2 Cache Allocation
>> > Technology (L2 CAT) to Xen.
>> > 
>> > L2 CAT is supported on Atom codename Goldmont and beyond. “Big-core”
>> > Xeon does not support L2 CAT in current generations.
>> 
>> Looks mostly like a direct (and hence reasonable) extension of what
>> we have for L3 right now. One immediate question I have is whether
>> tying this to per-socket information is a good idea. As soon as Xeon-s
>> would also gain such functionality, things would (aiui) need to become
>> per-core (as L2 is per core there iirc).
>> 
> 
> L2 Cache capability keeps the same through all cores in a socket, so we
> make it per-socket to balance code complexity and accessibility.
> 
> I am not a expert in scheduler, do you mean in some cases, a domain
> would apply different L2 cache access pattern when it is scheduled on
> different cores even though the cores are in the same socket?

No, I mean different domains may be running on different cores,
and hence different policies may be needed to accommodate them
all.

Jan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93989
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93989
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat fail REGR. vs. 93989
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93989
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail in 94030 REGR. vs. 93989

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qcow2 3 host-install(3)   broken pass in 94030
 test-amd64-amd64-pygrub   3 host-install(3)   broken pass in 94030
 test-armhf-armhf-xl-arndale   6 xen-boot   fail in 94030 pass in 94055
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 94030 pass in 94055
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 94030

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

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

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

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


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-prev