Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Juergen Gross]

Continuing the thread on xen-devel.

On 27/09/16 00:48, Sven Köhler wrote:
> Am 26.09.2016 um 07:43 schrieb Juergen Gross:
>> On 25/09/16 18:04, Sven Köhler wrote:
>>> Hi,
>>>
>>> I'm experiencing the bug below which was discussed on xen-devel December
>>> last year buy Ian and Juergen. I'm using xen-pvgrub-4.7.0 on Gentoo.
>>>
>>> The bug only seems to occur with the last domU booted on my machine.
>>> Where do I find a patch that fixes that?
>>
>> The issue back in December was fixed by commit
>> c8eb0ec277ae387e78d685523e0fee633e46f046 which is included in Xen 4.7.
>> Either gentoo didn't update to the official Xen 4.7 release (including
>> pvgrub) or you are seeing a new issue.
> 
> From the looks of it, the Gentoo package is using the grub from the
> xen-4.7.0 tarball.
> 
> I downgraded to pvgrub 4.6.3 and the problem went away.
> 
> So I assume I'm seeing a new issue. How do I debug it?

Interesting. Just tested it on upstream Xen and saw the same problem
with a rather old guest kernel (3.0 based, xen flavor), while a newer
kernel (4.1, pvops) is working.

Can you give me some more details about the kernel you are trying to
boot?

I'll investigate further.

In case you feel adventurous and want to do some debugging yourself:
You need to build Xen from the sources. Your scenario includes debugging
of Xen tools (probably the domain builder in tools/libxc), Mini-OS
(extras/mini-os-remote) and grub (stubdom/grub-upstream). All paths
mentioned are in the xen tree, some might be created only during first
build.


Juergen

>>> Once I find a patch to address the issue, I will also forward it to the
>>> Gentoo maintainers via their bugzilla.
>>>
>>>
>>> Kind Regards,
>>>   Sven
>>>
>>>
>>> output of xl create -c:
>>>
>>>   Booting 'Gentoo'
>>>
>>> root (hd0)
>>>  Filesystem type is ext2fs, using whole disk
>>> kernel /boot/vmlinuz ro root=/dev/xvda1 rootfstype=ext4
>>>
>>> = Init TPM Front 
>>> Tpmfront:Error Unable to read device/vtpm/0/backend-id during tpmfront
>>> initialization! error = ENOENT
>>> Tpmfront:Info Shutting down tpmfront
>>> pin_table(x) returned 28993
>>>
>>> Error 9: Unknown boot failure
>>>
>>> Press any key to continue...
>>>
>>>
>>>
>>> ___
>>> Xen-users mailing list
>>> xen-us...@lists.xen.org
>>> https://lists.xen.org/xen-users
>>>
>>
> 


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu7cfdc02dae0d2ff58c897496cfdbbafc0eda0f3f
baseline version:
 qemuu3b71ec8516bb50e9a743645bf139571de0b39f61

Last test of basis   101133  2016-09-24 03:18:52 Z3 days
Testing same since   101156  2016-09-26 20:14:27 Z0 days1 attempts


People who touched revisions under test:
  Cornelia Huck 
  David Kiarie 
  Igor Mammedov 
  Marc-André Lureau 
  Michael S. Tsirkin 
  Peter Maydell 
  Prasad J Pandit 
  Stefan Hajnoczi 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7188b4557a607c667175e026b60c6648a438e829
baseline version:
 ovmf 00df35fe4146b6ceb39bf55df1fabec955cd08a6

Last test of basis67765  2016-09-26 18:20:52 Z0 days
Testing same since67766  2016-09-27 00:49:21 Z0 days1 attempts


People who touched revisions under test:
  Tapan Shah 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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


Push not applicable.


commit 7188b4557a607c667175e026b60c6648a438e829
Author: Tapan Shah 
Date:   Fri Sep 23 09:03:16 2016 -0700

ShellPkg: Enhance 'cls' command to change the background and foreground 
colors

As per ECR 1416 change in UEFI Shell Specification 2.2,
enhancing 'cls' command to change the background color as well as
foreground color. Also add support to display current settings
using 'cls -sfo' command.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah 
Reviewed-by: Jaben Carsey 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f6be48e9907d8bb8f8534df50049ce428c38f719
baseline version:
 ovmf 7188b4557a607c667175e026b60c6648a438e829

Last test of basis   101157  2016-09-26 20:16:33 Z0 days
Testing same since   101158  2016-09-27 00:44:11 Z0 days1 attempts


People who touched revisions under test:
  Kurt Kennett 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=f6be48e9907d8bb8f8534df50049ce428c38f719
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
f6be48e9907d8bb8f8534df50049ce428c38f719
+ branch=ovmf
+ revision=f6be48e9907d8bb8f8534df50049ce428c38f719
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xf6be48e9907d8bb8f8534df50049ce428c38f719 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  89c423a170de2fef08445ea9151bcfa15c45b217
baseline version:
 xen  a75f34462612a05547fc43d192705a9c31cad7fb

Last test of basis   101148  2016-09-26 02:00:17 Z0 days
Testing same since   101154  2016-09-26 17:45:12 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Borislav Petkov 
  Emanuel Czirai 
  Jan Beulich 
  Kevin Tian 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7188b4557a607c667175e026b60c6648a438e829
baseline version:
 ovmf 00df35fe4146b6ceb39bf55df1fabec955cd08a6

Last test of basis   101152  2016-09-26 15:14:13 Z0 days
Testing same since   101157  2016-09-26 20:16:33 Z0 days1 attempts


People who touched revisions under test:
  Tapan Shah 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=7188b4557a607c667175e026b60c6648a438e829
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
7188b4557a607c667175e026b60c6648a438e829
+ branch=ovmf
+ revision=7188b4557a607c667175e026b60c6648a438e829
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x7188b4557a607c667175e026b60c6648a438e829 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 00df35fe4146b6ceb39bf55df1fabec955cd08a6
baseline version:
 ovmf 065ae7d717f9e49c3be12dada109d60dead0bb90

Last test of basis67763  2016-09-26 15:16:38 Z0 days
Testing same since67765  2016-09-26 18:20:52 Z0 days1 attempts


People who touched revisions under test:
  Hegde Nagaraj P 
  Jiaxin Wu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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


Push not applicable.


commit 00df35fe4146b6ceb39bf55df1fabec955cd08a6
Author: Jiaxin Wu 
Date:   Wed Sep 21 15:13:37 2016 +0800

NetworkPkg: Clean the previous address since the policy changed

The previous DNS server data will be retained after the policy
changes from Auto to Manual. This patch is used to clean the
previous dhcp configuration data.

Cc: Hegde Nagaraj P 
Cc: Subramanian Sriram 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
Reviewed-by: Sriram Subramanian 
Reviewed-by: Hegde Nagaraj P 
Tested-by: Hegde Nagaraj P 

commit 24b41b75f883a948f6844e455b9de020e23c72d4
Author: Jiaxin Wu 
Date:   Wed Sep 21 15:12:21 2016 +0800

MdeModulePkg: Clean the previous address since the policy changed

The previous DNS server data will be retained after the policy
changes from Dhcp to Static. This patch is used to clean the
previous dhcp configuration data.

Cc: Hegde Nagaraj P 
Cc: Subramanian Sriram 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
Reviewed-by: Sriram Subramanian 
Reviewed-by: Hegde Nagaraj P 
Tested-by: Hegde Nagaraj P 

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

Re: [Xen-devel] [PATCH v6 16/16] libxl/arm: Add the size of ACPI tables to maxmem

[Shannon Zhao]

On 2016/9/22 7:10, Wei Liu wrote:

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 2924629..118beab 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -408,8 +408,15 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>  }
>  }
>
> +
> +rc = libxl__arch_memory_constant(gc, info, state);
> +if (rc < 0) {
> +LOGE(ERROR, "Couldn't get arch constant memory size");
> +return ERROR_FAIL;
> +}
> +
>  if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> -LIBXL_MAXMEM_CONSTANT) < 0) {
> +LIBXL_MAXMEM_CONSTANT + rc) < 0) {

I think this LIBXL_MAXMEM_CONSTANT should be pushed to your helper
function, too.

So that, we can have all LIBXL_MAXMEM_CONSTANT removed in libxl
functions (see libxl.c and libxl_dom.c)

If we push LIBXL_MAXMEM_CONSTANT to the libxl_arch_memory_constant and 
remove it from libxl.c, do we need to call libxl_arch_memory_constant 
there in libxl_set_memory_target()?


Thanks,
--
Shannon

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

[Xen-devel] [Outreachy]Code Standards Checking using clang-format

[nimisha agarwal]

Hello,
 I wish to take part in the Outreach Program this time. The second  project
that interest me is *Code Standards Checking using clang-format. *I am
currently looking through clang-format so I could get to know how to use it.
To get started, if you could suggest couple of small bitesize work-items so
I could start contributing and get familiar with the codebase.


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

Re: [Xen-devel] [PATCH RFC v7 07/14] efi: create new early memory allocator

[Julien Grall]

Hi Jan,

On 25/09/2016 23:53, Jan Beulich wrote:

On 24.09.16 at 01:35,  wrote:

Hi Daniel,

On 23/09/2016 22:47, Daniel Kiper wrote:

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 38eb888..2085f35 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -66,6 +67,7 @@ integer_param("xenheap_megabytes", opt_xenheap_megabytes);

 static __used void init_done(void)
 {
+free_ebmalloc_unused_mem();


I said no to this on the previous version. And I think Jan suggested a
per-arch way to do it. So why is it here?


No, I specifically did not. I intended this to be universal, but then I
wasn't really aware that on ARM the EFI loader is so much different
from x86's.

Before coming to a final conclusion I'd really like to understand how
you would see dynamic memory allocation to work for pieces of data
to be communicated from EFI loader to main Xen. That'll determine
whether I'll have to grumblingly accept this code to be x86-specific.


In the current state, all the communication from EFI loader to main Xen 
should be done via the device-tree or the data have to be in init 
section (bss is zeroed when leaving the EFI stub and before entering to 
Xen).


I am not against changing this behavior, however in the current state 
this will not work at all. The call to the function will be misleading, 
hence why I suggested a TODO for the time-being (for now the code is 
only compiled on x86, anyway).


Regards,

--
Julien Grall

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

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

[osstest service owner]

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

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  9bb1865cca15b28be5aa185cd865b95b49e7b303
baseline version:
 xen  89c423a170de2fef08445ea9151bcfa15c45b217

Last test of basis   101153  2016-09-26 16:00:59 Z0 days
Testing same since   101155  2016-09-26 18:01:25 Z0 days1 attempts


People who touched revisions under test:
  Razvan Cojocaru 
  Tamas K Lengyel 

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=9bb1865cca15b28be5aa185cd865b95b49e7b303
+ . ./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 
9bb1865cca15b28be5aa185cd865b95b49e7b303
+ branch=xen-unstable-smoke
+ revision=9bb1865cca15b28be5aa185cd865b95b49e7b303
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x9bb1865cca15b28be5aa185cd865b95b49e7b303 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v6 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI

[Shannon Zhao]

On 2016/9/22 8:00, Jan Beulich wrote:

On 22.09.16 at 14:52,  wrote:

From: Shannon Zhao 

Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
them in evtchn_fixup().

Also use HVM_PARAM_CALLBACK_IRQ_TYPE_MASK in hvm_set_callback_via().

Cc: Jan Beulich 
Cc: Andrew Cooper 
Signed-off-by: Shannon Zhao 
---
 xen/arch/arm/domain_build.c | 9 ++---
 xen/arch/x86/hvm/irq.c  | 2 +-
 xen/include/public/hvm/params.h | 3 +++
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..0cf7dc3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2016,9 +2016,12 @@ static void evtchn_fixup(struct domain *d, struct
kernel_info *kinfo)
d->arch.evtchn_irq);

 /* Set the value of domain param HVM_PARAM_CALLBACK_IRQ */
-val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 56;
-val |= (2 << 8); /* Active-low level-sensitive  */
-val |= d->arch.evtchn_irq & 0xff;
+val = MASK_INSR(HVM_PARAM_CALLBACK_TYPE_PPI,
+HVM_PARAM_CALLBACK_IRQ_TYPE_MASK);
+/* Active-low level-sensitive  */
+val |= MASK_INSR(HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL,
+ HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_MASK);
+val |= d->arch.evtchn_irq;
 d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ] = val;

 /*
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 5323d7c..e597114 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -325,7 +325,7 @@ void hvm_set_callback_via(struct domain *d, uint64_t via)
 unsigned int gsi=0, pdev=0, pintx=0;
 uint8_t via_type;

-via_type = (uint8_t)(via >> 56) + 1;
+via_type = (uint8_t)MASK_EXTR(via, HVM_PARAM_CALLBACK_IRQ_TYPE_MASK) +
1;
 if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
  (via_type > HVMIRQ_callback_vector) )
 via_type = HVMIRQ_callback_none;
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index f7338a3..5c50e2e 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -30,6 +30,7 @@
  */

 #define HVM_PARAM_CALLBACK_IRQ 0
+#define HVM_PARAM_CALLBACK_IRQ_TYPE_MASK 0xFF00


I'd be surprised if this goes through on all compiler versions: This
is a constant which needs at least a UL suffix (and if intended to
be usable on 32-bit even a ULL one, which would then get us into
complications with there not being supposed to be any non-C89
constructs in the public headers).


Hi Jan,

Do I need to resend this patch or add new one to fix this on top of this 
one?


Thanks,
--
Shannon

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 26, 2016 2:35 PM
> 
> >>> On 24.09.16 at 01:34,  wrote:
> >>  From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, September 23, 2016 11:34 PM
> >>
> >> >>> On 20.09.16 at 15:30,  wrote:
> >> > --- a/xen/arch/x86/hvm/vlapic.c
> >> > +++ b/xen/arch/x86/hvm/vlapic.c
> >> > @@ -433,6 +433,12 @@ void vlapic_EOI_set(struct vlapic *vlapic)
> >> >  void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
> >> >  {
> >> >  struct domain *d = vlapic_domain(vlapic);
> >> > +struct vcpu *v = vlapic_vcpu(vlapic);
> >> > +struct hvm_intack pt_intack;
> >> > +
> >> > +pt_intack.vector = vector;
> >> > +pt_intack.source = hvm_intsrc_lapic;
> >> > +pt_intr_post(v, pt_intack);
> >>
> >> This also sits on the EOI LAPIC register write path, i.e. the change
> >> then also affects non-apicv environments.
> >
> > The new logic should be entered only when EOI-induced exit happens.
> 
> To me this reply reads ambiguously: Does "should" here mean the
> patch needs further adjustment in your opinion, or that you think
> the patch already does what is needed to ensure the new logic to
> bet involved only in the EOI-induced exit case. To me it continues
> to look like the former.

yes the former. Possibly clearer if I directly reply to original Quan's
patch. :-)

> 
> >> Furthermore - don't we have the same problem as with v1 again
> >> then? What prevents multiple EOIs to come here before the timer
> >> interrupt actually gets handled? You'd then clear ->irq_issued
> >> each time, rendering your change to pt_update_irq() ineffective.
> >
> > based on this patch, one irq_issued should cause only one EOI on
> > related pt vector and this EOI exit clears irq_issued then next EOI
> > would be seen only upon another injection when irq_issued is set
> > again... However there might be an issue if this pt vector is shared
> > with another device interrupt, which although is not a typical case...
> 
> That's a common problem: I don't think we can consider only the
> typical case. Or does hardware only deal with those, too?

need more thinking here.

> 
> And then the "should" here reads as ambiguously to me as the
> earlier one, the more that you seem to consider EOIs for only the
> one vector of interest, whereas my reply was specifically meant
> to cover also EOIs for other vectors.

This "should" means the behavior after further adjustment

> 
> >> > --- a/xen/arch/x86/hvm/vmx/intr.c
> >> > +++ b/xen/arch/x86/hvm/vmx/intr.c
> >> > @@ -333,8 +333,6 @@ void vmx_intr_assist(void)
> >> >  clear_bit(i, >arch.hvm_vmx.eoi_exitmap_changed);
> >> >  __vmwrite(EOI_EXIT_BITMAP(i),
> v->arch.hvm_vmx.eoi_exit_bitmap[i]);
> >> >  }
> >> > -
> >> > -pt_intr_post(v, intack);
> >> >  }
> >>
> >> I'll defer to the VMX maintainers to determine whether removing this
> >> but not the other one is correct.
> >
> > This is correct. The other one is for non-apicv scenario.
> 
> Sure, but the other path will also get used under certain conditions
> even when apicv is in use.
> 
> >> > --- a/xen/arch/x86/hvm/vpt.c
> >> > +++ b/xen/arch/x86/hvm/vpt.c
> >> > @@ -252,7 +252,8 @@ int pt_update_irq(struct vcpu *v)
> >> >  }
> >> >  else
> >> >  {
> >> > -if ( (pt->last_plt_gtime + pt->period) < max_lag )
> >> > +if ( (pt->last_plt_gtime + pt->period) < max_lag &&
> >> > + !pt->irq_issued )
> >> >  {
> >> >  max_lag = pt->last_plt_gtime + pt->period;
> >> >  earliest_pt = pt;
> >>
> >> Looking at the rest of the code I really wonder why this check
> >> hadn't been there from the beginning. Tim, do recall whether
> >> this was intentional (as opposed to simply having been an
> >> oversight)?
> >
> > Possibly simplify the emulation by relying on IRR/ISR to handling pending
> > situation?
> 
> Again I'm suffering ambiguity here: Do you suggest a possible
> explanation for why things are the way they are, or a possible
> code adjustment to be done?
> 

the former.

Thanks
Kevin

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

Re: [Xen-devel] Fwd: Openindiana, using -machine pc, accel=xen in qemu

[jim burns]

On Monday, 26 September 2016, 17:21:12 EDT, Anthony PERARD wrote:
> Try this (apix_enable=0):
> https://docs.oracle.com/cd/E27300_01/E27307/html/vmrns-bugs.html#vmrns-solar
> is10hangs with 'xen_platform_pci=1' in your config. (it did not work for me
> with xen_platform_pci=0.)
> 
> It worked for me with the "OpenIndiana Build 151a8 Server CD".

Glad you provided a link. I was going to put apix_enable=0 in the xen cfg 
file. Unfortunately, I went ahead and put in the vhd's /etc/system before I 
shutdown, and then found I couldn't boot back up again.

I tried the OI-hipster-gui-20160421 and oi-dev-151a8-live-x86 DVDs with the -
kd procedure on the grub kernel command line. I got a little further with the 
boot msgs, but it still panic-ed with a null dereference.

Finally, I was able to boot the vhd with standalone qemu and accel=tcg (no 
accel) for some reason, and was able to comment out the apix_enable line in /
etc/system, then tested rebooting with the -kd procedure, with the same 
results as the DVDs. I tried with the drives defined as xvd{a,c} and hd{a,c}, 
with and without the -cpu definition in the xen cfg. (Interestingly enough, 
you can't see the debugger prompt with the Xorg progress screen, but the 
debugger still accepts input.)

The web page link refers to the Westmere cpu family. I don't know what cpu 
family you had success on, but it didn't work for me.

Unless you have any other ideas, I'm giving up for now. Thanx for your help.


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

Re: [Xen-devel] [PATCH v6 16/16] libxl/arm: Add the size of ACPI tables to maxmem

[Shannon Zhao]

On 2016/9/26 2:05, Wei Liu wrote:

On Mon, Sep 26, 2016 at 03:08:43PM +0800, Shannon Zhao wrote:

>
>
> On 2016/9/22 22:32, Wei Liu wrote:

> >FAOD:
> >
> >I think all the issues I found so far in this patch and other patch(es)
> >are mostly cosmetic. I would be happy to accept incremental patches on
> >top of this series to make those changes.
> >

> Ok, thanks for your review.
>

> >No need to resend just yet unless there is something substantial that
> >you need to change.

> So far do I need to resend this series for comments?

No, you don't have to resend this series at the moment. Please address
Jan's comment on patch 14 first.

Ok, I see. Do I need to resend the patch or add new one on top of that?

Thanks,
--
Shannon

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

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/26/2016 12:48 PM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v6] acpi: Prevent GPL-only code from 
> seeping into non-GPL binaries"):
>> On 09/26/2016 10:45 AM, Ian Jackson wrote:
>>> If the indices are necessarily successive integers:
>>>
>>>   links="A B C D"
>>>   index=0
>>>   for link in $links; do
>>> index=$(( $index + 1 ))
>>> something with $link and $index
>>>
>>> If the indices are arbitrary:
>>>
>>>   links="1:A 4:B 7:C 10:D"
>>>   for linkinfo in $links; do
>>> link=${linkinfo#*:}
>>> index=${linkinfo%%:*}
>>> something with $link and $index
>>
>> The indices are not successive, in one case they are a function of two
>> enclosing loop indices, such as
> By `indices' I meant the things which in your code are 1 2 3 4.
> Apparently there is a different thing called an `idx'.
>
> Your code below suggests that the numbers you need for each A B C D
> are indeed successive integers.
>
>> for dev in $(seq 1 31)
>> do
>> for intx in $(seq 0 3)
>> do
>> link_idx=$(((dev + intx) & 3))
>> printf "Package(){0x%04x, %u, _SB.PCI0.LNK%c,
>> 0},\n" \
>> $dev $intx ${links:$link_idx:1}
>> done
>> done
>>
>> (And then there might also be a question of portability with the second
>> approach?)
>>
>> So if you don't object to
>>
>> link=`echo "A B C D" | cut -d" " -f $i`
>>
>> I'd rather go with that.
> I would still prefer
>
>links="A B C D"
>linkcounter=0
>for link in $links
>do
>linkcounter=$(( $linkcounter + 1))
>link_idx=$(( ($dev + $linkcounter) & 3 ))
>

This will not produce what I am trying to print tough. I want this sequence:

B   C   D   A   C   D   A   B   D   A   B   C   A

I can reverse loop order (I believe that even though resulting ASL will
be different, the AML binary that iasl produces will stay the same) but
then I think I will also need to reverse the dev loop direction.

Or I am just not understanding what you are suggesting.

-boris




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

Re: [Xen-devel] [Patch] x86emul: simplify prefix handling for VMFUNC

[Lai, Paul]

On Wed, Sep 21, 2016 at 10:22:32AM -0700, Lai, Paul wrote:
> On Wed, Sep 21, 2016 at 02:39:58AM -0600, Jan Beulich wrote:
> > >>> On 21.09.16 at 00:35,  wrote:
> > > On Tue, Sep 20, 2016 at 09:50:15AM -0600, Jan Beulich wrote:
> > >> 
> > >> Paul, there's been no reply to
> > >> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg00380.html
> > >>  
> > > 
> > > The refered to patch, commit a1b1572833, adds a check for vmfunc.
> > > I look a little time to look at the SDM and finally found the reference.
> > > The vmfunc can be found in Table A-6 "Opcode Extensions for One- and Two-
> > > byte Opcodes by Group Number" on page A-18 Vol. 2D of the
> > >  e64-ia-32-architectures-software-developer-manual-325462.pdf.
> > > The values for vmfunc match the values in the code.
> > > I also took the liberty of looking at the other existing cases in the
> > > switch statement, and can find RDTSCP and INVLPG. The CLZERO extension
> > > value is a mystery to me.
> > 
> > Well - the question raised was whether the documentation is
> > perhaps wrong.
> 
> VMFUNC allowing 66, F2, and F3 prefixes when
> > other opcodes in its neighborhood (e.g. xsetbv, xtest, xend)
> > don't seems at least suspicious. 
> 
> Thanks for the clearer problem statement. 
> 
> > Extensions originating from AMD
> > (rdtscp, clzero) can't be reasonably taken for reference.
> > 
> > Jan
> > 
> 
> I'll check
> 
At the bottom of the A-6 Table ("Opcode Extensions for One- and Two- byte
Opcodes by Group Number") there's a footnote that states
   All blanks in all opcode maps are reserved and must not be used.
   Do not depend on the operation of undefined or reserved locations
So, since the "pfx" value for Group 7 opcodes are "blank", none are allowed,
and an "#UD" is expected if a "pfx" is used.

I also checked the narrative descriptions of vmfunc (and similar opcodes,
in particular the list in 25.1.3 "Instructions That Cause VM Exits
Conditionally").  None of the descriptions seem to state explicitly the
expected values of "pfx", nor the behavior of a "bad pfx".  That said, the
table and footnote seem to be the most explicit, cleanest way of communicating
the information.

-Paul


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

Re: [Xen-devel] [PATCH RFC 01/12] PVHv2 Dom0

[Konrad Rzeszutek Wilk]

On Mon, Sep 26, 2016 at 07:12:39PM +0200, Roger Pau Monne wrote:
> On Mon, Sep 26, 2016 at 10:25:06AM -0600, Jan Beulich wrote:
> > >>> On 29.07.16 at 18:28,  wrote:
> > > This is a very rough implementation of a PVHv2 Dom0. There are still a 
> > > bunch 
> > > 
> > > of things that will not work properly (like SR-IOV, MSI, MSI-X...), but 
> > > it 
> > > *should* be able to boot a Dom0 kernel and it doesn't require using PIRQs.
> > 
> > It's been a long time since you had posted this, but I thought I'd
> > take a coarse look nevertheless. Basic concept looks okay, but of
> > course there are many rough edges.
> 
> Yes, sorry, it took longer than expected. I've just rebased all the HVM Dom0 
> code today and I will post a new version before the end of the week, this 
> time with PCIe, MSI and MSI-X support.

And please CC me and Boris on them.

Thanks.

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 065ae7d717f9e49c3be12dada109d60dead0bb90
baseline version:
 ovmf 587e9dfbbafe7d4e772c1870b8c880c6d7a8a70c

Last test of basis67761  2016-09-25 02:49:05 Z1 days
Testing same since67763  2016-09-26 15:16:38 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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


Push not applicable.


commit 065ae7d717f9e49c3be12dada109d60dead0bb90
Author: Ard Biesheuvel 
Date:   Mon Sep 19 09:36:13 2016 +0100

MdeModulePkg/PciBusDxe: make OPROM BAR degradation configurable

The 'universal' PCI bus driver in MdeModulePkg contains a quirk to
degrade 64-bit PCI MMIO BARs to 32-bit in the presence of an option
ROM on the same PCI controller.

This quirk is highly specific to not just the X64 architecture in general,
but to the PC platform in particular, given that only X64 platforms that
require legacy PC BIOS compatibility require it. However, making the
quirk dependent on the presence of the legacy BIOS protocol met with
resistance, due to the fact that it introduces a dependency on the
IntelFrameworkModulePkg package.

So instead, make the quirk configurable, by introducing a feature flag PCD
'PcdPciDegradeResourceForOptionRom' which defaults to TRUE only for X64.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Ruiyu Ni 

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

[Xen-devel] [PATCH Altp2m cleanup v6] altp2m cleanup work.

[Paul Lai]

Indent goto labels by one space.
Inline (header) altp2m functions.
In do_altp2m_op(), during the sanity check of the passed command,
return -ENONSYS if not a valid command.
In do_altp2m_op(), when evaluating a command, ASSERT_UNREACHABLE()
if the command is not recognizable.  The sanity check above should
have triggered the return of -ENOSYS.

Changes since last version:

Fixing fall through in switch statement above ASSERT_UNREACHABLE() (in
do_altp2m_op()).
Make hvm_funcs.altp2m_supported "bool" instead of "bool_t".
Make hvm_altp2m_supported() and altp2m_vcpu_emulate_ve() return
bool (rather than return void()).

Signed-off-by: Paul Lai 
---
 xen/arch/x86/hvm/hvm.c| 47 ---
 xen/include/asm-x86/hvm/hvm.h | 26 +++-
 2 files changed, 43 insertions(+), 30 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7bad845..3a4ea56 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1959,11 +1959,11 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
long gla,
  * Otherwise, this is an error condition. */
 rc = fall_through;
 
-out_put_gfn:
+ out_put_gfn:
 __put_gfn(p2m, gfn);
 if ( ap2m_active )
 __put_gfn(hostp2m, gfn);
-out:
+ out:
 /* All of these are delayed until we exit, since we might 
  * sleep on event ring wait queues, and we must not hold
  * locks in such circumstance */
@@ -5308,12 +5308,25 @@ static int do_altp2m_op(
 return -EFAULT;
 
 if ( a.pad1 || a.pad2 ||
- (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
- (a.cmd < HVMOP_altp2m_get_domain_state) ||
- (a.cmd > HVMOP_altp2m_change_gfn) )
+(a.version != HVMOP_ALTP2M_INTERFACE_VERSION) )
 return -EINVAL;
 
-d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
+switch ( a.cmd )
+{
+case HVMOP_altp2m_get_domain_state:
+case HVMOP_altp2m_set_domain_state:
+case HVMOP_altp2m_vcpu_enable_notify:
+case HVMOP_altp2m_create_p2m:
+case HVMOP_altp2m_destroy_p2m:
+case HVMOP_altp2m_switch_p2m:
+case HVMOP_altp2m_set_mem_access:
+case HVMOP_altp2m_change_gfn:
+break;
+default:
+return -ENOSYS;
+}
+
+d = ( a.cmd != HVMOP_altp2m_vcpu_enable_notify ) ?
 rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
 
 if ( d == NULL )
@@ -5430,6 +5443,9 @@ static int do_altp2m_op(
 rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
 _gfn(a.u.change_gfn.old_gfn),
 _gfn(a.u.change_gfn.new_gfn));
+break;
+default:
+ASSERT_UNREACHABLE();
 }
 
  out:
@@ -5954,25 +5970,6 @@ void hvm_toggle_singlestep(struct vcpu *v)
 v->arch.hvm_vcpu.single_step = !v->arch.hvm_vcpu.single_step;
 }
 
-void altp2m_vcpu_update_p2m(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_update_p2m )
-hvm_funcs.altp2m_vcpu_update_p2m(v);
-}
-
-void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve )
-hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v);
-}
-
-bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_emulate_ve )
-return hvm_funcs.altp2m_vcpu_emulate_ve(v);
-return 0;
-}
-
 int hvm_set_mode(struct vcpu *v, int mode)
 {
 
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 81b60d5..b1be6bd 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -100,7 +100,7 @@ struct hvm_function_table {
 bool_t pvh_supported;
 
 /* Necessary hardware support for alternate p2m's? */
-bool_t altp2m_supported;
+bool altp2m_supported;
 
 /* Indicate HAP capabilities. */
 unsigned int hap_capabilities;
@@ -593,19 +593,35 @@ static inline bool_t hvm_is_singlestep_supported(void)
 }
 
 /* returns true if hardware supports alternate p2m's */
-static inline bool_t hvm_altp2m_supported(void)
+static inline bool hvm_altp2m_supported(void)
 {
 return hvm_funcs.altp2m_supported;
 }
 
 /* updates the current hardware p2m */
-void altp2m_vcpu_update_p2m(struct vcpu *v);
+static inline void altp2m_vcpu_update_p2m(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_update_p2m )
+hvm_funcs.altp2m_vcpu_update_p2m(v);
+}
 
 /* updates VMCS fields related to VMFUNC and #VE */
-void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v);
+static inline void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve )
+hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v);
+}
 
 /* emulates #VE */
-bool_t altp2m_vcpu_emulate_ve(struct vcpu *v);
+static inline bool altp2m_vcpu_emulate_ve(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_emulate_ve )
+{
+hvm_funcs.altp2m_vcpu_emulate_ve(v);
+return true;
+}
+return false;
+}
 
 /* Check CR4/EFER values */
 const char *hvm_efer_valid(const struct vcpu *v, uint64_t 

[Xen-devel] [PATCH Altp2m cleanup v6] Cleaning up altp2m code

[Paul Lai]

Altp2m cleanup work

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

Most of the work has been:
Lots of white space, indentation, and other coding style preference
corrections.
Lots of function return type corrections (and checking).
Better sanity checking of values before processing in do_altp2m_op().
Using 'bool' instead of 'bool_t' for stronger checking.

Paul Lai (1):
  altp2m cleanup work.

 xen/arch/x86/hvm/hvm.c| 47 ---
 xen/include/asm-x86/hvm/hvm.h | 26 +++-
 2 files changed, 43 insertions(+), 30 deletions(-)

-- 
2.7.4


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

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

[osstest service owner]

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

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  89c423a170de2fef08445ea9151bcfa15c45b217
baseline version:
 xen  a75f34462612a05547fc43d192705a9c31cad7fb

Last test of basis   101126  2016-09-23 17:02:04 Z3 days
Testing same since   101153  2016-09-26 16:00:59 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Borislav Petkov 
  Emanuel Czirai 
  Jan Beulich 
  Kevin Tian 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=89c423a170de2fef08445ea9151bcfa15c45b217
+ . ./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 
89c423a170de2fef08445ea9151bcfa15c45b217
+ branch=xen-unstable-smoke
+ revision=89c423a170de2fef08445ea9151bcfa15c45b217
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x89c423a170de2fef08445ea9151bcfa15c45b217 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : 

Re: [Xen-devel] [PATCH Altp2m cleanup v5 1/3] altp2m cleanup work.

[Lai, Paul]

On Mon, Sep 26, 2016 at 10:01:50AM -0600, Jan Beulich wrote:
> >>> On 13.09.16 at 18:46,  wrote:
> > Indent goto labels by one space.
> > Inline (header) altp2m functions.
> > In do_altp2m_op(), during the sanity check of the passed command,
> > return -ENONSYS if not a valid command.
> > In do_altp2m_op(), when evaluating a command, ASSERT_UNREACHABLE()
> > if the command is not recognizable.  The sanity check above should
> > have triggered the return of -ENOSYS.
> > Make altp2m_vcpu_emulate_ve() return actual bool_t (rather than return
> > void()).
> > 
> > Signed-off-by: Paul Lai 
> > ---
> 
> It is very disappointing to find that there is still no information here
> on what changed from the previous version.
> 
> > @@ -5349,6 +5362,8 @@ static int do_altp2m_op(
> >  rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
> >  _gfn(a.u.change_gfn.old_gfn),
> >  _gfn(a.u.change_gfn.new_gfn));
> > +default:
> > +ASSERT_UNREACHABLE();
> >  }
> 
> And it is even worse that the bug pointed out here is still present.

I reread the comment in 
   https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg00937.html
and missed the "unintended fallthrough".
Will correct.

> 
> >  /* emulates #VE */
> > -bool_t altp2m_vcpu_emulate_ve(struct vcpu *v);
> > +static inline bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
> 
> Nor did you switch to plain bool here, as was requested during both
> v3 and v4 review.

I did not know "bool" existed, and thought "plain bool" was "bool_t".
I have looked around and see that "bool" is better defined ({0,1} instead of
{0, !0}) and hopefully understand your motivation for using/requiring it.
> 
> Please do not resubmit this series until you have taken care of
> _all_ review comments you've received so far. As with the
> previous version I'm not going to spend time looking at the other
> two patches due to this fundamental requirement, despite
> having been pointed out before, not being met.
> 
> Jan
> 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 00df35fe4146b6ceb39bf55df1fabec955cd08a6
baseline version:
 ovmf 065ae7d717f9e49c3be12dada109d60dead0bb90

Last test of basis   101151  2016-09-26 13:14:58 Z0 days
Testing same since   101152  2016-09-26 15:14:13 Z0 days1 attempts


People who touched revisions under test:
  Hegde Nagaraj P 
  Jiaxin Wu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=00df35fe4146b6ceb39bf55df1fabec955cd08a6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
00df35fe4146b6ceb39bf55df1fabec955cd08a6
+ branch=ovmf
+ revision=00df35fe4146b6ceb39bf55df1fabec955cd08a6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x00df35fe4146b6ceb39bf55df1fabec955cd08a6 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH 2/2] tools/configure: fix --with-system-{ovmf/seabios}

[Roger Pau Monne]

On Mon, Sep 26, 2016 at 05:57:00PM +0100, Wei Liu wrote:
> On Mon, Sep 26, 2016 at 06:44:09PM +0200, Roger Pau Monne wrote:
> > Current configure code doesn't define {SEABIOS/OVMF}_PATH when
> > --with-system-{ovmf/seabios} is used. Fix this by making sure those defines
> > are always set if the internal {ovmf/seabios}_path variables are also set.
> > 
> > Signed-off-by: Roger Pau Monné 
> > Cc: Wei Liu 
> > Cc: Ian Jackson 
> > ---
> > Please re-run autogen.sh before committing.
> > ---
> >  tools/configure.ac | 14 ++
> >  1 file changed, 6 insertions(+), 8 deletions(-)
> > 
> > diff --git a/tools/configure.ac b/tools/configure.ac
> > index f010d72..6788ea2 100644
> > --- a/tools/configure.ac
> > +++ b/tools/configure.ac
> > @@ -222,10 +222,9 @@ AC_ARG_WITH([system-seabios],
> >  *)  seabios_path=$withval ;;
> >  esac
> >  ],[])
> > -AS_IF([test "x$seabios" = "xy"], [
> > -AC_DEFINE_UNQUOTED([SEABIOS_PATH],
> > -   ["${seabios_path:-$XENFIRMWAREDIR/seabios.bin}"],
> > -   [SeaBIOS path])
> > +AS_IF([test "x$seabios" = "xy"], 
> > [seabios_path=$XENFIRMWAREDIR/seabios.bin])
> > +AS_IF([test -n "$seabios_path"], [
> > +AC_DEFINE_UNQUOTED([SEABIOS_PATH],["$seabios_path"],[SeaBIOS path])
> >  ])
> 
> What about just change the test condition in the original code to
> 
>   test "x$seabios" = "xy" || -n "$seabios_path"
> 
> ?
>
> That should result in the same thing, right?

Yes, that's right. Should I do it, or are you going to send it? TBH, it's 
just a one line change, and the idea is yours.

Roger.

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

Re: [Xen-devel] [PATCH RFC 01/12] PVHv2 Dom0

[Roger Pau Monne]

On Mon, Sep 26, 2016 at 10:25:06AM -0600, Jan Beulich wrote:
> >>> On 29.07.16 at 18:28,  wrote:
> > This is a very rough implementation of a PVHv2 Dom0. There are still a 
> > bunch 
> > 
> > of things that will not work properly (like SR-IOV, MSI, MSI-X...), but it 
> > *should* be able to boot a Dom0 kernel and it doesn't require using PIRQs.
> 
> It's been a long time since you had posted this, but I thought I'd
> take a coarse look nevertheless. Basic concept looks okay, but of
> course there are many rough edges.

Yes, sorry, it took longer than expected. I've just rebased all the HVM Dom0 
code today and I will post a new version before the end of the week, this 
time with PCIe, MSI and MSI-X support.

Roger.

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

Re: [Xen-devel] [PATCH RFC 07/12] xen/x86: parse Dom0 kernel for PVHv2

[Roger Pau Monne]

On Mon, Sep 26, 2016 at 10:16:19AM -0600, Jan Beulich wrote:
> >>> On 29.07.16 at 18:29,  wrote:
> > Introduce a helper to parse the Dom0 kernel.
> 
> It would help if you clarified why this needs to be different from
> the PV ELF parsing - to me, ELF is ELF, so no duplication should
> be necessary from a very high level perspective.

AFAICT, the current elf loader code in the PV Dom0 builder uses virtual 
addresses, and the HVM Dom0 builder only uses physical addresses. I agree 
that it could probably be made to work for both, but it's going to make the 
code more complex, and I really prefer the HVM Dom0 builder to be as clean 
and simple as possible.

Roger.

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

Re: [Xen-devel] [PATCH RFC 08/12] xen/x86: setup PVHv2 Dom0 CPUs

[Roger Pau Monne]

On Mon, Sep 26, 2016 at 10:19:04AM -0600, Jan Beulich wrote:
> >>> On 29.07.16 at 18:29,  wrote:
> > Initialize Dom0 BSP/APs and setup the memory and IO permissions.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > ---
> > The logic used to setup the CPUID leaves is extremely simplistic (and
> > probably wrong for hardware different than mine). I'm not sure what's the
> > best way to deal with this, the code that currently sets the CPUID leaves
> > for HVM guests lives in libxc, maybe moving it xen/common would be better?
> 
> Why don't you just set them from their respective hardware values?

That's what I'm already doing in this patch, but I'm not sure what should be 
removed (at least virt extensions should be removed, but I guess there's 
other stuff that we might want to remove too).
 
> > +static int __init hvm_setup_cpus(struct domain *d, paddr_t entry,
> > + paddr_t start_info)
> > +{
> > +vcpu_hvm_context_t cpu_ctx;
> > +struct vcpu *v = d->vcpu[0];
> > +int cpu, i, rc;
> > +struct {
> > +uint32_t index;
> > +uint32_t count;
> > +} cpuid_leaves[] = {
> > +{0, XEN_CPUID_INPUT_UNUSED},
> > +{1, XEN_CPUID_INPUT_UNUSED},
> > +{2, XEN_CPUID_INPUT_UNUSED},
> > +{4, 0},
> > +{4, 1},
> > +{4, 2},
> > +{4, 3},
> > +{4, 4},
> > +{7, 0},
> > +{0xa, XEN_CPUID_INPUT_UNUSED},
> > +{0xd, 0},
> > +{0x8000, XEN_CPUID_INPUT_UNUSED},
> > +{0x8001, XEN_CPUID_INPUT_UNUSED},
> > +{0x8002, XEN_CPUID_INPUT_UNUSED},
> > +{0x8003, XEN_CPUID_INPUT_UNUSED},
> > +{0x8004, XEN_CPUID_INPUT_UNUSED},
> > +{0x8005, XEN_CPUID_INPUT_UNUSED},
> > +{0x8006, XEN_CPUID_INPUT_UNUSED},
> > +{0x8007, XEN_CPUID_INPUT_UNUSED},
> > +{0x8008, XEN_CPUID_INPUT_UNUSED},
> > +};
> > +
> > +printk("** Setting up BSP/APs **\n");
> > +
> > +cpu = v->processor;
> > +for ( i = 1; i < d->max_vcpus; i++ )
> > +{
> > +cpu = cpumask_cycle(cpu, _cpus);
> > +setup_dom0_vcpu(d, i, cpu);
> > +}
> > +
> > +memset(_ctx, 0, sizeof(cpu_ctx));
> > +
> > +cpu_ctx.mode = VCPU_HVM_MODE_32B;
> > +
> > +cpu_ctx.cpu_regs.x86_32.ebx = start_info;
> > +cpu_ctx.cpu_regs.x86_32.eip = entry;
> > +cpu_ctx.cpu_regs.x86_32.cr0 = X86_CR0_PE | X86_CR0_ET;
> > +
> > +cpu_ctx.cpu_regs.x86_32.cs_limit = ~0u;
> > +cpu_ctx.cpu_regs.x86_32.ds_limit = ~0u;
> > +cpu_ctx.cpu_regs.x86_32.ss_limit = ~0u;
> > +cpu_ctx.cpu_regs.x86_32.tr_limit = 0x67;
> > +cpu_ctx.cpu_regs.x86_32.cs_ar = 0xc9b;
> > +cpu_ctx.cpu_regs.x86_32.ds_ar = 0xc93;
> > +cpu_ctx.cpu_regs.x86_32.ss_ar = 0xc93;
> > +cpu_ctx.cpu_regs.x86_32.tr_ar = 0x8b;
> 
> Much of this should be power on state of a HVM vCPU anyway, so
> it's not immediately clear why all of this is needed.

Oh, since I couldn't find any reference to the power on state of a HVM 
vCPU I though it might be better to set it all here, so it's clear what's 
the state on power on.

Roger.

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

Re: [Xen-devel] [PATCH 2/2] tools/configure: fix --with-system-{ovmf/seabios}

[Wei Liu]

On Mon, Sep 26, 2016 at 06:44:09PM +0200, Roger Pau Monne wrote:
> Current configure code doesn't define {SEABIOS/OVMF}_PATH when
> --with-system-{ovmf/seabios} is used. Fix this by making sure those defines
> are always set if the internal {ovmf/seabios}_path variables are also set.
> 
> Signed-off-by: Roger Pau Monné 
> Cc: Wei Liu 
> Cc: Ian Jackson 
> ---
> Please re-run autogen.sh before committing.
> ---
>  tools/configure.ac | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/configure.ac b/tools/configure.ac
> index f010d72..6788ea2 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -222,10 +222,9 @@ AC_ARG_WITH([system-seabios],
>  *)  seabios_path=$withval ;;
>  esac
>  ],[])
> -AS_IF([test "x$seabios" = "xy"], [
> -AC_DEFINE_UNQUOTED([SEABIOS_PATH],
> -   ["${seabios_path:-$XENFIRMWAREDIR/seabios.bin}"],
> -   [SeaBIOS path])
> +AS_IF([test "x$seabios" = "xy"], [seabios_path=$XENFIRMWAREDIR/seabios.bin])
> +AS_IF([test -n "$seabios_path"], [
> +AC_DEFINE_UNQUOTED([SEABIOS_PATH],["$seabios_path"],[SeaBIOS path])
>  ])

What about just change the test condition in the original code to

  test "x$seabios" = "xy" || -n "$seabios_path"

?

That should result in the same thing, right?


>  
>  AC_ARG_WITH([system-ovmf],
> @@ -239,10 +238,9 @@ AC_ARG_WITH([system-ovmf],
>  *)  ovmf_path=$withval ;;
>  esac
>  ],[])
> -AS_IF([test "x$ovmf" = "xy"], [
> -AC_DEFINE_UNQUOTED([OVMF_PATH],
> -   ["${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"],
> -   [OVMF path])
> +AS_IF([test "x$ovmf" = "xy"], [ovmf_path=$XENFIRMWAREDIR/ovmf.bin])
> +AS_IF([test -n "$ovmf_path"], [
> +AC_DEFINE_UNQUOTED([OVMF_PATH],["$ovmf_path"],[OVMF path])
>  ])
>  
>  AC_ARG_WITH([extra-qemuu-configure-args],
> -- 
> 2.7.4 (Apple Git-66)
> 

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

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

[Ian Jackson]

Ian Jackson writes ("Re: Problem with Xen 4.5 failing XTF tests on old AMD cpus 
?"):
> Andrew Cooper writes ("Re: Problem with Xen 4.5 failing XTF tests on old AMD 
> cpus ?"):
> > It will be because of Gen1 SVM which doesn't have NRIP support. This 
> > case requires emulation of the invlpg instruction, rather than just 
> > using the information provided by the intercept.
> 
> So it seems that the xtf test is not effective at detecting the Xen
> bug except on old hardware ?  Is there some way it could be improved ?
> 
> It's obviously not desirable that we should have tests which pass in
> the production colo and fail in the ancient Citrix Cambridge instance.

Andrew and I discussed this IRL.  I thought it worth writing down what
was said so that we can refer to it later.

This test failure is due to genuine bug(s) in Xen 4.5, in that it
doesn't have various fixes (see the rest of the thread).

The bugs are only exposed on old hardware, which uses different
codepaths in Xen.  On new hardware Xen takes a different approach.
This is why the test failure appears in the Citrix (Cambridge)
osstest but not in the Xen Project (Massachusetts) instance.

Xen decides which approach to take based on hardware features.  There
is not currently any way to tell Xen not to use these hardware
features (at least, not in this case - the AMD SVM NextRIP feature) if
they are available.  Andrew has a long-term plan to add more of such a
facility - but that is not going to be available any time soon.

In this particular case, the old hardware uses the Xen instruction
emulator where newer hardware uses hardware support.  (Andrew tells me
that without NextRIP support, Xen must use the instruction emulator
when handling `invlpg` instructions on behalf of the guest, to
calculate how many bytes to move the instruction pointer forward by.
And it is the emulator which has the bug here.)

So FEP could be used to cause the bug to manifest even on new hardware
and indeed where FEP is available, XTF does then use FEP to run
exactly the same set of tests.  However, FEP is not available in Xen
4.5 and there are good reasons for not backporting it there.

It would be possible to backport the bugfixes to Xen 4.5.  However,
the bugs address only very rare problems.  Andrew thinks the bugs
are, insofar they are bugs which might cause lossage, more likely to
bbe roughly "crashes obscure or very oddly-behaved guests" than
"crashes commonly used guests but only with very low probability.
The latter kind of bug would be worth a backport; the former much
less so (especially in a very old stable release, and especially
when the fixes involve behavioural changes).

The fixes would also provide an unquantified performance improvement
on AMD hardware, due to avoiding extraneous TLB flushes, but Andrew
says he doubts that's worth caring about.

We discussed host stickiness, host-specific bug detection, and
regression detection, in osstest.  I reassured Andrew that I think
the current osstest algorithms will deal with this situation
tolerably well (if not perfectly).

The conclusion is that there is nothing to be done, at least in the
short term.  There are good reasons for the bug to persist in 4.5 and
good reasons for it being hard to detect on newer hardware.

Ian.

(Thanks to Andrew for the IRL explanation and for review of this
email.)

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

Re: [Xen-devel] OUTREACHY 2016

[Roger Pau Monné]

On Sun, Sep 25, 2016 at 08:09:00PM +0530, Anamika Das wrote:
> Sir,
>  My name is Anamika Das and I am in my final year of  M.E. Computer
> Science postgraduate student from BITS Pilani Hyderabad, India. My
> proficiency revolves around the areas of  C/C++, C#.
>  I have successfully completed my project with Digital India with
> collaboration of Microsoft (India).
>  I would love to contribute to the Outreachy 2016. I have seen the
> project ideas on your organization page- XenProject, Projects- *Add PVH
> mode support to OVMF and QEMU xen*. It would be great if you could mentor
> me to further understand the intricacies of the projects.With the help of
> my resume, if you could guide me for the selection of the project. If there
> is any dedicated task then I would like to get the details. I am sending my
> resume attached.

Hello,

I'm sorry but this project is already under development and is no longer 
available to OPW students. Please see the following thread if you want more 
information about it, and another project which you might be interested in 
(also related to OVMF):

https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01106.html

Roger.

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

Re: [Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread

[Roger Pau Monné]

On Wed, Sep 21, 2016 at 10:07:10AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 21, 2016 at 09:50:30AM -0400, Chris Patterson wrote:
> > On Wed, Sep 21, 2016 at 9:00 AM, Wei Liu  wrote:
> > > On Wed, Sep 21, 2016 at 08:51:07AM -0400, Konrad Rzeszutek Wilk wrote:
> > >> On Tue, Sep 20, 2016 at 05:29:39PM -0400, Chris Patterson wrote:
> > >> > From: Chris Patterson 
> > >> >
> > >> > xs_watch() creates a thread to listen to xenstore events.  Currently, 
> > >> > the
> > >> > thread is created with the greater of 16K or PTHREAD_MIN_SIZE.
> > >> >
> > >> > There have been several bug reports and workarounds related to the 
> > >> > issue
> > >> > where xs_watch() fails because its attempt to create the reader thread 
> > >> > with
> > >> > pthread_create() fails. This is due to insufficient stack space size
> > >> > given the requirements for thread-local storage usage in the 
> > >> > applications
> > >> > and libraries that are linked against libxenstore.  [1,2,3,4].
> > >> >
> > >> > Specifying the stack size appears to have been added to reduce memory
> > >> > footprint (1d00c73b983b09fbee4d9dc0f58f6663c361c345).
> > >>
> > >> Ugh. 8MB.
> > >
> > > OOI isn't that 8MB virtual memory, which means it shouldn't have real
> > > impact unless it is used?
> 
> /me nods. That is my recollection too. But it does mean that 'top'
> shows the application as bigger (by 8MB).
> 
> > >
> > 
> > >From what I understand, that is correct.  At least in the Linux/glibc
> > case, I believe the stack is allocated using anonymous mmap() and that
> > resident memory usage shouldn't be greater than what you actually end
> > up writing.  However, I do not know if this holds true universally...
> 
> That should be faily easy to find out. One just needs to check
> the RSS size. Not sure how to do that on FreeBSD thought..

In any case, I don't think we should be setting the pthread stack size at 
all, we don't really know how much stack libc functions will try to use, so 
setting this to any value is likely wrong IMHO.

Roger.

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

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Ian Jackson]

Boris Ostrovsky writes ("Re: [PATCH v6] acpi: Prevent GPL-only code from 
seeping into non-GPL binaries"):
> On 09/26/2016 10:45 AM, Ian Jackson wrote:
> > If the indices are necessarily successive integers:
> >
> >   links="A B C D"
> >   index=0
> >   for link in $links; do
> > index=$(( $index + 1 ))
> > something with $link and $index
> >
> > If the indices are arbitrary:
> >
> >   links="1:A 4:B 7:C 10:D"
> >   for linkinfo in $links; do
> > link=${linkinfo#*:}
> > index=${linkinfo%%:*}
> > something with $link and $index
> 
> 
> The indices are not successive, in one case they are a function of two
> enclosing loop indices, such as

By `indices' I meant the things which in your code are 1 2 3 4.
Apparently there is a different thing called an `idx'.

Your code below suggests that the numbers you need for each A B C D
are indeed successive integers.

> for dev in $(seq 1 31)
> do
> for intx in $(seq 0 3)
> do
> link_idx=$(((dev + intx) & 3))
> printf "Package(){0x%04x, %u, _SB.PCI0.LNK%c,
> 0},\n" \
> $dev $intx ${links:$link_idx:1}
> done
> done
> 
> (And then there might also be a question of portability with the second
> approach?)
> 
> So if you don't object to
> 
> link=`echo "A B C D" | cut -d" " -f $i`
> 
> I'd rather go with that.

I would still prefer

   links="A B C D"
   linkcounter=0
   for link in $links
   do
   linkcounter=$(( $linkcounter + 1))
   link_idx=$(( ($dev + $linkcounter) & 3 ))

I think this is a lot easier to read than messing about with seq and
string slicing.

NB that the spaces inside the $(( )) are IMO essential for
readability.

Ian.

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

Re: [Xen-devel] [PATCH 1/2] lib/gnttab: fix build of gnttab_unimp.c

[Wei Liu]

I will change lib to libs in subject line while committing

On Mon, Sep 26, 2016 at 06:44:08PM +0200, Roger Pau Monne wrote:
> Fix the definition of the xengnttab_grant_copy function so it's inline with

in line with

> the prototypes in xengnttab.h.
> 
> This unbreaks the tools build on systems that don't have a gnttab device.
> 
> Signed-off-by: Roger Pau Monné 
> Cc: Ian Jackson 
> Cc: Wei Liu 

Acked-by: Wei Liu 

> ---
>  tools/libs/gnttab/gnttab_unimp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libs/gnttab/gnttab_unimp.c 
> b/tools/libs/gnttab/gnttab_unimp.c
> index 829eced..26e4ee1 100644
> --- a/tools/libs/gnttab/gnttab_unimp.c
> +++ b/tools/libs/gnttab/gnttab_unimp.c
> @@ -78,9 +78,9 @@ int xengnttab_unmap(xengnttab_handle *xgt, void 
> *start_address, uint32_t count)
>  abort();
>  }
>  
> -int xengnttab_copy_grant(xengnttab_handle *xgt,
> +int xengnttab_grant_copy(xengnttab_handle *xgt,
>   uint32_t count,
> - xengnttab_copy_grant_segment_t *segs)
> + xengnttab_grant_copy_segment_t *segs)
>  {
>  abort();
>  }
> -- 
> 2.7.4 (Apple Git-66)
> 

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

[Xen-devel] [PATCH 1/2] lib/gnttab: fix build of gnttab_unimp.c

[Roger Pau Monne]

Fix the definition of the xengnttab_grant_copy function so it's inline with
the prototypes in xengnttab.h.

This unbreaks the tools build on systems that don't have a gnttab device.

Signed-off-by: Roger Pau Monné 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libs/gnttab/gnttab_unimp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libs/gnttab/gnttab_unimp.c b/tools/libs/gnttab/gnttab_unimp.c
index 829eced..26e4ee1 100644
--- a/tools/libs/gnttab/gnttab_unimp.c
+++ b/tools/libs/gnttab/gnttab_unimp.c
@@ -78,9 +78,9 @@ int xengnttab_unmap(xengnttab_handle *xgt, void 
*start_address, uint32_t count)
 abort();
 }
 
-int xengnttab_copy_grant(xengnttab_handle *xgt,
+int xengnttab_grant_copy(xengnttab_handle *xgt,
  uint32_t count,
- xengnttab_copy_grant_segment_t *segs)
+ xengnttab_grant_copy_segment_t *segs)
 {
 abort();
 }
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH 0/2] tools: misc fixes

[Roger Pau Monne]

Two fixes for the tools, one is a typo fix and the other one is a fix for 
configure.

Roger.

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

[Xen-devel] [PATCH 2/2] tools/configure: fix --with-system-{ovmf/seabios}

[Roger Pau Monne]

Current configure code doesn't define {SEABIOS/OVMF}_PATH when
--with-system-{ovmf/seabios} is used. Fix this by making sure those defines
are always set if the internal {ovmf/seabios}_path variables are also set.

Signed-off-by: Roger Pau Monné 
Cc: Wei Liu 
Cc: Ian Jackson 
---
Please re-run autogen.sh before committing.
---
 tools/configure.ac | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index f010d72..6788ea2 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -222,10 +222,9 @@ AC_ARG_WITH([system-seabios],
 *)  seabios_path=$withval ;;
 esac
 ],[])
-AS_IF([test "x$seabios" = "xy"], [
-AC_DEFINE_UNQUOTED([SEABIOS_PATH],
-   ["${seabios_path:-$XENFIRMWAREDIR/seabios.bin}"],
-   [SeaBIOS path])
+AS_IF([test "x$seabios" = "xy"], [seabios_path=$XENFIRMWAREDIR/seabios.bin])
+AS_IF([test -n "$seabios_path"], [
+AC_DEFINE_UNQUOTED([SEABIOS_PATH],["$seabios_path"],[SeaBIOS path])
 ])
 
 AC_ARG_WITH([system-ovmf],
@@ -239,10 +238,9 @@ AC_ARG_WITH([system-ovmf],
 *)  ovmf_path=$withval ;;
 esac
 ],[])
-AS_IF([test "x$ovmf" = "xy"], [
-AC_DEFINE_UNQUOTED([OVMF_PATH],
-   ["${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"],
-   [OVMF path])
+AS_IF([test "x$ovmf" = "xy"], [ovmf_path=$XENFIRMWAREDIR/ovmf.bin])
+AS_IF([test -n "$ovmf_path"], [
+AC_DEFINE_UNQUOTED([OVMF_PATH],["$ovmf_path"],[OVMF path])
 ])
 
 AC_ARG_WITH([extra-qemuu-configure-args],
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [OSSTEST PATCH 2/3] mg-bisect-activity-*: New rather ad-hoc scripts for wall clock timing analysys

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 .gitignore|   2 +
 README.bisect-wallclock-analysis  |  85 ++
 mg-bisect-activity-collect-emails |  55 
 mg-bisect-activity-collect-tmpdir |  94 
 mg-bisect-activity-create-db  |  17 
 mg-bisect-activity-dump-periods   | 181 ++
 6 files changed, 434 insertions(+)
 create mode 100644 README.bisect-wallclock-analysis
 create mode 100755 mg-bisect-activity-collect-emails
 create mode 100755 mg-bisect-activity-collect-tmpdir
 create mode 100755 mg-bisect-activity-create-db
 create mode 100755 mg-bisect-activity-dump-periods

diff --git a/.gitignore b/.gitignore
index 69f7743..425506b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -33,3 +33,5 @@ images
 diskusage-[A-Z]*.html
 diskusage-[A-Z]*.png
 diskusage-[A-Z]*.pdf
+bisect-timing.db
+*.tmp
diff --git a/README.bisect-wallclock-analysis b/README.bisect-wallclock-analysis
new file mode 100644
index 000..856ee2c
--- /dev/null
+++ b/README.bisect-wallclock-analysis
@@ -0,0 +1,85 @@
+General approach
+
+
+ * Decide what branch to analyise.
+
+ * Save all the relevant emails generated by osstest (including the
+   main flight reports and the bisection reports) to an mbox called
+   eg bisect-data/report-emails
+
+ * Make a copy (with timestamps!) the tmp/ directory of the relevant
+   tree on the controller, eg in bisect-data/tmp with something like
+ rsync -aH osstest.test-lab:/home/osstest/bisects/for-xen-4.5-testing.git/tmp  
bisect-data/.
+
+ * Run
+ ./mg-bisect-activity-create-db
+ ./mg-bisect-activity-collect-emails ) {
+   chomp;
+   last if m/^$/;
+   if (m/^([^:]+)\:\s/) {
+   $h{lc $1} = $'\'';
+   }
+   }
+   while (<>) { }
+   die unless $h{subject};
+   my $date = $h{"x-original-date"} || $h{date};
+   die unless $date;
+   exit 0 unless $h{from} =~ m/$ENV{OSSTEST_BACEF}/o;
+   $_ = $h{subject} ;
+   s/\s+/ /g;
+   if (m/^\[[^][]+ bisection\](?: \d+\:)? (\w+) /) {
+   print "$1";
+   } elsif (m/^\[[^][ ]+ test\] \d+\: /) {
+   print "MAINREPORT";
+   } else {
+   chomp;
+   warn "$_\n";
+   exit 0;
+   }
+   print "\t";
+   flush STDOUT or die $!;
+   system(qw(date -d), $date, "+\%s") and die "$? $!";
+' | perl -we '
+   use strict;
+   use DBI;
+   #use Data::Dumper;
+   my $dbh = DBI->connect("dbi:SQLite:dbname=bisect-timing.db","","",
+  { RaiseError => 1, PrintError => 1 });
+   $dbh->begin_work();
+   my $stmt = $dbh->prepare(
+   "INSERT INTO events (evt,ts,cat) VALUES (?,?,'\''email'\'')"
+   );
+   while (<>) {
+ chomp or die;
+ my @v = split /\t/;
+ #print Dumper($_, \@v);
+ $stmt->execute(@v);
+   }
+   $dbh->commit();
+'
diff --git a/mg-bisect-activity-collect-tmpdir 
b/mg-bisect-activity-collect-tmpdir
new file mode 100755
index 000..1ba92bc
--- /dev/null
+++ b/mg-bisect-activity-collect-tmpdir
@@ -0,0 +1,94 @@
+#!/usr/bin/perl -w
+#
+# usage: ./mg-bisect-activity-collect-tmpdir PATH/TO/tmp
+
+use strict;
+use DBI;
+
+my $dbh = DBI->connect("dbi:SQLite:dbname=bisect-timing.db","","",
+  { RaiseError => 1, PrintError => 1 });
+
+$dbh->begin_work();
+
+my $stmt = $dbh->prepare("INSERT INTO events (ts,cat,evt) VALUES (?,?,?)");
+
+my ($inputdir) = @ARGV;
+
+sub date2ts ($) {
+my ($date) = @_;
+open S, "-|", qw(date -d), $date, qw(+%s) or die $!;
+my $ts = ;
+close S;
+chomp $ts or die "$? $!";
+$ts;
+}
+
+foreach my $f (<$inputdir/*>) {
+$_ = $f; s#.*/##;
+
+my $mtime = sub {
+   my ($evt,$cat) = @_;
+
+   lstat $f or die $!;
+   die unless -f _;
+   my $ts = ((stat _)[9]);
+
+   $stmt->execute($ts, ($cat // 'mtime'), $evt);
+};
+
+my @ec;
+if (m/^t\./) {
+} elsif (m/^\d+\.
+  ( transcript
+  | bisection-summary
+  | bisection-report
+  | email\.sent
+  )$/x) {
+   $mtime->($1);
+} elsif (m/^bisection-start-stamp$/) {
+   $mtime->($&, 'unique');
+} elsif (m/^bisection-start-stamp\.new$/) {
+} elsif (m/^cr-for-branches.log[-.0-9a-z]*$/) {
+   if (m/\.gz$/) {
+   open L, "zcat $f |" or die $!;
+   } else {
+   open L, "<", $f or die $!;
+   }
+   my $flightfirst;
+   while () {
+   if (m/^\[(\d\d\d\d\-\d\d\-\d\d \d\d:\d\d:\d\d UTC) \d+\] /) {
+   my $ts = date2ts($1);
+   if (m/\.\.\.$/) {
+   $stmt->execute($ts, 'crlog', 'begin');
+   } elsif (m/ status=\d+\s*$/) {
+   $stmt->execute($ts, 'crlog', 'end');
+   } else {
+   

[Xen-devel] [OSSTEST PATCH 3/3] mg-bisect-activity-dump-periods: Split out windows-install steps

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 mg-bisect-activity-dump-periods | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mg-bisect-activity-dump-periods b/mg-bisect-activity-dump-periods
index 0c04720..00576a0 100755
--- a/mg-bisect-activity-dump-periods
+++ b/mg-bisect-activity-dump-periods
@@ -178,4 +178,4 @@ email - complete | crlog - end
 flight - step start build host-(?:install|build-prep)
 flight - step start build .*-build
 flight - step start test capture-logs.*
-flight - step start test (?!capture|host-install|hosts-allocate).*
+flight - step start test 
(?!capture|host-install|hosts-allocate|windows-install).*
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 1/3] Add *.tmp to .gitignore

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index bccf488..69f7743 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,6 +1,7 @@
 *~
 *.bak
 tmp
+*.tmp
 bisection.ps
 bisection.dot
 bisection.html
-- 
2.1.4


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

Re: [Xen-devel] [Wg-test-framework] osstest Massachusetts test lab resource usage investigation

[Ian Jackson]

Ian Jackson writes ("Re: [Wg-test-framework] osstest Massachusetts test lab 
resource usage investigation"):
> I have now completed the investigation into db queries.

I've been looking at the bisector too.  I captured a history snapshot
containing two bisections chosen arbitrarily, and wrote some scripts
which I used to analyse the snapshot.


Xen 4.5 build failure around 20th of September.

The bisector completed bisections of both the amd64 and i386 build
failures, in that order.  Here is the top time spent for amd64:

  68.69%  41208 flight - step start build hosts-allocate | flight - step 
finish build
  10.96%   6577 flight - step start build host-install(3) | flight - step 
finish build
  10.53%   6316 flight - step start build .*-build | flight - step finish 
build
   5.42%   3249 flight - step start build host-(?:install|build-prep) | 
flight - step finish build
   0.76%453 email - testing | flight - job start

And for i386:

  49.22%   8976 flight - step start build hosts-allocate | flight - step 
finish build
  19.51%   3557 flight - step start build .*-build | flight - step finish 
build
  13.10%   2389 flight - step start build host-install(3) | flight - step 
finish build
   5.49%   1002 flight - step start build host-(?:install|build-prep) | 
flight - step finish build
   2.24%409 flight - flight ending | mtime - transcript

Overall it spent 50-70% of the elapsed time waiting for a slot on a
build machine, and then 16-20% of the elapsed time reinstalling the
build machine.

I think this could be improved by providing one or more hosts which
were dedicated to building.  They would not need reinstalling so
often, and would often be idle.

Looking at the logs there is a particularly long delay (15ks, 4h12)
before the first repro job completes.  I think this is probably
because each bisection job runs with the start time priority of the
first one, so that the first job is delayed by (roughly) the queue
length.  This is done deliberately to avoid trying to bisect things
which are fixed quickly.  Given the small proportion of our resources
being used for bisections we may want to reconsider that.


Xen 4.5 guest migration failure around 22nd September.
(test-amd64-amd64-xl-qemuu-winxpsp3, step guest-localmigrate/x10.

The bisector ran first for a different failure,
test-amd64-amd64-xl-qemuu-ovmf-amd64 and determined that that one was
unreproducible.

I have analysed data only up to Thu, 22 Sep 2016 07:59:02 GMT (since
that was in my collection snapshot).

Counting the whole period from the failure of the main flight to the
end of the snapshot recording, we have the following elapsed times:

  35.05%  23613 flight - step start build hosts-allocate | flight - step 
finish build
  18.85%  12698 flight - step start test hosts-allocate | flight - step 
finish test
  14.79%   9965 flight - step start test windows-install | flight - step 
finish test

These figures will disproportionately bias the initial startup host
allocation delay (see above), since this is not a finished bisection.

Counting only the period after the ovmf bisection was abandoned,

  37.11%   9965 flight - step start test windows-install | flight - step 
finish test
  10.97%   2946 flight - step start test hosts-allocate | flight - step 
finish test
   8.13%   2183 flight - step start test host-install(3) | flight - step 
finish test
   7.05%   1892 flight - step start test 
(?!capture|host-install|hosts-allocate|windows-install).* | flight - step 
finish test
   6.32%   1697 flight - step start build .*-build | flight - step finish 
build
   6.15%   1650 flight - step start build host-install(3) | flight - step 
finish build
   5.47%   1470 mtime - bisection-report | mtime - transcript
   4.54%   1220 crlog - begin | email - testing
   3.42%918 flight - step start build host-(?:install|build-prep) | 
flight - step finish build
   1.75%470 flight - job finish | flight - step finish build

Looking at the logs each iteration takes about 1 hour.

This bisection involves a much longer iteration for each step, because
the test involves a Windows install.  So the host allocation delay
here is a much smaller proportion, even though the bisector needs to
get exactly the right host.

11% is not that much here, but a faster test would make this look
worse.  I have a half-baked idea to allow an in-progress bisection to
reserve its test host.  I think that this would be worth pursuing,
although there's a fair amount of complication involved.

38% of the wall clock time was spent doing a Windows install.  The
test does a fresh install each time, rather than saving a VM image and
reusing it.

In principle it might be possible to use saved VM images.  We do fresh
installs because installs are a good exercise of a variety of
functionality, and because that avoids having to maintain and
comprehend a library of VMs.  In particular: if we were 

Re: [Xen-devel] [PATCH RFC 01/12] PVHv2 Dom0

[Jan Beulich]

>>> On 29.07.16 at 18:28,  wrote:
> This is a very rough implementation of a PVHv2 Dom0. There are still a bunch 
> 
> of things that will not work properly (like SR-IOV, MSI, MSI-X...), but it 
> *should* be able to boot a Dom0 kernel and it doesn't require using PIRQs.

It's been a long time since you had posted this, but I thought I'd
take a coarse look nevertheless. Basic concept looks okay, but of
course there are many rough edges.

Jan


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

Re: [Xen-devel] Fwd: Openindiana, using -machine pc, accel=xen in qemu

[Anthony PERARD]

On Mon, Sep 26, 2016 at 11:02:44AM -0400, jim burns wrote:
> On Monday, 26 September 2016, 12:32:01 EDT, Anthony PERARD wrote:
> > On Thu, Sep 22, 2016 at 10:37:14AM -0400, jim burns wrote:
> > > Pls cc me with any replies.
> > > 
> > > On Thursday, 22 September 2016, 12:22:02 EDT, Anthony PERARD wrote:
> > > > On Wed, Sep 21, 2016 at 06:20:16PM -0400, jim burns wrote:
> > > > > I didn't get any responses in xen-users, so I'm posting here. My use
> > > > > case
> > > > > is as below, but the jist of it is is the qemu option -machine
> > > > > pc,accel=xen meant to be usable in standalone qemu, or is it only
> > > > > available from a guest launched by xl, or libvirtd via libxl? If the
> > > > > latter, are there any plans to make it available as a standalone qemu
> > > > > option?
> > > > 
> > > > Hi,
> > > > 
> > > > -machine pc,accel=xen is to be used by libxl (used by xl or libvirt).
> > > > libxl takes care of creating a guest and launch QEMU when needed.
> > > 
> > > That was quick. Thank you for your response. So there is no way to hook
> > > libxl from a standalone qemu option?
> > 
> > With xl, you can add arguments to the qemu command line via the option:
> > device_model_args_hvm = [ "-extra-option", 'example' ]
> 
> And you saw me use that, as below. What I was asking is is there an option 
> for 
> standalone qemu that will let it connect to libxl?

No, that is not possible.

> > > ## live cd installer
> > > 
> > > Disk = [ "file:/home/jimb/Documents/rpms/OI-hipster-
> > > gui-20160421.iso,xvdc:cdrom,r", "phy:/dev/dm-2,xvda,w" ]
> > 
> > Would the guest works if you change xvda and xvdc to respectively hda
> > and hdc?
> > 
> > > vga="qxl"
> > > videoram=128
> > > #soundhw='all' #causes hvm domain start failure
> > > soundhw='sb16,es1370,ac97,adlib,gus,cs4231a'
> > 
> > You could specify only one sound card, instead of all, and you could use
> > 'hda' to start with.
> > 
> > > usbdevice='mouse'
> > 
> > Try with a tablet instead of the mouse:
> > usbdevice='tablet'
> > That is usually the virtual device I use for a mouse.
> > You could try also without the usbdevice option, and see if the guest
> > boot.
> 
> Neither '-soundhw hda' or '-usbdevice tablet' work in standalone qemu OI. OI 
> has initialization problems with hda, and I had to use another sound driver. 
> That's why I pass all the drivers except hda to standalone qemu. Also, OI 
> software is quite old (Gnome 2, gcc 4.9, xorg 1.14, etc.) and they don't 
> really have a tablet driver, and passing a tablet to standalone qemu resulted 
> in a non functional mouse.
> 
> None the less, I tried all three changes to my xen cfg, and commenting out 
> the 
> Haswell option, and there was no difference.
> 
> To reiterate from my OP, when 'xen_platform_pci=1', I can boot into grub, 
> edit 
> the kernel line for verbose booting (-v), and the boot msgs list the decoded 
> cpuid flags, then hang on the enumeration of the first pci device. If I pass 
> 'xen_platform_pci=0', I get the same msgs, but then the domain aborts with a 
> null pointer dereference in an OI kernel driver.
> 
> My only concern here is getting hardware acceleration for my OI domain, which 
> right now is only thru kvm/qemu, which is inconvenient to have to boot bare 
> metal, or have a very slow domain under a xen boot. However, I've tried 
> numerous variations in my xen cfg, to no avail. If there is no standalone 
> qemu 
> option to connect it to libxl, are there any plans to include one down the 
> road? (Which was my original question.)


Try this (apix_enable=0):
https://docs.oracle.com/cd/E27300_01/E27307/html/vmrns-bugs.html#vmrns-solaris10hangs
with 'xen_platform_pci=1' in your config. (it did not work for me with
xen_platform_pci=0.)

It worked for me with the "OpenIndiana Build 151a8 Server CD".

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH RFC 09/12] xen/x86: setup PVHv2 Dom0 ACPI tables

[Jan Beulich]

>>> On 29.07.16 at 18:29,  wrote:
> This maps all the regions in the e820 marked as E820_ACPI or E820_NVS to
> Dom0 1:1. It also shadows the page(s) where the native MADT is placed by
> mapping a RAM page over it, copying the original data and modifying it
> afterwards in order to represent the real CPU topology exposed to Dom0.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
> FWIW, I think that the current approach that I've used in order to craft the
> MADT is not the best one, IMHO it would be better to place the MADT at the
> end of the E820_ACPI region (expanding it's size one page), and modify the
> XSDT/RSDT in order to point to it, that way we avoid shadowing any other
> ACPI data that might be at the same page as the native MADT (and that needs
> to be modified by Dom0) .

I think I agree. Problem is that you can't be sure there is any space
left after the E820_ACPI region, so I think the placement aspect
would need relaxation.

Jan

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

Re: [Xen-devel] [PATCH RFC 08/12] xen/x86: setup PVHv2 Dom0 CPUs

[Jan Beulich]

>>> On 29.07.16 at 18:29,  wrote:
> Initialize Dom0 BSP/APs and setup the memory and IO permissions.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
> The logic used to setup the CPUID leaves is extremely simplistic (and
> probably wrong for hardware different than mine). I'm not sure what's the
> best way to deal with this, the code that currently sets the CPUID leaves
> for HVM guests lives in libxc, maybe moving it xen/common would be better?

Why don't you just set them from their respective hardware values?

> +static int __init hvm_setup_cpus(struct domain *d, paddr_t entry,
> + paddr_t start_info)
> +{
> +vcpu_hvm_context_t cpu_ctx;
> +struct vcpu *v = d->vcpu[0];
> +int cpu, i, rc;
> +struct {
> +uint32_t index;
> +uint32_t count;
> +} cpuid_leaves[] = {
> +{0, XEN_CPUID_INPUT_UNUSED},
> +{1, XEN_CPUID_INPUT_UNUSED},
> +{2, XEN_CPUID_INPUT_UNUSED},
> +{4, 0},
> +{4, 1},
> +{4, 2},
> +{4, 3},
> +{4, 4},
> +{7, 0},
> +{0xa, XEN_CPUID_INPUT_UNUSED},
> +{0xd, 0},
> +{0x8000, XEN_CPUID_INPUT_UNUSED},
> +{0x8001, XEN_CPUID_INPUT_UNUSED},
> +{0x8002, XEN_CPUID_INPUT_UNUSED},
> +{0x8003, XEN_CPUID_INPUT_UNUSED},
> +{0x8004, XEN_CPUID_INPUT_UNUSED},
> +{0x8005, XEN_CPUID_INPUT_UNUSED},
> +{0x8006, XEN_CPUID_INPUT_UNUSED},
> +{0x8007, XEN_CPUID_INPUT_UNUSED},
> +{0x8008, XEN_CPUID_INPUT_UNUSED},
> +};
> +
> +printk("** Setting up BSP/APs **\n");
> +
> +cpu = v->processor;
> +for ( i = 1; i < d->max_vcpus; i++ )
> +{
> +cpu = cpumask_cycle(cpu, _cpus);
> +setup_dom0_vcpu(d, i, cpu);
> +}
> +
> +memset(_ctx, 0, sizeof(cpu_ctx));
> +
> +cpu_ctx.mode = VCPU_HVM_MODE_32B;
> +
> +cpu_ctx.cpu_regs.x86_32.ebx = start_info;
> +cpu_ctx.cpu_regs.x86_32.eip = entry;
> +cpu_ctx.cpu_regs.x86_32.cr0 = X86_CR0_PE | X86_CR0_ET;
> +
> +cpu_ctx.cpu_regs.x86_32.cs_limit = ~0u;
> +cpu_ctx.cpu_regs.x86_32.ds_limit = ~0u;
> +cpu_ctx.cpu_regs.x86_32.ss_limit = ~0u;
> +cpu_ctx.cpu_regs.x86_32.tr_limit = 0x67;
> +cpu_ctx.cpu_regs.x86_32.cs_ar = 0xc9b;
> +cpu_ctx.cpu_regs.x86_32.ds_ar = 0xc93;
> +cpu_ctx.cpu_regs.x86_32.ss_ar = 0xc93;
> +cpu_ctx.cpu_regs.x86_32.tr_ar = 0x8b;

Much of this should be power on state of a HVM vCPU anyway, so
it's not immediately clear why all of this is needed.

Jan

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

Re: [Xen-devel] [PATCH RFC 07/12] xen/x86: parse Dom0 kernel for PVHv2

[Jan Beulich]

>>> On 29.07.16 at 18:29,  wrote:
> Introduce a helper to parse the Dom0 kernel.

It would help if you clarified why this needs to be different from
the PV ELF parsing - to me, ELF is ELF, so no duplication should
be necessary from a very high level perspective.

Jan


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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel]

On Mon, Sep 26, 2016 at 12:24 AM, Jan Beulich  wrote:
 On 23.09.16 at 22:45,  wrote:
>> On Fri, Sep 23, 2016 at 9:50 AM, Tamas K Lengyel
>>  wrote:
>>> On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich  wrote:
>>> On 23.09.16 at 17:26,  wrote:
> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich  wrote:
> On 22.09.16 at 19:18,  wrote:
>>> So I verified that when CPU-based load exiting is enabled, the TLB
>>> flush here is critical. Without it the guest kernel crashes at random
>>> points during boot. OTOH why does Xen trap every guest CR3 update
>>> unconditionally? While we have features such as the vm_event/monitor
>>> that may choose to subscribe to that event, Xen traps it even when
>>> that is not in use. Is that trapping necessary for something else?
>>
>> Where do you see this being unconditional? construct_vmcs()
>> clearly avoids setting these intercepts when using EPT. Are you
>> perhaps suffering from
>>
>> /* Trap CR3 updates if CR3 memory events are enabled. */
>> if ( v->domain->arch.monitor.write_ctrlreg_enabled &
>>  monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
>> v->arch.hvm_vmx.exec_control |= 
>> CPU_BASED_CR3_LOAD_EXITING;
>>
>> in vmx_update_guest_cr()? That'll be rather something for you
>> or Razvan to explain. Outside of nested VMX I don't see any
>> other enabling of that intercept (didn't check AMD code on the
>> assumption that you're working on Intel hardware).
>
> So there seems to be two separate paths that lead to the TLB flushing.
> One is indeed the above case you cited when we enable CR3 monitoring
> through the monitor interface. However, during domain boot I also see
> this path being called that is not related to the
> CPU_BASED_CR3_LOAD_EXITING:
>
> (XEN) hap.c:739:d1v0 hap_update_paging_modes is calling hap_update_cr3
> (XEN) hap.c:701:d1v0 HAP update cr3 called
> (XEN) /src/xen/xen/include/asm/hvm/hvm.h:344:d1v0 HVM update guest cr3
>> called
> (XEN) vmx.c:1549:d1v0 Update guest CR3 value=0x7a7c4000
>
> This path seems to de-activate once the domain is fully booted.

 This late? According to the CR0 handling in
 vmx_update_guest_cr() I would understand it to be enabled only
 while the guest is still in real mode (and even then only on old
 hardware, i.e. without the Unrestricted Guest functionality).

>>>
>>> Right, with unrestricted guest support I would assume none of this
>>> would get called - but it does, and quite frequently during domain
>>> boot. The CPU is a Intel(R) Xeon(R) CPU E5-2430.
>>>
>>
>> So I experimented with selectively disabling the flushing such that
>> it's done only when coming from a path other then CPU-based CR3 load
>> exiting. I've added a bool to struct vcpu that gets set to 0 every
>> time vmx_vmexit_handler is called, and only gets set to 1 when
>> vmx_cr_access reports a MOV-TO-CR3. Then in the vmx_update_guest_cr
>> the flush only happens as such:
>>
>> if ( !v->movtocr3 )
>> hvm_asid_flush_vcpu(v);
>>
>> In the guest I run a test application that allocates a page at a fixed
>> VA, writes a magic value to it, and then keeps spinning on reading the
>> magic value back from the page, checking if it's the same as
>> originally supplied. I lunch this application twice with different
>> magic values, so that if the TLB invalidation is an issue one of the
>> test applications would read back the wrong magic value from the VA
>> using a stale TLB entry. I've verified that same VA in the two
>> applications point to different pages and that those PTEs are not
>> marked global and no PCID is used.
>>
>> [  724] test (struct addr:88003730f330). PGD: 0x3731f000
>> VADDR 0x500 -> PADDR 0x73e35000. Global page: 0
>> [  727] test (struct addr:88003681ea20). PGD: 0x777a6000
>> VADDR 0x500 -> PADDR 0x75043000. Global page: 0
>
> I'm surprised. As said before - a mov-to-CR3 cannot be emulated
> without a minimal amount of flushing. No experiments whatsoever
> are suitable to prove the contrary.

That's a pretty strong statement - can you tell me where in the SDM
does it say that exactly? I've went through it couple times already
and I can't find anything that explicitly says that the flushing has
to be performed by the VMM when mov-to-CR3 trapping is enabled. The
closest thing I found was indicating the contrary. Furthermore, if the
flushing is necessary, then how would you explain that there were no
TLB mixups in the above experiment?

>
>> Both applications work as expected without the VPID flushing taking
>> place. So at least for CPU-based CR3 load exiting it seems that this
>> flush is not necessary. As for why this path 

[Xen-devel] [PATCH v2] Added COPYING and README.patch files to xen/common and xen/tools

[Lars Kurth]

This patch adds information related to non-GPL licenses and code
imports from 3rd party projects. The aim of this patch, is to
make it easier for future contributors, to perform a review
of the codebase.

Signed-off-by: Lars Kurth 

Reviewed-by: Konrad Rzeszutek Wilk 
---
Changes since v1
Fixed typos: amd=>and & teh=>the

---
 xen/common/COPYING  | 16 +
 xen/common/README.source| 50 +
 xen/tools/kconfig/README.source |  9 
 3 files changed, 75 insertions(+)
 create mode 100644 xen/common/COPYING
 create mode 100644 xen/common/README.source
 create mode 100644 xen/tools/kconfig/README.source

diff --git a/xen/common/COPYING b/xen/common/COPYING
new file mode 100644
index 000..dbfb26b
--- /dev/null
+++ b/xen/common/COPYING
@@ -0,0 +1,16 @@
+Most files in this directory are covered by version 2 of the
+GNU General Public License except where explicitly stated.
+See the main COPYING file in xen.git for more information.
+
+The following files and directories are notable exceptions
+and cover code which has been imported into the Xen codebase.
+For more information on the origin of these files and their
+licenses, see README.source
+
+bunzip2.c
+unizma.c
+xmalloc_tlsf.c
+libelf/*
+libfdt/*
+lz4/decompress.c
+xz/*
\ No newline at end of file
diff --git a/xen/common/README.source b/xen/common/README.source
new file mode 100644
index 000..f053a81
--- /dev/null
+++ b/xen/common/README.source
@@ -0,0 +1,50 @@
+About
+=
+This file documents the upstream sources for files and directories
+in this part of the Xen source tree. Note that the list may not
+be complete: in particular for code that has been imported from
+the Linux Kernel underr a GPLv2 license.
+
+bunzip2.c
+-
+Originally from https://www.landley.net/code/bunzip-4.1.c
+The file is licensed under LGPLv2 (or later)
+
+unizma.c
+
+This file was originally imported from the Linux tree
+at kernel/git/torvalds/linux.git, path: lib/decompress_unlzma.c
+The file is licensed under LGPLv2.1 (or later)
+
+xmalloc_tlsf.c
+--
+This file was originally imported from the compcache project at
+https://code.google.com/archive/p/compcache/source, path
+compcache/sub-projects/allocators/tlsf-kmod
+The file is dually licensed under GPLv2.0 and LGPLv2.1
+
+libelf
+--
+This directory was opriginally imported from the libelf
+project at http://www.mr511.de/software/english.html
+This directory is licensed under LGPLv2.1 (see COPYING file)
+
+libfdt
+--
+This directory was originally imported from the Device Tree 
+Compiler at https://github.com/dgibson/dtc/tree/master/libfdt 
+This directory is dually licensed as GPLv2.0 or later
+and a BSD 2-clause license
+
+lz4/decompress.c
+-
+This file was originally imported from the LZ4 project
+( http://www.lz4.org). The source is available from 
+https://github.com/Cyan4973/lz4 
+The file is licensed under a BSD 2-clause license
+
+xz 
+--
+This directory was imported from the XZ Utils project
+and is available under http://tukaani.org/xz/  
+The imported code is in the public domain
\ No newline at end of file
diff --git a/xen/tools/kconfig/README.source b/xen/tools/kconfig/README.source
new file mode 100644
index 000..620214c
--- /dev/null
+++ b/xen/tools/kconfig/README.source
@@ -0,0 +1,9 @@
+About
+=
+This file documents the upstream sources for files and directories
+in this part of the Xen source tree. 
+
+xen/tools/kconfig
+-
+The kconfig directory was originally imported from the linux kernel 
+git tree at kernel/git/torvalds/linux.git, path: scripts/kconfig
\ No newline at end of file
-- 
2.5.4 (Apple Git-61)


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

Re: [Xen-devel] [PATCH Altp2m cleanup v5 1/3] altp2m cleanup work.

[Jan Beulich]

>>> On 13.09.16 at 18:46,  wrote:
> Indent goto labels by one space.
> Inline (header) altp2m functions.
> In do_altp2m_op(), during the sanity check of the passed command,
> return -ENONSYS if not a valid command.
> In do_altp2m_op(), when evaluating a command, ASSERT_UNREACHABLE()
> if the command is not recognizable.  The sanity check above should
> have triggered the return of -ENOSYS.
> Make altp2m_vcpu_emulate_ve() return actual bool_t (rather than return
> void()).
> 
> Signed-off-by: Paul Lai 
> ---

It is very disappointing to find that there is still no information here
on what changed from the previous version.

> @@ -5349,6 +5362,8 @@ static int do_altp2m_op(
>  rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
>  _gfn(a.u.change_gfn.old_gfn),
>  _gfn(a.u.change_gfn.new_gfn));
> +default:
> +ASSERT_UNREACHABLE();
>  }

And it is even worse that the bug pointed out here is still present.

>  /* emulates #VE */
> -bool_t altp2m_vcpu_emulate_ve(struct vcpu *v);
> +static inline bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)

Nor did you switch to plain bool here, as was requested during both
v3 and v4 review.

Please do not resubmit this series until you have taken care of
_all_ review comments you've received so far. As with the
previous version I'm not going to spend time looking at the other
two patches due to this fundamental requirement, despite
having been pointed out before, not being met.

Jan


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

Re: [Xen-devel] [PATCH v4] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Paul Durrant]

> -Original Message-
> From: Tamas K Lengyel [mailto:tamas.leng...@zentific.com]
> Sent: 22 September 2016 19:54
> To: xen-de...@lists.xenproject.org
> Cc: Tamas K Lengyel ; Paul Durrant
> ; Jan Beulich ; Andrew
> Cooper ; Jun Nakajima
> ; Kevin Tian ; George
> Dunlap ; Stefano Stabellini
> ; Julien Grall 
> Subject: [PATCH v4] x86/vm_event: Allow overwriting Xen's i-cache used for
> emulation
> 
> When emulating instructions Xen's emulator maintains a small i-cache
> fetched from the guest memory. This patch extends the vm_event interface
> to allow overwriting this i-cache via a buffer returned in the vm_event
> response.
> 
> When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor
> subscriber normally has to remove the INT3 from memory - singlestep - place
> back INT3 to allow the guest to continue execution. This routine however is
> susceptible to a race-condition on multi-vCPU guests. By allowing the
> subscriber to return the i-cache to be used for emulation it can side-step the
> problem by returning a clean buffer without the INT3 present.
> 
> As part of this patch we rename hvm_mem_access_emulate_one to
> hvm_emulate_one_vm_event to better reflect that it is used in various
> vm_event scenarios now, not just in response to mem_access events.
> 
> Signed-off-by: Tamas K Lengyel 
> Acked-by: Razvan Cojocaru 
> ---
> Cc: Paul Durrant 

I/O emulation code:
Reviewed-by: Paul Durrant 

> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> Cc: George Dunlap 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> 
> v4: Copy insn buffer into mmio buffer to avoid more login in
> hvm_emulate_one
> Add comment in hvm_do_resume to preserve order as described in
> vm_event.h
> ---
>  xen/arch/x86/hvm/emulate.c| 27 +--
>  xen/arch/x86/hvm/hvm.c| 13 ++---
>  xen/arch/x86/vm_event.c   | 11 ++-
>  xen/include/asm-x86/hvm/emulate.h |  5 +++--
>  xen/include/asm-x86/vm_event.h|  5 -
>  xen/include/public/vm_event.h | 17 -
>  6 files changed, 64 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index cc25676..17f7f0d 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -76,9 +76,9 @@ static int set_context_data(void *buffer, unsigned int
> size)
>  if ( curr->arch.vm_event )
>  {
>  unsigned int safe_size =
> -min(size, curr->arch.vm_event->emul_read_data.size);
> +min(size, curr->arch.vm_event->emul.read.size);
> 
> -memcpy(buffer, curr->arch.vm_event->emul_read_data.data,
> safe_size);
> +memcpy(buffer, curr->arch.vm_event->emul.read.data, safe_size);
>  memset(buffer + safe_size, 0, size - safe_size);
>  return X86EMUL_OKAY;
>  }
> @@ -1931,7 +1931,7 @@ int hvm_emulate_one_mmio(unsigned long mfn,
> unsigned long gla)
>  return rc;
>  }
> 
> -void hvm_mem_access_emulate_one(enum emul_kind kind, unsigned int
> trapnr,
> +void hvm_emulate_one_vm_event(enum emul_kind kind, unsigned int
> trapnr,
>  unsigned int errcode)
>  {
>  struct hvm_emulate_ctxt ctx = {{ 0 }}; @@ -1944,10 +1944,25 @@ void
> hvm_mem_access_emulate_one(enum emul_kind kind, unsigned int trapnr,
>  case EMUL_KIND_NOWRITE:
>  rc = hvm_emulate_one_no_write();
>  break;
> -case EMUL_KIND_SET_CONTEXT:
> -ctx.set_context = 1;
> -/* Intentional fall-through. */
> +case EMUL_KIND_SET_CONTEXT_INSN: {
> +struct vcpu *curr = current;
> +struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
> +
> +BUILD_BUG_ON(sizeof(vio->mmio_insn) !=
> + sizeof(curr->arch.vm_event->emul.insn.data));
> +ASSERT(!vio->mmio_insn_bytes);
> +
> +/*
> + * Stash insn buffer into mmio buffer here instead of ctx
> + * to avoid having to add more logic to hvm_emulate_one.
> + */
> +vio->mmio_insn_bytes = sizeof(vio->mmio_insn);
> +memcpy(vio->mmio_insn, curr->arch.vm_event->emul.insn.data,
> +   vio->mmio_insn_bytes);
> +}
> +/* Fall-through */
>  default:
> +ctx.set_context = (kind == EMUL_KIND_SET_CONTEXT_DATA);
>  rc = hvm_emulate_one();
>  }
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index
> 7bad845..b06e4d5 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -487,15 

Re: [Xen-devel] [PATCH] Added COPYING and README.patch files to xen/common and xen/tools

[Lars Kurth]

On 26/09/2016 16:49, "Konrad Rzeszutek Wilk" 
wrote:

>On Mon, Sep 26, 2016 at 04:23:27PM +0100, Lars Kurth wrote:
>> This patch adds information related to non-GPL licenses and code
>> imports from 3rd party projects. The aim of this patch, is to
>> make it easier for future contributors, to perform a review
>> of the codebase.
>
>I see a lot 'amd' instead of 'and'. And one 'teh' instead of 'the'.
>
>Is that intentional? If so that should be mentioned in the commmit
>description.

Not intentional: apologies. Will fix and re-send.
Lars

>
>Otherwise,
>
>Reviewed-by: Konrad Rzeszutek Wilk 


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

Re: [Xen-devel] [PATCH v7 14/14] x86: add multiboot2 protocol support for relocatable images

[Jan Beulich]

>>> On 23.09.16 at 23:47,  wrote:
> @@ -383,10 +390,19 @@ __start:
>  cmp %edi,MB2_fixed_total_size(%ebx)
>  jbe trampoline_bios_setup
>  
> +/* Get Xen image load base address from Multiboot2 information. */
> +cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
> +jne 1f
> +
> +mov MB2_load_base_addr(%ecx),%esi
> +sub $XEN_IMG_OFFSET,%esi
> +jmp 9f
> +
> +1:
>  /* Get mem_lower from Multiboot2 information. */
>  cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
>  cmove   MB2_mem_lower(%ecx),%edx
> -je  trampoline_bios_setup
> +je  9f
>  
>  /* EFI IA-32 platforms are not supported. */
>  cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx)

Considering that you look for another tag type here, doesn't the
branch target change above point out an issue in an earlier patch?

Jan


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

Re: [Xen-devel] [PATCH] Added COPYING and README.patch files to xen/common and xen/tools

[Konrad Rzeszutek Wilk]

On Mon, Sep 26, 2016 at 04:23:27PM +0100, Lars Kurth wrote:
> This patch adds information related to non-GPL licenses and code
> imports from 3rd party projects. The aim of this patch, is to
> make it easier for future contributors, to perform a review
> of the codebase.

I see a lot 'amd' instead of 'and'. And one 'teh' instead of 'the'.

Is that intentional? If so that should be mentioned in the commmit description.

Otherwise,

Reviewed-by: Konrad Rzeszutek Wilk 
> 
> Signed-off-by: Lars Kurth 
> ---
>  xen/common/COPYING  | 16 +
>  xen/common/README.source| 50 
> +
>  xen/tools/kconfig/README.source |  9 
>  3 files changed, 75 insertions(+)
>  create mode 100644 xen/common/COPYING
>  create mode 100644 xen/common/README.source
>  create mode 100644 xen/tools/kconfig/README.source
> 
> diff --git a/xen/common/COPYING b/xen/common/COPYING
> new file mode 100644
> index 000..dbfb26b
> --- /dev/null
> +++ b/xen/common/COPYING
> @@ -0,0 +1,16 @@
> +Most files in this directory are covered by version 2 of the
> +GNU General Public License except where explicitly stated.
> +See the main COPYING file in xen.git for more information.
> +
> +The following files and directories are notable exceptions
> +and cover code which has been imported into the Xen codebase.
> +For more information on the origin of these files and their
> +licenses, see README.source
> +
> +bunzip2.c
> +unizma.c
> +xmalloc_tlsf.c
> +libelf/*
> +libfdt/*
> +lz4/decompress.c
> +xz/*
> \ No newline at end of file
> diff --git a/xen/common/README.source b/xen/common/README.source
> new file mode 100644
> index 000..b821122
> --- /dev/null
> +++ b/xen/common/README.source
> @@ -0,0 +1,50 @@
> +About
> +=
> +This file documents the upstream sources for files amd directories
> +in this part of the Xen source tree. Note that the list may not
> +be complete: in particular for code that has been imported from
> +the Linux Kernel underr a GPLv2 license.
> +
> +bunzip2.c
> +-
> +Originally from https://www.landley.net/code/bunzip-4.1.c
> +The file is licensed under LGPLv2 (or later)
> +
> +unizma.c
> +
> +This file was originally imported from the Linux tree
> +at kernel/git/torvalds/linux.git, path: lib/decompress_unlzma.c
> +The file is licensed under LGPLv2.1 (or later)
> +
> +xmalloc_tlsf.c
> +--
> +This file was originally imported from teh compcache project at
> +https://code.google.com/archive/p/compcache/source, path
> +compcache/sub-projects/allocators/tlsf-kmod
> +The file is dually licensed under GPLv2.0 and LGPLv2.1
> +
> +libelf
> +--
> +This directory was opriginally imported from the libelf
> +project at http://www.mr511.de/software/english.html
> +This directory is licensed under LGPLv2.1 (see COPYING file)
> +
> +libfdt
> +--
> +This directory was originally imported from the Device Tree 
> +Compiler at https://github.com/dgibson/dtc/tree/master/libfdt 
> +This directory is dually licensed as GPLv2.0 or later
> +and a BSD 2-clause license
> +
> +lz4/decompress.c
> +-
> +This file was originally imported from the LZ4 project
> +( http://www.lz4.org). The source is available from 
> +https://github.com/Cyan4973/lz4 
> +The file is licensed under a BSD 2-clause license
> +
> +xz 
> +--
> +This directory was imported from the XZ Utils project
> +and is available under http://tukaani.org/xz/  
> +The imported code is in the public domain
> \ No newline at end of file
> diff --git a/xen/tools/kconfig/README.source b/xen/tools/kconfig/README.source
> new file mode 100644
> index 000..71880fe
> --- /dev/null
> +++ b/xen/tools/kconfig/README.source
> @@ -0,0 +1,9 @@
> +About
> +=
> +This file documents the upstream sources for files amd directories
> +in this part of the Xen source tree. 
> +
> +xen/tools/kconfig
> +-
> +The kconfig directory was originally imported from the linux kernel 
> +git tree at kernel/git/torvalds/linux.git, path: scripts/kconfig
> \ No newline at end of file
> -- 
> 2.5.4 (Apple Git-61)
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v7 13/14] x86/boot: rename sym_phys() to sym_offs()

[Jan Beulich]

>>> On 23.09.16 at 23:47,  wrote:
> This way macro name better describes its function.

I'd appreciate if you could mention the change in function, so that
it ends up being quite obvious why the name change is desirable.

With that:
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v4] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Razvan Cojocaru]

On 09/26/2016 05:55 PM, Tamas K Lengyel wrote:
> On Sep 26, 2016 08:29, "Razvan Cojocaru"  > wrote:
>>
>> On 09/26/2016 01:33 PM, Jan Beulich wrote:
>>  On 22.09.16 at 20:54,  > wrote:
>> >> When emulating instructions Xen's emulator maintains a small
> i-cache fetched
>> >> from the guest memory. This patch extends the vm_event interface to
> allow
>> >> overwriting this i-cache via a buffer returned in the vm_event
> response.
>> >>
>> >> When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor
> subscriber
>> >> normally has to remove the INT3 from memory - singlestep - place
> back INT3
>> >> to allow the guest to continue execution. This routine however is
>> >> susceptible
>> >> to a race-condition on multi-vCPU guests. By allowing the
> subscriber to return
>> >> the i-cache to be used for emulation it can side-step the problem
> by returning
>> >> a clean buffer without the INT3 present.
>> >>
>> >> As part of this patch we rename hvm_mem_access_emulate_one to
>> >> hvm_emulate_one_vm_event to better reflect that it is used in various
>> >> vm_event
>> >> scenarios now, not just in response to mem_access events.
>> >>
>> >> Signed-off-by: Tamas K Lengyel  >
>> >> Acked-by: Razvan Cojocaru  >
>> >
>> > Non-VM-event specific code:
>> > Reviewed-by: Jan Beulich >
>> >
>> > One question though:
>> >
>> >> --- a/xen/arch/x86/vm_event.c
>> >> +++ b/xen/arch/x86/vm_event.c
>> >> @@ -209,11 +209,20 @@ void vm_event_emulate_check(struct vcpu *v,
> vm_event_response_t *rsp)
>> >>  if ( p2m_mem_access_emulate_check(v, rsp) )
>> >>  {
>> >>  if ( rsp->flags & VM_EVENT_FLAG_SET_EMUL_READ_DATA )
>> >> -v->arch.vm_event->emul_read_data =
> rsp->data.emul_read_data;
>> >> +v->arch.vm_event->emul.read = rsp->data.emul.read;
>> >>
>> >>  v->arch.vm_event->emulate_flags = rsp->flags;
>> >>  }
>> >>  break;
>> >> +
>> >> +case VM_EVENT_REASON_SOFTWARE_BREAKPOINT:
>> >> +if ( rsp->flags & VM_EVENT_FLAG_SET_EMUL_INSN_DATA )
>> >> +{
>> >> +v->arch.vm_event->emul.insn = rsp->data.emul.insn;
>> >> +v->arch.vm_event->emulate_flags = rsp->flags;
>> >> +}
>> >> +break;
>> >
>> > Is this intentionally different from the case above (where the setting
>> > of ->emulate_flags is outside the inner if()?
> 
> Yes, it's intentional.
> 
>> Good point. The case below should follow suit of the one above unless
>> there's a corner case Tamas is aware of that I'm missing. Otherwise, a
>> comment would be nice to explain the difference (perhaps for
>> VM_EVENT_REASON_SOFTWARE_BREAKPOINT only
>> VM_EVENT_FLAG_SET_EMUL_INSN_DATA ever makes sense - never a simple
>> emulation).
>>
> 
> That's exactly the case here as the commit text explains. Emulating in
> response to an int3 event only makes sense if you return the insn
> buffer. I can add a comment to that effect if that helps, though I think
> it's pretty straight forward.

It might help dispel future confusion, but the commit text should
suffice for now - I won't hold the patch hostage because of this.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH] x86emul: correct loading of %ss

[Andrew Cooper]

On 26/09/16 16:25, Jan Beulich wrote:
 On 26.09.16 at 15:40,  wrote:
>> On 21/09/16 10:05, Jan Beulich wrote:
>>> - Instead of #NP, #SS needs to be raised for non-present descriptors.
>>> - Loading a null selector is fine in 64-bit mode at CPL != 3, as long
>>>   as RPL == CPL.
>>> - Don't lose the low two selector bits on null selector loads (also
>>>   applies to %ds, %es, %fs, and %gs).
>>>
>>> Since we need CPL earlier now, also switch to using get_cpl() (instead
>>> of open coding it).
>>>
>>> Signed-off-by: Jan Beulich 
>> Reviewed-by: Andrew Cooper , although...
>>
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -1194,18 +1194,25 @@ protmode_load_seg(
>>>  struct x86_emulate_ctxt *ctxt,
>>>  const struct x86_emulate_ops *ops)
>>>  {
>>> -struct segment_register desctab, ss;
>>> +struct segment_register desctab;
>>>  struct { uint32_t a, b; } desc;
>>> -uint8_t dpl, rpl, cpl;
>>> +uint8_t dpl, rpl;
>>> +int cpl = get_cpl(ctxt, ops);
>>>  uint32_t new_desc_b, a_flag = 0x100;
>>>  int rc, fault_type = EXC_GP;
>>>  
>>> +if ( cpl < 0 )
>>> +return X86EMUL_UNHANDLEABLE;
>>> +
>>>  /* NULL selector? */
>>>  if ( (sel & 0xfffc) == 0 )
>>>  {
>>> -if ( (seg == x86_seg_cs) || (seg == x86_seg_ss) )
>>> +if ( (seg == x86_seg_cs) ||
>>> + ((seg == x86_seg_ss) &&
>>> +  (!mode_64bit() || (cpl == 3) || (cpl != sel))) )
> I've just noticed that this depends on
>
> @@ -607,7 +609,7 @@ do{ asm volatile (
>  })
>  #define truncate_ea(ea) truncate_word((ea), ad_bytes)
>  
> -#define mode_64bit() (def_ad_bytes == 8)
> +#define mode_64bit() (ctxt->addr_size == 64)
>  
>  #define fail_if(p)  \
>  do {\
>
> from the large decode rework series. I'll assume you're okay with me
> folding this in.

Yeah - that looks fine.

~Andrew

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

Re: [Xen-devel] [PATCH] x86emul: correct loading of %ss

[Jan Beulich]

>>> On 26.09.16 at 15:40,  wrote:
> On 21/09/16 10:05, Jan Beulich wrote:
>> - Instead of #NP, #SS needs to be raised for non-present descriptors.
>> - Loading a null selector is fine in 64-bit mode at CPL != 3, as long
>>   as RPL == CPL.
>> - Don't lose the low two selector bits on null selector loads (also
>>   applies to %ds, %es, %fs, and %gs).
>>
>> Since we need CPL earlier now, also switch to using get_cpl() (instead
>> of open coding it).
>>
>> Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Andrew Cooper , although...
> 
>>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -1194,18 +1194,25 @@ protmode_load_seg(
>>  struct x86_emulate_ctxt *ctxt,
>>  const struct x86_emulate_ops *ops)
>>  {
>> -struct segment_register desctab, ss;
>> +struct segment_register desctab;
>>  struct { uint32_t a, b; } desc;
>> -uint8_t dpl, rpl, cpl;
>> +uint8_t dpl, rpl;
>> +int cpl = get_cpl(ctxt, ops);
>>  uint32_t new_desc_b, a_flag = 0x100;
>>  int rc, fault_type = EXC_GP;
>>  
>> +if ( cpl < 0 )
>> +return X86EMUL_UNHANDLEABLE;
>> +
>>  /* NULL selector? */
>>  if ( (sel & 0xfffc) == 0 )
>>  {
>> -if ( (seg == x86_seg_cs) || (seg == x86_seg_ss) )
>> +if ( (seg == x86_seg_cs) ||
>> + ((seg == x86_seg_ss) &&
>> +  (!mode_64bit() || (cpl == 3) || (cpl != sel))) )

I've just noticed that this depends on

@@ -607,7 +609,7 @@ do{ asm volatile (
 })
 #define truncate_ea(ea) truncate_word((ea), ad_bytes)
 
-#define mode_64bit() (def_ad_bytes == 8)
+#define mode_64bit() (ctxt->addr_size == 64)
 
 #define fail_if(p)  \
 do {\

from the large decode rework series. I'll assume you're okay with me
folding this in.

Jan


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

[Xen-devel] [PATCH] Added COPYING and README.patch files to xen/common and xen/tools

[Lars Kurth]

This patch adds information related to non-GPL licenses and code
imports from 3rd party projects. The aim of this patch, is to
make it easier for future contributors, to perform a review
of the codebase.

Signed-off-by: Lars Kurth 
---
 xen/common/COPYING  | 16 +
 xen/common/README.source| 50 +
 xen/tools/kconfig/README.source |  9 
 3 files changed, 75 insertions(+)
 create mode 100644 xen/common/COPYING
 create mode 100644 xen/common/README.source
 create mode 100644 xen/tools/kconfig/README.source

diff --git a/xen/common/COPYING b/xen/common/COPYING
new file mode 100644
index 000..dbfb26b
--- /dev/null
+++ b/xen/common/COPYING
@@ -0,0 +1,16 @@
+Most files in this directory are covered by version 2 of the
+GNU General Public License except where explicitly stated.
+See the main COPYING file in xen.git for more information.
+
+The following files and directories are notable exceptions
+and cover code which has been imported into the Xen codebase.
+For more information on the origin of these files and their
+licenses, see README.source
+
+bunzip2.c
+unizma.c
+xmalloc_tlsf.c
+libelf/*
+libfdt/*
+lz4/decompress.c
+xz/*
\ No newline at end of file
diff --git a/xen/common/README.source b/xen/common/README.source
new file mode 100644
index 000..b821122
--- /dev/null
+++ b/xen/common/README.source
@@ -0,0 +1,50 @@
+About
+=
+This file documents the upstream sources for files amd directories
+in this part of the Xen source tree. Note that the list may not
+be complete: in particular for code that has been imported from
+the Linux Kernel underr a GPLv2 license.
+
+bunzip2.c
+-
+Originally from https://www.landley.net/code/bunzip-4.1.c
+The file is licensed under LGPLv2 (or later)
+
+unizma.c
+
+This file was originally imported from the Linux tree
+at kernel/git/torvalds/linux.git, path: lib/decompress_unlzma.c
+The file is licensed under LGPLv2.1 (or later)
+
+xmalloc_tlsf.c
+--
+This file was originally imported from teh compcache project at
+https://code.google.com/archive/p/compcache/source, path
+compcache/sub-projects/allocators/tlsf-kmod
+The file is dually licensed under GPLv2.0 and LGPLv2.1
+
+libelf
+--
+This directory was opriginally imported from the libelf
+project at http://www.mr511.de/software/english.html
+This directory is licensed under LGPLv2.1 (see COPYING file)
+
+libfdt
+--
+This directory was originally imported from the Device Tree 
+Compiler at https://github.com/dgibson/dtc/tree/master/libfdt 
+This directory is dually licensed as GPLv2.0 or later
+and a BSD 2-clause license
+
+lz4/decompress.c
+-
+This file was originally imported from the LZ4 project
+( http://www.lz4.org). The source is available from 
+https://github.com/Cyan4973/lz4 
+The file is licensed under a BSD 2-clause license
+
+xz 
+--
+This directory was imported from the XZ Utils project
+and is available under http://tukaani.org/xz/  
+The imported code is in the public domain
\ No newline at end of file
diff --git a/xen/tools/kconfig/README.source b/xen/tools/kconfig/README.source
new file mode 100644
index 000..71880fe
--- /dev/null
+++ b/xen/tools/kconfig/README.source
@@ -0,0 +1,9 @@
+About
+=
+This file documents the upstream sources for files amd directories
+in this part of the Xen source tree. 
+
+xen/tools/kconfig
+-
+The kconfig directory was originally imported from the linux kernel 
+git tree at kernel/git/torvalds/linux.git, path: scripts/kconfig
\ No newline at end of file
-- 
2.5.4 (Apple Git-61)


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

Re: [Xen-devel] [PATCH] x86/svm: Drop the set_segment_register() macro

[Boris Ostrovsky]

On 09/26/2016 10:45 AM, Andrew Cooper wrote:
> Replace its sole users with a single piece of inline assembly which is more
> flexable about its register constraints, rather than forcing the use of %ax.
>
> While editing this area, reflow the comment to remove trailing whitespace and
> use fewer lines.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 

Reviewed-by: Boris Ostrovsky 



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

Re: [Xen-devel] [PATCH] x86/svm: Drop the set_segment_register() macro

[Jan Beulich]

>>> On 26.09.16 at 16:45,  wrote:
> Replace its sole users with a single piece of inline assembly which is more
> flexable about its register constraints, rather than forcing the use of %ax.
> 
> While editing this area, reflow the comment to remove trailing whitespace and
> use fewer lines.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v7 08/14] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 26.09.16 at 16:40,  wrote:
> On 26/09/16 15:33, Jan Beulich wrote:
> On 26.09.16 at 16:19,  wrote:
>>> On 23/09/16 22:47, Daniel Kiper wrote:
 +/*
 + * Initialize BSS (no nasty surprises!).
 + * It must be done earlier than in BIOS case
 + * because efi_multiboot2() touches it.
 + */
 +lea .startof.(.bss)(%rip),%edi
 +mov $.sizeof.(.bss),%ecx
>>> Sorry, but you cannot use this syntax, for the same reasons why I won't
>>> accept Jan's patch making similar changes elsewhere.
>>>
>>> Amongst other issues, you will break the Clang build with it.
>> Did you verify meanwhile that this doesn't work with llvm?
> 
> Yes.
> 
> andrewcoop@andrewcoop:/local/xen.git/xen$ cat foo.c
> #include 
> 
> static unsigned int x;
> 
> int main(void)
> {
> asm volatile("lea .startof.(.bss)(%%rip), %%rdi;"
>  "mov $.sizeof.(.bss), %%rcx;"
>  "mov $-1, %%rax;"
>  "rep stosb;"
>  ::: "memory", "rax", "rcx", "rdi");
> printf("x: %#x\n", x);
> }
> andrewcoop@andrewcoop:/local/xen.git/xen$ gcc foo.c -o foo && ./foo
> x: 0x
> andrewcoop@andrewcoop:/local/xen.git/xen$ clang-3.8 foo.c -o foo && ./foo
> foo.c:7:18: error: unexpected token in memory operand
> asm volatile("lea .startof.(.bss)(%%rip), %%rdi;"
>  ^
> :1:16: note: instantiated into assembly here
> lea .startof.(.bss)(%rip), %rdi;mov $.sizeof.(.bss), %rcx;mov
> $-1, %rax;rep stosb;
>   ^
> foo.c:7:18: error: unexpected token in argument list
> asm volatile("lea .startof.(.bss)(%%rip), %%rdi;"
>  ^
> :1:47: note: instantiated into assembly here
> lea .startof.(.bss)(%rip), %rdi;mov $.sizeof.(.bss), %rcx;mov
> $-1, %rax;rep stosb;
>  ^
> 2 errors generated.

No, that's inline assembly, which does not match Daniel's use
case. That's why I referred to llvm, as with assembly sources it
should only be the linker which gets to see the symbols generated
from those constructs (and if llvm supported them I'd then consider
breaking out the assembly file changes from that patch of mine).

Jan


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

Re: [Xen-devel] [PATCH v7 12/14] x86: make Xen early boot code relocatable

[Jan Beulich]

>>> On 23.09.16 at 23:47,  wrote:
> @@ -426,32 +453,65 @@ trampoline_bios_setup:
>  xor %cl, %cl
>  
>  trampoline_setup:
> +/*
> + * Called on legacy BIOS and EFI platforms.
> + *
> + * Initialize 0-15 bits of BOOT_FS segment descriptor base address.
> + */
> +mov %si,BOOT_FS+2+sym_esi(trampoline_gdt)
> +
> +/* Initialize 16-23 bits of BOOT_FS segment descriptor base address. 
> */
> +mov %esi,%edx
> +shr $16,%edx

I'd have liked it even better if you had done this with a single
instruction, but anyway.

> @@ -474,23 +534,53 @@ trampoline_setup:
>  
>  /* Stash TSC to calculate a good approximation of time-since-boot */
>  rdtsc
> -mov %eax,sym_phys(boot_tsc_stamp)
> -mov %edx,sym_phys(boot_tsc_stamp+4)
> +mov %eax,sym_fs(boot_tsc_stamp)
> +mov %edx,sym_fs(boot_tsc_stamp)+4
> +
> +/*
> + * Update frame addresses in page tables excluding l2_identmap
> + * without its first entry which points to l1_identmap.
> + */
> +mov $((__page_tables_end-__page_tables_start)/8),%ecx
> +mov $(((l2_identmap-__page_tables_start)/8)+2),%edx

The +2 instead of +1 here is confusing. Why don't you do the natural
thing here and ...

> +1:  cmp 
> $((l2_identmap+l2_identmap_sizeof-__page_tables_start)/8),%ecx
> +cmove   %edx,%ecx
> +je  2f

... simply drop this branch?

> +testl   $_PAGE_PRESENT,sym_fs(__page_tables_start)-8(,%ecx,8)
> +jz  2f
> +add %esi,sym_fs(__page_tables_start)-8(,%ecx,8)
> +2:  loop1b
> +
> +/* Initialize L2 boot-map/direct map page table entries (14MB). */
> +lea sym_esi(start),%ebx
> +lea 
> (1< +shr $(L2_PAGETABLE_SHIFT-3),%ebx
> +mov $8,%ecx

The comment saying 14Mb kind of contradicts this being 8 here.

> +1:  mov %eax,sym_fs(l2_bootmap)-8(%ebx,%ecx,8)
> +mov %eax,sym_fs(l2_identmap)-8(%ebx,%ecx,8)
> +sub $(1< +loop1b
> +
> +/* Initialize L3 boot-map page directory entry. */
> +lea 
> __PAGE_HYPERVISOR+(L2_PAGETABLE_ENTRIES*8)*3+sym_esi(l2_bootmap),%eax
> +mov $4,%ecx
> +1:  mov %eax,sym_fs(l3_bootmap)-8(,%ecx,8)
> +sub $(L2_PAGETABLE_ENTRIES*8),%eax
> +loop1b
>  
>  /*
>   * During boot, hook 4kB mappings of first 2MB of memory into L2.
> - * This avoids mixing cachability for the legacy VGA region, and is
> - * corrected when Xen relocates itself.
> + * This avoids mixing cachability for the legacy VGA region.
>   */
> -mov $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
> -mov %edi,sym_phys(l2_xenmap)
> +lea __PAGE_HYPERVISOR+sym_esi(l1_identmap),%edi
> +mov %edi,sym_fs(l2_bootmap)

Switching from l2_xenmap to l2_bootmap here?

> @@ -121,8 +127,9 @@ GLOBAL(l2_identmap)
>   * page.
>   */
>  GLOBAL(l2_xenmap)
> -idx = 0
> -.rept 8
> +.quad 0
> +idx = 1
> +.rept 7
>  .quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) + 
> (PAGE_HYPERVISOR | _PAGE_PSE)
>  idx = idx + 1
>  .endr

How come the first entry doesn't need filling anymore? I think such
less obvious changes should really get briefly mentioned/explained
in the commit message.

> @@ -674,6 +671,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  printk("Command line: %s\n", cmdline);
>  
> +printk("Xen image load base address: 0x%08lx\n", xen_phys_start);

Please prefer %#lx in cases like this.

> @@ -1018,6 +1018,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  : "memory" );
>  
>  bootstrap_map(NULL);
> +
> +printk("New Xen image base address: %#08lx\n", xen_phys_start);

# and a minimum width generally don't fit together well.

Jan

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

Re: [Xen-devel] Fwd: Openindiana, using -machine pc, accel=xen in qemu

[jim burns]

On Monday, 26 September 2016, 12:32:01 EDT, Anthony PERARD wrote:
> On Thu, Sep 22, 2016 at 10:37:14AM -0400, jim burns wrote:
> > Pls cc me with any replies.
> > 
> > On Thursday, 22 September 2016, 12:22:02 EDT, Anthony PERARD wrote:
> > > On Wed, Sep 21, 2016 at 06:20:16PM -0400, jim burns wrote:
> > > > I didn't get any responses in xen-users, so I'm posting here. My use
> > > > case
> > > > is as below, but the jist of it is is the qemu option -machine
> > > > pc,accel=xen meant to be usable in standalone qemu, or is it only
> > > > available from a guest launched by xl, or libvirtd via libxl? If the
> > > > latter, are there any plans to make it available as a standalone qemu
> > > > option?
> > > 
> > > Hi,
> > > 
> > > -machine pc,accel=xen is to be used by libxl (used by xl or libvirt).
> > > libxl takes care of creating a guest and launch QEMU when needed.
> > 
> > That was quick. Thank you for your response. So there is no way to hook
> > libxl from a standalone qemu option?
> 
> With xl, you can add arguments to the qemu command line via the option:
> device_model_args_hvm = [ "-extra-option", 'example' ]

And you saw me use that, as below. What I was asking is is there an option for 
standalone qemu that will let it connect to libxl?

> > > What is your xen config file for OI ?
> > 
> > name = "osol134"
> > uuid = "f80856df-3180-acc5-931d-32190cfe4062"
> > memory=2048
> > vcpus=4
> > localtime=1
> > on_poweroff = "destroy"
> > on_reboot = "destroy"
> > on_crash = "preserve"
> > #
> > boot="dc"
> > builder="hvm"
> > xen_platform_pci=0  # forces -machine pc,accel=xen
> > device_model_args=[ '-cpu','Haswell-noTSX' ]
> 
> This -cpu would not work, QEMU have no control over the cpu when running
> with Xen.

Well, that may be, but if you do a process list, and grep for the qemu process 
that xl just created, the -cpu option shows up. Also, when I can get a verbose 
boot log from an xl initiated OpenIndiana (OI), the cpuid options listed 
correspond to the cpuid options listed when I run OI with standalone qemu with 
'-cpu Haswell-noTSX', including sse4.n, avx*, and x2apic. Of course, my system 
IS an Haswell Icore-5, so xen may just be passing the host cpu along.

> > ## live cd installer
> > 
> > Disk = [ "file:/home/jimb/Documents/rpms/OI-hipster-
> > gui-20160421.iso,xvdc:cdrom,r", "phy:/dev/dm-2,xvda,w" ]
> 
> Would the guest works if you change xvda and xvdc to respectively hda
> and hdc?
> 
> > vga="qxl"
> > videoram=128
> > #soundhw='all' #causes hvm domain start failure
> > soundhw='sb16,es1370,ac97,adlib,gus,cs4231a'
> 
> You could specify only one sound card, instead of all, and you could use
> 'hda' to start with.
> 
> > usbdevice='mouse'
> 
> Try with a tablet instead of the mouse:
> usbdevice='tablet'
> That is usually the virtual device I use for a mouse.
> You could try also without the usbdevice option, and see if the guest
> boot.

Neither '-soundhw hda' or '-usbdevice tablet' work in standalone qemu OI. OI 
has initialization problems with hda, and I had to use another sound driver. 
That's why I pass all the drivers except hda to standalone qemu. Also, OI 
software is quite old (Gnome 2, gcc 4.9, xorg 1.14, etc.) and they don't 
really have a tablet driver, and passing a tablet to standalone qemu resulted 
in a non functional mouse.

None the less, I tried all three changes to my xen cfg, and commenting out the 
Haswell option, and there was no difference.

To reiterate from my OP, when 'xen_platform_pci=1', I can boot into grub, edit 
the kernel line for verbose booting (-v), and the boot msgs list the decoded 
cpuid flags, then hang on the enumeration of the first pci device. If I pass 
'xen_platform_pci=0', I get the same msgs, but then the domain aborts with a 
null pointer dereference in an OI kernel driver.

My only concern here is getting hardware acceleration for my OI domain, which 
right now is only thru kvm/qemu, which is inconvenient to have to boot bare 
metal, or have a very slow domain under a xen boot. However, I've tried 
numerous variations in my xen cfg, to no avail. If there is no standalone qemu 
option to connect it to libxl, are there any plans to include one down the 
road? (Which was my original question.)

P.S. - I have read with interest your xen-devel posts this month on OVMF (as a 
user, not a developer). I had to re-compile xen with '-enable-ovmf', since 
Fedora (at least) does not deliver it that way, and that was not straight 
forward. That code path needs a little love since -Werror is used a lot. There 
were a couple of source files that gcc choked on for improper indentation, and 
a ton of files in the compile of edk2 that choked on a variable that was set 
but not used, except in an 'assert' statement. I had to add '-Wno-unused-but-
set-variable' to BaseTools/Conf/tools_def.template. Then, in the compile of 
gmp, the configure script couldn't calculate sizeof(unsigned short), 
sizeof(unsigned), etc., and I had to force reasonable values.

I'll 

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/26/2016 10:45 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v6] acpi: Prevent GPL-only code from 
> seeping into non-GPL binaries"):
>> There are two interdependent variables that I need to print. The C
>> equivalent is
>>
>> for ( i = 0; i < 4; i++ )
>> printf("%d %c\n", i, 'A'+i);
>>
>> The character value is derived from 'i', which in this example is an
>> index into 'links' array.
>>
>> I suggested in response to Jan
>>
>> link=`echo "A B C D" | cut -d" " -f $i`
> If the indices are necessarily successive integers:
>
>   links="A B C D"
>   index=0
>   for link in $links; do
> index=$(( $index + 1 ))
> something with $link and $index
>
> If the indices are arbitrary:
>
>   links="1:A 4:B 7:C 10:D"
>   for linkinfo in $links; do
> link=${linkinfo#*:}
> index=${linkinfo%%:*}
> something with $link and $index


The indices are not successive, in one case they are a function of two
enclosing loop indices, such as
for dev in $(seq 1 31)
do
for intx in $(seq 0 3)
do
link_idx=$(((dev + intx) & 3))
printf "Package(){0x%04x, %u, _SB.PCI0.LNK%c,
0},\n" \
$dev $intx ${links:$link_idx:1}
done
done

(And then there might also be a question of portability with the second
approach?)

So if you don't object to

link=`echo "A B C D" | cut -d" " -f $i`

I'd rather go with that.

(I'll add '#!/bin/sh' as you requested in another email)

-boris


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 065ae7d717f9e49c3be12dada109d60dead0bb90
baseline version:
 ovmf 587e9dfbbafe7d4e772c1870b8c880c6d7a8a70c

Last test of basis   101139  2016-09-25 00:47:51 Z1 days
Testing same since   101151  2016-09-26 13:14:58 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=065ae7d717f9e49c3be12dada109d60dead0bb90
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
065ae7d717f9e49c3be12dada109d60dead0bb90
+ branch=ovmf
+ revision=065ae7d717f9e49c3be12dada109d60dead0bb90
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x065ae7d717f9e49c3be12dada109d60dead0bb90 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v4] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Tamas K Lengyel]

On Sep 26, 2016 08:29, "Razvan Cojocaru"  wrote:
>
> On 09/26/2016 01:33 PM, Jan Beulich wrote:
>  On 22.09.16 at 20:54,  wrote:
> >> When emulating instructions Xen's emulator maintains a small i-cache
fetched
> >> from the guest memory. This patch extends the vm_event interface to
allow
> >> overwriting this i-cache via a buffer returned in the vm_event
response.
> >>
> >> When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor
subscriber
> >> normally has to remove the INT3 from memory - singlestep - place back
INT3
> >> to allow the guest to continue execution. This routine however is
> >> susceptible
> >> to a race-condition on multi-vCPU guests. By allowing the subscriber
to return
> >> the i-cache to be used for emulation it can side-step the problem by
returning
> >> a clean buffer without the INT3 present.
> >>
> >> As part of this patch we rename hvm_mem_access_emulate_one to
> >> hvm_emulate_one_vm_event to better reflect that it is used in various
> >> vm_event
> >> scenarios now, not just in response to mem_access events.
> >>
> >> Signed-off-by: Tamas K Lengyel 
> >> Acked-by: Razvan Cojocaru 
> >
> > Non-VM-event specific code:
> > Reviewed-by: Jan Beulich 
> >
> > One question though:
> >
> >> --- a/xen/arch/x86/vm_event.c
> >> +++ b/xen/arch/x86/vm_event.c
> >> @@ -209,11 +209,20 @@ void vm_event_emulate_check(struct vcpu *v,
vm_event_response_t *rsp)
> >>  if ( p2m_mem_access_emulate_check(v, rsp) )
> >>  {
> >>  if ( rsp->flags & VM_EVENT_FLAG_SET_EMUL_READ_DATA )
> >> -v->arch.vm_event->emul_read_data =
rsp->data.emul_read_data;
> >> +v->arch.vm_event->emul.read = rsp->data.emul.read;
> >>
> >>  v->arch.vm_event->emulate_flags = rsp->flags;
> >>  }
> >>  break;
> >> +
> >> +case VM_EVENT_REASON_SOFTWARE_BREAKPOINT:
> >> +if ( rsp->flags & VM_EVENT_FLAG_SET_EMUL_INSN_DATA )
> >> +{
> >> +v->arch.vm_event->emul.insn = rsp->data.emul.insn;
> >> +v->arch.vm_event->emulate_flags = rsp->flags;
> >> +}
> >> +break;
> >
> > Is this intentionally different from the case above (where the setting
> > of ->emulate_flags is outside the inner if()?

Yes, it's intentional.

> Good point. The case below should follow suit of the one above unless
> there's a corner case Tamas is aware of that I'm missing. Otherwise, a
> comment would be nice to explain the difference (perhaps for
> VM_EVENT_REASON_SOFTWARE_BREAKPOINT only
> VM_EVENT_FLAG_SET_EMUL_INSN_DATA ever makes sense - never a simple
> emulation).
>

That's exactly the case here as the commit text explains. Emulating in
response to an int3 event only makes sense if you return the insn buffer. I
can add a comment to that effect if that helps, though I think it's pretty
straight forward.

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

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Ian Jackson]

Boris Ostrovsky writes ("Re: [PATCH v6] acpi: Prevent GPL-only code from 
seeping into non-GPL binaries"):
> On 09/26/2016 06:04 AM, Wei Liu wrote:
> > On Fri, Sep 23, 2016 at 03:14:20PM -0400, Boris Ostrovsky wrote:
> >> diff --git a/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh 
> >> b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
> >> new file mode 100755
> >> index 000..28a0dd7
> >> --- /dev/null
> >> +++ b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
> >> @@ -0,0 +1,116 @@
> > #!/bin/sh ?
> 
> (Just noticed this comment)
> 
> I don't think this is needed since it's invoked by the Makefile as
> 
> $(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)

The script should be runnable from the command line without saying
"sh" or soemthing.  So it should have a #! line and be executable.

Ian.

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

Re: [Xen-devel] Outreachy Winter Internship

[George Dunlap]

On Wed, Sep 14, 2016 at 5:28 PM, George Dunlap  wrote:
> On 11/09/16 11:52, Kavya Sharma wrote:
>> Hello Sir,I am Kavya Sharma, an aspiring Outreachy intern.It would be my
>> privilege to be an intern with xenproject.org this winter.I have read
>> about Xen Hypervisor Userspace Tools and I am interested in your project
>> 'golang bindings for libxl'.
>>
>> Sir,can you please guide me on this and also give some suggestions so
>> that I can work on the bite-sized projects so that I can fulfil the
>> requirements.
>
> Kavya,

Hey Kavya,

Just wondering how you're getting on with this, and if you need any help.

If you haven't started, or have decided not to take the project on, no
problem; I just wanted to make sure you weren't stuck.

Thanks,
 -George

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

[Xen-devel] [PATCH] x86/svm: Drop the set_segment_register() macro

[Andrew Cooper]

Replace its sole users with a single piece of inline assembly which is more
flexable about its register constraints, rather than forcing the use of %ax.

While editing this area, reflow the comment to remove trailing whitespace and
use fewer lines.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/svm.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 679e615..0ed3e73 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -69,9 +69,6 @@ u32 svm_feature_flags;
 /* Indicates whether guests may use EFER.LMSLE. */
 bool_t cpu_has_lmsl;
 
-#define set_segment_register(name, value)  \
-asm volatile ( "movw %%ax ,%%" STR(name) "" : : "a" (value) )
-
 static void svm_update_guest_efer(struct vcpu *);
 
 static struct hvm_function_table svm_function_table;
@@ -1023,15 +1020,12 @@ static void svm_ctxt_switch_to(struct vcpu *v)
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
 int cpu = smp_processor_id();
 
-/* 
- * This is required, because VMRUN does consistency check
- * and some of the DOM0 selectors are pointing to 
- * invalid GDT locations, and cause AMD processors
- * to shutdown.
+/*
+ * This is required, because VMRUN does consistency check and some of the
+ * DOM0 selectors are pointing to invalid GDT locations, and cause AMD
+ * processors to shutdown.
  */
-set_segment_register(ds, 0);
-set_segment_register(es, 0);
-set_segment_register(ss, 0);
+asm volatile ("mov %0, %%ds; mov %0, %%es; mov %0, %%ss;" :: "r" (0));
 
 /*
  * Cannot use ISTs for NMI/#MC/#DF while we are running with the guest TR.
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Ian Jackson]

Boris Ostrovsky writes ("Re: [PATCH v6] acpi: Prevent GPL-only code from 
seeping into non-GPL binaries"):
> There are two interdependent variables that I need to print. The C
> equivalent is
> 
> for ( i = 0; i < 4; i++ )
> printf("%d %c\n", i, 'A'+i);
> 
> The character value is derived from 'i', which in this example is an
> index into 'links' array.
> 
> I suggested in response to Jan
> 
> link=`echo "A B C D" | cut -d" " -f $i`

If the indices are necessarily successive integers:

  links="A B C D"
  index=0
  for link in $links; do
index=$(( $index + 1 ))
something with $link and $index

If the indices are arbitrary:

  links="1:A 4:B 7:C 10:D"
  for linkinfo in $links; do
link=${linkinfo#*:}
index=${linkinfo%%:*}
something with $link and $index

Ian.

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

Re: [Xen-devel] [PATCH v7 08/14] x86: add multiboot2 protocol support for EFI platforms

[Andrew Cooper]

On 26/09/16 15:33, Jan Beulich wrote:
 On 26.09.16 at 16:19,  wrote:
>> On 23/09/16 22:47, Daniel Kiper wrote:
>>> +/*
>>> + * Initialize BSS (no nasty surprises!).
>>> + * It must be done earlier than in BIOS case
>>> + * because efi_multiboot2() touches it.
>>> + */
>>> +lea .startof.(.bss)(%rip),%edi
>>> +mov $.sizeof.(.bss),%ecx
>> Sorry, but you cannot use this syntax, for the same reasons why I won't
>> accept Jan's patch making similar changes elsewhere.
>>
>> Amongst other issues, you will break the Clang build with it.
> Did you verify meanwhile that this doesn't work with llvm?

Yes.

andrewcoop@andrewcoop:/local/xen.git/xen$ cat foo.c
#include 

static unsigned int x;

int main(void)
{
asm volatile("lea .startof.(.bss)(%%rip), %%rdi;"
 "mov $.sizeof.(.bss), %%rcx;"
 "mov $-1, %%rax;"
 "rep stosb;"
 ::: "memory", "rax", "rcx", "rdi");
printf("x: %#x\n", x);
}
andrewcoop@andrewcoop:/local/xen.git/xen$ gcc foo.c -o foo && ./foo
x: 0x
andrewcoop@andrewcoop:/local/xen.git/xen$ clang-3.8 foo.c -o foo && ./foo
foo.c:7:18: error: unexpected token in memory operand
asm volatile("lea .startof.(.bss)(%%rip), %%rdi;"
 ^
:1:16: note: instantiated into assembly here
lea .startof.(.bss)(%rip), %rdi;mov $.sizeof.(.bss), %rcx;mov
$-1, %rax;rep stosb;
  ^
foo.c:7:18: error: unexpected token in argument list
asm volatile("lea .startof.(.bss)(%%rip), %%rdi;"
 ^
:1:47: note: instantiated into assembly here
lea .startof.(.bss)(%rip), %rdi;mov $.sizeof.(.bss), %rcx;mov
$-1, %rax;rep stosb;
 ^
2 errors generated.

~Andrew

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

Re: [Xen-devel] [PATCH v7 08/14] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 26.09.16 at 16:19,  wrote:
> On 23/09/16 22:47, Daniel Kiper wrote:
>> +/*
>> + * Initialize BSS (no nasty surprises!).
>> + * It must be done earlier than in BIOS case
>> + * because efi_multiboot2() touches it.
>> + */
>> +lea .startof.(.bss)(%rip),%edi
>> +mov $.sizeof.(.bss),%ecx
> 
> Sorry, but you cannot use this syntax, for the same reasons why I won't
> accept Jan's patch making similar changes elsewhere.
> 
> Amongst other issues, you will break the Clang build with it.

Did you verify meanwhile that this doesn't work with llvm?

Jan


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

Re: [Xen-devel] [PATCH v4] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Razvan Cojocaru]

On 09/26/2016 01:33 PM, Jan Beulich wrote:
 On 22.09.16 at 20:54,  wrote:
>> When emulating instructions Xen's emulator maintains a small i-cache fetched
>> from the guest memory. This patch extends the vm_event interface to allow
>> overwriting this i-cache via a buffer returned in the vm_event response.
>>
>> When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor subscriber
>> normally has to remove the INT3 from memory - singlestep - place back INT3
>> to allow the guest to continue execution. This routine however is 
>> susceptible
>> to a race-condition on multi-vCPU guests. By allowing the subscriber to 
>> return
>> the i-cache to be used for emulation it can side-step the problem by 
>> returning
>> a clean buffer without the INT3 present.
>>
>> As part of this patch we rename hvm_mem_access_emulate_one to
>> hvm_emulate_one_vm_event to better reflect that it is used in various 
>> vm_event
>> scenarios now, not just in response to mem_access events.
>>
>> Signed-off-by: Tamas K Lengyel 
>> Acked-by: Razvan Cojocaru 
> 
> Non-VM-event specific code:
> Reviewed-by: Jan Beulich 
> 
> One question though:
> 
>> --- a/xen/arch/x86/vm_event.c
>> +++ b/xen/arch/x86/vm_event.c
>> @@ -209,11 +209,20 @@ void vm_event_emulate_check(struct vcpu *v, 
>> vm_event_response_t *rsp)
>>  if ( p2m_mem_access_emulate_check(v, rsp) )
>>  {
>>  if ( rsp->flags & VM_EVENT_FLAG_SET_EMUL_READ_DATA )
>> -v->arch.vm_event->emul_read_data = rsp->data.emul_read_data;
>> +v->arch.vm_event->emul.read = rsp->data.emul.read;
>>  
>>  v->arch.vm_event->emulate_flags = rsp->flags;
>>  }
>>  break;
>> +
>> +case VM_EVENT_REASON_SOFTWARE_BREAKPOINT:
>> +if ( rsp->flags & VM_EVENT_FLAG_SET_EMUL_INSN_DATA )
>> +{
>> +v->arch.vm_event->emul.insn = rsp->data.emul.insn;
>> +v->arch.vm_event->emulate_flags = rsp->flags;
>> +}
>> +break;
> 
> Is this intentionally different from the case above (where the setting
> of ->emulate_flags is outside the inner if()?

Good point. The case below should follow suit of the one above unless
there's a corner case Tamas is aware of that I'm missing. Otherwise, a
comment would be nice to explain the difference (perhaps for
VM_EVENT_REASON_SOFTWARE_BREAKPOINT only
VM_EVENT_FLAG_SET_EMUL_INSN_DATA ever makes sense - never a simple
emulation).


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v7 08/14] x86: add multiboot2 protocol support for EFI platforms

[Andrew Cooper]

On 23/09/16 22:47, Daniel Kiper wrote:
> +/*
> + * Initialize BSS (no nasty surprises!).
> + * It must be done earlier than in BIOS case
> + * because efi_multiboot2() touches it.
> + */
> +lea .startof.(.bss)(%rip),%edi
> +mov $.sizeof.(.bss),%ecx

Sorry, but you cannot use this syntax, for the same reasons why I won't
accept Jan's patch making similar changes elsewhere.

Amongst other issues, you will break the Clang build with it.

~Andrew

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

Re: [Xen-devel] [PATCH] block: xen-blkback: don't get/put blkif ref for each queue

[Konrad Rzeszutek Wilk]

On Mon, Sep 26, 2016 at 03:36:24PM +0800, Bob Liu wrote:
> xen_blkif_get/put() for each queue is useless, and introduces a bug:
> 
> If there is I/O inflight when removing device, xen_blkif_disconnect() will
> return -EBUSY and xen_blkif_put() not be called.
> Which means the references are leaked, then even if I/O completed, the
> xen_blkif_put() won't call xen_blkif_deferred_free() to free resources 
> anymore.
> 
> Signed-off-by: Bob Liu 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/block/xen-blkback/xenbus.c |2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/xenbus.c 
> b/drivers/block/xen-blkback/xenbus.c
> index 3cc6d1d..2e1bb6d 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -159,7 +159,6 @@ static int xen_blkif_alloc_rings(struct xen_blkif *blkif)
>   init_waitqueue_head(>shutdown_wq);
>   ring->blkif = blkif;
>   ring->st_print = jiffies;
> - xen_blkif_get(blkif);
>   }
>  
>   return 0;
> @@ -296,7 +295,6 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
>   BUG_ON(ring->free_pages_num != 0);
>   BUG_ON(ring->persistent_gnt_c != 0);
>   WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));
> - xen_blkif_put(blkif);
>   }
>   blkif->nr_ring_pages = 0;
>   /*
> -- 
> 1.7.10.4
> 

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

Re: [Xen-devel] [PATCH] x86/HVM: correct segment register loading during task switch

[Andrew Cooper]

On 23/09/16 11:09, Jan Beulich wrote:
> Instead of #NP, #SS needs to be raised for a non-present %ss
> descriptor.
>
> Don't lose the low two selector bits on null selector loads.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Wei Liu]

On Mon, Sep 26, 2016 at 10:01:37AM -0400, Boris Ostrovsky wrote:
> On 09/26/2016 06:04 AM, Wei Liu wrote:
> > On Fri, Sep 23, 2016 at 03:14:20PM -0400, Boris Ostrovsky wrote:
> >> diff --git a/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh 
> >> b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
> >> new file mode 100755
> >> index 000..28a0dd7
> >> --- /dev/null
> >> +++ b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
> >> @@ -0,0 +1,116 @@
> > #!/bin/sh ?
> 
> (Just noticed this comment)
> 
> I don't think this is needed since it's invoked by the Makefile as
> 
> $(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
> 

Fair enough.

I don't think this is large enough an issue to block this patch. Please
resend this patch and provide a branch on top of staging.

Wei.

> 
> -boris
> 
> 

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

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/26/2016 06:04 AM, Wei Liu wrote:
> On Fri, Sep 23, 2016 at 03:14:20PM -0400, Boris Ostrovsky wrote:
>> diff --git a/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh 
>> b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
>> new file mode 100755
>> index 000..28a0dd7
>> --- /dev/null
>> +++ b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
>> @@ -0,0 +1,116 @@
> #!/bin/sh ?

(Just noticed this comment)

I don't think this is needed since it's invoked by the Makefile as

$(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)


-boris



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

Re: [Xen-devel] [PATCH] x86emul: correct loading of %ss

[Jan Beulich]

>>> On 26.09.16 at 15:40,  wrote:
> On 21/09/16 10:05, Jan Beulich wrote:
>> @@ -1248,7 +1254,6 @@ protmode_load_seg(
>>  
>>  dpl = (desc.b >> 13) & 3;
>>  rpl = sel & 3;
> 
> ... it occurs to me that the calculation of rpl can be moved up to its
> declaration, which allows you to check (cpl == 3) || (cpl != rpl) rather
> than sel, which is more clearly correct IMO.

I think I prefer to leave this alone for the moment.

Jan


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

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Jan Beulich]

>>> On 26.09.16 at 15:43,  wrote:
> On 09/26/2016 09:08 AM, Jan Beulich wrote:
> On 26.09.16 at 14:49,  wrote:
>>> On 09/26/2016 02:46 AM, Jan Beulich wrote:
>>> On 23.09.16 at 21:14,  wrote:
> Changes in v6:
> * Replaced script's printf in most case with "here document" (for 
> multi-line
>   text) or echo for single line. Left printf for formatted output.
>   (Note that in one case paramter expansion is necessary and so
>delimiter word is intentionally not quoted).
> * Replaced bash arrays with ${string:index:size} syntax.
 Without having looked at the patch in full yet - is this any more
 portable than the previous approach? I can't see any mention of
 it in SUSv6 / SUSv7 either.
>>> I can't say for sure but I remember seeing this construct long time ago.
>>>
>>> Of course, this being bash, there are at least 3 ways of doing the same
>>> thing so I can also do
>>>
>>> link=`echo "A B C D" | cut  -d" " -f $i`
>>>
>>> Will SUSv6 understand this?
>> Yes, it looks like it will. But you could have checked yourself.
> 
> 
> Yes, I could. But somehow I thought you were referring to a SUSE product
> instead of the UNIX spec.
> 
> Anyway, I will hold off re-sending the patch with this fixed until you
> review the one I sent.

Oh, I've looked over it already, and it looks reasonable once the
comments already given by others have got addressed.

Jan


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

Re: [Xen-devel] [PATCH] x86emul: don't allow null selector for LTR

[Andrew Cooper]

On 22/09/16 07:38, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v7 09/14] x86/boot: implement early command line parser in C

[Jan Beulich]

>>> On 23.09.16 at 23:47,  wrote:
> Current early command line parser implementation in assembler
> is very difficult to change to relocatable stuff using segment
> registers. This requires a lot of changes in very weird and
> fragile code. So, reimplement this functionality in C. This
> way code will be relocatable out of the box (without playing
> with segment registers) and much easier to maintain.
> 
> Additionally, put all common cmdline.c and reloc.c definitions
> into defs.h header. This way we do not duplicate needlessly
> some stuff.
> 
> And finally remove unused xen/include/asm-x86/config.h
> header from reloc.c dependencies.
> 
> Suggested-by: Andrew Cooper 
> Signed-off-by: Daniel Kiper 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v7 08/14] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 23.09.16 at 23:47,  wrote:
> This way Xen can be loaded on EFI platforms using GRUB2 and
> other boot loaders which support multiboot2 protocol.
> 
> Signed-off-by: Daniel Kiper 
> Acked-by: Jan Beulich 
> ---
> v7 - suggestions/fixes:
>- do not allocate twice memory for trampoline if we were
>  loaded via multiboot2 protocol on EFI platform,

If you fix bugs not noticed by a reviewer but by yourself, please
drop all acks/R-b-s covering the code in question. And then I'm
afraid I haven't even been able to locate that change - could you
please point out what you did where?

> +/*
> + * Initialize BSS (no nasty surprises!).
> + * It must be done earlier than in BIOS case
> + * because efi_multiboot2() touches it.
> + */
> +lea .startof.(.bss)(%rip),%edi
> +mov $.sizeof.(.bss),%ecx
> +shr $3,%ecx
> +xor %eax,%eax
> +rep stosq
> +
> +pop %rdi
> +
> +/*
> + * efi_multiboot2() is called according to System V AMD64 ABI:
> + *   - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> + *   - OUT: %rax - highest usable memory address below 1 MiB;
> + * memory above this address is reserved for 
> trampoline;
> + * memory below this address is used for stack and as
> + * a storage for boot data.

How can you validly use memory below this address? (And I'd like to
note that this also changed from v6, and the change to comments
listed in the v7 section and supposedly suggested by me can't cover
this, as I don't recall having asked for such an adjustment.)

Jan


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

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/26/2016 09:08 AM, Jan Beulich wrote:
 On 26.09.16 at 14:49,  wrote:
>> On 09/26/2016 02:46 AM, Jan Beulich wrote:
>> On 23.09.16 at 21:14,  wrote:
 Changes in v6:
 * Replaced script's printf in most case with "here document" (for 
 multi-line
   text) or echo for single line. Left printf for formatted output.
   (Note that in one case paramter expansion is necessary and so
delimiter word is intentionally not quoted).
 * Replaced bash arrays with ${string:index:size} syntax.
>>> Without having looked at the patch in full yet - is this any more
>>> portable than the previous approach? I can't see any mention of
>>> it in SUSv6 / SUSv7 either.
>> I can't say for sure but I remember seeing this construct long time ago.
>>
>> Of course, this being bash, there are at least 3 ways of doing the same
>> thing so I can also do
>>
>> link=`echo "A B C D" | cut  -d" " -f $i`
>>
>> Will SUSv6 understand this?
> Yes, it looks like it will. But you could have checked yourself.


Yes, I could. But somehow I thought you were referring to a SUSE product
instead of the UNIX spec.

Anyway, I will hold off re-sending the patch with this fixed until you
review the one I sent.

-boris


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

Re: [Xen-devel] [PATCH] x86emul: correct loading of %ss

[Andrew Cooper]

On 21/09/16 10:05, Jan Beulich wrote:
> - Instead of #NP, #SS needs to be raised for non-present descriptors.
> - Loading a null selector is fine in 64-bit mode at CPL != 3, as long
>   as RPL == CPL.
> - Don't lose the low two selector bits on null selector loads (also
>   applies to %ds, %es, %fs, and %gs).
>
> Since we need CPL earlier now, also switch to using get_cpl() (instead
> of open coding it).
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper , although...

>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1194,18 +1194,25 @@ protmode_load_seg(
>  struct x86_emulate_ctxt *ctxt,
>  const struct x86_emulate_ops *ops)
>  {
> -struct segment_register desctab, ss;
> +struct segment_register desctab;
>  struct { uint32_t a, b; } desc;
> -uint8_t dpl, rpl, cpl;
> +uint8_t dpl, rpl;
> +int cpl = get_cpl(ctxt, ops);
>  uint32_t new_desc_b, a_flag = 0x100;
>  int rc, fault_type = EXC_GP;
>  
> +if ( cpl < 0 )
> +return X86EMUL_UNHANDLEABLE;
> +
>  /* NULL selector? */
>  if ( (sel & 0xfffc) == 0 )
>  {
> -if ( (seg == x86_seg_cs) || (seg == x86_seg_ss) )
> +if ( (seg == x86_seg_cs) ||
> + ((seg == x86_seg_ss) &&
> +  (!mode_64bit() || (cpl == 3) || (cpl != sel))) )
>  goto raise_exn;
>  memset(sreg, 0, sizeof(*sreg));
> +sreg->sel = sel;
>  return X86EMUL_OKAY;
>  }
>  
> @@ -1213,8 +1220,7 @@ protmode_load_seg(
>  if ( !is_x86_user_segment(seg) && (sel & 4) )
>  goto raise_exn;
>  
> -if ( (rc = ops->read_segment(x86_seg_ss, , ctxt)) ||
> - (rc = ops->read_segment((sel & 4) ? x86_seg_ldtr : x86_seg_gdtr,
> +if ( (rc = ops->read_segment((sel & 4) ? x86_seg_ldtr : x86_seg_gdtr,
>   , ctxt)) )
>  return rc;
>  
> @@ -1229,7 +1235,7 @@ protmode_load_seg(
>  /* Segment present in memory? */
>  if ( !(desc.b & (1u<<15)) )
>  {
> -fault_type = EXC_NP;
> +fault_type = seg != x86_seg_ss ? EXC_NP : EXC_SS;
>  goto raise_exn;
>  }
>  
> @@ -1248,7 +1254,6 @@ protmode_load_seg(
>  
>  dpl = (desc.b >> 13) & 3;
>  rpl = sel & 3;

... it occurs to me that the calculation of rpl can be moved up to its
declaration, which allows you to check (cpl == 3) || (cpl != rpl) rather
than sel, which is more clearly correct IMO.

~Andrew

> -cpl = ss.attr.fields.dpl;
>  
>  switch ( seg )
>  {
>
>
>


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

Re: [Xen-devel] [PATCH RFC v7 07/14] efi: create new early memory allocator

[Jan Beulich]

>>> On 23.09.16 at 23:47,  wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -79,6 +79,10 @@ static size_t wstrlen(const CHAR16 * s);
>  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
>  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
>  
> +#ifndef CONFIG_ARM
> +static void *ebmalloc(size_t size);
> +#endif

Leaving aside the ARM aspect (to be clarified by Julien), is there a
reason you need to forward declare this here, rather than moving
the whole addition from further down up immediately ahead of the
inclusion point of efi-boot.h?

Jan


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

Re: [Xen-devel] [PATCH v2 0/2] Clarify License information : stubdom, tools/blktap2

[Wei Liu]

On Mon, Sep 26, 2016 at 01:16:32PM +0100, Lars Kurth wrote:
> This series contains some of the easier license clean-up cases, which can be 
> fixed
> by adding COPYING files or README.source files. The series specially contains:
> 
> stubdom
> Added a COPYING file as a boilerplate to explain license oddities in this 
> directory
> Added a vtpm/COPYING file which contains MIT licensed files only
> Added a vtpmmgr/README.source file which contains many BSD-3-Clause files 
> only,
> that originally came from tools/vtpm_manager
> 
> tools/blktap2
> Added a COPYING file 
> There is some complexity here, but I believe it is not necessary to fix this 
> at this
> stage, as for some time we were discussing to remove blktap2.
> 

I will commit this series on Friday if I hear no objection by then.

Wei.

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

Re: [Xen-devel] [PATCH v7 03/14] x86: add multiboot2 protocol support

[Jan Beulich]

>>> On 23.09.16 at 23:47,  wrote:
> +static multiboot_info_t *mbi2_reloc(u32 mbi_in)
> +{
> +const multiboot2_fixed_t *mbi_fix = _p(mbi_in);
> +const multiboot2_memory_map_t *mmap_src;
> +const multiboot2_tag_t *tag;
> +module_t *mbi_out_mods = NULL;
> +memory_map_t *mmap_dst;
> +multiboot_info_t *mbi_out;
> +u32 ptr;
> +unsigned int i, mod_idx = 0;
> +
> +ptr = alloc_mem(sizeof(*mbi_out));
> +mbi_out = _p(ptr);
> +zero_mem(ptr, sizeof(*mbi_out));
> +
> +/* Skip Multiboot2 information fixed part. */
> +ptr = ALIGN_UP(mbi_in + sizeof(multiboot2_fixed_t), 
> MULTIBOOT2_TAG_ALIGN);

There are still instances (like this one) of sizeof() using type names when
they would better use the type of the variable/expression they actually
refer to (here: *mbi_fix).

With _all_ of them adjusted,
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] Outreachy Round 13 .Reg

[George Dunlap]

On 26/09/16 13:59, Harini V Reddy wrote:
> Hi,
> 
> I am Harini, an undergraduate pursuing Bachelors Of Engineering
> in Information Science having some prior experience with coding
> in C and Golang.
> 
> I am interested in applying for Outreachy Round 13 in golang bindings
> for libxl project.
> 
> Can I know the first contributions to be made for the same?
> 
> I would really appreciate it if you could give some insights in this regard

Harini,

Thanks for your interest in the Xen Project!

First, I want to emphasize that Outreachy internships should be
considered a full-time job.  As part of the application process you
will be asked to confirm that you will not be taking any classes, nor
have any other significant commitments (such as another job) during
the period of the internship.

Now on to the bite-sized task.  We've actually found that one of the
difficult parts of getting going with our project is making sure that
you understand how to get your whole system and environment set up.
And another thing we want to see is to what degree you can balance
figuring things out, finding the answers on the web, and asking for
help when you need it.

So with that in mind, we've started experimenting with tasks which
don't contribute very much to the project directly, but provide a
really solid base of knowledge to do further contributions.

So here's my challenge for you.

---
OUTCOME

Attached is the very beginnings of a set of golang bindings that I
wrote for a project of my own.  They contain an implementation of
Context.Open() and Context.ListCpupool(), along with a structure
called Bitmap.  Bitmap is used to store an array of bits in eight-bit
chunks.  So bits 0-7 are bits 0-7 of Bitmap.bitmap[0]; bits 8-15 are
bits 0-7 of Bitmap.bitmap[1], and so on.

On this structure, there are three "stub" methods defined -- Test(),
Set(), and Clear().  (These have labeled with comments which contain
"TODO".) Please implement these methods, so that the main() function
at the bottom of the file runs properly.

You can refer to the C versions of these functions in
xen.git/tools/libxl/libxl_utils.c.  The function names are
libxl_bitmap_test(), libxl_bitmap_set(), and libxl_bitmap_reset().
("reset" in this case is the same as "Clear" in the methods I've
defined.)

Please post a copy of your .go program with these functions implemented,
along with the results of output, to xen-devel.

STEPS

1. Set up a system running Linux

If you don't have one, Ubuntu, Fedora, or Debian should all be fine.

2. Download, build, and install the latest development
version of Xen.  The following page should be useful:

https://wiki.xenproject.org/wiki/Compiling_Xen_From_Source

I would recommend using "make debball" or "make rpmball" over the
"make install".

3. You'll need to build an image for at least one guest VM.

There are tons of options here, but one really simple thing would be
to follow this HOWTO from a previous OPW intern:

https://umasharma17.wordpress.com/2015/02/13/creating-guests-using-xl-in-xen/

4. Implement the stub methods for Bitmap.

The go program will need to Open() the context, then call DomainInfo()
on the target domain ID, and output the required info based on "xl
list".

libxl.go uses cgo to compile a library against C.  If you have the
libraries set up properly, the current version should just work.

--

That's it!  Remember that the goal of this is to see how well you
balance figuring things out on your own vs asking questions.  So try
to figure things out on your own, but when you run into a bit of
difficultly, don't hesitate to ask questions or clarification --
particularly at the beginning.

You can ask questions either here on xen-devel or on the #xendevel or
#xen-opw channels on freenode IRC.

Good luck, and look forward to hearing from you!

 -George

/*
 * Copyright (C) 2016 George W. Dunlap, Citrix Systems UK Ltd
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; version 2 of the
 * License only.
 *
 * 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, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
 * 02110-1301, USA.
 */
package main

/*
#cgo LDFLAGS: -lxenlight -lyajl
#include 
#include 
*/
import "C"

import (
	"unsafe"
	"fmt"
	"time"
)

type Context struct {
	ctx *C.libxl_ctx
}

var Ctx Context

func (Ctx *Context) IsOpen() bool {
	return Ctx.ctx != nil
}

func (Ctx *Context) Open() (err error) {
	if Ctx.ctx != nil {
		return
	}
	
	ret := C.libxl_ctx_alloc(unsafe.Pointer(), C.LIBXL_VERSION, 0, nil)

	if ret != 0 {
		err = 

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Jan Beulich]

>>> On 26.09.16 at 14:49,  wrote:
> On 09/26/2016 02:46 AM, Jan Beulich wrote:
> On 23.09.16 at 21:14,  wrote:
>>> Changes in v6:
>>> * Replaced script's printf in most case with "here document" (for multi-line
>>>   text) or echo for single line. Left printf for formatted output.
>>>   (Note that in one case paramter expansion is necessary and so
>>>delimiter word is intentionally not quoted).
>>> * Replaced bash arrays with ${string:index:size} syntax.
>> Without having looked at the patch in full yet - is this any more
>> portable than the previous approach? I can't see any mention of
>> it in SUSv6 / SUSv7 either.
> 
> I can't say for sure but I remember seeing this construct long time ago.
> 
> Of course, this being bash, there are at least 3 ways of doing the same
> thing so I can also do
> 
> link=`echo "A B C D" | cut  -d" " -f $i`
> 
> Will SUSv6 understand this?

Yes, it looks like it will. But you could have checked yourself.

Jan


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

Re: [Xen-devel] [PATCH v4 6/6] VMX: Fixup PI descritpor when cpu is offline

[Jan Beulich]

>>> On 21.09.16 at 04:37,  wrote:
> +void vmx_pi_desc_fixup(int cpu)
> +{
> +unsigned int new_cpu, dest;
> +unsigned long flags;
> +struct arch_vmx_struct *vmx, *tmp;
> +spinlock_t *new_lock, *old_lock = _cpu(vmx_pi_blocking, cpu).lock;
> +struct list_head *blocked_vcpus = _cpu(vmx_pi_blocking, cpu).list;
> +
> +if ( !iommu_intpost )
> +return;
> +
> +spin_lock_irqsave(old_lock, flags);
> +
> +list_for_each_entry_safe(vmx, tmp, blocked_vcpus, pi_blocking.list)
> +{
> +/*
> + * We need to find an online cpu as the NDST of the PI descriptor, it
> + * doesn't matter whether it is within the cpupool of the domain or
> + * not. As long as it is online, the vCPU will be woken up once the
> + * notification event arrives.
> + */
> +new_cpu = cpumask_any(_online_map);
> +new_lock = _cpu(vmx_pi_blocking, new_cpu).lock;
> +
> +spin_lock(new_lock);

Without extra consideration this is a classical ABBA deadlock
scenario. Please add a comment (perhaps at the first lock location
above) at least briefly explaining why there can't be any deadlock
here.

Apart from that the patch looks fine to me now.

Jan


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

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Wei Liu]

On Mon, Sep 26, 2016 at 08:58:00AM -0400, Boris Ostrovsky wrote:
> On 09/26/2016 06:24 AM, Wei Liu wrote:
> > On Mon, Sep 26, 2016 at 11:20:50AM +0100, Ian Jackson wrote:
> >> Wei Liu writes ("Re: [PATCH v6] acpi: Prevent GPL-only code from seeping 
> >> into non-GPL binaries"):
> >>> On Fri, Sep 23, 2016 at 03:14:20PM -0400, Boris Ostrovsky wrote:
>  +links="ABCD"
>  +
>  +for i in $(seq 0 3)
>  +do
>  +link=${links:$i:1}
> >>> This is not portable.
> >>>
> >>> Use following instead:
> >>>
> >>> links="A B C D"
> >>>
> >>> set $links
> >>> for link in $@
> >> What's wrong with
> >>
> >>   links="A B C D"
> >>
> >>   for link in $links; do
> >> 
> >>
> >> ?
> 
> There are two interdependent variables that I need to print. The C
> equivalent is
> 
> for ( i = 0; i < 4; i++ )
> printf("%d %c\n", i, 'A'+i);
> 
> The character value is derived from 'i', which in this example is an
> index into 'links' array.
> 
> I suggested in response to Jan
> 
> link=`echo "A B C D" | cut -d" " -f $i`
> 

Oh, two variables. Then you could also do:

  link=`echo $i | tr "1234" "ABCD"`

(cut and tr are both from coreutils, so I think we're fine with using
either of them)

Anyway, enough of discussion about shell script. Pick the method you
like. :-)

Wei.


> 
> 
> -boris
> 

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

[Xen-devel] Outreachy Round 13 .Reg

[Harini V Reddy]

Hi,

I am Harini, an undergraduate pursuing Bachelors Of Engineering
in Information Science having some prior experience with coding
in C and Golang.

I am interested in applying for Outreachy Round 13 in golang bindings
for libxl project.

Can I know the first contributions to be made for the same?

I would really appreciate it if you could give some insights in this regard

Thanks,
Harini

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

Re: [Xen-devel] [PATCH v4 5/6] VT-d: No need to set irq affinity for posted format IRTE

[Jan Beulich]

>>> On 21.09.16 at 04:37,  wrote:
> We don't set the affinity for posted format IRTE, since the
> destination of these interrupts is vCPU and the vCPU affinity
> is set during vCPU scheduling.

I'm quite sure I did point out before that you talk about just affinity
changes here, yet ...

> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -637,9 +637,12 @@ static int msi_msg_to_remap_entry(
>  remap_rte->address_hi = 0;
>  remap_rte->data = index - i;
>  
> -memcpy(iremap_entry, _ire, sizeof(struct iremap_entry));
> -iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
> -iommu_flush_iec_index(iommu, 0, index);
> +if ( !iremap_entry->remap.p || !iremap_entry->remap.im )
> +{
> +memcpy(iremap_entry, _ire, sizeof(struct iremap_entry));
> +iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
> +iommu_flush_iec_index(iommu, 0, index);
> +}

... you suppress the update also in other cases. This _may_ be safe
at present, but you're digging a hole for someone else to fall into
down the road. Hence at the very least you should, in a to be added
"else" path, ASSERT() that nothing in the descriptor changed except
the bits representing affinity. Even better would be if in fact you
suppressed the update+flush only when nothing other than dst
changed.

Also, since you already touch this, please consider switching from the
type-unsafe memcpy() to type-safe structure assignment. And please
in any event change the sizeof()-s to sizeof(*iremap_entry).

Jan


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

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/26/2016 06:24 AM, Wei Liu wrote:
> On Mon, Sep 26, 2016 at 11:20:50AM +0100, Ian Jackson wrote:
>> Wei Liu writes ("Re: [PATCH v6] acpi: Prevent GPL-only code from seeping 
>> into non-GPL binaries"):
>>> On Fri, Sep 23, 2016 at 03:14:20PM -0400, Boris Ostrovsky wrote:
 +links="ABCD"
 +
 +for i in $(seq 0 3)
 +do
 +link=${links:$i:1}
>>> This is not portable.
>>>
>>> Use following instead:
>>>
>>> links="A B C D"
>>>
>>> set $links
>>> for link in $@
>> What's wrong with
>>
>>   links="A B C D"
>>
>>   for link in $links; do
>> 
>>
>> ?

There are two interdependent variables that I need to print. The C
equivalent is

for ( i = 0; i < 4; i++ )
printf("%d %c\n", i, 'A'+i);

The character value is derived from 'i', which in this example is an
index into 'links' array.

I suggested in response to Jan

link=`echo "A B C D" | cut -d" " -f $i`



-boris


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

Re: [Xen-devel] [PATCH] x86/AMD: apply erratum 665 workaround

[Andrew Cooper]

On 26/09/16 13:27, Jan Beulich wrote:
> From: Emanuel Czirai 
>
> AMD F12h machines have an erratum which can cause DIV/IDIV to behave
> unpredictably. The workaround is to set MSRC001_1029[31] but sometimes
> there is no BIOS update containing that workaround so let's do it
> ourselves unconditionally. It is simple enough.
>
> [ Borislav: Wrote commit message. ]
>
> Signed-off-by: Emanuel Czirai 
> Signed-off-by: Borislav Petkov 
> [Linux commit: d1992996753132e2dafe955cccb2fb0714d3cfc4]
>
> Make applicable to Xen.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

It would be nice to have a name for this bit, but the Fam 12h BKDG
identified it as reserved, making the erratum description the only
reference I can find to it.  Oh well.

~Andrew

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

Re: [Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/26/2016 02:46 AM, Jan Beulich wrote:
 On 23.09.16 at 21:14,  wrote:
>> Changes in v6:
>> * Replaced script's printf in most case with "here document" (for multi-line
>>   text) or echo for single line. Left printf for formatted output.
>>   (Note that in one case paramter expansion is necessary and so
>>delimiter word is intentionally not quoted).
>> * Replaced bash arrays with ${string:index:size} syntax.
> Without having looked at the patch in full yet - is this any more
> portable than the previous approach? I can't see any mention of
> it in SUSv6 / SUSv7 either.

I can't say for sure but I remember seeing this construct long time ago.

Of course, this being bash, there are at least 3 ways of doing the same
thing so I can also do

link=`echo "A B C D" | cut  -d" " -f $i`

Will SUSv6 understand this? I don't have access to anything older than
fedora 13.


-boris



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

Re: [Xen-devel] [PATCH v4 4/6] VMX: Make sure PI is in proper state before install the hooks

[Jan Beulich]

>>> On 21.09.16 at 04:37,  wrote:
> We may hit the ASSERT() in vmx_vcpu_block in the current code,

There are three of them - please be explicit which one is what gets
dealt with here.

> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -956,16 +956,13 @@ void virtual_vmcs_vmwrite(const struct vcpu *v, u32 
> vmcs_encoding, u64 val)
>   */
>  static void pi_desc_init(struct vcpu *v)
>  {
> -uint32_t dest;
> -
>  v->arch.hvm_vmx.pi_desc.nv = posted_intr_vector;
>  
> -dest = cpu_physical_id(v->processor);
> -
> -if ( x2apic_enabled )
> -v->arch.hvm_vmx.pi_desc.ndst = dest;
> -else
> -v->arch.hvm_vmx.pi_desc.ndst = MASK_INSR(dest, PI_xAPIC_NDST_MASK);
> +/*
> + * Mark NDST as invalid, then we can use this invalid value as a
> + * marker to whether update NDST or not in vmx_pi_hooks_assign().
> + */
> +v->arch.hvm_vmx.pi_desc.ndst = 0xff;

Is this a proper "invalid" indicator in the x2APIC case? I would have
assumed you want 0x in that case.

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -211,14 +211,39 @@ static void vmx_pi_list_cleanup(struct vcpu *v)
>  /* This function is called when pcidevs_lock is held */
>  void vmx_pi_hooks_assign(struct domain *d)
>  {
> +struct vcpu *v;
> +
>  if ( !iommu_intpost || !has_hvm_container_domain(d) )
>  return;
>  
>  ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
>  
> -d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> +/*
> + * We carefully handle the timing here:
> + * - Install the context switch first
> + * - Then set the NDST field
> + * - Install the block and resume hooks in the end
> + *
> + * This can make sure the PI (especially the NDST feild) is
> + * in proper state when we call vmx_vcpu_block().
> + */
>  d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
>  d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
> +
> +for_each_vcpu ( d, v )
> +{
> +unsigned int dest = cpu_physical_id(v->processor);
> +struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
> +
> + /*
> +  * We don't need to update NDST if 'arch.hvm_domain.vmx.pi_switch_to'
> +  * already gets called
> +  */

Stray tabs.

> +(void)cmpxchg(_desc->ndst, 0xff,
> +x2apic_enabled ? dest : MASK_INSR(dest, PI_xAPIC_NDST_MASK));

Here even more than above I think you want to derive the xAPIC
value from the wider x2APIC one not just for the value to write, but
also for the value to compare against. If you did so in pi_desc_init()
as well as here, I don't see a strict need for introducing a suitable
#define. If you don't, however, you definitely want a pair of
#define-s to one can associate both places with one another.

But overall I think this is much better than the previous version, so
thanks for doing (and testing) this.

Jan


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

[Xen-devel] [PATCH 2/2] xen: add qemu device for each pvusb backend

[Juergen Gross]

In order to be able to specify to which pvusb controller a new pvusb
device should be added we need a qemu device for each pvusb controller
with an associated id.

Add such a device when a new controller is requested and attach the
usb bus of that controller to the new device. Any device connected to
that controller can now specify the bus and port directly via its
properties.

Signed-off-by: Juergen Gross 
---
 hw/usb/xen-usb.c | 81 +++-
 1 file changed, 68 insertions(+), 13 deletions(-)

diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 174d715..439d104 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -29,6 +29,7 @@
 #include "hw/usb.h"
 #include "hw/xen/xen_backend.h"
 #include "monitor/qdev.h"
+#include "qapi/error.h"
 #include "qapi/qmp/qbool.h"
 #include "qapi/qmp/qint.h"
 #include "qapi/qmp/qstring.h"
@@ -47,12 +48,16 @@
 struct timeval tv;  \
 \
 gettimeofday(, NULL);\
-xen_be_printf(xendev, lvl, "%8ld.%06ld xen-usb(%s):" fmt,   \
+xen_be_printf(xendev, 0, "%8ld.%06ld xen-usb(%s):" fmt,   \
   tv.tv_sec, tv.tv_usec, __func__, ##args); \
 }
 #define TR_BUS(xendev, fmt, args...) TR(xendev, 2, fmt, ##args)
 #define TR_REQ(xendev, fmt, args...) TR(xendev, 3, fmt, ##args)
 
+#define TYPE_USBBACK"xen-pvusb"
+#define USBBACK_DEVICE(obj) \
+ OBJECT_CHECK(USBBACKDevice, (obj), TYPE_USBBACK)
+
 #define USBBACK_MAXPORTSUSBIF_PIPE_PORT_MASK
 #define USB_DEV_ADDR_SIZE   (USBIF_PIPE_DEV_MASK + 1)
 
@@ -67,6 +72,7 @@ struct usbif_ctrlrequest {
 
 struct usbback_info;
 struct usbback_req;
+struct USBBACKDevice;
 
 struct usbback_stub {
 USBDevice *dev;
@@ -101,6 +107,8 @@ struct usbback_hotplug {
 
 struct usbback_info {
 struct XenDevice xendev;  /* must be first */
+char id[24];
+struct USBBACKDevice *dev;
 USBBus   bus;
 void *urb_sring;
 void *conn_sring;
@@ -116,6 +124,10 @@ struct usbback_info {
 QEMUBH   *bh;
 };
 
+typedef struct USBBACKDevice {
+DeviceState qdev;
+} USBBACKDevice;
+
 static struct usbback_req *usbback_get_req(struct usbback_info *usbif)
 {
 struct usbback_req *usbback_req;
@@ -712,15 +724,10 @@ static void usbback_portid_detach(struct usbback_info 
*usbif, unsigned port)
 
 static void usbback_portid_remove(struct usbback_info *usbif, unsigned port)
 {
-USBPort *p;
-
 if (!usbif->ports[port - 1].dev) {
 return;
 }
 
-p = &(usbif->ports[port - 1].port);
-snprintf(p->path, sizeof(p->path), "%d", 99);
-
 object_unparent(OBJECT(usbif->ports[port - 1].dev));
 usbif->ports[port - 1].dev = NULL;
 usbback_portid_detach(usbif, port);
@@ -733,10 +740,10 @@ static void usbback_portid_add(struct usbback_info 
*usbif, unsigned port,
 {
 unsigned speed;
 char *portname;
-USBPort *p;
 Error *local_err = NULL;
 QDict *qdict;
 QemuOpts *opts;
+char tmp[32];
 
 if (usbif->ports[port - 1].dev) {
 return;
@@ -749,11 +756,14 @@ static void usbback_portid_add(struct usbback_info 
*usbif, unsigned port,
 return;
 }
 portname++;
-p = &(usbif->ports[port - 1].port);
-snprintf(p->path, sizeof(p->path), "%s", portname);
 
 qdict = qdict_new();
 qdict_put(qdict, "driver", qstring_from_str("usb-host"));
+snprintf(tmp, sizeof(tmp), "%s.0", usbif->id);
+qdict_put(qdict, "bus", qstring_from_str(tmp));
+snprintf(tmp, sizeof(tmp), "%s-%u", usbif->id, port);
+qdict_put(qdict, "id", qstring_from_str(tmp));
+qdict_put(qdict, "port", qint_from_int(port));
 qdict_put(qdict, "hostbus", qint_from_int(atoi(busid)));
 qdict_put(qdict, "hostport", qstring_from_str(portname));
 opts = qemu_opts_from_qdict(qemu_find_opts("device"), qdict, _err);
@@ -765,7 +775,6 @@ static void usbback_portid_add(struct usbback_info *usbif, 
unsigned port,
 goto err;
 }
 QDECREF(qdict);
-snprintf(p->path, sizeof(p->path), "%d", port);
 speed = usbif->ports[port - 1].dev->speed;
 switch (speed) {
 case USB_SPEED_LOW:
@@ -799,7 +808,6 @@ static void usbback_portid_add(struct usbback_info *usbif, 
unsigned port,
 
 err:
 QDECREF(qdict);
-snprintf(p->path, sizeof(p->path), "%d", 99);
 xen_be_printf(>xendev, 0, "device %s could not be opened\n", busid);
 }
 
@@ -1009,16 +1017,36 @@ static void usbback_alloc(struct XenDevice *xendev)
 struct usbback_info *usbif;
 USBPort *p;
 unsigned int i, max_grants;
+Error *local_err = NULL;
+QDict *qdict;
+QemuOpts *opts;
 
 usbif = container_of(xendev, struct usbback_info, xendev);
 
-usb_bus_new(>bus, sizeof(usbif->bus), _usb_bus_ops, xen_sysdev);

[Xen-devel] [PATCH 1/2] xen: add an own bus for xen backend devices

[Juergen Gross]

Add a bus for Xen backend devices in order to be able to establish a
dedicated device path for pluggable devices.

Signed-off-by: Juergen Gross 
---
 hw/xen/xen_backend.c | 19 ---
 include/hw/xen/xen_backend.h |  4 
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 69a2388..687adf4 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -29,13 +29,13 @@
 #include "hw/sysbus.h"
 #include "sysemu/char.h"
 #include "qemu/log.h"
+#include "qapi/error.h"
 #include "hw/xen/xen_backend.h"
 
 #include 
 
-#define TYPE_XENSYSDEV "xensysdev"
-
 DeviceState *xen_sysdev;
+BusState *xen_sysbus;
 
 /* - */
 
@@ -750,6 +750,8 @@ int xen_be_init(void)
 
 xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV);
 qdev_init_nofail(xen_sysdev);
+xen_sysbus = qbus_create(TYPE_XENSYSBUS, DEVICE(xen_sysdev), "xen-sysbus");
+qbus_set_bus_hotplug_handler(xen_sysbus, _abort);
 
 return 0;
 
@@ -862,6 +864,15 @@ void xen_be_printf(struct XenDevice *xendev, int 
msg_level, const char *fmt, ...
 qemu_log_flush();
 }
 
+static const TypeInfo xensysbus_info = {
+.name   = TYPE_XENSYSBUS,
+.parent = TYPE_BUS,
+.interfaces = (InterfaceInfo[]) {
+{ TYPE_HOTPLUG_HANDLER },
+{ }
+}
+};
+
 static int xen_sysdev_init(SysBusDevice *dev)
 {
 return 0;
@@ -878,6 +889,7 @@ static void xen_sysdev_class_init(ObjectClass *klass, void 
*data)
 
 k->init = xen_sysdev_init;
 dc->props = xen_sysdev_properties;
+dc->bus_type = TYPE_XENSYSBUS;
 }
 
 static const TypeInfo xensysdev_info = {
@@ -889,7 +901,8 @@ static const TypeInfo xensysdev_info = {
 
 static void xenbe_register_types(void)
 {
+type_register_static(_info);
 type_register_static(_info);
 }
 
-type_init(xenbe_register_types);
+type_init(xenbe_register_types)
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 0df282a..4087231 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -54,6 +54,9 @@ struct XenDevice {
 QTAILQ_ENTRY(XenDevice) next;
 };
 
+#define TYPE_XENSYSDEV "xensysdev"
+#define TYPE_XENSYSBUS "xen-sysbus"
+
 /* - */
 
 /* variables */
@@ -62,6 +65,7 @@ extern xenforeignmemory_handle *xen_fmem;
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
 extern DeviceState *xen_sysdev;
+extern BusState *xen_sysbus;
 
 /* xenstore helper functions */
 int xenstore_mkdir(char *path, int p);
-- 
2.6.6


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