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

[Dirk Behme]

On 09.11.2016 13:14, Julien Grall wrote:

Hello,

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

On 08.11.2016 16:41, Iurii Mykhalskyi wrote:

Hello Dirk,

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



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

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

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


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

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



Yes, correct, from general point of view :)

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


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


Best regards

Dirk

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm  3 host-install(3)  broken pass in 102045
 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail pass in 
102045

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

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

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

Last test of basis   102068  2016-11-09 13:00:05 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17115 days0 attempts

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] [linux-3.4 test] 102067: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl   6 xen-boot fail in 101695 pass in 102067
 test-amd64-amd64-libvirt-vhd  6 xen-boot fail in 101695 pass in 102067
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail in 101695 pass in 102067
 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail in 101695 pass in 
102067
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-boot   fail in 101695 pass in 102067
 test-amd64-amd64-xl-qcow2 6 xen-boot fail in 101695 pass in 102067
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail in 101695 pass in 
102067
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-bootfail in 101695 pass in 102067
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot  fail in 101695 pass in 102067
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail in 101695 
pass in 102067
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101695 pass 
in 102067
 test-amd64-i386-xl6 xen-boot fail in 101695 pass in 102067
 test-amd64-amd64-xl-xsm   6 xen-boot fail in 101695 pass in 102067
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail in 101695 pass in 
102067
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 101695

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

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

version targeted for testing:
 linux8d1988f838a95e836342b505398d38b223181f17
baseline version:
 linux343a5fbeef08baf2097b8cf4e26137cebe3cfef4

Last test of basis92983  2016-04-27 16:21:44 Z  196 days
Testing same since   101695  2016-10-26 18:26:23 Z   14 days   21 attempts


People who touched revisions under test:
  "Suzuki K. Poulose" 
  Aaro Koskinen 
  Al Viro 
  Alan Stern 
  Aleksander Morgado 
  Alex Thorlton 
  Alexandru Cornea 
  Alexey Khoroshilov 
  Amitkumar Karwar 
  Andrew Banman 
  Andrew Morton 
  Andrey Ryabinin 
  Anson Huang 
  Arnaldo Carvalho de Melo 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Ben Hutchings 
  Bjørn Mork 
  Boris Brezillon 
  Borislav Petkov 
  Brian Norris 
  Charles Keepax 
  Chen Yu 
  Christoph Hellwig 
  Chunfeng Yun 
  Clemens Ladisch 
  Colin Ian King 
  Cong Wang 
  Daeho Jeong 
  Dan Carpenter 
  Darren Hart 
  Dave Airlie 
  David Howells 
  David Rientjes 
  David S. Miller 
  David Turner 
  David Vrabel 
  David Woodhouse 
  Dmitry Tunin 

Re: [Xen-devel] [PATCH v3 00/15] Enable L2 Cache Allocation Technology

[Yi Sun]

On 16-11-09 01:37:55, Jan Beulich wrote:
> >>> On 09.11.16 at 02:28,  wrote:
> > Any comment or suggestion to this patch set? That would be very appreciated.
> 
> Please be assured that this has not been forgotten, but there are
> more important things to deal with, so it may take some more time
> to get to this. That's both because this clearly is for 4.9 only, and
> because it affecting Atoms only for now its relatively low priority
> only anyway (to date Atoms aren't a primary target for Xen afaict).
> 
> Jan
> 
Thank you! This patch set refactors the psr.c. It is the base of other
new features implementation. So, it would be better to get them merged
ASAP. Of course, I can understand you are busy working on more important
things. Please review the patches once you are free. Thanks!

> 
> ___
> 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] [Xen PATCH] xen-netback: fix error handling output

[David Miller]

From: Arnd Bergmann 
Date: Tue,  8 Nov 2016 14:34:34 +0100

> The connect function prints an unintialized error code after an
> earlier initialization was removed:
> 
> drivers/net/xen-netback/xenbus.c: In function 'connect':
> drivers/net/xen-netback/xenbus.c:938:3: error: 'err' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This prints it as -EINVAL instead, which seems to be the most
> appropriate error code. Before the patch that caused the warning,
> this would print a positive number returned by vsscanf() instead,
> which is also wrong. We probably don't need a backport though,
> as fixing the warning here should be sufficient.
> 
> Fixes: f95842e7a9f2 ("xen: make use of xenbus_read_unsigned() in xen-netback")
> Fixes: 8d3d53b3e433 ("xen-netback: Add support for multiple queues")
> Signed-off-by: Arnd Bergmann 

That first Fixes: commit mentioned is in neither of my trees, so I
assume it is in the Xen tree and thus this fix should get applied
there.

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

Re: [Xen-devel] [PATCH v3] xen-netback: prefer xenbus_scanf() over xenbus_gather()

[David Miller]

From: "Jan Beulich" 
Date: Tue, 08 Nov 2016 00:45:53 -0700

