Re: [Xen-devel] xenstored crashes with SIGSEGV

[Philipp Hahn]

Hello,

happy new year to everyone.

On 19.12.2014 13:36, Philipp Hahn wrote:
> On 18.12.2014 11:17, Ian Campbell wrote:
>> On Tue, 2014-12-16 at 16:13 +, Frediano Ziglio wrote:
>>> Do we have a bug in Xen that affect SSE instructions (possibly already
>>> fixed after Philipp version) ?
>>
>> I've had a niggling feeling of Deja Vu over this which I'd been putting
>> down to an old Xen on ARM bug in the area of FPU register switching.
>>
>> But it seems at some point (possibly even still) there was a similar
>> issue with pvops kernels on x86, see:
>> http://bugs.xenproject.org/xen/bug/40
> 
> That definitely looks interesting.
> 
>> Philipp, what kernel are you guys using?
> 
> The crash "2014-12-06 01:26:21 xenstored[4337]" happened on linux-3.10.46.

I looked through the changes of v3.10.46..v3.10.63 and found the
following patches:
| fb5b6e7 x86, fpu: shift drop_init_fpu() from save_xstate_sig() to
handle_signal()
| b888e3d x86, fpu: __restore_xstate_sig()->math_state_restore() needs
preempt_disable()

They look interesting enough to may have fixed the bug, which could
explain the strange bit pattern caused by not restoring the FPU state
correctly. Because of that and because of the missing

>> commit d1cc001905146d58c17ac8452eb96f226767819d
>> Author: Silesh C V 
>> Date:   Wed Jul 23 13:59:59 2014 -0700
>>
>> coredump: fix the setting of PF_DUMPCORE
>> commit aed8adb7688d5744cb484226820163af31d2499a upstream.

we're now working on upgrading the dom0 kernel which should give use
usable core dumps again and may also fix the underlying problem. It that
bug ever happens again I'll keep you informed.

Thanks so far to everybody for the excellent support.

Sincerely
Philipp Hahn

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

[Xen-devel] [linux-next test] 33122: regressions - FAIL

[xen . org]

flight 33122 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33122/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install fail REGR. vs. 33087

Regressions which are regarded as allowable (not blocking):
 build-armhf-libvirt   5 libvirt-buildfail   like 33087
 build-i386-libvirt5 libvirt-buildfail   like 33087
 build-amd64-libvirt   5 libvirt-buildfail   like 33087
 test-amd64-i386-freebsd10-amd64  7 freebsd-install fail like 33087
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail like 33087
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33087
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail like 33087

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass

version targeted for testing:
 linux35393dcb2ed331e8698a548fbba8042457f5fd32
baseline version:
 linuxd753856c9f9ae33a980192aa7b81d8b97d79dec2

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

[Xen-devel] Fw: Dataset for pre-copy while migrating VM???

[Minalkumar Patel]

i want to extract dirty page bitmap so it can able to make  possible statistics 
of those pages - historical analysis


i am forwarding previous email with this
I request to give me little idea. How people use Xen hypervisor for this task 
on MATLAB/R language/Other tool


On Friday, 2 January 2015 1:15 PM, Minalkumar Patel  
wrote:
 


My idea is to get dataset of pre-copy at the time of live migration. basically 
i am planning to write few code into opnesource so i need dataset. actually, 
from which file/log file i can able to get page modificaiton information. let 
take scenario,

if VM is migrating, then it will check dirty page in each iteration. if found 
dirty pages, then it would skip those pages and may send them in next round 
(not current round) once they are non-dirty. so from which file, these 
information can be possible to collect/gather or where i can modify code to 
print such output in xc_domain_save. Verbose -vvv utility can't give detail 
statastic but it gives number of pages dirty/iteration number etc but non the 
informaiotn page-vise.

I get daily message from xen-devel so how to avoid daily messages?

Regards,



 

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

[Xen-devel] [qemu-mainline bisection] complete test-amd64-i386-xl-qemuu-ovmf-amd64

[xen . org]

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
test debian-hvm-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum 
  Date:   Tue Dec 16 16:58:05 2014 +
  
  machine: remove qemu_machine_opts global list
  
  QEMU has support for options per machine, keeping
  a global list of options is no longer necessary.
  
  Signed-off-by: Marcel Apfelbaum 
  Reviewed-by: Alexander Graf 
  Reviewed-by: Greg Bellows 
  Message-id: 1418217570-15517-2-git-send-email-marce...@redhat.com
  Signed-off-by: Peter Maydell 


For bisection revision-tuple graph see:
   
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-xl-qemuu-ovmf-amd64.debian-hvm-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Searching for failure / basis pass:
 33111 fail [host=grain-weevil] / 32598 [host=potato-beetle] 32585 
[host=scape-moth] 32571 [host=leaf-beetle] 32561 [host=leaf-beetle] 32542 
[host=rice-weevil] 32517 [host=bush-cricket] 32459 [host=moss-bug] 32429 
[host=lace-bug] 32418 [host=itch-mite] 32294 ok.
Failure / basis pass flights: 33111 / 32294
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
ab0302ee764fd702465aef6d88612cdff4302809 
36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 356a3e1fde11190febb8ace3cdab8694848ed220 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
b141290478f847ecaa25561f3b31fbf1ddde95e6 
2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#356a3e1fde11190febb8ace3cdab8694848ed220-83a926f7a4e39fb6be0576024e67fe161593defa
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22
 
git://git.qemu.org/qemu.git#b141290478f847ecaa25561f3b31fbf1ddde95e6-ab0302ee764fd702465aef6d88612cdff4302809
 
git://xenbits.xen.org/xen.git#2a549b9c8aa48dc39d7c97e5a93978b781b3a1db-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-pvops
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-pvops
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 11036 nodes in revision graph
Searching for test results:
 32294 pass 356a3e1fde11190febb8ace3cdab8694848ed220 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
b141290478f847ecaa25561f3b31fbf1ddde95e6 
2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
 32377 []
 32418 [host=itch-mite]
 32429 [host=lace-bug]
 32517 [host=bush-cricket]
 32459 [host=moss-bug]
 32542 [host=rice-weevil]
 32572 [host=leaf-beetle]
 32583 [host=leaf-beetle]
 32571 [host=leaf-beetle]
 32561 [host=leaf-beetle]
 32585 [host=scape-moth]
 32598 [host=potato-beetle]
 32611 fail 83a926f7a4e39fb6be

Re: [Xen-devel] [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM

[Pang, LongtaoX]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, December 11, 2014 7:44 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
> ian.campb...@citrix.com; wei.l...@citrix.com; Hu, Robert; Zheng, Di
> Subject: Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
> 
> On Wed, Dec 10, 2014 at 04:07:39PM +0800, longtao.pang wrote:
> > From: "longtao.pang" 
> >
> > This patch is used for installing L2 guest VM inside L1 guest VM.
> >
> > ---
> >  sg-run-job|2 +
> >  ts-debian-install |  166
> > +
> >  2 files changed, 132 insertions(+), 36 deletions(-)
> >
> > diff --git a/sg-run-job b/sg-run-job
> > index e513bd1..85f7b22 100755
> > --- a/sg-run-job
> > +++ b/sg-run-job
> > @@ -292,6 +292,8 @@ proc need-hosts/test-nested {} {return host}  proc
> > run-job/test-nested {} {
> >  run-ts . = ts-debian-hvm-install + host + nested + nested_L1
> >  run-ts . = ts-xen-install + host + nested + nested_build
> > +run-ts . = ts-debian-install + host + nested + amd64 + nested_L2
> > +run-ts . = ts-guest-destroy + host nested
> 
> It would also be possible to run ts-debian-hvm-install as L2. That would suite
> this test case better -- it's testing nested HVM.
> 
> There's no need to remove the PV test case though.

[Pang, LongtaoX] 
[Pang, LongtaoX] Thanks for checking. We used ts-debian-hvm-install for 
installing L1 HVM guest via ISO Image, 
because we will build XEN, XEN-Tools and dom0 kernel inside it, and then we 
will install L2 guest inside L1. 
But, L2 guest is just a native OS, so we think use ts-debian-install is enough 
for installing L2 and will make it easy to control.

> 
> >  }
> >
> >  proc test-guest-migr {g} {
> > diff --git a/ts-debian-install b/ts-debian-install index
> > 58ea743..2ca54e8 100755
> > --- a/ts-debian-install
> > +++ b/ts-debian-install
> > @@ -22,41 +22,61 @@ use Osstest::TestSupport;
> >
> >  tsreadconfig();
> >
> > -our ($whhost,$gn) = @ARGV;
> > -$whhost ||= 'host';
> > -$gn ||= 'debian';
> > +our ($whhost,$gn,$arch,$nested_L2) = @ARGV;
> > +$nested_L2 ||= '';
> >
> > -our $ho= selecthost($whhost);
> > +if($nested_L2 eq 'nested_L2') {
> > +my $L1_IP = &get_VM_IP($r{'nested_ether'});
> > +$whhost = "host=$L1_IP";
> > +$gn ||= 'nested';
> > +$arch ||= 'amd64';
> > +} else {
> > +$whhost ||= 'host';
> > +$gn ||= 'debian';
> > +}
> >
> > +our $ho= selecthost($whhost);
> >  our $ram_mb=512;
> >  our $swap_mb=  1000;
> >  our $disk_mb= 1;
> > -
> 
> Stray blank line.
> 
> >  our $guesthost= "$gn.guest.osstest";
> >  our $gho;
> > +our $L2_MAC = select_ether($ho,"L2_ether");
> >
> >  sub prep () {
> >  target_install_packages_norec($ho, qw(lvm2 xen-tools));
> > -
> > -$gho= prepareguest($ho, $gn, $guesthost, 22,
> > -   $swap_mb + $disk_mb + 2,
> > -   40);
> > -target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
> > +unless($nested_L2 eq 'nested_L2') {
> > +   $gho= prepareguest($ho, $gn, $guesthost, 22,
> > +  $swap_mb + $disk_mb + 2,
> > +  40);
> > +   target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
> > +}
> >  }
> >
> >  sub ginstall () {
> > -my $arch= $r{"$gho->{Guest}_arch"};
> > +my $gsuite;
> > +my $kernpath;
> > +my $initrd;
> > +my $kernver;
> > +if($nested_L2 eq 'nested_L2'){
> > +my $suite= "$c{DebianSuite}";
> > +$gsuite= defined($suite) ? "--dist=$suite" : '';
> > +$kernver ||= target_cmd_output_root($ho, 'uname -r');
> > +$kernpath = "/boot/vmlinuz-$kernver";
> > +$initrd ||= "/boot/initrd.img-$kernver";
> > +} else {
> > +my $arch= $r{"$gho->{Guest}_arch"};
> > +$gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
> > +$kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
> > +$initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
> > +if (!$kernpath) {
> > +   $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
> > +$kernver ||= target_cmd_output($ho, 'uname -r');
> > +   $kernpath = "/boot/vmlinuz-$kernver";
> > +   $initrd ||= "/boot/initrd.img-$kernver";
> > +}
> > +}
> 
> To be honest, this looks convoluted. Special casing needs better explanation.

[Pang, LongtaoX] Thanks for checking, I will try to adjust it.

> 
> >  my $archarg= defined($arch) ? "--arch $arch" : '';
> > -my $gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
> > -
> > -my $kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
> > -my $initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
> > -if (!$kernpath) {
> > -   my $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
> > -   $kernver ||= target_cmd_output($ho, 'uname -r');
> > -   $kernpath = "/boot/vmlinuz-$kernver";
> > -   $initrd ||= "/boo

Re: [Xen-devel] [OSSTEST PATCH 4/4] Insert nested test job name and runvars into

[Pang, LongtaoX]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, December 11, 2014 7:46 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
> ian.campb...@citrix.com; wei.l...@citrix.com; Hu, Robert; Zheng, Di
> Subject: Re: [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
> 
> On Wed, Dec 10, 2014 at 04:07:40PM +0800, longtao.pang wrote:
> > From: "longtao.pang" 
> >
> > This patch is used for inserting nested test job name and runvars into
> > standalone.db database after execute command './standalone-reset'.
> >
> > ---
> >  make-flight |   19 +++
> >  mfi-common  |8 
> >  2 files changed, 27 insertions(+)
> >
> > diff --git a/make-flight b/make-flight index 9963a46..fe64237 100755
> > --- a/make-flight
> > +++ b/make-flight
> > @@ -197,6 +197,24 @@ do_hvm_win7_x64_tests () {
> >  all_hostflags=$most_hostflags,hvm  }
> >
> > +do_hvm_debian_nested_tests () {
> > +  if [ $xenarch != amd64 ]; then
> > +return
> > +  fi
> > +  if [ $dom0arch != amd64 ]; then
> > +return
> > +  fi
> > +
> > +  job_create_test test-$xenarch$kern-$dom0arch-nested test-nested xl \
> > +   $xenarch $dom0arch \
> > +nested_image=debian-7.6.0-amd64-DVD-1.iso \
> > +   bios=seabios \
> > +   kernbuildjob=build-amd64-hvm \
> > +   kernkind=hvm \
> > +   device_model_version=qemu-xen \
> > +all_hostflags=$most_hostflags,hvm }
> > +
> >  do_hvm_debian_test_one () {
> >testname=$1
> >bios=$2
> > @@ -364,6 +382,7 @@ test_matrix_do_one () {
> >
> >fi
> >
> > +  do_hvm_debian_nested_tests
> >do_passthrough_tests
> >  }
> >
> > diff --git a/mfi-common b/mfi-common
> > index 5c4f5d5..b65f0b5 100644
> > --- a/mfi-common
> > +++ b/mfi-common
> > @@ -166,6 +166,14 @@ create_build_jobs () {
> >  revision_qemu=$REVISION_QEMU
> \
> >  revision_qemuu=$REVISION_QEMU_UPSTREAM
> >  fi
> > +./cs-job-create $flight build-$arch-hvm build-kern
> \
> > +arch=$arch kconfighow=xen-enable-xen-config
> \
> > +$RUNVARS $BUILD_RUNVARS $BUILD_LINUX_RUNVARS
> $arch_runvars   \
> > +$suite_runvars
> \
> > +host_hostflags=$build_hostflags
> \
> > +revision_linux=v3.16
> \
> > +
> tree_linux=git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> \
> 
> Please don't hard code tree and revision.
> 
> You can specify tree and revision in you test configuration.
> 
> Wei.

[Pang, LongtaoX] Thanks for checking, I will try to modify it.

> 
> > +${TREEVCS_LINUX:+treevcs_linux=}${TREEVCS_LINUX}
> >
> >  ./cs-job-create $flight build-$arch-pvops build-kern
> \
> >  arch=$arch kconfighow=xen-enable-xen-config
> \
> > --
> > 1.7.10.4

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

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

[xen . org]

flight 33120 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33120/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 26303
 build-i386-libvirt5 libvirt-build fail REGR. vs. 26303
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 26303
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install  fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-armhf-armhf-xl   5 xen-boot fail   never pass
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass

version targeted for testing:
 linuxa472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linuxbe67db109090b17b56eb8eb2190cd70700f107aa


816 people touched revisions under test,
not listing them all


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

Re: [Xen-devel] [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual machine

[Xu, Quan]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, January 05, 2015 9:21 PM
> To: Xu, Quan
> Cc: xen-devel@lists.xen.org; dgde...@tycho.nsa.gov;
> samuel.thiba...@ens-lyon.org; ian.jack...@eu.citrix.com;
> stefano.stabell...@eu.citrix.com; wei.l...@citrix.com
> Subject: Re: [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual
> machine
> 
> On Tue, 2014-12-30 at 23:44 -0500, Quan Xu wrote:
> 
> Please can you arrange for you patch submissions to be correctly threaded i.e.
> with all the mails containing a reference header either to the previous patch
> or to the 0/N introductory patch.
> 
> Take a look at the --chainreplyto and --thread options to git send-email. If 
> you
> use --dry-run then you should see each mail has a suitable References:
> header if you have got it right.
> 
> Without this I end up with N+1 unrelated email in my INBOX which are very
> hard to keep straight as a series once people start commenting on a subset.
> 
> Thanks,
> Ian.
> 


Thanks. I tried for a lot of times, I will ask some opensource veteran to help 
me.
I really didn't understand it before you tell me.

Thanks 
Quan Xu

> > This patch series are only the Xen part to enable stubdom vTPM for HVM
> virtual machine.
> > it will work w/ Qemu patch series and seaBios patch series. Change
> > QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the
> Qemu/SeaBios patch series are merged.
> >
> > 
> > *INTRODUCTION*
> > 
> > The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM
> > functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows
> > .etc). This allows programs to interact with a TPM in a virtual
> > machine the same way they interact with a TPM on the physical system.
> > Each virtual machine gets its own unique, emulated, software TPM. Each
> major component of vTPM is implemented as a stubdom, providing secure
> separation guaranteed by the hypervisor.
> >
> > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the
> > virtual machine to use. It is a small wrapper around the Berlios TPM
> > emulator. TPM commands are passed from mini-os TPM backend driver.
> >
> > 
> >  *ARCHITECTURE*
> > 
> > The architecture of stubdom vTPM for HVM virtual machine:
> >
> > ++
> > | Windows/Linux DomU | ...
> > ||  ^|
> > |v  ||
> > |  Qemu tpm1.2 Tis   |
> > ||  ^|
> > |v  ||
> > | XenStubdoms backend|
> > ++
> >  |  ^
> >  v  |
> > ++
> > |  XenDevOps |
> > ++
> >  |  ^
> >  v  |
> > ++
> > |  mini-os/tpmback   |
> > ||  ^|
> > |v  ||
> > |   vtpm-stubdom | ...
> > ||  ^|
> > |v  ||
> > |  mini-os/tpmfront  |
> > ++
> >  |  ^
> >  v  |
> > ++
> > |  mini-os/tpmback   |
> > ||  ^|
> > |v  ||
> > |  vtpmmgr-stubdom   |
> > ||  ^|
> > |v  ||
> > |  mini-os/tpm_tis   |
> > ++
> >  |  ^
> >  v  |
> > ++
> > |Hardware TPM|
> > ++
> >
> >
> >
> >  * Windows/Linux DomU:
> > The HVM based guest that wants to use a vTPM. There may be
> > more than one of these.
> >
> >  * Qemu tpm1.2 Tis:
> > Implementation of the tpm1.2 Tis interface for HVM virtual
> > machines. It is Qemu emulation device.
> >
> >  * vTPM xenstubdoms driver:
> > Qemu vTPM driver. This driver provides vtpm initialization
> > and sending data and commends to a para-virtualized vtpm
> > stubdom.
> >
> >  * XenDevOps:
> > Register Xen stubdom vTPM frontend driver, and transfer any
> > request/repond between TPM xenstubdoms driver and Xen vTPM
> > stubdom. Facilitate communications between Xen vTPM stubdom
> > and vTPM xenstubdoms driver.
> >
> >  * mini-os/tpmback:
> > Mini-os TPM backend driver. The Linux frontend driver connects
> > to this backend driver to facilitate communications between the
> > Linux DomU and its vTPM. This driver is also used by vtpmmgr
> > stubdom to communicate with vtpm-stubdom.
> >
> >  * vtpm-stubdom:
> > A mini-os stub domain that implemen

Re: [Xen-devel] [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual machine

[Xu, Quan]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Monday, January 05, 2015 9:19 PM
> To: Xu, Quan
> Cc: xen-devel@lists.xen.org; dgde...@tycho.nsa.gov;
> samuel.thiba...@ens-lyon.org; ian.jack...@eu.citrix.com;
> stefano.stabell...@eu.citrix.com; ian.campb...@citrix.com;
> wei.l...@citrix.com
> Subject: Re: [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual
> machine
> 
> FWIW in the future please configure git to chain all your patches to one
> thread. :-)
> 
> What I usually do is to
> 
> git format-patch HEAD~NNN --cover --subject-prefix='PATCH vXX'
> ... edit -cover-letter.patch ...
> git send-email --to xen-devel@ --cc XXX
> 
> All patches will be chained to 00/00 cover letter.
> 

Thanks. I tried for a lot of times, I will ask some opensource veteran to help 
me. I hope I can do right in next v3.

Quan
Thanks



> Wei.

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

Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported

[Mukesh Rathor]

On Mon, 5 Jan 2015 15:35:27 +
Andrew Cooper  wrote:

> On 05/01/15 15:16, Ian Campbell wrote:
> > On Fri, 2015-01-02 at 19:12 +, Andrew Cooper wrote:
> >> supervisor_mode_kernel was an x86_32-only feature which permitted
> >> a PV dom0 to run in ring 0, but at the expense of not being able
> >> to start any domUs.
> >>
> >> As the x86_32 Xen build has been removed from tree, removing the
> >> remaining supervisor_mode_kernel code.
> >>
> >> Signed-off-by: Andrew Cooper 
> >> CC: Keir Fraser 
> >> CC: Jan Beulich 
> >> CC: Ian Campbell 
> >> CC: Stefano Stabellini 
> >> CC: Tim Deegan 
> >>
> >> ---
> >>
> >> One complication is that PVH has reused
> >> XENFEAT_supervisor_mode_kernel with a modified meaning, and the
> >> Linux PVH code actively uses the flag as to indicate running as a
> >> PVH guest.
> > What is the modification? Doesn't a PVH kernel just use it to
> > indicate that it should (or wants) run in ring0 instead of
> > ring1/ring3? That was the original intention IIRC.

That flag has confused me too, and it was added later to pvh. 
Since, PVH guest is able to run in ring 0 ir-respective of the flag,
imho, XENFEAT_supervisor_mode_kernel can be just removed. The important
ones are really:

XENFEAT_auto_translated_physmap
XENFEAT_hvm_callback_vector

thanks
Mukesh


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

Re: [Xen-devel] [PATCH v2 2/5] vTPM: limit libxl__add_vtpms() function to para virtual machine

[Xu, Quan]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Monday, January 05, 2015 8:53 PM
> To: Xu, Quan
> Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
> stefano.stabell...@eu.citrix.com; ian.campb...@citrix.com;
> wei.l...@citrix.com
> Subject: Re: [PATCH v2 2/5] vTPM: limit libxl__add_vtpms() function to para
> virtual machine
> 
> On Tue, Dec 30, 2014 at 11:45:02PM -0500, Quan Xu wrote:
> > Signed-off-by: Quan Xu 
> > ---
> >  tools/libxl/libxl_create.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index b1ff5ae..0a09925 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -1358,8 +1358,9 @@ static void domcreate_attach_vtpms(libxl__egc
> *egc,
> > goto error_out;
> > }
> >
> > -/* Plug vtpm devices */
> > -   if (d_config->num_vtpms > 0) {
> > +   /* Plug vtpm devices for para virtual domain*/
> > +   if (d_config->num_vtpms > 0 &&
> > +   d_config->b_info.type == LIBXL_DOMAIN_TYPE_PV) {
> 
> It's unclear to me why you stub out HVM domain. You need to state your
> reasoning in comment and commit log. :-/

In brief, it is different to plug vtpm device for HVM/PV domain. I will try to 
describe more detailed in next v3. Thanks Wei.

Thanks 
Quan Xu
> 
> Wei.
> 
> > /* Attach vtpms */
> > libxl__multidev_begin(ao, &dcs->multidev);
> > dcs->multidev.callback = domcreate_attach_pci;
> > --
> > 1.8.3.2

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

Re: [Xen-devel] [Testday]Xen 4.5 RC4

[Robert Hu]

On Fri, 2015-01-02 at 16:47 +, Jan Beulich wrote:
> >>> Boris Ostrovsky  12/26/14 9:12 PM >>>
> >> On Thu, Dec 25, 2014 at 02:58:06AM +, Hu, Robert wrote:
> >> Issue 1 -- detach a vt-d assigned device from guest, then reattach it to 
> >> guest, will fail.
> >> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html
> >
> >This is regression introduced by abfb006f.
> 
> And the referenced mail even contains a proposed fix - Robert, did you give 
> this a try?
Yes, we have verified it. It did fixed the issue.
> 
> Jan
> 



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

[Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient

[Boris Ostrovsky]

Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a single structure and do a single copy for each
processor.

There is also no need to copy whole op to user at the end, max_cpu_index is
sufficient

Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the fact
that these are used for CPU topology. Subsequent patch will add support for
PCI topology sysctl.

Signed-off-by: Boris Ostrovsky 
---
 tools/libxc/include/xenctrl.h |4 +-
 tools/libxc/xc_misc.c |   10 +++---
 tools/libxl/libxl.c   |   52 ++-
 tools/misc/xenpm.c|   69 ++--
 tools/python/xen/lowlevel/xc/xc.c |   40 +++--
 xen/common/sysctl.c   |   47 +++--
 xen/include/public/sysctl.h   |   40 --
 7 files changed, 117 insertions(+), 145 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..0cb6743 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1226,7 +1226,7 @@ int xc_readconsolering(xc_interface *xch,
 int xc_send_debug_keys(xc_interface *xch, char *keys);
 
 typedef xen_sysctl_physinfo_t xc_physinfo_t;
-typedef xen_sysctl_topologyinfo_t xc_topologyinfo_t;
+typedef xen_sysctl_cputopoinfo_t xc_cputopoinfo_t;
 typedef xen_sysctl_numainfo_t xc_numainfo_t;
 
 typedef uint32_t xc_cpu_to_node_t;
@@ -1237,7 +1237,7 @@ typedef uint64_t xc_node_to_memfree_t;
 typedef uint32_t xc_node_to_node_dist_t;
 
 int xc_physinfo(xc_interface *xch, xc_physinfo_t *info);
-int xc_topologyinfo(xc_interface *xch, xc_topologyinfo_t *info);
+int xc_cputopoinfo(xc_interface *xch, xc_cputopoinfo_t *info);
 int xc_numainfo(xc_interface *xch, xc_numainfo_t *info);
 
 int xc_sched_id(xc_interface *xch,
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index e253a58..be68291 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -177,20 +177,20 @@ int xc_physinfo(xc_interface *xch,
 return 0;
 }
 
-int xc_topologyinfo(xc_interface *xch,
-xc_topologyinfo_t *put_info)
+int xc_cputopoinfo(xc_interface *xch,
+   xc_cputopoinfo_t *put_info)
 {
 int ret;
 DECLARE_SYSCTL;
 
-sysctl.cmd = XEN_SYSCTL_topologyinfo;
+sysctl.cmd = XEN_SYSCTL_cputopoinfo;
 
-memcpy(&sysctl.u.topologyinfo, put_info, sizeof(*put_info));
+memcpy(&sysctl.u.cputopoinfo, put_info, sizeof(*put_info));
 
 if ( (ret = do_sysctl(xch, &sysctl)) != 0 )
 return ret;
 
-memcpy(put_info, &sysctl.u.topologyinfo, sizeof(*put_info));
+memcpy(put_info, &sysctl.u.cputopoinfo, sizeof(*put_info));
 
 return 0;
 }
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 50a8928..cd87614 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5072,10 +5072,8 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo 
*physinfo)
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out)
 {
 GC_INIT(ctx);
-xc_topologyinfo_t tinfo;
-DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
-DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
-DECLARE_HYPERCALL_BUFFER(xc_cpu_to_node_t, nodemap);
+xc_cputopoinfo_t tinfo;
+DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
 libxl_cputopology *ret = NULL;
 int i;
 int max_cpus;
@@ -5088,48 +5086,36 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx 
*ctx, int *nb_cpu_out)
 goto out;
 }
 
-coremap = xc_hypercall_buffer_alloc
-(ctx->xch, coremap, sizeof(*coremap) * max_cpus);
-socketmap = xc_hypercall_buffer_alloc
-(ctx->xch, socketmap, sizeof(*socketmap) * max_cpus);
-nodemap = xc_hypercall_buffer_alloc
-(ctx->xch, nodemap, sizeof(*nodemap) * max_cpus);
-if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL)) {
+cputopo = xc_hypercall_buffer_alloc(ctx->xch, cputopo,
+sizeof(*cputopo) * max_cpus);
+if (cputopo == NULL) {
 LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
 "Unable to allocate hypercall arguments");
 goto fail;
 }
-
-set_xen_guest_handle(tinfo.cpu_to_core, coremap);
-set_xen_guest_handle(tinfo.cpu_to_socket, socketmap);
-set_xen_guest_handle(tinfo.cpu_to_node, nodemap);
+set_xen_guest_handle(tinfo.cputopo, cputopo);
 tinfo.max_cpu_index = max_cpus - 1;
-if (xc_topologyinfo(ctx->xch, &tinfo) != 0) {
-LIBXL__LOG_ERRNO(ctx, XTL_ERROR, "Topology info hypercall failed");
+
+if (xc_cputopoinfo(ctx->xch, &tinfo) != 0) {
+LIBXL__LOG_ERRNO(ctx, XTL_ERROR, "CPU topology info hypercall failed");
 goto fail;
 }
 
-if (tinfo.max_cpu_index < max_cpus - 1)
-max_cpus = tinfo.max_cpu_index + 1;
+*nb_cpu_out = tinfo.max_cpu_index + 1;
+ret = libxl__zalloc(NOGC, sizeof(libx

[Xen-devel] [PATCH v2 4/4] libxl: Add interface for querying hypervisor about PCI topology

[Boris Ostrovsky]

.. and use this new interface to display it along with CPU topology
and NUMA information when 'xl info -n' command is issued

Signed-off-by: Boris Ostrovsky 
---
 tools/libxc/include/xenctrl.h |2 +
 tools/libxc/xc_misc.c |   18 ++
 tools/libxl/libxl.c   |   58 +
 tools/libxl/libxl.h   |4 ++
 tools/libxl/libxl_freebsd.c   |   12 +++
 tools/libxl/libxl_internal.h  |5 +++
 tools/libxl/libxl_linux.c |   71 +
 tools/libxl/libxl_netbsd.c|   12 +++
 tools/libxl/libxl_types.idl   |7 
 tools/libxl/libxl_utils.c |8 +
 tools/libxl/xl_cmdimpl.c  |   39 ++
 11 files changed, 229 insertions(+), 7 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0cb6743..3c5824a 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1227,6 +1227,7 @@ int xc_send_debug_keys(xc_interface *xch, char *keys);
 
 typedef xen_sysctl_physinfo_t xc_physinfo_t;
 typedef xen_sysctl_cputopoinfo_t xc_cputopoinfo_t;
+typedef xen_sysctl_pcitopoinfo_t xc_pcitopoinfo_t;
 typedef xen_sysctl_numainfo_t xc_numainfo_t;
 
 typedef uint32_t xc_cpu_to_node_t;
@@ -1238,6 +1239,7 @@ typedef uint32_t xc_node_to_node_dist_t;
 
 int xc_physinfo(xc_interface *xch, xc_physinfo_t *info);
 int xc_cputopoinfo(xc_interface *xch, xc_cputopoinfo_t *info);
+int xc_pcitopoinfo(xc_interface *xch, xc_pcitopoinfo_t *info);
 int xc_numainfo(xc_interface *xch, xc_numainfo_t *info);
 
 int xc_sched_id(xc_interface *xch,
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index be68291..e33a312 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -195,6 +195,24 @@ int xc_cputopoinfo(xc_interface *xch,
 return 0;
 }
 
+int xc_pcitopoinfo(xc_interface *xch,
+   xc_pcitopoinfo_t *put_info)
+{
+int ret;
+DECLARE_SYSCTL;
+
+sysctl.cmd = XEN_SYSCTL_pcitopoinfo;
+
+memcpy(&sysctl.u.pcitopoinfo, put_info, sizeof(*put_info));
+
+if ( (ret = do_sysctl(xch, &sysctl)) != 0 )
+return ret;
+
+memcpy(put_info, &sysctl.u.pcitopoinfo, sizeof(*put_info));
+
+return 0;
+}
+
 int xc_numainfo(xc_interface *xch,
 xc_numainfo_t *put_info)
 {
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index cd87614..888f068 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5121,6 +5121,64 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx 
*ctx, int *nb_cpu_out)
 return ret;
 }
 
+libxl_pcitopology *libxl_get_pci_topology(libxl_ctx *ctx, int *num_devs)
+{
+GC_INIT(ctx);
+xc_pcitopoinfo_t tinfo;
+DECLARE_HYPERCALL_BUFFER(xen_sysctl_pcitopo_t, pcitopo);
+libxl_pcitopology *ret = NULL;
+int i, rc;
+
+tinfo.num_devs = libxl__pci_numdevs(gc);
+if (tinfo.num_devs <= 0) {
+LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of PCI 
devices");
+goto out;
+}
+
+pcitopo = xc_hypercall_buffer_alloc(ctx->xch, pcitopo,
+sizeof(*pcitopo) * tinfo.num_devs);
+if (pcitopo == NULL) {
+LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+"Unable to allocate hypercall arguments");
+goto out;
+}
+
+rc = libxl__pci_topology_init(gc, pcitopo, tinfo.num_devs);
+if (rc) {
+LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "Cannot initialize PCI"
+" hypercall structure");
+goto fail;
+}
+
+tinfo.first_dev = 0;
+
+set_xen_guest_handle(tinfo.pcitopo, pcitopo);
+
+if (xc_pcitopoinfo(ctx->xch, &tinfo) != 0) {
+LIBXL__LOG_ERRNO(ctx, XTL_ERROR, "PCI topology info hypercall failed");
+goto fail;
+}
+
+ret = libxl__zalloc(NOGC, sizeof(libxl_pcitopology) * tinfo.num_devs);
+
+for (i = 0; i < tinfo.num_devs; i++) {
+ret[i].seg = pcitopo[i].pcidev.seg;
+ret[i].bus = pcitopo[i].pcidev.bus;
+ret[i].devfn = pcitopo[i].pcidev.devfn;
+ret[i].node = (pcitopo[i].node ==  INVALID_TOPOLOGY_ID) ?
+LIBXL_PCITOPOLOGY_INVALID_ENTRY :  pcitopo[i].node;
+}
+
+*num_devs = tinfo.num_devs;
+
+ fail:
+xc_hypercall_buffer_free(ctx->xch, pcitopo);
+
+ out:
+GC_FREE;
+return ret;
+}
+
 libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
 {
 GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0a123f1..eb83f0a 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1070,6 +1070,10 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int 
nb_vm);
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out);
 void libxl_cputopology_list_free(libxl_cputopology *, int nb_cpu);
 
+#define LIBXL_PCITOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
+libxl_pcitopology *libxl_get_pci_topology(libxl_ctx *ctx, int *num_dev);
+void libxl_pcitopology_list_free(libxl_pcitopology *, int num_dev);

[Xen-devel] [PATCH v2 3/4] sysctl: Add sysctl interface for querying PCI topology

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
 xen/common/sysctl.c |   60 +++
 xen/include/public/sysctl.h |   35 -
 2 files changed, 94 insertions(+), 1 deletions(-)

diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 1254a24..f09d377 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -365,6 +365,66 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 }
 break;
 
+case XEN_SYSCTL_pcitopoinfo:
+{
+xen_sysctl_pcitopoinfo_t *ti = &op->u.pcitopoinfo;
+
+if ( guest_handle_is_null(ti->pcitopo) ||
+ (ti->first_dev >= ti->num_devs) )
+{
+ret = -EINVAL;
+break;
+}
+
+for ( ; ti->first_dev < ti->num_devs; ti->first_dev++ )
+{
+xen_sysctl_pcitopo_t pcitopo;
+struct pci_dev *pdev;
+
+if ( copy_from_guest_offset(&pcitopo, ti->pcitopo,
+ti->first_dev, 1) )
+{
+ret = -EFAULT;
+break;
+}
+
+spin_lock(&pcidevs_lock);
+pdev = pci_get_pdev(pcitopo.pcidev.seg, pcitopo.pcidev.bus,
+pcitopo.pcidev.devfn);
+if ( !pdev || (pdev->node == NUMA_NO_NODE) )
+pcitopo.node = INVALID_TOPOLOGY_ID;
+else
+pcitopo.node = pdev->node;
+spin_unlock(&pcidevs_lock);
+
+if ( copy_to_guest_offset(ti->pcitopo, ti->first_dev,
+  &pcitopo, 1) )
+{
+ret = -EFAULT;
+break;
+}
+
+if ( hypercall_preempt_check() )
+break;
+}
+
+if ( !ret )
+{
+if ( __copy_field_to_guest(u_sysctl, op,
+   u.pcitopoinfo.first_dev) )
+{
+ret = -EFAULT;
+break;
+}
+
+if ( ti->first_dev < ti->num_devs )
+ret = hypercall_create_continuation(__HYPERVISOR_sysctl,
+   "h", u_sysctl);
+
+}
+}
+break;
+
 #ifdef TEST_COVERAGE
 case XEN_SYSCTL_coverage_op:
 ret = sysctl_coverage_op(&op->u.coverage_op);
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 512ad74..628ed6a 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -33,6 +33,7 @@
 
 #include "xen.h"
 #include "domctl.h"
+#include "physdev.h"
 
 #define XEN_SYSCTL_INTERFACE_VERSION 0x000C
 
@@ -463,7 +464,7 @@ typedef struct xen_sysctl_lockprof_op 
xen_sysctl_lockprof_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_lockprof_op_t);
 
 /* XEN_SYSCTL_cputopoinfo */
-#define INVALID_TOPOLOGY_ID  (~0U)
+#define INVALID_TOPOLOGY_ID  (~0U) /* Also used by pcitopo */
 
 struct xen_sysctl_cputopo {
 uint32_t core;
@@ -492,6 +493,36 @@ struct xen_sysctl_cputopoinfo {
 typedef struct xen_sysctl_cputopoinfo xen_sysctl_cputopoinfo_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cputopoinfo_t);
 
+/* XEN_SYSCTL_pcitopoinfo */
+struct xen_sysctl_pcitopo {
+struct physdev_pci_device pcidev;
+uint32_t node;
+};
+typedef struct xen_sysctl_pcitopo xen_sysctl_pcitopo_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_pcitopo_t);
+
+struct xen_sysctl_pcitopoinfo {
+/* IN: Size of pcitopo array */
+uint32_t num_devs;
+
+/*
+ * IN/OUT: First element of pcitopo array that needs to be processed by
+ * hypervisor.
+ * This is used primarily by hypercall continuations and callers will
+ * typically set it to zero
+ */
+uint32_t first_dev;
+
+/*
+ * If not NULL, filled with node identifier for each pcidev
+ * If information for a particular device is not avalable then node is set
+ * to INVALID_TOPOLOGY_ID.
+ */
+XEN_GUEST_HANDLE_64(xen_sysctl_pcitopo_t) pcitopo;
+};
+typedef struct xen_sysctl_pcitopoinfo xen_sysctl_pcitopoinfo_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_pcitopoinfo_t);
+
 /* XEN_SYSCTL_numainfo */
 #define INVALID_NUMAINFO_ID (~0U)
 struct xen_sysctl_numainfo {
@@ -681,12 +712,14 @@ struct xen_sysctl {
 #define XEN_SYSCTL_scheduler_op  19
 #define XEN_SYSCTL_coverage_op   20
 #define XEN_SYSCTL_psr_cmt_op21
+#define XEN_SYSCTL_pcitopoinfo   22
 uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
 union {
 struct xen_sysctl_readconsole   readconsole;
 struct xen_sysctl_tbuf_op   tbuf_op;
 struct xen_sysctl_physinfo  physinfo;
 struct xen_sysctl_cputopoinfo   cputopoinfo;
+struct xen_sysctl_pcitopoinfo   pcitopoinfo;
 struct xen_sysctl_numainfo  numainfo;
 struct xen_sysctl_sched_id  sched_id;
 struct xen_sysctl_perfc_op  perfc_op;
-- 
1.7.1


___

[Xen-devel] [PATCH v2 1/4] pci: Do not ignore device's PXM information

[Boris Ostrovsky]

If ACPI provides PXM data for IO devices then dom0 will pass it to
hypervisor during PHYSDEVOP_pci_device_add call. This information,
however, is currently ignored.

We will store this information (in the form of nodeID) in pci_dev
structure so that we can provide it, for example, to the toolstack
when it adds support (in the following patches) for querying the
hypervisor about device topology

We will also print it when user requests device information dump.

Signed-off-by: Boris Ostrovsky 
---
 xen/arch/x86/physdev.c|   23 ---
 xen/drivers/passthrough/pci.c |   13 +
 xen/include/public/physdev.h  |6 ++
 xen/include/xen/pci.h |5 -
 4 files changed, 39 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 6b3201b..62e768e 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -565,7 +565,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
 break;
 
-ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn, NULL);
+ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn,
+ NULL, NUMA_NO_NODE);
 break;
 }
 
@@ -597,13 +598,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
 ret = pci_add_device(0, manage_pci_ext.bus,
  manage_pci_ext.devfn,
- &pdev_info);
+ &pdev_info, NUMA_NO_NODE);
 break;
 }
 
 case PHYSDEVOP_pci_device_add: {
 struct physdev_pci_device_add add;
 struct pci_dev_info pdev_info;
+int node;
 
 ret = -EFAULT;
 if ( copy_from_guest(&add, arg, 1) != 0 )
@@ -618,7 +620,22 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 }
 else
 pdev_info.is_virtfn = 0;
-ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);
+
+if ( add.flags & XEN_PCI_DEV_PXM )
+{
+uint32_t pxm;
+int optarr_off = offsetof(struct physdev_pci_device_add, optarr) /
+ sizeof(add.optarr[0]);
+
+if ( copy_from_guest_offset(&pxm, arg, optarr_off, 1) )
+break;
+
+node = pxm_to_node(pxm);
+}
+else
+node = NUMA_NO_NODE;
+
+ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info, node);
 break;
 }
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..3002129 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -568,7 +568,8 @@ static void pci_enable_acs(struct pci_dev *pdev)
 pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
 }
 
-int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
+int pci_add_device(u16 seg, u8 bus, u8 devfn,
+   const struct pci_dev_info *info, int node)
 {
 struct pci_seg *pseg;
 struct pci_dev *pdev;
@@ -586,7 +587,8 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct 
pci_dev_info *info)
 pdev = pci_get_pdev(seg, info->physfn.bus, info->physfn.devfn);
 spin_unlock(&pcidevs_lock);
 if ( !pdev )
-pci_add_device(seg, info->physfn.bus, info->physfn.devfn, NULL);
+pci_add_device(seg, info->physfn.bus, info->physfn.devfn,
+   NULL, node);
 pdev_type = "virtual function";
 }
 else
@@ -609,6 +611,8 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct 
pci_dev_info *info)
 if ( !pdev )
 goto out;
 
+pdev->node = node;
+
 if ( info )
 pdev->info = *info;
 else if ( !pdev->vf_rlen[0] )
@@ -1191,10 +1195,11 @@ static int _dump_pci_devices(struct pci_seg *pseg, void 
*arg)
 
 list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list )
 {
-printk("%04x:%02x:%02x.%u - dom %-3d - MSIs < ",
+printk("%04x:%02x:%02x.%u - dom %-3d - node %-3d - MSIs < ",
pseg->nr, pdev->bus,
PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn),
-   pdev->domain ? pdev->domain->domain_id : -1);
+   pdev->domain ? pdev->domain->domain_id : -1,
+   (pdev->node != NUMA_NO_NODE) ? pdev->node : -1);
 list_for_each_entry ( msi, &pdev->msi_list, list )
printk("%d ", msi->irq);
 printk(">\n");
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index d547928..309346b 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -293,6 +293,12 @@ struct physdev_pci_device_add {
 uint8_t bus;
 uint8_t devfn;
 } physfn;
+
+/*
+ * Optional parameters array.
+ * First element ([0]) is PXM domain associa

[Xen-devel] [PATCH v2 0/4] Display IO topology when PXM data is available

[Boris Ostrovsky]

Changes in v2:
* Split topology sysctls into two --- one for CPU topology and the other
  for devices
* Avoid long loops in the hypervisor by using continuations. (I am not
  particularly happy about using first_dev in the interface, suggestions
  for a better interface would be appreciated)
* Use proper libxl conventions for interfaces
* Avoid hypervisor stack corruption when copying PXM data from guest


4 patches that add interface for querying hypervisor about device
topology and allow 'xl info -n' display this information if PXM object
is provided by ACPI.

The patches are:

* Store PXM data (nodeID) in pci_dev during PHYSDEVOP_pci_device_add
  hypercall
* Modify XEN_SYSCTL_topologyinfo interface to make it a little more efficient.
  (This patch is not necessary for IO topology handling)
* Add XEN_SYSCTL_pcitopoinfo sysctl for querying hypervisor about
  device topology
* Make use of the above sysctl in libxl.


Boris Ostrovsky (4):
  pci: Do not ignore device's PXM information
  sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient
  sysctl: Add sysctl interface for querying PCI topology
  libxl: Add interface for querying hypervisor about PCI topology

 tools/libxc/include/xenctrl.h |6 +-
 tools/libxc/xc_misc.c |   28 --
 tools/libxl/libxl.c   |  110 ++---
 tools/libxl/libxl.h   |4 +
 tools/libxl/libxl_freebsd.c   |   12 
 tools/libxl/libxl_internal.h  |5 ++
 tools/libxl/libxl_linux.c |   71 
 tools/libxl/libxl_netbsd.c|   12 
 tools/libxl/libxl_types.idl   |7 ++
 tools/libxl/libxl_utils.c |8 +++
 tools/libxl/xl_cmdimpl.c  |   39 +++--
 tools/misc/xenpm.c|   69 +--
 tools/python/xen/lowlevel/xc/xc.c |   40 +-
 xen/arch/x86/physdev.c|   23 +++-
 xen/common/sysctl.c   |  103 +--
 xen/drivers/passthrough/pci.c |   13 +++-
 xen/include/public/physdev.h  |6 ++
 xen/include/public/sysctl.h   |   75 +++--
 xen/include/xen/pci.h |5 +-
 19 files changed, 477 insertions(+), 159 deletions(-)


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

[Xen-devel] [libvirt bisection] complete build-amd64-libvirt

[xen . org]

branch xen-unstable
xen branch xen-unstable
job build-amd64-libvirt
test libvirt-build

Tree: gnulib_libvirt 
git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
Tree: libvirt git://libvirt.org/libvirt.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  gnulib_libvirt 
git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
  Bug introduced:  b9bfe78424b871f5b92e5ee9e7d21ef951a6801d
  Bug not present: bd86632bd0a614a4195e38ae376893432fcaec3b


  commit b9bfe78424b871f5b92e5ee9e7d21ef951a6801d
  Author: Paul Eggert 
  Date:   Thu Jan 1 01:38:23 2015 +
  
  version-etc: new year
  
  * doc/gnulib.texi:
  * lib/version-etc.c (COPYRIGHT_YEAR): Update copyright date.
  * all files: Run 'make update-copyright'.


For bisection revision-tuple graph see:
   
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.libvirt.build-amd64-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Searching for failure / basis pass:
 33117 fail [host=rice-weevil] / 32648 [host=field-cricket] 32617 
[host=field-cricket] 32596 [host=scape-moth] 32576 [host=bush-cricket] 32555 
[host=field-cricket] 32534 [host=scape-moth] 32508 [host=scape-moth] 32471 
[host=scape-moth] 32433 [host=scape-moth] 32414 [host=bush-cricket] 32351 
[host=field-cricket] 32330 [host=field-cricket] 32308 [host=moss-bug] 32272 
[host=grain-weevil] 32217 [host=worm-moth] 32137 [host=field-cricket] 32005 
[host=bush-cricket] 31928 [host=bush-cricket] 31860 [host=scape-moth] 31852 
[host=field-cricket] 31839 ok.
Failure / basis pass flights: 33117 / 31839
(tree with no url: seabios)
Tree: gnulib_libvirt 
git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
Tree: libvirt git://libvirt.org/libvirt.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 498a1b6bc7d70f944ca0f939e1bc470889fdce76 
262d913ffc6a20ceafbf4ba2f174854a0a583805 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
1ebb75b1fee779621b63e84fefa7b07354c43a99 
36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 624ea2886cc570788cb01c4fd59315de301b0cd6 
1fd83607514eda8e7331cba39f83d51fb9e565c9 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Generating revisions with ./adhoc-revtuple-generator  
git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]#624ea2886cc570788cb01c4fd59315de301b0cd6-498a1b6bc7d70f944ca0f939e1bc470889fdce76
 
git://libvirt.org/libvirt.git#1fd83607514eda8e7331cba39f83d51fb9e565c9-262d913ffc6a20ceafbf4ba2f174854a0a583805
 
git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22
 
git://xenbits.xen.org/staging/qemu-upstream-unstable.git#0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51-1ebb75b1fee779621b63e84fefa7b07354c43a99
 
git://xenbits.xen.org/xen.git#6913fa31fa898f45ecc3b00e2397b8ebc75c8df4-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/gnulib
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/libvirt
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/gnulib
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/libvirt
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/

Re: [Xen-devel] RMRR Fix Design for Xen

[Chen, Tiejun]

On 2015/1/6 1:01, George Dunlap wrote:

On Fri, Dec 19, 2014 at 1:21 AM, Tiejun Chen  wrote:

 RMRR Fix Design for Xen

This design is a goal to fix RMRR for Xen. It includes four sectors as
follows:

 * Background
 * What is RMRR
 * Current RMRR Issues
 * Design Overview

We hope this can help us to understand current problem then figure out a
clean and better solution everyone can agree now to go forward.

Background
==

We first identified this RMRR defect when trying to pass-through IGD device,
which can be simply fixed by adding an identity mapping in case of shared
EPT table. However along with the community discussion, it boiled down to
a more general RMRR problem, i.e. the identity mapping is brute-added
in hypervisor, w/o considering whether conflicting with an existing guest
PFN ranges. As a general solution we need invent a new mechanism so
reserved ranges allocated by hypervisor can be exported to the user space
toolstack and hvmloader, so conflict can be detected when constructing
guest PFN layout, with best-effort avoidance policies to further help.

What is RMRR


RMRR is a acronym for Reserved Memory Region Reporting.

BIOS may report each such reserved memory region through the RMRR structures,
along with the devices that requires access to the specified reserved memory
region. Reserved memory ranges that are either not DMA targets, or memory
ranges that may be target of BIOS initiated DMA only during pre-boot phase
(such as from a boot disk drive) must not be included in the reserved memory
region reporting. The base address of each RMRR region must be 4KB aligned and
the size must be an integer multiple of 4KB. BIOS must report the RMRR reported
memory addresses as reserved in the system memory map returned through methods
suchas INT15, EFI GetMemoryMap etc. The reserved memory region reporting
structures are optional. If there are no RMRR structures, the system software
concludes that the platform does not have any reserved memory ranges that are
DMA targets.

The RMRR regions are expected to be used for legacy usages (such as USB, UMA
Graphics, etc.) requiring reserved memory. Platform designers shouldavoid or
limit use of reserved memory regions since these require system software to
create holes in the DMA virtual address range available to system software and
its drivers.

The following is grabbed from my BDW:

(XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ab80a000 end_address ab81dfff
(XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ad00 end_address af7f

Here USB occupies 0xab80a000:0xab81dfff, IGD owns 0xad00:0xaf7f.

Note there are zero or more Reserved Memory Region Reporting (RMRR) in one given
platform. And multiple devices may share one RMRR range. Additionally RMRR can
go anyplace.


Tiejun,

Thanks for this document -- such a document is really helpful in
figuring out the best way to architect the solution to a problem.

I hope you don't mind me asking a few additional questions here.


Everything is fine to me :)


You've said that:
* RMRR is a range used by devices (typically legacy devices such as
USB, but apparently also newer devices like IGD)
* RMRR ranges are reported by BIOSes
* RMRR ranges should be avoided by the guest.

I'm still missing a few things, however.

* In the case of passing through a virtual device, how does the
"range" apply wrt gpfn space and mfn space?  I assume in example
above, the range [ab80a000,ab81dfff] corresponds to an mfn range.
When passing through this device to the guest, do pfns
[ab80a000,ab81dfff] need to be mapped to the same mfn range (i.e., 1-1
mapping), or can they be mapped from somewhere else in pfn space?


Always 1:1 mapping here.



* You've described the range, but later on you talk about Xen
"creating" RMRR mappings.  What does this mean?  Are there registers
that need to be written?  Do the ept / IOMMU tables need some kind of
special flags?


We don't use or introduce any special flags.

As you know Xen supports two scenarios. In case of non-shared ept, we 
just create VT-D table to cover those 1:1 mappings but if case of shared 
ept we always create and share such 1:1 mappings.


BTW, this v1 document is not good as a design review so Kevin sent out 
v2, "(v2) Design proposal for RMRR fix", again. I hope that can provide 
more as you expect.


Thanks
Tiejun

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

Re: [Xen-devel] Parallel make supported?

[Peter Kay]

root[xen-4.5.0-rc4]# ls -l tools/xenstore/libxenstore*
-rw-r--r-- 1 root root 98580 Dec 19 22:02 tools/xenstore/libxenstore.a
-rwxr-xr-x 1 root root 82624 Dec 19 22:02
tools/xenstore/libxenstore.so.3.0.3

Please see output of make -d -C tools/xenstore init-xenstore-domain
attached - it's quite long uncompressed

PK

On 5 January 2015 at 16:01, Ian Campbell  wrote:

> On Mon, 2014-12-29 at 13:01 +, Wei Liu wrote:
> > Please don't top post.
> >
> > On Fri, Dec 19, 2014 at 10:09:31PM +, Peter Kay wrote:
> > > Thanks, see attached :
> > >
> > > This is on Salix 14.1 running the 3.17.4 kernel. That's not
> particularly
> > > relevant though, as I had exactly the same error on Debian using other
> > > kernel versions.
> > >
> >
> > Looking at your build log
> >
> > gcc -pthread -Wl,-soname -Wl,libxenstore.so.3.0 -shared -o
> libxenstore.so.3.0.3 xs.opic xs_lib.opic
> > ar rcs libxenstore.a xs.o xs_lib.o
> > gcc xs_tdb_dump.o utils.o tdb.o talloc.o -o xs_tdb_dump
> > gcc xenstored_core.o xenstored_watch.o xenstored_domain.o
> xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o
> xenstored_posix.o
>  
> /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenctrl.so
> -o xenstored
> > gcc init-xenstore-domain.o libxenstore.so
>  
> /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenctrl.so
> /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenguest.so
> /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/xenstore/libxenstore.so
> -o init-xenstore-domain
> > gcc: error: libxenstore.so: No such file or directory
> > gcc: error:
> /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/xenstore/libxenstore.so:
> No such file or directory
> > make[4]: *** [init-xenstore-domain] Error 1
> > make[4]: Leaving directory
> `/home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore'
> > make[3]: *** [subdir-install-xenstore] Error 2
> > make[3]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools'
> > make[2]: *** [subdirs-install] Error 2
> > make[2]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools'
> > make[1]: *** [install-tools] Error 2
> > make[1]: *** Waiting for unfinished jobs
> >
> > libxenstore.so is missing. However Makefile dependency ensures the
> > compilation of init-xenstore-domain does not proceed unless
> > libxenstore.so exists.
>
> Right. Specifically (quoting a select few lines from
> tools/xenstore/Makefile):
>
> LIBXENSTORE := libxenstore.so
> init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
> libxenstore.so: libxenstore.so.$(MAJOR)
> libxenstore.so.$(MAJOR): libxenstore.so.$(MAJOR).$(MINOR)
> libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic
>
> So it would be a make bug if init-xenstore-domain were linked without
> having created libxenstore.so first, but that (such an obvious bug in
> make) doesn't seem very likely.
>
> Peter, what does
> ls -l tools/xenstore/libxenstore*
> show?
>
> Also "make -d -C tools/xenstore init-xenstore-domain" might give a clue
> as to why make thinks it doesn't need to rebuild those objects.
>
> If $(LIBXENSTORE) were unset then that might explain things, but I can't
> see how that could happen, it must always be either libxenstore.so or
> libxenstore.a. Changing the init-xenstore-domain rule to:
> init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
> @echo init-xenstore-domain using $(LIBXENSTORE)
> $(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl)
> $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
> would confirm or deny that theory (nb before @echo needs to be a hard
> tab).
>
> Ian.
>
>


xsdm.gz
Description: GNU Zip compressed data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] bind interdomain ioctl error xen-kvm.c

[Don Slutz]

On 01/05/15 14:10, Rishi Ranjan wrote:
> Hi Stefano,
>  Please find my answers inline. 
> 
> However Anthony (CC'ed) should have some patches for it.
> Anthony, can you please share any patch that can help me with this?
> 
> 
> Can you post the full output of the logs?
> I have attached the output of "sudo xl -v create /etc/xen/qemu-pv.cfg"
> as xl_create.txt. I have also enabled DEBUG_XEN_HVM in xen-hvm.c and
> pasted output of "sudo ./x86_64-softmmu/qemu-system-x86_64  -machine
> q35,accel=xen -cpu qemu64 -xen-domid 13" below: 
> 

The output of "sudo xl -vvv create /etc/xen/qemu-pv.cfg" will help
since it includes how xen invokes qemu.

> 
> xen: shared page at pfn feffd
> xen: buffered io page at pfn feffb
> bind interdomain ioctl error 22
> xen hardware virtual machine initialisation failed


This says that where you are reporting the error is not
correct.

The message "buffered io page at pfn feffb" is output
after the code that contains shared_vmport_page.

Also posting the data in /var/log/xen/qemu-dm-qemu-hvm.log
will help.


It looks like you are re-starting QEMU on a domain.  This is not
supported as far as I know (and not clear that you are starting the same
version that xen tried).


> 
> 
> What is the Xen version that you are running?
> 
> I am using XEN 4.4.1 as this is the default on Ubuntu 14.04. I have
> attached the output of "xl info" command as xl_info.txt. 
> 

You are running QEMU 2.2.0 or later based on having
shared_vmport_page in the code.


>Did you execute the xencommons init script at boot time?
> On Ubuntu I don't see /etc/init.d/xencommon but there is a
> /etc/init.d/xen script which starts xenstored and xenconsoled. I did
> confirm from ps aufx that both the daemons are running. I have attched
> log for "ps aufx" as ps_aufx_grep_xen.txt .
> 
> 
> 
> 
> 
> 
> On Mon, Jan 5, 2015 at 4:48 AM, Stefano Stabellini
>  > wrote:
> 
> On Tue, 30 Dec 2014, Rishi Ranjan wrote:
> > I am trying to use Xen as accelerator for my Qemu machine. I have 
> created a guest domain with following xl config: 
> > builder = "hvm"
> > name = "qemu-hvm"
> > memory = "512"
> > vcpus = 1
> > vif = ['']
> > vnc = 1
> > boot="c"
> >
> >
> > When I try to run with following parameters: 
> >
> > -machine q35,accel=xen -cpu qemu64 -bios ./pc-bios/bios-256k.bin 
> -xen-domid "Domain id of guest"
> 
> You should know that q35 emulation is not fully working on Xen yet.
> However Anthony (CC'ed) should have some patches for it.
> 
> That said, it does not look like this error has something to do with
> q35.
> 
> 
> > I am getting follwing error from xen-hvm.c: 
> >
> > "bind interdomain ioctl error" in xen_hvm_init while calling 
> state->shared_vmport_page =
> > xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
> >  PROT_READ|PROT_WRITE, ioreq_pfn); 

To get here, xen_get_vmport_regs_pfn() needs to return 0.

In include/hw/xen/xen_common.h:


#ifdef HVM_PARAM_VMPORT_REGS_PFN
static inline int xen_get_vmport_regs_pfn(XenXC xc, domid_t dom,
  unsigned long *vmport_regs_pfn)
{
return xc_get_hvm_param(xc, dom, HVM_PARAM_VMPORT_REGS_PFN,
vmport_regs_pfn);
}
#else
static inline int xen_get_vmport_regs_pfn(XenXC xc, domid_t dom,
  unsigned long *vmport_regs_pfn)
{
return -ENOSYS;
}
#endif


requires HVM_PARAM_VMPORT_REGS_PFN to be defined before it will return
0.

I am sure that xen 4.4.1 does not define this (patch that does is
waiting for xen 4.6 to open up).


   -Don Slutz

> >
> > Can someone help me get this working? 
> 
> Can you post the full output of the logs?
> What is the Xen version that you are running?
> Did you execute the xencommons init script at boot time?
> 
> 

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

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

[Andy Lutomirski]

On Mon, Jan 5, 2015 at 2:48 PM, Marcelo Tosatti  wrote:
> On Mon, Jan 05, 2015 at 02:38:46PM -0800, Andy Lutomirski wrote:
>> On Mon, Jan 5, 2015 at 11:17 AM, Marcelo Tosatti  wrote:
>> > On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
>> >> On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti  
>> >> wrote:
>> >> > On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
>> >> >> The pvclock vdso code was too abstracted to understand easily and
>> >> >> excessively paranoid.  Simplify it for a huge speedup.
>> >> >>
>> >> >> This opens the door for additional simplifications, as the vdso no
>> >> >> longer accesses the pvti for any vcpu other than vcpu 0.
>> >> >>
>> >> >> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
>> >> >> With this change, it takes 19ns, which is almost as fast as the pure 
>> >> >> TSC
>> >> >> implementation.
>> >> >>
>> >> >> Signed-off-by: Andy Lutomirski 
>> >> >> ---
>> >> >>  arch/x86/vdso/vclock_gettime.c | 82 
>> >> >> --
>> >> >>  1 file changed, 47 insertions(+), 35 deletions(-)
>> >> >>
>> >> >> diff --git a/arch/x86/vdso/vclock_gettime.c 
>> >> >> b/arch/x86/vdso/vclock_gettime.c
>> >> >> index 9793322751e0..f2e0396d5629 100644
>> >> >> --- a/arch/x86/vdso/vclock_gettime.c
>> >> >> +++ b/arch/x86/vdso/vclock_gettime.c
>> >> >> @@ -78,47 +78,59 @@ static notrace const struct 
>> >> >> pvclock_vsyscall_time_info *get_pvti(int cpu)
>> >> >>
>> >> >>  static notrace cycle_t vread_pvclock(int *mode)
>> >> >>  {
>> >> >> - const struct pvclock_vsyscall_time_info *pvti;
>> >> >> + const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>> >> >>   cycle_t ret;
>> >> >> - u64 last;
>> >> >> - u32 version;
>> >> >> - u8 flags;
>> >> >> - unsigned cpu, cpu1;
>> >> >> -
>> >> >> + u64 tsc, pvti_tsc;
>> >> >> + u64 last, delta, pvti_system_time;
>> >> >> + u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>> >> >>
>> >> >>   /*
>> >> >> -  * Note: hypervisor must guarantee that:
>> >> >> -  * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
>> >> >> -  * 2. that per-CPU pvclock time info is updated if the
>> >> >> -  *underlying CPU changes.
>> >> >> -  * 3. that version is increased whenever underlying CPU
>> >> >> -  *changes.
>> >> >> +  * Note: The kernel and hypervisor must guarantee that cpu ID
>> >> >> +  * number maps 1:1 to per-CPU pvclock time info.
>> >> >> +  *
>> >> >> +  * Because the hypervisor is entirely unaware of guest userspace
>> >> >> +  * preemption, it cannot guarantee that per-CPU pvclock time
>> >> >> +  * info is updated if the underlying CPU changes or that that
>> >> >> +  * version is increased whenever underlying CPU changes.
>> >> >> +  *
>> >> >> +  * On KVM, we are guaranteed that pvti updates for any vCPU are
>> >> >> +  * atomic as seen by *all* vCPUs.  This is an even stronger
>> >> >> +  * guarantee than we get with a normal seqlock.
>> >> >>*
>> >> >> +  * On Xen, we don't appear to have that guarantee, but Xen still
>> >> >> +  * supplies a valid seqlock using the version field.
>> >> >> +
>> >> >> +  * We only do pvclock vdso timing at all if
>> >> >> +  * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
>> >> >> +  * mean that all vCPUs have matching pvti and that the TSC is
>> >> >> +  * synced, so we can just look at vCPU 0's pvti.
>> >> >>*/
>> >> >
>> >> > Can Xen guarantee that ?
>> >>
>> >> I think so, vacuously.  Xen doesn't seem to set PVCLOCK_TSC_STABLE_BIT
>> >> at all.  I have no idea going forward, though.
>> >>
>> >> Xen people?
>> >>
>> >> >
>> >> >> - do {
>> >> >> - cpu = __getcpu() & VGETCPU_CPU_MASK;
>> >> >> - /* TODO: We can put vcpu id into higher bits of 
>> >> >> pvti.version.
>> >> >> -  * This will save a couple of cycles by getting rid of
>> >> >> -  * __getcpu() calls (Gleb).
>> >> >> -  */
>> >> >> -
>> >> >> - pvti = get_pvti(cpu);
>> >> >> -
>> >> >> - version = __pvclock_read_cycles(&pvti->pvti, &ret, 
>> >> >> &flags);
>> >> >> -
>> >> >> - /*
>> >> >> -  * Test we're still on the cpu as well as the version.
>> >> >> -  * We could have been migrated just after the first
>> >> >> -  * vgetcpu but before fetching the version, so we
>> >> >> -  * wouldn't notice a version change.
>> >> >> -  */
>> >> >> - cpu1 = __getcpu() & VGETCPU_CPU_MASK;
>> >> >> - } while (unlikely(cpu != cpu1 ||
>> >> >> -   (pvti->pvti.version & 1) ||
>> >> >> -   pvti->pvti.version != version));
>> >> >> -
>> >> >> - if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
>> >> >> +
>> >> >> + if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>> >> >>

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

[Marcelo Tosatti]

On Mon, Jan 05, 2015 at 02:38:46PM -0800, Andy Lutomirski wrote:
> On Mon, Jan 5, 2015 at 11:17 AM, Marcelo Tosatti  wrote:
> > On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
> >> On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti  
> >> wrote:
> >> > On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
> >> >> The pvclock vdso code was too abstracted to understand easily and
> >> >> excessively paranoid.  Simplify it for a huge speedup.
> >> >>
> >> >> This opens the door for additional simplifications, as the vdso no
> >> >> longer accesses the pvti for any vcpu other than vcpu 0.
> >> >>
> >> >> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
> >> >> With this change, it takes 19ns, which is almost as fast as the pure TSC
> >> >> implementation.
> >> >>
> >> >> Signed-off-by: Andy Lutomirski 
> >> >> ---
> >> >>  arch/x86/vdso/vclock_gettime.c | 82 
> >> >> --
> >> >>  1 file changed, 47 insertions(+), 35 deletions(-)
> >> >>
> >> >> diff --git a/arch/x86/vdso/vclock_gettime.c 
> >> >> b/arch/x86/vdso/vclock_gettime.c
> >> >> index 9793322751e0..f2e0396d5629 100644
> >> >> --- a/arch/x86/vdso/vclock_gettime.c
> >> >> +++ b/arch/x86/vdso/vclock_gettime.c
> >> >> @@ -78,47 +78,59 @@ static notrace const struct 
> >> >> pvclock_vsyscall_time_info *get_pvti(int cpu)
> >> >>
> >> >>  static notrace cycle_t vread_pvclock(int *mode)
> >> >>  {
> >> >> - const struct pvclock_vsyscall_time_info *pvti;
> >> >> + const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
> >> >>   cycle_t ret;
> >> >> - u64 last;
> >> >> - u32 version;
> >> >> - u8 flags;
> >> >> - unsigned cpu, cpu1;
> >> >> -
> >> >> + u64 tsc, pvti_tsc;
> >> >> + u64 last, delta, pvti_system_time;
> >> >> + u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
> >> >>
> >> >>   /*
> >> >> -  * Note: hypervisor must guarantee that:
> >> >> -  * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
> >> >> -  * 2. that per-CPU pvclock time info is updated if the
> >> >> -  *underlying CPU changes.
> >> >> -  * 3. that version is increased whenever underlying CPU
> >> >> -  *changes.
> >> >> +  * Note: The kernel and hypervisor must guarantee that cpu ID
> >> >> +  * number maps 1:1 to per-CPU pvclock time info.
> >> >> +  *
> >> >> +  * Because the hypervisor is entirely unaware of guest userspace
> >> >> +  * preemption, it cannot guarantee that per-CPU pvclock time
> >> >> +  * info is updated if the underlying CPU changes or that that
> >> >> +  * version is increased whenever underlying CPU changes.
> >> >> +  *
> >> >> +  * On KVM, we are guaranteed that pvti updates for any vCPU are
> >> >> +  * atomic as seen by *all* vCPUs.  This is an even stronger
> >> >> +  * guarantee than we get with a normal seqlock.
> >> >>*
> >> >> +  * On Xen, we don't appear to have that guarantee, but Xen still
> >> >> +  * supplies a valid seqlock using the version field.
> >> >> +
> >> >> +  * We only do pvclock vdso timing at all if
> >> >> +  * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
> >> >> +  * mean that all vCPUs have matching pvti and that the TSC is
> >> >> +  * synced, so we can just look at vCPU 0's pvti.
> >> >>*/
> >> >
> >> > Can Xen guarantee that ?
> >>
> >> I think so, vacuously.  Xen doesn't seem to set PVCLOCK_TSC_STABLE_BIT
> >> at all.  I have no idea going forward, though.
> >>
> >> Xen people?
> >>
> >> >
> >> >> - do {
> >> >> - cpu = __getcpu() & VGETCPU_CPU_MASK;
> >> >> - /* TODO: We can put vcpu id into higher bits of 
> >> >> pvti.version.
> >> >> -  * This will save a couple of cycles by getting rid of
> >> >> -  * __getcpu() calls (Gleb).
> >> >> -  */
> >> >> -
> >> >> - pvti = get_pvti(cpu);
> >> >> -
> >> >> - version = __pvclock_read_cycles(&pvti->pvti, &ret, 
> >> >> &flags);
> >> >> -
> >> >> - /*
> >> >> -  * Test we're still on the cpu as well as the version.
> >> >> -  * We could have been migrated just after the first
> >> >> -  * vgetcpu but before fetching the version, so we
> >> >> -  * wouldn't notice a version change.
> >> >> -  */
> >> >> - cpu1 = __getcpu() & VGETCPU_CPU_MASK;
> >> >> - } while (unlikely(cpu != cpu1 ||
> >> >> -   (pvti->pvti.version & 1) ||
> >> >> -   pvti->pvti.version != version));
> >> >> -
> >> >> - if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
> >> >> +
> >> >> + if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
> >> >>   *mode = VCLOCK_NONE;
> >> >> + return 0;
> >> >> + }
> >> >
> >> > This check must be performed after reading a stable pvti.
> >> >
> >>
> >> We

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

[Andy Lutomirski]

On Mon, Jan 5, 2015 at 11:17 AM, Marcelo Tosatti  wrote:
> On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
>> On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti  wrote:
>> > On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
>> >> The pvclock vdso code was too abstracted to understand easily and
>> >> excessively paranoid.  Simplify it for a huge speedup.
>> >>
>> >> This opens the door for additional simplifications, as the vdso no
>> >> longer accesses the pvti for any vcpu other than vcpu 0.
>> >>
>> >> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
>> >> With this change, it takes 19ns, which is almost as fast as the pure TSC
>> >> implementation.
>> >>
>> >> Signed-off-by: Andy Lutomirski 
>> >> ---
>> >>  arch/x86/vdso/vclock_gettime.c | 82 
>> >> --
>> >>  1 file changed, 47 insertions(+), 35 deletions(-)
>> >>
>> >> diff --git a/arch/x86/vdso/vclock_gettime.c 
>> >> b/arch/x86/vdso/vclock_gettime.c
>> >> index 9793322751e0..f2e0396d5629 100644
>> >> --- a/arch/x86/vdso/vclock_gettime.c
>> >> +++ b/arch/x86/vdso/vclock_gettime.c
>> >> @@ -78,47 +78,59 @@ static notrace const struct 
>> >> pvclock_vsyscall_time_info *get_pvti(int cpu)
>> >>
>> >>  static notrace cycle_t vread_pvclock(int *mode)
>> >>  {
>> >> - const struct pvclock_vsyscall_time_info *pvti;
>> >> + const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>> >>   cycle_t ret;
>> >> - u64 last;
>> >> - u32 version;
>> >> - u8 flags;
>> >> - unsigned cpu, cpu1;
>> >> -
>> >> + u64 tsc, pvti_tsc;
>> >> + u64 last, delta, pvti_system_time;
>> >> + u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>> >>
>> >>   /*
>> >> -  * Note: hypervisor must guarantee that:
>> >> -  * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
>> >> -  * 2. that per-CPU pvclock time info is updated if the
>> >> -  *underlying CPU changes.
>> >> -  * 3. that version is increased whenever underlying CPU
>> >> -  *changes.
>> >> +  * Note: The kernel and hypervisor must guarantee that cpu ID
>> >> +  * number maps 1:1 to per-CPU pvclock time info.
>> >> +  *
>> >> +  * Because the hypervisor is entirely unaware of guest userspace
>> >> +  * preemption, it cannot guarantee that per-CPU pvclock time
>> >> +  * info is updated if the underlying CPU changes or that that
>> >> +  * version is increased whenever underlying CPU changes.
>> >> +  *
>> >> +  * On KVM, we are guaranteed that pvti updates for any vCPU are
>> >> +  * atomic as seen by *all* vCPUs.  This is an even stronger
>> >> +  * guarantee than we get with a normal seqlock.
>> >>*
>> >> +  * On Xen, we don't appear to have that guarantee, but Xen still
>> >> +  * supplies a valid seqlock using the version field.
>> >> +
>> >> +  * We only do pvclock vdso timing at all if
>> >> +  * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
>> >> +  * mean that all vCPUs have matching pvti and that the TSC is
>> >> +  * synced, so we can just look at vCPU 0's pvti.
>> >>*/
>> >
>> > Can Xen guarantee that ?
>>
>> I think so, vacuously.  Xen doesn't seem to set PVCLOCK_TSC_STABLE_BIT
>> at all.  I have no idea going forward, though.
>>
>> Xen people?
>>
>> >
>> >> - do {
>> >> - cpu = __getcpu() & VGETCPU_CPU_MASK;
>> >> - /* TODO: We can put vcpu id into higher bits of 
>> >> pvti.version.
>> >> -  * This will save a couple of cycles by getting rid of
>> >> -  * __getcpu() calls (Gleb).
>> >> -  */
>> >> -
>> >> - pvti = get_pvti(cpu);
>> >> -
>> >> - version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
>> >> -
>> >> - /*
>> >> -  * Test we're still on the cpu as well as the version.
>> >> -  * We could have been migrated just after the first
>> >> -  * vgetcpu but before fetching the version, so we
>> >> -  * wouldn't notice a version change.
>> >> -  */
>> >> - cpu1 = __getcpu() & VGETCPU_CPU_MASK;
>> >> - } while (unlikely(cpu != cpu1 ||
>> >> -   (pvti->pvti.version & 1) ||
>> >> -   pvti->pvti.version != version));
>> >> -
>> >> - if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
>> >> +
>> >> + if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>> >>   *mode = VCLOCK_NONE;
>> >> + return 0;
>> >> + }
>> >
>> > This check must be performed after reading a stable pvti.
>> >
>>
>> We can even read it in the middle, guarded by the version checks.
>> I'll do that for v2.
>>
>> >> +
>> >> + do {
>> >> + version = pvti->version;
>> >> +
>> >> + /* This is also a read barrier, so we'll read version 
>> >> first. */
>> >> + rdtsc_barrier();
>> >> +

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

[Marcelo Tosatti]

On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
> On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti  wrote:
> > On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
> >> The pvclock vdso code was too abstracted to understand easily and
> >> excessively paranoid.  Simplify it for a huge speedup.
> >>
> >> This opens the door for additional simplifications, as the vdso no
> >> longer accesses the pvti for any vcpu other than vcpu 0.
> >>
> >> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
> >> With this change, it takes 19ns, which is almost as fast as the pure TSC
> >> implementation.
> >>
> >> Signed-off-by: Andy Lutomirski 
> >> ---
> >>  arch/x86/vdso/vclock_gettime.c | 82 
> >> --
> >>  1 file changed, 47 insertions(+), 35 deletions(-)
> >>
> >> diff --git a/arch/x86/vdso/vclock_gettime.c 
> >> b/arch/x86/vdso/vclock_gettime.c
> >> index 9793322751e0..f2e0396d5629 100644
> >> --- a/arch/x86/vdso/vclock_gettime.c
> >> +++ b/arch/x86/vdso/vclock_gettime.c
> >> @@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info 
> >> *get_pvti(int cpu)
> >>
> >>  static notrace cycle_t vread_pvclock(int *mode)
> >>  {
> >> - const struct pvclock_vsyscall_time_info *pvti;
> >> + const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
> >>   cycle_t ret;
> >> - u64 last;
> >> - u32 version;
> >> - u8 flags;
> >> - unsigned cpu, cpu1;
> >> -
> >> + u64 tsc, pvti_tsc;
> >> + u64 last, delta, pvti_system_time;
> >> + u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
> >>
> >>   /*
> >> -  * Note: hypervisor must guarantee that:
> >> -  * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
> >> -  * 2. that per-CPU pvclock time info is updated if the
> >> -  *underlying CPU changes.
> >> -  * 3. that version is increased whenever underlying CPU
> >> -  *changes.
> >> +  * Note: The kernel and hypervisor must guarantee that cpu ID
> >> +  * number maps 1:1 to per-CPU pvclock time info.
> >> +  *
> >> +  * Because the hypervisor is entirely unaware of guest userspace
> >> +  * preemption, it cannot guarantee that per-CPU pvclock time
> >> +  * info is updated if the underlying CPU changes or that that
> >> +  * version is increased whenever underlying CPU changes.
> >> +  *
> >> +  * On KVM, we are guaranteed that pvti updates for any vCPU are
> >> +  * atomic as seen by *all* vCPUs.  This is an even stronger
> >> +  * guarantee than we get with a normal seqlock.
> >>*
> >> +  * On Xen, we don't appear to have that guarantee, but Xen still
> >> +  * supplies a valid seqlock using the version field.
> >> +
> >> +  * We only do pvclock vdso timing at all if
> >> +  * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
> >> +  * mean that all vCPUs have matching pvti and that the TSC is
> >> +  * synced, so we can just look at vCPU 0's pvti.
> >>*/
> >
> > Can Xen guarantee that ?
> 
> I think so, vacuously.  Xen doesn't seem to set PVCLOCK_TSC_STABLE_BIT
> at all.  I have no idea going forward, though.
> 
> Xen people?
> 
> >
> >> - do {
> >> - cpu = __getcpu() & VGETCPU_CPU_MASK;
> >> - /* TODO: We can put vcpu id into higher bits of pvti.version.
> >> -  * This will save a couple of cycles by getting rid of
> >> -  * __getcpu() calls (Gleb).
> >> -  */
> >> -
> >> - pvti = get_pvti(cpu);
> >> -
> >> - version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
> >> -
> >> - /*
> >> -  * Test we're still on the cpu as well as the version.
> >> -  * We could have been migrated just after the first
> >> -  * vgetcpu but before fetching the version, so we
> >> -  * wouldn't notice a version change.
> >> -  */
> >> - cpu1 = __getcpu() & VGETCPU_CPU_MASK;
> >> - } while (unlikely(cpu != cpu1 ||
> >> -   (pvti->pvti.version & 1) ||
> >> -   pvti->pvti.version != version));
> >> -
> >> - if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
> >> +
> >> + if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
> >>   *mode = VCLOCK_NONE;
> >> + return 0;
> >> + }
> >
> > This check must be performed after reading a stable pvti.
> >
> 
> We can even read it in the middle, guarded by the version checks.
> I'll do that for v2.
> 
> >> +
> >> + do {
> >> + version = pvti->version;
> >> +
> >> + /* This is also a read barrier, so we'll read version first. 
> >> */
> >> + rdtsc_barrier();
> >> + tsc = __native_read_tsc();
> >> +
> >> + pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
> >> + pvti_tsc_shift = pvti->tsc_shift;
> >> + 

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

[Paolo Bonzini]

On 05/01/2015 19:56, Andy Lutomirski wrote:
>> > 1) State: all pvtis marked as PVCLOCK_TSC_STABLE_BIT.
>> > 1) Update request for all vcpus, for a TSC_STABLE_BIT -> ~TSC_STABLE_BIT
>> > transition.
>> > 2) vCPU-1 updates its pvti with new values.
>> > 3) vCPU-0 still has not updated its pvti with new values.
>> > 4) vCPU-1 VM-enters, uses vCPU-0 values, even though it has been
>> > notified of a TSC_STABLE_BIT -> ~TSC_STABLE_BIT transition.
>> >
>> > The update is not actually atomic across all vCPUs, its atomic in
>> > the sense of not allowing visibility of distinct
>> > system_timestamp/tsc_timestamp values.
>> >
> Hmm.  In step 4, is there a guarantee that vCPU-0 won't VM-enter until
> it gets marked unstable?  Otherwise the vdso could could just as
> easily be called from vCPU-1, migrated to vCPU-0, read the data
> complete with stale stable bit, and get migrated back to vCPU-1.
> 
> But I thought that KVM currently froze all vCPUs when updating pvti
> for any of them.  How can this happen?  I admit I don't really
> understand the update request code.

That was also my understanding.  I thought this was the point of
kvm_make_mclock_inprogress_request/KVM_REQ_MCLOCK_INPROGRESS.

Disabling TSC_STABLE_BIT is triggered by pvclock_gtod_update_fn but it
happens in kvm_gen_update_masterclock, and no guest entries will happen
in the meanwhile.

Paolo

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

[Xen-devel] [PATCH v17 14/23] x86/VPMU: Initialize VPMUs with __initcall

[Boris Ostrovsky]

Move some VPMU initilization operations into __initcalls to avoid performing
same tests and calculations for each vcpu.

Signed-off-by: Boris Ostrovsky 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/svm/vpmu.c   | 112 
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 151 +++---
 xen/arch/x86/hvm/vpmu.c   |  36 +
 xen/include/asm-x86/hvm/vpmu.h|   2 +
 4 files changed, 161 insertions(+), 140 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 2cfdf08..03474a3 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -375,57 +375,6 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t 
*msr_content)
 return 1;
 }
 
-static int amd_vpmu_initialise(struct vcpu *v)
-{
-struct xen_pmu_amd_ctxt *ctxt;
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
-uint8_t family = current_cpu_data.x86;
-
-if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
-return 0;
-
-if ( counters == NULL )
-{
- switch ( family )
-{
-case 0x15:
-num_counters = F15H_NUM_COUNTERS;
-counters = AMD_F15H_COUNTERS;
-ctrls = AMD_F15H_CTRLS;
-k7_counters_mirrored = 1;
-break;
-case 0x10:
-case 0x12:
-case 0x14:
-case 0x16:
-default:
-num_counters = F10H_NUM_COUNTERS;
-counters = AMD_F10H_COUNTERS;
-ctrls = AMD_F10H_CTRLS;
-k7_counters_mirrored = 0;
-break;
-}
-}
-
-ctxt = xzalloc_bytes(sizeof(*ctxt) +
- 2 * sizeof(uint64_t) * num_counters);
-if ( !ctxt )
-{
-gdprintk(XENLOG_WARNING, "Insufficient memory for PMU, "
-" PMU feature is unavailable on domain %d vcpu %d.\n",
-v->vcpu_id, v->domain->domain_id);
-return -ENOMEM;
-}
-
-ctxt->counters = sizeof(*ctxt);
-ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
-
-vpmu->context = ctxt;
-vpmu->priv_context = NULL;
-vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
-return 0;
-}
-
 static void amd_vpmu_destroy(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
@@ -497,30 +446,63 @@ struct arch_vpmu_ops amd_vpmu_ops = {
 
 int svm_vpmu_initialise(struct vcpu *v)
 {
+struct xen_pmu_amd_ctxt *ctxt;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-uint8_t family = current_cpu_data.x86;
-int ret = 0;
 
-/* vpmu enabled? */
-if ( vpmu_mode == XENPMU_MODE_OFF )
+if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+ vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
 return 0;
 
-switch ( family )
+if ( !counters )
+return -EINVAL;
+
+ctxt = xzalloc_bytes(sizeof(*ctxt) +
+ 2 * sizeof(uint64_t) * num_counters);
+if ( !ctxt )
+{
+printk(XENLOG_G_WARNING "Insufficient memory for PMU, "
+   " PMU feature is unavailable on domain %d vcpu %d.\n",
+   v->vcpu_id, v->domain->domain_id);
+return -ENOMEM;
+}
+
+ctxt->counters = sizeof(*ctxt);
+ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
+
+vpmu->context = ctxt;
+vpmu->priv_context = NULL;
+
+vpmu->arch_vpmu_ops = &amd_vpmu_ops;
+
+vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
+return 0;
+}
+
+int __init amd_vpmu_init(void)
+{
+switch ( current_cpu_data.x86 )
 {
+case 0x15:
+num_counters = F15H_NUM_COUNTERS;
+counters = AMD_F15H_COUNTERS;
+ctrls = AMD_F15H_CTRLS;
+k7_counters_mirrored = 1;
+break;
 case 0x10:
 case 0x12:
 case 0x14:
-case 0x15:
 case 0x16:
-ret = amd_vpmu_initialise(v);
-if ( !ret )
-vpmu->arch_vpmu_ops = &amd_vpmu_ops;
-return ret;
+num_counters = F10H_NUM_COUNTERS;
+counters = AMD_F10H_COUNTERS;
+ctrls = AMD_F10H_CTRLS;
+k7_counters_mirrored = 0;
+break;
+default:
+printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
+   current_cpu_data.x86);
+return -EINVAL;
 }
 
-printk("VPMU: Initialization failed. "
-   "AMD processor family %d has not "
-   "been supported\n", family);
-return -EINVAL;
+return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 4d08d1b..6c78323 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -724,62 +724,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs 
*regs)
 return 1;
 }
 
-static int core2_vpmu_initialise(struct vcpu *v)
-{
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
-u64 msr_content;
-static bool_t ds_warned;
-
-if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
-goto func_out;
-/* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
-while ( bo

[Xen-devel] [PATCH v17 10/23] x86/VPMU: Add public xenpmu.h

[Boris Ostrovsky]

Add pmu.h header files, move various macros and structures that will be
shared between hypervisor and PV guests to it.

Move MSR banks out of architectural PMU structures to allow for larger sizes
in the future. The banks are allocated immediately after the context and
PMU structures store offsets to them.

While making these updates, also:
* Remove unused vpmu_domain() macro from vpmu.h
* Convert msraddr_to_bitpos() into an inline and make it a little faster by
  realizing that all Intel's PMU-related MSRs are in the lower MSR range.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Acked-by: Jan Beulich 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/svm/vpmu.c  |  83 +++--
 xen/arch/x86/hvm/vmx/vpmu_core2.c| 123 +--
 xen/arch/x86/hvm/vpmu.c  |  10 +++
 xen/arch/x86/oprofile/op_model_ppro.c|   6 +-
 xen/include/Makefile |   3 +-
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |  32 
 xen/include/asm-x86/hvm/vpmu.h   |  16 ++--
 xen/include/public/arch-arm.h|   3 +
 xen/include/public/arch-x86/pmu.h|  91 +++
 xen/include/public/pmu.h |  38 ++
 xen/include/xlat.lst |   4 +
 11 files changed, 275 insertions(+), 134 deletions(-)
 delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
 create mode 100644 xen/include/public/arch-x86/pmu.h
 create mode 100644 xen/include/public/pmu.h

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 64dc167..545962d 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -30,10 +30,7 @@
 #include 
 #include 
 #include 
-
-#define F10H_NUM_COUNTERS 4
-#define F15H_NUM_COUNTERS 6
-#define MAX_NUM_COUNTERS F15H_NUM_COUNTERS
+#include 
 
 #define MSR_F10H_EVNTSEL_GO_SHIFT   40
 #define MSR_F10H_EVNTSEL_EN_SHIFT   22
@@ -49,6 +46,9 @@ static const u32 __read_mostly *counters;
 static const u32 __read_mostly *ctrls;
 static bool_t __read_mostly k7_counters_mirrored;
 
+#define F10H_NUM_COUNTERS   4
+#define F15H_NUM_COUNTERS   6
+
 /* PMU Counter MSRs. */
 static const u32 AMD_F10H_COUNTERS[] = {
 MSR_K7_PERFCTR0,
@@ -83,12 +83,14 @@ static const u32 AMD_F15H_CTRLS[] = {
 MSR_AMD_FAM15H_EVNTSEL5
 };
 
-/* storage for context switching */
-struct amd_vpmu_context {
-u64 counters[MAX_NUM_COUNTERS];
-u64 ctrls[MAX_NUM_COUNTERS];
-bool_t msr_bitmap_set;
-};
+/* Use private context as a flag for MSR bitmap */
+#define msr_bitmap_on(vpmu)do {\
+   (vpmu)->priv_context = (void *)-1L; \
+   } while (0)
+#define msr_bitmap_off(vpmu)   do {\
+   (vpmu)->priv_context = NULL;\
+   } while (0)
+#define is_msr_bitmap_on(vpmu) ((vpmu)->priv_context != NULL)
 
 static inline int get_pmu_reg_type(u32 addr)
 {
@@ -142,7 +144,6 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
 {
 unsigned int i;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
 
 for ( i = 0; i < num_counters; i++ )
 {
@@ -150,14 +151,13 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
 svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_WRITE);
 }
 
-ctxt->msr_bitmap_set = 1;
+msr_bitmap_on(vpmu);
 }
 
 static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
 {
 unsigned int i;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
 
 for ( i = 0; i < num_counters; i++ )
 {
@@ -165,7 +165,7 @@ static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
 svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_RW);
 }
 
-ctxt->msr_bitmap_set = 0;
+msr_bitmap_off(vpmu);
 }
 
 static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
@@ -177,19 +177,22 @@ static inline void context_load(struct vcpu *v)
 {
 unsigned int i;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
+struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
+uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
 for ( i = 0; i < num_counters; i++ )
 {
-wrmsrl(counters[i], ctxt->counters[i]);
-wrmsrl(ctrls[i], ctxt->ctrls[i]);
+wrmsrl(counters[i], counter_regs[i]);
+wrmsrl(ctrls[i], ctrl_regs[i]);
 }
 }
 
 static void amd_vpmu_load(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
+struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
 vpmu_reset(vpmu, VPMU_FROZEN);
 
@@ -198,7 +201,7 @@ static void amd_vpmu_load(struct vcpu *v)
 unsigned

[Xen-devel] [PATCH v17 13/23] x86/VPMU: Interface for setting PMU mode and flags

[Boris Ostrovsky]

Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF:  PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
  can profile itself and the hypervisor.

Note that PMU modes are different from what can be provided at Xen's boot line
with 'vpmu' argument. An 'off' (or '0') value is equivalent to XENPMU_MODE_OFF.
Any other value, on the other hand, will cause VPMU mode to be set to
XENPMU_MODE_SELF during boot.

For feature flags only Intel's BTS is currently supported.

Mode and flags are set via HYPERVISOR_xenpmu_op hypercall.

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 
Tested-by: Dietmar Hahn 
---
 tools/flask/policy/policy/modules/xen/xen.te |   3 +
 xen/arch/x86/domain.c|   6 +-
 xen/arch/x86/hvm/svm/vpmu.c  |  25 +++-
 xen/arch/x86/hvm/vmx/vmcs.c  |   7 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c|  27 +++-
 xen/arch/x86/hvm/vpmu.c  | 210 ++-
 xen/arch/x86/oprofile/nmi_int.c  |   3 +-
 xen/arch/x86/x86_64/compat/entry.S   |   4 +
 xen/arch/x86/x86_64/entry.S  |   4 +
 xen/include/asm-x86/hvm/vmx/vmcs.h   |   7 +-
 xen/include/asm-x86/hvm/vpmu.h   |  33 +++--
 xen/include/public/pmu.h |  45 ++
 xen/include/public/xen.h |   1 +
 xen/include/xen/hypercall.h  |   4 +
 xen/include/xlat.lst |   1 +
 xen/include/xsm/dummy.h  |  15 ++
 xen/include/xsm/xsm.h|   6 +
 xen/xsm/dummy.c  |   1 +
 xen/xsm/flask/hooks.c|  18 +++
 xen/xsm/flask/policy/access_vectors  |   2 +
 20 files changed, 390 insertions(+), 32 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index c0128aa..870ff81 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -68,6 +68,9 @@ allow dom0_t xen_t:xen2 {
 resource_op
 psr_cmt_op
 };
+allow dom0_t xen_t:xen2 {
+pmu_ctrl
+};
 allow dom0_t xen_t:mmu memorymap;
 
 # Allow dom0 to use these domctls on itself. For domctls acting on other
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 4e45fa8..d00622d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1544,7 +1544,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 if ( is_hvm_vcpu(prev) )
 {
 if (prev != next)
-vpmu_save(vcpu_vpmu(prev));
+vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(next));
 
 if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
 pt_save_timer(prev);
@@ -1587,9 +1587,9 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
!is_hardware_domain(next->domain));
 }
 
-if (is_hvm_vcpu(next) && (prev != next) )
+if ( is_hvm_vcpu(next) && (prev != next) )
 /* Must be done with interrupts enabled */
-vpmu_load(vcpu_vpmu(next));
+vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
 
 context_saved(prev);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 72e2561..2cfdf08 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
 return 1;
 }
 
+static void amd_vpmu_unload(struct vpmu_struct *vpmu)
+{
+struct vcpu *v;
+
+if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_FROZEN) )
+{
+unsigned int i;
+
+for ( i = 0; i < num_counters; i++ )
+wrmsrl(ctrls[i], 0);
+context_save(vpmu);
+}
+
+v = vpmu_vcpu(vpmu);
+if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
+amd_vpmu_unset_msr_bitmap(v);
+
+vpmu_reset(vpmu, VPMU_FROZEN);
+}
+
 static void context_update(unsigned int msr, u64 msr_content)
 {
 unsigned int i;
@@ -471,17 +491,18 @@ struct arch_vpmu_ops amd_vpmu_ops = {
 .arch_vpmu_destroy = amd_vpmu_destroy,
 .arch_vpmu_save = amd_vpmu_save,
 .arch_vpmu_load = amd_vpmu_load,
+.arch_vpmu_unload = amd_vpmu_unload,
 .arch_vpmu_dump = amd_vpmu_dump
 };
 
-int svm_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int svm_vpmu_initialise(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 uint8_t family = current_cpu_data.x86;
 int ret = 0;
 
 /* vpmu enabled? */
-if ( !vpmu_flags )
+if ( vpmu_mode == XENPMU_MODE_OFF )
 return 0;
 
 switch ( family )
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index b9e3ef8..f45ce93 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1183,11 +1183,10 @@ int vmx

[Xen-devel] [PATCH v17 05/23] x86/VPMU: Make vpmu macros a bit more efficient

[Boris Ostrovsky]

Introduce vpmu_are_all_set that allows testing multiple bits at once. Convert 
macros
into inlines for better compiler checking.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  5 +
 xen/arch/x86/hvm/vpmu.c   |  3 +--
 xen/include/asm-x86/hvm/vpmu.h| 25 +
 3 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index c9fb202..951aece 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -326,10 +326,7 @@ static int core2_vpmu_save(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_SAVE) )
-return 0;
-
-if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) ) 
+if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
 return 0;
 
 __core2_vpmu_save(v);
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index e17e194..63b2158 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -143,8 +143,7 @@ void vpmu_save(struct vcpu *v)
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 int pcpu = smp_processor_id();
 
-if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) &&
-   vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)) )
+if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_ALLOCATED | VPMU_CONTEXT_LOADED) 
)
return;
 
 vpmu->last_pcpu = pcpu;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 1f28bd8..ddc2748 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -82,10 +82,27 @@ struct vpmu_struct {
 #define VPMU_CPU_HAS_BTS0x200 /* Has Branch Trace Store */
 
 
-#define vpmu_set(_vpmu, _x)((_vpmu)->flags |= (_x))
-#define vpmu_reset(_vpmu, _x)  ((_vpmu)->flags &= ~(_x))
-#define vpmu_is_set(_vpmu, _x) ((_vpmu)->flags & (_x))
-#define vpmu_clear(_vpmu)  ((_vpmu)->flags = 0)
+static inline void vpmu_set(struct vpmu_struct *vpmu, const u32 mask)
+{
+vpmu->flags |= mask;
+}
+static inline void vpmu_reset(struct vpmu_struct *vpmu, const u32 mask)
+{
+vpmu->flags &= ~mask;
+}
+static inline void vpmu_clear(struct vpmu_struct *vpmu)
+{
+vpmu->flags = 0;
+}
+static inline bool_t vpmu_is_set(const struct vpmu_struct *vpmu, const u32 
mask)
+{
+return !!(vpmu->flags & mask);
+}
+static inline bool_t vpmu_are_all_set(const struct vpmu_struct *vpmu,
+  const u32 mask)
+{
+return !!((vpmu->flags & mask) == mask);
+}
 
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
-- 
1.8.1.4


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

[Xen-devel] [PATCH v17 11/23] x86/VPMU: Make vpmu not HVM-specific

[Boris Ostrovsky]

vpmu structure will be used for both HVM and PV guests. Move it from
hvm_vcpu to arch_vcpu.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Reviewed-by: Kevin Tian 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/include/asm-x86/domain.h   | 2 ++
 xen/include/asm-x86/hvm/vcpu.h | 3 ---
 xen/include/asm-x86/hvm/vpmu.h | 5 ++---
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 6a77a93..be4d1dc 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -426,6 +426,8 @@ struct arch_vcpu
 void (*ctxt_switch_from) (struct vcpu *);
 void (*ctxt_switch_to) (struct vcpu *);
 
+struct vpmu_struct vpmu;
+
 /* Virtual Machine Extensions */
 union {
 struct pv_vcpu pv_vcpu;
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..71a5b15 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -151,9 +151,6 @@ struct hvm_vcpu {
 u32 msr_tsc_aux;
 u64 msr_tsc_adjust;
 
-/* VPMU */
-struct vpmu_struct  vpmu;
-
 union {
 struct arch_vmx_struct vmx;
 struct arch_svm_struct svm;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 83eea7e..82bfa0e 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -31,9 +31,8 @@
 #define VPMU_BOOT_ENABLED 0x1/* vpmu generally enabled. */
 #define VPMU_BOOT_BTS 0x2/* Intel BTS feature wanted. */
 
-#define vcpu_vpmu(vcpu)   (&((vcpu)->arch.hvm_vcpu.vpmu))
-#define vpmu_vcpu(vpmu)   (container_of((vpmu), struct vcpu, \
-  arch.hvm_vcpu.vpmu))
+#define vcpu_vpmu(vcpu)   (&(vcpu)->arch.vpmu)
+#define vpmu_vcpu(vpmu)   container_of((vpmu), struct vcpu, arch.vpmu)
 
 #define MSR_TYPE_COUNTER0
 #define MSR_TYPE_CTRL   1
-- 
1.8.1.4


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

[Xen-devel] [PATCH v17 07/23] vmx: Merge MSR management routines

[Boris Ostrovsky]

vmx_add_host_load_msr() and vmx_add_guest_msr() share fair amount of code. Merge
them to simplify code maintenance.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/vmx/vmcs.c| 84 +++---
 xen/include/asm-x86/hvm/vmx/vmcs.h | 16 +++-
 2 files changed, 55 insertions(+), 45 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 9d8033e..b9e3ef8 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1201,64 +1201,62 @@ int vmx_write_guest_msr(u32 msr, u64 val)
 return -ESRCH;
 }
 
-int vmx_add_guest_msr(u32 msr)
+int vmx_add_msr(u32 msr, int type)
 {
 struct vcpu *curr = current;
-unsigned int i, msr_count = curr->arch.hvm_vmx.msr_count;
-struct vmx_msr_entry *msr_area = curr->arch.hvm_vmx.msr_area;
+unsigned int idx, *msr_count;
+struct vmx_msr_entry **msr_area, *msr_area_elem;
+
+if ( type == VMX_GUEST_MSR )
+{
+msr_count = &curr->arch.hvm_vmx.msr_count;
+msr_area = &curr->arch.hvm_vmx.msr_area;
+}
+else
+{
+ASSERT(type == VMX_HOST_MSR);
+msr_count = &curr->arch.hvm_vmx.host_msr_count;
+msr_area = &curr->arch.hvm_vmx.host_msr_area;
+}
 
-if ( msr_area == NULL )
+if ( *msr_area == NULL )
 {
-if ( (msr_area = alloc_xenheap_page()) == NULL )
+if ( (*msr_area = alloc_xenheap_page()) == NULL )
 return -ENOMEM;
-curr->arch.hvm_vmx.msr_area = msr_area;
-__vmwrite(VM_EXIT_MSR_STORE_ADDR, virt_to_maddr(msr_area));
-__vmwrite(VM_ENTRY_MSR_LOAD_ADDR, virt_to_maddr(msr_area));
+
+if ( type == VMX_GUEST_MSR )
+{
+__vmwrite(VM_EXIT_MSR_STORE_ADDR, virt_to_maddr(*msr_area));
+__vmwrite(VM_ENTRY_MSR_LOAD_ADDR, virt_to_maddr(*msr_area));
+}
+else
+__vmwrite(VM_EXIT_MSR_LOAD_ADDR, virt_to_maddr(*msr_area));
 }
 
-for ( i = 0; i < msr_count; i++ )
-if ( msr_area[i].index == msr )
+for ( idx = 0; idx < *msr_count; idx++ )
+if ( (*msr_area)[idx].index == msr )
 return 0;
 
-if ( msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
+if ( *msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
 return -ENOSPC;
 
-msr_area[msr_count].index = msr;
-msr_area[msr_count].mbz   = 0;
-msr_area[msr_count].data  = 0;
-curr->arch.hvm_vmx.msr_count = ++msr_count;
-__vmwrite(VM_EXIT_MSR_STORE_COUNT, msr_count);
-__vmwrite(VM_ENTRY_MSR_LOAD_COUNT, msr_count);
+msr_area_elem = *msr_area + *msr_count;
+msr_area_elem->index = msr;
+msr_area_elem->mbz = 0;
 
-return 0;
-}
+++*msr_count;
 
-int vmx_add_host_load_msr(u32 msr)
-{
-struct vcpu *curr = current;
-unsigned int i, msr_count = curr->arch.hvm_vmx.host_msr_count;
-struct vmx_msr_entry *msr_area = curr->arch.hvm_vmx.host_msr_area;
-
-if ( msr_area == NULL )
+if ( type == VMX_GUEST_MSR )
 {
-if ( (msr_area = alloc_xenheap_page()) == NULL )
-return -ENOMEM;
-curr->arch.hvm_vmx.host_msr_area = msr_area;
-__vmwrite(VM_EXIT_MSR_LOAD_ADDR, virt_to_maddr(msr_area));
+msr_area_elem->data = 0;
+__vmwrite(VM_EXIT_MSR_STORE_COUNT, *msr_count);
+__vmwrite(VM_ENTRY_MSR_LOAD_COUNT, *msr_count);
+}
+else
+{
+rdmsrl(msr, msr_area_elem->data);
+__vmwrite(VM_EXIT_MSR_LOAD_COUNT, *msr_count);
 }
-
-for ( i = 0; i < msr_count; i++ )
-if ( msr_area[i].index == msr )
-return 0;
-
-if ( msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
-return -ENOSPC;
-
-msr_area[msr_count].index = msr;
-msr_area[msr_count].mbz   = 0;
-rdmsrl(msr, msr_area[msr_count].data);
-curr->arch.hvm_vmx.host_msr_count = ++msr_count;
-__vmwrite(VM_EXIT_MSR_LOAD_COUNT, msr_count);
 
 return 0;
 }
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 6a99dca..949884b 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -482,12 +482,15 @@ extern const unsigned int 
vmx_introspection_force_enabled_msrs_size;
 
 #define MSR_TYPE_R 1
 #define MSR_TYPE_W 2
+
+#define VMX_GUEST_MSR 0
+#define VMX_HOST_MSR  1
+
 void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
 void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
 int vmx_read_guest_msr(u32 msr, u64 *val);
 int vmx_write_guest_msr(u32 msr, u64 val);
-int vmx_add_guest_msr(u32 msr);
-int vmx_add_host_load_msr(u32 msr);
+int vmx_add_msr(u32 msr, int type);
 void vmx_vmcs_switch(struct vmcs_struct *from, struct vmcs_struct *to);
 void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector);
 void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector);
@@ -497,6 +500,15 @@ void v

[Xen-devel] [PATCH v17 04/23] x86/VPMU: Set MSR bitmaps only for HVM/PVH guests

[Boris Ostrovsky]

In preparation for making VPMU code shared with PV make sure that we we update
MSR bitmaps only for HVM/PVH guests

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/svm/vpmu.c   | 21 +
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  8 +---
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 4c448bb..19777e3 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -244,7 +244,8 @@ static int amd_vpmu_save(struct vcpu *v)
 
 context_save(v);
 
-if ( !vpmu_is_set(vpmu, VPMU_RUNNING) && ctx->msr_bitmap_set )
+if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
+ has_hvm_container_vcpu(v) && ctx->msr_bitmap_set )
 amd_vpmu_unset_msr_bitmap(v);
 
 return 1;
@@ -287,8 +288,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 ASSERT(!supported);
 
 /* For all counters, enable guest only mode for HVM guest */
-if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
-!(is_guest_mode(msr_content)) )
+if ( has_hvm_container_vcpu(v) &&
+ (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
+ !is_guest_mode(msr_content) )
 {
 set_guest_mode(msr_content);
 }
@@ -303,8 +305,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 apic_write(APIC_LVTPC, PMU_APIC_VECTOR);
 vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR;
 
-if ( !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
-amd_vpmu_set_msr_bitmap(v);
+if ( has_hvm_container_vcpu(v) &&
+ !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+ amd_vpmu_set_msr_bitmap(v);
 }
 
 /* stop saving & restore if guest stops first counter */
@@ -314,8 +317,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
 vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
 vpmu_reset(vpmu, VPMU_RUNNING);
-if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
-amd_vpmu_unset_msr_bitmap(v);
+if ( has_hvm_container_vcpu(v) &&
+ ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+ amd_vpmu_unset_msr_bitmap(v);
 release_pmu_ownship(PMU_OWNER_HVM);
 }
 
@@ -403,7 +407,8 @@ static void amd_vpmu_destroy(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
+if ( has_hvm_container_vcpu(v) &&
+ ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
 amd_vpmu_unset_msr_bitmap(v);
 
 xfree(vpmu->context);
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 590c2a9..c9fb202 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -335,7 +335,8 @@ static int core2_vpmu_save(struct vcpu *v)
 __core2_vpmu_save(v);
 
 /* Unset PMU MSR bitmap to trap lazy load. */
-if ( !vpmu_is_set(vpmu, VPMU_RUNNING) && cpu_has_vmx_msr_bitmap )
+if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
+ has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
 core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
 
 return 1;
@@ -448,7 +449,8 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int 
*type, int *index)
 {
 __core2_vpmu_load(current);
 vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
-if ( cpu_has_vmx_msr_bitmap )
+if ( has_hvm_container_vcpu(current) &&
+ cpu_has_vmx_msr_bitmap )
 core2_vpmu_set_msr_bitmap(current->arch.hvm_vmx.msr_bitmap);
 }
 return 1;
@@ -820,7 +822,7 @@ static void core2_vpmu_destroy(struct vcpu *v)
 
 xfree(core2_vpmu_cxt->pmu_enable);
 xfree(vpmu->context);
-if ( cpu_has_vmx_msr_bitmap )
+if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
 core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
 release_pmu_ownship(PMU_OWNER_HVM);
 vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
-- 
1.8.1.4


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

[Xen-devel] [PATCH v17 19/23] x86/VPMU: Handle PMU interrupts for PV guests

[Boris Ostrovsky]

Add support for handling PMU interrupts for PV guests.

VPMU for the interrupted VCPU is unloaded until the guest issues XENPMU_flush
hypercall. This allows the guest to access PMU MSR values that are stored in
VPMU context which is shared between hypervisor and domain, thus avoiding
traps to hypervisor.

Since the interrupt handler may now force VPMU context save (i.e. set
VPMU_CONTEXT_SAVE flag) we need to make changes to amd_vpmu_save() which
until now expected this flag to be set only when the counters were stopped.

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 
Acked-by: Jan Beulich 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/svm/vpmu.c   |  11 +-
 xen/arch/x86/hvm/vpmu.c   | 208 --
 xen/include/public/arch-x86/pmu.h |   6 ++
 xen/include/public/pmu.h  |   2 +
 xen/include/xsm/dummy.h   |   4 +-
 xen/xsm/flask/hooks.c |   2 +
 6 files changed, 213 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 27c8a9c..68113c7 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -225,17 +225,12 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
 struct vcpu *v;
 unsigned int i;
 
-/*
- * Stop the counters. If we came here via vpmu_save_force (i.e.
- * when VPMU_CONTEXT_SAVE is set) counters are already stopped.
- */
+for ( i = 0; i < num_counters; i++ )
+wrmsrl(ctrls[i], 0);
+
 if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_SAVE) )
 {
 vpmu_set(vpmu, VPMU_FROZEN);
-
-for ( i = 0; i < num_counters; i++ )
-wrmsrl(ctrls[i], 0);
-
 return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 800d98c..c57b250 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -80,27 +80,52 @@ static void __init parse_vpmu_param(char *s)
 
 void vpmu_lvtpc_update(uint32_t val)
 {
-struct vpmu_struct *vpmu = vcpu_vpmu(current);
+struct vcpu *curr = current;
+struct vpmu_struct *vpmu = vcpu_vpmu(curr);
 
 vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
-apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
+
+/* Postpone APIC updates for PV(H) guests if PMU interrupt is pending */
+if ( is_hvm_vcpu(curr) || !vpmu->xenpmu_data ||
+ !(vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
+apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
 
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
 {
-struct vpmu_struct *vpmu = vcpu_vpmu(current);
+struct vcpu *curr = current;
+struct vpmu_struct *vpmu;
 
 if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
 return 0;
 
+vpmu = vcpu_vpmu(curr);
 if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
-return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
+{
+int ret = vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
+
+/*
+ * We may have received a PMU interrupt during WRMSR handling
+ * and since do_wrmsr may load VPMU context we should save
+ * (and unload) it again.
+ */
+if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+ (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
+{
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu);
+vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+}
+return ret;
+}
+
 return 0;
 }
 
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
 {
-struct vpmu_struct *vpmu = vcpu_vpmu(current);
+struct vcpu *curr = current;
+struct vpmu_struct *vpmu;
 
 if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
 {
@@ -108,24 +133,161 @@ int vpmu_do_rdmsr(unsigned int msr, uint64_t 
*msr_content)
 return 0;
 }
 
+vpmu = vcpu_vpmu(curr);
 if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
-return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
+{
+int ret = vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
+
+if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+ (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
+{
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu);
+vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+}
+return ret;
+}
 else
 *msr_content = 0;
 
 return 0;
 }
 
+static struct vcpu *choose_hwdom_vcpu(void)
+{
+unsigned idx = smp_processor_id() % hardware_domain->max_vcpus;
+
+if ( hardware_domain->vcpu == NULL )
+return NULL;
+
+return hardware_domain->vcpu[idx];
+}
+
 void vpmu_do_interrupt(struct cpu_user_regs *regs)
 {
-struct vcpu *v = current;
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
+str

[Xen-devel] [PATCH v17 01/23] common/symbols: Export hypervisor symbols to privileged guest

[Boris Ostrovsky]

Export Xen's symbols as {} triplet via new XENPF_get_symbol
hypercall

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/platform_hypercall.c   | 28 +++
 xen/common/symbols.c| 54 +
 xen/include/public/platform.h   | 19 +
 xen/include/xen/symbols.h   |  3 +++
 xen/include/xlat.lst|  1 +
 xen/xsm/flask/hooks.c   |  4 +++
 xen/xsm/flask/policy/access_vectors |  2 ++
 7 files changed, 111 insertions(+)

diff --git a/xen/arch/x86/platform_hypercall.c 
b/xen/arch/x86/platform_hypercall.c
index 32f39b2..7b37960 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -760,6 +761,33 @@ ret_t 
do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
 }
 break;
 
+case XENPF_get_symbol:
+{
+static char name[KSYM_NAME_LEN + 1]; /* protected by xenpf_lock */
+XEN_GUEST_HANDLE(char) nameh;
+uint32_t namelen, copylen;
+
+guest_from_compat_handle(nameh, op->u.symdata.name);
+
+ret = xensyms_read(&op->u.symdata.symnum, &op->u.symdata.type,
+   &op->u.symdata.address, name);
+
+namelen = strlen(name) + 1;
+
+if ( namelen > op->u.symdata.namelen )
+copylen = op->u.symdata.namelen;
+else
+copylen = namelen;
+
+op->u.symdata.namelen = namelen;
+
+if ( !ret && copy_to_guest(nameh, name, copylen) )
+ret = -EFAULT;
+if ( !ret && __copy_field_to_guest(u_xenpf_op, op, u.symdata) )
+ret = -EFAULT;
+}
+break;
+
 default:
 ret = -ENOSYS;
 break;
diff --git a/xen/common/symbols.c b/xen/common/symbols.c
index bc2fde6..2c0942d 100644
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef SYMBOLS_ORIGIN
 extern const unsigned int symbols_offsets[1];
@@ -148,3 +150,55 @@ const char *symbols_lookup(unsigned long addr,
 *offset = addr - symbols_address(low);
 return namebuf;
 }
+
+/*
+ * Get symbol type information. This is encoded as a single char at the
+ * beginning of the symbol name.
+ */
+static char symbols_get_symbol_type(unsigned int off)
+{
+/*
+ * Get just the first code, look it up in the token table,
+ * and return the first char from this token.
+ */
+return symbols_token_table[symbols_token_index[symbols_names[off + 1]]];
+}
+
+int xensyms_read(uint32_t *symnum, char *type,
+ uint64_t *address, char *name)
+{
+/*
+ * Symbols are most likely accessed sequentially so we remember position
+ * from previous read. This can help us avoid the extra call to
+ * get_symbol_offset().
+ */
+static uint64_t next_symbol, next_offset;
+static DEFINE_SPINLOCK(symbols_mutex);
+
+if ( *symnum > symbols_num_syms )
+return -ERANGE;
+if ( *symnum == symbols_num_syms )
+{
+/* No more symbols */
+name[0] = '\0';
+return 0;
+}
+
+spin_lock(&symbols_mutex);
+
+if ( *symnum == 0 )
+next_offset = next_symbol = 0;
+if ( next_symbol != *symnum )
+/* Non-sequential access */
+next_offset = get_symbol_offset(*symnum);
+
+*type = symbols_get_symbol_type(next_offset);
+next_offset = symbols_expand_symbol(next_offset, name);
+*address = symbols_offsets[*symnum] + SYMBOLS_ORIGIN;
+
+next_symbol = ++*symnum;
+
+spin_unlock(&symbols_mutex);
+
+return 0;
+}
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 5c57615..6dd7732 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -560,6 +560,24 @@ struct xenpf_resource_op {
 typedef struct xenpf_resource_op xenpf_resource_op_t;
 DEFINE_XEN_GUEST_HANDLE(xenpf_resource_op_t);
 
+#define XENPF_get_symbol   62
+struct xenpf_symdata {
+/* IN/OUT variables */
+uint32_t namelen; /* IN:  size of name buffer   */
+  /* OUT: strlen(name) of hypervisor symbol (may be */
+  /*  larger than what's been copied to guest)  */
+uint32_t symnum;  /* IN:  Symbol to read*/
+  /* OUT: Next available symbol. If same as IN then */
+  /*  we reached the end*/
+
+/* OUT variables */
+XEN_GUEST_HANDLE(char) name;
+uint64_t address;
+char type;
+};
+typedef struct xenpf_symdata xenpf_symdata_t;
+DEFINE_XEN_GUEST_HANDLE(xenpf_symdata_t);
+
 /*
  * ` enum neg_errnoval
  * ` HYPERVISOR_platform_op(const struct xen_platform_op*);
@@ -587,6 +605,7 @@ struct xen_platform_op {
 

[Xen-devel] [PATCH v17 00/23] x86/PMU: Xen PMU PV(H) support

[Boris Ostrovsky]

Version 17 of PV(H) PMU patches.

Changes in v17:
* Disable VPMU when unknown CPU vendor is detected (patch #2)
* Remove unnecessary vendor tests in vendor-specific init routines (patch #14)
* Remember first CPU that starts mode change and use it to stop the cycle 
(patch #13)
* If vpmu ops is not present, return 0 as value for VPMU MSR read (as opposed 
to 
  returning an error as was the case in previous patch.) (patch #18)
  * Change slightly vpmu_do_msr() logic as result of this chage (patch #20)
* stringify VPMU version (patch #14)
* Use 'CS > 1' to mark sample as PMU_SAMPLE_USER (patch #19)

Changes in v16:

* Many changes in VPMU mode patch (#13):
  * Replaced arguments to some vpmu routines (vcpu -> vpmu). New patch (#12)
  * Added vpmu_unload vpmu op to completely unload vpmu data (e.g clear
MSR bitmaps). This routine may be called in context switch 
(vpmu_switch_to()).
  * Added vmx_write_guest_msr_vcpu() interface to write MSRs of non-current VCPU
  * Use cpumask_cycle instead of cpumask_next
  * Dropped timeout error
  * Adjusted types of mode variables
  * Don't allow oprofile to allocate its context on MSR access if VPMU context
has already been allocated (which may happen when VMPU mode was set to off
while the guest was running)
* vpmu_initialise() no longer turns off VPMU globally on failure. New patch (#2)
* vpmu_do_msr() will return 1 (failure) if vpmu_ops are not set. This is done to
  prevent PV guests that are not VPMU-enabled from wrongly assuming that they 
have
  access to counters (Linux check_hw_exists() will make this assumption) (patch 
#18)
* Add cpl field to shared structure that will be passed for HVM guests' samples
  (instead of PMU_SAMPLE_USER flag). Add PMU_SAMPLE_PV flag to mark whose sample
  is passed up. (Patches ## 10, 19, 22)

Changes in v15:

* Rewrote vpmu_force_context_switch() to use continue_hypercall_on_cpu()
* Added vpmu_init initcall that will call vendor-specific init routines
* Added a lock to vpmu_struct to serialize pmu_init()/pmu_finish()
* Use SS instead of CS for DPL (instead of RPL)
* Don't take lock for XENPMU_mode_get
* Make vmpu_mode/features an unsigned int (from uint64_t)
* Adjusted pvh_hypercall64_table[] order
* Replaced address range check [XEN_VIRT_START..XEN_VIRT_END] with guest_mode()
* A few style cleanups

Changes in v14:

* Moved struct xen_pmu_regs to pmu.h
* Moved CHECK_pmu_* to an earlier patch (when structures are first introduced)
* Added PMU_SAMPLE_REAL flag to indicate whether the sample was taken in real 
mode
* Simplified slightly setting rules for xenpmu_data flags
* Rewrote vpmu_force_context_switch() to again use continuations. (Returning 
EAGAIN
  to user would mean that VPMU mode may get into inconsistent state (across 
processors)
  and dealing with that is more compicated than I'd like).
* Fixed msraddr_to_bitpos() and converted it into an inline
* Replaced address range check in vmpu_do_interrupt() with guest_mode()
* No error returns from __initcall
* Rebased on top of recent VPMU changes
* Various cleanups

Changes in v13:

* Rearranged data in xenpf_symdata to eliminate a hole (no change in
  structure size)
* Removed unnecessary zeroing of last character in name string during
  symbol read hypercall
* Updated comment in access_vectors for pmu_use operation
* Compute AMD MSR bank size at runtime
* Moved a couple of BUILD_BUG_ON later, to when the structures they are
  checking are first used
* Added ss and eflags to xen_pmu_registers structure
* vpmu_force_context_switch() uses per-cpu tasklet pointers.
* Moved most of arch-specific VPMU initialization code into an __initcall()
  to avoid re-calculating/re-checking things more than once (new patch, #12)
* Replaced is_*_domain() with is_*_vcpu()
* choose_hwdom_vcpu() will now assume that hardware_domain->vcpu[idx]
  is always there (callers will still verify whether or not that's true)
* Fixed a couple of sampled vs. sampling tests in vpmu_do_interrupt()
* Pass CS to the guest unchanged, add pmu_flags's flag to indicate whether the
  sample was for a user or kernel space. Move pmu_flags from xen_pmu_data into
  xen_pmu_arch
* Removed local msr_content variable from vpmu_do_wrmsr()
* Re-arranged code in parse_vpmu_param()
* Made vpmu_interrupt_type checks test for value, not individual bits
* Moved PMU_SOFTIRQ definition into arch-specific header
* Moved vpmu*.c files into xen/arch/x86/cpu/ instead of xen/arch/x86/
* For hypervisor samples, report DOMID_XEN to the guest
* Changed logic to select which registers to report to the guest (include RIP
  check to see whether we are in the hypervisor)

Changes in v12:

* Added XSM support
* Made a valifity check before writing MSR_CORE_PERF_GLOBAL_OVF_CTRL
* Updated documentation for 'vpmu=nmi' option
* Added more text to a bunch of commit messages (per Konrad's request)

Changes in v11:

* Replaced cpu_user_regs with new xen_pmu_regs (IP, SP, CS) in xen_pmu_arch.
  - as part of this re-work noticed that CS regis

[Xen-devel] [PATCH v17 22/23] x86/VPMU: NMI-based VPMU support

[Boris Ostrovsky]

Add support for using NMIs as PMU interrupts to allow profiling hypervisor
when interrupts are disabled.

Most of processing is still performed by vpmu_do_interrupt(). However, since
certain operations are not NMI-safe we defer them to a softint that 
vpmu_do_interrupt()
will schedule:
* For PV guests that would be send_guest_vcpu_virq()
* For HVM guests it's VLAPIC accesses and hvm_get_segment_register() (the later
can be called in privileged profiling mode when the interrupted guest is an HVM 
one).

With send_guest_vcpu_virq() and hvm_get_segment_register() for PV(H) and vlapic
accesses for HVM moved to sofint, the only routines/macros that 
vpmu_do_interrupt()
calls in NMI mode are:
* memcpy()
* querying domain type (is_XX_domain())
* guest_cpu_user_regs()
* XLAT_cpu_user_regs()
* raise_softirq()
* vcpu_vpmu()
* vpmu_ops->arch_vpmu_save()
* vpmu_ops->do_interrupt()

The latter two only access PMU MSRs with {rd,wr}msrl() (not the _safe versions
which would not be NMI-safe).

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 docs/misc/xen-command-line.markdown |   8 +-
 xen/arch/x86/hvm/svm/vpmu.c |   3 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c   |   3 +-
 xen/arch/x86/hvm/vpmu.c | 226 
 xen/include/asm-x86/hvm/vpmu.h  |   4 +-
 xen/include/asm-x86/softirq.h   |   3 +-
 6 files changed, 192 insertions(+), 55 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 152ae03..f3d64c7 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1314,11 +1314,11 @@ Use Virtual Processor ID support if available.  This 
prevents the need for TLB
 flushes on VM entry and exit, increasing performance.
 
 ### vpmu
-> `= ( bts )`
+> `= ( [nmi,][bts] )`
 
 > Default: `off`
 
-Switch on the virtualized performance monitoring unit for HVM guests.
+Switch on the virtualized performance monitoring unit.
 
 If the current cpu isn't supported a message like
 'VPMU: Initialization failed. ...'
@@ -1330,6 +1330,10 @@ wrong behaviour (see handle\_pmc\_quirk()).
 If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
 feature is switched on on Intel processors supporting this feature.
 
+If 'vpmu=nmi' is specified the PMU interrupt will cause an NMI instead of a
+regular vector interrupt (which is the default). This can be useful for 
sampling
+hypervisor code that is executed with interrupts disabled.
+
 *Warning:*
 As the BTS virtualisation is not 100% safe and because of the nehalem quirk
 don't use the vpmu flag on production systems with Intel cpus!
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 68113c7..7ddce33 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -168,7 +168,7 @@ static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
 msr_bitmap_off(vpmu);
 }
 
-static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
+static int amd_vpmu_do_interrupt(const struct cpu_user_regs *regs)
 {
 return 1;
 }
@@ -220,6 +220,7 @@ static inline void context_save(struct vpmu_struct *vpmu)
 rdmsrl(counters[i], counter_regs[i]);
 }
 
+/* Must be NMI-safe */
 static int amd_vpmu_save(struct vpmu_struct *vpmu)
 {
 struct vcpu *v;
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 8067d83..0c7fd74 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -305,6 +305,7 @@ static inline void __core2_vpmu_save(struct vpmu_struct 
*vpmu)
 rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
+/* Must be NMI-safe */
 static int core2_vpmu_save(struct vpmu_struct *vpmu)
 {
 struct vcpu *v = vpmu_vcpu(vpmu);
@@ -720,7 +721,7 @@ static void core2_vpmu_dump(const struct vcpu *v)
 }
 }
 
-static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
+static int core2_vpmu_do_interrupt(const struct cpu_user_regs *regs)
 {
 struct vcpu *v = current;
 u64 msr_content;
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index ebab0f5..2ba0feb 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -54,36 +55,54 @@ unsigned int __read_mostly vpmu_features = 0;
 static void parse_vpmu_param(char *s);
 custom_param("vpmu", parse_vpmu_param);
 
+static void pmu_softnmi(void);
+
 static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
+static DEFINE_PER_CPU(struct vcpu *, sampled_vcpu);
+
+static uint32_t __read_mostly vpmu_interrupt_type = PMU_APIC_VECTOR;
 
 static void __init parse_vpmu_param(char *s)
 {
-switch ( parse_bool(s) )
-{
-case 0:
-break;
-default:
-if ( !strcmp(s, "bts") )
-vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
-else if ( *s )
+char *ss;
+
+vpmu_mode = XENPMU

[Xen-devel] [PATCH v17 23/23] x86/VPMU: Move VPMU files up from hvm/ directory

[Boris Ostrovsky]

Since PMU is now not HVM specific we can move VPMU-related files up from
arch/x86/hvm/ directory.

Specifically:
arch/x86/hvm/vpmu.c -> arch/x86/cpu/vpmu.c
arch/x86/hvm/svm/vpmu.c -> arch/x86/cpu/vpmu_amd.c
arch/x86/hvm/vmx/vpmu_core2.c -> arch/x86/cpu/vpmu_intel.c
include/asm-x86/hvm/vpmu.h -> include/asm-x86/vpmu.h

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/cpu/Makefile   | 1 +
 xen/arch/x86/{hvm => cpu}/vpmu.c| 2 +-
 xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} | 2 +-
 xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 2 +-
 xen/arch/x86/hvm/Makefile   | 1 -
 xen/arch/x86/hvm/svm/Makefile   | 1 -
 xen/arch/x86/hvm/vlapic.c   | 2 +-
 xen/arch/x86/hvm/vmx/Makefile   | 1 -
 xen/arch/x86/oprofile/op_model_ppro.c   | 2 +-
 xen/arch/x86/traps.c| 2 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h  | 2 +-
 xen/include/asm-x86/{hvm => }/vpmu.h| 0
 12 files changed, 8 insertions(+), 10 deletions(-)
 rename xen/arch/x86/{hvm => cpu}/vpmu.c (99%)
 rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (99%)
 rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (99%)
 rename xen/include/asm-x86/{hvm => }/vpmu.h (100%)

diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index d73d93a..74f23ae 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -7,3 +7,4 @@ obj-y += common.o
 obj-y += intel.o
 obj-y += intel_cacheinfo.o
 obj-y += mwait-idle.o
+obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/cpu/vpmu.c
similarity index 99%
rename from xen/arch/x86/hvm/vpmu.c
rename to xen/arch/x86/cpu/vpmu.c
index 2ba0feb..4c632a9 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -27,10 +27,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/cpu/vpmu_amd.c
similarity index 99%
rename from xen/arch/x86/hvm/svm/vpmu.c
rename to xen/arch/x86/cpu/vpmu_amd.c
index 7ddce33..35b0b75 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -28,8 +28,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 
 #define MSR_F10H_EVNTSEL_GO_SHIFT   40
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/cpu/vpmu_intel.c
similarity index 99%
rename from xen/arch/x86/hvm/vmx/vpmu_core2.c
rename to xen/arch/x86/cpu/vpmu_intel.c
index 0c7fd74..8c6349e 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /*
  * See Intel SDM Vol 2a Instruction Set Reference chapter 3 for CPUID
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index eea..742b83b 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -22,4 +22,3 @@ obj-y += vlapic.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
-obj-y += vpmu.o
\ No newline at end of file
diff --git a/xen/arch/x86/hvm/svm/Makefile b/xen/arch/x86/hvm/svm/Makefile
index a10a55e..760d295 100644
--- a/xen/arch/x86/hvm/svm/Makefile
+++ b/xen/arch/x86/hvm/svm/Makefile
@@ -6,4 +6,3 @@ obj-y += nestedsvm.o
 obj-y += svm.o
 obj-y += svmdebug.o
 obj-y += vmcb.o
-obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 56b9d23..9ec5da1 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -33,12 +33,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/xen/arch/x86/hvm/vmx/Makefile b/xen/arch/x86/hvm/vmx/Makefile
index 373b3d9..04a29ce 100644
--- a/xen/arch/x86/hvm/vmx/Makefile
+++ b/xen/arch/x86/hvm/vmx/Makefile
@@ -3,5 +3,4 @@ obj-y += intr.o
 obj-y += realmode.o
 obj-y += vmcs.o
 obj-y += vmx.o
-obj-y += vpmu_core2.o
 obj-y += vvmx.o
diff --git a/xen/arch/x86/oprofile/op_model_ppro.c 
b/xen/arch/x86/oprofile/op_model_ppro.c
index ca429a1..89649d0 100644
--- a/xen/arch/x86/oprofile/op_model_ppro.c
+++ b/xen/arch/x86/oprofile/op_model_ppro.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "op_x86_model.h"
 #include "op_counter.h"
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 663b44f..33f0fc5 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -72,7 +72,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/v

[Xen-devel] [PATCH v17 18/23] x86/VPMU: Add support for PMU register handling on PV guests

[Boris Ostrovsky]

Intercept accesses to PMU MSRs and process them in VPMU module. If vpmu ops
for VCPU are not initialized (which is the case, for example, for PV guests that
are not "VPMU-enlightened") access to MSRs will return failure.

Dump VPMU state for all domains (HVM and PV) when requested.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Acked-by: Kevin Tian 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/domain.c |  3 +--
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 53 +++
 xen/arch/x86/hvm/vpmu.c   |  3 +++
 xen/arch/x86/traps.c  | 50 +++-
 4 files changed, 96 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7d5d46b..db6e6ef 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2081,8 +2081,7 @@ void arch_dump_vcpu_info(struct vcpu *v)
 {
 paging_dump_vcpu_info(v);
 
-if ( is_hvm_vcpu(v) )
-vpmu_dump(v);
+vpmu_dump(v);
 }
 
 void domain_cpuid(
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index f5b9453..8067d83 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -299,19 +300,23 @@ static inline void __core2_vpmu_save(struct vpmu_struct 
*vpmu)
 rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, fixed_counters[i]);
 for ( i = 0; i < arch_pmc_cnt; i++ )
 rdmsrl(MSR_IA32_PERFCTR0 + i, xen_pmu_cntr_pair[i].counter);
+
+if ( !has_hvm_container_vcpu(vpmu_vcpu(vpmu)) )
+rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
 static int core2_vpmu_save(struct vpmu_struct *vpmu)
 {
-struct vcpu *v;
+struct vcpu *v = vpmu_vcpu(vpmu);
+
+if ( !has_hvm_container_vcpu(v) )
+wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
 
 if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
 return 0;
 
 __core2_vpmu_save(vpmu);
 
-v = vpmu_vcpu(vpmu);
-
 /* Unset PMU MSR bitmap to trap lazy load. */
 if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
  has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
@@ -360,6 +365,13 @@ static inline void __core2_vpmu_load(struct vpmu_struct 
*vpmu)
 wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
 wrmsrl(MSR_IA32_DS_AREA, core2_vpmu_cxt->ds_area);
 wrmsrl(MSR_IA32_PEBS_ENABLE, core2_vpmu_cxt->pebs_enable);
+
+if ( !has_hvm_container_vcpu(vpmu_vcpu(vpmu)) )
+{
+wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, core2_vpmu_cxt->global_ovf_ctrl);
+core2_vpmu_cxt->global_ovf_ctrl = 0;
+wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
+}
 }
 
 static void core2_vpmu_load(struct vpmu_struct *vpmu)
@@ -458,7 +470,6 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int 
*type, int *index)
 static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
uint64_t supported)
 {
-u64 global_ctrl;
 int i, tmp;
 int type = -1, index = -1;
 struct vcpu *v = current;
@@ -502,7 +513,12 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 switch ( msr )
 {
 case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+if ( msr_content & ~(0xC000 |
+ (((1ULL << fixed_pmc_cnt) - 1) << 32) |
+ ((1ULL << arch_pmc_cnt) - 1)) )
+return 1;
 core2_vpmu_cxt->global_status &= ~msr_content;
+wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
 return 0;
 case MSR_CORE_PERF_GLOBAL_STATUS:
 gdprintk(XENLOG_INFO, "Can not write readonly MSR: "
@@ -530,14 +546,18 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
 return 0;
 case MSR_CORE_PERF_GLOBAL_CTRL:
-global_ctrl = msr_content;
+core2_vpmu_cxt->global_ctrl = msr_content;
 break;
 case MSR_CORE_PERF_FIXED_CTR_CTRL:
 if ( msr_content &
  ( ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1)) )
 return 1;
 
-vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+if ( has_hvm_container_vcpu(v) )
+vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
+   &core2_vpmu_cxt->global_ctrl);
+else
+rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
 *enabled_cntrs &= ~(((1ULL << fixed_pmc_cnt) - 1) << 32);
 if ( msr_content != 0 )
 {
@@ -562,7 +582,11 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 if ( msr_content & (~((1ull << 32) - 1)) )
 return 1;
 
-vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+   

[Xen-devel] [PATCH v17 15/23] x86/VPMU: Initialize PMU for PV(H) guests

[Boris Ostrovsky]

Code for initializing/tearing down PMU for PV guests

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Acked-by: Jan Beulich 
Acked-by: Daniel De Graaf  
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 tools/flask/policy/policy/modules/xen/xen.te |   4 ++
 xen/arch/x86/domain.c|   2 +
 xen/arch/x86/hvm/hvm.c   |   1 +
 xen/arch/x86/hvm/svm/svm.c   |   4 +-
 xen/arch/x86/hvm/svm/vpmu.c  |  44 
 xen/arch/x86/hvm/vmx/vmx.c   |   4 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c|  79 +++--
 xen/arch/x86/hvm/vpmu.c  | 101 +--
 xen/common/event_channel.c   |   1 +
 xen/include/asm-x86/hvm/vpmu.h   |   2 +
 xen/include/public/pmu.h |   2 +
 xen/include/public/xen.h |   1 +
 xen/include/xsm/dummy.h  |   3 +
 xen/xsm/flask/hooks.c|   4 ++
 xen/xsm/flask/policy/access_vectors  |   2 +
 15 files changed, 211 insertions(+), 43 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index 870ff81..73bbe7b 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -120,6 +120,10 @@ domain_comms(dom0_t, dom0_t)
 # Allow all domains to use (unprivileged parts of) the tmem hypercall
 allow domain_type xen_t:xen tmem_op;
 
+# Allow all domains to use PMU (but not to change its settings --- that's what
+# pmu_ctrl is for)
+allow domain_type xen_t:xen2 pmu_use;
+
 ###
 #
 # Domain creation
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d00622d..a29db67 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -445,6 +445,8 @@ int vcpu_initialise(struct vcpu *v)
 
 vmce_init_vcpu(v);
 
+spin_lock_init(&v->arch.vpmu.vpmu_lock);
+
 if ( has_hvm_container_domain(d) )
 {
 rc = hvm_vcpu_initialise(v);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index bc414ff..737f3ea 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4820,6 +4820,7 @@ static hvm_hypercall_t *const 
pvh_hypercall64_table[NR_hypercalls] = {
 HYPERCALL(hvm_op),
 HYPERCALL(sysctl),
 HYPERCALL(domctl),
+HYPERCALL(xenpmu_op),
 [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
 };
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index a7655bd..59cca08 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1166,7 +1166,9 @@ static int svm_vcpu_initialise(struct vcpu *v)
 return rc;
 }
 
-vpmu_initialise(v);
+/* PVH's VPMU is initialized via hypercall */
+if ( is_hvm_vcpu(v) )
+vpmu_initialise(v);
 
 svm_guest_osvw_init(v);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 03474a3..7eeefa2 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -379,17 +379,19 @@ static void amd_vpmu_destroy(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
-amd_vpmu_unset_msr_bitmap(v);
+if ( has_hvm_container_vcpu(v) )
+{
+if ( is_msr_bitmap_on(vpmu) )
+amd_vpmu_unset_msr_bitmap(v);
 
-xfree(vpmu->context);
-vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
+if ( is_hvm_vcpu(v) )
+xfree(vpmu->context);
 
-if ( vpmu_is_set(vpmu, VPMU_RUNNING) )
-{
-vpmu_reset(vpmu, VPMU_RUNNING);
 release_pmu_ownship(PMU_OWNER_HVM);
 }
+
+vpmu->context = NULL;
+vpmu_clear(vpmu);
 }
 
 /* VPMU part of the 'q' keyhandler */
@@ -456,15 +458,19 @@ int svm_vpmu_initialise(struct vcpu *v)
 if ( !counters )
 return -EINVAL;
 
-ctxt = xzalloc_bytes(sizeof(*ctxt) +
- 2 * sizeof(uint64_t) * num_counters);
-if ( !ctxt )
+if ( is_hvm_vcpu(v) )
 {
-printk(XENLOG_G_WARNING "Insufficient memory for PMU, "
-   " PMU feature is unavailable on domain %d vcpu %d.\n",
-   v->vcpu_id, v->domain->domain_id);
-return -ENOMEM;
+ctxt = xzalloc_bytes(sizeof(*ctxt) +
+ 2 * sizeof(uint64_t) * num_counters);
+if ( !ctxt )
+{
+printk(XENLOG_G_WARNING "%pv: Insufficient memory for PMU, "
+   " PMU feature is unavailable\n", v);
+return -ENOMEM;
+}
 }
+else
+ctxt = &v->arch.vpmu.xenpmu_data->pmu.c.amd;
 
 ctxt->counters = sizeof(*ctxt);
 ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
@@ -503,6 +509,16 @@ int __init amd_vpmu_init(void)
 return -EINVAL;
 }
 

[Xen-devel] [PATCH v17 09/23] intel/VPMU: MSR_CORE_PERF_GLOBAL_CTRL should be initialized to zero

[Boris Ostrovsky]

MSR_CORE_PERF_GLOBAL_CTRL register should be set zero initially. It is up to
the guest to set it so that counters are enabled.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 8b84079..7793145 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -165,14 +165,6 @@ static int core2_get_fixed_pmc_count(void)
 return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
 }
 
-static u64 core2_calc_intial_glb_ctrl_msr(void)
-{
-int arch_pmc_bits = (1 << arch_pmc_cnt) - 1;
-u64 fix_pmc_bits  = (1 << fixed_pmc_cnt) - 1;
-
-return (fix_pmc_bits << 32) | arch_pmc_bits;
-}
-
 /* edx bits 5-12: Bit width of fixed-function performance counters  */
 static int core2_get_bitwidth_fix_count(void)
 {
@@ -373,8 +365,7 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
 
 if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
 goto out_err;
-vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
- core2_calc_intial_glb_ctrl_msr());
+vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
 
 core2_vpmu_cxt = xzalloc_bytes(sizeof(struct core2_vpmu_context) +
 (arch_pmc_cnt-1)*sizeof(struct arch_msr_pair));
-- 
1.8.1.4


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

[Xen-devel] [PATCH v17 12/23] x86/VPMU: Replace vcpu with vpmu as argument to some routines

[Boris Ostrovsky]

A subsequent patch will add an inline routine to vpmu.h that will call 
vpmu_load().
This inline will try to access vcpu->vpmu which is not possible since struct
vcpu may not be fully defined at that point. So we will have that inline pass
vpmu pointer to vpmu_load() instead.

This change slightly simplifies some of vpmu code.

For symmetry also modify vpmu_save() (and vpmu_save_force()) to use vpmu
instead of vcpu.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 xen/arch/x86/domain.c |  4 ++--
 xen/arch/x86/hvm/svm/vpmu.c   | 23 +++
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 24 
 xen/arch/x86/hvm/vpmu.c   | 31 +--
 xen/include/asm-x86/hvm/vpmu.h| 26 +-
 5 files changed, 51 insertions(+), 57 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 11c7d9f..4e45fa8 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1544,7 +1544,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 if ( is_hvm_vcpu(prev) )
 {
 if (prev != next)
-vpmu_save(prev);
+vpmu_save(vcpu_vpmu(prev));
 
 if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
 pt_save_timer(prev);
@@ -1589,7 +1589,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 
 if (is_hvm_vcpu(next) && (prev != next) )
 /* Must be done with interrupts enabled */
-vpmu_load(next);
+vpmu_load(vcpu_vpmu(next));
 
 context_saved(prev);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 545962d..72e2561 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -173,10 +173,9 @@ static int amd_vpmu_do_interrupt(struct cpu_user_regs 
*regs)
 return 1;
 }
 
-static inline void context_load(struct vcpu *v)
+static inline void context_load(struct vpmu_struct *vpmu)
 {
 unsigned int i;
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
 struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
 uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
 uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
@@ -188,9 +187,8 @@ static inline void context_load(struct vcpu *v)
 }
 }
 
-static void amd_vpmu_load(struct vcpu *v)
+static void amd_vpmu_load(struct vpmu_struct *vpmu)
 {
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
 struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
 uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
@@ -208,13 +206,12 @@ static void amd_vpmu_load(struct vcpu *v)
 
 vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 
-context_load(v);
+context_load(vpmu);
 }
 
-static inline void context_save(struct vcpu *v)
+static inline void context_save(struct vpmu_struct *vpmu)
 {
 unsigned int i;
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
 struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
 uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
 
@@ -223,9 +220,9 @@ static inline void context_save(struct vcpu *v)
 rdmsrl(counters[i], counter_regs[i]);
 }
 
-static int amd_vpmu_save(struct vcpu *v)
+static int amd_vpmu_save(struct vpmu_struct *vpmu)
 {
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
+struct vcpu *v;
 unsigned int i;
 
 /*
@@ -245,7 +242,9 @@ static int amd_vpmu_save(struct vcpu *v)
 if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
 return 0;
 
-context_save(v);
+context_save(vpmu);
+
+v = vpmu_vcpu(vpmu);
 
 if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
  has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
@@ -325,7 +324,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)
 || vpmu_is_set(vpmu, VPMU_FROZEN) )
 {
-context_load(v);
+context_load(vpmu);
 vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 vpmu_reset(vpmu, VPMU_FROZEN);
 }
@@ -346,7 +345,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t 
*msr_content)
 if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)
 || vpmu_is_set(vpmu, VPMU_FROZEN) )
 {
-context_load(v);
+context_load(vpmu);
 vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 vpmu_reset(vpmu, VPMU_FROZEN);
 }
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index c2405bf..ad7c058 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -287,10 +287,10 @@ static void core2_vpmu_unset_msr_bitmap(unsigned long 
*msr_bitmap)
 set_bit(msraddr_to_bitpos(MSR_IA32_DS_AREA), msr_bitmap);
 }
 
-static inline void __core2_vpmu_save(struct vcpu *v)
+static inline void __core2_vpmu_save(struct vpmu_struct *vpmu)
 {
 int i;
-struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vpmu->context;
 uint64_t *fixed_counters = vpmu_reg_pointer(core2_vpmu_cxt, 
fi

[Xen-devel] [PATCH v17 21/23] x86/VPMU: Add privileged PMU mode

[Boris Ostrovsky]

Add support for privileged PMU mode (XENPMU_MODE_ALL) which allows privileged
domain (dom0) profile both itself (and the hypervisor) and the guests. While
this mode is on profiling in guests is disabled.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/vpmu.c  | 40 ++--
 xen/arch/x86/traps.c | 12 
 xen/include/public/pmu.h |  3 +++
 3 files changed, 45 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 79391b6..ebab0f5 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -99,7 +99,9 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
 struct arch_vpmu_ops *ops;
 int ret = 0;
 
-if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+ ((vpmu_mode & XENPMU_MODE_ALL) &&
+ !is_hardware_domain(current->domain)) )
 goto nop;
 
 curr = current;
@@ -151,8 +153,12 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 struct vcpu *sampled = current, *sampling;
 struct vpmu_struct *vpmu;
 
-/* dom0 will handle interrupt for special domains (e.g. idle domain) */
-if ( sampled->domain->domain_id >= DOMID_FIRST_RESERVED )
+/*
+ * dom0 will handle interrupt for special domains (e.g. idle domain) or,
+ * in XENPMU_MODE_ALL, for everyone.
+ */
+if ( (vpmu_mode & XENPMU_MODE_ALL) ||
+ (sampled->domain->domain_id >= DOMID_FIRST_RESERVED) )
 {
 sampling = choose_hwdom_vcpu();
 if ( !sampling )
@@ -162,12 +168,12 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 sampling = sampled;
 
 vpmu = vcpu_vpmu(sampling);
-if ( !is_hvm_vcpu(sampling) )
+if ( !is_hvm_vcpu(sampling) || (vpmu_mode & XENPMU_MODE_ALL) )
 {
 /* PV(H) guest */
 const struct cpu_user_regs *cur_regs;
 uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
-uint32_t domid = DOMID_SELF;
+uint32_t domid;
 
 if ( !vpmu->xenpmu_data )
 return;
@@ -176,6 +182,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 return;
 
 if ( is_pvh_vcpu(sampling) &&
+ !(vpmu_mode & XENPMU_MODE_ALL) &&
  !vpmu->arch_vpmu_ops->do_interrupt(regs) )
 return;
 
@@ -189,6 +196,11 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 else
 *flags = PMU_SAMPLE_PV;
 
+if ( sampled == sampling )
+domid = DOMID_SELF;
+else
+domid = sampled->domain->domain_id;
+
 /* Store appropriate registers in xenpmu_data */
 /* FIXME: 32-bit PVH should go here as well */
 if ( is_pv_32bit_vcpu(sampling) )
@@ -217,7 +229,8 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 
 if ( (vpmu_mode & XENPMU_MODE_SELF) )
 cur_regs = guest_cpu_user_regs();
-else if ( !guest_mode(regs) && 
is_hardware_domain(sampling->domain) )
+else if ( !guest_mode(regs) &&
+  is_hardware_domain(sampling->domain) )
 {
 cur_regs = regs;
 domid = DOMID_XEN;
@@ -471,7 +484,8 @@ static int pvpmu_init(struct domain *d, xen_pmu_params_t 
*params)
 struct page_info *page;
 uint64_t gfn = params->val;
 
-if ( vpmu_mode == XENPMU_MODE_OFF )
+if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+ ((vpmu_mode & XENPMU_MODE_ALL) && !is_hardware_domain(d)) )
 return -EINVAL;
 
 if ( (params->vcpu >= d->max_vcpus) || (d->vcpu == NULL) ||
@@ -551,6 +565,10 @@ void vpmu_dump(struct vcpu *v)
 
 void vpmu_unload(struct vpmu_struct *vpmu)
 {
+if ( (vpmu_mode & XENPMU_MODE_ALL) &&
+ is_hardware_domain(vpmu_vcpu(vpmu)->domain) )
+return;
+
 if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_RUNNING) )
 return;
 
@@ -663,11 +681,13 @@ long do_xenpmu_op(int op, 
XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 if ( copy_from_guest(&pmu_params, arg, 1) )
 return -EFAULT;
 
-if ( pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+if ( pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV |
+XENPMU_MODE_ALL) )
 return -EINVAL;
 
 /* 32-bit dom0 can only sample itself. */
-if ( is_pv_32bit_vcpu(current) && (pmu_params.val & XENPMU_MODE_HV) )
+if ( is_pv_32bit_vcpu(current) &&
+ (pmu_params.val & (XENPMU_MODE_HV | XENPMU_MODE_ALL)) )
 return -EINVAL;
 
 /*
@@ -686,7 +706,7 @@ long do_xenpmu_op(int op, 
XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 old_mode = vpmu_mode;
 vpmu_mode = pmu_params.val;
 
-if ( vpmu_mode == XENPMU_MODE_OFF )
+if ( (vpmu_mode == XENPMU_MODE_OFF) || (vpmu_mode == XENPMU_MODE_ALL) 

[Xen-devel] [PATCH v17 06/23] intel/VPMU: Clean up Intel VPMU code

[Boris Ostrovsky]

Remove struct pmumsr and core2_pmu_enable. Replace static MSR structures with
fields in core2_vpmu_context.

Call core2_get_pmc_count() once, during initialization.

Properly clean up when core2_vpmu_alloc_resource() fails.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/vmx/vpmu_core2.c| 380 ++-
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |  19 --
 2 files changed, 171 insertions(+), 228 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 951aece..9c4d00e 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -69,6 +69,27 @@
 static bool_t __read_mostly full_width_write;
 
 /*
+ * MSR_CORE_PERF_FIXED_CTR_CTRL contains the configuration of all fixed
+ * counters. 4 bits for every counter.
+ */
+#define FIXED_CTR_CTRL_BITS 4
+#define FIXED_CTR_CTRL_MASK ((1 << FIXED_CTR_CTRL_BITS) - 1)
+
+#define VPMU_CORE2_MAX_FIXED_PMCS 4
+struct core2_vpmu_context {
+u64 fixed_ctrl;
+u64 ds_area;
+u64 pebs_enable;
+u64 global_ovf_status;
+u64 enabled_cntrs;  /* Follows PERF_GLOBAL_CTRL MSR format */
+u64 fix_counters[VPMU_CORE2_MAX_FIXED_PMCS];
+struct arch_msr_pair arch_msr_pair[1];
+};
+
+/* Number of general-purpose and fixed performance counters */
+static unsigned int __read_mostly arch_pmc_cnt, fixed_pmc_cnt;
+
+/*
  * QUIRK to workaround an issue on various family 6 cpus.
  * The issue leads to endless PMC interrupt loops on the processor.
  * If the interrupt handler is running and a pmc reaches the value 0, this
@@ -88,11 +109,8 @@ static void check_pmc_quirk(void)
 is_pmc_quirk = 0;
 }
 
-static int core2_get_pmc_count(void);
 static void handle_pmc_quirk(u64 msr_content)
 {
-int num_gen_pmc = core2_get_pmc_count();
-int num_fix_pmc  = 3;
 int i;
 u64 val;
 
@@ -100,7 +118,7 @@ static void handle_pmc_quirk(u64 msr_content)
 return;
 
 val = msr_content;
-for ( i = 0; i < num_gen_pmc; i++ )
+for ( i = 0; i < arch_pmc_cnt; i++ )
 {
 if ( val & 0x1 )
 {
@@ -112,7 +130,7 @@ static void handle_pmc_quirk(u64 msr_content)
 val >>= 1;
 }
 val = msr_content >> 32;
-for ( i = 0; i < num_fix_pmc; i++ )
+for ( i = 0; i < fixed_pmc_cnt; i++ )
 {
 if ( val & 0x1 )
 {
@@ -125,128 +143,91 @@ static void handle_pmc_quirk(u64 msr_content)
 }
 }
 
-static const u32 core2_fix_counters_msr[] = {
-MSR_CORE_PERF_FIXED_CTR0,
-MSR_CORE_PERF_FIXED_CTR1,
-MSR_CORE_PERF_FIXED_CTR2
-};
-
 /*
- * MSR_CORE_PERF_FIXED_CTR_CTRL contains the configuration of all fixed
- * counters. 4 bits for every counter.
+ * Read the number of general counters via CPUID.EAX[0xa].EAX[8..15]
  */
-#define FIXED_CTR_CTRL_BITS 4
-#define FIXED_CTR_CTRL_MASK ((1 << FIXED_CTR_CTRL_BITS) - 1)
-
-/* The index into the core2_ctrls_msr[] of this MSR used in core2_vpmu_dump() 
*/
-#define MSR_CORE_PERF_FIXED_CTR_CTRL_IDX 0
-
-/* Core 2 Non-architectual Performance Control MSRs. */
-static const u32 core2_ctrls_msr[] = {
-MSR_CORE_PERF_FIXED_CTR_CTRL,
-MSR_IA32_PEBS_ENABLE,
-MSR_IA32_DS_AREA
-};
-
-struct pmumsr {
-unsigned int num;
-const u32 *msr;
-};
-
-static const struct pmumsr core2_fix_counters = {
-VPMU_CORE2_NUM_FIXED,
-core2_fix_counters_msr
-};
+static int core2_get_arch_pmc_count(void)
+{
+u32 eax;
 
-static const struct pmumsr core2_ctrls = {
-VPMU_CORE2_NUM_CTRLS,
-core2_ctrls_msr
-};
-static int arch_pmc_cnt;
+eax = cpuid_eax(0xa);
+return MASK_EXTR(eax, PMU_GENERAL_NR_MASK);
+}
 
 /*
- * Read the number of general counters via CPUID.EAX[0xa].EAX[8..15]
+ * Read the number of fixed counters via CPUID.EDX[0xa].EDX[0..4]
  */
-static int core2_get_pmc_count(void)
+static int core2_get_fixed_pmc_count(void)
 {
-u32 eax, ebx, ecx, edx;
+u32 eax;
 
-if ( arch_pmc_cnt == 0 )
-{
-cpuid(0xa, &eax, &ebx, &ecx, &edx);
-arch_pmc_cnt = (eax & PMU_GENERAL_NR_MASK) >> PMU_GENERAL_NR_SHIFT;
-}
-
-return arch_pmc_cnt;
+eax = cpuid_eax(0xa);
+return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
 }
 
 static u64 core2_calc_intial_glb_ctrl_msr(void)
 {
-int arch_pmc_bits = (1 << core2_get_pmc_count()) - 1;
-u64 fix_pmc_bits  = (1 << 3) - 1;
-return ((fix_pmc_bits << 32) | arch_pmc_bits);
+int arch_pmc_bits = (1 << arch_pmc_cnt) - 1;
+u64 fix_pmc_bits  = (1 << fixed_pmc_cnt) - 1;
+
+return (fix_pmc_bits << 32) | arch_pmc_bits;
 }
 
 /* edx bits 5-12: Bit width of fixed-function performance counters  */
 static int core2_get_bitwidth_fix_count(void)
 {
-u32 eax, ebx, ecx, edx;
+u32 edx;
 
-cpuid(0xa, &eax, &ebx, &ecx, &edx);
-return ((edx & PMU_FIXED_WIDTH_MASK) >> PMU_FIXED_WIDTH_SHIFT);
+edx = cpuid_edx(0xa);
+return MASK_EXTR(edx, PMU_FIXED_WIDTH_MASK);
 }
 
 static int is_core2_vpmu_msr

[Xen-devel] [PATCH v17 17/23] x86/VPMU: When handling MSR accesses, leave fault injection to callers

[Boris Ostrovsky]

With this patch return value of 1 of vpmu_do_msr() will now indicate whether an
error was encountered during MSR processing (instead of stating that the access
was to a VPMU register).

As part of this patch we also check for validity of certain MSR accesses right
when we determine which register is being written, as opposed to postponing this
until later.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/svm/svm.c|  6 ++-
 xen/arch/x86/hvm/svm/vpmu.c   |  6 +--
 xen/arch/x86/hvm/vmx/vmx.c| 24 +---
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 82 ++-
 4 files changed, 55 insertions(+), 63 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 59cca08..a8cb9ae 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1709,7 +1709,8 @@ static int svm_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 case MSR_AMD_FAM15H_EVNTSEL3:
 case MSR_AMD_FAM15H_EVNTSEL4:
 case MSR_AMD_FAM15H_EVNTSEL5:
-vpmu_do_rdmsr(msr, msr_content);
+if ( vpmu_do_rdmsr(msr, msr_content) )
+goto gpf;
 break;
 
 case MSR_AMD64_DR0_ADDRESS_MASK:
@@ -1860,7 +1861,8 @@ static int svm_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 case MSR_AMD_FAM15H_EVNTSEL3:
 case MSR_AMD_FAM15H_EVNTSEL4:
 case MSR_AMD_FAM15H_EVNTSEL5:
-vpmu_do_wrmsr(msr, msr_content, 0);
+if ( vpmu_do_wrmsr(msr, msr_content, 0) )
+goto gpf;
 break;
 
 case MSR_IA32_MCx_MISC(4): /* Threshold register */
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 7eeefa2..27c8a9c 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -324,7 +324,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 is_pmu_enabled(msr_content) && !vpmu_is_set(vpmu, VPMU_RUNNING) )
 {
 if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
-return 1;
+return 0;
 vpmu_set(vpmu, VPMU_RUNNING);
 
 if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
@@ -354,7 +354,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 
 /* Write to hw counters */
 wrmsrl(msr, msr_content);
-return 1;
+return 0;
 }
 
 static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
@@ -372,7 +372,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t 
*msr_content)
 
 rdmsrl(msr, *msr_content);
 
-return 1;
+return 0;
 }
 
 static void amd_vpmu_destroy(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2b6981e..012bca4 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2112,12 +2112,17 @@ static int vmx_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 *msr_content |= MSR_IA32_MISC_ENABLE_BTS_UNAVAIL |
MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL;
 /* Perhaps vpmu will change some bits. */
+/* FALLTHROUGH */
+case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
+case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+case MSR_IA32_PEBS_ENABLE:
+case MSR_IA32_DS_AREA:
 if ( vpmu_do_rdmsr(msr, msr_content) )
-goto done;
+goto gp_fault;
 break;
 default:
-if ( vpmu_do_rdmsr(msr, msr_content) )
-break;
 if ( passive_domain_do_rdmsr(msr, msr_content) )
 goto done;
 switch ( long_mode_do_msr_read(msr, msr_content) )
@@ -2293,7 +2298,7 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 if ( msr_content & ~supported )
 {
 /* Perhaps some other bits are supported in vpmu. */
-if ( !vpmu_do_wrmsr(msr, msr_content, supported) )
+if ( vpmu_do_wrmsr(msr, msr_content, supported) )
 break;
 }
 if ( msr_content & IA32_DEBUGCTLMSR_LBR )
@@ -2321,9 +2326,16 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 if ( !nvmx_msr_write_intercept(msr, msr_content) )
 goto gp_fault;
 break;
+case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(7):
+case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+case MSR_IA32_PEBS_ENABLE:
+case MSR_IA32_DS_AREA:
+ if ( vpmu_do_wrmsr(msr, msr_content, 0) )
+goto gp_fault;
+break;
 default:
-if ( vpmu_do_wrmsr(msr, msr_content, 0) )
-return X86EMUL_OKAY;
 if ( passive_domain_do_wrmsr(msr, msr_content) )
 return X86EMUL_O

[Xen-devel] [PATCH v17 03/23] x86/VPMU: Manage VPMU_CONTEXT_SAVE flag in vpmu_save_force()

[Boris Ostrovsky]

There is a possibility that we set VPMU_CONTEXT_SAVE on VPMU context in
vpmu_load() and never clear it (because vpmu_save_force() will see
VPMU_CONTEXT_LOADED bit clear, which is possible on AMD processors)

The problem is that amd_vpmu_save() assumes that if VPMU_CONTEXT_SAVE is set
then (1) we need to save counters and (2) we don't need to "stop" control
registers since they must have been stopped earlier. The latter may cause all
sorts of problem (like counters still running in a wrong guest and hypervisor
sending to that guest unexpected PMU interrupts).

Since setting this flag is currently always done prior to calling
vpmu_save_force() let's both set and clear it there.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/vpmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index efb2279..e17e194 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -128,6 +128,8 @@ static void vpmu_save_force(void *arg)
 if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
 return;
 
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+
 if ( vpmu->arch_vpmu_ops )
 (void)vpmu->arch_vpmu_ops->arch_vpmu_save(v);
 
@@ -176,7 +178,6 @@ void vpmu_load(struct vcpu *v)
  */
 if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
 {
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
 on_selected_cpus(cpumask_of(vpmu->last_pcpu),
  vpmu_save_force, (void *)v, 1);
 vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
@@ -193,7 +194,6 @@ void vpmu_load(struct vcpu *v)
 vpmu = vcpu_vpmu(prev);
 
 /* Someone ran here before us */
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
 vpmu_save_force(prev);
 vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
 
-- 
1.8.1.4


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

[Xen-devel] [PATCH v17 02/23] x86/VPMU: Don't globally disable VPMU if initialization fails.

[Boris Ostrovsky]

The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
forever.

Signed-off-by: Boris Ostrovsky 
Reported-by: Jan Beulich 
---
 xen/arch/x86/hvm/vpmu.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 37f0d9f..efb2279 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -218,6 +218,7 @@ void vpmu_initialise(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 uint8_t vendor = current_cpu_data.x86_vendor;
+int ret;
 
 if ( is_pvh_vcpu(v) )
 return;
@@ -230,21 +231,25 @@ void vpmu_initialise(struct vcpu *v)
 switch ( vendor )
 {
 case X86_VENDOR_AMD:
-if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-opt_vpmu_enabled = 0;
+ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
 break;
 
 case X86_VENDOR_INTEL:
-if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-opt_vpmu_enabled = 0;
+ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
 break;
 
 default:
-printk("VPMU: Initialization failed. "
-   "Unknown CPU vendor %d\n", vendor);
-opt_vpmu_enabled = 0;
-break;
+if ( opt_vpmu_enabled )
+{
+printk(XENLOG_G_WARNING "VPMU: Unknown CPU vendor %d. "
+   "Disabling VPMU\n", vendor);
+opt_vpmu_enabled = 0;
+}
+return;
 }
+
+if ( ret )
+printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
 }
 
 static void vpmu_clear_last(void *arg)
-- 
1.8.1.4


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

[Xen-devel] [PATCH v17 08/23] x86/VPMU: Handle APIC_LVTPC accesses

[Boris Ostrovsky]

Don't have the hypervisor update APIC_LVTPC when _it_ thinks the vector should
be updated. Instead, handle guest's APIC_LVTPC accesses and write what the guest
explicitly wanted.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Acked-by: Jan Beulich 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/svm/vpmu.c   |  4 
 xen/arch/x86/hvm/vlapic.c |  3 +++
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 17 -
 xen/arch/x86/hvm/vpmu.c   |  8 
 xen/include/asm-x86/hvm/vpmu.h|  1 +
 5 files changed, 12 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 19777e3..64dc167 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -302,8 +302,6 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
 return 1;
 vpmu_set(vpmu, VPMU_RUNNING);
-apic_write(APIC_LVTPC, PMU_APIC_VECTOR);
-vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR;
 
 if ( has_hvm_container_vcpu(v) &&
  !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
@@ -314,8 +312,6 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
 (is_pmu_enabled(msr_content) == 0) && vpmu_is_set(vpmu, VPMU_RUNNING) )
 {
-apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
-vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
 vpmu_reset(vpmu, VPMU_RUNNING);
 if ( has_hvm_container_vcpu(v) &&
  ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 72b6509..56b9d23 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -789,6 +790,8 @@ static int vlapic_reg_write(struct vcpu *v,
 }
 if ( (offset == APIC_LVTT) && !(val & APIC_LVT_MASKED) )
 pt_may_unmask_irq(NULL, &vlapic->pt);
+if ( offset == APIC_LVTPC )
+vpmu_lvtpc_update(val);
 break;
 
 case APIC_TMICT:
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 9c4d00e..8b84079 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -528,19 +528,6 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 else
 vpmu_reset(vpmu, VPMU_RUNNING);
 
-/* Setup LVTPC in local apic */
-if ( vpmu_is_set(vpmu, VPMU_RUNNING) &&
- is_vlapic_lvtpc_enabled(vcpu_vlapic(v)) )
-{
-apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR);
-vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR;
-}
-else
-{
-apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
-vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
-}
-
 if ( type != MSR_TYPE_GLOBAL )
 {
 u64 mask;
@@ -706,10 +693,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs 
*regs)
 return 0;
 }
 
-/* HW sets the MASK bit when performance counter interrupt occurs*/
-vpmu->hw_lapic_lvtpc = apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED;
-apic_write_around(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
-
 return 1;
 }
 
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 63b2158..d94b63c 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -64,6 +64,14 @@ static void __init parse_vpmu_param(char *s)
 }
 }
 
+void vpmu_lvtpc_update(uint32_t val)
+{
+struct vpmu_struct *vpmu = vcpu_vpmu(current);
+
+vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
+apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
+}
+
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(current);
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index ddc2748..9c4e65a 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -104,6 +104,7 @@ static inline bool_t vpmu_are_all_set(const struct 
vpmu_struct *vpmu,
 return !!((vpmu->flags & mask) == mask);
 }
 
+void vpmu_lvtpc_update(uint32_t val);
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
 void vpmu_do_interrupt(struct cpu_user_regs *regs);
-- 
1.8.1.4


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

[Xen-devel] [PATCH v17 20/23] x86/VPMU: Merge vpmu_rdmsr and vpmu_wrmsr

[Boris Ostrovsky]

The two routines share most of their logic.

Signed-off-by: Boris Ostrovsky 
---
 xen/arch/x86/hvm/vpmu.c| 77 --
 xen/include/asm-x86/hvm/vpmu.h | 14 ++--
 2 files changed, 42 insertions(+), 49 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index c57b250..79391b6 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -91,65 +91,48 @@ void vpmu_lvtpc_update(uint32_t val)
 apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
 
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+uint64_t supported, bool_t is_write)
 {
-struct vcpu *curr = current;
+struct vcpu *curr;
 struct vpmu_struct *vpmu;
+struct arch_vpmu_ops *ops;
+int ret = 0;
 
 if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
-return 0;
+goto nop;
 
+curr = current;
 vpmu = vcpu_vpmu(curr);
-if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
-{
-int ret = vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
-
-/*
- * We may have received a PMU interrupt during WRMSR handling
- * and since do_wrmsr may load VPMU context we should save
- * (and unload) it again.
- */
-if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
- (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
-{
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu);
-vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-}
-return ret;
-}
-
-return 0;
-}
-
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
-{
-struct vcpu *curr = current;
-struct vpmu_struct *vpmu;
+ops = vpmu->arch_vpmu_ops;
+if ( !ops )
+goto nop;
+
+if ( is_write && ops->do_wrmsr )
+ret = ops->do_wrmsr(msr, *msr_content, supported);
+else if ( !is_write && ops->do_rdmsr )
+ret = ops->do_rdmsr(msr, msr_content);
+else
+goto nop;
 
-if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+/*
+ * We may have received a PMU interrupt while handling MSR access
+ * and since do_wr/rdmsr may load VPMU context we should save
+ * (and unload) it again.
+ */
+if ( !is_hvm_vcpu(curr) &&
+ vpmu->xenpmu_data && (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
 {
-*msr_content = 0;
-return 0;
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+ops->arch_vpmu_save(vpmu);
+vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
 }
 
-vpmu = vcpu_vpmu(curr);
-if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
-{
-int ret = vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
+return ret;
 
-if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
- (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED) )
-{
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu);
-vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-}
-return ret;
-}
-else
+ nop:
+if ( !is_write )
 *msr_content = 0;
-
 return 0;
 }
 
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 42a09f9..2c888cc 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -100,8 +100,8 @@ static inline bool_t vpmu_are_all_set(const struct 
vpmu_struct *vpmu,
 }
 
 void vpmu_lvtpc_update(uint32_t val);
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+uint64_t supported, bool_t is_write);
 void vpmu_do_interrupt(struct cpu_user_regs *regs);
 void vpmu_do_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx);
@@ -112,6 +112,16 @@ void vpmu_load(struct vpmu_struct *vpmu);
 void vpmu_unload(struct vpmu_struct *vpmu);
 void vpmu_dump(struct vcpu *v);
 
+static inline int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
+uint64_t supported)
+{
+return vpmu_do_msr(msr, &msr_content, supported, 1);
+}
+static inline int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
+{
+return vpmu_do_msr(msr, msr_content, 0, 0);
+}
+
 extern int acquire_pmu_ownership(int pmu_ownership);
 extern void release_pmu_ownership(int pmu_ownership);
 
-- 
1.8.1.4


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

[Xen-devel] [PATCH v17 16/23] x86/VPMU: Save VPMU state for PV guests during context switch

[Boris Ostrovsky]

Save VPMU state during context switch for both HVM and PV(H) guests.

A subsequent patch ("x86/VPMU: NMI-based VPMU support") will make it possible
for vpmu_switch_to() to call vmx_vmcs_try_enter()->vcpu_pause() which needs
is_running to be correctly set/cleared. To prepare for that, call 
context_saved()
before vpmu_switch_to() is executed. (Note that while this change could have
been dalayed until that later patch, the changes are harmless to existing code
and so we do it here)

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/domain.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a29db67..7d5d46b 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1541,17 +1541,14 @@ void context_switch(struct vcpu *prev, struct vcpu 
*next)
 }
 
 if ( prev != next )
-_update_runstate_area(prev);
-
-if ( is_hvm_vcpu(prev) )
 {
-if (prev != next)
-vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(next));
-
-if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
-pt_save_timer(prev);
+_update_runstate_area(prev);
+vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(next));
 }
 
+if ( is_hvm_vcpu(prev) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
+pt_save_timer(prev);
+
 local_irq_disable();
 
 set_current(next);
@@ -1589,15 +1586,16 @@ void context_switch(struct vcpu *prev, struct vcpu 
*next)
!is_hardware_domain(next->domain));
 }
 
-if ( is_hvm_vcpu(next) && (prev != next) )
-/* Must be done with interrupts enabled */
-vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
-
 context_saved(prev);
 
 if ( prev != next )
+{
 _update_runstate_area(next);
 
+/* Must be done with interrupts enabled */
+vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
+}
+
 /* Ensure that the vcpu has an up-to-date time base. */
 update_vcpu_system_time(next);
 
-- 
1.8.1.4


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

Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes for 4.5

[Konrad Rzeszutek Wilk]

On Wed, Dec 31, 2014 at 10:31:06AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 22, 2014 at 09:06:40AM +0100, Olaf Hering wrote:
> > On Fri, Dec 19, Konrad Rzeszutek Wilk wrote:
> > 
> > > On Fri, Dec 19, 2014 at 12:25:26PM +0100, Olaf Hering wrote:
> > > > This is a resend of these two series:
> > > > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html
> > > > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> > > > 
> > > > New in v3 is a wrapper to run xenstored. See its patch description
> > > > for details.
> > > > 
> > > > Patch 2-6 should be applied for 4.5.0.

IanJ, Wei, IanC, please read below.

Patch #2-#6:

Release-Acked-by: Konrad Rzeszutek Wilk 
Tested-by: Konrad Rzeszutek Wilk 

#2,#3 has an Ack

#4 ("tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service")
#5 ("tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service")
#6 ("tools/hotplug: remove EnvironmentFile from 
xen-qemu-dom0-disk-backend.service")

need Acks. 

> > > > 
> > > > The first and the last one still has issues with xenstored and
> > > > SELinux. See below.  Up to now no solution is known to me.
> > > > 
> > > > 
> > > > The first patch fixes Arch Linux and does not break anything.  As such
> > > > it should be safe to be applied for 4.5.0.  SELinux users (who build
> > > > from source) should put their special mount options into fstab. Distro

For patch #1 ("tools/hotplug: remove SELinux options from 
var-lib-xenstored.mount")

Release-Acked-by: Konrad Rzeszutek Wilk 
Tested-by: Konrad Rzeszutek Wilk 

with the below change to README file. It also needs an Ack.

For patch #7 (" tools/hotplug: add wrapper to start xenstored")

Tested-by: Konrad Rzeszutek Wilk 
However there is a question in there for Ian:

"The place of the wrapper is currently LIBEXEC_BIN, it has to be
decided what the final location is supposed to be. IanJ wants it in
"/etc".
"

IanJ - any specific reasons for having it in /etc instead of
LIBEXEC_BIN? This is in regards to the introduction of this file:

diff --git a/tools/hotplug/Linux/xenstored.sh.in 
b/tools/hotplug/Linux/xenstored.sh.in
new file mode 100644
index 000..dc806ee
--- /dev/null
+++ b/tools/hotplug/Linux/xenstored.sh.in
@@ -0,0 +1,6 @@
+#!/bin/sh
+if test -n "$XENSTORED_TRACE"
+then
+   XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
+fi
+exec $XENSTORED $@ $XENSTORED_ARGS


> > > 
> > > Could you elaborate what that is? As in what is that 'special mount 
> > > options'?
> > 
> > The context= mount option, about which we argue since a few weeks?
> 
> You said 'special mount options into fstab' ? Is that the same as 'context='??
> (checks the manpage) AHA, it is!
> 
> 
> In which case would it just to say that this needs to be added as
> a workaround:
> 
> xenstored /var/lib/xenstored xenstored 
> context="system_u:object_r:xenstored_var_lib_t:s0" 1 1

To be exact:

tmpfs   /var/lib/xenstored  tmpfs   
mode=755,context="system_u:object_r:xenstored_var_lib_t:s0" 0 0

> 
> > See patch #1.
> > 
> > > > packages will most likely include a proper .service file.
> > > > 
> > > > 
> > > > The last patch addresses the XENSTORED_TRACE issue. But SELinux will
> > > > most likely still not work.
> > > > 
> > > > Possible ways to handle launching xenstored and SELinux:
> > > > 
> > > > - do nothing
> > > >   pro: - no Xen source changes required
> > > >   con: - possible unhappy users who build from source and still have
> > > >  SELinux enabled
> > > 
> > > At this stage I prefer this and just have in the release notes the
> > > work-around documented.
> > 
> > Which workaround is that? No SELinux on Fedora?
> 
> That is not an option.
> 
> The workaround is to document what the 'context' is .. or whatever
> else is needed to make this work.

Such as this might be good (Or perhaps move it to the INSTALL file)

diff --git a/README b/README
index 412607a..7d74214 100644
--- a/README
+++ b/README
@@ -33,6 +33,26 @@ This file contains some quick-start instructions to install 
Xen on
 your system. For more information see http:/www.xen.org/ and
 http://wiki.xen.org/
 
+Release Issues
+==
+
+While we did the utmost to get a release out, there are certain
+fixes which were not complete on time. As such please reference this
+section if you are running into trouble.
+
+* systemd not working with Fedora Core 20, 21 or later (systemctl
+  reports xenstore failing to start).
+
+  Systemd support is now part of Xen source code. While utmost work has
+  been done to make the systemd files compatible across all the
+  distributions, there might issues when using systemd files from
+  Xen sources. The work-around is to define an mount entry in
+  /etc/fstab as follow:
+
+  tmpfs   /var/lib/xenstored  tmpfs
+  mode=755,context="system_u:object_r:x

Re: [Xen-devel] [PATCH v16 13/23] x86/VPMU: Interface for setting PMU mode and flags

[Daniel De Graaf]

On 12/17/2014 10:38 AM, Boris Ostrovsky wrote:

Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF:  PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
   can profile itself and the hypervisor.

Note that PMU modes are different from what can be provided at Xen's boot line
with 'vpmu' argument. An 'off' (or '0') value is equivalent to XENPMU_MODE_OFF.
Any other value, on the other hand, will cause VPMU mode to be set to
XENPMU_MODE_SELF during boot.

For feature flags only Intel's BTS is currently supported.

Mode and flags are set via HYPERVISOR_xenpmu_op hypercall.

Signed-off-by: Boris Ostrovsky 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v16 15/23] x86/VPMU: Initialize PMU for PV(H) guests

[Daniel De Graaf]

On 12/17/2014 10:38 AM, Boris Ostrovsky wrote:

Code for initializing/tearing down PMU for PV guests

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Acked-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 


Acked-by: Daniel De Graaf 

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

[Xen-devel] Xen 4.5 Development Update (GA slip by a week)

[konrad . wilk]

Xen 4.5-rc4 was out on Monday (Dec 15th). The GA
General Release is on Jan 7th^H^H^14th!

There are some outstanding patches on which we need to figure
out whether we will commit them in or not.

When we commit a patch in, the OSSTest takes a day or so to push it to 'master'
- and if it fails during that time patches that are later in the sequence are
not applied. Hence if everything works out great - we get the patches
to show up next day - however if something breaks - we are stalled.

Ian(s) has pointed to me that the OSSTest is sometimes on the fritz and that it
might take more than one day to push patches through which means we won't
make it by Wednesday.

As such, moving it the release by a week to give us ample room to get through
those changes.

These are the patches that need to be investigated whether they should
go in or not:

 VT-d: don't crash when PTE bits 52 and up are non-zero
 VT-d: extend XSA-59 workaround to XeonE5 v3 (Haswell)
 VT-d: make XSA-59 workaround fully cover XeonE5/E7 v2
 x86/VPMU: Clear last_vcpu when destroying VPMU
 tools/hotplug: add wrapper to start xenstored
 tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service
 tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service
 tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service
 tools/hotplug: xendomains.service depends on network
 tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service
 tools/hotplug: remove SELinux options from var-lib-xenstored.mount
 tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ss
 xen: arm: correct off-by-one error in consider_module

 
= Timeline =

Xen 4.5 is a 10 month release. The dates are:

* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
* RC2: Nov 11th
* RC2 Test-day: Nov 13th
* RC3: Dec 3rd.
* RC3 Test-day: Dec 4th
* RC4: Dec 15th
* RC4 Test-day: Dec 17th

< WE ARE HERE ===>

 Release Date: Jan 14th.


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

[Xen-devel] [linux-linus test] 33115: regressions - FAIL

[xen . org]

flight 33115 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33115/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail like 32879
 test-amd64-i386-freebsd10-amd64  7 freebsd-install fail like 32879
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32879
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail like 32879

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass

version targeted for testing:
 linux693a30b8f19a964087a3762d09fb2e1cbad6b0d4
baseline version:
 linux9bb29b6b927bcd79cf185ee67bcebfe630f0dea1


People who touched revisions under test:
  Alan Stern 
  Andrew Jackson 
  Anil Chintalapati (achintal) 
  Anil Chintalapati 
  Christoph Hellwig 
  Daniel Borkmann 
  Daniel Walter 
  Fang, Yang A 
  Hannes Reinecke 
  Herbert Xu 
  Hiral Shah 
  James Bottomley 
  Jarkko Nikula 
  Jianqun Xu 
  Jie Yang 
  Lars-Peter Clausen 
  Ley Foon Tan 
  Linus Torvalds 
  Mark Brown 
  Martin K. Petersen 
  Michael S. Tsirkin 
  Ming Lei 
  Paolo Bonzini 
  Paul Moore 
  Pavel Machek 
  Rabin Vincent 
  Randy Dunlap 
  Richard Weinberger 
  Russell King 
  Rusty Russell 
  Sesidhar Baddela 
  Takashi Iwai 
  Tobias Klauser 
  Walter Goossens 
  Андрей Аладьев 


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

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

[Andy Lutomirski]

On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti  wrote:
> On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
>> The pvclock vdso code was too abstracted to understand easily and
>> excessively paranoid.  Simplify it for a huge speedup.
>>
>> This opens the door for additional simplifications, as the vdso no
>> longer accesses the pvti for any vcpu other than vcpu 0.
>>
>> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
>> With this change, it takes 19ns, which is almost as fast as the pure TSC
>> implementation.
>>
>> Signed-off-by: Andy Lutomirski 
>> ---
>>  arch/x86/vdso/vclock_gettime.c | 82 
>> --
>>  1 file changed, 47 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
>> index 9793322751e0..f2e0396d5629 100644
>> --- a/arch/x86/vdso/vclock_gettime.c
>> +++ b/arch/x86/vdso/vclock_gettime.c
>> @@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info 
>> *get_pvti(int cpu)
>>
>>  static notrace cycle_t vread_pvclock(int *mode)
>>  {
>> - const struct pvclock_vsyscall_time_info *pvti;
>> + const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>>   cycle_t ret;
>> - u64 last;
>> - u32 version;
>> - u8 flags;
>> - unsigned cpu, cpu1;
>> -
>> + u64 tsc, pvti_tsc;
>> + u64 last, delta, pvti_system_time;
>> + u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>>
>>   /*
>> -  * Note: hypervisor must guarantee that:
>> -  * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
>> -  * 2. that per-CPU pvclock time info is updated if the
>> -  *underlying CPU changes.
>> -  * 3. that version is increased whenever underlying CPU
>> -  *changes.
>> +  * Note: The kernel and hypervisor must guarantee that cpu ID
>> +  * number maps 1:1 to per-CPU pvclock time info.
>> +  *
>> +  * Because the hypervisor is entirely unaware of guest userspace
>> +  * preemption, it cannot guarantee that per-CPU pvclock time
>> +  * info is updated if the underlying CPU changes or that that
>> +  * version is increased whenever underlying CPU changes.
>> +  *
>> +  * On KVM, we are guaranteed that pvti updates for any vCPU are
>> +  * atomic as seen by *all* vCPUs.  This is an even stronger
>> +  * guarantee than we get with a normal seqlock.
>>*
>> +  * On Xen, we don't appear to have that guarantee, but Xen still
>> +  * supplies a valid seqlock using the version field.
>> +
>> +  * We only do pvclock vdso timing at all if
>> +  * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
>> +  * mean that all vCPUs have matching pvti and that the TSC is
>> +  * synced, so we can just look at vCPU 0's pvti.
>>*/
>
> Can Xen guarantee that ?

I think so, vacuously.  Xen doesn't seem to set PVCLOCK_TSC_STABLE_BIT
at all.  I have no idea going forward, though.

Xen people?

>
>> - do {
>> - cpu = __getcpu() & VGETCPU_CPU_MASK;
>> - /* TODO: We can put vcpu id into higher bits of pvti.version.
>> -  * This will save a couple of cycles by getting rid of
>> -  * __getcpu() calls (Gleb).
>> -  */
>> -
>> - pvti = get_pvti(cpu);
>> -
>> - version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
>> -
>> - /*
>> -  * Test we're still on the cpu as well as the version.
>> -  * We could have been migrated just after the first
>> -  * vgetcpu but before fetching the version, so we
>> -  * wouldn't notice a version change.
>> -  */
>> - cpu1 = __getcpu() & VGETCPU_CPU_MASK;
>> - } while (unlikely(cpu != cpu1 ||
>> -   (pvti->pvti.version & 1) ||
>> -   pvti->pvti.version != version));
>> -
>> - if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
>> +
>> + if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>>   *mode = VCLOCK_NONE;
>> + return 0;
>> + }
>
> This check must be performed after reading a stable pvti.
>

We can even read it in the middle, guarded by the version checks.
I'll do that for v2.

>> +
>> + do {
>> + version = pvti->version;
>> +
>> + /* This is also a read barrier, so we'll read version first. */
>> + rdtsc_barrier();
>> + tsc = __native_read_tsc();
>> +
>> + pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
>> + pvti_tsc_shift = pvti->tsc_shift;
>> + pvti_system_time = pvti->system_time;
>> + pvti_tsc = pvti->tsc_timestamp;
>> +
>> + /* Make sure that the version double-check is last. */
>> + smp_rmb();
>> + } while (unlikely((version & 1) || version != pvti->version));
>> +
>> + delta = tsc - pvti_tsc;
>> + 

Re: [Xen-devel] Writable page tables questions

[Andrew Cooper]

On 04/01/2015 17:17, Junji Zhi wrote:
> Hi,
>
> I'm Junji, a newbie in Xen and hoping I can contribute to the
> community one day. I have a few questions regarding the writable page
> tables, while reading The Definitive Guide to the Xen Hypervisor by
> David Chisnall:
>
> 1. Writable page tables is one Xen memory assist technique, applied to
> paravirtualized guests ONLY. HVM does not apply. Correct?
>
> 2. According to the book, when a guest wants to modify its page table,
> it triggers a trap into the hypervisor and it does a few steps:
>
> (1) it invalidates a PTE that points to the page containing the page
> table. Is my understanding correct?
>
> Q: What does "invalidate" really mean here? Does it mean simply
> flipping a bit in the PTE of the page table, or removing the PTE
> completely? Does it also need to invalidate the TLB entry?
>
> (2) then the control goes back to the guest and it can write/read the
> page table now.
>
> (3) The book's words pasted: "When an address referenced by the newly
> invalidated page directory entry is referenced (read or write), a page
> fault occurs. "
>
> Q: The description of step (3) is confusing. What does it mean by "an
> address referenced by the newly invalidated page directory entry is
> referenced"? Does it mean the case when the guest code is accessing an
> virtual address that needs to search the invalidated page table for
> translation?

I do not have the Chisnall book to hand at the moment, so cannot comment
as to the exact text in it.

However, looking at the code as it exists today,
XENFEAT_writable_page_tables (there is a typo in the ABI) is strictly
only offered to HVM guests, and not to PV guests.

PV guests must, under all circumstances, have their pagetables reachable
from any cr3 read-only.  Any ability to write to an active pagetable
without an audit from Xen would be a security issue, as a guest could
give itself access to frames which belonged to Xen or other guests.

Updating an individual PTE can be done by either writing directly to it,
in which case Xen will trap, emulate and audit the attempt, or use an
appropriate hypercall, which will be more efficient as no emulation is
required.  A PV guest is required to perform its own TLB management when
necessary (again, hypercall or trap and emulate).

Updating pagetables in general can either be done by updating each PTE
individually, or by constructing a new pagetable from scratch, pinning
it (via hypercall), which performs all the auditing at once, then
introducing it into the active set of pagetables.

An example might be:
1) Write all 512 entries into a regular page
2) Unmap the page (taking its refcount to 0, to permit a typechange)
3) Pinning the page as a specific type of pagetable (each level of
pagetables have a different type, for refcounting purposes)
4) PTE write or hypercall to introduce this new pagetable into the
active set.

The important points are that nothing can ever be changed in the active
set of pagetables without an audit by Xen, but the cost of the audit can
be amortised by constructing pagetables separately in a regular page first.

I hope this helps to clarify the situation.

~Andrew


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

Re: [Xen-devel] RMRR Fix Design for Xen

[George Dunlap]

On Fri, Dec 19, 2014 at 1:21 AM, Tiejun Chen  wrote:
> RMRR Fix Design for Xen
>
> This design is a goal to fix RMRR for Xen. It includes four sectors as
> follows:
>
> * Background
> * What is RMRR
> * Current RMRR Issues
> * Design Overview
>
> We hope this can help us to understand current problem then figure out a
> clean and better solution everyone can agree now to go forward.
>
> Background
> ==
>
> We first identified this RMRR defect when trying to pass-through IGD device,
> which can be simply fixed by adding an identity mapping in case of shared
> EPT table. However along with the community discussion, it boiled down to
> a more general RMRR problem, i.e. the identity mapping is brute-added
> in hypervisor, w/o considering whether conflicting with an existing guest
> PFN ranges. As a general solution we need invent a new mechanism so
> reserved ranges allocated by hypervisor can be exported to the user space
> toolstack and hvmloader, so conflict can be detected when constructing
> guest PFN layout, with best-effort avoidance policies to further help.
>
> What is RMRR
> 
>
> RMRR is a acronym for Reserved Memory Region Reporting.
>
> BIOS may report each such reserved memory region through the RMRR structures,
> along with the devices that requires access to the specified reserved memory
> region. Reserved memory ranges that are either not DMA targets, or memory
> ranges that may be target of BIOS initiated DMA only during pre-boot phase
> (such as from a boot disk drive) must not be included in the reserved memory
> region reporting. The base address of each RMRR region must be 4KB aligned and
> the size must be an integer multiple of 4KB. BIOS must report the RMRR 
> reported
> memory addresses as reserved in the system memory map returned through methods
> suchas INT15, EFI GetMemoryMap etc. The reserved memory region reporting
> structures are optional. If there are no RMRR structures, the system software
> concludes that the platform does not have any reserved memory ranges that are
> DMA targets.
>
> The RMRR regions are expected to be used for legacy usages (such as USB, UMA
> Graphics, etc.) requiring reserved memory. Platform designers shouldavoid or
> limit use of reserved memory regions since these require system software to
> create holes in the DMA virtual address range available to system software and
> its drivers.
>
> The following is grabbed from my BDW:
>
> (XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
> (XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ab80a000 end_address ab81dfff
> (XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
> (XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ad00 end_address af7f
>
> Here USB occupies 0xab80a000:0xab81dfff, IGD owns 0xad00:0xaf7f.
>
> Note there are zero or more Reserved Memory Region Reporting (RMRR) in one 
> given
> platform. And multiple devices may share one RMRR range. Additionally RMRR can
> go anyplace.

Tiejun,

Thanks for this document -- such a document is really helpful in
figuring out the best way to architect the solution to a problem.

I hope you don't mind me asking a few additional questions here.
You've said that:
* RMRR is a range used by devices (typically legacy devices such as
USB, but apparently also newer devices like IGD)
* RMRR ranges are reported by BIOSes
* RMRR ranges should be avoided by the guest.

I'm still missing a few things, however.

* In the case of passing through a virtual device, how does the
"range" apply wrt gpfn space and mfn space?  I assume in example
above, the range [ab80a000,ab81dfff] corresponds to an mfn range.
When passing through this device to the guest, do pfns
[ab80a000,ab81dfff] need to be mapped to the same mfn range (i.e., 1-1
mapping), or can they be mapped from somewhere else in pfn space?

* You've described the range, but later on you talk about Xen
"creating" RMRR mappings.  What does this mean?  Are there registers
that need to be written?  Do the ept / IOMMU tables need some kind of
special flags?

Thanks,
 -George

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

Re: [Xen-devel] [PATCH for-4.5 v2] libxl: Initialise CTX->xce in domain suspend [and 2 more messages]

[Ian Jackson]

Ian Jackson writes ("Re: [PATCH for-4.5 v2] libxl: Initialise CTX->xce in 
domain suspend"):
> Konrad: this should go in 4.5 because it is a bugfix without which
> libxl may dereference NULL.
...

Ian Campbell writes ("Re: [PATCH for-4.5 v2] libxl: Initialise CTX->xce in 
domain suspend"):
> Acked-by: Ian Campbell 

Konrad Rzeszutek Wilk writes ("Re: [PATCH for-4.5 v2] libxl: Initialise 
CTX->xce in domain suspend"):
> OK. Release-Acked-by: Konrad Rzeszutek Wilk 

Applied, thanks.

Ian.

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

Re: [Xen-devel] [PATCH for-4.5] libxl: Fix if{} nesting in do_pci_remove [and 1 more messages]

[Ian Jackson]

> Acked-by: Ian Campbell 
> RElease-Acked-by: Konrad Rzeszutek Wilk 

Pushed, thanks.

Ian.

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

Re: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround

[Konrad Rzeszutek Wilk]

On Mon, Jan 05, 2015 at 04:28:02PM +, Dugger, Donald D wrote:
> Working to resolve this issue, I hope to have a definitive answer by the end 
> of this week.

OK, so past Xen 4.5 release. thanks!
> 
> --
> Don Dugger
> "Censeo Toto nos in Kansa esse decisse." - D. Gale
> Ph: 303/443-3786
> 
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] 
> Sent: Monday, January 5, 2015 9:27 AM
> To: Jan Beulich
> Cc: xen-devel; Zhang, Yang Z; Tian, Kevin; Dugger, Donald D
> Subject: Re: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround
> 
> On Fri, Dec 19, 2014 at 08:31:51AM +, Jan Beulich wrote:
> > The endless story continues.
> 
> Intel maintainers, are you folks OK with these patches?
> 
> >From my perspective: Release-Acked-by: Konrad Rzeszutek Wilk 
> >
> > 
> > 1: make XSA-59 workaround fully cover XeonE5/E7 v2
> > 2: extend XSA-59 workaround to XeonE5 v3 (Haswell)
> > 
> > Signed-off-by: Jan Beulich 
> > 
> > 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH for-4.5] libxl: Fix if{} nesting in do_pci_remove

[Konrad Rzeszutek Wilk]

On Mon, Jan 05, 2015 at 04:34:36PM +, Ian Jackson wrote:
> From: Ian Jackson 
> 
> do_pci_remove contained this:
> 
> if (type == LIBXL_DOMAIN_TYPE_HVM) {
>[stuff]
> } else if (type != LIBXL_DOMAIN_TYPE_PV)
> abort();
> {
> 
> This is bizarre, and not correct.  The effect is that HVM guests end
> up running both the proper code and that intended for PV guests.  This
> causes (amongst other things) trouble when PCI devices are
> hot-unplugged from HVM guests.
> 
> This bug was introduced in abfb006f "tools/libxl: explicitly grant
> access to needed I/O-memory ranges".
> 
> This is clear candidate for Xen 4.5, being a bugfix to an important
> feature.
> 
> Reported-by: Boris Ostrovsky 
> Signed-off-by: Ian Jackson 
> Tested-by: Robert Hu 
> CC: Konrad Wilk 

RElease-Acked-by: Konrad Rzeszutek Wilk 

> CC: Sander Eikelenboom 
> CC: George Dunlap 
> ---
>  tools/libxl/libxl_pci.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 316643c..9ae37fa 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -1247,9 +1247,9 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
>  rc = ERROR_FAIL;
>  goto out_fail;
>  }
> -} else if (type != LIBXL_DOMAIN_TYPE_PV)
> -abort();
> -{
> +} else {
> +assert(type == LIBXL_DOMAIN_TYPE_PV);
> +
>  char *sysfs_path = libxl__sprintf(gc, 
> SYSFS_PCI_DEV"/"PCI_BDF"/resource", pcidev->domain,
>   pcidev->bus, pcidev->dev, 
> pcidev->func);
>  FILE *f = fopen(sysfs_path, "r");
> -- 
> 1.7.10.4
> 

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

Re: [Xen-devel] [PATCH for-4.5] libxl: Fix if{} nesting in do_pci_remove

[Ian Campbell]

On Mon, 2015-01-05 at 16:34 +, Ian Jackson wrote:
> From: Ian Jackson 
> 
> do_pci_remove contained this:
> 
> if (type == LIBXL_DOMAIN_TYPE_HVM) {
>[stuff]
> } else if (type != LIBXL_DOMAIN_TYPE_PV)
> abort();
> {
> 
> This is bizarre, and not correct.  The effect is that HVM guests end
> up running both the proper code and that intended for PV guests.  This
> causes (amongst other things) trouble when PCI devices are
> hot-unplugged from HVM guests.
> 
> This bug was introduced in abfb006f "tools/libxl: explicitly grant
> access to needed I/O-memory ranges".
> 
> This is clear candidate for Xen 4.5, being a bugfix to an important
> feature.
> 
> Reported-by: Boris Ostrovsky 
> Signed-off-by: Ian Jackson 
> Tested-by: Robert Hu 
> CC: Konrad Wilk 
> CC: Sander Eikelenboom 
> CC: George Dunlap 

Acked-by: Ian Campbell 



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

[Xen-devel] [PATCH for-4.5] libxl: Fix if{} nesting in do_pci_remove

[Ian Jackson]

From: Ian Jackson 

do_pci_remove contained this:

if (type == LIBXL_DOMAIN_TYPE_HVM) {
   [stuff]
} else if (type != LIBXL_DOMAIN_TYPE_PV)
abort();
{

This is bizarre, and not correct.  The effect is that HVM guests end
up running both the proper code and that intended for PV guests.  This
causes (amongst other things) trouble when PCI devices are
hot-unplugged from HVM guests.

This bug was introduced in abfb006f "tools/libxl: explicitly grant
access to needed I/O-memory ranges".

This is clear candidate for Xen 4.5, being a bugfix to an important
feature.

Reported-by: Boris Ostrovsky 
Signed-off-by: Ian Jackson 
Tested-by: Robert Hu 
CC: Konrad Wilk 
CC: Sander Eikelenboom 
CC: George Dunlap 
---
 tools/libxl/libxl_pci.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 316643c..9ae37fa 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1247,9 +1247,9 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
 rc = ERROR_FAIL;
 goto out_fail;
 }
-} else if (type != LIBXL_DOMAIN_TYPE_PV)
-abort();
-{
+} else {
+assert(type == LIBXL_DOMAIN_TYPE_PV);
+
 char *sysfs_path = libxl__sprintf(gc, 
SYSFS_PCI_DEV"/"PCI_BDF"/resource", pcidev->domain,
  pcidev->bus, pcidev->dev, 
pcidev->func);
 FILE *f = fopen(sysfs_path, "r");
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v4 for 4.5] x86/VPMU: Clear last_vcpu when destroying VPMU

[Konrad Rzeszutek Wilk]

On Thu, Dec 18, 2014 at 01:06:40PM -0500, Boris Ostrovsky wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try to dereference it in
> the future, when VCPU is gone.
> 
> We have to do this via IPI since otherwise there is a (somewheat
> theoretical) chance that between test and subsequent clearing
> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
> both vpmu_load() and then vpmu_save() for another VCPU. The former
> will clear last_vcpu and the latter will set it to something else.
> 
> Performing this operation via IPI will guarantee that nothing can
> happen on the remote processor between testing and clearing of
> last_vcpu.
> 
> We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
> avoid unnecessary percpu tests and arch-specific destroy ops. Thus
> checks in AMD and Intel routines are no longer needed.
> 
> Signed-off-by: Boris Ostrovsky 
> ---
>  xen/arch/x86/hvm/svm/vpmu.c   |3 ---
>  xen/arch/x86/hvm/vmx/vpmu_core2.c |2 --
>  xen/arch/x86/hvm/vpmu.c   |   20 
>  3 files changed, 20 insertions(+), 5 deletions(-)

CC-ing the rest of the maintainers (Intel ones, since Boris is
on the AMD side).

I am OK with this patch going in Xen 4.5 as for one thing to actually
use vpmu you have to pass 'vpmu=1' on the Xen command line.

Aka, Release-Acked-by: Konrad Rzeszutek Wilk 

> 
> Changes in v4:
>  * Back to v2's IPI implementation
> 
> Changes in v3:
>  * Use cmpxchg instead of IPI
>  * Use correct routine names in commit message
>  * Remove duplicate test for VPMU_CONTEXT_ALLOCATED in arch-specific
>destroy ops
> 
> Changes in v2:
>  * Test last_vcpu locally before IPI
>  * Don't handle local pcpu as a special case --- on_selected_cpus
>will take care of that
>  * Dont't cast variables unnecessarily
> 
> 
> diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
> index 8e07a98..4c448bb 100644
> --- a/xen/arch/x86/hvm/svm/vpmu.c
> +++ b/xen/arch/x86/hvm/svm/vpmu.c
> @@ -403,9 +403,6 @@ static void amd_vpmu_destroy(struct vcpu *v)
>  {
>  struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> -if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> -return;
> -
>  if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
>  amd_vpmu_unset_msr_bitmap(v);
>  
> diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
> b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> index 68b6272..590c2a9 100644
> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> @@ -818,8 +818,6 @@ static void core2_vpmu_destroy(struct vcpu *v)
>  struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  struct core2_vpmu_context *core2_vpmu_cxt = vpmu->context;
>  
> -if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> -return;
>  xfree(core2_vpmu_cxt->pmu_enable);
>  xfree(vpmu->context);
>  if ( cpu_has_vmx_msr_bitmap )
> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
> index 1df74c2..37f0d9f 100644
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -247,10 +247,30 @@ void vpmu_initialise(struct vcpu *v)
>  }
>  }
>  
> +static void vpmu_clear_last(void *arg)
> +{
> +if ( this_cpu(last_vcpu) == arg )
> +this_cpu(last_vcpu) = NULL;
> +}
> +
>  void vpmu_destroy(struct vcpu *v)
>  {
>  struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> +if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> +return;
> +
> +/*
> + * Need to clear last_vcpu in case it points to v.
> + * We can check here non-atomically whether it is 'v' since
> + * last_vcpu can never become 'v' again at this point.
> + * We will test it again in vpmu_clear_last() with interrupts
> + * disabled to make sure we don't clear someone else.
> + */
> +if ( per_cpu(last_vcpu, vpmu->last_pcpu) == v )
> +on_selected_cpus(cpumask_of(vpmu->last_pcpu),
> + vpmu_clear_last, v, 1);
> +
>  if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>  vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>  }
> -- 
> 1.7.1
> 

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

Re: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround

[Dugger, Donald D]

Working to resolve this issue, I hope to have a definitive answer by the end of 
this week.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-Original Message-
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] 
Sent: Monday, January 5, 2015 9:27 AM
To: Jan Beulich
Cc: xen-devel; Zhang, Yang Z; Tian, Kevin; Dugger, Donald D
Subject: Re: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround

On Fri, Dec 19, 2014 at 08:31:51AM +, Jan Beulich wrote:
> The endless story continues.

Intel maintainers, are you folks OK with these patches?

>From my perspective: Release-Acked-by: Konrad Rzeszutek Wilk 
>
> 
> 1: make XSA-59 workaround fully cover XeonE5/E7 v2
> 2: extend XSA-59 workaround to XeonE5 v3 (Haswell)
> 
> Signed-off-by: Jan Beulich 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround

[Konrad Rzeszutek Wilk]

On Fri, Dec 19, 2014 at 08:31:51AM +, Jan Beulich wrote:
> The endless story continues.

Intel maintainers, are you folks OK with these patches?

>From my perspective: Release-Acked-by: Konrad Rzeszutek Wilk 
>
> 
> 1: make XSA-59 workaround fully cover XeonE5/E7 v2
> 2: extend XSA-59 workaround to XeonE5 v3 (Haswell)
> 
> Signed-off-by: Jan Beulich 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH] xen: arm: correct off-by-one error in consider_modules

[Konrad Rzeszutek Wilk]

On Mon, Dec 22, 2014 at 11:54:01AM +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 21/12/2014 12:18, Ian Campbell wrote:
> >By iterating up to <= mi->nr_mods we are running off the end of the boot
> >modules, but more importantly it causes us to then skip the first FDT 
> >reserved
> >region, meaning we might clobber it.
> 
> Oops. Good catch!
> 
> OOI, how did you find it?
> 
> >Signed-off-by: Ian Campbell 
> 
> Reviewed-by: Julien Grall 
> 
> >---
> >For 4.5: I think this bug fix should go in, it fixes a real issue and is low
> >risk.

Release-Acked-by: Konrad Rzeszutek Wilk 
> 
> Agreed.
> 
> >I'll also add to my list of things to consider for backport to 4.4.
> 
> Ditto.
> 
> Regards,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported

[Ian Campbell]

On Mon, 2015-01-05 at 16:07 +, Andrew Cooper wrote:
> >> What usecase was supervisor_mode_kernel developed for?  It seems
> >> counter-intuitive, but I can't find anything in the history explaining
> >> its use.
> > It was a prototype from the pre-pvops days to see if it would be
> > feasible to have a single kernel binary which ran either on Xen or on a
> > stub hypervisor which ran it "as native" with little or no loss of
> > performance^TM (e.g. for distro's convenience to avoid the multiple
> > kernel issue).
> >
> > It never went beyond a prototype with Xen proper instead of the proposed
> > stub hypervisor and then pvops came along and was a much more sensible
> > idea...
> 
> Considering the implications of running dom0 in ring0, pvops seems like
> a much more sensible idea.

It wouldn't have been a dom0, it would have just been a native system
which happened to use some Xen interfaces, the intention was never to be
able to run guests or anything, just to allow distros to only support
one binary.

Ian.


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

Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported

[Andrew Cooper]

On 05/01/15 15:41, Ian Campbell wrote:
> On Mon, 2015-01-05 at 15:35 +, Andrew Cooper wrote:
>> Answering out-of-order
>>
>> This patch has no functional change WRT PVH.  The hunk commented on is
>> simply changed via indentation due to the removal of the conditional it
>> is in.  It was never been possible for a PVH kernel boot with
>> "!XENFEAT_supervisor_mode_kernel" in its feature string.
> Oh, good!
>
>> If retcon'ing this feature flag is acceptable then the problem goes
>> away, as can the commented hunk.  However, given the meaning of the
>> flag, it really should be advertised to plain HVM guests as well,
>> because their kernel does run in ring0.  At that point, it becomes more
>> of a general "running in an hvm container" flag.
> Conversely one could argue that it is a PV* only feature which makes no
> sense to an HVM guest (which I think is approximately what it means now)

This is going to cause problems with the effort to unify PVH and HVM
into a single guest type, which is why I raised the point.  The Linux
PVH code is already using it as a PVH vs non-PVH flag.

Either way - these are not problems which need fixing right now, but do
need to be considered as the unification work progresses.

>
>> What usecase was supervisor_mode_kernel developed for?  It seems
>> counter-intuitive, but I can't find anything in the history explaining
>> its use.
> It was a prototype from the pre-pvops days to see if it would be
> feasible to have a single kernel binary which ran either on Xen or on a
> stub hypervisor which ran it "as native" with little or no loss of
> performance^TM (e.g. for distro's convenience to avoid the multiple
> kernel issue).
>
> It never went beyond a prototype with Xen proper instead of the proposed
> stub hypervisor and then pvops came along and was a much more sensible
> idea...

Considering the implications of running dom0 in ring0, pvops seems like
a much more sensible idea.

~Andrew


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

Re: [Xen-devel] [v3 1/5] Qemu-Xen-vTPM: Support for Xen stubdom vTPM command line options

[Eric Blake]

On 12/30/2014 04:02 PM, Quan Xu wrote:
> Signed-off-by: Quan Xu 

This message was missing an In-Reply-To header tying it to the 0/5 cover
letter, making it show up as an independent thread.  Please see if you
can fix that for the next submission.

> ---
>  configure| 14 ++
>  hmp.c|  7 +++
>  qapi-schema.json | 19 ---
>  qemu-options.hx  | 13 +++--
>  tpm.c|  7 ++-
>  5 files changed, 54 insertions(+), 6 deletions(-)
> 

> +++ b/qapi-schema.json
> @@ -2854,9 +2854,10 @@
>  #
>  # @passthrough: TPM passthrough type
>  #
> -# Since: 1.5
> +# @xenstubdoms: TPM xenstubdoms type (since 2.3)## Since 1.5

Missing newlines.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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

Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine

[Daniel De Graaf]

On 12/30/2014 11:44 PM, Quan Xu wrote:[...]

diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c

[...]

+   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;


Unless I'm missing something, this still assumes that the HVM device
model is located in domain 0, and so it will not work if a stub domain
is used for qemu.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH] xc Python ext lib: Xen 4.6 Unable to start a 2T guest without OverflowError

[Konrad Rzeszutek Wilk]

On Tue, Dec 23, 2014 at 02:04:28PM -0500, Cathy Avery wrote:
> Starting a vm with memory over 2T resulted in an overflow error.
> 
> memory = 2097152 defined as number of megabytes returns the error
> "OverflowError: signed integer is greater than maximum"
> 
> The error is the result of the python extension argument translator
> defining max_memkb as a signed int instead of an unsigned int.
> So PyArg_ParseTuple(args, "ii", &dom, &maxmem_kb) overflowed by one with
> 2147483648 kb.
> 
> The other issue is that max_memkb is defined as uint64_t in the subsequent
> domctl target api so the xc lib and its python C extension should use 
> uint64_t as well.
> 
> /* XEN_DOMCTL_max_mem */
> struct xen_domctl_max_mem {
> /* IN variables. */
> uint64_aligned_t max_memkb;
> };
> 
> Signed-off-by: Cathy Avery 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  tools/libxc/include/xenctrl.h |2 +-
>  tools/libxc/xc_domain.c   |2 +-
>  tools/python/xen/lowlevel/xc/xc.c |4 ++--
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 0ad8b8d..1b5c622 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1253,7 +1253,7 @@ int xc_getcpuinfo(xc_interface *xch, int max_cpus,
>  
>  int xc_domain_setmaxmem(xc_interface *xch,
>  uint32_t domid,
> -unsigned int max_memkb);
> +uint64_t max_memkb);
>  
>  int xc_domain_set_memmap_limit(xc_interface *xch,
> uint32_t domid,
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index b864872..2c0fc9f 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -630,7 +630,7 @@ int xc_shadow_control(xc_interface *xch,
>  
>  int xc_domain_setmaxmem(xc_interface *xch,
>  uint32_t domid,
> -unsigned int max_memkb)
> +uint64_t max_memkb)
>  {
>  DECLARE_DOMCTL;
>  domctl.cmd = XEN_DOMCTL_max_mem;
> diff --git a/tools/python/xen/lowlevel/xc/xc.c 
> b/tools/python/xen/lowlevel/xc/xc.c
> index f83e33d..7a5d36e 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -1658,9 +1658,9 @@ static PyObject *pyxc_sched_credit2_domain_get(XcObject 
> *self, PyObject *args)
>  static PyObject *pyxc_domain_setmaxmem(XcObject *self, PyObject *args)
>  {
>  uint32_t dom;
> -unsigned int maxmem_kb;
> +uint64_t maxmem_kb;
>  
> -if (!PyArg_ParseTuple(args, "ii", &dom, &maxmem_kb))
> +if (!PyArg_ParseTuple(args, "ik", &dom, &maxmem_kb))
>  return NULL;
>  
>  if (xc_domain_setmaxmem(self->xc_handle, dom, maxmem_kb) != 0)
> -- 
> 1.7.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Xen-devel] [rumpuserxen test] 33116: all pass - PUSHED

[xen . org]

flight 33116 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33116/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen  21a3f2f128032fa5450f5693c3d00d82fc693123
baseline version:
 rumpuserxen  21689d533b9e90721fc8679c2794d00815b46cce


People who touched revisions under test:
  Antti Kantee 


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-i386-rumpuserxen-i386 pass



sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

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


Pushing revision :

+ branch=rumpuserxen
+ revision=21a3f2f128032fa5450f5693c3d00d82fc693123
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen 
21a3f2f128032fa5450f5693c3d00d82fc693123
+ branch=rumpuserxen
+ revision=21a3f2f128032fa5450f5693c3d00d82fc693123
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock 
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ 

Re: [Xen-devel] Parallel make supported?

[Ian Campbell]

On Mon, 2014-12-29 at 13:01 +, Wei Liu wrote:
> Please don't top post.
> 
> On Fri, Dec 19, 2014 at 10:09:31PM +, Peter Kay wrote:
> > Thanks, see attached :
> > 
> > This is on Salix 14.1 running the 3.17.4 kernel. That's not particularly
> > relevant though, as I had exactly the same error on Debian using other
> > kernel versions.
> > 
> 
> Looking at your build log
> 
> gcc -pthread -Wl,-soname -Wl,libxenstore.so.3.0 -shared -o 
> libxenstore.so.3.0.3 xs.opic xs_lib.opic
> ar rcs libxenstore.a xs.o xs_lib.o
> gcc xs_tdb_dump.o utils.o tdb.o talloc.o -o xs_tdb_dump
> gcc xenstored_core.o xenstored_watch.o xenstored_domain.o 
> xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o 
> xenstored_posix.o 
> /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenctrl.so
>   -o xenstored
> gcc init-xenstore-domain.o libxenstore.so 
> /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenctrl.so
>  
> /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenguest.so
>  
> /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/xenstore/libxenstore.so
>  -o init-xenstore-domain
> gcc: error: libxenstore.so: No such file or directory
> gcc: error: 
> /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/xenstore/libxenstore.so:
>  No such file or directory
> make[4]: *** [init-xenstore-domain] Error 1
> make[4]: Leaving directory 
> `/home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore'
> make[3]: *** [subdir-install-xenstore] Error 2
> make[3]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools'
> make[2]: *** [subdirs-install] Error 2
> make[2]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools'
> make[1]: *** [install-tools] Error 2
> make[1]: *** Waiting for unfinished jobs
> 
> libxenstore.so is missing. However Makefile dependency ensures the
> compilation of init-xenstore-domain does not proceed unless
> libxenstore.so exists.

Right. Specifically (quoting a select few lines from
tools/xenstore/Makefile):

LIBXENSTORE := libxenstore.so
init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
libxenstore.so: libxenstore.so.$(MAJOR)
libxenstore.so.$(MAJOR): libxenstore.so.$(MAJOR).$(MINOR)
libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic

So it would be a make bug if init-xenstore-domain were linked without
having created libxenstore.so first, but that (such an obvious bug in
make) doesn't seem very likely.

Peter, what does
ls -l tools/xenstore/libxenstore*
show?

Also "make -d -C tools/xenstore init-xenstore-domain" might give a clue
as to why make thinks it doesn't need to rebuild those objects.

If $(LIBXENSTORE) were unset then that might explain things, but I can't
see how that could happen, it must always be either libxenstore.so or
libxenstore.a. Changing the init-xenstore-domain rule to:
init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
@echo init-xenstore-domain using $(LIBXENSTORE)
$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) 
$(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
would confirm or deny that theory (nb before @echo needs to be a hard
tab).

Ian.


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

Re: [Xen-devel] Crash on efi_reset_machine on Lenovo ThinkCentre m93 (Haswell)

[Andrew Cooper]

On 05/01/15 15:04, Konrad Rzeszutek Wilk wrote:
> The BIOS on the machine is:
>
> DMI: LENOVO 10A6S09R01/SHARKBAY, BIOS FBKTA4AUS 12/11/2014
>
> (just flashed it today - earlier versions had the same issue)
>
> And with both Xen 4.4 and Xen 4.5 when rebooting from EFI
> I get:
>
>
> [   35.278564] reboot: Restarting system
> (XEN) Domain 0 shutdown: rebooting machine.
> (XEN) [ Xen-4.4.1  x86_64  debug=n  Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] d5fd8412
> (XEN) RFLAGS: 00010202   CONTEXT: hypervisor
> (XEN) rax: 0046   rbx:    rcx: 
> (XEN) rdx: d5fd89b0   rsi:    rdi: 
> (XEN) rbp:    rsp: 82d0802dfac8   r8:  82d0802dfb08
> (XEN) r9:  82d0802dfaf8   r10:    r11: 0022ebb099f2
> (XEN) r12:    r13: 0061   r14: 
> (XEN) r15: 82d0802dfd7c   cr0: 80050033   cr4: 001526f0
> (XEN) cr3: 0004134cf000   cr2: 8800092472b0
> (XEN) ds:    es:    fs:    gs:    ss:    cs: e008
> (XEN) Xen stack trace from rsp=82d0802dfac8:
> (XEN)0001 0010 82d080178660 
> (XEN)82d0802dfb00 0004f0f8 82d0802dfd7c 
> (XEN)0046   d5fe32f6
> (XEN)  c1e87000 fffe
> (XEN)82d0802d8000 82d080233a1d  c1e87000
> (XEN)001526f0 82d0802339fd 0061 
> (XEN)fffe 82d0801958dd 82d0802d8000 
> (XEN)82d0802f7800  82d0802dfdc8 82d0802f7800
> (XEN) 82d080195a1b 0067 82d080128f94
> (XEN)0008 82d0802dfc78 82d080289780 82d08017f329
> (XEN)00fc083c3a60 82d0802dfdc8  00fb8000
> (XEN)0008 0046 0008 82d080301040
> (XEN)82d080289780 82d0802dfdc8 82d0802f7800 
> (XEN)82d0802dfd7c 82d0801772f7 82d0802dfd7c 
> (XEN)82d0802f7800 82d0802dfdc8 82d080289780 82d080301040
> (XEN)0022ebb099f2 82d080322ab0 0002 00082b337202
> (XEN)00c1 0002 03fa 0002
> (XEN)82d080301040 00fb 82d08013fa0f e008
> (XEN)0206 82d0802dfd20  82d08013fba1
> (XEN)0004 82d08012b96e 82d0802dfdc8 82d080301080
> (XEN) Xen call trace:
> (XEN)[] d5fd8412
> (XEN)[] io_apic_write+0/0x70
> (XEN)[] efi_reset_system+0x2d/0x60
> (XEN)[] efi_reset_system+0xd/0x60
> (XEN)[] machine_restart+0xbd/0x1f0
> (XEN)[] __machine_restart+0xb/0x10
> (XEN)[] smp_call_function_interrupt+0x64/0xa0
> (XEN)[] do_IRQ+0x279/0x6b0
> (XEN)[] common_interrupt+0x57/0x60
> (XEN)[] ns_read_reg+0x4f/0x50
> (XEN)[] ns16550_interrupt+0x31/0x80
> (XEN)[] add_entry+0x4e/0xb0
> (XEN)[] do_IRQ+0x337/0x6b0
> (XEN)[] common_interrupt+0x57/0x60
> (XEN)[] mwait_idle+0x222/0x370
> (XEN)[] idle_loop+0x26/0x60
> (XEN) 
> (XEN) 
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) GENERAL PROTECTION FAULT
> (XEN) [error_code=]
> (XEN) 
> (XEN) 
> (XEN) ...
>
> or (Xen 4.5):
>
> (XEN) Domain 0 shutdown: rebooting machine.
> (XEN) [ Xen-4.5.0-rc-lK  x86_64  debug=y  Tainted:C ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] d5fd83d0
> (XEN) RFLAGS: 00010246   CONTEXT: hypervisor
> (XEN) rax: c2e1a990   rbx:    rcx: 0002
> (XEN) rdx: d5fd89b0   rsi:    rdi: 
> (XEN) rbp:    rsp: 82d080457aa8   r8:  
> (XEN) r9:  82d080457ad8   r10: 82d0802a1270   r11: 002580dbb411
> (XEN) r12:    r13: 00fb   r14: 0061
> (XEN) r15:    cr0: 80050033   cr4: 001526f0
> (XEN) cr3: 000413479000   cr2: 8803e800e4f0
> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=82d080457aa8:
> (XEN)82d080457ab8 82d08017c007 82d080457ae8 82d08017d1ef
> (XEN)82d080457ae0 0092  0286
> (XEN)82d080457b18 0206  d5fe32f6
> (XEN)  82d080457b48 82d08024582c
> (XEN) 82d080245ad4 c1eb4000 82d080457b68
> (XEN)00152670 fff

Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1

[Ian Jackson]

Boris Ostrovsky writes ("Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 
4.5 confirmed to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 
4.5.0-rc1"):
> On 01/05/2015 10:27 AM, Konrad Rzeszutek Wilk wrote:
> > Ian, were you waiting on Boris to repost the patches?

Yes.

> I wasn't planning on resending them. They (or, more likely, it) need to 
> be reworked to use async notifications and I haven't done this.

Oh.

In the meantime we should apply my fix, but it doesn't have a proper
commit message yet.  I will write one and a release ack request.

Ian.

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

Re: [Xen-devel] [PATCH OSSTEST v3] ts-libvirt-build: use Osstest::BuildSupport::submodulefixup

[Ian Campbell]

On Mon, 2015-01-05 at 15:36 +, Ian Campbell wrote:
> Instead of cloning gnulib manually which can break if upstream gnulib
> gets ahead of libvirt.git (which applies patches on the fly etc). By
> using submodulefixup we automatically DTRT and use the version of
> gnulib specified by the libvirt.git submodule metadata, but with a
> runvar override if necessary.
> 
> This also removes a whole bunch of faffing in ap-*, cr-daily-branch
> and mfi-common to get the version of gnulib to use, which was always a
> bit of a wart (ungated for one thing...).
> 
> We continue to use --no-git and GNULIB_SRCDIR because otherwise
> autogen.sh (via bootstrap) will force its own version, overwriting
> what submodulefixup has done. For this we need a way to get the hash
> representing the module, so introduce submodule_find (and rework
> submodule_have in terms of it).
> 
> Tested in standalone mode with build-amd64-libvirt and
> build-amd64-rumpuserxen (because I touched submodule_have, AFAICT the
> bodges were not run). The libvirt build was tested both with the
> automatic revisions and with:
> revision_libvirt=2360fe5d24175835d3f5fd1c7e8e6e13addab629
> revision_libvirt_gnulib=16518d9ed8f25d3e53931dd1aa343072933e4604
> (used in successful libvirt flight 32648), in both cases confirming
> that the build used the desired versions.
> 
> Signed-off-by: Ian Campbell 

Ian J acked on IRC so I have pushed to osstests' pretest branch.

Ian.

> ---
> v2: Honour revision_libvirt_gnulib.
> v3: Fix submodule_have, defined(&sub) is always true because defined
> is special wrt &sub.
> ---
>  Osstest/BuildSupport.pm | 13 ++---
>  ap-common   |  3 ---
>  ap-fetch-version|  4 
>  ap-fetch-version-old|  4 
>  ap-print-url|  3 ---
>  ap-push |  5 -
>  cr-daily-branch |  4 
>  mfi-common  |  1 -
>  ts-libvirt-build| 20 +++-
>  9 files changed, 21 insertions(+), 36 deletions(-)
> 
> diff --git a/Osstest/BuildSupport.pm b/Osstest/BuildSupport.pm
> index 874e27e..933f6e1 100644
> --- a/Osstest/BuildSupport.pm
> +++ b/Osstest/BuildSupport.pm
> @@ -43,7 +43,7 @@ BEGIN {
>xendist
>$xendist
>  
> -  submodulefixup submodule_have
> +  submodulefixup submodule_have submodule_find
>  
>);
>  %EXPORT_TAGS = ( );
> @@ -145,9 +145,16 @@ sub submodulefixup () {
>  return \@submodules;
>  }
>  
> -sub submodule_have ($$) {
> +sub submodule_find ($$) {
>  my ($submodules, $ourname) = @_;
> -return !!grep { $_->{OurName} eq $ourname } @$submodules;
> +my @submods = grep { $_->{OurName} eq $ourname } @$submodules;
> +return undef unless @submods;
> +die "more than one $ourname?" if @submods ne 1;
> +return $submods[0];
> +}
> +
> +sub submodule_have ($$) {
> +return !!&submodule_find;
>  }
>  
>  1;
> diff --git a/ap-common b/ap-common
> index ff50754..96cbd14 100644
> --- a/ap-common
> +++ b/ap-common
> @@ -37,8 +37,6 @@
>  : ${PUSH_TREE_LIBVIRT:=$XENBITS:/home/xen/git/libvirt.git}
>  : ${BASE_TREE_LIBVIRT:=git://xenbits.xen.org/libvirt.git}
>  
> -: ${TREE_GNULIB_LIBVIRT:=$(besteffort_repo git://git.sv.gnu.org/gnulib.git)}
> -
>  : ${TREE_RUMPUSERXEN:=https://github.com/rumpkernel/rumprun-xen}
>  : ${TREEVCS_RUMPUSERXEN:=git}
>  : ${BASE_TREE_RUMPUSERXEN:=git://xenbits.xen.org/rumpuser-xen.git}
> @@ -77,7 +75,6 @@ fi
>  : ${LOCALREV_XEN:=daily-cron.$branch}
>  : ${LOCALREV_LINUX:=daily-cron.$branch}
>  : ${LOCALREV_LIBVIRT:=daily-cron.$branch}
> -: ${LOCALREV_GNULIB_LIBVIRT:=daily-cron.$branch}
>  : ${LOCALREV_RUMPUSERXEN:=daily-cron.$branch}
>  : ${LOCALREV_SEABIOS:=daily-cron.$branch}
>  
> diff --git a/ap-fetch-version b/ap-fetch-version
> index 9c189b4..f6c65d8 100755
> --- a/ap-fetch-version
> +++ b/ap-fetch-version
> @@ -77,10 +77,6 @@ libvirt)
>   repo_tree_rev_fetch_git libvirt \
>   $TREE_LIBVIRT master $LOCALREV_LIBVIRT
>   ;;
> -gnulib-libvirt)
> - repo_tree_rev_fetch_git gnulib-libvirt \
> - $TREE_GNULIB_LIBVIRT master $LOCALREV_GNULIB_LIBVIRT
> - ;;
>  rumpuserxen)
>   repo_tree_rev_fetch_git rumpuserxen \
>   $TREE_RUMPUSERXEN master $LOCALREV_RUMPUSERXEN
> diff --git a/ap-fetch-version-old b/ap-fetch-version-old
> index f3cf339..43c997c 100755
> --- a/ap-fetch-version-old
> +++ b/ap-fetch-version-old
> @@ -88,10 +88,6 @@ rumpuserxen)
>   repo_tree_rev_fetch_git rumpuserxen \
>   $BASE_TREE_RUMPUSERXEN xen-tested-master 
> $BASE_LOCALREV_RUMPUSERXEN
>   ;;
> -gnulib-libvirt)
> - # No push gate, same as ap-fetch-version
> - ./ap-fetch-version $branch
> - ;;
>  seabios)
>   repo_tree_rev_fetch_git seabios \
>   $BASE_TREE_SEABIOS xen-tested-master $BASE_LOCALREV_SEABIOS
> diff --git a/ap-print-url b/ap-print-url
> index a14d2a6..7b27e1e 100755
> --- a/ap-print-

Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1

[Boris Ostrovsky]

On 01/05/2015 10:27 AM, Konrad Rzeszutek Wilk wrote:

On Mon, Jan 05, 2015 at 12:48:16PM +, George Dunlap wrote:

On Thu, Dec 18, 2014 at 4:55 AM, Hu, Robert  wrote:

For this specific problem though I think

http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html

We verified this on RC4, it works.
Will your patch get in Xen 4.5 release? Otherwise hotplug vt-d device with a 
running guest will not work properly.

It looks like  IanJ's patch (referenced above) has not been applied.
It's clearly a bug fix, so it probably should be...



Ian, were you waiting on Boris to repost the patches?


I wasn't planning on resending them. They (or, more likely, it) need to 
be reworked to use async notifications and I haven't done this.


Ian's fix is independent of what I need to do.

-boris

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

Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.

[George Dunlap]

On Fri, Dec 12, 2014 at 6:29 AM, Tian, Kevin  wrote:
>> We're not there in the current design, purely because XenGT has to be
>> in dom0 (so it can trivially DoS Xen by rebooting the host).
>
> Can we really decouple dom0 from DoS Xen? I know there's on-going effort
> like PVH Dom0, however there are lots of trickiness in Dom0 which can
> put the platform into a bad state. One example is ACPI. All the platform
> details are encapsulated in AML language, and only dom0 knows how to
> handle ACPI events. Unless Xen has another parser to guard all possible
> resources which might be touched thru ACPI, a tampered dom0 has many
> way to break out. But that'd be very challenging and complex.
>
> If we can't containerize Dom0's behavior completely, I would think dom0
> and Xen actually in the same trust zone, so putting XenGT in Dom0 shouldn't
> make things worse.

The question here is, "If a malicious guest can manage to break into
XenGT, what can they do?"

If XenGT is running in dom0, then the answer is, "At very least, they
can DoS the host because dom0 is allowed to reboot; they can probably
do lots of other nasty things as well."

If XenGT is running in its own domain, and can only add IOMMU entries
for MFNs belonging to XenGT-only VMs, then the answer is, "They can
access other XenGT-enabled VMs, but they cannot shut down the host or
access non-XenGT VMs."

Slides 8-11 of a presentation I gave
(http://www.slideshare.net/xen_com_mgr/a-brief-tutorial-on-xens-advanced-security-features)
can give you a graphical idea of what we're' talking about.

 -George

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

Re: [Xen-devel] [PATCH for-4.5] tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ssid_label

[Konrad Rzeszutek Wilk]

On Mon, Jan 05, 2015 at 02:19:58PM +, Andrew Cooper wrote:
> libxl_dominfo contains a ssid_label pointer which will have memory allocated
> for it in libxl_domain_info() if the hypervisor has CONFIG_XSM compiled.
> However, the lack of appropriate use of libxl_dominfo_{init,dispose}() will
> cause the label string to be leaked, even in success cases.
> 
> This was discovered by XenServers Coverity scanning, and are issues not
> identified by upstream Coverity Scan.
> 
> Signed-off-by: Andrew Cooper 
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Konrad Rzeszutek Wilk 
> 
> ---
> 
> Requesting a release-exception as suggested by IanJ.  These are memory leaks
> which accumulate via the successful completion of libxl library functions (if
> XSM is enabled), which will undoubtedly cause issues for the likes of libvirt
> and xenopsd-libxl which use libxl in daemon processes.

Release-Acked-by: Konrad Rzeszutek Wilk 


> 
> As we are very close to the release, I have opted for the more
> obviously-correct code rather than the pragmatically better code, particularly
> in two locations where libxl_domain_info() is called in a loop, and the
> dispose()/init() pair is required to prevent leaking the allocation on each
> iteration.
> 
> All of the uses of libxl_domain_info() patched here could better be an
> xc_dominfo_getlist() which reduces the quantity of hypercalls made, and the
> amount of data transformation done behind the scenes.
> ---
>  tools/libxl/libxl.c |   26 --
>  tools/libxl/libxl_dom.c |   14 ++
>  2 files changed, 34 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 50a8928..372dd3b 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -364,6 +364,8 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>  char *uuid;
>  const char *vm_name_path;
>  
> +libxl_dominfo_init(&info);
> +
>  dom_path = libxl__xs_get_dompath(gc, domid);
>  if (!dom_path) goto x_nomem;
>  
> @@ -481,6 +483,7 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>  rc = 0;
>   x_rc:
>  if (our_trans) xs_transaction_end(ctx->xsh, our_trans, 1);
> +libxl_dominfo_dispose(&info);
>  return rc;
>  
>   x_fail:  rc = ERROR_FAIL;  goto x_rc;
> @@ -4594,6 +4597,8 @@ static int libxl__fill_dom0_memory_info(libxl__gc *gc, 
> uint32_t *target_memkb,
>  libxl_ctx *ctx = libxl__gc_owner(gc);
>  uint32_t free_mem_slack_kb = 0;
>  
> +libxl_dominfo_init(&info);
> +
>  retry_transaction:
>  t = xs_transaction_start(ctx->xsh);
>  
> @@ -4626,6 +4631,8 @@ retry_transaction:
>  }
>  }
>  
> +libxl_dominfo_dispose(&info);
> +libxl_dominfo_init(&info);
>  rc = libxl_domain_info(ctx, &info, 0);
>  if (rc < 0)
>  goto out;
> @@ -4664,7 +4671,7 @@ out:
>  rc = ERROR_FAIL;
>  }
>  
> -
> +libxl_dominfo_dispose(&info);
>  return rc;
>  }
>  
> @@ -4999,6 +5006,8 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx, 
> uint32_t domid, int wait_secs)
>  uint32_t target_memkb = 0;
>  libxl_dominfo info;
>  
> +libxl_dominfo_init(&info);
> +
>  do {
>  wait_secs--;
>  sleep(1);
> @@ -5007,9 +5016,11 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx, 
> uint32_t domid, int wait_secs)
>  if (rc < 0)
>  goto out;
>  
> +libxl_dominfo_dispose(&info);
> +libxl_dominfo_init(&info);
>  rc = libxl_domain_info(ctx, &info, domid);
>  if (rc < 0)
> -return rc;
> +goto out;
>  } while (wait_secs > 0 && (info.current_memkb + info.outstanding_memkb) 
> > target_memkb);
>  
>  if ((info.current_memkb + info.outstanding_memkb) <= target_memkb)
> @@ -5018,6 +5029,7 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx, 
> uint32_t domid, int wait_secs)
>  rc = ERROR_FAIL;
>  
>  out:
> +libxl_dominfo_dispose(&info);
>  return rc;
>  }
>  
> @@ -5435,6 +5447,8 @@ static int libxl__set_vcpuonline_xenstore(libxl__gc 
> *gc, uint32_t domid,
>  xs_transaction_t t;
>  int i, rc = ERROR_FAIL;
>  
> +libxl_dominfo_init(&info);
> +
>  if (libxl_domain_info(CTX, &info, domid) < 0) {
>  LOGE(ERROR, "getting domain info list");
>  goto out;
> @@ -5454,6 +5468,7 @@ retry_transaction:
>  } else
>  rc = 0;
>  out:
> +libxl_dominfo_dispose(&info);
>  return rc;
>  }
>  
> @@ -5463,8 +5478,11 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, 
> uint32_t domid,
>  libxl_dominfo info;
>  int i;
>  
> +libxl_dominfo_init(&info);
> +
>  if (libxl_domain_info(CTX, &info, domid) < 0) {
>  LOGE(ERROR, "getting domain info list");
> +libxl_dominfo_dispose(&info);
>  return ERROR_FAIL;
>  }
>  for (i = 0; i <= info.vcpu_max_id; i++) {
> @@ -5477,6 +5495,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, 
> uint32_t domid,
>  

Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1

[Konrad Rzeszutek Wilk]

On Mon, Jan 05, 2015 at 12:48:16PM +, George Dunlap wrote:
> On Thu, Dec 18, 2014 at 4:55 AM, Hu, Robert  wrote:
> >>
> >> For this specific problem though I think
> >>
> >> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html
> > We verified this on RC4, it works.
> > Will your patch get in Xen 4.5 release? Otherwise hotplug vt-d device with 
> > a running guest will not work properly.
> 
> It looks like  IanJ's patch (referenced above) has not been applied.
> It's clearly a bug fix, so it probably should be...



Ian, were you waiting on Boris to repost the patches?
> 
>  -George

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

Re: [Xen-devel] [PATCH for-4.5 v2] libxl: Initialise CTX->xce in domain suspend

[Konrad Rzeszutek Wilk]

On Mon, Jan 05, 2015 at 02:35:37PM +, Ian Jackson wrote:
> Yang Hongyang writes ("[PATCH] xl/libxl: fix migrate/Remus regression (core 
> dumped)"):
> > When excuting xl migrate/Remus, the following error occurd:
> > [root@master xen]# xl migrate 5 slaver
> > migration target: Ready to receive domain.
> > Saving to migration stream new xl format (info 0x1/0x0/1225)
> > Loading new save file  (new xl fmt info 
> > 0x1/0x0/1225)
> >  Savefile contains xl domain config in JSON format
> > Parsing config from 
> > Segmentation fault (core dumped)
> > 
> > This is because CTX->xce is used without been initialized.
> > The bug was introduced by commit 2ffeb5d7f5d8
> > libxl: events: Deregister evtchn fd when not needed
> > which remove the initialization of xce from libxl__ctx_alloc.
> > 
> > This patch initialze the CTX->xce before use it.
> 
> Thanks.  This patch goes in the right direction, but isn't quite
> correct because it doesn't check the return value from
> libxl__ctx_evtchn_init.
> 
> Looking at this it is clear that following the on-demand
> initialisation of CTX->xce, it is normally necessary for any evtchn
> user in libxl to call libxl__ctx_evtchn_init, since they will need the
> xce for finding the right port number to pass to
> libxl__ev_evtchn_wait.
> 
> Sorry for not noticing this when I made my earlier change.
> 
> I have therefore:
>  * In the patch below, added changes to the comments to document this.
>  * Done git grep '\bxce\b' tools/libxl  and checked the other uses.
>  * Consequently, verified that the rest of the code in libxl_dom.c
>avoids using xce unless guest_evtchn.port>=0, and properly
>initialises .port to -1, so that there is no need for further calls
>to libxl__ctx_evtchn_init.
> 
> I have compiled but not executed this patch.  Yang Hongyang: can you
> please test that it fixes the bug for you ?
> 
> Konrad: this should go in 4.5 because it is a bugfix without which
> libxl may dereference NULL.

OK. Release-Acked-by: Konrad Rzeszutek Wilk 

> 
> (I have also somewhat improved the English grammar in the commit
> message.)
> 
> Thanks,
> Ian.
> 
> commit 9d1cb27f5e961fd9db1c7d8381af18e33510f924
> Author: Ian Jackson 
> Date:   Mon Jan 5 14:31:00 2015 +
> 
> libxl: Initialise CTX->xce in domain suspend, as needed
> 
> When excuting xl migrate/Remus, the following error can occur:
>   [root@master xen]# xl migrate 5 slaver
>   migration target: Ready to receive domain.
>   Saving to migration stream new xl format (info 0x1/0x0/1225)
>   Loading new save file  (new xl fmt info 
> 0x1/0x0/12\
> )
>Savefile contains xl domain config in JSON format
>   Parsing config from 
>   Segmentation fault (core dumped)
> 
> This is because CTX->xce is used without been initialized.
> The bug was introduced by commit 2ffeb5d7f5d8
> libxl: events: Deregister evtchn fd when not needed
> which removed the initialization of xce from libxl__ctx_alloc.
> 
> In this patch we initialise the CTX->xce before using it.  Also, we
> adjust the doc comment for libxl__ev_evtchn_* to mention the need to
> do so.
> 
> Signed-off-by: Yang Hongyang 
> Signed-off-by: Ian Jackson 
> Cc: Ian Campbell 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Wei Liu 
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 74ea84b..94ae818 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -1824,6 +1824,9 @@ void libxl__domain_suspend(libxl__egc *egc, 
> libxl__domain_suspend_state *dss)
>  port = xs_suspend_evtchn_port(dss->domid);
>  
>  if (port >= 0) {
> +rc = libxl__ctx_evtchn_init(gc);
> +if (rc) goto out;
> +
>  dss->guest_evtchn.port =
>  xc_suspend_evtchn_init_exclusive(CTX->xch, CTX->xce,
>dss->domid, port, 
> &dss->guest_evtchn_lockfd);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 9695f18..6dac0f8 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -800,8 +800,10 @@ static inline int libxl__ev_xswatch_isregistered(const 
> libxl__ev_xswatch *xw)
>  
>  /*
>   * The evtchn facility is one-shot per call to libxl__ev_evtchn_wait.
> - * You should call some suitable xc bind function on (or to obtain)
> - * the port, then libxl__ev_evtchn_wait.
> + * You should:
> + *   Use libxl__ctx_evtchn_init to make sure CTX->xce is valid;
> + *   Call some suitable xc bind function on (or to obtain) the port;
> + *   Then call libxl__ev_evtchn_wait.
>   *
>   * When the event is signaled then the callback will be made, once.
>   * Then you must call libxl__ev_evtchn_wait again, if desired.

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

[Xen-devel] Crash on efi_reset_machine on Lenovo ThinkCentre m93 (Haswell)

[Konrad Rzeszutek Wilk]

The BIOS on the machine is:

DMI: LENOVO 10A6S09R01/SHARKBAY, BIOS FBKTA4AUS 12/11/2014

(just flashed it today - earlier versions had the same issue)

And with both Xen 4.4 and Xen 4.5 when rebooting from EFI
I get:


[   35.278564] reboot: Restarting system
(XEN) Domain 0 shutdown: rebooting machine.
(XEN) [ Xen-4.4.1  x86_64  debug=n  Not tainted ]
(XEN) CPU:0
(XEN) RIP:e008:[] d5fd8412
(XEN) RFLAGS: 00010202   CONTEXT: hypervisor
(XEN) rax: 0046   rbx:    rcx: 
(XEN) rdx: d5fd89b0   rsi:    rdi: 
(XEN) rbp:    rsp: 82d0802dfac8   r8:  82d0802dfb08
(XEN) r9:  82d0802dfaf8   r10:    r11: 0022ebb099f2
(XEN) r12:    r13: 0061   r14: 
(XEN) r15: 82d0802dfd7c   cr0: 80050033   cr4: 001526f0
(XEN) cr3: 0004134cf000   cr2: 8800092472b0
(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
(XEN) Xen stack trace from rsp=82d0802dfac8:
(XEN)0001 0010 82d080178660 
(XEN)82d0802dfb00 0004f0f8 82d0802dfd7c 
(XEN)0046   d5fe32f6
(XEN)  c1e87000 fffe
(XEN)82d0802d8000 82d080233a1d  c1e87000
(XEN)001526f0 82d0802339fd 0061 
(XEN)fffe 82d0801958dd 82d0802d8000 
(XEN)82d0802f7800  82d0802dfdc8 82d0802f7800
(XEN) 82d080195a1b 0067 82d080128f94
(XEN)0008 82d0802dfc78 82d080289780 82d08017f329
(XEN)00fc083c3a60 82d0802dfdc8  00fb8000
(XEN)0008 0046 0008 82d080301040
(XEN)82d080289780 82d0802dfdc8 82d0802f7800 
(XEN)82d0802dfd7c 82d0801772f7 82d0802dfd7c 
(XEN)82d0802f7800 82d0802dfdc8 82d080289780 82d080301040
(XEN)0022ebb099f2 82d080322ab0 0002 00082b337202
(XEN)00c1 0002 03fa 0002
(XEN)82d080301040 00fb 82d08013fa0f e008
(XEN)0206 82d0802dfd20  82d08013fba1
(XEN)0004 82d08012b96e 82d0802dfdc8 82d080301080
(XEN) Xen call trace:
(XEN)[] d5fd8412
(XEN)[] io_apic_write+0/0x70
(XEN)[] efi_reset_system+0x2d/0x60
(XEN)[] efi_reset_system+0xd/0x60
(XEN)[] machine_restart+0xbd/0x1f0
(XEN)[] __machine_restart+0xb/0x10
(XEN)[] smp_call_function_interrupt+0x64/0xa0
(XEN)[] do_IRQ+0x279/0x6b0
(XEN)[] common_interrupt+0x57/0x60
(XEN)[] ns_read_reg+0x4f/0x50
(XEN)[] ns16550_interrupt+0x31/0x80
(XEN)[] add_entry+0x4e/0xb0
(XEN)[] do_IRQ+0x337/0x6b0
(XEN)[] common_interrupt+0x57/0x60
(XEN)[] mwait_idle+0x222/0x370
(XEN)[] idle_loop+0x26/0x60
(XEN) 
(XEN) 
(XEN) 
(XEN) Panic on CPU 0:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=]
(XEN) 
(XEN) 
(XEN) ...

or (Xen 4.5):

(XEN) Domain 0 shutdown: rebooting machine.
(XEN) [ Xen-4.5.0-rc-lK  x86_64  debug=y  Tainted:C ]
(XEN) CPU:0
(XEN) RIP:e008:[] d5fd83d0
(XEN) RFLAGS: 00010246   CONTEXT: hypervisor
(XEN) rax: c2e1a990   rbx:    rcx: 0002
(XEN) rdx: d5fd89b0   rsi:    rdi: 
(XEN) rbp:    rsp: 82d080457aa8   r8:  
(XEN) r9:  82d080457ad8   r10: 82d0802a1270   r11: 002580dbb411
(XEN) r12:    r13: 00fb   r14: 0061
(XEN) r15:    cr0: 80050033   cr4: 001526f0
(XEN) cr3: 000413479000   cr2: 8803e800e4f0
(XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
(XEN) Xen stack trace from rsp=82d080457aa8:
(XEN)82d080457ab8 82d08017c007 82d080457ae8 82d08017d1ef
(XEN)82d080457ae0 0092  0286
(XEN)82d080457b18 0206  d5fe32f6
(XEN)  82d080457b48 82d08024582c
(XEN) 82d080245ad4 c1eb4000 82d080457b68
(XEN)00152670 82d080245aa4  82d080457c78
(XEN)82d080457bb8 82d080198dc5 82d080457bc0 80457b90
(XEN)82d080198f38   82d080457c78
(XEN)00fb 

Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported

[Ian Campbell]

On Mon, 2015-01-05 at 15:35 +, Andrew Cooper wrote:
> Answering out-of-order
> 
> This patch has no functional change WRT PVH.  The hunk commented on is
> simply changed via indentation due to the removal of the conditional it
> is in.  It was never been possible for a PVH kernel boot with
> "!XENFEAT_supervisor_mode_kernel" in its feature string.

Oh, good!

> If retcon'ing this feature flag is acceptable then the problem goes
> away, as can the commented hunk.  However, given the meaning of the
> flag, it really should be advertised to plain HVM guests as well,
> because their kernel does run in ring0.  At that point, it becomes more
> of a general "running in an hvm container" flag.

Conversely one could argue that it is a PV* only feature which makes no
sense to an HVM guest (which I think is approximately what it means now)

> What usecase was supervisor_mode_kernel developed for?  It seems
> counter-intuitive, but I can't find anything in the history explaining
> its use.

It was a prototype from the pre-pvops days to see if it would be
feasible to have a single kernel binary which ran either on Xen or on a
stub hypervisor which ran it "as native" with little or no loss of
performance^TM (e.g. for distro's convenience to avoid the multiple
kernel issue).

It never went beyond a prototype with Xen proper instead of the proposed
stub hypervisor and then pvops came along and was a much more sensible
idea...

Ian.


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

[Xen-devel] [PATCH OSSTEST v3] ts-libvirt-build: use Osstest::BuildSupport::submodulefixup

[Ian Campbell]

Instead of cloning gnulib manually which can break if upstream gnulib
gets ahead of libvirt.git (which applies patches on the fly etc). By
using submodulefixup we automatically DTRT and use the version of
gnulib specified by the libvirt.git submodule metadata, but with a
runvar override if necessary.

This also removes a whole bunch of faffing in ap-*, cr-daily-branch
and mfi-common to get the version of gnulib to use, which was always a
bit of a wart (ungated for one thing...).

We continue to use --no-git and GNULIB_SRCDIR because otherwise
autogen.sh (via bootstrap) will force its own version, overwriting
what submodulefixup has done. For this we need a way to get the hash
representing the module, so introduce submodule_find (and rework
submodule_have in terms of it).

Tested in standalone mode with build-amd64-libvirt and
build-amd64-rumpuserxen (because I touched submodule_have, AFAICT the
bodges were not run). The libvirt build was tested both with the
automatic revisions and with:
revision_libvirt=2360fe5d24175835d3f5fd1c7e8e6e13addab629
revision_libvirt_gnulib=16518d9ed8f25d3e53931dd1aa343072933e4604
(used in successful libvirt flight 32648), in both cases confirming
that the build used the desired versions.

Signed-off-by: Ian Campbell 
---
v2: Honour revision_libvirt_gnulib.
v3: Fix submodule_have, defined(&sub) is always true because defined
is special wrt &sub.
---
 Osstest/BuildSupport.pm | 13 ++---
 ap-common   |  3 ---
 ap-fetch-version|  4 
 ap-fetch-version-old|  4 
 ap-print-url|  3 ---
 ap-push |  5 -
 cr-daily-branch |  4 
 mfi-common  |  1 -
 ts-libvirt-build| 20 +++-
 9 files changed, 21 insertions(+), 36 deletions(-)

diff --git a/Osstest/BuildSupport.pm b/Osstest/BuildSupport.pm
index 874e27e..933f6e1 100644
--- a/Osstest/BuildSupport.pm
+++ b/Osstest/BuildSupport.pm
@@ -43,7 +43,7 @@ BEGIN {
   xendist
   $xendist
 
-  submodulefixup submodule_have
+  submodulefixup submodule_have submodule_find
 
   );
 %EXPORT_TAGS = ( );
@@ -145,9 +145,16 @@ sub submodulefixup () {
 return \@submodules;
 }
 
-sub submodule_have ($$) {
+sub submodule_find ($$) {
 my ($submodules, $ourname) = @_;
-return !!grep { $_->{OurName} eq $ourname } @$submodules;
+my @submods = grep { $_->{OurName} eq $ourname } @$submodules;
+return undef unless @submods;
+die "more than one $ourname?" if @submods ne 1;
+return $submods[0];
+}
+
+sub submodule_have ($$) {
+return !!&submodule_find;
 }
 
 1;
diff --git a/ap-common b/ap-common
index ff50754..96cbd14 100644
--- a/ap-common
+++ b/ap-common
@@ -37,8 +37,6 @@
 : ${PUSH_TREE_LIBVIRT:=$XENBITS:/home/xen/git/libvirt.git}
 : ${BASE_TREE_LIBVIRT:=git://xenbits.xen.org/libvirt.git}
 
-: ${TREE_GNULIB_LIBVIRT:=$(besteffort_repo git://git.sv.gnu.org/gnulib.git)}
-
 : ${TREE_RUMPUSERXEN:=https://github.com/rumpkernel/rumprun-xen}
 : ${TREEVCS_RUMPUSERXEN:=git}
 : ${BASE_TREE_RUMPUSERXEN:=git://xenbits.xen.org/rumpuser-xen.git}
@@ -77,7 +75,6 @@ fi
 : ${LOCALREV_XEN:=daily-cron.$branch}
 : ${LOCALREV_LINUX:=daily-cron.$branch}
 : ${LOCALREV_LIBVIRT:=daily-cron.$branch}
-: ${LOCALREV_GNULIB_LIBVIRT:=daily-cron.$branch}
 : ${LOCALREV_RUMPUSERXEN:=daily-cron.$branch}
 : ${LOCALREV_SEABIOS:=daily-cron.$branch}
 
diff --git a/ap-fetch-version b/ap-fetch-version
index 9c189b4..f6c65d8 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -77,10 +77,6 @@ libvirt)
repo_tree_rev_fetch_git libvirt \
$TREE_LIBVIRT master $LOCALREV_LIBVIRT
;;
-gnulib-libvirt)
-   repo_tree_rev_fetch_git gnulib-libvirt \
-   $TREE_GNULIB_LIBVIRT master $LOCALREV_GNULIB_LIBVIRT
-   ;;
 rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$TREE_RUMPUSERXEN master $LOCALREV_RUMPUSERXEN
diff --git a/ap-fetch-version-old b/ap-fetch-version-old
index f3cf339..43c997c 100755
--- a/ap-fetch-version-old
+++ b/ap-fetch-version-old
@@ -88,10 +88,6 @@ rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$BASE_TREE_RUMPUSERXEN xen-tested-master 
$BASE_LOCALREV_RUMPUSERXEN
;;
-gnulib-libvirt)
-   # No push gate, same as ap-fetch-version
-   ./ap-fetch-version $branch
-   ;;
 seabios)
repo_tree_rev_fetch_git seabios \
$BASE_TREE_SEABIOS xen-tested-master $BASE_LOCALREV_SEABIOS
diff --git a/ap-print-url b/ap-print-url
index a14d2a6..7b27e1e 100755
--- a/ap-print-url
+++ b/ap-print-url
@@ -52,9 +52,6 @@ linuxfirmware)
 libvirt)
echo $TREE_LIBVIRT
;;
-gnulib-libvirt)
-   echo $TREE_GNULIB_LIBVIRT
-   ;;
 rumpuserxen)
echo $TREE_RUMPUSERXEN
;;
diff --git a/ap-push b/ap-push
index 9df900a..a2aa747 100755
--- a/ap-push
+++ b/ap-push
@@ -88,11 +88,6 @@ rumpuserxen)
cd 

Re: [Xen-devel] [PATCH v2] x86/xen: avoid freeing static 'name' when kasprintf() fails

[Laszlo Ersek]

On 01/05/15 16:27, Vitaly Kuznetsov wrote:
> In case kasprintf() fails in xen_setup_timer() we assign name to the static
> string "". We, however, don't check that fact before
> issuing kfree() in xen_teardown_timer(), kernel is supposed to crash with
> 'kernel BUG at mm/slub.c:3341!'
> 
> Solve the issue by making name a fixed length string inside struct
> xen_clock_event_device. 16 bytes should be enough.
> 
> Suggested-by: Laszlo Ersek 
> Signed-off-by: Vitaly Kuznetsov 
> ---
> Changes from v1 (David Vrabel):
> - add 'struct xen_clock_event_device *xevt' for covenience
> - sizeof(xevt->name) in snprintf() call
> - Suggested-by: Laszlo Ersek
> ---
>  arch/x86/xen/time.c | 16 +---
>  1 file changed, 5 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index f473d26..9f743f4 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -391,7 +391,7 @@ static const struct clock_event_device *xen_clockevent =
>  
>  struct xen_clock_event_device {
>   struct clock_event_device evt;
> - char *name;
> + char name[16];
>  };
>  static DEFINE_PER_CPU(struct xen_clock_event_device, xen_clock_events) = { 
> .evt.irq = -1 };
>  
> @@ -420,39 +420,33 @@ void xen_teardown_timer(int cpu)
>   if (evt->irq >= 0) {
>   unbind_from_irqhandler(evt->irq, NULL);
>   evt->irq = -1;
> - kfree(per_cpu(xen_clock_events, cpu).name);
> - per_cpu(xen_clock_events, cpu).name = NULL;
>   }
>  }
>  
>  void xen_setup_timer(int cpu)
>  {
> - char *name;
> - struct clock_event_device *evt;
> + struct xen_clock_event_device *xevt = &per_cpu(xen_clock_events, cpu);
> + struct clock_event_device *evt = &xevt->evt;
>   int irq;
>  
> - evt = &per_cpu(xen_clock_events, cpu).evt;
>   WARN(evt->irq >= 0, "IRQ%d for CPU%d is already allocated\n", evt->irq, 
> cpu);
>   if (evt->irq >= 0)
>   xen_teardown_timer(cpu);
>  
>   printk(KERN_INFO "installing Xen timer for CPU %d\n", cpu);
>  
> - name = kasprintf(GFP_KERNEL, "timer%d", cpu);
> - if (!name)
> - name = "";
> + snprintf(xevt->name, sizeof(xevt->name), "timer%d", cpu);
>  
>   irq = bind_virq_to_irqhandler(VIRQ_TIMER, cpu, xen_timer_interrupt,
> IRQF_PERCPU|IRQF_NOBALANCING|IRQF_TIMER|
> IRQF_FORCE_RESUME|IRQF_EARLY_RESUME,
> -   name, NULL);
> +   xevt->name, NULL);
>   (void)xen_set_irq_priority(irq, XEN_IRQ_PRIORITY_MAX);
>  
>   memcpy(evt, xen_clockevent, sizeof(*evt));
>  
>   evt->cpumask = cpumask_of(cpu);
>   evt->irq = irq;
> - per_cpu(xen_clock_events, cpu).name = name;
>  }
>  
>  
> 

Looks good to me (but I defer to Xen people of course :))

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

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

Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported

[Andrew Cooper]

On 05/01/15 15:16, Ian Campbell wrote:
> On Fri, 2015-01-02 at 19:12 +, Andrew Cooper wrote:
>> supervisor_mode_kernel was an x86_32-only feature which permitted a PV dom0 
>> to
>> run in ring 0, but at the expense of not being able to start any domUs.
>>
>> As the x86_32 Xen build has been removed from tree, removing the remaining
>> supervisor_mode_kernel code.
>>
>> Signed-off-by: Andrew Cooper 
>> CC: Keir Fraser 
>> CC: Jan Beulich 
>> CC: Ian Campbell 
>> CC: Stefano Stabellini 
>> CC: Tim Deegan 
>>
>> ---
>>
>> One complication is that PVH has reused XENFEAT_supervisor_mode_kernel with a
>> modified meaning, and the Linux PVH code actively uses the flag as to 
>> indicate
>> running as a PVH guest.
> What is the modification? Doesn't a PVH kernel just use it to indicate
> that it should (or wants) run in ring0 instead of ring1/ring3? That was
> the original intention IIRC.
>
> Regardless, supervisor_mode_kernel was never anything more than a
> prototype, I'm pretty certain there can be no kernels out there relying
> on it, so rather than breaking pvh dom0 as you seem to do here I think
> it would be better to retcon the meaning of the flag as needed.
>
>> This causes an discontinuity between PVH and HVM guests, both of which run
>> their kernels with the PVH-taken meaning of XENFEAT_supervisor_mode_kernel.
>>
>> It also means that a dom0 kernel is unable to express "PVH-only" by requiring
>> this feature, as a 64bit Xen will validly reject an attempt to require a
>> 32bit-only Xen feature.
> I wouldn't describe XENFEAT_supervisor_mode_kernel as a "32-bit only Xen
> feature". It was only ever implemented for 32-bit, but conceptually it
> isn't specific to 32-bit but to any setup where PV requires you to run
> the kernel at a lower then normal privilege level.

Answering out-of-order

This patch has no functional change WRT PVH.  The hunk commented on is
simply changed via indentation due to the removal of the conditional it
is in.  It was never been possible for a PVH kernel boot with
"!XENFEAT_supervisor_mode_kernel" in its feature string.

If retcon'ing this feature flag is acceptable then the problem goes
away, as can the commented hunk.  However, given the meaning of the
flag, it really should be advertised to plain HVM guests as well,
because their kernel does run in ring0.  At that point, it becomes more
of a general "running in an hvm container" flag.

What usecase was supervisor_mode_kernel developed for?  It seems
counter-intuitive, but I can't find anything in the history explaining
its use.

~Andrew


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

[Xen-devel] [PATCH v2] x86/xen: avoid freeing static 'name' when kasprintf() fails

[Vitaly Kuznetsov]

In case kasprintf() fails in xen_setup_timer() we assign name to the static
string "". We, however, don't check that fact before
issuing kfree() in xen_teardown_timer(), kernel is supposed to crash with
'kernel BUG at mm/slub.c:3341!'

Solve the issue by making name a fixed length string inside struct
xen_clock_event_device. 16 bytes should be enough.

Suggested-by: Laszlo Ersek 
Signed-off-by: Vitaly Kuznetsov 
---
Changes from v1 (David Vrabel):
- add 'struct xen_clock_event_device *xevt' for covenience
- sizeof(xevt->name) in snprintf() call
- Suggested-by: Laszlo Ersek
---
 arch/x86/xen/time.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index f473d26..9f743f4 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -391,7 +391,7 @@ static const struct clock_event_device *xen_clockevent =
 
 struct xen_clock_event_device {
struct clock_event_device evt;
-   char *name;
+   char name[16];
 };
 static DEFINE_PER_CPU(struct xen_clock_event_device, xen_clock_events) = { 
.evt.irq = -1 };
 
@@ -420,39 +420,33 @@ void xen_teardown_timer(int cpu)
if (evt->irq >= 0) {
unbind_from_irqhandler(evt->irq, NULL);
evt->irq = -1;
-   kfree(per_cpu(xen_clock_events, cpu).name);
-   per_cpu(xen_clock_events, cpu).name = NULL;
}
 }
 
 void xen_setup_timer(int cpu)
 {
-   char *name;
-   struct clock_event_device *evt;
+   struct xen_clock_event_device *xevt = &per_cpu(xen_clock_events, cpu);
+   struct clock_event_device *evt = &xevt->evt;
int irq;
 
-   evt = &per_cpu(xen_clock_events, cpu).evt;
WARN(evt->irq >= 0, "IRQ%d for CPU%d is already allocated\n", evt->irq, 
cpu);
if (evt->irq >= 0)
xen_teardown_timer(cpu);
 
printk(KERN_INFO "installing Xen timer for CPU %d\n", cpu);
 
-   name = kasprintf(GFP_KERNEL, "timer%d", cpu);
-   if (!name)
-   name = "";
+   snprintf(xevt->name, sizeof(xevt->name), "timer%d", cpu);
 
irq = bind_virq_to_irqhandler(VIRQ_TIMER, cpu, xen_timer_interrupt,
  IRQF_PERCPU|IRQF_NOBALANCING|IRQF_TIMER|
  IRQF_FORCE_RESUME|IRQF_EARLY_RESUME,
- name, NULL);
+ xevt->name, NULL);
(void)xen_set_irq_priority(irq, XEN_IRQ_PRIORITY_MAX);
 
memcpy(evt, xen_clockevent, sizeof(*evt));
 
evt->cpumask = cpumask_of(cpu);
evt->irq = irq;
-   per_cpu(xen_clock_events, cpu).name = name;
 }
 
 
-- 
1.9.3


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

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

[Marcelo Tosatti]

On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
> The pvclock vdso code was too abstracted to understand easily and
> excessively paranoid.  Simplify it for a huge speedup.
> 
> This opens the door for additional simplifications, as the vdso no
> longer accesses the pvti for any vcpu other than vcpu 0.
> 
> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
> With this change, it takes 19ns, which is almost as fast as the pure TSC
> implementation.
> 
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/vdso/vclock_gettime.c | 82 
> --
>  1 file changed, 47 insertions(+), 35 deletions(-)
> 
> diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
> index 9793322751e0..f2e0396d5629 100644
> --- a/arch/x86/vdso/vclock_gettime.c
> +++ b/arch/x86/vdso/vclock_gettime.c
> @@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info 
> *get_pvti(int cpu)
>  
>  static notrace cycle_t vread_pvclock(int *mode)
>  {
> - const struct pvclock_vsyscall_time_info *pvti;
> + const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>   cycle_t ret;
> - u64 last;
> - u32 version;
> - u8 flags;
> - unsigned cpu, cpu1;
> -
> + u64 tsc, pvti_tsc;
> + u64 last, delta, pvti_system_time;
> + u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>  
>   /*
> -  * Note: hypervisor must guarantee that:
> -  * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
> -  * 2. that per-CPU pvclock time info is updated if the
> -  *underlying CPU changes.
> -  * 3. that version is increased whenever underlying CPU
> -  *changes.
> +  * Note: The kernel and hypervisor must guarantee that cpu ID
> +  * number maps 1:1 to per-CPU pvclock time info.
> +  *
> +  * Because the hypervisor is entirely unaware of guest userspace
> +  * preemption, it cannot guarantee that per-CPU pvclock time
> +  * info is updated if the underlying CPU changes or that that
> +  * version is increased whenever underlying CPU changes.
> +  *
> +  * On KVM, we are guaranteed that pvti updates for any vCPU are
> +  * atomic as seen by *all* vCPUs.  This is an even stronger
> +  * guarantee than we get with a normal seqlock.
>*
> +  * On Xen, we don't appear to have that guarantee, but Xen still
> +  * supplies a valid seqlock using the version field.
> +
> +  * We only do pvclock vdso timing at all if
> +  * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
> +  * mean that all vCPUs have matching pvti and that the TSC is
> +  * synced, so we can just look at vCPU 0's pvti.
>*/

Can Xen guarantee that ?

> - do {
> - cpu = __getcpu() & VGETCPU_CPU_MASK;
> - /* TODO: We can put vcpu id into higher bits of pvti.version.
> -  * This will save a couple of cycles by getting rid of
> -  * __getcpu() calls (Gleb).
> -  */
> -
> - pvti = get_pvti(cpu);
> -
> - version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
> -
> - /*
> -  * Test we're still on the cpu as well as the version.
> -  * We could have been migrated just after the first
> -  * vgetcpu but before fetching the version, so we
> -  * wouldn't notice a version change.
> -  */
> - cpu1 = __getcpu() & VGETCPU_CPU_MASK;
> - } while (unlikely(cpu != cpu1 ||
> -   (pvti->pvti.version & 1) ||
> -   pvti->pvti.version != version));
> -
> - if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
> +
> + if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>   *mode = VCLOCK_NONE;
> + return 0;
> + }

This check must be performed after reading a stable pvti.

> +
> + do {
> + version = pvti->version;
> +
> + /* This is also a read barrier, so we'll read version first. */
> + rdtsc_barrier();
> + tsc = __native_read_tsc();
> +
> + pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
> + pvti_tsc_shift = pvti->tsc_shift;
> + pvti_system_time = pvti->system_time;
> + pvti_tsc = pvti->tsc_timestamp;
> +
> + /* Make sure that the version double-check is last. */
> + smp_rmb();
> + } while (unlikely((version & 1) || version != pvti->version));
> +
> + delta = tsc - pvti_tsc;
> + ret = pvti_system_time +
> + pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
> + pvti_tsc_shift);

The following is possible:

1) State: all pvtis marked as PVCLOCK_TSC_STABLE_BIT.
1) Update request for all vcpus, for a TSC_STABLE_BIT -> ~TSC_STABLE_BIT
transition.
2) vCPU-1 updates its pvti with new values.
3) vCPU-0 still has not updated it

Re: [Xen-devel] patch ping

[Konrad Rzeszutek Wilk]

On Fri, Dec 19, 2014 at 01:13:41PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 19, 2014 at 01:48:18PM +, Jan Beulich wrote:
> > Konrad,
> > 
> > any word on
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01253.html
> 
> Release-Acked-by: Konrad Rzeszutek Wilk 
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01370.html
> 
> Shouldn't that have Reported-by: Sander..?
> Release-Acked-by: Konrad Rzeszutek Wilk 
> 
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01485.html
> 
> Release-Acked-by: Konrad Rzeszutek Wilk 
> > sent several days ago (there were more earlier today) for 4.5?
> > 
> > Thanks, Jan


Pushed to staging with the Release, Reviewed, Acked, etc tags applied.

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

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

Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported

[Ian Campbell]

On Fri, 2015-01-02 at 19:12 +, Andrew Cooper wrote:
> supervisor_mode_kernel was an x86_32-only feature which permitted a PV dom0 to
> run in ring 0, but at the expense of not being able to start any domUs.
> 
> As the x86_32 Xen build has been removed from tree, removing the remaining
> supervisor_mode_kernel code.
> 
> Signed-off-by: Andrew Cooper 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Ian Campbell 
> CC: Stefano Stabellini 
> CC: Tim Deegan 
> 
> ---
> 
> One complication is that PVH has reused XENFEAT_supervisor_mode_kernel with a
> modified meaning, and the Linux PVH code actively uses the flag as to indicate
> running as a PVH guest.

What is the modification? Doesn't a PVH kernel just use it to indicate
that it should (or wants) run in ring0 instead of ring1/ring3? That was
the original intention IIRC.

Regardless, supervisor_mode_kernel was never anything more than a
prototype, I'm pretty certain there can be no kernels out there relying
on it, so rather than breaking pvh dom0 as you seem to do here I think
it would be better to retcon the meaning of the flag as needed.

> This causes an discontinuity between PVH and HVM guests, both of which run
> their kernels with the PVH-taken meaning of XENFEAT_supervisor_mode_kernel.
> 
> It also means that a dom0 kernel is unable to express "PVH-only" by requiring
> this feature, as a 64bit Xen will validly reject an attempt to require a
> 32bit-only Xen feature.

I wouldn't describe XENFEAT_supervisor_mode_kernel as a "32-bit only Xen
feature". It was only ever implemented for 32-bit, but conceptually it
isn't specific to 32-bit but to any setup where PV requires you to run
the kernel at a lower then normal privilege level.

Ian.


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

[Xen-devel] [PATCH OSSTEST v2] ts-libvirt-build: use Osstest::BuildSupport::submodulefixup

[Ian Campbell]

Instead of cloning gnulib manually which can break if upstream gnulib
gets ahead of libvirt.git (which applies patches on the fly etc). By
using submodulefixup we automatically DTRT and use the version of
gnulib specified by the libvirt.git submodule metadata, but with a
runvar override if necessary.

This also removes a whole bunch of faffing in ap-*, cr-daily-branch
and mfi-common to get the version of gnulib to use, which was always a
bit of a wart (ungated for one thing...).

We continue to use --no-git and GNULIB_SRCDIR because otherwise
autogen.sh (via bootstrap) will force its own version, overwriting
what submodulefixup has done. For this we need a way to get the hash
representing the module, so introduce submodule_find (and rework
submodule_have in terms of it).

Tested in standalone mode with build-amd64-libvirt and
build-amd64-rumpuserxen (because I touched submodule_have, AFAICT the
bodges were not run). The libvirt build was tested both with the
automatic revisions and with:
revision_libvirt=2360fe5d24175835d3f5fd1c7e8e6e13addab629
revision_libvirt_gnulib=16518d9ed8f25d3e53931dd1aa343072933e4604
(used in successful libvirt flight 32648), in both cases confirming
that the build used the desired versions.

Signed-off-by: Ian Campbell 
---
v2: Honour revision_libvirt_gnulib.
---
 Osstest/BuildSupport.pm | 13 ++---
 ap-common   |  3 ---
 ap-fetch-version|  4 
 ap-fetch-version-old|  4 
 ap-print-url|  3 ---
 ap-push |  5 -
 cr-daily-branch |  4 
 mfi-common  |  1 -
 ts-libvirt-build| 20 +++-
 9 files changed, 21 insertions(+), 36 deletions(-)

diff --git a/Osstest/BuildSupport.pm b/Osstest/BuildSupport.pm
index 874e27e..c323162 100644
--- a/Osstest/BuildSupport.pm
+++ b/Osstest/BuildSupport.pm
@@ -43,7 +43,7 @@ BEGIN {
   xendist
   $xendist
 
-  submodulefixup submodule_have
+  submodulefixup submodule_have submodule_find
 
   );
 %EXPORT_TAGS = ( );
@@ -145,9 +145,16 @@ sub submodulefixup () {
 return \@submodules;
 }
 
-sub submodule_have ($$) {
+sub submodule_find ($$) {
 my ($submodules, $ourname) = @_;
-return !!grep { $_->{OurName} eq $ourname } @$submodules;
+my @submods = grep { $_->{OurName} eq $ourname } @$submodules;
+return undef unless @submods;
+die "more than one $ourname?" if @submods ne 1;
+return $submods[0];
+}
+
+sub submodule_have ($$) {
+return defined(&submodule_find);
 }
 
 1;
diff --git a/ap-common b/ap-common
index ff50754..96cbd14 100644
--- a/ap-common
+++ b/ap-common
@@ -37,8 +37,6 @@
 : ${PUSH_TREE_LIBVIRT:=$XENBITS:/home/xen/git/libvirt.git}
 : ${BASE_TREE_LIBVIRT:=git://xenbits.xen.org/libvirt.git}
 
-: ${TREE_GNULIB_LIBVIRT:=$(besteffort_repo git://git.sv.gnu.org/gnulib.git)}
-
 : ${TREE_RUMPUSERXEN:=https://github.com/rumpkernel/rumprun-xen}
 : ${TREEVCS_RUMPUSERXEN:=git}
 : ${BASE_TREE_RUMPUSERXEN:=git://xenbits.xen.org/rumpuser-xen.git}
@@ -77,7 +75,6 @@ fi
 : ${LOCALREV_XEN:=daily-cron.$branch}
 : ${LOCALREV_LINUX:=daily-cron.$branch}
 : ${LOCALREV_LIBVIRT:=daily-cron.$branch}
-: ${LOCALREV_GNULIB_LIBVIRT:=daily-cron.$branch}
 : ${LOCALREV_RUMPUSERXEN:=daily-cron.$branch}
 : ${LOCALREV_SEABIOS:=daily-cron.$branch}
 
diff --git a/ap-fetch-version b/ap-fetch-version
index 9c189b4..f6c65d8 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -77,10 +77,6 @@ libvirt)
repo_tree_rev_fetch_git libvirt \
$TREE_LIBVIRT master $LOCALREV_LIBVIRT
;;
-gnulib-libvirt)
-   repo_tree_rev_fetch_git gnulib-libvirt \
-   $TREE_GNULIB_LIBVIRT master $LOCALREV_GNULIB_LIBVIRT
-   ;;
 rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$TREE_RUMPUSERXEN master $LOCALREV_RUMPUSERXEN
diff --git a/ap-fetch-version-old b/ap-fetch-version-old
index f3cf339..43c997c 100755
--- a/ap-fetch-version-old
+++ b/ap-fetch-version-old
@@ -88,10 +88,6 @@ rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$BASE_TREE_RUMPUSERXEN xen-tested-master 
$BASE_LOCALREV_RUMPUSERXEN
;;
-gnulib-libvirt)
-   # No push gate, same as ap-fetch-version
-   ./ap-fetch-version $branch
-   ;;
 seabios)
repo_tree_rev_fetch_git seabios \
$BASE_TREE_SEABIOS xen-tested-master $BASE_LOCALREV_SEABIOS
diff --git a/ap-print-url b/ap-print-url
index a14d2a6..7b27e1e 100755
--- a/ap-print-url
+++ b/ap-print-url
@@ -52,9 +52,6 @@ linuxfirmware)
 libvirt)
echo $TREE_LIBVIRT
;;
-gnulib-libvirt)
-   echo $TREE_GNULIB_LIBVIRT
-   ;;
 rumpuserxen)
echo $TREE_RUMPUSERXEN
;;
diff --git a/ap-push b/ap-push
index 9df900a..a2aa747 100755
--- a/ap-push
+++ b/ap-push
@@ -88,11 +88,6 @@ rumpuserxen)
cd $repos/rumpuserxen
git push $TREE_RUMPUSERXEN $revision:xen-tested-master
 

Re: [Xen-devel] [PATCH for-4.5 v2] libxl: Initialise CTX->xce in domain suspend

[Ian Campbell]

On Mon, 2015-01-05 at 14:35 +, Ian Jackson wrote:
> Yang Hongyang writes ("[PATCH] xl/libxl: fix migrate/Remus regression (core 
> dumped)"):
> > When excuting xl migrate/Remus, the following error occurd:
> > [root@master xen]# xl migrate 5 slaver
> > migration target: Ready to receive domain.
> > Saving to migration stream new xl format (info 0x1/0x0/1225)
> > Loading new save file  (new xl fmt info 
> > 0x1/0x0/1225)
> >  Savefile contains xl domain config in JSON format
> > Parsing config from 
> > Segmentation fault (core dumped)
> > 
> > This is because CTX->xce is used without been initialized.
> > The bug was introduced by commit 2ffeb5d7f5d8
> > libxl: events: Deregister evtchn fd when not needed
> > which remove the initialization of xce from libxl__ctx_alloc.
> > 
> > This patch initialze the CTX->xce before use it.
> 
> Thanks.  This patch goes in the right direction, but isn't quite
> correct because it doesn't check the return value from
> libxl__ctx_evtchn_init.
> 
> Looking at this it is clear that following the on-demand
> initialisation of CTX->xce, it is normally necessary for any evtchn
> user in libxl to call libxl__ctx_evtchn_init, since they will need the
> xce for finding the right port number to pass to
> libxl__ev_evtchn_wait.
> 
> Sorry for not noticing this when I made my earlier change.
> 
> I have therefore:
>  * In the patch below, added changes to the comments to document this.
>  * Done git grep '\bxce\b' tools/libxl  and checked the other uses.
>  * Consequently, verified that the rest of the code in libxl_dom.c
>avoids using xce unless guest_evtchn.port>=0, and properly
>initialises .port to -1, so that there is no need for further calls
>to libxl__ctx_evtchn_init.
> 
> I have compiled but not executed this patch.  Yang Hongyang: can you
> please test that it fixes the bug for you ?
> 
> Konrad: this should go in 4.5 because it is a bugfix without which
> libxl may dereference NULL.
> 
> (I have also somewhat improved the English grammar in the commit
> message.)
> 
> Thanks,
> Ian.
> 
> commit 9d1cb27f5e961fd9db1c7d8381af18e33510f924
> Author: Ian Jackson 
> Date:   Mon Jan 5 14:31:00 2015 +
> 
> libxl: Initialise CTX->xce in domain suspend, as needed
> 
> When excuting xl migrate/Remus, the following error can occur:
>   [root@master xen]# xl migrate 5 slaver
>   migration target: Ready to receive domain.
>   Saving to migration stream new xl format (info 0x1/0x0/1225)
>   Loading new save file  (new xl fmt info 
> 0x1/0x0/12\
> )
>Savefile contains xl domain config in JSON format
>   Parsing config from 
>   Segmentation fault (core dumped)
> 
> This is because CTX->xce is used without been initialized.
> The bug was introduced by commit 2ffeb5d7f5d8
> libxl: events: Deregister evtchn fd when not needed
> which removed the initialization of xce from libxl__ctx_alloc.
> 
> In this patch we initialise the CTX->xce before using it.  Also, we
> adjust the doc comment for libxl__ev_evtchn_* to mention the need to
> do so.
> 
> Signed-off-by: Yang Hongyang 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 



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

Re: [Xen-devel] [PATCH for-4.5] tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ssid_label

[Wei Liu]

On Mon, Jan 05, 2015 at 02:19:58PM +, Andrew Cooper wrote:
> libxl_dominfo contains a ssid_label pointer which will have memory allocated
> for it in libxl_domain_info() if the hypervisor has CONFIG_XSM compiled.
> However, the lack of appropriate use of libxl_dominfo_{init,dispose}() will
> cause the label string to be leaked, even in success cases.
> 
> This was discovered by XenServers Coverity scanning, and are issues not
> identified by upstream Coverity Scan.
> 
> Signed-off-by: Andrew Cooper 
> CC: Ian Campbell 
> CC: Ian Jackson 

Reviewed-by : Wei Liu 

> CC: Konrad Rzeszutek Wilk 
> 
> ---
> 
> Requesting a release-exception as suggested by IanJ.  These are memory leaks
> which accumulate via the successful completion of libxl library functions (if
> XSM is enabled), which will undoubtedly cause issues for the likes of libvirt
> and xenopsd-libxl which use libxl in daemon processes.
> 
> As we are very close to the release, I have opted for the more
> obviously-correct code rather than the pragmatically better code, particularly
> in two locations where libxl_domain_info() is called in a loop, and the
> dispose()/init() pair is required to prevent leaking the allocation on each
> iteration.
> 
> All of the uses of libxl_domain_info() patched here could better be an
> xc_dominfo_getlist() which reduces the quantity of hypercalls made, and the
> amount of data transformation done behind the scenes.
> ---
>  tools/libxl/libxl.c |   26 --
>  tools/libxl/libxl_dom.c |   14 ++
>  2 files changed, 34 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 50a8928..372dd3b 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -364,6 +364,8 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,

(This function is really convoluted. :-/)

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

Re: [Xen-devel] [PATCH for-4.5 v2] libxl: Initialise CTX->xce in domain suspend

[Ian Jackson]

Yang Hongyang writes ("[PATCH] xl/libxl: fix migrate/Remus regression (core 
dumped)"):
> When excuting xl migrate/Remus, the following error occurd:
> [root@master xen]# xl migrate 5 slaver
> migration target: Ready to receive domain.
> Saving to migration stream new xl format (info 0x1/0x0/1225)
> Loading new save file  (new xl fmt info 
> 0x1/0x0/1225)
>  Savefile contains xl domain config in JSON format
> Parsing config from 
> Segmentation fault (core dumped)
> 
> This is because CTX->xce is used without been initialized.
> The bug was introduced by commit 2ffeb5d7f5d8
> libxl: events: Deregister evtchn fd when not needed
> which remove the initialization of xce from libxl__ctx_alloc.
> 
> This patch initialze the CTX->xce before use it.

Thanks.  This patch goes in the right direction, but isn't quite
correct because it doesn't check the return value from
libxl__ctx_evtchn_init.

Looking at this it is clear that following the on-demand
initialisation of CTX->xce, it is normally necessary for any evtchn
user in libxl to call libxl__ctx_evtchn_init, since they will need the
xce for finding the right port number to pass to
libxl__ev_evtchn_wait.

Sorry for not noticing this when I made my earlier change.

I have therefore:
 * In the patch below, added changes to the comments to document this.
 * Done git grep '\bxce\b' tools/libxl  and checked the other uses.
 * Consequently, verified that the rest of the code in libxl_dom.c
   avoids using xce unless guest_evtchn.port>=0, and properly
   initialises .port to -1, so that there is no need for further calls
   to libxl__ctx_evtchn_init.

I have compiled but not executed this patch.  Yang Hongyang: can you
please test that it fixes the bug for you ?

Konrad: this should go in 4.5 because it is a bugfix without which
libxl may dereference NULL.

(I have also somewhat improved the English grammar in the commit
message.)

Thanks,
Ian.

commit 9d1cb27f5e961fd9db1c7d8381af18e33510f924
Author: Ian Jackson 
Date:   Mon Jan 5 14:31:00 2015 +

libxl: Initialise CTX->xce in domain suspend, as needed

When excuting xl migrate/Remus, the following error can occur:
  [root@master xen]# xl migrate 5 slaver
  migration target: Ready to receive domain.
  Saving to migration stream new xl format (info 0x1/0x0/1225)
  Loading new save file  (new xl fmt info 
0x1/0x0/12\
)
   Savefile contains xl domain config in JSON format
  Parsing config from 
  Segmentation fault (core dumped)

This is because CTX->xce is used without been initialized.
The bug was introduced by commit 2ffeb5d7f5d8
libxl: events: Deregister evtchn fd when not needed
which removed the initialization of xce from libxl__ctx_alloc.

In this patch we initialise the CTX->xce before using it.  Also, we
adjust the doc comment for libxl__ev_evtchn_* to mention the need to
do so.

Signed-off-by: Yang Hongyang 
Signed-off-by: Ian Jackson 
Cc: Ian Campbell 
Cc: Konrad Rzeszutek Wilk 
Cc: Wei Liu 

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..94ae818 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1824,6 +1824,9 @@ void libxl__domain_suspend(libxl__egc *egc, 
libxl__domain_suspend_state *dss)
 port = xs_suspend_evtchn_port(dss->domid);
 
 if (port >= 0) {
+rc = libxl__ctx_evtchn_init(gc);
+if (rc) goto out;
+
 dss->guest_evtchn.port =
 xc_suspend_evtchn_init_exclusive(CTX->xch, CTX->xce,
   dss->domid, port, &dss->guest_evtchn_lockfd);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9695f18..6dac0f8 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -800,8 +800,10 @@ static inline int libxl__ev_xswatch_isregistered(const 
libxl__ev_xswatch *xw)
 
 /*
  * The evtchn facility is one-shot per call to libxl__ev_evtchn_wait.
- * You should call some suitable xc bind function on (or to obtain)
- * the port, then libxl__ev_evtchn_wait.
+ * You should:
+ *   Use libxl__ctx_evtchn_init to make sure CTX->xce is valid;
+ *   Call some suitable xc bind function on (or to obtain) the port;
+ *   Then call libxl__ev_evtchn_wait.
  *
  * When the event is signaled then the callback will be made, once.
  * Then you must call libxl__ev_evtchn_wait again, if desired.

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

[Xen-devel] [PATCH for-4.5] tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ssid_label

[Andrew Cooper]

libxl_dominfo contains a ssid_label pointer which will have memory allocated
for it in libxl_domain_info() if the hypervisor has CONFIG_XSM compiled.
However, the lack of appropriate use of libxl_dominfo_{init,dispose}() will
cause the label string to be leaked, even in success cases.

This was discovered by XenServers Coverity scanning, and are issues not
identified by upstream Coverity Scan.

Signed-off-by: Andrew Cooper 
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: Konrad Rzeszutek Wilk 

---

Requesting a release-exception as suggested by IanJ.  These are memory leaks
which accumulate via the successful completion of libxl library functions (if
XSM is enabled), which will undoubtedly cause issues for the likes of libvirt
and xenopsd-libxl which use libxl in daemon processes.

As we are very close to the release, I have opted for the more
obviously-correct code rather than the pragmatically better code, particularly
in two locations where libxl_domain_info() is called in a loop, and the
dispose()/init() pair is required to prevent leaking the allocation on each
iteration.

All of the uses of libxl_domain_info() patched here could better be an
xc_dominfo_getlist() which reduces the quantity of hypercalls made, and the
amount of data transformation done behind the scenes.
---
 tools/libxl/libxl.c |   26 --
 tools/libxl/libxl_dom.c |   14 ++
 2 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 50a8928..372dd3b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -364,6 +364,8 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 char *uuid;
 const char *vm_name_path;
 
+libxl_dominfo_init(&info);
+
 dom_path = libxl__xs_get_dompath(gc, domid);
 if (!dom_path) goto x_nomem;
 
@@ -481,6 +483,7 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 rc = 0;
  x_rc:
 if (our_trans) xs_transaction_end(ctx->xsh, our_trans, 1);
+libxl_dominfo_dispose(&info);
 return rc;
 
  x_fail:  rc = ERROR_FAIL;  goto x_rc;
@@ -4594,6 +4597,8 @@ static int libxl__fill_dom0_memory_info(libxl__gc *gc, 
uint32_t *target_memkb,
 libxl_ctx *ctx = libxl__gc_owner(gc);
 uint32_t free_mem_slack_kb = 0;
 
+libxl_dominfo_init(&info);
+
 retry_transaction:
 t = xs_transaction_start(ctx->xsh);
 
@@ -4626,6 +4631,8 @@ retry_transaction:
 }
 }
 
+libxl_dominfo_dispose(&info);
+libxl_dominfo_init(&info);
 rc = libxl_domain_info(ctx, &info, 0);
 if (rc < 0)
 goto out;
@@ -4664,7 +4671,7 @@ out:
 rc = ERROR_FAIL;
 }
 
-
+libxl_dominfo_dispose(&info);
 return rc;
 }
 
@@ -4999,6 +5006,8 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t 
domid, int wait_secs)
 uint32_t target_memkb = 0;
 libxl_dominfo info;
 
+libxl_dominfo_init(&info);
+
 do {
 wait_secs--;
 sleep(1);
@@ -5007,9 +5016,11 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx, 
uint32_t domid, int wait_secs)
 if (rc < 0)
 goto out;
 
+libxl_dominfo_dispose(&info);
+libxl_dominfo_init(&info);
 rc = libxl_domain_info(ctx, &info, domid);
 if (rc < 0)
-return rc;
+goto out;
 } while (wait_secs > 0 && (info.current_memkb + info.outstanding_memkb) > 
target_memkb);
 
 if ((info.current_memkb + info.outstanding_memkb) <= target_memkb)
@@ -5018,6 +5029,7 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t 
domid, int wait_secs)
 rc = ERROR_FAIL;
 
 out:
+libxl_dominfo_dispose(&info);
 return rc;
 }
 
@@ -5435,6 +5447,8 @@ static int libxl__set_vcpuonline_xenstore(libxl__gc *gc, 
uint32_t domid,
 xs_transaction_t t;
 int i, rc = ERROR_FAIL;
 
+libxl_dominfo_init(&info);
+
 if (libxl_domain_info(CTX, &info, domid) < 0) {
 LOGE(ERROR, "getting domain info list");
 goto out;
@@ -5454,6 +5468,7 @@ retry_transaction:
 } else
 rc = 0;
 out:
+libxl_dominfo_dispose(&info);
 return rc;
 }
 
@@ -5463,8 +5478,11 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, 
uint32_t domid,
 libxl_dominfo info;
 int i;
 
+libxl_dominfo_init(&info);
+
 if (libxl_domain_info(CTX, &info, domid) < 0) {
 LOGE(ERROR, "getting domain info list");
+libxl_dominfo_dispose(&info);
 return ERROR_FAIL;
 }
 for (i = 0; i <= info.vcpu_max_id; i++) {
@@ -5477,6 +5495,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc, 
uint32_t domid,
 libxl__qmp_cpu_add(gc, domid, i);
 }
 }
+libxl_dominfo_dispose(&info);
 return 0;
 }
 
@@ -6569,12 +6588,15 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, 
uint32_t domid,
 /* Domain UUID */
 {
 libxl_dominfo info;
+libxl_dominfo_init(&info);
 rc = libxl_domain_info(ctx, &info, domid);
 if (rc) {
 LOG(ERROR, "fail

Re: [Xen-devel] [PATCH] x86/xen: avoid freeing static 'name' when kasprintf() fails

[Laszlo Ersek]

On 01/05/15 14:19, David Vrabel wrote:
> On 05/01/15 13:06, Vitaly Kuznetsov wrote:
>> In case kasprintf() fails in xen_setup_timer() we assign name to the static
>> string "". We, however, don't check that fact before
>> issuing kfree() in xen_teardown_timer(), kernel is supposed to crash with
>> 'kernel BUG at mm/slub.c:3341!'
>>
>> Solve the issue by making name a fixed length string inside struct
>> xen_clock_event_device. 16 bytes should be enough.
>>
>> The issue was discovered by Laszlo Ersek.
> 
> Add Reported-by: Laszlo ... tag perhaps?
> 
>> --- a/arch/x86/xen/time.c
>> +++ b/arch/x86/xen/time.c
>> @@ -391,7 +391,7 @@ static const struct clock_event_device *xen_clockevent =
>>  
>>  struct xen_clock_event_device {
>>  struct clock_event_device evt;
>> -char *name;
>> +char name[16];
>>  };
>>  static DEFINE_PER_CPU(struct xen_clock_event_device, xen_clock_events) = { 
>> .evt.irq = -1 };
>>  
>> @@ -420,14 +420,11 @@ void xen_teardown_timer(int cpu)
>>  if (evt->irq >= 0) {
>>  unbind_from_irqhandler(evt->irq, NULL);
>>  evt->irq = -1;
>> -kfree(per_cpu(xen_clock_events, cpu).name);
>> -per_cpu(xen_clock_events, cpu).name = NULL;
>>  }
>>  }
>>  
>>  void xen_setup_timer(int cpu)
>>  {
>> -char *name;
>>  struct clock_event_device *evt;
> 
> struct xen_clock_event_device *xevt = ...;
> 
>>  int irq;
>>  
>> @@ -438,21 +435,19 @@ void xen_setup_timer(int cpu)
>>  
>>  printk(KERN_INFO "installing Xen timer for CPU %d\n", cpu);
>>  
>> -name = kasprintf(GFP_KERNEL, "timer%d", cpu);
>> -if (!name)
>> -name = "";
>> +snprintf(per_cpu(xen_clock_events, cpu).name, 16, "timer%d", cpu);
> 
> Use sizeof(xevt->name) here.

Yes, I wanted to recommend sizeof too.

Also the "standard" Reported-by tag would be nice.

Thanks!
Laszlo


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

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

[xen . org]

flight 33112 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33112/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33083

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass

version targeted for testing:
 xen  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen  36174af3fbeb1b662c0eadbfa193e77f68cc955b

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-xl-credit2

Re: [Xen-devel] [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual machine

[Ian Campbell]

On Mon, 2015-01-05 at 13:18 +, Wei Liu wrote:
> FWIW in the future please configure git to chain all your patches to one
> thread. :-)
> 
> What I usually do is to
> 
> git format-patch HEAD~NNN --cover --subject-prefix='PATCH vXX'
> ... edit -cover-letter.patch ...
> git send-email --to xen-devel@ --cc XXX
> 
> All patches will be chained to 00/00 cover letter.

FWIW I author 00/NN in my regular MUA then:
git format-patch HEAD~NNN --in-reply-to='' 
--subject-prefix='PATCH vXX'

But the affect is the same I think.

Ian.


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