> For single items being collected this should be preferred as being more
> typesafe (as the compiler can check format string and to-be-written-to
> variable match) and more efficient (requiring one less parameter to be
> passed).
> 
> Signed-off-by: Jan Beulich 
> ---
> v3: For consistency with other code don't consider zero an error
> (utilizing that xenbus_scanf() at present won't return zero).
> v2: Avoid commit message to continue from subject.

Applied to net-next, thanks.

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

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

[Wen Congyang]

On 11/10/2016 01:31 AM, Sadi wrote:
> Hello again,
> 
> Looking at the primary host's syslog, the arptables command from 
> xen/etc/scripts/colo-proxy-setup has failed.
> 
> Here's the log:
> 
> Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: setup 
> XENBUS_PATH=
> Nov  9 14:43:39 colop kernel: [  302.825788] u32 classifier
> Nov  9 14:43:39 colop kernel: [  302.825791] Actions configured
> Nov  9 14:43:39 colop kernel: [  302.835407] Mirror/redirect action on
> Nov  9 14:43:39 colop kernel: [  302.919605] ip6_tables: (C) 2000-2006 
> Netfilter Core Team
> Nov  9 14:43:39 colop kernel: [  302.941511] arp_tables: (C) 2002 David S. 
> Miller
> Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: arptables -I 
> INPUT -i eth1 -j MARK --set-mark 1 failed
> Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: Writing 
> /hotplug-status connected to xenstore.
> Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: Successful 
> colo-proxy-setup setup for vif2.0-emu. mode = primary  vifname: vif2.0-emu, 
> index: 1, forwarddev: eth1.
> 
> It's ok for the --set-mark argument to have value equal '1' , not a hex?

This log is very useful, we will investigate it.

Thanks
Wen Congyang

> 
> The i got running the command is:
> root@colop:~# arptables -I INPUT -i eth1 -j MARK --set-mark 1
> Bad argument `1'
> 
> Thanks, Sadi.
> 
> 
> 
> On Tue, Nov 8, 2016 at 6:53 PM, Sadi  > wrote:
> 
> Hi,
> 
> Apparently vif2.0-emu was already binded with br0 when "brctl addif br0 
> vif2.0-emu" failed.
> 
> root@colob-HP-Compaq-6005-Pro-MT-PC:~# brctl addif br0 vif2.0-emu
> device vif2.0-emu is already a member of a bridge; can't enslave it to 
> bridge br0.
> root@colob-HP-Compaq-6005-Pro-MT-PC:~# brctl show
> bridge name bridge id   STP enabled interfaces
> br0 8000.001a3fc46255   no  eth0
> vif2.0
> vif2.0-emu
> br1 8000.   no
> 
> About the iptables, it seems like SECCOLO target can't be recognised.
> 
> root@colob-HP-Compaq-6005-Pro-MT-PC:~# iptables -t mangle -D PREROUTING 
> -m physdev --physdev-in vif2.0-emu -j SECCOLO --index 1
> iptables: No chain/target/match by that name.
> 
> Here is my active modules matching colo:
> 
> root@colob-HP-Compaq-6005-Pro-MT-PC:~# lsmod | grep -i colo
> xt_SECCOLO 16384  1
> nf_conntrack_colo  16384  2 xt_SECCOLO
> x_tables   36864  8 
> xt_physdev,ip6table_mangle,ip_tables,xt_SECCOLO,xt_tcpudp,iptable_filter,iptable_mangle,ip6_tables
> nf_conntrack  106496  4 
> xt_SECCOLO,nf_nat,nf_conntrack_colo,nf_conntrack_ipv4
> 
> So i was looking in the iptables and this really looks like the source of 
> the problem. 
> 
> Sadi.
> 
> On Tue, Nov 8, 2016 at 5:57 PM, Konrad Rzeszutek Wilk 
> > wrote:
> 
> > entered forwarding state
> > Nov  7 18:10:30 colob NetworkManager[907]:   (vif2.0-emu): 
> enslaved
> > to br0
> > Nov  7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup: 
> brctl addif
> > br0 vif2.0-emu failed
> 
> 
> How come this failed?
> 
> > Nov  7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup: 
> iptables -t
> > mangle -D PREROUTING -m physdev --physdev-in vif2.0-emu -j SECCOLO 
> --index
> > 1 failed
> 
> Ah b/c of this. Are there any errors of what exactly failed?
> 
> 
> 
> 
> -- 
> Sadi.
> 
> 
> 
> 
> -- 
> Sadi.




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

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

[osstest service owner]

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

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

Last test of basis   102022  2016-11-08 02:01:33 Z1 days
Testing same since   102079  2016-11-09 23:01:39 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

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=420596c8685d2c413ef4fc11fc942739b856a049
+ . ./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 
420596c8685d2c413ef4fc11fc942739b856a049
+ branch=xen-unstable-smoke
+ revision=420596c8685d2c413ef4fc11fc942739b856a049
+ . ./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
+ '[' x420596c8685d2c413ef4fc11fc942739b856a049 = 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] [RFC PATCH 24/24] ARM: vGIC: advertising LPI support

[Stefano Stabellini]

On Wed, 28 Sep 2016, Andre Przywara wrote:
> To let a guest know about the availability of virtual LPIs, set the
> respective bits in the virtual GIC registers and let a guest control
> the LPI enable bit.
> Only report the LPI capability if the host has initialized at least
> one ITS.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/vgic-v3.c | 28 +++-
>  1 file changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index d230a1f..61c97a2 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -168,8 +168,10 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  switch ( gicr_reg )
>  {
>  case VREG32(GICR_CTLR):
> -/* We have not implemented LPI's, read zero */
> -goto read_as_zero_32;
> +if ( dabt.size != DABT_WORD ) goto bad_width;
> +*r = vgic_reg32_extract(!!(v->arch.vgic.flags & 
> VGIC_V3_LPIS_ENABLED),
> +info);

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


> +return 1;
>  
>  case VREG32(GICR_IIDR):
>  if ( dabt.size != DABT_WORD ) goto bad_width;
> @@ -181,16 +183,19 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu 
> *v, mmio_info_t *info,
>  uint64_t typer, aff;
>  
>  if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> -/* TBD: Update processor id in [23:8] when ITS support is added */
>  aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
> MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
> MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
> MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
>  typer = aff;
> +typer |= (v->vcpu_id & 0x) << 8;
>  
>  if ( v->arch.vgic.flags & VGIC_V3_RDIST_LAST )
>  typer |= GICR_TYPER_LAST;
>  
> +if ( v->domain->arch.vgic.has_its )
> +typer |= GICR_TYPER_PLPIS;
> +
>  *r = vgic_reg64_extract(typer, info);
>  
>  return 1;
> @@ -468,8 +473,16 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu 
> *v, mmio_info_t *info,
>  switch ( gicr_reg )
>  {
>  case VREG32(GICR_CTLR):
> -/* LPI's not implemented */
> -goto write_ignore_32;
> +if ( dabt.size != DABT_WORD ) goto bad_width;
> +if ( !v->domain->arch.vgic.has_its )
> +return 1;
> +
> +if ( r & 1 )
> +v->arch.vgic.flags |= VGIC_V3_LPIS_ENABLED;
> +else
> +v->arch.vgic.flags &= !VGIC_V3_LPIS_ENABLED;
> +
> +return 1;
>  
>  case VREG32(GICR_IIDR):
>  /* RO */
> @@ -1075,6 +1088,11 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  typer = ((ncpus - 1) << GICD_TYPE_CPUS_SHIFT |
>   DIV_ROUND_UP(v->domain->arch.vgic.nr_spis, 32));
>  
> +if ( v->domain->arch.vgic.has_its )
> +{
> +typer |= GICD_TYPE_LPIS;
> +irq_bits = 16;
> +}
>  typer |= (irq_bits - 1) << GICD_TYPE_ID_BITS_SHIFT;
>  
>  *r = vgic_reg32_extract(typer, info);
> -- 
> 2.9.0
> 

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

Re: [Xen-devel] [RFC PATCH 22/24] ARM: vITS: create and initialize virtual ITSes for Dom0

[Stefano Stabellini]

On Wed, 28 Sep 2016, Andre Przywara wrote:
> For each hardware ITS create and initialize a virtual ITS for Dom0.
> We use the same memory mapped address to keep the doorbell working.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/vgic-its.c   | 22 ++
>  xen/arch/arm/vgic-v3.c| 12 
>  xen/include/asm-arm/domain.h  |  1 +
>  xen/include/asm-arm/gic-its.h | 13 +
>  4 files changed, 48 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index 1e429b7..5c605b5 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -829,6 +829,28 @@ static const struct mmio_handler_ops 
> vgic_its_mmio_handler = {
>  .write = vgic_v3_its_mmio_write,
>  };
>  
> +int vgic_v3_its_init_virtual(struct domain *d, struct host_its *hw_its,
> + paddr_t guest_addr)
> +{
> +struct virt_its *its;
> +
> +its = xzalloc(struct virt_its);
> +if ( ! its )
> +return -ENOMEM;
> +
> +its->d = d;
> +its->hw_its = hw_its;
> +its->baser0 = 0x79170400;
> +its->baser1 = 0x3c010400;
> +its->cbaser = 0x380e0400;

Please #define these values.


> +spin_lock_init(>vcmd_lock);
> +spin_lock_init(>its_lock);
> +
> +register_mmio_handler(d, _its_mmio_handler, guest_addr, SZ_64K, 
> its);
> +
> +return 0;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index aa53a1e..d230a1f 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -1572,6 +1573,7 @@ static int vgic_v3_domain_init(struct domain *d)
>   */
>  if ( is_hardware_domain(d) )
>  {
> +struct host_its *hw_its;
>  unsigned int first_cpu = 0;
>  
>  d->arch.vgic.dbase = vgic_v3_hw.dbase;
> @@ -1597,6 +1599,16 @@ static int vgic_v3_domain_init(struct domain *d)
>  
>  first_cpu += size / d->arch.vgic.rdist_stride;
>  }
> +d->arch.vgic.nr_regions = vgic_v3_hw.nr_rdist_regions;
> +
> +list_for_each_entry(hw_its, _its_list, entry)
> +{
> +/* Emulate the control registers frame (lower 64K). */
> +vgic_v3_its_init_virtual(d, hw_its, hw_its->addr);
> +
> +d->arch.vgic.has_its = true;
> +}
> +
>  }
>  else
>  {
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 0cd3500..1c2f7c7 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -111,6 +111,7 @@ struct arch_domain
>  uint32_t rdist_stride;  /* Re-Distributor stride */
>  uint64_t rdist_propbase;
>  uint8_t *proptable;
> +bool has_its;
>  #endif
>  } vgic;
>  
> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
> index ba6b2d5..b58e092 100644
> --- a/xen/include/asm-arm/gic-its.h
> +++ b/xen/include/asm-arm/gic-its.h
> @@ -123,6 +123,13 @@ void gicv3_set_redist_addr(paddr_t address, int 
> redist_id);
>  /* Map a collection for this host CPU to each host ITS. */
>  void gicv3_its_setup_collection(int cpu);
>  
> +/* Create and register a virtual ITS at the given guest address.
> + * If a host ITS is specified, a hardware domain can reach out to that host
> + * ITS to deal with devices and LPI mappings and can enable/disable LPIs.
> + */
> +int vgic_v3_its_init_virtual(struct domain *d, struct host_its *hw_its,
> + paddr_t guest_addr);
> +
>  /* Map a device on the host by allocating an ITT on the host (ITS).
>   * "bits" specifies how many events (interrupts) this device will need.
>   * Setting "valid" to false deallocates the device.
> @@ -204,6 +211,12 @@ static inline bool gicv3_lpi_is_enabled(struct domain 
> *d, uint32_t lpi)
>  {
>  return false;
>  }
> +static inline int vgic_v3_its_init_virtual(struct domain *d,
> +   struct host_its *hw_its,
> +   paddr_t guest_addr)
> +{
> +return 0;
> +}
>  
>  #endif /* CONFIG_HAS_ITS */
>  
> -- 
> 2.9.0
> 

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

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

[Stefano Stabellini]

On Fri, 4 Nov 2016, Andre Przywara wrote:
> Hi,
> 
> On 24/10/16 16:32, Vijay Kilari wrote:
> > On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara  
> > wrote:
> >> The INVALL command instructs an ITS to invalidate the configuration
> >> data for all LPIs associated with a given redistributor (read: VCPU).
> >> To avoid iterating (and mapping!) all guest tables, we instead go through
> >> the host LPI table to find any LPIs targetting this VCPU. We then update
> >> the configuration bits for the connected virtual LPIs.
> >>
> >> Signed-off-by: Andre Przywara 
> >> ---
> >>  xen/arch/arm/gic-its.c| 58 
> >> +++
> >>  xen/arch/arm/vgic-its.c   | 30 ++
> >>  xen/include/asm-arm/gic-its.h |  2 ++
> >>  3 files changed, 90 insertions(+)
> >>
> >> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> >> index 6f4329f..5129d6e 100644
> >> --- a/xen/arch/arm/gic-its.c
> >> +++ b/xen/arch/arm/gic-its.c
> >> @@ -228,6 +228,18 @@ static int its_send_cmd_inv(struct host_its *its,
> >>  return its_send_command(its, cmd);
> >>  }
> >>
> >> +static int its_send_cmd_invall(struct host_its *its, int cpu)
> >> +{
> >> +uint64_t cmd[4];
> >> +
> >> +cmd[0] = GITS_CMD_INVALL;
> >> +cmd[1] = 0x00;
> >> +cmd[2] = cpu & GENMASK(15, 0);
> >> +cmd[3] = 0x00;
> >> +
> >> +return its_send_command(its, cmd);
> >> +}
> >> +
> >>  int gicv3_its_map_device(struct host_its *hw_its, struct domain *d,
> >>   int devid, int bits, bool valid)
> >>  {
> >> @@ -668,6 +680,52 @@ uint32_t gicv3_lpi_lookup_lpi(struct domain *d, 
> >> uint32_t host_lpi, int *vcpu_id)
> >>  return hlpi.virt_lpi;
> >>  }
> >>
> >> +/* Iterate over all host LPIs, and updating the "enabled" state for a 
> >> given
> >> + * guest redistributor (VCPU) given the respective state in the provided
> >> + * proptable. This proptable is indexed by the stored virtual LPI number.
> >> + * This is to implement a guest INVALL command.
> >> + */
> >> +void gicv3_lpi_update_configurations(struct vcpu *v, uint8_t *proptable)
> >> +{
> >> +int chunk, i;
> >> +struct host_its *its;
> >> +
> >> +for (chunk = 0; chunk < MAX_HOST_LPIS / HOST_LPIS_PER_PAGE; chunk++)
> >> +{
> >> +if ( !lpi_data.host_lpis[chunk] )
> >> +continue;
> >> +
> >> +for (i = 0; i < HOST_LPIS_PER_PAGE; i++)
> >> +{
> >> +union host_lpi *hlpip = _data.host_lpis[chunk][i], hlpi;
> >> +uint32_t hlpi_nr;
> >> +
> >> +hlpi.data = hlpip->data;
> >> +if ( !hlpi.virt_lpi )
> >> +continue;
> >> +
> >> +if ( hlpi.dom_id != v->domain->domain_id )
> >> +continue;
> >> +
> >> +if ( hlpi.vcpu_id != v->vcpu_id )
> >> +continue;
> >> +
> >> +hlpi_nr = chunk * HOST_LPIS_PER_PAGE + i;
> >> +
> >> +if ( proptable[hlpi.virt_lpi] & LPI_PROP_ENABLED )
> >> +lpi_data.lpi_property[hlpi_nr - 8192] |= LPI_PROP_ENABLED;
> >> +else
> >> +lpi_data.lpi_property[hlpi_nr - 8192] &= 
> >> ~LPI_PROP_ENABLED;
> >> +}
> >> +}
> > AFAIK, the initial design is to use tasklet to update property
> > table as it consumes
> > lot of time to update the table.
> 
> This is a possible, but premature optimization.
> Linux (at the moment, at least) only calls INVALL _once_, just after
> initialising the collections. And at this point no LPI is mapped, so the
> whole routine does basically nothing - and that quite fast.
> We can later have any kind of fancy algorithm if there is a need for.

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

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

We need to protect Xen from too frequent and too expensive requests like
this.


> >> +
> >> +/* Tell all ITSes that they should update the property table for CPU 
> >> 0,
> >> + * which is where we map all LPIs to.
> >> + */
> >> +list_for_each_entry(its, _its_list, entry)
> >> +its_send_cmd_invall(its, 0);
> >> +}
> >> +
> >>  void gicv3_lpi_set_enable(struct host_its *its,
> >>uint32_t deviceid, uint32_t eventid,
> >>uint32_t host_lpi, bool enabled)
> >> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> >> index 74da8fc..1e429b7 100644
> 

Re: [Xen-devel] Xen ARM community call

[Anastassios Nanos]

Hi Julien, all,

> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.

great idea, I'd like to join too (GMT).

> Example of features that could be discussed:
> - Sharing co-processor between guests
> - PCI passthrough

Another issue to discuss, at some point, could be big.LITTLE support
(based on 
https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01802.html).

cheers,
A.

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

Re: [Xen-devel] [PATCH v3 2/2] Partially revert 21550029f709072aacf3b90edd574e7d3021b400

[Stefano Stabellini]

On Wed, 9 Nov 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 08/11/16 19:42, Stefano Stabellini wrote:
> > @@ -1189,7 +1194,10 @@ static int __init gicv2_init(void)
> >  printk(XENLOG_WARNING
> > "GICv2: Adjusting CPU interface base to %#"PRIx64"\n",
> > cbase + aliased_offset);
> > -}
> > +} else if ( csize == SZ_128K )
> > +printk(XENLOG_WARNING
> > +"GICv2: GICC size=%lu but not aliased\n",
> > +csize);
> 
> The indentation looks wrong here.
> 
> With that:
> 
> Acked-by: Julien Grall 

Thanks, I fixed that and also the %lu, which should be %#"PRIx64" like
few lines above. I committed the patches.

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

[Xen-devel] [linux-3.10 test] 102063: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 100648
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 100648

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

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

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

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

[Boris Ostrovsky]

On 11/09/2016 02:58 PM, Andrew Cooper wrote:
> On 09/11/16 15:14, Boris Ostrovsky wrote:
>> On 11/09/2016 09:59 AM, Andrew Cooper wrote:
 diff --git a/xen/include/public/hvm/ioreq.h 
 b/xen/include/public/hvm/ioreq.h
 index 2e5809b..e3fa704 100644
 --- a/xen/include/public/hvm/ioreq.h
 +++ b/xen/include/public/hvm/ioreq.h
 @@ -24,6 +24,8 @@
  #ifndef _IOREQ_H_
  #define _IOREQ_H_
  
 +#include "hvm_info_table.h" /* HVM_MAX_VCPUS */
 +
  #define IOREQ_READ  1
  #define IOREQ_WRITE 0
  
 @@ -124,6 +126,17 @@ typedef struct buffered_iopage buffered_iopage_t;
  #define ACPI_GPE0_BLK_ADDRESSACPI_GPE0_BLK_ADDRESS_V0
  #define ACPI_GPE0_BLK_LENACPI_GPE0_BLK_LEN_V0
  
 +#define ACPI_PM1A_EVT_BLK_LEN0x04
 +#define ACPI_PM1A_CNT_BLK_LEN0x02
 +#define ACPI_PM_TMR_BLK_LEN  0x04
 +
 +/* Location of online VCPU bitmap. */
 +#define ACPI_CPU_MAP 0xaf00
 +#define ACPI_CPU_MAP_LEN ((HVM_MAX_VCPUS / 8) + \
 +  ((HVM_MAX_VCPUS & 7) ? 1 : 0))
 +#if ACPI_CPU_MAP + ACPI_CPU_MAP_LEN >= ACPI_GPE0_BLK_ADDRESS_V1
 +#error "ACPI_CPU_MAP is too big"
 +#endif
>>> Why is this in ioreq.h?  It has nothing to do with ioreq's.
>>>
>>> The current ACPI bits in here are to do with the qemu ACPI interface,
>>> not the Xen ACPI interface.
>>>
>>> Also, please can we avoid hard-coding the location of the map in the
>>> hypervisor ABI.  These constants make it impossible to ever extend the
>>> number of HVM vcpus at a future date.
>> The first three logically belong here because corresponding blocks'
>> addresses are defined right above.
> They have no relationship to the ones above, other than their name.

They describe the same object --- for example
ACPI_PM1A_CNT_BLK_ADDRESS_V1 and (new) ACPI_PM1A_CNT_BLK_LEN describe
pm1a control.

As far as definitions being there for qemu interface only ---
ACPI_PM1A_CNT_BLK_ADDRESS_V1, for example, is used only by hvmloader and
libacpi.


>
>> ACPI_CPU_MAP has to be seen by both the toolstack (libacpi) and the
>> hypervisor (and qemu as well, although it is defined as
>> PIIX4_CPU_HOTPLUG_IO_BASE).
>>
>> Where do you think it should go then?
> This highlights a reoccurring problem in Xen which desperately needs
> fixing, but still isn't high enough on my TODO list to tackle yet.
>
> There is no central registration of claims on domain resources.  This is
> the root cause of memory accounting problems for HVM guests.
>
>
> The way I planned to fix this was to have Xen maintain a registry of
> domains physical resources which ends up looking very much like
> /proc/io{mem,ports}.  There will be a hypercall interface for querying
> this information, and for a toolstack and device model to modify it.
>
> The key point is that Xen needs to be authoritative source of
> information pertaining to layout, rather than the current fiasco we have
> of the toolstack, qemu and hvmloader all thinking they know and control
> what's going on.  This fixes several current unknowns which have caused
> real problems, such as whether a domain was told about certain RMRRs
> when it booted, or how many PXEROMs qemu tried to fit into the physmap.
>
> This information (eventually, when I get Xen-level migration v2 sorted)
> needs to move at the head of the migration stream.
>
> The way I would envisage this working is that on domain create, Xen
> makes a blank map indicating that all space is free.  By selecting
> X86_EMUL_APCI_*, Xen takes out an allocation when it wires up the ioport
> handler.
>
> Later, when constructing the ACPI tables, the toolstack reads the
> current ioport allocations and can see exactly which ports are reserved
> for what.
>
>
> Now, I understand that lumbering you with this work as a prerequisite
> would be unfair.
>
> Therefore, I will accept an alternative of hiding all these definitions
> behind __XEN_TOOLS__ so the longterm fix can be introduced in a
> compatible manner in the future.


__XEN_TOOLS__ or (__XEN__ || __XEN_TOOLS__) ? Because both the toolstack
and the hypervisor want to see them.


>
> That said, I am still certain that they shouldn't live in ioreq.h, as
> they have nothing to do with Qemu.

None of the existing files looks (to me) much better in terms of being
more appropriate. include/public/arch-x86/xen.h?


-boris


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

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

[Pasi Kärkkäinen]

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

I think you mean iBFT = iSCSI Boot Firmware Table.


-- Pasi


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

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

[Andrew Cooper]

On 09/11/16 15:14, Boris Ostrovsky wrote:
> On 11/09/2016 09:59 AM, Andrew Cooper wrote:
>>> diff --git a/xen/include/public/hvm/ioreq.h b/xen/include/public/hvm/ioreq.h
>>> index 2e5809b..e3fa704 100644
>>> --- a/xen/include/public/hvm/ioreq.h
>>> +++ b/xen/include/public/hvm/ioreq.h
>>> @@ -24,6 +24,8 @@
>>>  #ifndef _IOREQ_H_
>>>  #define _IOREQ_H_
>>>  
>>> +#include "hvm_info_table.h" /* HVM_MAX_VCPUS */
>>> +
>>>  #define IOREQ_READ  1
>>>  #define IOREQ_WRITE 0
>>>  
>>> @@ -124,6 +126,17 @@ typedef struct buffered_iopage buffered_iopage_t;
>>>  #define ACPI_GPE0_BLK_ADDRESSACPI_GPE0_BLK_ADDRESS_V0
>>>  #define ACPI_GPE0_BLK_LENACPI_GPE0_BLK_LEN_V0
>>>  
>>> +#define ACPI_PM1A_EVT_BLK_LEN0x04
>>> +#define ACPI_PM1A_CNT_BLK_LEN0x02
>>> +#define ACPI_PM_TMR_BLK_LEN  0x04
>>> +
>>> +/* Location of online VCPU bitmap. */
>>> +#define ACPI_CPU_MAP 0xaf00
>>> +#define ACPI_CPU_MAP_LEN ((HVM_MAX_VCPUS / 8) + \
>>> +  ((HVM_MAX_VCPUS & 7) ? 1 : 0))
>>> +#if ACPI_CPU_MAP + ACPI_CPU_MAP_LEN >= ACPI_GPE0_BLK_ADDRESS_V1
>>> +#error "ACPI_CPU_MAP is too big"
>>> +#endif
>> Why is this in ioreq.h?  It has nothing to do with ioreq's.
>>
>> The current ACPI bits in here are to do with the qemu ACPI interface,
>> not the Xen ACPI interface.
>>
>> Also, please can we avoid hard-coding the location of the map in the
>> hypervisor ABI.  These constants make it impossible to ever extend the
>> number of HVM vcpus at a future date.
> The first three logically belong here because corresponding blocks'
> addresses are defined right above.

They have no relationship to the ones above, other than their name.

>
> ACPI_CPU_MAP has to be seen by both the toolstack (libacpi) and the
> hypervisor (and qemu as well, although it is defined as
> PIIX4_CPU_HOTPLUG_IO_BASE).
>
> Where do you think it should go then?

This highlights a reoccurring problem in Xen which desperately needs
fixing, but still isn't high enough on my TODO list to tackle yet.

There is no central registration of claims on domain resources.  This is
the root cause of memory accounting problems for HVM guests.


The way I planned to fix this was to have Xen maintain a registry of
domains physical resources which ends up looking very much like
/proc/io{mem,ports}.  There will be a hypercall interface for querying
this information, and for a toolstack and device model to modify it.

The key point is that Xen needs to be authoritative source of
information pertaining to layout, rather than the current fiasco we have
of the toolstack, qemu and hvmloader all thinking they know and control
what's going on.  This fixes several current unknowns which have caused
real problems, such as whether a domain was told about certain RMRRs
when it booted, or how many PXEROMs qemu tried to fit into the physmap.

This information (eventually, when I get Xen-level migration v2 sorted)
needs to move at the head of the migration stream.

The way I would envisage this working is that on domain create, Xen
makes a blank map indicating that all space is free.  By selecting
X86_EMUL_APCI_*, Xen takes out an allocation when it wires up the ioport
handler.

Later, when constructing the ACPI tables, the toolstack reads the
current ioport allocations and can see exactly which ports are reserved
for what.


Now, I understand that lumbering you with this work as a prerequisite
would be unfair.

Therefore, I will accept an alternative of hiding all these definitions
behind __XEN_TOOLS__ so the longterm fix can be introduced in a
compatible manner in the future.

That said, I am still certain that they shouldn't live in ioreq.h, as
they have nothing to do with Qemu.

~Andrew

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

Re: [Xen-devel] [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Boris Ostrovsky]

On 11/09/2016 02:23 PM, Andrew Cooper wrote:
> On 09/11/16 15:29, Boris Ostrovsky wrote:
>> On 11/09/2016 10:04 AM, Andrew Cooper wrote:
>>> On 09/11/16 14:39, Boris Ostrovsky wrote:
 This domctl is called when a VCPU is hot-(un)plugged to a guest (via
 'xl vcpu-set'). While this currently is only intended to be needed by
 PVH guests we will call this domctl for all (x86) guests for consistency.

 Signed-off-by: Boris Ostrovsky 
 Acked-by: Daniel De Graaf 
 ---
 Changes in v2:
 * Added comment in arch_do_domctl() stating that the domctl is only 
 required
   for PVH guests
>>> I am not happy with this change until we understand why it is needed.
>>>
>>> Are we genuinely saying that there is no current enforcement in the
>>> PV-hotplug mechanism?
>> That's right. Don't call setup_cpu_watcher() in Linux and you will be
>> running with maxvcpus.
> /sigh - Quality engineering there...
>
> Yes - lets take the time to actually do this properly.
>
 diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
 index 2a2fe04..b736d4c 100644
 --- a/xen/arch/x86/domctl.c
 +++ b/xen/arch/x86/domctl.c
 @@ -1430,6 +1430,23 @@ long arch_do_domctl(
  }
  break;
  
 +case XEN_DOMCTL_set_avail_vcpus:
 +{
 +unsigned int num = domctl->u.avail_vcpus.num;
 +
 +/*
 + * This is currently only needed by PVH guests (but
 + * any guest is free to make this call).
 + */
 +ret = -EINVAL;
 +if ( num > d->max_vcpus )
 +break;
 +
 +d->arch.avail_vcpus = num;
 +ret = 0;
 +break;
 +}
>>> What do you actually mean by "avail_vcpus"?  What happens if a vcpu
>>> higher than the new number is currently online and running?  What
>>> happens to the already-existing vcpus-at-startup value?
>> It shouldn't happen: we set avail_vcpus at domain creation time to
>> vcpus-at-startup.
>>
>> The name is not great. It would have been better to have it online_vcpus
>> but that usually means that VPF_down is set (which can happen, for
>> example, when the guest offlines a VCPU).
> How about an availability bitmap instead, which always has max_vcpus
> bits in it?  Xen should consult the bitmap before allowing a VM to
> online a new vcpu.

We could indeed use bitmap (and then it will actually be easier to
handle io request as we can just copy appropriate bytes of the map
instead of going bit-by-bit). This will still require the new domctl.

I am not convinced though that we can start enforcing this new VCPU
count, at least for PV guests. They expect to start all max VCPUs and
then offline them. This, of course, can be fixed but all non-updated
kernels will stop booting.
-boris


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

Re: [Xen-devel] [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Andrew Cooper]

On 09/11/16 15:29, Boris Ostrovsky wrote:
> On 11/09/2016 10:04 AM, Andrew Cooper wrote:
>> On 09/11/16 14:39, Boris Ostrovsky wrote:
>>> This domctl is called when a VCPU is hot-(un)plugged to a guest (via
>>> 'xl vcpu-set'). While this currently is only intended to be needed by
>>> PVH guests we will call this domctl for all (x86) guests for consistency.
>>>
>>> Signed-off-by: Boris Ostrovsky 
>>> Acked-by: Daniel De Graaf 
>>> ---
>>> Changes in v2:
>>> * Added comment in arch_do_domctl() stating that the domctl is only required
>>>   for PVH guests
>> I am not happy with this change until we understand why it is needed.
>>
>> Are we genuinely saying that there is no current enforcement in the
>> PV-hotplug mechanism?
> That's right. Don't call setup_cpu_watcher() in Linux and you will be
> running with maxvcpus.

/sigh - Quality engineering there...

Yes - lets take the time to actually do this properly.

>
>>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>>> index 2a2fe04..b736d4c 100644
>>> --- a/xen/arch/x86/domctl.c
>>> +++ b/xen/arch/x86/domctl.c
>>> @@ -1430,6 +1430,23 @@ long arch_do_domctl(
>>>  }
>>>  break;
>>>  
>>> +case XEN_DOMCTL_set_avail_vcpus:
>>> +{
>>> +unsigned int num = domctl->u.avail_vcpus.num;
>>> +
>>> +/*
>>> + * This is currently only needed by PVH guests (but
>>> + * any guest is free to make this call).
>>> + */
>>> +ret = -EINVAL;
>>> +if ( num > d->max_vcpus )
>>> +break;
>>> +
>>> +d->arch.avail_vcpus = num;
>>> +ret = 0;
>>> +break;
>>> +}
>> What do you actually mean by "avail_vcpus"?  What happens if a vcpu
>> higher than the new number is currently online and running?  What
>> happens to the already-existing vcpus-at-startup value?
> It shouldn't happen: we set avail_vcpus at domain creation time to
> vcpus-at-startup.
>
> The name is not great. It would have been better to have it online_vcpus
> but that usually means that VPF_down is set (which can happen, for
> example, when the guest offlines a VCPU).

How about an availability bitmap instead, which always has max_vcpus
bits in it?  Xen should consult the bitmap before allowing a VM to
online a new vcpu.

~Andrew

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

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

[Andrew Cooper]

On 09/11/16 15:59, Roger Pau Monné wrote:
> Hello,
>
> I'm attaching a draft of how a PVHv2 Dom0 is supposed to interact with 
> physical devices, and what needs to be done inside of Xen in order to 
> achieve it. Current draft is RFC because I'm quite sure I'm missing bits 
> that should be written down here. So far I've tried to describe what my 
> previous series attempted to do by adding a bunch of IO and memory space 
> handlers.
>
> Please note that this document only applies to PVHv2 Dom0, it is not 
> applicable to untrusted domains that will need more handlers in order to 
> secure Xen and other domains running on the same system. The idea is that 
> this can be expanded to untrusted domains also in the long term, thus having 
> a single set of IO and memory handlers for passed-through devices.
>
> Roger.
>
> ---8<---
>
> This document describes how a PVHv2 Dom0 is supposed to interact with physical
> devices.
>
> Architecture
> 
>
> Purpose
> ---
>
> Previous Dom0 implementations have always used PIRQs (physical interrupts
> routed over event channels) in order to receive events from physical devices.
> This prevents Dom0 form taking advantage of new hardware virtualization
> features, like posted interrupts or hardware virtualized local APIC. Also the
> current device memory management in the PVH Dom0 implementation is lacking,
> and might not support devices that have memory regions past the 4GB 
> boundary.
>
> The new PVH implementation (PVHv2) should overcome the interrupt limitations 
> by
> providing the same interface that's used on bare metal (a local and IO APICs)
> thus allowing the usage of advanced hardware assisted virtualization
> techniques. This also aligns with the trend on the hardware industry to
> move part of the emulation into the silicon itself.

+10

>
> In order to improve the mapping of device memory areas, Xen will have to
> know of those devices in advance (before Dom0 tries to interact with them)
> so that the memory BARs will be properly mapped into Dom0 memory map.
>
> The following document describes the proposed interface and implementation
> of all the logic needed in order to achieve the functionality described 
> above.
>
> MMIO areas
> ==
>
> Overview
> 
>
> On x86 systems certain regions of memory might be used in order to manage
> physical devices on the system. Access to this areas is critical for a
> PVH Dom0 in order to operate properly. Unlike previous PVH Dom0 implementation
> (PVHv1) that was setup with identity mappings of all the holes and reserved
> regions found in the memory map, this new implementation intents to map only
> what's actually needed by the Dom0.
>
> Low 1MB
> ---
>
> When booted with a legacy BIOS, the low 1MB contains firmware related data
> that should be identity mapped to the Dom0. This include the EBDA, video
> memory and possibly ROMs. All non RAM regions below 1MB will be identity
> mapped to the Dom0 so that it can access this data freely.

Are you proposing a unilateral identity map of the first 1MB, or just
the interesting regions?

One thing to remember is the iBVT, for iscsi boot, which lives in
regular RAM and needs searching for.

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

Yes.  There is no 

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

[Konrad Rzeszutek Wilk]

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

memory regions meaning BAR regions?

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

What if the hardware PVH2 runs on does not have vAPIC?
> 
> In order to improve the mapping of device memory areas, Xen will have to
> know of those devices in advance (before Dom0 tries to interact with them)
> so that the memory BARs will be properly mapped into Dom0 memory map.

Oh, that is going to be a problem with SR-IOV. Those are created _after_
dom0 has booted. In fact they are done by the drivers themselves.

See xen_add_device in drivers/xen/pci.c how this is handled.

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

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

You can make that simpler - we have hypercalls to "notify" in Linux
when a device is changing. Those can provide that information as well.
(This is what PV dom0 does).

Also you are missing one important part - the MMCFG. That is required
for Xen to be able to poke at the PCI configuration spaces (above the 256).
And you can only get the MMCFG if the ACPI DSDT has been parsed.

So if you do the PCI bus scanning _before_ booting PVH dom0, you may
need to update your view of PCI devices after the MMCFG locations
have been provided to you.

> 
> Limitations
> ---
> 
>  - Xen needs to be aware of any PCI device before Dom0 tries to interact with
>it, so that the MMIO regions are properly mapped.
> 
> Interrupt management
> 
> 
> Overview
> 
> 
> On x86 systems there are tree different mechanisms that can be used in order
> to deliver interrupts: IO 

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

[Andrew Cooper]

On 09/11/16 14:14, Jan Beulich wrote:
 On 09.11.16 at 13:28,  wrote:
>> The original code has a bug; eax and edx get unconditionally updated even 
>> when
>> hvm_msr_read_intercept() doesn't return X86EMUL_OKAY.
>>
>> It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content
>> pointer) that this isn't an information leak into guests.
>>
>> While fixing this bug, reduce the scope of msr_content and initialise it to 
>> 0.
>> This makes it obvious that a stack leak won't occur, even if there were to be
>> a buggy codepath in hvm_msr_read_intercept().
>>
>> Also make some non-functional improvements.  Make the insn_len calculation
>> common, and reduce the quantity of explicit casting by making better use of
>> the existing register names.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
> with two possible further adjustments:
>
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1948,26 +1948,28 @@ static int svm_msr_write_intercept(unsigned int msr, 
>> uint64_t msr_content)
>>  
>>  static void svm_do_msr_access(struct cpu_user_regs *regs)
>>  {
>> -int rc, inst_len;
>>  struct vcpu *v = current;
>> -struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>> -uint64_t msr_content;
>> +bool rdmsr = v->arch.hvm_svm.vmcb->exitinfo1 == 0;
>> +int rc, inst_len = __get_instruction_length(
>> +v, rdmsr ? INSTR_RDMSR : INSTR_WRMSR);
> With all of this I think it wouldn't make the patch worse to look at if
> you also renamed v -> curr.

I am sure at least one version of this patch had that adjustment.  I
will fix it.

>
>> +if ( inst_len == 0 )
>> +return;
>>  
>> -if ( vmcb->exitinfo1 == 0 )
>> +if ( rdmsr )
>>  {
>> -if ( (inst_len = __get_instruction_length(v, INSTR_RDMSR)) == 0 )
>> -return;
>> -rc = hvm_msr_read_intercept(regs->ecx, _content);
>> -regs->eax = (uint32_t)msr_content;
>> -regs->edx = (uint32_t)(msr_content >> 32);
>> +uint64_t msr_content = 0;
>> +
>> +rc = hvm_msr_read_intercept(regs->_ecx, _content);
>> +if ( rc == X86EMUL_OKAY )
>> +{
>> +regs->rax = (uint32_t)msr_content;
>> +regs->rdx = (uint32_t)(msr_content >> 32);
> While the first of the casts is needed, the second one isn't.

Right, but removing the cast make the code harder to read.  This at
least is visually obvious that msr_content is being split in half.

~Andrew

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

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

[Sadi]

Hello again,

Looking at the primary host's syslog, the arptables command from
xen/etc/scripts/colo-proxy-setup has failed.

Here's the log:

Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: setup
XENBUS_PATH=
Nov  9 14:43:39 colop kernel: [  302.825788] u32 classifier
Nov  9 14:43:39 colop kernel: [  302.825791] Actions configured
Nov  9 14:43:39 colop kernel: [  302.835407] Mirror/redirect action on
Nov  9 14:43:39 colop kernel: [  302.919605] ip6_tables: (C) 2000-2006
Netfilter Core Team
Nov  9 14:43:39 colop kernel: [  302.941511] arp_tables: (C) 2002 David S.
Miller
Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: arptables
-I INPUT -i eth1 -j MARK --set-mark 1 failed
Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: Writing
/hotplug-status connected to xenstore.
Nov  9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: Successful
colo-proxy-setup setup for vif2.0-emu. mode = primary  vifname: vif2.0-emu,
index: 1, forwarddev: eth1.

It's ok for the --set-mark argument to have value equal '1' , not a hex?

The i got running the command is:
root@colop:~# arptables -I INPUT -i eth1 -j MARK --set-mark 1
Bad argument `1'

Thanks, Sadi.



On Tue, Nov 8, 2016 at 6:53 PM, Sadi  wrote:

> Hi,
>
> Apparently vif2.0-emu was already binded with br0 when "brctl addif br0
> vif2.0-emu" failed.
>
> root@colob-HP-Compaq-6005-Pro-MT-PC:~# brctl addif br0 vif2.0-emu
> device vif2.0-emu is already a member of a bridge; can't enslave it to
> bridge br0.
> root@colob-HP-Compaq-6005-Pro-MT-PC:~# brctl show
> bridge name bridge id   STP enabled interfaces
> br0 8000.001a3fc46255   no  eth0
> vif2.0
> vif2.0-emu
> br1 8000.   no
>
> About the iptables, it seems like SECCOLO target can't be recognised.
>
> root@colob-HP-Compaq-6005-Pro-MT-PC:~# iptables -t mangle -D PREROUTING
> -m physdev --physdev-in vif2.0-emu -j SECCOLO --index 1
> iptables: No chain/target/match by that name.
>
> Here is my active modules matching colo:
>
> root@colob-HP-Compaq-6005-Pro-MT-PC:~# lsmod | grep -i colo
> xt_SECCOLO 16384  1
> nf_conntrack_colo  16384  2 xt_SECCOLO
> x_tables   36864  8 xt_physdev,ip6table_mangle,ip_
> tables,xt_SECCOLO,xt_tcpudp,iptable_filter,iptable_mangle,ip6_tables
> nf_conntrack  106496  4 xt_SECCOLO,nf_nat,nf_
> conntrack_colo,nf_conntrack_ipv4
>
> So i was looking in the iptables and this really looks like the source of
> the problem.
>
> Sadi.
>
> On Tue, Nov 8, 2016 at 5:57 PM, Konrad Rzeszutek Wilk <
> konrad.w...@oracle.com> wrote:
>
>> > entered forwarding state
>> > Nov  7 18:10:30 colob NetworkManager[907]:   (vif2.0-emu):
>> enslaved
>> > to br0
>> > Nov  7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup: brctl
>> addif
>> > br0 vif2.0-emu failed
>>
>>
>> How come this failed?
>>
>> > Nov  7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup:
>> iptables -t
>> > mangle -D PREROUTING -m physdev --physdev-in vif2.0-emu -j SECCOLO
>> --index
>> > 1 failed
>>
>> Ah b/c of this. Are there any errors of what exactly failed?
>>
>
>
>
> --
> Sadi.
>



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

Re: [Xen-devel] [OSSTEST PATCH v6 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

[Ian Jackson]

We just discussed this IRL, and here are our conclusions:

Ian Jackson writes ("Re: [OSSTEST PATCH v6 3/3] Create a flight to test 
OpenStack with xen-unstable and libvirt"):
> Do we intend to try to gate xen-unstable on this eventually ?

Maybe eventually, but not right now.

> AFAICT you pull in new versions of all the subtrees willy-nilly.
> Isn't that likely to cause regressions ?

The openstack components other than nova are already tested by the
openstack upstream CI loop, whose output we are going to be
consuming, so regressions there will be less frequent.  They might
block our openstack-nova push gate occasionally, but it would unblock
when upstream fixed it.

Your proposed arrangements would allow the bisector to work, across
all the relevant trees.

The obvious alternative would be to set up a push gate for each
openstack subtree, which obviously not something we want to do.

There is a less-obvious alternative, to have cr-daily-branch fetch all
the openstack trees' versions together, and then push them together to
a multitude of push-gate-output branches.  This would be fairly fiddly
work in cr-daily-branch, and introduce (yet another) a new special
case there.  It's not clear that we want to do this at all.
Definitely neither of us want to do that *now*.

So overall the conclusion is that your approach is OK.

> > +: ${TREE_OPENSTACK_CINDER:=$GIT_OPENSTACK_ORG/openstack/cinder.git}
> > +: ${TREE_OPENSTACK_DEVSTACK:=$GIT_OPENSTACK_ORG/openstack-dev/devstack.git}
> > +: ${TREE_OPENSTACK_GLANCE:=$GIT_OPENSTACK_ORG/openstack/glance.git}
> > +: ${TREE_OPENSTACK_KEYSTONE:=$GIT_OPENSTACK_ORG/openstack/keystone.git}
> > +: ${TREE_OPENSTACK_NOVA:=$GIT_OPENSTACK_ORG/openstack/nova.git}
> 
> Regardless of your answer to the above, this and the part in
> make-flight could really do with some metaprogramming.

Anthony is going to go and write some shell functions.

Ian.

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

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

[osstest service owner]

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

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

Last test of basis   102050  2016-11-08 20:54:26 Z0 days
Testing same since   102065  2016-11-09 10:17:52 Z0 days1 attempts


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

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



sg-report-flight on osstest.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=c3c9892c3b4dafd1d0ccdc8e5e017d80e8c4361e
+ . ./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 
c3c9892c3b4dafd1d0ccdc8e5e017d80e8c4361e
+ branch=ovmf
+ revision=c3c9892c3b4dafd1d0ccdc8e5e017d80e8c4361e
+ . ./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
+ '[' xc3c9892c3b4dafd1d0ccdc8e5e017d80e8c4361e = 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] Xen, EFI and kexec

[Konrad Rzeszutek Wilk]

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

CC-ing Daniel.
> issue.

> 
> I'm also not sure if the EFI virtual address mode will be an issue or
> not yet. (i.e. Xen uses the physical address mode, but is that usable
> after the first linux setup the virtual mode).

OK, then that ought to work.
> 
> Is there anything else I overlooked that will be an issue ?

Buggy BIOSes?
> 
> Is this a use case worth supporting ? (Obviously I think so, but I'm biased 
> :p)

I think the idea of kexecing Xen is quite neat. You could (long-term with
lots of careful work), restart Xen without bringing down the guests.

(Yeah, I know, it sounds insane, but then I am livepatching an hypervisor
so I already have a foot in the looney bin)
> 
> And if I'm looking at it the wrong way, what way should I be looking at it ?
> 
> 
> Cheers,
> 
> Sylvain Munaut
> 
> 
> PS: I'm currently making my way through the 2000+ pages of the EFI
> specs so I probably got some things wrong above ...
> 
> ___
> 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] [OSSTEST PATCH v6 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

[Ian Jackson]

Anthony PERARD writes ("[OSSTEST PATCH v6 3/3] Create a flight to test 
OpenStack with xen-unstable and libvirt"):
> This patch should create a flight "openstack-nova", with those jobs:
>   build-amd64
>   build-amd64-xsm
>   build-amd64-pvops
>   build-amd64-libvirt
>   test-amd64-amd64-devstack
>   test-amd64-amd64-devstack-xsm

Do we intend to try to gate xen-unstable on this eventually ?

AFAICT you pull in new versions of all the subtrees willy-nilly.
Isn't that likely to cause regressions ?

> +: ${TREE_OPENSTACK_CINDER:=$GIT_OPENSTACK_ORG/openstack/cinder.git}
> +: ${TREE_OPENSTACK_DEVSTACK:=$GIT_OPENSTACK_ORG/openstack-dev/devstack.git}
> +: ${TREE_OPENSTACK_GLANCE:=$GIT_OPENSTACK_ORG/openstack/glance.git}
> +: ${TREE_OPENSTACK_KEYSTONE:=$GIT_OPENSTACK_ORG/openstack/keystone.git}
> +: ${TREE_OPENSTACK_NOVA:=$GIT_OPENSTACK_ORG/openstack/nova.git}

Regardless of your answer to the above, this and the part in
make-flight could really do with some metaprogramming.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH v6 2/3] ts-openstack-tempest: Run Tempest to check OpenStack

[Ian Jackson]

Anthony PERARD writes ("[OSSTEST PATCH v6 2/3] ts-openstack-tempest: Run 
Tempest to check OpenStack"):
> This script runs the OpenStack integration test suite, Tempest.
...
> +  push @ignored_tests,
> +  "^\Q$volume_boot_pattern.test_volume_boot_pattern\E";
> +  push @ignored_tests,
> +  "^\Q$volume_boot_pattern.test_create_ebs_image_and_check_boot\E";
> +  push @ignored_tests,
> +  "^\Q$shelve_instance.test_shelve_volume_backed_instance\E";
> +
> +  # Those tests access a volume through iSCSI. This does not work when both 
> the
> +  # server and client of iSCSI are on the same Xen host, Linux 4.0 is the 
> first
> +  # Linux to have a fix.
> +  push @ignored_tests,
> +  "^\Q${volume_boot_pattern}V2.test_volume_boot_pattern\E";
> +  push @ignored_tests,
> +  "^\Q${volume_boot_pattern}V2.test_create_ebs_image_and_check_boot\E";
> +
> +  # This regex below select the tests to run and exclude the ones marked as
> +  # slow as well as the explicit tests listed above.
> +  # It is based on the one that can be found in tempest.git/tox.ini
> +  # in the section [testenv:full].
> +  my $ignored_tests = join("|", @ignored_tests);
> +  my $regex =
> +  
> "(?!.*\\[.*\\bslow\\b.*\\]|$ignored_tests)(^tempest\\.(api|scenario|thirdparty))";

This is all quite nightmarish.  I don't have a better suggestion,
though.

Acked-by: Ian Jackson 

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH v6 1/3] ts-openstack-deploy: Deploy OpenStack on a host with devstack

[Ian Jackson]

Anthony PERARD writes ("[OSSTEST PATCH v6 1/3] ts-openstack-deploy: Deploy 
OpenStack on a host with devstack"):
> This script installs any necessary packages and clones all of the OpenStack
> trees which are used by devstack to deploy OpenStack.

Thanks for this contribution.  I have no knowledge of OpenStack so I
can't really know whether what you are doing here is right, but it
looks basically OK to me.


I have some minor comments.  The most annoying one will be that I
would like you to file bugs in appropriate upstream bug trackers
(OpenStack or Debian), for each of the the workarounds.  Sorry...



> +sub packages () {
> +  # Install open-iscsi ahead of devstack ...
> +  target_install_packages($ho, qw(git sudo open-iscsi));

The indentation is a bit odd.  I won't insist you fix it, but usual
indent in osstest is 4 spaces.

> +  # ... and start open-iscsi to have /etc/iscsi/initiatorname.iscsi
> +  # generated. This is done on install on Ubuntu.
> +  target_cmd_root($ho, 'service open-iscsi start');

This looks like it is a workaround.  Can you please
 1. file a bug against Debian
 2. quote the bug number in your code
 3. make the workaround conditional on the suite

> +sub checkout () {
> +  prepbuilddirs();
> +  build_clone($ho, 'cinder', $builddir, 'cinder');
> +  build_clone($ho, 'devstack', $builddir, 'devstack');
> +  build_clone($ho, 'glance', $builddir, 'glance');
> +  build_clone($ho, 'keystone', $builddir, 'keystone');
> +  build_clone($ho, 'nova', $builddir, 'nova');
> +  build_clone($ho, 'requirements', $builddir, 'requirements');
> +  build_clone($ho, 'tempest', $builddir, 'tempest');

This could profitably be reformatted with extra whitespace so that the
columns line up.  (Again I won't insist on this.)

> +LOGFILE=\$DEST/logs/stack.sh.log
> +# stackrc set this but don't take \$DEST into account

ITYM "sets this but doesn't take".

> +  # stackrc does not take $DEST from local.conf into account, so fix it here
> +  target_editfile($ho, "$builddir/devstack/stackrc", sub {

This is a workround for an upstream bug ?  Is there a corresponding
upstream bug report ?  Should there be ?

In osstest I like to reduce, where possible, unconditional workarounds
for bugs in the software under test.  In general there should be an
upstream bug report, referred to in the osstest code.  Ideally there
would be a way to automatically disable the workaround eventually,
although that's probably too difficult here.

> +  while () {
> +if (m/^DEST=\/opt\/stack$/) {
> +  s/DEST=\/opt\/stack/DEST=$builddir/;

Using a regexp delimiter other than // would make this much clearer.

  +if (m{^DEST=/opt/stack$}) {
  +if (m#^DEST=/opt/stack$}) {
  +  s{DEST=/opt/stack}{DEST=$builddir};
  +  s#DEST=/opt/stack#DEST=$builddir#;

For example.  Take your pick.  I see later you used % % which is also
OK, although it is not the most idiomatic Perl (since the human reader
will tend to see % as a reference to a hash).

> +  # libvirt is already installed, but not as a package, so avoid 
> installation of
> +  # the libvirt package with devstack
> +  target_editfile($ho, "$builddir/devstack/files/debs/nova", sub {
> +  while () {
> +next if m/.*libvirt.*/;
> +print EO or die $!;
> +  }
> +  });
> +  target_editfile($ho, 
> "$builddir/devstack/lib/nova_plugins/functions-libvirt", sub {
> +  while () {
> +next if m/install_package.*libvirt.*/;
> +print EO or die $!;
> +  }
> +  });

These look like they ought to come with an upstream wishlist bug
asking for a front-door way to achieve this.

> +  # devstack blindly assume that systemd is used if systemctl is present
> +  target_editfile($ho, "$builddir/devstack/functions-common", sub {
> +  while () {
> +if (m%\[ -x /bin/systemctl%) {
> +  s%\[ -x /bin/systemctl \]%false%
> +}
> +print EO or die $!;
> +  }
> +  });

Again, an upstream bug.

> +  # OpenStack needs access to libvirt from a user.
> +  target_cmd_root($ho, < +if ! getent group libvirt >/dev/null; then
> +  groupadd libvirt

You should probably use "addgroup --system".  That is idempotent, so
you do not need the test.

> +# For unknown reason, restart fail when done by devstack
> +# so stop the service here, and devstack will start it.

Again, upstream bug.

> +  # devstack is going to setup the host, install some dependency.
> +  target_putfilecontents_root_stash($ho, 100, 
> < +  target_putfilecontents_root_stash($ho, 60, tgt_init(), "/etc/init.d/tgt");
> +  target_cmd_root($ho, < +chmod +x /etc/init.d/tgt
> +END
> +}

You may find it better to combine some of these target_cmd_root
stanzas.  That would reduce the overall amount of clutter in the perl
code.

> +# This is missing from Debian but 

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

[Boris Ostrovsky]

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

Reviewed-by: Boris Ostrovsky 

(with or without changes suggested by Jan)


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

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

[Roger Pau Monné]

Hello,

I'm attaching a draft of how a PVHv2 Dom0 is supposed to interact with 
physical devices, and what needs to be done inside of Xen in order to 
achieve it. Current draft is RFC because I'm quite sure I'm missing bits 
that should be written down here. So far I've tried to describe what my 
previous series attempted to do by adding a bunch of IO and memory space 
handlers.

Please note that this document only applies to PVHv2 Dom0, it is not 
applicable to untrusted domains that will need more handlers in order to 
secure Xen and other domains running on the same system. The idea is that 
this can be expanded to untrusted domains also in the long term, thus having 
a single set of IO and memory handlers for passed-through devices.

Roger.

---8<---

This document describes how a PVHv2 Dom0 is supposed to interact with physical
devices.

Architecture


Purpose
---

Previous Dom0 implementations have always used PIRQs (physical interrupts
routed over event channels) in order to receive events from physical devices.
This prevents Dom0 form taking advantage of new hardware virtualization
features, like posted interrupts or hardware virtualized local APIC. Also the
current device memory management in the PVH Dom0 implementation is lacking,
and might not support devices that have memory regions past the 4GB 
boundary.

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

In order to improve the mapping of device memory areas, Xen will have to
know of those devices in advance (before Dom0 tries to interact with them)
so that the memory BARs will be properly mapped into Dom0 memory map.

The following document describes the proposed interface and implementation
of all the logic needed in order to achieve the functionality described 
above.

MMIO areas
==

Overview


On x86 systems certain regions of memory might be used in order to manage
physical devices on the system. Access to this areas is critical for a
PVH Dom0 in order to operate properly. Unlike previous PVH Dom0 implementation
(PVHv1) that was setup with identity mappings of all the holes and reserved
regions found in the memory map, this new implementation intents to map only
what's actually needed by the Dom0.

Low 1MB
---

When booted with a legacy BIOS, the low 1MB contains firmware related data
that should be identity mapped to the Dom0. This include the EBDA, video
memory and possibly ROMs. All non RAM regions below 1MB will be identity
mapped to the Dom0 so that it can access this data freely.

ACPI regions


ACPI regions will be identity mapped to the Dom0, this implies regions with
type 3 and 4 in the e820 memory map. Also, since some BIOS report incorrect
memory maps, the top-level tables discovered by Xen (as listed in the
{X/R}SDT) that are not on RAM regions will be mapped to Dom0.

PCI memory BARs
---

PCI devices discovered by Xen will have it's BARs scanned in order to detect
memory BARs, and those will be identity mapped to Dom0. Since BARs can be
freely moved by the Dom0 OS by writing to the appropriate PCI config space
register, Xen must trap those accesses and unmap the previous region and
map the new one as set by Dom0.

Limitations
---

 - Xen needs to be aware of any PCI device before Dom0 tries to interact with
   it, so that the MMIO regions are properly mapped.

Interrupt management


Overview


On x86 systems there are tree different mechanisms that can be used in order
to deliver interrupts: IO APIC, MSI and MSI-X. Note that each device might
support different methods, but those are never active at the same time.

Legacy PCI interrupts
-

The only way to deliver legacy PCI interrupts to PVHv2 guests is using the
IO APIC, PVHv2 domains don't have an emulated PIC. As a consequence the ACPI
_PIC method must be set to APIC mode by the Dom0 OS.

Xen will always provide a single IO APIC, that will match the number of
possible GSIs of the underlying hardware. This is possible because ACPI
uses a system cookie in order to name interrupts, so the IO APIC device ID
or pin number is not used in _PTR methods.

XXX: is it possible to have more than 256 GSIs?

The binding between the underlying physical interrupt and the emulated
interrupt is performed when unmasking an IO APIC PIN, so writes to the
IOREDTBL registers that unset the mask bit will trigger this binding
and enable the interrupt.

MSI Interrupts
--

MSI interrupts are setup using the PCI config space, either the IO ports
or the memory mapped configuration area. This means that both spaces should
be trapped by Xen, in order to detect accesses to these 

Re: [Xen-devel] [linux-3.10 test] 102032: regressions - FAIL

[Ian Jackson]

osstest service owner writes ("[linux-3.10 test] 102032: regressions - FAIL"):
> flight 102032 linux-3.10 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/102032/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl   6 xen-boot   fail REGR. vs. 100648

Etc.

The system seems to boot normally but fails to find the disk
controller.  I think this must mean that the disk controller is simply
not in Linux 3.10, which would be quite plausible.  3.4 is failing
too.

I will configure the noblings to reject 3.10 and earlier.

Ian.

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

Re: [Xen-devel] [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Boris Ostrovsky]

On 11/09/2016 10:04 AM, Andrew Cooper wrote:
> On 09/11/16 14:39, Boris Ostrovsky wrote:
>> This domctl is called when a VCPU is hot-(un)plugged to a guest (via
>> 'xl vcpu-set'). While this currently is only intended to be needed by
>> PVH guests we will call this domctl for all (x86) guests for consistency.
>>
>> Signed-off-by: Boris Ostrovsky 
>> Acked-by: Daniel De Graaf 
>> ---
>> Changes in v2:
>> * Added comment in arch_do_domctl() stating that the domctl is only required
>>   for PVH guests
> I am not happy with this change until we understand why it is needed.
>
> Are we genuinely saying that there is no current enforcement in the
> PV-hotplug mechanism?

That's right. Don't call setup_cpu_watcher() in Linux and you will be
running with maxvcpus.

>
>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>> index 2a2fe04..b736d4c 100644
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1430,6 +1430,23 @@ long arch_do_domctl(
>>  }
>>  break;
>>  
>> +case XEN_DOMCTL_set_avail_vcpus:
>> +{
>> +unsigned int num = domctl->u.avail_vcpus.num;
>> +
>> +/*
>> + * This is currently only needed by PVH guests (but
>> + * any guest is free to make this call).
>> + */
>> +ret = -EINVAL;
>> +if ( num > d->max_vcpus )
>> +break;
>> +
>> +d->arch.avail_vcpus = num;
>> +ret = 0;
>> +break;
>> +}
> What do you actually mean by "avail_vcpus"?  What happens if a vcpu
> higher than the new number is currently online and running?  What
> happens to the already-existing vcpus-at-startup value?

It shouldn't happen: we set avail_vcpus at domain creation time to
vcpus-at-startup.

The name is not great. It would have been better to have it online_vcpus
but that usually means that VPF_down is set (which can happen, for
example, when the guest offlines a VCPU).

-boris



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

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

[Boris Ostrovsky]

On 11/09/2016 09:59 AM, Andrew Cooper wrote:
>
>> diff --git a/xen/include/public/hvm/ioreq.h b/xen/include/public/hvm/ioreq.h
>> index 2e5809b..e3fa704 100644
>> --- a/xen/include/public/hvm/ioreq.h
>> +++ b/xen/include/public/hvm/ioreq.h
>> @@ -24,6 +24,8 @@
>>  #ifndef _IOREQ_H_
>>  #define _IOREQ_H_
>>  
>> +#include "hvm_info_table.h" /* HVM_MAX_VCPUS */
>> +
>>  #define IOREQ_READ  1
>>  #define IOREQ_WRITE 0
>>  
>> @@ -124,6 +126,17 @@ typedef struct buffered_iopage buffered_iopage_t;
>>  #define ACPI_GPE0_BLK_ADDRESSACPI_GPE0_BLK_ADDRESS_V0
>>  #define ACPI_GPE0_BLK_LENACPI_GPE0_BLK_LEN_V0
>>  
>> +#define ACPI_PM1A_EVT_BLK_LEN0x04
>> +#define ACPI_PM1A_CNT_BLK_LEN0x02
>> +#define ACPI_PM_TMR_BLK_LEN  0x04
>> +
>> +/* Location of online VCPU bitmap. */
>> +#define ACPI_CPU_MAP 0xaf00
>> +#define ACPI_CPU_MAP_LEN ((HVM_MAX_VCPUS / 8) + \
>> +  ((HVM_MAX_VCPUS & 7) ? 1 : 0))
>> +#if ACPI_CPU_MAP + ACPI_CPU_MAP_LEN >= ACPI_GPE0_BLK_ADDRESS_V1
>> +#error "ACPI_CPU_MAP is too big"
>> +#endif
> Why is this in ioreq.h?  It has nothing to do with ioreq's.
>
> The current ACPI bits in here are to do with the qemu ACPI interface,
> not the Xen ACPI interface.
>
> Also, please can we avoid hard-coding the location of the map in the
> hypervisor ABI.  These constants make it impossible to ever extend the
> number of HVM vcpus at a future date.

The first three logically belong here because corresponding blocks'
addresses are defined right above.

ACPI_CPU_MAP has to be seen by both the toolstack (libacpi) and the
hypervisor (and qemu as well, although it is defined as
PIIX4_CPU_HOTPLUG_IO_BASE).

Where do you think it should go then?

-boris



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

Re: [Xen-devel] [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Andrew Cooper]

On 09/11/16 14:39, Boris Ostrovsky wrote:
> This domctl is called when a VCPU is hot-(un)plugged to a guest (via
> 'xl vcpu-set'). While this currently is only intended to be needed by
> PVH guests we will call this domctl for all (x86) guests for consistency.
>
> Signed-off-by: Boris Ostrovsky 
> Acked-by: Daniel De Graaf 
> ---
> Changes in v2:
> * Added comment in arch_do_domctl() stating that the domctl is only required
>   for PVH guests

I am not happy with this change until we understand why it is needed.

Are we genuinely saying that there is no current enforcement in the
PV-hotplug mechanism?

> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index 2a2fe04..b736d4c 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1430,6 +1430,23 @@ long arch_do_domctl(
>  }
>  break;
>  
> +case XEN_DOMCTL_set_avail_vcpus:
> +{
> +unsigned int num = domctl->u.avail_vcpus.num;
> +
> +/*
> + * This is currently only needed by PVH guests (but
> + * any guest is free to make this call).
> + */
> +ret = -EINVAL;
> +if ( num > d->max_vcpus )
> +break;
> +
> +d->arch.avail_vcpus = num;
> +ret = 0;
> +break;
> +}

What do you actually mean by "avail_vcpus"?  What happens if a vcpu
higher than the new number is currently online and running?  What
happens to the already-existing vcpus-at-startup value?

~Andrew

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

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

[Andrew Cooper]

On 09/11/16 14:39, Boris Ostrovsky wrote:
> ACPI hotplug-related IO accesses (to GPE0 block) are handled
> by qemu for HVM guests. Since PVH guests don't have qemu these
> accesses will need to be procesed by the hypervisor.
>
> Because ACPI event model expects pm1a block to be present we
> need to have the hypervisor emulate it as well.
>
> Signed-off-by: Boris Ostrovsky 
> ---
> CC: Julien Grall 
> CC: Paul Durrant 
> ---
> Changes in v2:
> * Added public macros for ACPI CPU bitmap (at 0xaf00). Note: PRST
>   region shrinks from 32 bytes to 16 (when 128 VCPUs are
>   supported).
>
>
>  tools/libacpi/mk_dsdt.c  |  4 +++-
>  tools/libacpi/static_tables.c| 28 +++-
>  xen/include/asm-x86/hvm/domain.h |  6 ++
>  xen/include/public/arch-arm.h| 11 ---
>  xen/include/public/hvm/ioreq.h   | 13 +
>  5 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
> index 4ae68bc..2b8234d 100644
> --- a/tools/libacpi/mk_dsdt.c
> +++ b/tools/libacpi/mk_dsdt.c
> @@ -19,6 +19,7 @@
>  #include 
>  #if defined(__i386__) || defined(__x86_64__)
>  #include 
> +#include 
>  #elif defined(__aarch64__)
>  #include 
>  #endif
> @@ -244,7 +245,8 @@ int main(int argc, char **argv)
>  #endif
>  
>  /* Operation Region 'PRST': bitmask of online CPUs. */
> -stmt("OperationRegion", "PRST, SystemIO, 0xaf00, 32");
> +stmt("OperationRegion", "PRST, SystemIO, 0x%x, %d",
> +ACPI_CPU_MAP, ACPI_CPU_MAP_LEN);
>  push_block("Field", "PRST, ByteAcc, NoLock, Preserve");
>  indent(); printf("PRS, %u\n", max_cpus);
>  pop_block();
> diff --git a/tools/libacpi/static_tables.c b/tools/libacpi/static_tables.c
> index 617bf68..413abcc 100644
> --- a/tools/libacpi/static_tables.c
> +++ b/tools/libacpi/static_tables.c
> @@ -20,6 +20,8 @@
>   * Firmware ACPI Control Structure (FACS).
>   */
>  
> +#define ACPI_REG_BIT_OFFSET0
> +
>  struct acpi_20_facs Facs = {
>  .signature = ACPI_2_0_FACS_SIGNATURE,
>  .length= sizeof(struct acpi_20_facs),
> @@ -30,14 +32,6 @@ struct acpi_20_facs Facs = {
>  /*
>   * Fixed ACPI Description Table (FADT).
>   */
> -
> -#define ACPI_PM1A_EVT_BLK_BIT_WIDTH 0x20
> -#define ACPI_PM1A_EVT_BLK_BIT_OFFSET0x00
> -#define ACPI_PM1A_CNT_BLK_BIT_WIDTH 0x10
> -#define ACPI_PM1A_CNT_BLK_BIT_OFFSET0x00
> -#define ACPI_PM_TMR_BLK_BIT_WIDTH   0x20
> -#define ACPI_PM_TMR_BLK_BIT_OFFSET  0x00
> -
>  struct acpi_20_fadt Fadt = {
>  .header = {
>  .signature= ACPI_2_0_FADT_SIGNATURE,
> @@ -56,9 +50,9 @@ struct acpi_20_fadt Fadt = {
>  .pm1a_cnt_blk = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
>  .pm_tmr_blk = ACPI_PM_TMR_BLK_ADDRESS_V1,
>  .gpe0_blk = ACPI_GPE0_BLK_ADDRESS_V1,
> -.pm1_evt_len = ACPI_PM1A_EVT_BLK_BIT_WIDTH / 8,
> -.pm1_cnt_len = ACPI_PM1A_CNT_BLK_BIT_WIDTH / 8,
> -.pm_tmr_len = ACPI_PM_TMR_BLK_BIT_WIDTH / 8,
> +.pm1_evt_len = ACPI_PM1A_EVT_BLK_LEN,
> +.pm1_cnt_len = ACPI_PM1A_CNT_BLK_LEN,
> +.pm_tmr_len = ACPI_PM_TMR_BLK_LEN,
>  .gpe0_blk_len = ACPI_GPE0_BLK_LEN_V1,
>  
>  .p_lvl2_lat = 0x0fff, /* >100,  means we do not support C2 state */
> @@ -79,22 +73,22 @@ struct acpi_20_fadt Fadt = {
>  
>  .x_pm1a_evt_blk = {
>  .address_space_id= ACPI_SYSTEM_IO,
> -.register_bit_width  = ACPI_PM1A_EVT_BLK_BIT_WIDTH,
> -.register_bit_offset = ACPI_PM1A_EVT_BLK_BIT_OFFSET,
> +.register_bit_width  = ACPI_PM1A_EVT_BLK_LEN * 8,
> +.register_bit_offset = ACPI_REG_BIT_OFFSET,
>  .address = ACPI_PM1A_EVT_BLK_ADDRESS_V1,
>  },
>  
>  .x_pm1a_cnt_blk = {
>  .address_space_id= ACPI_SYSTEM_IO,
> -.register_bit_width  = ACPI_PM1A_CNT_BLK_BIT_WIDTH,
> -.register_bit_offset = ACPI_PM1A_CNT_BLK_BIT_OFFSET,
> +.register_bit_width  = ACPI_PM1A_CNT_BLK_LEN * 8,
> +.register_bit_offset = ACPI_REG_BIT_OFFSET,
>  .address = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
>  },
>  
>  .x_pm_tmr_blk = {
>  .address_space_id= ACPI_SYSTEM_IO,
> -.register_bit_width  = ACPI_PM_TMR_BLK_BIT_WIDTH,
> -.register_bit_offset = ACPI_PM_TMR_BLK_BIT_OFFSET,
> +.register_bit_width  = ACPI_PM_TMR_BLK_LEN * 8,
> +.register_bit_offset = ACPI_REG_BIT_OFFSET,
>  .address = ACPI_PM_TMR_BLK_ADDRESS_V1,
>  }
>  };
> diff --git a/xen/include/asm-x86/hvm/domain.h 
> b/xen/include/asm-x86/hvm/domain.h
> index f34d784..f492a2b 100644
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -87,6 +87,12 @@ struct hvm_domain {
>  } ioreq_server;
>  struct hvm_ioreq_server *default_ioreq_server;
>  
> +/* PVH guests */
> +struct {
> +uint8_t pm1a[ACPI_PM1A_EVT_BLK_LEN];
> +uint8_t 

Re: [Xen-devel] [PATCH v2 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

[Paul Durrant]

> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 09 November 2016 14:40
> To: xen-devel@lists.xen.org
> Cc: jbeul...@suse.com; Andrew Cooper ;
> Wei Liu ; Ian Jackson ; Roger
> Pau Monne ; Boris Ostrovsky
> ; Paul Durrant 
> Subject: [PATCH v2 08/11] pvh/acpi: Handle ACPI accesses for PVH guests
> 
> Signed-off-by: Boris Ostrovsky 
> ---
> CC: Paul Durrant 

Reviewed-by: Paul Durrant 

> ---
> Changes in v2:
> * Use 'true/false' values for bools
> 
> 
>  xen/arch/x86/hvm/ioreq.c | 72
> 
>  1 file changed, 72 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index e6ff48f..3ef01cf 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -1383,6 +1383,78 @@ static int hvm_access_cf8(
>  static int acpi_ioaccess(
>  int dir, unsigned int port, unsigned int bytes, uint32_t *val)
>  {
> +unsigned int i;
> +unsigned int bits = bytes * 8;
> +unsigned int idx = port & 3;
> +uint8_t *reg = NULL;
> +bool is_cpu_map = false;
> +struct domain *currd = current->domain;
> +
> +BUILD_BUG_ON((ACPI_PM1A_EVT_BLK_LEN != 4) ||
> + (ACPI_GPE0_BLK_LEN_V1 != 4));
> +
> +if ( has_ioreq_cpuhp(currd) )
> +return X86EMUL_UNHANDLEABLE;
> +
> +switch (port)
> +{
> +case ACPI_PM1A_EVT_BLK_ADDRESS_V1 ...
> +(ACPI_PM1A_EVT_BLK_ADDRESS_V1 + ACPI_PM1A_EVT_BLK_LEN - 1):
> +reg = currd->arch.hvm_domain.acpi_io.pm1a;
> +break;
> +case ACPI_GPE0_BLK_ADDRESS_V1 ...
> +(ACPI_GPE0_BLK_ADDRESS_V1 + ACPI_GPE0_BLK_LEN_V1 - 1):
> +reg = currd->arch.hvm_domain.acpi_io.gpe;
> +break;
> +case ACPI_CPU_MAP ... (ACPI_CPU_MAP + ACPI_CPU_MAP_LEN - 1):
> +is_cpu_map = true;
> +break;
> +default:
> +return X86EMUL_UNHANDLEABLE;
> +}
> +
> +if ( bytes == 0 )
> +return X86EMUL_OKAY;
> +
> +if ( dir == IOREQ_READ )
> +{
> +*val &= ~((1U << bits) - 1);
> +
> +if ( is_cpu_map )
> +{
> +unsigned int first_bit, last_bit;
> +
> +first_bit = (port - ACPI_CPU_MAP) * 8;
> +last_bit = min(currd->arch.avail_vcpus, first_bit + bits);
> +for ( i = first_bit; i < last_bit; i++ )
> +*val |= (1U << (i - first_bit));
> +}
> +else
> +memcpy(val, [idx], bytes);
> +}
> +else
> +{
> +if ( is_cpu_map )
> +/*
> + * CPU map is only read by DSDT's PRSC method and should never
> + * be written by a guest.
> + */
> +return X86EMUL_UNHANDLEABLE;
> +
> +/* Write either status or enable reegister. */
> +if ( (bytes > 2) || ((bytes == 2) && (port & 1)) )
> +return X86EMUL_UNHANDLEABLE;
> +
> +if ( idx < 2 ) /* status, write 1 to clear. */
> +{
> +reg[idx] &= ~(*val & 0xff);
> +if ( bytes == 2 )
> +reg[idx + 1] &= ~((*val >> 8) & 0xff);
> +}
> +else   /* enable */
> +memcpy([idx], val, bytes);
> +}
> +
>  return X86EMUL_OKAY;
>  }
> 
> --
> 2.7.4


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

Re: [Xen-devel] [PATCH v2 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses

[Paul Durrant]

> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 09 November 2016 14:40
> To: xen-devel@lists.xen.org
> Cc: jbeul...@suse.com; Andrew Cooper ;
> Wei Liu ; Ian Jackson ; Roger
> Pau Monne ; Boris Ostrovsky
> ; Paul Durrant 
> Subject: [PATCH v2 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO
> accesses
> 
> PVH guests will have ACPI accesses emulated by the hypervisor
> as opposed to QEMU (as is the case for HVM guests)
> 
> Support for IOREQ server emulation of CPU hotplug is indicated
> by XEN_X86_EMU_IOREQ_CPUHP flag.
> 
> Logic for the handler will be provided by a later patch.
> 
> Signed-off-by: Boris Ostrovsky 
> ---
> CC: Paul Durrant 
> ---
> Changes in v2:
> * Introduce XEN_X86_EMU_IOREQ_CPUHP, don't set
> HVM_PARAM_NR_IOREQ_SERVER_PAGES
>   for PVH guests

Is 'CPUHP' the right name? The same GPE block could be used for DIMM and PCI 
hotplug, right? That aside...

Reviewed-by: Paul Durrant 

> * Register IO hadler for PVH from hvm_ioreq_init()
> 
>  xen/arch/x86/hvm/ioreq.c  | 18 ++
>  xen/include/asm-x86/domain.h  |  2 ++
>  xen/include/public/arch-x86/xen.h |  5 -
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index d2245e2..e6ff48f 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -1380,6 +1380,12 @@ static int hvm_access_cf8(
>  return X86EMUL_UNHANDLEABLE;
>  }
> 
> +static int acpi_ioaccess(
> +int dir, unsigned int port, unsigned int bytes, uint32_t *val)
> +{
> +return X86EMUL_OKAY;
> +}
> +
>  void hvm_ioreq_init(struct domain *d)
>  {
>  spin_lock_init(>arch.hvm_domain.ioreq_server.lock);
> @@ -1387,6 +1393,18 @@ void hvm_ioreq_init(struct domain *d)
> 
>  if ( !is_pvh_domain(d) )
>  register_portio_handler(d, 0xcf8, 4, hvm_access_cf8);
> +
> +if ( !has_ioreq_cpuhp(d) )
> +{
> +/* Online CPU map, see DSDT's PRST region. */
> +register_portio_handler(d, ACPI_CPU_MAP,
> +ACPI_CPU_MAP_LEN, acpi_ioaccess);
> +
> +register_portio_handler(d, ACPI_GPE0_BLK_ADDRESS_V1,
> +ACPI_GPE0_BLK_LEN_V1, acpi_ioaccess);
> +register_portio_handler(d, ACPI_PM1A_EVT_BLK_ADDRESS_V1,
> +ACPI_PM1A_EVT_BLK_LEN, acpi_ioaccess);
> +}
>  }
> 
>  /*
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index a279e4a..7aa736c 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -431,6 +431,8 @@ struct arch_domain
>  #define has_vvga(d)(!!((d)->arch.emulation_flags &
> XEN_X86_EMU_VGA))
>  #define has_viommu(d)  (!!((d)->arch.emulation_flags &
> XEN_X86_EMU_IOMMU))
>  #define has_vpit(d)(!!((d)->arch.emulation_flags &
> XEN_X86_EMU_PIT))
> +#define has_ioreq_cpuhp(d) (!!((d)->arch.emulation_flags & \
> +   XEN_X86_EMU_IOREQ_CPUHP))
> 
>  #define has_arch_pdevs(d)(!list_empty(&(d)->arch.pdev_list))
> 
> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-
> x86/xen.h
> index cdd93c1..350bc66 100644
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -283,12 +283,15 @@ struct xen_arch_domainconfig {
>  #define XEN_X86_EMU_IOMMU   (1U<<_XEN_X86_EMU_IOMMU)
>  #define _XEN_X86_EMU_PIT8
>  #define XEN_X86_EMU_PIT (1U<<_XEN_X86_EMU_PIT)
> +#define _XEN_X86_EMU_IOREQ_CPUHP9
> +#define XEN_X86_EMU_IOREQ_CPUHP
> (1U<<_XEN_X86_EMU_IOREQ_CPUHP)
> 
>  #define XEN_X86_EMU_ALL (XEN_X86_EMU_LAPIC |
> XEN_X86_EMU_HPET |  \
>   XEN_X86_EMU_PM | XEN_X86_EMU_RTC |  
> \
>   XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC |  
> \
>   XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU |   
> \
> - XEN_X86_EMU_PIT)
> + XEN_X86_EMU_PIT |   
> \
> + XEN_X86_EMU_IOREQ_CPUHP)
>  uint32_t emulation_flags;
>  };
>  #endif
> --
> 2.7.4


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

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

[Jan Beulich]

>>> On 09.11.16 at 15:28,  wrote:
> On 11/09/2016 01:17 PM, Jan Beulich wrote:
> On 09.11.16 at 10:42,  wrote:
>>> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>>> +{
>>> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>>> +
>>> +if ( vmcb->eventinj.fields.v )
>>> +return false;
>>> +
>>> +info->vector = vmcb->eventinj.fields.vector;
>>> +info->type = vmcb->eventinj.fields.type;
>>> +info->error_code = vmcb->eventinj.fields.errorcode;
>>> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
>> 
>> I'd prefer for this last part to be put into generic code (i.e. the
>> wrapper).
> 
> Actually, doing this:
> 
> static inline bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap 
> *info)
> {
> info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
> return hvm_funcs.get_pending_event(v, info);
> }
> 
> leads to "error: dereferencing pointer to incomplete type" about v->, so
> to do this an additional #include will be necessary. Is that acceptable?

Better make it an out-of-line function in hvm.c.

Jan


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

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

[Boris Ostrovsky]

On 11/09/2016 09:48 AM, Julien Grall wrote:
> Hi Boris,
>
> On 09/11/16 14:39, Boris Ostrovsky wrote:
>> diff --git a/xen/include/public/arch-arm.h
>> b/xen/include/public/arch-arm.h
>> index bd974fb..b793774 100644
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@ -383,6 +383,9 @@ typedef uint64_t xen_callback_t;
>>   * should instead use the FDT.
>>   */
>>
>> +/* Current supported guest VCPUs */
>> +#define GUEST_MAX_VCPUS 128
>> +
>>  /* Physical Address Space */
>>
>>  /*
>> @@ -410,6 +413,11 @@ typedef uint64_t xen_callback_t;
>>  #define GUEST_ACPI_BASE 0x2000ULL
>>  #define GUEST_ACPI_SIZE 0x0200ULL
>>
>> +/* Location of online VCPU bitmap. */
>> +#define ACPI_CPU_MAP 0xaf00
>> +#define ACPI_CPU_MAP_LEN ((GUEST_MAX_VCPUS / 8) + \
>> +  ((GUEST_MAX_VCPUS & 7) ? 1 : 0))
>> +
>
> I don't understand this change. PRST is not generated for ARM (see the
> return 0 in mk_dsdt a bit before).

Oh, right --- I missed it. Then this change needs to be dropped.

-boris

>
> In any case, I am expecting CPU hotplug to be handle via PSCI on ARM.
>
> Regards,
>


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

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

[Paul Durrant]

> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 09 November 2016 14:40
> To: xen-devel@lists.xen.org
> Cc: jbeul...@suse.com; Andrew Cooper ;
> Wei Liu ; Ian Jackson ; Roger
> Pau Monne ; Boris Ostrovsky
> ; Julien Grall ; Paul
> Durrant 
> Subject: [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests
> 
> ACPI hotplug-related IO accesses (to GPE0 block) are handled
> by qemu for HVM guests. Since PVH guests don't have qemu these
> accesses will need to be procesed by the hypervisor.
> 
> Because ACPI event model expects pm1a block to be present we
> need to have the hypervisor emulate it as well.
> 
> Signed-off-by: Boris Ostrovsky 
> ---
> CC: Julien Grall 
> CC: Paul Durrant 

Reviewed-by: Paul Durrant 

> ---
> Changes in v2:
> * Added public macros for ACPI CPU bitmap (at 0xaf00). Note: PRST
>   region shrinks from 32 bytes to 16 (when 128 VCPUs are
>   supported).
> 
> 
>  tools/libacpi/mk_dsdt.c  |  4 +++-
>  tools/libacpi/static_tables.c| 28 +++-
>  xen/include/asm-x86/hvm/domain.h |  6 ++
>  xen/include/public/arch-arm.h| 11 ---
>  xen/include/public/hvm/ioreq.h   | 13 +
>  5 files changed, 41 insertions(+), 21 deletions(-)
> 
> diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
> index 4ae68bc..2b8234d 100644
> --- a/tools/libacpi/mk_dsdt.c
> +++ b/tools/libacpi/mk_dsdt.c
> @@ -19,6 +19,7 @@
>  #include 
>  #if defined(__i386__) || defined(__x86_64__)
>  #include 
> +#include 
>  #elif defined(__aarch64__)
>  #include 
>  #endif
> @@ -244,7 +245,8 @@ int main(int argc, char **argv)
>  #endif
> 
>  /* Operation Region 'PRST': bitmask of online CPUs. */
> -stmt("OperationRegion", "PRST, SystemIO, 0xaf00, 32");
> +stmt("OperationRegion", "PRST, SystemIO, 0x%x, %d",
> +ACPI_CPU_MAP, ACPI_CPU_MAP_LEN);
>  push_block("Field", "PRST, ByteAcc, NoLock, Preserve");
>  indent(); printf("PRS, %u\n", max_cpus);
>  pop_block();
> diff --git a/tools/libacpi/static_tables.c b/tools/libacpi/static_tables.c
> index 617bf68..413abcc 100644
> --- a/tools/libacpi/static_tables.c
> +++ b/tools/libacpi/static_tables.c
> @@ -20,6 +20,8 @@
>   * Firmware ACPI Control Structure (FACS).
>   */
> 
> +#define ACPI_REG_BIT_OFFSET0
> +
>  struct acpi_20_facs Facs = {
>  .signature = ACPI_2_0_FACS_SIGNATURE,
>  .length= sizeof(struct acpi_20_facs),
> @@ -30,14 +32,6 @@ struct acpi_20_facs Facs = {
>  /*
>   * Fixed ACPI Description Table (FADT).
>   */
> -
> -#define ACPI_PM1A_EVT_BLK_BIT_WIDTH 0x20
> -#define ACPI_PM1A_EVT_BLK_BIT_OFFSET0x00
> -#define ACPI_PM1A_CNT_BLK_BIT_WIDTH 0x10
> -#define ACPI_PM1A_CNT_BLK_BIT_OFFSET0x00
> -#define ACPI_PM_TMR_BLK_BIT_WIDTH   0x20
> -#define ACPI_PM_TMR_BLK_BIT_OFFSET  0x00
> -
>  struct acpi_20_fadt Fadt = {
>  .header = {
>  .signature= ACPI_2_0_FADT_SIGNATURE,
> @@ -56,9 +50,9 @@ struct acpi_20_fadt Fadt = {
>  .pm1a_cnt_blk = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
>  .pm_tmr_blk = ACPI_PM_TMR_BLK_ADDRESS_V1,
>  .gpe0_blk = ACPI_GPE0_BLK_ADDRESS_V1,
> -.pm1_evt_len = ACPI_PM1A_EVT_BLK_BIT_WIDTH / 8,
> -.pm1_cnt_len = ACPI_PM1A_CNT_BLK_BIT_WIDTH / 8,
> -.pm_tmr_len = ACPI_PM_TMR_BLK_BIT_WIDTH / 8,
> +.pm1_evt_len = ACPI_PM1A_EVT_BLK_LEN,
> +.pm1_cnt_len = ACPI_PM1A_CNT_BLK_LEN,
> +.pm_tmr_len = ACPI_PM_TMR_BLK_LEN,
>  .gpe0_blk_len = ACPI_GPE0_BLK_LEN_V1,
> 
>  .p_lvl2_lat = 0x0fff, /* >100,  means we do not support C2 state */
> @@ -79,22 +73,22 @@ struct acpi_20_fadt Fadt = {
> 
>  .x_pm1a_evt_blk = {
>  .address_space_id= ACPI_SYSTEM_IO,
> -.register_bit_width  = ACPI_PM1A_EVT_BLK_BIT_WIDTH,
> -.register_bit_offset = ACPI_PM1A_EVT_BLK_BIT_OFFSET,
> +.register_bit_width  = ACPI_PM1A_EVT_BLK_LEN * 8,
> +.register_bit_offset = ACPI_REG_BIT_OFFSET,
>  .address = ACPI_PM1A_EVT_BLK_ADDRESS_V1,
>  },
> 
>  .x_pm1a_cnt_blk = {
>  .address_space_id= ACPI_SYSTEM_IO,
> -.register_bit_width  = ACPI_PM1A_CNT_BLK_BIT_WIDTH,
> -.register_bit_offset = ACPI_PM1A_CNT_BLK_BIT_OFFSET,
> +.register_bit_width  = ACPI_PM1A_CNT_BLK_LEN * 8,
> +.register_bit_offset = ACPI_REG_BIT_OFFSET,
>  .address = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
>  },
> 
>  .x_pm_tmr_blk = {
>  .address_space_id= ACPI_SYSTEM_IO,
> -.register_bit_width  = ACPI_PM_TMR_BLK_BIT_WIDTH,
> -.register_bit_offset = ACPI_PM_TMR_BLK_BIT_OFFSET,
> +.register_bit_width  = ACPI_PM_TMR_BLK_LEN * 8,
> +.register_bit_offset 

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

[Julien Grall]

Hi Boris,

On 09/11/16 14:39, Boris Ostrovsky wrote:

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index bd974fb..b793774 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -383,6 +383,9 @@ typedef uint64_t xen_callback_t;
  * should instead use the FDT.
  */

+/* Current supported guest VCPUs */
+#define GUEST_MAX_VCPUS 128
+
 /* Physical Address Space */

 /*
@@ -410,6 +413,11 @@ typedef uint64_t xen_callback_t;
 #define GUEST_ACPI_BASE 0x2000ULL
 #define GUEST_ACPI_SIZE 0x0200ULL

+/* Location of online VCPU bitmap. */
+#define ACPI_CPU_MAP 0xaf00
+#define ACPI_CPU_MAP_LEN ((GUEST_MAX_VCPUS / 8) + \
+  ((GUEST_MAX_VCPUS & 7) ? 1 : 0))
+


I don't understand this change. PRST is not generated for ARM (see the 
return 0 in mk_dsdt a bit before).


In any case, I am expecting CPU hotplug to be handle via PSCI on ARM.

Regards,

--
Julien Grall

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

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

[George John]

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

Thanks and regards,
George

On Tue, Nov 8, 2016 at 5:20 PM, Julien Grall  wrote:

>
>
> On 07/11/2016 16:39, George John wrote:
>
>> Hi,
>>
>
> Hello,
>
> (XEN) Freed 276kB init memory.
>> (XEN) traps.c:2505:d0v0 HSR=0x93820007 pc=0xc001d084 gva=0xe7804060
>> gpa=0x00e6160060
>>
>
> Looking at the log, DOM0 is trying to access an region that is not mapped
> (0x00e6160060).
>
> When booting Xen is going through the device tree and mapping to dom0 all
> the regions described. So it seems that this region is not present in the
> device tree.
>
> Which Linux kernel are you using? I would recommend you to try the latest
> as possible and use the device-tree provided in arch/arm/boot/dts/ to see
> if it solves the problem.
>
> Cheers,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses

[Boris Ostrovsky]

PVH guests will have ACPI accesses emulated by the hypervisor
as opposed to QEMU (as is the case for HVM guests)

Support for IOREQ server emulation of CPU hotplug is indicated
by XEN_X86_EMU_IOREQ_CPUHP flag.

Logic for the handler will be provided by a later patch.

Signed-off-by: Boris Ostrovsky 
---
CC: Paul Durrant 
---
Changes in v2:
* Introduce XEN_X86_EMU_IOREQ_CPUHP, don't set HVM_PARAM_NR_IOREQ_SERVER_PAGES
  for PVH guests
* Register IO hadler for PVH from hvm_ioreq_init()

 xen/arch/x86/hvm/ioreq.c  | 18 ++
 xen/include/asm-x86/domain.h  |  2 ++
 xen/include/public/arch-x86/xen.h |  5 -
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index d2245e2..e6ff48f 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1380,6 +1380,12 @@ static int hvm_access_cf8(
 return X86EMUL_UNHANDLEABLE;
 }
 
+static int acpi_ioaccess(
+int dir, unsigned int port, unsigned int bytes, uint32_t *val)
+{
+return X86EMUL_OKAY;
+}
+
 void hvm_ioreq_init(struct domain *d)
 {
 spin_lock_init(>arch.hvm_domain.ioreq_server.lock);
@@ -1387,6 +1393,18 @@ void hvm_ioreq_init(struct domain *d)
 
 if ( !is_pvh_domain(d) )
 register_portio_handler(d, 0xcf8, 4, hvm_access_cf8);
+
+if ( !has_ioreq_cpuhp(d) )
+{
+/* Online CPU map, see DSDT's PRST region. */
+register_portio_handler(d, ACPI_CPU_MAP,
+ACPI_CPU_MAP_LEN, acpi_ioaccess);
+
+register_portio_handler(d, ACPI_GPE0_BLK_ADDRESS_V1,
+ACPI_GPE0_BLK_LEN_V1, acpi_ioaccess);
+register_portio_handler(d, ACPI_PM1A_EVT_BLK_ADDRESS_V1,
+ACPI_PM1A_EVT_BLK_LEN, acpi_ioaccess);
+}
 }
 
 /*
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index a279e4a..7aa736c 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -431,6 +431,8 @@ struct arch_domain
 #define has_vvga(d)(!!((d)->arch.emulation_flags & XEN_X86_EMU_VGA))
 #define has_viommu(d)  (!!((d)->arch.emulation_flags & XEN_X86_EMU_IOMMU))
 #define has_vpit(d)(!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
+#define has_ioreq_cpuhp(d) (!!((d)->arch.emulation_flags & \
+   XEN_X86_EMU_IOREQ_CPUHP))
 
 #define has_arch_pdevs(d)(!list_empty(&(d)->arch.pdev_list))
 
diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index cdd93c1..350bc66 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -283,12 +283,15 @@ struct xen_arch_domainconfig {
 #define XEN_X86_EMU_IOMMU   (1U<<_XEN_X86_EMU_IOMMU)
 #define _XEN_X86_EMU_PIT8
 #define XEN_X86_EMU_PIT (1U<<_XEN_X86_EMU_PIT)
+#define _XEN_X86_EMU_IOREQ_CPUHP9
+#define XEN_X86_EMU_IOREQ_CPUHP (1U<<_XEN_X86_EMU_IOREQ_CPUHP)
 
 #define XEN_X86_EMU_ALL (XEN_X86_EMU_LAPIC | XEN_X86_EMU_HPET |  \
  XEN_X86_EMU_PM | XEN_X86_EMU_RTC |  \
  XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC |  \
  XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU |   \
- XEN_X86_EMU_PIT)
+ XEN_X86_EMU_PIT |   \
+ XEN_X86_EMU_IOREQ_CPUHP)
 uint32_t emulation_flags;
 };
 #endif
-- 
2.7.4


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

[Xen-devel] [PATCH v2 06/11] acpi: PVH guests need _E02 method

[Boris Ostrovsky]

This is the method that will get invoked on an SCI.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Andrew Cooper 
---
 tools/libacpi/mk_dsdt.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 2b8234d..780783e 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -282,11 +282,6 @@ int main(int argc, char **argv)
 
 pop_block();
 
-if (dm_version == QEMU_NONE) {
-pop_block();
-return 0;
-}
-
 /* Define GPE control method. */
 push_block("Scope", "\\_GPE");
 push_block("Method",
@@ -294,6 +289,11 @@ int main(int argc, char **argv)
 stmt("\\_SB.PRSC ()", NULL);
 pop_block();
 pop_block();
+
+if (dm_version == QEMU_NONE) {
+pop_block();
+return 0;
+}
 / Processor end /
 
 
-- 
2.7.4


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

[Xen-devel] [PATCH v2 10/11] pvh: Send an SCI on VCPU hotplug event

[Boris Ostrovsky]

.. and update GPE0 registers.

Signed-off-by: Boris Ostrovsky 
---
Changes in v2:
* Use has_ioreq_cpuhp() instead of ioreq_gmfn.mask==0 as check 
  for PVH guest


 xen/arch/x86/domctl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index b736d4c..07c8247 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1443,6 +1443,18 @@ long arch_do_domctl(
 break;
 
 d->arch.avail_vcpus = num;
+
+/*
+ * For PVH guests we need to send an SCI and set enable/status
+ * bits in GPE block (DSDT specifies _E02, so it's bit 2).
+ */
+if ( is_hvm_domain(d) && !has_ioreq_cpuhp(d) )
+{
+d->arch.hvm_domain.acpi_io.gpe[2] =
+d->arch.hvm_domain.acpi_io.gpe[0] = 4;
+send_guest_vcpu_virq(d->vcpu[0], VIRQ_SCI);
+}
+
 ret = 0;
 break;
 }
-- 
2.7.4


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

[Xen-devel] [PATCH v2 11/11] docs: Describe PVHv2's VCPU hotplug procedure

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
Changes in v2:
* New patch

 docs/misc/hvmlite.markdown | 12 
 1 file changed, 12 insertions(+)

diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 898b8ee..0045d22 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -75,3 +75,15 @@ info structure that's passed at boot time (field rsdp_paddr).
 
 Description of paravirtualized devices will come from XenStore, just as it's
 done for HVM guests.
+
+## VCPU hotplug ##
+
+VCPU hotplug (e.g. 'xl vcpu-set  ') for PVHv2 guests
+follows ACPI model where change in domain's number of VCPUS (stored in
+arch_domain.avail_vcpus) results in an SCI being sent to the guest. The
+guest then executes DSDT's PRSC method, updating MADT enable status for
+the affected VCPU.
+
+This is achieved by having the toolstack call XEN_DOMCTL_set_avail_vcpus
+which sets appropriate bits in ACPI GPE0 enable and status registers followed
+by sending VIRQ_SCI to the guest.
-- 
2.7.4


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

[Xen-devel] [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Boris Ostrovsky]

This domctl is called when a VCPU is hot-(un)plugged to a guest (via
'xl vcpu-set'). While this currently is only intended to be needed by
PVH guests we will call this domctl for all (x86) guests for consistency.

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 
---
Changes in v2:
* Added comment in arch_do_domctl() stating that the domctl is only required
  for PVH guests


 tools/flask/policy/modules/dom0.te  |  2 +-
 tools/flask/policy/modules/xen.if   |  4 ++--
 tools/libxc/include/xenctrl.h   |  5 +
 tools/libxc/xc_dom_x86.c| 11 +++
 tools/libxl/libxl.c | 10 +-
 tools/libxl/libxl_arch.h|  4 
 tools/libxl/libxl_arm.c |  6 ++
 tools/libxl/libxl_dom.c |  7 +++
 tools/libxl/libxl_x86.c |  6 ++
 xen/arch/x86/domctl.c   | 17 +
 xen/include/asm-x86/domain.h|  6 ++
 xen/include/public/domctl.h |  9 +
 xen/xsm/flask/hooks.c   |  3 +++
 xen/xsm/flask/policy/access_vectors |  2 ++
 14 files changed, 88 insertions(+), 4 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index 2d982d9..fd60c39 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -38,7 +38,7 @@ allow dom0_t dom0_t:domain {
 };
 allow dom0_t dom0_t:domain2 {
set_cpuid gettsc settsc setscheduler set_max_evtchn set_vnumainfo
-   get_vnumainfo psr_cmt_op psr_cat_op
+   get_vnumainfo psr_cmt_op psr_cat_op set_avail_vcpus
 };
 allow dom0_t dom0_t:resource { add remove };
 
diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index eb646f5..afbedc2 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -52,7 +52,7 @@ define(`create_domain_common', `
settime setdomainhandle getvcpucontext };
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
-   psr_cmt_op psr_cat_op soft_reset };
+   psr_cmt_op psr_cat_op soft_reset set_avail_vcpus};
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage 
mmuext_op updatemp };
@@ -85,7 +85,7 @@ define(`manage_domain', `
getaddrsize pause unpause trigger shutdown destroy
setaffinity setdomainmaxmem getscheduler resume
setpodtarget getpodtarget };
-allow $1 $2:domain2 set_vnumainfo;
+allow $1 $2:domain2 { set_vnumainfo set_avail_vcpus };
 ')
 
 # migrate_domain_out(priv, target)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 2c83544..49e9b9f 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1256,6 +1256,11 @@ int xc_domain_getvnuma(xc_interface *xch,
 int xc_domain_soft_reset(xc_interface *xch,
  uint32_t domid);
 
+int xc_domain_set_avail_vcpus(xc_interface *xch,
+  uint32_t domid,
+  unsigned int num_vcpus);
+
+
 #if defined(__i386__) || defined(__x86_64__)
 /*
  * PC BIOS standard E820 types and structure.
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 0eab8a7..7fcdee1 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -125,6 +125,17 @@ const char *xc_domain_get_native_protocol(xc_interface 
*xch,
 return protocol;
 }
 
+int xc_domain_set_avail_vcpus(xc_interface *xch,
+  uint32_t domid,
+  unsigned int num_vcpus)
+{
+DECLARE_DOMCTL;
+domctl.cmd = XEN_DOMCTL_set_avail_vcpus;
+domctl.domain = (domid_t)domid;
+domctl.u.avail_vcpus.num = num_vcpus;
+return do_domctl(xch, );
+}
+
 static int count_pgtables(struct xc_dom_image *dom, xen_vaddr_t from,
   xen_vaddr_t to, xen_pfn_t pfn)
 {
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 33c5e4c..9b94413 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5148,11 +5148,12 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t 
domid, libxl_bitmap *cpumap)
 case LIBXL_DOMAIN_TYPE_HVM:
 switch (libxl__device_model_version_running(gc, domid)) {
 case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-case LIBXL_DEVICE_MODEL_VERSION_NONE:
 rc = libxl__set_vcpuonline_xenstore(gc, domid, cpumap, );
 break;
 case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
 rc = libxl__set_vcpuonline_qmp(gc, domid, cpumap, );
+/* fallthrough */
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
 break;
 default:
 rc = ERROR_INVAL;
@@ -5164,6 

[Xen-devel] [PATCH v2 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
CC: Paul Durrant 
---
Changes in v2:
* Use 'true/false' values for bools


 xen/arch/x86/hvm/ioreq.c | 72 
 1 file changed, 72 insertions(+)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index e6ff48f..3ef01cf 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1383,6 +1383,78 @@ static int hvm_access_cf8(
 static int acpi_ioaccess(
 int dir, unsigned int port, unsigned int bytes, uint32_t *val)
 {
+unsigned int i;
+unsigned int bits = bytes * 8;
+unsigned int idx = port & 3;
+uint8_t *reg = NULL;
+bool is_cpu_map = false;
+struct domain *currd = current->domain;
+
+BUILD_BUG_ON((ACPI_PM1A_EVT_BLK_LEN != 4) ||
+ (ACPI_GPE0_BLK_LEN_V1 != 4));
+
+if ( has_ioreq_cpuhp(currd) )
+return X86EMUL_UNHANDLEABLE;
+
+switch (port)
+{
+case ACPI_PM1A_EVT_BLK_ADDRESS_V1 ...
+(ACPI_PM1A_EVT_BLK_ADDRESS_V1 + ACPI_PM1A_EVT_BLK_LEN - 1):
+reg = currd->arch.hvm_domain.acpi_io.pm1a;
+break;
+case ACPI_GPE0_BLK_ADDRESS_V1 ...
+(ACPI_GPE0_BLK_ADDRESS_V1 + ACPI_GPE0_BLK_LEN_V1 - 1):
+reg = currd->arch.hvm_domain.acpi_io.gpe;
+break;
+case ACPI_CPU_MAP ... (ACPI_CPU_MAP + ACPI_CPU_MAP_LEN - 1):
+is_cpu_map = true;
+break;
+default:
+return X86EMUL_UNHANDLEABLE;
+}
+
+if ( bytes == 0 )
+return X86EMUL_OKAY;
+
+if ( dir == IOREQ_READ )
+{
+*val &= ~((1U << bits) - 1);
+
+if ( is_cpu_map )
+{
+unsigned int first_bit, last_bit;
+
+first_bit = (port - ACPI_CPU_MAP) * 8;
+last_bit = min(currd->arch.avail_vcpus, first_bit + bits);
+for ( i = first_bit; i < last_bit; i++ )
+*val |= (1U << (i - first_bit));
+}
+else
+memcpy(val, [idx], bytes);
+}
+else
+{
+if ( is_cpu_map )
+/*
+ * CPU map is only read by DSDT's PRSC method and should never
+ * be written by a guest.
+ */
+return X86EMUL_UNHANDLEABLE;
+
+/* Write either status or enable reegister. */
+if ( (bytes > 2) || ((bytes == 2) && (port & 1)) )
+return X86EMUL_UNHANDLEABLE;
+
+if ( idx < 2 ) /* status, write 1 to clear. */
+{
+reg[idx] &= ~(*val & 0xff);
+if ( bytes == 2 )
+reg[idx + 1] &= ~((*val >> 8) & 0xff);
+}
+else   /* enable */
+memcpy([idx], val, bytes);
+}
+
 return X86EMUL_OKAY;
 }
 
-- 
2.7.4


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

[Xen-devel] [PATCH v2 05/11] acpi: Power and Sleep ACPI buttons are not emulated for PVH guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
Changes in v2:
* HVM guests continue having the buttons

 tools/firmware/hvmloader/util.c | 3 ++-
 tools/libacpi/build.c   | 2 ++
 tools/libacpi/libacpi.h | 1 +
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 1d78973..a3f12fe 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -949,7 +949,8 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
 config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC |
-ACPI_HAS_WAET | ACPI_HAS_PMTIMER);
+ACPI_HAS_WAET | ACPI_HAS_PMTIMER |
+ACPI_HAS_BUTTONS);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 58822d3..5c4a818 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -579,6 +579,8 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 Fadt.pm_tmr_blk = 0;
 memset(_pm_tmr_blk, 0, sizeof(Fadt.x_pm_tmr_blk));
 }
+if ( !(config->table_flags & ACPI_HAS_BUTTONS) )
+Fadt.flags |= (ACPI_PWR_BUTTON | ACPI_SLP_BUTTON);
 memcpy(fadt, , sizeof(struct acpi_20_fadt));
 fadt->dsdt   = ctxt->mem_ops.v2p(ctxt, dsdt);
 fadt->x_dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index bda692e..dd6ef8b 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -31,6 +31,7 @@
 #define ACPI_HAS_IOAPIC  (1<<8)
 #define ACPI_HAS_WAET(1<<9)
 #define ACPI_HAS_PMTIMER (1<<10)
+#define ACPI_HAS_BUTTONS (1<<11)
 
 struct xen_vmemrange;
 struct acpi_numa {
-- 
2.7.4


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

[Xen-devel] [PATCH v2 09/11] events/x86: Define SCI virtual interrupt

[Boris Ostrovsky]

PVH guests do not have IOAPIC which typically generates an SCI. For
those guests SCI will be provided as a virtual interrupt.

We also move VIRQ_MCA definition out of xen-mca.h to
keep all x86-specific VIRQ_ARCH_* in one place.

Signed-off-by: Boris Ostrovsky 
---
 xen/include/asm-x86/event.h   | 3 ++-
 xen/include/public/arch-x86/xen-mca.h | 2 --
 xen/include/public/arch-x86/xen.h | 3 +++
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index a82062e..9cad8e3 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -38,9 +38,10 @@ static inline void local_event_delivery_enable(void)
 vcpu_info(current, evtchn_upcall_mask) = 0;
 }
 
-/* No arch specific virq definition now. Default to global. */
 static inline int arch_virq_is_global(uint32_t virq)
 {
+if ( virq == VIRQ_SCI )
+   return 0;
 return 1;
 }
 
diff --git a/xen/include/public/arch-x86/xen-mca.h 
b/xen/include/public/arch-x86/xen-mca.h
index a97e821..b76c53c 100644
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -91,8 +91,6 @@
 
 #ifndef __ASSEMBLY__
 
-#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
-
 /*
  * Machine Check Architecure:
  * structs are read-only and used to report all kinds of
diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index 350bc66..4750ba7 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -296,6 +296,9 @@ struct xen_arch_domainconfig {
 };
 #endif
 
+#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
+#define VIRQ_SCI VIRQ_ARCH_1 /* V. (PVH) ACPI interrupt */
+
 #endif /* !__ASSEMBLY__ */
 
 /*
-- 
2.7.4


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

[Xen-devel] [PATCH v2 00/11] PVH VCPU hotplug support

[Boris Ostrovsky]

This series adds support for ACPI-based VCPU hotplug for unprivileged
PVH guests.

New XEN_DOMCTL_set_avail_vcpus is introduced and is called during
guest creation and in response to 'xl vcpu-set' command. This domctl
updates GPE0's status and enable registers and sends an SCI to the
guest using (newly added) VIRQ_SCI.

Main changes in V2:
* Add XEN_X86_EMU_IOREQ_CPUHP flag to indicate need to handle
  ACPI accesses in hypervisor
* Add ACPI_CPU_MAP[_LEN] for 0xafee address block


Boris Ostrovsky (11):
  x86/domctl: Add XEN_DOMCTL_set_avail_vcpus
  acpi: Define ACPI IO registers for PVH guests
  pvh: Set online VCPU map to avail_vcpus
  acpi: Make pmtimer optional in FADT
  acpi: Power and Sleep ACPI buttons are not emulated for PVH guests
  acpi: PVH guests need _E02 method
  pvh/ioreq: Install handlers for ACPI-related PVH IO accesses
  pvh/acpi: Handle ACPI accesses for PVH guests
  events/x86: Define SCI virtual interrupt
  pvh: Send an SCI on VCPU hotplug event
  docs: Describe PVHv2's VCPU hotplug procedure

 docs/misc/hvmlite.markdown| 12 +
 tools/firmware/hvmloader/util.c   |  4 +-
 tools/flask/policy/modules/dom0.te|  2 +-
 tools/flask/policy/modules/xen.if |  4 +-
 tools/libacpi/build.c |  7 +++
 tools/libacpi/libacpi.h   |  2 +
 tools/libacpi/mk_dsdt.c   | 14 +++---
 tools/libacpi/static_tables.c | 28 +--
 tools/libxc/include/xenctrl.h |  5 ++
 tools/libxc/xc_dom_x86.c  | 11 +
 tools/libxl/libxl.c   | 10 +++-
 tools/libxl/libxl_arch.h  |  4 ++
 tools/libxl/libxl_arm.c   |  6 +++
 tools/libxl/libxl_dom.c   |  7 +++
 tools/libxl/libxl_x86.c   |  6 +++
 tools/libxl/libxl_x86_acpi.c  |  6 +--
 xen/arch/x86/domctl.c | 29 +++
 xen/arch/x86/hvm/ioreq.c  | 90 +++
 xen/include/asm-x86/domain.h  |  8 
 xen/include/asm-x86/event.h   |  3 +-
 xen/include/asm-x86/hvm/domain.h  |  6 +++
 xen/include/public/arch-arm.h | 11 +++--
 xen/include/public/arch-x86/xen-mca.h |  2 -
 xen/include/public/arch-x86/xen.h |  8 +++-
 xen/include/public/domctl.h   |  9 
 xen/include/public/hvm/ioreq.h| 13 +
 xen/xsm/flask/hooks.c |  3 ++
 xen/xsm/flask/policy/access_vectors   |  2 +
 28 files changed, 274 insertions(+), 38 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

[Boris Ostrovsky]

ACPI hotplug-related IO accesses (to GPE0 block) are handled
by qemu for HVM guests. Since PVH guests don't have qemu these
accesses will need to be procesed by the hypervisor.

Because ACPI event model expects pm1a block to be present we
need to have the hypervisor emulate it as well.

Signed-off-by: Boris Ostrovsky 
---
CC: Julien Grall 
CC: Paul Durrant 
---
Changes in v2:
* Added public macros for ACPI CPU bitmap (at 0xaf00). Note: PRST
  region shrinks from 32 bytes to 16 (when 128 VCPUs are
  supported).


 tools/libacpi/mk_dsdt.c  |  4 +++-
 tools/libacpi/static_tables.c| 28 +++-
 xen/include/asm-x86/hvm/domain.h |  6 ++
 xen/include/public/arch-arm.h| 11 ---
 xen/include/public/hvm/ioreq.h   | 13 +
 5 files changed, 41 insertions(+), 21 deletions(-)

diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 4ae68bc..2b8234d 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -19,6 +19,7 @@
 #include 
 #if defined(__i386__) || defined(__x86_64__)
 #include 
+#include 
 #elif defined(__aarch64__)
 #include 
 #endif
@@ -244,7 +245,8 @@ int main(int argc, char **argv)
 #endif
 
 /* Operation Region 'PRST': bitmask of online CPUs. */
-stmt("OperationRegion", "PRST, SystemIO, 0xaf00, 32");
+stmt("OperationRegion", "PRST, SystemIO, 0x%x, %d",
+ACPI_CPU_MAP, ACPI_CPU_MAP_LEN);
 push_block("Field", "PRST, ByteAcc, NoLock, Preserve");
 indent(); printf("PRS, %u\n", max_cpus);
 pop_block();
diff --git a/tools/libacpi/static_tables.c b/tools/libacpi/static_tables.c
index 617bf68..413abcc 100644
--- a/tools/libacpi/static_tables.c
+++ b/tools/libacpi/static_tables.c
@@ -20,6 +20,8 @@
  * Firmware ACPI Control Structure (FACS).
  */
 
+#define ACPI_REG_BIT_OFFSET0
+
 struct acpi_20_facs Facs = {
 .signature = ACPI_2_0_FACS_SIGNATURE,
 .length= sizeof(struct acpi_20_facs),
@@ -30,14 +32,6 @@ struct acpi_20_facs Facs = {
 /*
  * Fixed ACPI Description Table (FADT).
  */
-
-#define ACPI_PM1A_EVT_BLK_BIT_WIDTH 0x20
-#define ACPI_PM1A_EVT_BLK_BIT_OFFSET0x00
-#define ACPI_PM1A_CNT_BLK_BIT_WIDTH 0x10
-#define ACPI_PM1A_CNT_BLK_BIT_OFFSET0x00
-#define ACPI_PM_TMR_BLK_BIT_WIDTH   0x20
-#define ACPI_PM_TMR_BLK_BIT_OFFSET  0x00
-
 struct acpi_20_fadt Fadt = {
 .header = {
 .signature= ACPI_2_0_FADT_SIGNATURE,
@@ -56,9 +50,9 @@ struct acpi_20_fadt Fadt = {
 .pm1a_cnt_blk = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
 .pm_tmr_blk = ACPI_PM_TMR_BLK_ADDRESS_V1,
 .gpe0_blk = ACPI_GPE0_BLK_ADDRESS_V1,
-.pm1_evt_len = ACPI_PM1A_EVT_BLK_BIT_WIDTH / 8,
-.pm1_cnt_len = ACPI_PM1A_CNT_BLK_BIT_WIDTH / 8,
-.pm_tmr_len = ACPI_PM_TMR_BLK_BIT_WIDTH / 8,
+.pm1_evt_len = ACPI_PM1A_EVT_BLK_LEN,
+.pm1_cnt_len = ACPI_PM1A_CNT_BLK_LEN,
+.pm_tmr_len = ACPI_PM_TMR_BLK_LEN,
 .gpe0_blk_len = ACPI_GPE0_BLK_LEN_V1,
 
 .p_lvl2_lat = 0x0fff, /* >100,  means we do not support C2 state */
@@ -79,22 +73,22 @@ struct acpi_20_fadt Fadt = {
 
 .x_pm1a_evt_blk = {
 .address_space_id= ACPI_SYSTEM_IO,
-.register_bit_width  = ACPI_PM1A_EVT_BLK_BIT_WIDTH,
-.register_bit_offset = ACPI_PM1A_EVT_BLK_BIT_OFFSET,
+.register_bit_width  = ACPI_PM1A_EVT_BLK_LEN * 8,
+.register_bit_offset = ACPI_REG_BIT_OFFSET,
 .address = ACPI_PM1A_EVT_BLK_ADDRESS_V1,
 },
 
 .x_pm1a_cnt_blk = {
 .address_space_id= ACPI_SYSTEM_IO,
-.register_bit_width  = ACPI_PM1A_CNT_BLK_BIT_WIDTH,
-.register_bit_offset = ACPI_PM1A_CNT_BLK_BIT_OFFSET,
+.register_bit_width  = ACPI_PM1A_CNT_BLK_LEN * 8,
+.register_bit_offset = ACPI_REG_BIT_OFFSET,
 .address = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
 },
 
 .x_pm_tmr_blk = {
 .address_space_id= ACPI_SYSTEM_IO,
-.register_bit_width  = ACPI_PM_TMR_BLK_BIT_WIDTH,
-.register_bit_offset = ACPI_PM_TMR_BLK_BIT_OFFSET,
+.register_bit_width  = ACPI_PM_TMR_BLK_LEN * 8,
+.register_bit_offset = ACPI_REG_BIT_OFFSET,
 .address = ACPI_PM_TMR_BLK_ADDRESS_V1,
 }
 };
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index f34d784..f492a2b 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -87,6 +87,12 @@ struct hvm_domain {
 } ioreq_server;
 struct hvm_ioreq_server *default_ioreq_server;
 
+/* PVH guests */
+struct {
+uint8_t pm1a[ACPI_PM1A_EVT_BLK_LEN];
+uint8_t gpe[ACPI_GPE0_BLK_LEN_V1];
+} acpi_io;
+
 /* Cached CF8 for guest PCI config cycles */
 uint32_tpci_cf8;
 
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index bd974fb..b793774 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ 

[Xen-devel] [PATCH v2 03/11] pvh: Set online VCPU map to avail_vcpus

[Boris Ostrovsky]

ACPI builder marks VCPUS set in vcpu_online map as enabled in MADT.
With ACPI-based CPU hotplug we only want VCPUs that are started by
the guest to be marked as such. Remaining VCPUs will be set to
"enable" by AML code during hotplug.

Signed-off-by: Boris Ostrovsky 
---
Changes in v2:
* Clarified in the commit message that it's AML that updates MADT

 tools/libxl/libxl_x86_acpi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
index ff0e2df..949f555 100644
--- a/tools/libxl/libxl_x86_acpi.c
+++ b/tools/libxl/libxl_x86_acpi.c
@@ -98,7 +98,7 @@ static int init_acpi_config(libxl__gc *gc,
 uint32_t domid = dom->guest_domid;
 xc_dominfo_t info;
 struct hvm_info_table *hvminfo;
-int i, rc = 0;
+int rc = 0;
 
 config->dsdt_anycpu = config->dsdt_15cpu = dsdt_pvh;
 config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_pvh_len;
@@ -144,8 +144,8 @@ static int init_acpi_config(libxl__gc *gc,
 hvminfo->nr_vcpus = info.max_vcpu_id + 1;
 }
 
-for (i = 0; i < hvminfo->nr_vcpus; i++)
-hvminfo->vcpu_online[i / 8] |= 1 << (i & 7);
+memcpy(hvminfo->vcpu_online, b_info->avail_vcpus.map,
+   b_info->avail_vcpus.size);
 
 config->hvminfo = hvminfo;
 
-- 
2.7.4


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

[Xen-devel] [PATCH v2 04/11] acpi: Make pmtimer optional in FADT

[Boris Ostrovsky]

PM timer is not supported by PVH guests.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 tools/firmware/hvmloader/util.c | 3 ++-
 tools/libacpi/build.c   | 5 +
 tools/libacpi/libacpi.h | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 6e0cfe7..1d78973 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -948,7 +948,8 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
-config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET);
+config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC |
+ACPI_HAS_WAET | ACPI_HAS_PMTIMER);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 47dae01..58822d3 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -574,6 +574,11 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 
 fadt = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_fadt), 16);
 if (!fadt) goto oom;
+if ( !(config->table_flags & ACPI_HAS_PMTIMER) )
+{
+Fadt.pm_tmr_blk = 0;
+memset(_pm_tmr_blk, 0, sizeof(Fadt.x_pm_tmr_blk));
+}
 memcpy(fadt, , sizeof(struct acpi_20_fadt));
 fadt->dsdt   = ctxt->mem_ops.v2p(ctxt, dsdt);
 fadt->x_dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index 1d388f9..bda692e 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -30,6 +30,7 @@
 #define ACPI_HAS_TCPA(1<<7)
 #define ACPI_HAS_IOAPIC  (1<<8)
 #define ACPI_HAS_WAET(1<<9)
+#define ACPI_HAS_PMTIMER (1<<10)
 
 struct xen_vmemrange;
 struct acpi_numa {
-- 
2.7.4


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

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

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
67978
 test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 
67978
 test-amd64-i386-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
67978
 test-amd64-i386-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 67978

baseline version:
 flight   67978

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



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

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

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


Push not applicable.


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

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

Last test of basis68016  2016-11-09 00:49:32 Z0 days
Testing same since68019  2016-11-09 10:17:59 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 
  Michael Kinney 

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.

(No revision log; it would be 1044 lines long.)

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

[Xen-devel] [OSSTEST PATCH 2/3] rump build tests: Introduce ts-xen-build-rump

[Ian Jackson]

We are going to want to pass a whole slew of options to configure, and
hence to ts-xen-build.  I think putting that in sg-run-job is
undesirable.

So, split out the ts-xen-build invocation into its own script.
Explicitly set the testid so that it does not change.

No significant functional change.

Signed-off-by: Ian Jackson 
---
 sg-run-job| 2 +-
 ts-xen-build-rump | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)
 create mode 100755 ts-xen-build-rump

diff --git a/sg-run-job b/sg-run-job
index 57080e7..104c880 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -501,7 +501,7 @@ proc run-job/build-libvirt {} {
 proc run-job/build-rumprun {} {
 run-ts . = ts-rumprun-build
 run-ts . = ts-rumprun-demo-build + host + nettest rump-test-net
-run-ts . = ts-xen-build + host --no-kconfig tools
+run-ts . xen-build ts-xen-build-rump + host --no-kconfig --
 run-ts . = ts-rumprun-bake + host \
 nettest :nettest:/rump-test-net \
 xenstorels ::/usr/local/bin/xenstore-ls
diff --git a/ts-xen-build-rump b/ts-xen-build-rump
new file mode 100755
index 000..7ce3e73
--- /dev/null
+++ b/ts-xen-build-rump
@@ -0,0 +1,6 @@
+#!/bin/sh
+set -ex
+
+exec ./ts-xen-build "$@"   \
+   --- \
+   tools
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 3/3] rump build tests: Disable a lot of unwanted Xen things at configure time

[Ian Jackson]

Amongst other things, we disable rombios which requires lzma.

Signed-off-by: Ian Jackson 
---
 ts-xen-build-rump | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ts-xen-build-rump b/ts-xen-build-rump
index 7ce3e73..9ea595b 100755
--- a/ts-xen-build-rump
+++ b/ts-xen-build-rump
@@ -2,5 +2,8 @@
 set -ex
 
 exec ./ts-xen-build "$@"   \
+   --disable-ovmf --disable-seabios --disable-blktap2  \
+   --disable-rombios --disable-qemu-traditional\
+   --disable-stubdom --disable-xen --disable-docs  \
--- \
tools
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 0/3] Fix rump tests for lzma et al

[Ian Jackson]

Between my last series for fixing the rump tests in osstest, xen.git
grew a dependency on liblzma which causese the rump build of the Xen
tools to fail.

Here I fix this by disabling lots of unwanted stuff by passing
appropriate --disable-whatever options to the xen.git configure
script.

I ran an adhoc flight of the rump parts and it all passed.

This series is next in the queue for osstest pretest.

Ian.

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

[Xen-devel] [OSSTEST PATCH 1/3] ts-xen-build: Support passing arguments to configure

[Ian Jackson]

No functional change with existing callers.

Signed-off-by: Ian Jackson 
---
 ts-xen-build | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/ts-xen-build b/ts-xen-build
index 3e53d74..7dfcda7 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -37,7 +37,15 @@ while (@ARGV && $ARGV[0] =~ m/^-/) {
die "$_ ?";
 }
 }
+
+my ($dashdashdash) = grep { $ARGV[$_] eq '---' } 0..$#ARGV;
+my (@configure_args, @make_args);
+$dashdashdash //= -1;
+@configure_args = @ARGV[0..$dashdashdash-1];
+@make_args  = @ARGV[$dashdashdash+1..$#ARGV];
+
 # remaining arguments are passed as targets to "make"
+# if there is a ---, those before that are arguments to "configure"
 
 builddirsprops();
 
@@ -126,7 +134,7 @@ sub build () {
 ovmf=$ovmf_opt
 fi
 END
-   $configure_prefix ./configure --sysconfdir=/etc \$xend \$ovmf 
$configure_suffix
+   $configure_prefix ./configure --sysconfdir=/etc \$xend \$ovmf 
$configure_suffix @configure_args
 END
 fi
 END
@@ -139,7 +147,7 @@ END
 END
 
 buildcmd_stamped_logged(9000, 'xen', 'build', '',<

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

[osstest service owner]

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

Regressions :-(

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

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

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

version targeted for testing:
 qemuu207faf24c58859f5240f66bf6decc33b87a1776e
baseline version:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f

Last test of basis   101909  2016-11-03 23:21:40 Z5 days
Failing since101943  2016-11-04 22:40:48 Z4 days7 attempts
Testing same since   102031  2016-11-08 07:59:22 Z1 days2 attempts


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

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

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

[Razvan Cojocaru]

On 11/09/2016 01:17 PM, Jan Beulich wrote:
 On 09.11.16 at 10:42,  wrote:
>> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>> +{
>> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>> +
>> +if ( vmcb->eventinj.fields.v )
>> +return false;
>> +
>> +info->vector = vmcb->eventinj.fields.vector;
>> +info->type = vmcb->eventinj.fields.type;
>> +info->error_code = vmcb->eventinj.fields.errorcode;
>> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
> 
> I'd prefer for this last part to be put into generic code (i.e. the
> wrapper).

Actually, doing this:

static inline bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap
*info)
{
info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
return hvm_funcs.get_pending_event(v, info);
}

leads to "error: dereferencing pointer to incomplete type" about v->, so
to do this an additional #include will be necessary. Is that acceptable?


Thanks,
Razvan


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

Re: [Xen-devel] question: is it a CVE in relinquish_memory()[xen/arch/x86/domain.c]

[Jan Beulich]

>>> On 09.11.16 at 13:01,  wrote:
> Based on CVE-2015-7814 and commit 1ef01396fdff, ' arm: handle races between 
> relinquish_memory and free_domheap_pages'..
> relinquish_memory() [xen/arch/arm/domain.c, arm code], 
> when couldn't get a reference -- someone is freeing this page and has already 
> committed to doing so, so no more to do here, continue.
> 
> 
> But in relinquish_memory()[xen/arch/x86/domain.c, __x86__ code], when 
> couldn't get a reference -- someone is freeing this page,
> Why adding this page to d->arch.relmem_list again. 
> Is it a CVE to double free page, then hit the ''" alloc_heap_pages() : 
> BUG_ON(pg[i].count_info != PGC_state_free)"" in creating guests later..

Well, considering that you've even quoted the description of the
patch, it should be clear to you that the difference in behavior
between ARM and x86 is intended. Hence I'm having difficulty
seeing what you actually want to point out.

And then, if you again suspect a security issue in the future,
please ask on security@ first, rather than posting publicly (on
xen-devel@ or elsewhere).

Thanks, Jan


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

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

[Jan Beulich]

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

Reviewed-by: Jan Beulich 
with two possible further adjustments:

> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1948,26 +1948,28 @@ static int svm_msr_write_intercept(unsigned int msr, 
> uint64_t msr_content)
>  
>  static void svm_do_msr_access(struct cpu_user_regs *regs)
>  {
> -int rc, inst_len;
>  struct vcpu *v = current;
> -struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> -uint64_t msr_content;
> +bool rdmsr = v->arch.hvm_svm.vmcb->exitinfo1 == 0;
> +int rc, inst_len = __get_instruction_length(
> +v, rdmsr ? INSTR_RDMSR : INSTR_WRMSR);

With all of this I think it wouldn't make the patch worse to look at if
you also renamed v -> curr.

> +if ( inst_len == 0 )
> +return;
>  
> -if ( vmcb->exitinfo1 == 0 )
> +if ( rdmsr )
>  {
> -if ( (inst_len = __get_instruction_length(v, INSTR_RDMSR)) == 0 )
> -return;
> -rc = hvm_msr_read_intercept(regs->ecx, _content);
> -regs->eax = (uint32_t)msr_content;
> -regs->edx = (uint32_t)(msr_content >> 32);
> +uint64_t msr_content = 0;
> +
> +rc = hvm_msr_read_intercept(regs->_ecx, _content);
> +if ( rc == X86EMUL_OKAY )
> +{
> +regs->rax = (uint32_t)msr_content;
> +regs->rdx = (uint32_t)(msr_content >> 32);

While the first of the casts is needed, the second one isn't.

Jan


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

[Xen-devel] Xen, EFI and kexec

[Sylvain Munaut]

Hi,


A bit of background: What I'm currently trying to do is to network
boot a first linux image in EFI mode (using UEFI network boot), then
from that image, kexec into Xen in EFI mode as well.

It's not working.

When you kexec into another linux in EFI mode, kexec actually passes
some more infos to the kernel to allow it to use EFI mode properly.
IIUC Linux also maps the various EFI ranges at deterministic addresses
because the seting up EFI virtual address mode is only allowed once
per boot and so both the old and new kernel have to use the same
mappings.

I have seen the patch series by Daniel Kiper to add support for
multiboot2 protocol and EFI support for it. This seems like a good
step toward what I'd like to do. Adding multiboot2 support to kexec
user tools seems like something I could do. This should allow Xen to
get the info it needs.

However I don't think that'll be sufficient.

By the time kexec will launch Xen, the first kernel will have done an
"ExitBootServices". And looking at Daniel's patch, that seems to be an
issue.

I'm also not sure if the EFI virtual address mode will be an issue or
not yet. (i.e. Xen uses the physical address mode, but is that usable
after the first linux setup the virtual mode).

Is there anything else I overlooked that will be an issue ?

Is this a use case worth supporting ? (Obviously I think so, but I'm biased :p)

And if I'm looking at it the wrong way, what way should I be looking at it ?


Cheers,

Sylvain Munaut


PS: I'm currently making my way through the 2000+ pages of the EFI
specs so I probably got some things wrong above ...

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 libvirt  f694f3ff6bd8a94d71582adab669b0dcd1f7bfe5
baseline version:
 libvirt  214c226f9e1440f02ba338b485899b62d9e6bdf8

Last test of basis   102026  2016-11-08 04:28:21 Z1 days
Testing same since   102058  2016-11-09 04:33:12 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Dawid Zamirski 
  Félix Bouliane 
  John Ferlan 
  Michal Privoznik 

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



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

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

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

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


Pushing revision :

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

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

[Jan Beulich]

>>> On 09.11.16 at 12:49,  wrote:
> On 09/11/16 11:32, Razvan Cojocaru wrote:
>> On 11/09/2016 01:17 PM, Jan Beulich wrote:
>> On 09.11.16 at 10:42,  wrote:
 @@ -259,6 +266,13 @@ struct vm_event_cpuid {
  uint32_t _pad;
  };
  
 +struct vm_event_interrupt {
 +uint32_t vector;
 +uint32_t type;
 +uint32_t error_code;
 +uint64_t cr2;
 +};
>>> This being x86-specific, I think it should be named or union-ized
>>> accordingly.
>> Right, I'll rename it.
> 
> You area also exposing  X86_EVENTTYPE_* in the hypervisor ABI.
> 
> This is probably fine as it is an ABI inherited from VT-x/SVM (and by
> some miracle, are actually compatible), but you do need to move the
> constants into the public API as well.

I was about to make that comment too, but then checked: These
constants are already exposed (via the inject trap hypercall). While
moving them into the public header might be a good idea in general,
I don't think that belongs into this patch.

Jan


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

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

[Razvan Cojocaru]

On 11/09/2016 04:04 PM, Jan Beulich wrote:
 On 09.11.16 at 12:32,  wrote:
>> On 11/09/2016 01:17 PM, Jan Beulich wrote:
>> On 09.11.16 at 10:42,  wrote:
 --- a/xen/arch/x86/hvm/hvm.c
 +++ b/xen/arch/x86/hvm/hvm.c
 @@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
  }
  }
  
 -/* Inject pending hw/sw trap */
 -if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
 -{
 +/* Inject pending hw/sw trap if there are no other pending 
 interrupts. */
 +if ( v->arch.hvm_vcpu.inject_trap.vector != -1 && 
 !hvm_event_pending(v) )
  hvm_inject_trap(>arch.hvm_vcpu.inject_trap);
 -v->arch.hvm_vcpu.inject_trap.vector = -1;
 +
 +v->arch.hvm_vcpu.inject_trap.vector = -1;
>>>
>>> I don't see why you pull this out of the if() body.
>>
>> That is intended, and covered by the "the patch also fixes the behaviour
>> of the xc_hvm_inject_trap() hypercall, which would lead to
>> non-architectural interrupts overwriting pending (specifically
>> reinjected) architectural ones" part of the patch description.
>>
>> If we couldn't inject the trap because there was a pending event (i.e.
>> the second if() condition, then not setting
>> v->arch.hvm_vcpu.inject_trap.vector to -1 would lead to the trap being
>> kept for injection at the first opportunity - and that could be when the
>> context has changed and we shouldn't inject it anymore. So
>> v->arch.hvm_vcpu.inject_trap.vector is therefore reset either way.
> 
> Ah, that's because you extend the condition. How about you leave
> the condition as is, and only make the actual call conditonal
> upon hvm_event_pending()'s return value? That's also make the
> patch better readable.

Of course, no problem.


Thanks,
Razvan

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

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

[Jan Beulich]

>>> On 09.11.16 at 12:32,  wrote:
> On 11/09/2016 01:17 PM, Jan Beulich wrote:
> On 09.11.16 at 10:42,  wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
>>>  }
>>>  }
>>>  
>>> -/* Inject pending hw/sw trap */
>>> -if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>>> -{
>>> +/* Inject pending hw/sw trap if there are no other pending interrupts. 
>>> */
>>> +if ( v->arch.hvm_vcpu.inject_trap.vector != -1 && 
>>> !hvm_event_pending(v) )
>>>  hvm_inject_trap(>arch.hvm_vcpu.inject_trap);
>>> -v->arch.hvm_vcpu.inject_trap.vector = -1;
>>> +
>>> +v->arch.hvm_vcpu.inject_trap.vector = -1;
>> 
>> I don't see why you pull this out of the if() body.
> 
> That is intended, and covered by the "the patch also fixes the behaviour
> of the xc_hvm_inject_trap() hypercall, which would lead to
> non-architectural interrupts overwriting pending (specifically
> reinjected) architectural ones" part of the patch description.
> 
> If we couldn't inject the trap because there was a pending event (i.e.
> the second if() condition, then not setting
> v->arch.hvm_vcpu.inject_trap.vector to -1 would lead to the trap being
> kept for injection at the first opportunity - and that could be when the
> context has changed and we shouldn't inject it anymore. So
> v->arch.hvm_vcpu.inject_trap.vector is therefore reset either way.

Ah, that's because you extend the condition. How about you leave
the condition as is, and only make the actual call conditonal
upon hvm_event_pending()'s return value? That's also make the
patch better readable.

Jan


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

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

[Razvan Cojocaru]

On 11/09/2016 01:17 PM, Jan Beulich wrote:
>> @@ -259,6 +266,13 @@ struct vm_event_cpuid {
>> >  uint32_t _pad;
>> >  };
>> >  
>> > +struct vm_event_interrupt {
>> > +uint32_t vector;
>> > +uint32_t type;
>> > +uint32_t error_code;
>> > +uint64_t cr2;
>> > +};
> This being x86-specific, I think it should be named or union-ized
> accordingly.

I think I should also pad this to be a multiple of 64 bits as the others
are (with a uint32_t _pad; member).


Thanks,
Razvan

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

Re: [Xen-devel] [RFC PATCH 13/24] ARM: vITS: handle CLEAR command

[Julien Grall]

Hi,

On 09/11/16 00:39, Stefano Stabellini wrote:

On Wed, 28 Sep 2016, Andre Przywara wrote:

This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.

In addition this patch introduces the lookup function which translates
a given DeviceID/EventID pair into a pointer to our vITTE structure.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-its.c | 115 
 1 file changed, 115 insertions(+)

diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index 875b992..99d9e9c 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -61,6 +61,73 @@ struct vits_itte
 uint64_t collection:16;
 };

+#define UNMAPPED_COLLECTION  ((uint16_t)~0)
+
+/* Must be called with the ITS lock held. */
+static struct vcpu *get_vcpu_from_collection(struct virt_its *its, int collid)
+{
+uint16_t vcpu_id;
+
+if ( collid >= its->max_collections )
+return NULL;
+
+vcpu_id = its->coll_table[collid];
+if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
+return NULL;
+
+return its->d->vcpu[vcpu_id];
+}
+
+#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
+#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(7, 0)) + 1))
+#define DEV_TABLE_ENTRY(addr, bits) \
+(((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(7, 0)))
+
+static paddr_t get_itte_address(struct virt_its *its,
+uint32_t devid, uint32_t evid)
+{
+paddr_t addr;
+
+if ( devid >= its->max_devices )
+return ~0;


Please #define the error


Technically this should be INVALID_PADDR here.




+if ( evid >= DEV_TABLE_ITT_SIZE(its->dev_table[devid]) )
+return ~0;


same here


Ditto.





+addr = DEV_TABLE_ITT_ADDR(its->dev_table[devid]);
+
+return addr + evid * sizeof(struct vits_itte);
+}
+
+/* Looks up a given deviceID/eventID pair on an ITS and returns a pointer to
+ * the corresponding ITTE. This maps the respective guest page into Xen.
+ * Once finished with handling the ITTE, call put_devid_evid() to unmap
+ * the page again.
+ * Must be called with the ITS lock held.
+ */
+static struct vits_itte *get_devid_evid(struct virt_its *its,
+uint32_t devid, uint32_t evid)
+{
+paddr_t addr = get_itte_address(its, devid, evid);
+struct vits_itte *itte;
+
+if (addr == ~0)
+return NULL;
+
+/* TODO: check locking for map_guest_pages() */
+itte = map_guest_pages(its->d, addr & PAGE_MASK, 1);
+if ( !itte )
+return NULL;


No need to use the vmap to map 1 page


But you do have to translate the IPA to a PA, so you cannot directly use 
__pa on it.





+return itte + (addr & ~PAGE_MASK) / sizeof(struct vits_itte);


Please use () around the div operation for clarity



+}
+
+/* Must be called with the ITS lock held. */
+static void put_devid_evid(struct virt_its *its, struct vits_itte *itte)
+{
+unmap_guest_pages(itte, 1);


No need for this, once you use __pa instead of the vmap


Well, we should at least use map_domain_page/unmap_domain_page even if 
they are a nop on ARM64. And not directly __pa.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 2/2] Partially revert 21550029f709072aacf3b90edd574e7d3021b400

[Julien Grall]

Hi Stefano,

On 08/11/16 19:42, Stefano Stabellini wrote:

@@ -1189,7 +1194,10 @@ static int __init gicv2_init(void)
 printk(XENLOG_WARNING
"GICv2: Adjusting CPU interface base to %#"PRIx64"\n",
cbase + aliased_offset);
-}
+} else if ( csize == SZ_128K )
+printk(XENLOG_WARNING
+"GICv2: GICC size=%lu but not aliased\n",
+csize);


The indentation looks wrong here.

With that:

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  bcb13635fa503113c981c6ea7423f930c1548452
baseline version:
 xen  8a35a95615b1a64c98c30195f343bc2c58054d9d

Last test of basis   102008  2016-11-07 16:52:13 Z1 days
Testing same since   102027  2016-11-08 04:30:42 Z1 days2 attempts


People who touched revisions under test:
  Jan Beulich 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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
 

[Xen-devel] [linux-3.4 test] 102041: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 92983
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 92983
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot   fail REGR. vs. 92983
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
92983
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101695 pass 
in 102041
 test-amd64-amd64-i386-pvgrub  6 xen-boot   fail pass in 101695
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 101695
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101695
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101720
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101720
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101822
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot  fail pass in 101840
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail pass in 101840
 test-amd64-amd64-amd64-pvgrub  6 xen-boot  fail pass in 101867
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101867
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101867
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host fail pass in 101951
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 101951
 test-amd64-amd64-pair 9 xen-boot/src_host  fail pass in 101951
 test-amd64-amd64-pair10 xen-boot/dst_host  fail pass in 101951

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

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

version targeted for testing:
 linux8d1988f838a95e836342b505398d38b223181f17
baseline version:
 linux343a5fbeef08baf2097b8cf4e26137cebe3cfef4

Last test of basis92983  2016-04-27 16:21:44 Z  195 days
Testing same since   101695  2016-10-26 18:26:23 Z   13 days   20 attempts


People who touched revisions under test:
  "Suzuki K. Poulose" 
  Aaro Koskinen 
  Al Viro 
  Alan Stern 
  Aleksander Morgado 
  Alex Thorlton 
  Alexandru Cornea 
  Alexey Khoroshilov 
  Amitkumar Karwar 
  Andrew Banman 
  Andrew Morton 
  Andrey Ryabinin 
  Anson Huang 
  Arnaldo Carvalho de Melo 
  

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

[Andrew Cooper]

The original code has a bug; eax and edx get unconditionally updated even when
hvm_msr_read_intercept() doesn't return X86EMUL_OKAY.

It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content
pointer) that this isn't an information leak into guests.

While fixing this bug, reduce the scope of msr_content and initialise it to 0.
This makes it obvious that a stack leak won't occur, even if there were to be
a buggy codepath in hvm_msr_read_intercept().

Also make some non-functional improvements.  Make the insn_len calculation
common, and reduce the quantity of explicit casting by making better use of
the existing register names.

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

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 16427f6..6530e22 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1948,26 +1948,28 @@ static int svm_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 
 static void svm_do_msr_access(struct cpu_user_regs *regs)
 {
-int rc, inst_len;
 struct vcpu *v = current;
-struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
-uint64_t msr_content;
+bool rdmsr = v->arch.hvm_svm.vmcb->exitinfo1 == 0;
+int rc, inst_len = __get_instruction_length(
+v, rdmsr ? INSTR_RDMSR : INSTR_WRMSR);
+
+if ( inst_len == 0 )
+return;
 
-if ( vmcb->exitinfo1 == 0 )
+if ( rdmsr )
 {
-if ( (inst_len = __get_instruction_length(v, INSTR_RDMSR)) == 0 )
-return;
-rc = hvm_msr_read_intercept(regs->ecx, _content);
-regs->eax = (uint32_t)msr_content;
-regs->edx = (uint32_t)(msr_content >> 32);
+uint64_t msr_content = 0;
+
+rc = hvm_msr_read_intercept(regs->_ecx, _content);
+if ( rc == X86EMUL_OKAY )
+{
+regs->rax = (uint32_t)msr_content;
+regs->rdx = (uint32_t)(msr_content >> 32);
+}
 }
 else
-{
-if ( (inst_len = __get_instruction_length(v, INSTR_WRMSR)) == 0 )
-return;
-msr_content = ((uint64_t)regs->edx << 32) | (uint32_t)regs->eax;
-rc = hvm_msr_write_intercept(regs->ecx, msr_content, 1);
-}
+rc = hvm_msr_write_intercept(regs->_ecx,
+ (regs->rdx << 32) | regs->_eax, 1);
 
 if ( rc == X86EMUL_OKAY )
 __update_guest_eip(regs, inst_len);
-- 
2.1.4


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

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

[Julien Grall]

Hello,

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

On 08.11.2016 16:41, Iurii Mykhalskyi wrote:

Hello Dirk,

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



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

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

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


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


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


Regards,

--
Julien Grall

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

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

[Andrew Cooper]

On 09/11/16 08:25, Jan Beulich wrote:
> There are two cases where this was wrong, albeit in a benign way (the
> compiler - according to my checking - didn't leverage the wrongness
> for any optimizations affecting overall outcome).
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] question: is it a CVE in relinquish_memory()[xen/arch/x86/domain.c]

[Xuquan (Quan Xu)]

Hi,
Based on CVE-2015-7814 and commit 1ef01396fdff, ' arm: handle races between 
relinquish_memory and free_domheap_pages'..
relinquish_memory() [xen/arch/arm/domain.c, arm code], 
when couldn't get a reference -- someone is freeing this page and has already 
committed to doing so, so no more to do here, continue.


But in relinquish_memory()[xen/arch/x86/domain.c, __x86__ code], when couldn't 
get a reference -- someone is freeing this page,
Why adding this page to d->arch.relmem_list again. 
Is it a CVE to double free page, then hit the ''" alloc_heap_pages() : 
BUG_ON(pg[i].count_info != PGC_state_free)"" in creating guests later..






[1] CVE-2015-7814
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7814

[2] commit 1ef01396fdff

commit 1ef01396fdff88b1c3331a09ca5c69619b90f4ea
Author: Ian Campbell 
Date:   Thu Oct 29 13:34:17 2015 +0100

arm: handle races between relinquish_memory and free_domheap_pages

Primarily this means XENMEM_decrease_reservation from a toolstack
domain.

Unlike x86 we have no requirement right now to queue such pages onto
a separate list, if we hit this race then the other code has already
fully accepted responsibility for freeing this page and therefore
there is no more for relinquish_memory to do.

This is CVE-2015-7814 / XSA-147.

Signed-off-by: Ian Campbell 
Reviewed-by: Julien Grall 
Reviewed-by: Jan Beulich 

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 683e769..880d0a6 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -772,8 +772,15 @@ static int relinquish_memory(struct domain *d, struct 
page_list_head *list)
 {
 /* Grab a reference to the page so it won't disappear from under us. */
 if ( unlikely(!get_page(page, d)) )
-/* Couldn't get a reference -- someone is freeing this page. */
-BUG();
+/*
+ * Couldn't get a reference -- someone is freeing this page and
+ * has already committed to doing so, so no more to do here.
+ *
+ * Note that the page must be left on the list, a list_del
+ * here will clash with the list_del done by the other
+ * party in the race and corrupt the list head.
+ */
+continue;

 if ( test_and_clear_bit(_PGC_allocated, >count_info) )
 put_page(page);
~


Quan

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

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

[Andrew Cooper]

On 08/11/16 16:22, Roger Pau Monne wrote:
> Commit fac7f7 changed the value of ptr so that it points to the right memory
> area, taking the page offset into account, but failed to remove this when
> doing the unmap, which caused the region to not be unmapped. Fix this by not
> modifying ptr and instead adding the page offset directly in the memcpy
> call.

Coverity-ID: 1394285

(Coverity scan has now run and found this issue, so we have a public ID
to use).

> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

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

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

[Andrew Cooper]

On 09/11/16 11:32, Razvan Cojocaru wrote:
> On 11/09/2016 01:17 PM, Jan Beulich wrote:
> On 09.11.16 at 10:42,  wrote:
>>> Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
>>> which is now fired in a one-shot manner when enabled via the new
>>> VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
>>> The patch also fixes the behaviour of the xc_hvm_inject_trap()
>>> hypercall, which would lead to non-architectural interrupts
>>> overwriting pending (specifically reinjected) architectural ones.
>> Looks quite okay, just some more or less mechanical comments.
>>
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
>>>  }
>>>  }
>>>  
>>> -/* Inject pending hw/sw trap */
>>> -if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>>> -{
>>> +/* Inject pending hw/sw trap if there are no other pending interrupts. 
>>> */
>>> +if ( v->arch.hvm_vcpu.inject_trap.vector != -1 && 
>>> !hvm_event_pending(v) )
>>>  hvm_inject_trap(>arch.hvm_vcpu.inject_trap);
>>> -v->arch.hvm_vcpu.inject_trap.vector = -1;
>>> +
>>> +v->arch.hvm_vcpu.inject_trap.vector = -1;
>> I don't see why you pull this out of the if() body.
> That is intended, and covered by the "the patch also fixes the behaviour
> of the xc_hvm_inject_trap() hypercall, which would lead to
> non-architectural interrupts overwriting pending (specifically
> reinjected) architectural ones" part of the patch description.
>
> If we couldn't inject the trap because there was a pending event (i.e.
> the second if() condition, then not setting
> v->arch.hvm_vcpu.inject_trap.vector to -1 would lead to the trap being
> kept for injection at the first opportunity - and that could be when the
> context has changed and we shouldn't inject it anymore. So
> v->arch.hvm_vcpu.inject_trap.vector is therefore reset either way.
>
>>> +if ( unlikely(v->arch.vm_event) &&
>>> +v->arch.vm_event->monitor_next_interrupt )
>> Hard tab.
> I'll fix it.
>
>>> --- a/xen/arch/x86/hvm/monitor.c
>>> +++ b/xen/arch/x86/hvm/monitor.c
>>> @@ -150,6 +150,21 @@ int hvm_monitor_cpuid(unsigned long insn_length, 
>>> unsigned int leaf,
>>>  return monitor_traps(curr, 1, );
>>>  }
>>>  
>>> +void hvm_monitor_interrupt(unsigned int vector, unsigned int type,
>>> +   unsigned int err, uint64_t cr2)
>>> +{
>>> +struct vcpu *curr = current;
>> Pointless local variable (used just once).
> I'll remove it.
>
>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>> @@ -2220,6 +2220,21 @@ static void svm_invlpg(struct vcpu *v, unsigned long 
>>> vaddr)
>>>  svm_asid_g_invlpg(v, vaddr);
>>>  }
>>>  
>>> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>>> +{
>>> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>>> +
>>> +if ( vmcb->eventinj.fields.v )
>>> +return false;
>>> +
>>> +info->vector = vmcb->eventinj.fields.vector;
>>> +info->type = vmcb->eventinj.fields.type;
>>> +info->error_code = vmcb->eventinj.fields.errorcode;
>>> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
>> I'd prefer for this last part to be put into generic code (i.e. the
>> wrapper).
> You mean setting CR2, which is common, right? I'll move it to the wrapper.
>
>>> --- a/xen/include/asm-arm/vm_event.h
>>> +++ b/xen/include/asm-arm/vm_event.h
>>> @@ -52,4 +52,10 @@ void vm_event_emulate_check(struct vcpu *v, 
>>> vm_event_response_t *rsp)
>>>  /* Not supported on ARM. */
>>>  }
>>>  
>>> +static inline
>>> +void vm_event_monitor_next_interrupt(struct vcpu *v)
>>> +{
>>> +/* Not supported on ARM. */
>>> +}
>> That's unfortunate. If it can't be implemented, shouldn't the caller at
>> least be advised of this being unavailable? Wasn't there even some
>> mechanism to report capabilities?
> Yes, I forgot to update the capabilities list. Good point, I'll see
> about that as well.
>
>>> --- a/xen/include/asm-x86/hvm/hvm.h
>>> +++ b/xen/include/asm-x86/hvm/hvm.h
>>> @@ -237,6 +237,8 @@ struct hvm_function_table {
>>>  /* Architecture function to setup TSC scaling ratio */
>>>  void (*setup)(struct vcpu *v);
>>>  } tsc_scaling;
>>> +
>>> +bool (*get_pending_event)(struct vcpu *v, struct hvm_trap *info);
>>>  };
>> Stylistically I think this would better go a little earlier.
> I'll move it after event_pending.
>
>>> --- a/xen/include/asm-x86/vm_event.h
>>> +++ b/xen/include/asm-x86/vm_event.h
>>> @@ -32,6 +32,7 @@ struct arch_vm_event {
>>>  struct vm_event_emul_insn_data insn;
>>>  } emul;
>>>  struct monitor_write_data write_data;
>>> +bool monitor_next_interrupt;
>>>  };
>> I think there's a 32-bit padding hole before write_data, so the new
>> field would better go earlier (perhaps even right after flags).
> I'll move it there.
>
>>> @@ -139,6 +144,8 @@
>>>   *   These kinds of events will be filtered out in 

Re: [Xen-devel] CPUID improvements (phase 2) Design Doc

[Andrew Cooper]

On 09/11/16 08:31, Jan Beulich wrote:
 On 08.11.16 at 19:36,  wrote:
>> On 08/11/16 16:32, Jan Beulich wrote:
>> On 08.11.16 at 16:35,  wrote:
 Please find inline the design doc for further CPUID improvements, planned 
 for
 development during the 4.9 timeframe.
>>> Looks good, just a couple of minor remarks.
>>>
 ## Changes in hypercall behaviour

 During domain construction, some pieces of information critical to the
 determination of the domains maximum acceptable CPUID policy are available
 right from the very start (Most notably, the HVM and HAP flags from the
 `XEN_DOMCTL_createdomain`).

 However, some other parameters are not available at convenient points.

 1.  The disable flag from `XEN_DOMCTL_disable_migrate` is used to set
 `d->disable_migrate`, whose only purpose is to avoid the unconditional
 clobbering of the Invariant TSC flag.  This flag cannot even be 
 queried by
 the toolstack once set.

 There are other facilities which should be restricted based on whether 
 a
 VM might migrate or not.  (e.g. The use of LBR, whose record format is
 hardware specific.)
>>> Not really - the LBR format only limits the set of hosts the VM can
>>> migrate to. I.e. this is just like a CPUID flag which needs to be set
>>> on the target host in order for the VM to be permitted to migrate
>>> there.
>> It is more complicated than that.  The LBR format also depends on
>> whether TSX is enabled or not, which on Haswell-WS CPUs depends on
>> whether hyperthreading is enabled.
> Yes, but is this relevant? It's still only a value (identifying the format)
> which needs to match between source and destination hosts. I.e. not
> different from individual feature bits, just that here we're dealing with
> a multi-bit entity.

LBR format is controlled by IA32_PERF_CAPABILITIES[5:0], which I will
eventually get to covering with MSR levelling, with this being a
strictly non-levelable field.

Users' expectations when migrating a VM is that it should be able to go
anywhere.  In practice, this is only insofar as we can maintain
compatibility.  We should default to being as compatible as possible; if
a user asks for both migrateable and LBR, then thats fine as it comes
with an understanding of reduced mobility.

~Andrew

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

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

[Razvan Cojocaru]

On 11/09/2016 01:17 PM, Jan Beulich wrote:
 On 09.11.16 at 10:42,  wrote:
>> Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
>> which is now fired in a one-shot manner when enabled via the new
>> VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
>> The patch also fixes the behaviour of the xc_hvm_inject_trap()
>> hypercall, which would lead to non-architectural interrupts
>> overwriting pending (specifically reinjected) architectural ones.
> 
> Looks quite okay, just some more or less mechanical comments.
> 
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
>>  }
>>  }
>>  
>> -/* Inject pending hw/sw trap */
>> -if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>> -{
>> +/* Inject pending hw/sw trap if there are no other pending interrupts. 
>> */
>> +if ( v->arch.hvm_vcpu.inject_trap.vector != -1 && !hvm_event_pending(v) 
>> )
>>  hvm_inject_trap(>arch.hvm_vcpu.inject_trap);
>> -v->arch.hvm_vcpu.inject_trap.vector = -1;
>> +
>> +v->arch.hvm_vcpu.inject_trap.vector = -1;
> 
> I don't see why you pull this out of the if() body.

That is intended, and covered by the "the patch also fixes the behaviour
of the xc_hvm_inject_trap() hypercall, which would lead to
non-architectural interrupts overwriting pending (specifically
reinjected) architectural ones" part of the patch description.

If we couldn't inject the trap because there was a pending event (i.e.
the second if() condition, then not setting
v->arch.hvm_vcpu.inject_trap.vector to -1 would lead to the trap being
kept for injection at the first opportunity - and that could be when the
context has changed and we shouldn't inject it anymore. So
v->arch.hvm_vcpu.inject_trap.vector is therefore reset either way.

>> +if ( unlikely(v->arch.vm_event) &&
>> + v->arch.vm_event->monitor_next_interrupt )
> 
> Hard tab.

I'll fix it.

>> --- a/xen/arch/x86/hvm/monitor.c
>> +++ b/xen/arch/x86/hvm/monitor.c
>> @@ -150,6 +150,21 @@ int hvm_monitor_cpuid(unsigned long insn_length, 
>> unsigned int leaf,
>>  return monitor_traps(curr, 1, );
>>  }
>>  
>> +void hvm_monitor_interrupt(unsigned int vector, unsigned int type,
>> +   unsigned int err, uint64_t cr2)
>> +{
>> +struct vcpu *curr = current;
> 
> Pointless local variable (used just once).

I'll remove it.

>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -2220,6 +2220,21 @@ static void svm_invlpg(struct vcpu *v, unsigned long 
>> vaddr)
>>  svm_asid_g_invlpg(v, vaddr);
>>  }
>>  
>> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>> +{
>> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>> +
>> +if ( vmcb->eventinj.fields.v )
>> +return false;
>> +
>> +info->vector = vmcb->eventinj.fields.vector;
>> +info->type = vmcb->eventinj.fields.type;
>> +info->error_code = vmcb->eventinj.fields.errorcode;
>> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
> 
> I'd prefer for this last part to be put into generic code (i.e. the
> wrapper).

You mean setting CR2, which is common, right? I'll move it to the wrapper.

>> --- a/xen/include/asm-arm/vm_event.h
>> +++ b/xen/include/asm-arm/vm_event.h
>> @@ -52,4 +52,10 @@ void vm_event_emulate_check(struct vcpu *v, 
>> vm_event_response_t *rsp)
>>  /* Not supported on ARM. */
>>  }
>>  
>> +static inline
>> +void vm_event_monitor_next_interrupt(struct vcpu *v)
>> +{
>> +/* Not supported on ARM. */
>> +}
> 
> That's unfortunate. If it can't be implemented, shouldn't the caller at
> least be advised of this being unavailable? Wasn't there even some
> mechanism to report capabilities?

Yes, I forgot to update the capabilities list. Good point, I'll see
about that as well.

>> --- a/xen/include/asm-x86/hvm/hvm.h
>> +++ b/xen/include/asm-x86/hvm/hvm.h
>> @@ -237,6 +237,8 @@ struct hvm_function_table {
>>  /* Architecture function to setup TSC scaling ratio */
>>  void (*setup)(struct vcpu *v);
>>  } tsc_scaling;
>> +
>> +bool (*get_pending_event)(struct vcpu *v, struct hvm_trap *info);
>>  };
> 
> Stylistically I think this would better go a little earlier.

I'll move it after event_pending.

>> --- a/xen/include/asm-x86/vm_event.h
>> +++ b/xen/include/asm-x86/vm_event.h
>> @@ -32,6 +32,7 @@ struct arch_vm_event {
>>  struct vm_event_emul_insn_data insn;
>>  } emul;
>>  struct monitor_write_data write_data;
>> +bool monitor_next_interrupt;
>>  };
> 
> I think there's a 32-bit padding hole before write_data, so the new
> field would better go earlier (perhaps even right after flags).

I'll move it there.

>> @@ -139,6 +144,8 @@
>>   *   These kinds of events will be filtered out in future versions.
>>   */
>>  #define VM_EVENT_REASON_PRIVILEGED_CALL 11
>> +/* Result of toolstack-requested (non-architectural) trap injection. 

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

[Jan Beulich]

>>> On 09.11.16 at 10:42,  wrote:
> Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
> which is now fired in a one-shot manner when enabled via the new
> VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
> The patch also fixes the behaviour of the xc_hvm_inject_trap()
> hypercall, which would lead to non-architectural interrupts
> overwriting pending (specifically reinjected) architectural ones.

Looks quite okay, just some more or less mechanical comments.

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
>  }
>  }
>  
> -/* Inject pending hw/sw trap */
> -if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
> -{
> +/* Inject pending hw/sw trap if there are no other pending interrupts. */
> +if ( v->arch.hvm_vcpu.inject_trap.vector != -1 && !hvm_event_pending(v) )
>  hvm_inject_trap(>arch.hvm_vcpu.inject_trap);
> -v->arch.hvm_vcpu.inject_trap.vector = -1;
> +
> +v->arch.hvm_vcpu.inject_trap.vector = -1;

I don't see why you pull this out of the if() body.

> +if ( unlikely(v->arch.vm_event) &&
> +  v->arch.vm_event->monitor_next_interrupt )

Hard tab.

> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -150,6 +150,21 @@ int hvm_monitor_cpuid(unsigned long insn_length, 
> unsigned int leaf,
>  return monitor_traps(curr, 1, );
>  }
>  
> +void hvm_monitor_interrupt(unsigned int vector, unsigned int type,
> +   unsigned int err, uint64_t cr2)
> +{
> +struct vcpu *curr = current;

Pointless local variable (used just once).

> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2220,6 +2220,21 @@ static void svm_invlpg(struct vcpu *v, unsigned long 
> vaddr)
>  svm_asid_g_invlpg(v, vaddr);
>  }
>  
> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
> +{
> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> +
> +if ( vmcb->eventinj.fields.v )
> +return false;
> +
> +info->vector = vmcb->eventinj.fields.vector;
> +info->type = vmcb->eventinj.fields.type;
> +info->error_code = vmcb->eventinj.fields.errorcode;
> +info->cr2 = v->arch.hvm_vcpu.guest_cr[2];

I'd prefer for this last part to be put into generic code (i.e. the
wrapper).

> --- a/xen/include/asm-arm/vm_event.h
> +++ b/xen/include/asm-arm/vm_event.h
> @@ -52,4 +52,10 @@ void vm_event_emulate_check(struct vcpu *v, 
> vm_event_response_t *rsp)
>  /* Not supported on ARM. */
>  }
>  
> +static inline
> +void vm_event_monitor_next_interrupt(struct vcpu *v)
> +{
> +/* Not supported on ARM. */
> +}

That's unfortunate. If it can't be implemented, shouldn't the caller at
least be advised of this being unavailable? Wasn't there even some
mechanism to report capabilities?

> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -237,6 +237,8 @@ struct hvm_function_table {
>  /* Architecture function to setup TSC scaling ratio */
>  void (*setup)(struct vcpu *v);
>  } tsc_scaling;
> +
> +bool (*get_pending_event)(struct vcpu *v, struct hvm_trap *info);
>  };

Stylistically I think this would better go a little earlier.

> --- a/xen/include/asm-x86/vm_event.h
> +++ b/xen/include/asm-x86/vm_event.h
> @@ -32,6 +32,7 @@ struct arch_vm_event {
>  struct vm_event_emul_insn_data insn;
>  } emul;
>  struct monitor_write_data write_data;
> +bool monitor_next_interrupt;
>  };

I think there's a 32-bit padding hole before write_data, so the new
field would better go earlier (perhaps even right after flags).

> @@ -139,6 +144,8 @@
>   *   These kinds of events will be filtered out in future versions.
>   */
>  #define VM_EVENT_REASON_PRIVILEGED_CALL 11
> +/* Result of toolstack-requested (non-architectural) trap injection. */
> +#define VM_EVENT_REASON_INTERRUPT   12

Considering the event reports all kinds of interruptions, I don't think
the comment is appropriate.

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

This being x86-specific, I think it should be named or union-ized
accordingly.

Jan

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  bcb13635fa503113c981c6ea7423f930c1548452
baseline version:
 xen  3ebe9a1a826e8d569bef6045777cc01a5699933d

Last test of basis   101966  2016-11-06 09:19:06 Z3 days
Testing same since   102062  2016-11-09 09:21:05 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Jan Beulich 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-coverity
+ revision=bcb13635fa503113c981c6ea7423f930c1548452
+ . ./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-coverity bcb13635fa503113c981c6ea7423f930c1548452
+ branch=xen-unstable-coverity
+ revision=bcb13635fa503113c981c6ea7423f930c1548452
+ . ./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-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.7-testing
+ '[' xbcb13635fa503113c981c6ea7423f930c1548452 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : 

Re: [Xen-devel] per-domain logging

[Cedric Bosdonnat]

Hi Wei, Ian,

I now have a big lot of changes to use the LOG*D family through the libxl code.
What should be the best way to submit that for review? I guess a giant commit
won't be too easy to handle for review and maintenance, maybe I should have one
commit per changed file... any opinion on that?

--
Cedric

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

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

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

[osstest service owner]

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

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

Last test of basis   102036  2016-11-08 12:14:46 Z0 days
Testing same since   102050  2016-11-08 20:54:26 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 
  Michael Kinney 

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=008e2ccf02e7be65b3a1b48a925f005115027d1c
+ . ./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 
008e2ccf02e7be65b3a1b48a925f005115027d1c
+ branch=ovmf
+ revision=008e2ccf02e7be65b3a1b48a925f005115027d1c
+ . ./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
+ '[' x008e2ccf02e7be65b3a1b48a925f005115027d1c = 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
++ : 

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

[Razvan Cojocaru]

Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
which is now fired in a one-shot manner when enabled via the new
VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
The patch also fixes the behaviour of the xc_hvm_inject_trap()
hypercall, which would lead to non-architectural interrupts
overwriting pending (specifically reinjected) architectural ones.

Signed-off-by: Razvan Cojocaru 
---
 xen/arch/x86/hvm/hvm.c| 20 
 xen/arch/x86/hvm/monitor.c| 15 +++
 xen/arch/x86/hvm/svm/svm.c| 16 
 xen/arch/x86/hvm/vmx/vmx.c| 21 +
 xen/arch/x86/vm_event.c   |  6 ++
 xen/common/vm_event.c |  3 +++
 xen/include/asm-arm/vm_event.h|  6 ++
 xen/include/asm-x86/hvm/hvm.h |  7 +++
 xen/include/asm-x86/hvm/monitor.h |  2 ++
 xen/include/asm-x86/vm_event.h|  1 +
 xen/include/public/vm_event.h | 15 +++
 xen/include/xen/vm_event.h|  2 ++
 12 files changed, 110 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 704fd64..06c426c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
 }
 }
 
-/* Inject pending hw/sw trap */
-if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
-{
+/* Inject pending hw/sw trap if there are no other pending interrupts. */
+if ( v->arch.hvm_vcpu.inject_trap.vector != -1 && !hvm_event_pending(v) )
 hvm_inject_trap(>arch.hvm_vcpu.inject_trap);
-v->arch.hvm_vcpu.inject_trap.vector = -1;
+
+v->arch.hvm_vcpu.inject_trap.vector = -1;
+
+if ( unlikely(v->arch.vm_event) &&
+v->arch.vm_event->monitor_next_interrupt )
+{
+struct hvm_trap info;
+
+if ( hvm_get_pending_event(v, ) )
+{
+hvm_monitor_interrupt(info.vector, info.type, info.error_code,
+  info.cr2);
+v->arch.vm_event->monitor_next_interrupt = false;
+}
 }
 }
 
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 401a8c6..00b2c3b 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -150,6 +150,21 @@ int hvm_monitor_cpuid(unsigned long insn_length, unsigned 
int leaf,
 return monitor_traps(curr, 1, );
 }
 
+void hvm_monitor_interrupt(unsigned int vector, unsigned int type,
+   unsigned int err, uint64_t cr2)
+{
+struct vcpu *curr = current;
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_INTERRUPT,
+.u.interrupt.vector = vector,
+.u.interrupt.type = type,
+.u.interrupt.error_code = err,
+.u.interrupt.cr2 = cr2,
+};
+
+monitor_traps(curr, 1, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 16427f6..bba0399 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2220,6 +2220,21 @@ static void svm_invlpg(struct vcpu *v, unsigned long 
vaddr)
 svm_asid_g_invlpg(v, vaddr);
 }
 
+static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
+{
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+
+if ( vmcb->eventinj.fields.v )
+return false;
+
+info->vector = vmcb->eventinj.fields.vector;
+info->type = vmcb->eventinj.fields.type;
+info->error_code = vmcb->eventinj.fields.errorcode;
+info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
+
+return true;
+}
+
 static struct hvm_function_table __initdata svm_function_table = {
 .name = "SVM",
 .cpu_up_prepare   = svm_cpu_up_prepare,
@@ -2272,6 +2287,7 @@ static struct hvm_function_table __initdata 
svm_function_table = {
 .tsc_scaling = {
 .max_ratio = ~TSC_RATIO_RSVD_BITS,
 },
+.get_pending_event = svm_get_pending_event,
 };
 
 void svm_vmexit_handler(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 9a8f694..6f64033 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2134,6 +2134,26 @@ static int vmx_set_mode(struct vcpu *v, int mode)
 return 0;
 }
 
+static bool vmx_get_pending_event(struct vcpu *v, struct hvm_trap *info)
+{
+unsigned long intr_info, error_code;
+
+vmx_vmcs_enter(v);
+__vmread(VM_ENTRY_INTR_INFO, _info);
+__vmread(VM_ENTRY_EXCEPTION_ERROR_CODE, _code);
+vmx_vmcs_exit(v);
+
+if ( !(intr_info & INTR_INFO_VALID_MASK) )
+return false;
+
+info->vector = MASK_EXTR(intr_info, INTR_INFO_VECTOR_MASK);
+info->type = MASK_EXTR(intr_info, INTR_INFO_INTR_TYPE_MASK);
+info->error_code = error_code;
+info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
+
+return true;
+}
+
 static struct hvm_function_table __initdata vmx_function_table = {
 .name = "VMX",
 .cpu_up_prepare   

[Xen-devel] [linux-3.10 test] 102032: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 100648
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 100648
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-credit2   6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 100648

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 101947 pass in 
102032
 test-amd64-i386-libvirt-xsm   9 debian-install   fail in 101783 pass in 101975
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail pass in 101594
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101663
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101680
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot  fail pass in 101680
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101731
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot   fail pass in 101731
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host fail pass in 101731
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 101731
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot fail pass in 101783
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot   fail pass in 101783
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-amd64-qemuu-nested-intel  6 xen-bootfail pass in 101814
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101828
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101828
 test-amd64-amd64-pair 9 xen-boot/src_host  fail pass in 101828
 test-amd64-amd64-pair10 xen-boot/dst_host  fail pass in 101828
 test-amd64-amd64-xl-multivcpu  6 xen-boot  fail pass in 101837
 test-amd64-i386-freebsd10-i386  6 xen-boot fail pass in 101837
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot  fail pass in 101844
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail pass in 101844
 test-amd64-amd64-xl-xsm   6 xen-boot   fail pass in 101856
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101947
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail pass in 101958
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 101958
 test-amd64-i386-libvirt-xsm   6 xen-boot   fail pass in 101975
 test-amd64-amd64-libvirt  6 xen-boot   fail pass in 101975
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 101975

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt 12 migrate-support-check fail in 101680 never pass
 test-amd64-i386-libvirt-xsm 12 migrate-support-check fail in 101680 never pass
 test-amd64-amd64-libvirt12 migrate-support-check fail in 101680 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 101680 never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 101680 never pass
 build-i386-rumprun7 xen-buildfail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-check

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

[Wu, Feng]

> 
> > 2. if previous p is 1 and it is in remapped mode, we can only set it to
> > remapped mode in _this_ function, setting it to posted mode is in
> > another function: pi_update_irte().
> 
> Which may be part of the problem: Why are there two functions?
> 
I think the reason is that pi_update_irte() was introduced when we first
enabled VT-d PI, and this patch handles some cases which need to be
done in msi_msg_to_remap_entry(). But I think your suggestion here
is good, I am thinking of calling msi_msg_to_remap_entry() (Need to add
new parameter to this function) in pi_update_irte().

Thanks,
Feng

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

Re: [Xen-devel] [PATCH v3 00/15] Enable L2 Cache Allocation Technology

[Jan Beulich]

>>> On 09.11.16 at 02:28,  wrote:
> Any comment or suggestion to this patch set? That would be very appreciated.

Please be assured that this has not been forgotten, but there are
more important things to deal with, so it may take some more time
to get to this. That's both because this clearly is for 4.9 only, and
because it affecting Atoms only for now its relatively low priority
only anyway (to date Atoms aren't a primary target for Xen afaict).

Jan


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

Re: [Xen-devel] CPUID improvements (phase 2) Design Doc

[Jan Beulich]

>>> On 08.11.16 at 19:36,  wrote:
> On 08/11/16 16:32, Jan Beulich wrote:
> On 08.11.16 at 16:35,  wrote:
>>> Please find inline the design doc for further CPUID improvements, planned 
>>> for
>>> development during the 4.9 timeframe.
>> Looks good, just a couple of minor remarks.
>>
>>> ## Changes in hypercall behaviour
>>>
>>> During domain construction, some pieces of information critical to the
>>> determination of the domains maximum acceptable CPUID policy are available
>>> right from the very start (Most notably, the HVM and HAP flags from the
>>> `XEN_DOMCTL_createdomain`).
>>>
>>> However, some other parameters are not available at convenient points.
>>>
>>> 1.  The disable flag from `XEN_DOMCTL_disable_migrate` is used to set
>>> `d->disable_migrate`, whose only purpose is to avoid the unconditional
>>> clobbering of the Invariant TSC flag.  This flag cannot even be queried 
>>> by
>>> the toolstack once set.
>>>
>>> There are other facilities which should be restricted based on whether a
>>> VM might migrate or not.  (e.g. The use of LBR, whose record format is
>>> hardware specific.)
>> Not really - the LBR format only limits the set of hosts the VM can
>> migrate to. I.e. this is just like a CPUID flag which needs to be set
>> on the target host in order for the VM to be permitted to migrate
>> there.
> 
> It is more complicated than that.  The LBR format also depends on
> whether TSX is enabled or not, which on Haswell-WS CPUs depends on
> whether hyperthreading is enabled.

Yes, but is this relevant? It's still only a value (identifying the format)
which needs to match between source and destination hosts. I.e. not
different from individual feature bits, just that here we're dealing with
a multi-bit entity.

Jan


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

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

[Roger Pau Monne]

On Tue, Nov 08, 2016 at 12:19:06PM -0500, Boris Ostrovsky wrote:
> 
> 
> On 11/08/2016 11:22 AM, Roger Pau Monne wrote:
> > Commit fac7f7 changed the value of ptr so that it points to the right memory
> > area, taking the page offset into account, but failed to remove this when
> > doing the unmap, which caused the region to not be unmapped. Fix this by not
> > modifying ptr and instead adding the page offset directly in the memcpy
> > call.
> > 
> > Reported-by: Andrew Cooper 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Wei Liu 
> > Cc: Andrew Cooper 
> > Cc: Boris Ostrovsky 
> > Cc: Ian Jackson 
> > ---
> >  tools/libxc/xc_dom_core.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> > index ad819dd..36cd3c8 100644
> > --- a/tools/libxc/xc_dom_core.c
> > +++ b/tools/libxc/xc_dom_core.c
> > @@ -1119,10 +1119,9 @@ static int xc_dom_load_acpi(struct xc_dom_image *dom)
> >  goto err;
> >  }
> > 
> > -ptr = (uint8_t *)ptr +
> > -  (dom->acpi_modules[i].guest_addr_out & ~XC_PAGE_MASK);
> > -
> > -memcpy(ptr, dom->acpi_modules[i].data, 
> > dom->acpi_modules[i].length);
> > +memcpy((uint8_t *)ptr +
> > +   (dom->acpi_modules[i].guest_addr_out & ~XC_PAGE_MASK),
> > +   dom->acpi_modules[i].data, dom->acpi_modules[i].length);
> >  munmap(ptr, XC_PAGE_SIZE * num_pages);
> > 
> >  free(extents);
> > 
> 
> 
> Reviewed-by: Boris Ostrovsky 
> 
> (Although I don't think this would cause memory not to be unmapped: per
> Linux man page "All pages containing a part of the indicated range are
> unmapped ..." and ptr is offset from its original value by a fraction of a
> page.)

Linux man page states:

"The implementation shall require that addr be a multiple of the page size 
{PAGESIZE}."

And on FreeBSD:

"The munmap() system call will fail if: The addr argument was not page 
aligned, [...]"

Roger.

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

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

[Jan Beulich]

There are two cases where this was wrong, albeit in a benign way (the
compiler - according to my checking - didn't leverage the wrongness
for any optimizations affecting overall outcome).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3683,7 +3683,7 @@ x86_emulate(
 if ( (rc = ops->read(src.mem.seg, src.mem.off,
  , src.bytes, ctxt)) != 0 )
 goto done;
-emulate_fpu_insn_memdst("fldt", src.val);
+emulate_fpu_insn_memsrc("fldt", src.val);
 break;
 case 7: /* fstp m80fp */
 ea.bytes = 10;
@@ -3780,7 +3780,7 @@ x86_emulate(
 ea.bytes = 8;
 dst = ea;
 dst.type = OP_MEM;
-emulate_fpu_insn_memsrc("fstl", dst.val);
+emulate_fpu_insn_memdst("fstl", dst.val);
 break;
 case 3: /* fstp m64fp */
 ea.bytes = 8;



x86emul: correct direction of FPU insn emulations

There are two cases where this was wrong, albeit in a benign way (the
compiler - according to my checking - didn't leverage the wrongness
for any optimizations affecting overall outcome).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3683,7 +3683,7 @@ x86_emulate(
 if ( (rc = ops->read(src.mem.seg, src.mem.off,
  , src.bytes, ctxt)) != 0 )
 goto done;
-emulate_fpu_insn_memdst("fldt", src.val);
+emulate_fpu_insn_memsrc("fldt", src.val);
 break;
 case 7: /* fstp m80fp */
 ea.bytes = 10;
@@ -3780,7 +3780,7 @@ x86_emulate(
 ea.bytes = 8;
 dst = ea;
 dst.type = OP_MEM;
-emulate_fpu_insn_memsrc("fstl", dst.val);
+emulate_fpu_insn_memdst("fstl", dst.val);
 break;
 case 3: /* fstp m64fp */
 ea.bytes = 8;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel