[Xen-devel] [xen-4.5-testing baseline-only test] 38118: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  21 guest-start/debian.repeat fail REGR. vs. 38021

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 38021
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10  fail like 38021
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate.2 fail like 
38021

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  0297baf5b5b6724e006e76124969204dacfb
baseline version:
 xen  bbbd29a25d090f1180d14210358c6d7ccdebef85

Last test of basis38021  2015-09-22 18:25:16 Z   10 days
Testing same since38118  2015-10-02 12:55:22 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Kouya Shimura 
  Stefano Stabellini 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd   

[Xen-devel] [PATCH 1/2] MAINTAINERS: adding myself as co-maintainer of scheduling.

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
---
 MAINTAINERS |1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f008a8c..b612e06 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -287,6 +287,7 @@ F:  xen/common/sched_rt.c
 
 SCHEDULING
 M: George Dunlap 
+M: Dario Faggioli 
 S: Supported
 F: xen/common/sched*
 


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

[Xen-devel] [PATCH 0/2] Co-maintaining scheduling and cpupools

[Dario Faggioli]

Hi everyone,

I've been rather active on scheduling and cpupools lately, and I plan to
continue to do so (I've lost of ideas in mind :-D).

I think I gained good confidence with these subsystems work, and I'd like to
step up for helping George and Juergen (co-)maintaining them.

Regards,
Dario
---
Dario Faggioli (2):
  MAINTAINERS: adding myself as co-maintainer of scheduling.
  MAINTAINERS: adding myself as co-maintainer of cpupools.

 MAINTAINERS |2 ++
 1 file changed, 2 insertions(+)
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

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

[Xen-devel] [PATCH 2/2] MAINTAINERS: adding myself as co-maintainer of cpupools.

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Cc: Juergen Gross 
---
 MAINTAINERS |1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b612e06..902a28a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -145,6 +145,7 @@ F:  xen/arch/arm/gic-hip04.c
 
 CPU POOLS
 M: Juergen Gross 
+M: Dario Faggioli 
 S: Supported
 F: xen/common/cpupool.c
 


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

Re: [Xen-devel] RFC: change to 6 months release cycle

[Dario Faggioli]

On Fri, 2015-10-02 at 18:43 +0100, Wei Liu wrote:

> # Proposed release cycle
> 
> Aim for 6 months release cycle -- 4 months development period, 2
> months hardening period. Make two releases per year.
> 
> Fixed hard cut-off date, no more freeze exception. Arrange RCs
> immediately after cut-off.
> 
> Take into account holiday seasons in US, Europe and China, the two
> cut-off dates are the Fridays in which that last day of March and
> September are in.

> Comments are welcome!
> 
+1

I do like a lot the fact that this, as Wei mentioned, gives us the
chance to (at least potentially) deliver new features and improvements
much faster/more frequent to downstreams and end users.

Also, I think the idea of code and feature freeze, with freeze
exceptions, was a good idea, and served us well for the first couple of
releases for which it's been in effect. However, lately, maybe also
because of changes/evolution of the project and the community, it has
IMO shown its limits, and did cause issues, so I'd really love ditching
that.

Regards,
Dario

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



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

Re: [Xen-devel] [OSSTEST PATCH v3 0/3] Test case for cpupools

[Dario Faggioli]

Cc-ing people I wanted to Cc in the first place, and...

On Sat, 2015-10-03 at 02:39 +0200, Dario Faggioli wrote:
> Hey,
>
> [...]
>
> What I drafted was right that kind (or so it looks to me) of host
> properties,
> but meant at standalone mode, and I did it like in the attached
> patch... Any
> thoughts on this?
> 
Actually attaching the patch! :-)

Sorry for the mess,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

commit ee4834c6d7200ee23cfc9756bdfd28916b0884c9
Author: Dario Faggioli 
Date:   Thu Oct 30 18:10:21 2014 +0100

Osstest/TestSupport.pm: read hosts' hardware characteristics

if defined, in the form of host properties. In standalone
mode, that should happen via the config file.

Methods are introduced to read those host properties or,
if they are not defined, to fetch the information by
querying the host directly.

The host properties always take precedence. This means
that, if they're defined, no command is run on the host,
and the values stored in the properties are used.

This commit also introduces a simple bash script that,
if run on the host, retrieves and prints such host
hardware properties, for convenience and/or testing.

Signed-off-by: Dario Faggioli 
Cc: Wei Liu 
Cc: Ian Campbell 
Cc: Ian Jackson 

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 7cc5be6..251668a 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -58,7 +58,7 @@ BEGIN {
   target_put_guest_image target_editfile
   target_editfile_root target_file_exists
   target_catfile_stash target_catfile_root_stash
-  target_run_apt
+  target_file_contains target_run_apt
   target_install_packages target_install_packages_norec
   target_jobdir target_extract_jobdistpath_subdir
   target_extract_jobdistpath target_guest_lv_name
@@ -67,6 +67,7 @@ BEGIN {
   contents_make_cpio file_simple_write_contents
 
   selecthost get_hostflags get_host_property
+  get_host_cpus get_host_numanodes get_host_memory
   get_host_native_linux_console
   power_state power_cycle power_cycle_time
   serial_fetch_logs
@@ -519,6 +520,15 @@ sub target_file_exists ($$) {
 die "$rfile $out ?";
 }
 
+sub target_file_contains ($$$) {
+  my ($ho,$rfile,$filecont) = @_;
+  return 0 unless target_file_exists($ho,$rfile);
+  my $out= target_cmd_output($ho, "grep $filecont $rfile");
+  return 1 if ($out ne "");
+  return 0 if ($out eq "");
+  die "$rfile $filecont $out ?";
+}
+
 sub teditfileex {
 my $user= shift @_;
 my $code= pop @_;
@@ -866,6 +876,11 @@ sub selecthost ($) {
 }
 $ho->{Ip}= $ho->{IpStatic};
 
+#- HW specs -
+$ho->{Cpus} = get_host_property($ho,'cpus');
+$ho->{Memory} = get_host_property($ho,'memory');
+$ho->{Nodes} = get_host_property($ho,'nodes');
+
 #- tftp -
 
 my $tftpscope = get_host_property($ho, 'TftpScope', $c{TftpDefaultScope});
@@ -937,6 +952,66 @@ sub get_host_method_object ($$$) {
 return $mo;
 }
 
+sub get_host_cpus ($) {
+my ($ho) = @_;
+
+# Let's first try if there's an host property defined;
+# if no, we'll "ask" the host directly.
+my $cpus= get_host_property($ho,'cpus',undef);
+return $cpus if defined $cpus;
+
+# Is the host running Dom0 or baremetal?
+if (target_file_contains($ho,"/proc/xen/capabilities","control_d")) {
+$cpus= target_cmd_output_root($ho,
+"xl info | grep ^nr_cpus | awk '{print \$3}'");
+} else {
+$cpus= target_cmd_output_root($ho,
+"cat /proc/cpuinfo | grep '^processor' | wc -l");
+}
+
+return $cpus;
+}
+
+sub get_host_numanodes ($) {
+my ($ho) = @_;
+
+# Let's first try if there's an host property defined;
+# if no, we'll "ask" the host directly.
+my $nodes= get_host_property($ho,'nodes',undef);
+return $nodes if defined $nodes;
+
+# Is the host running Dom0 or baremetal?
+if (target_file_contains($ho,"/proc/xen/capabilities","control_d")) {
+$nodes= target_cmd_output_root($ho,
+"xl info | grep ^nr_nodes | awk '{print \$3}'");
+} else {
+$nodes= target_cmd_output_root($ho,
+"which numactl && numactl --hardware | grep ^available: | awk 
'{print \$2}'");
+}
+
+return $nodes;
+}
+
+sub get_host_memory ($) {
+my ($ho) = @_;
+
+# Let's first try if there's an host property defined;
+# if no, we'll "ask" the host directly.
+my $mem= get_host_property($ho,'memory',undef);
+return $mem if defined $mem;
+
+# Is the h

[Xen-devel] [OSSTEST PATCH v3 3/3] ts-logs-capture: include some cpupools info in the captured logs.

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Juergen Gross 
---
Changes from v2:
 * new patch, the introduction of which was suggested
   during review.
---
 ts-logs-capture |2 ++
 1 file changed, 2 insertions(+)

diff --git a/ts-logs-capture b/ts-logs-capture
index b99b1db..b1e7012 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -186,6 +186,8 @@ sub fetch_logs_host () {
  'cat /proc/cpuinfo',
  'xl list',
  'xl vcpu-list',
+ 'xl cpupool-list',
+ 'xl cpupool-list -c',
  'xm list',
  'xm list --long',
  'xenstore-ls -fp',


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

[Xen-devel] [OSSTEST PATCH v3 2/3] Testing cpupools: recipe for it and job definition

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Juergen Gross 
---
Changes from v2:
 * restrict test generation to xl only.

Changes from v1:
 * added invocation to ts-guest-stop in the recipe to kill
   leak-check complaints (which went unnoticed during v1
   testing, sorry)
 * moved the test before the "ARM cutoff", and remove the
   per-arch filtering, so that the test can run on ARM
   hardware too
---
 make-flight |   12 
 sg-run-job  |7 +++
 2 files changed, 19 insertions(+)

diff --git a/make-flight b/make-flight
index 8c75a9c..d27a02c 100755
--- a/make-flight
+++ b/make-flight
@@ -373,6 +373,16 @@ do_multivcpu_tests () {
 $debian_runvars all_hostflags=$most_hostflags
 }
 
+do_cpupools_tests () {
+  if [ x$toolstack != xxl -a $xenarch != $dom0arch ]; then
+return
+  fi
+
+  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools\
+test-cpupools xl $xenarch $dom0arch   \
+$debian_runvars all_hostflags=$most_hostflags
+}
+
 do_passthrough_tests () {
   if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
 return
@@ -498,6 +508,8 @@ test_matrix_do_one () {
   do_rtds_tests
   do_credit2_tests
 
+  do_cpupools_tests
+
   # No further arm tests at the moment
   if [ $dom0arch = armhf ]; then
   return
diff --git a/sg-run-job b/sg-run-job
index 66145b8..ea48a03 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -296,6 +296,13 @@ proc run-job/test-debianhvm {} {
 test-guest debianhvm
 }
 
+proc need-hosts/test-cpupools {} { return host }
+proc run-job/test-cpupools {} {
+install-guest-debian
+run-ts . = ts-cpupools + host debian
+run-ts . = ts-guest-stop + host debian
+}
+
 proc setup-test-pair {} {
 run-ts . =  ts-debian-install  dst_host
 run-ts . =  ts-debian-fixupdst_host  + debian


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

[Xen-devel] [OSSTEST PATCH v3 0/3] Test case for cpupools

[Dario Faggioli]

Hey,

This is v3 of my cpupools OSSTest test case. I know, quite a few time passed...
Sorry for that, I've been sidetracked.  In fact, v2 was here:

  
http://xen-devel.narkive.com/x8VxgO3c/osstest-patch-v2-0-2-test-case-for-cpupools

Since then, I reworked the patch quite a bit. Of course, I did consider and
address the comments I got with v2.

The test case tries to create one cpupool, and then plays a bit with it, e.g.,
by moving pCPUs and domains around.  It does so for all the schedulers we
support, i.e., it creates one cpupool with one scheduler, plays with it as said
above, then destroys it and goes ahead with the next scheduler, etc.

A git branch is available here:

  git://xenbits.xen.org/people/dariof/osstest.git  tests/cpupools-v3
  
http://xenbits.xen.org/gitweb/?p=people/dariof/osstest.git;a=shortlog;h=refs/heads/tests/cpupools-v3

There are some host related considerations. In fact, this test case requires
that an host with at least 2 pCPUs is used. v2 was failing the test, if that
was not the case. Now, I'm just skipping doing pretty much everything, but I'm
not reporting failure.  In any case, while reviewing v2, IanC said:

 "The proper fix would be a property in the hostdb which was used to
  constrain which hosts the jobs containing this test could run on. (e.g.
  we have pcipassthrough-nic).

  Maybe this way is OK until we find we are commissioning a machine with a
  single CPU, at which point this failure will seem pretty obvious. Ian?"

I do like this. I, actually, even started to do this already, for other
reasons, and I am fine continuing working to make this happen, but I'd need
some help, or at least some pointers.

I've never interacted with the hostdb, so I'd appreciate pointers for knowing
where to look.

What I drafted was right that kind (or so it looks to me) of host properties,
but meant at standalone mode, and I did it like in the attached patch... Any
thoughts on this?

What I also miss, in both the cases of standalone mode config file defined
properties, and hostdb ones, it the logic for telling the host allocator to
consider such properties when choosing the host to be used for a job. I'll go
studying how to do it, but if anyone feels the irresistible need of advising,
feel free to go ahead... :-)

Thanks and Regards,
Dario
---
Dario Faggioli (3):
  ts-cpupools: new test script
  Testing cpupools: recipe for it and job definition
  ts-logs-capture: include some cpupools info in the captured logs.

 make-flight |   12 +
 sg-run-job  |7 +++
 ts-cpupools |  121 +++
 ts-logs-capture |2 +
 4 files changed, 142 insertions(+)
 create mode 100755 ts-cpupools
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

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

[Xen-devel] [OSSTEST PATCH v3 1/3] ts-cpupools: new test script

[Dario Faggioli]

for smoke testing cpupools a bit. It tries to partition
a live host in two cpupools, trying out the following 3
schedulers for the new cpupool (one after the other):
 credit, credit2 and RTDS.

It also tries to migrating a domain to the new cpupool
and then back to Pool-0.

Signed-off-by: Dario Faggioli 
---
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Juergen Gross 
---
Changes from v2:
 * reorganized internal subroutines;
 * avoid failing (just don't run the test) if we find
   only 1 pCPU on the host;
 * use 'map' and 'grep' in place of foreach loops, as
   suggested during review;
 * fix the check for the default cpupool configuration
   to be in place when starting the test, as identified
   during review;
 * fix quoting for the name of the cpupool, as idenfied
   during review;
 * use target_cmd_root(), instead of target_cmd_output_root(),
   as requested during review;
 * check for the toolstack to be xl and only xl, as
   requested during review.
---
 ts-cpupools |  121 +++
 1 file changed, 121 insertions(+)
 create mode 100755 ts-cpupools

diff --git a/ts-cpupools b/ts-cpupools
new file mode 100755
index 000..7fe9a27
--- /dev/null
+++ b/ts-cpupools
@@ -0,0 +1,121 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2014 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($ho,$gho) = ts_get_host_guest(@ARGV);
+
+our $nr_cpus;
+our $default_pool= "Pool-0";
+our @schedulers= ("credit","credit2","rtds");
+our @cpulist;
+
+# Figure out the number of pCPUs of the host. We need to know that for
+# deciding with what pCPUs we'll create the test pool.
+sub check_cpus () {
+  my $xlinfo= target_cmd_output_root($ho, "xl info");
+  $xlinfo =~ /nr_cpus\s*:\s([0-9]*)/;
+  $nr_cpus= $1;
+  logm("Found $nr_cpus pCPUs");
+  logm("$nr_cpus is yoo few pCPUs for testing cpupools");
+}
+
+# At the beginning:
+#  * only 1 pool must exist,
+#  * it must be the default pool.
+sub check () {
+  my $cppinfo= target_cmd_output_root($ho, "xl cpupool-list");
+  my $nr_cpupools= $cppinfo =~ tr/\n//;
+
+  logm("Found $nr_cpupools cpupools");
+  die "There already is more than one cpu pool!" if $nr_cpupools > 1;
+  die "Non-default cpupool configuration detected"
+  unless $cppinfo =~ /$default_pool/;
+
+  die "This test is meant for xl only"
+  if toolstack($ho)->{Name} ne "xl";
+}
+
+# Odd pCPUs will end up in out test pool
+sub prep_cpulist () {
+  @cpulist = grep { $_ % 2 } (0..$nr_cpus);
+  logm("Using the following cpus fo the test pool: @cpulist");
+}
+
+sub prep_pool ($) {
+  my ($sched)= @_;
+  my @cpustr;
+
+  my @cpustr= map { $_ == -1 ? "[ " : $_ == $#cpulist+1 ? " ]" :
+  "\"$cpulist[$_]\"," } (-1 .. $#cpulist+1);
+
+  target_putfilecontents_stash($ho,100,<<"END","/etc/xen/cpupool-test-$sched");
+name = \"cpupool-test-$sched\"
+sched = \"$sched\"
+cpus = @cpustr
+END
+}
+
+# For each cpupool:
+#  * create it
+#  * rename it
+#  * move a domain in it
+#  * move back a domain out of it
+#  * add back the pcpus from it to the default pool
+#  * destroy it
+sub run ($) {
+  my ($sched)= @_;
+
+  foreach my $cpu (@cpulist) {
+target_cmd_root($ho,"xl cpupool-cpu-remove $default_pool $cpu");
+  }
+  target_cmd_root($ho, "xl cpupool-list -c");
+  target_cmd_root($ho, "xl cpupool-create /etc/xen/cpupool-test-$sched");
+  target_cmd_root($ho, "xl cpupool-rename cpupool-test-$sched cpupool-test");
+  target_cmd_root($ho, "xl cpupool-list -c");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} cpupool-test");
+  target_cmd_root($ho, "xl cpupool-list");
+  target_cmd_root($ho, "xl vcpu-list");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} Pool-0");
+  target_cmd_root($ho, "xl cpupool-list");
+
+  foreach my $cpu (@cpulist) {
+target_cmd_root($ho,"xl cpupool-cpu-remove cpupool-test $cpu");
+target_cmd_root($ho,"xl cpupool-cpu-add $default_pool $cpu");
+  }
+  target_cmd_output_root($ho, "xl cpupool-list -c");
+
+  target_cmd_root($ho, "xl cpupool-destroy cpupool-test");
+  target_cmd_root($ho, "xl cpupool-list");
+}
+
+check();
+check_cpus();
+if ($nr_cpus > 1) {
+  prep_cpulist();
+  foreach my $s (@schedulers) {
+prep_pool("$s");
+run("$s");
+

Re: [Xen-devel] [PATCH v3 3/9] xen/blkfront: separate per ring information out of device info

[Bob Liu]

On 10/03/2015 01:02 AM, Roger Pau Monné wrote:
> El 05/09/15 a les 14.39, Bob Liu ha escrit:
>> Split per ring information to an new structure:blkfront_ring_info, also 
>> rename
>> per blkfront_info to blkfront_dev_info.
>   ^ removed.
>>
>> A ring is the representation of a hardware queue, every vbd device can 
>> associate
>> with one or more blkfront_ring_info depending on how many hardware
>> queues/rings to be used.
>>
>> This patch is a preparation for supporting real multi hardware queues/rings.
>>
>> Signed-off-by: Arianna Avanzini 
>> Signed-off-by: Bob Liu 
>> ---
>>  drivers/block/xen-blkfront.c |  854 
>> ++
>>  1 file changed, 445 insertions(+), 409 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 5dd591d..bf416d5 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -107,7 +107,7 @@ static unsigned int xen_blkif_max_ring_order;
>>  module_param_named(max_ring_page_order, xen_blkif_max_ring_order, int, 
>> S_IRUGO);
>>  MODULE_PARM_DESC(max_ring_page_order, "Maximum order of pages to be used 
>> for the shared ring");
>>  
>> -#define BLK_RING_SIZE(info) __CONST_RING_SIZE(blkif, PAGE_SIZE * 
>> (info)->nr_ring_pages)
>> +#define BLK_RING_SIZE(dinfo) __CONST_RING_SIZE(blkif, PAGE_SIZE * 
>> (dinfo)->nr_ring_pages)
> 
> This change looks pointless, any reason to use dinfo instead of info?
> 
>>  #define BLK_MAX_RING_SIZE __CONST_RING_SIZE(blkif, PAGE_SIZE * 
>> XENBUS_MAX_RING_PAGES)
>>  /*
>>   * ring-ref%i i=(-1UL) would take 11 characters + 'ring-ref' is 8, so 19
>> @@ -116,12 +116,31 @@ MODULE_PARM_DESC(max_ring_page_order, "Maximum order 
>> of pages to be used for the
>>  #define RINGREF_NAME_LEN (20)
>>  
>>  /*
>> + *  Per-ring info.
>> + *  Every blkfront device can associate with one or more blkfront_ring_info,
>> + *  depending on how many hardware queues to be used.
>> + */
>> +struct blkfront_ring_info
>> +{
>> +struct blkif_front_ring ring;
>> +unsigned int ring_ref[XENBUS_MAX_RING_PAGES];
>> +unsigned int evtchn, irq;
>> +struct work_struct work;
>> +struct gnttab_free_callback callback;
>> +struct blk_shadow shadow[BLK_MAX_RING_SIZE];
>> +struct list_head grants;
>> +struct list_head indirect_pages;
>> +unsigned int persistent_gnts_c;
> 
> persistent grants should be per-device, not per-queue IMHO. Is it really
> hard to make this global instead of per-queue?
> 

The most important thing is keep changes minimal for better review at this 
stage.
I'll check which way has the least modification.

>> +unsigned long shadow_free;
>> +struct blkfront_dev_info *dinfo;
>> +};
>> +
>> +/*
>>   * We have one of these per vbd, whether ide, scsi or 'other'.  They
>>   * hang in private_data off the gendisk structure. We may end up
>>   * putting all kinds of interesting stuff here :-)
>>   */
>> -struct blkfront_info
>> -{
>> +struct blkfront_dev_info {
> 
> IMHO, you can leave this as blkfront_info (unless I'm missing something).
> 
>>  spinlock_t io_lock;
> 
> Shouldn't the spinlock be per-queue instead of per-device?
> 

That's in another patch for better review.
'[PATCH v3 5/9] xen/blkfront: convert per device io_lock to per ring ring_lock' 
will do that.

>>  struct mutex mutex;
>>  struct xenbus_device *xbdev;
>> @@ -129,18 +148,7 @@ struct blkfront_info
>>  int vdevice;
>>  blkif_vdev_t handle;
>>  enum blkif_state connected;
>> -int ring_ref[XENBUS_MAX_RING_PAGES];
>> -unsigned int nr_ring_pages;
>> -struct blkif_front_ring ring;
>> -unsigned int evtchn, irq;
>>  struct request_queue *rq;
>> -struct work_struct work;
>> -struct gnttab_free_callback callback;
>> -struct blk_shadow shadow[BLK_MAX_RING_SIZE];
>> -struct list_head grants;
>> -struct list_head indirect_pages;
>> -unsigned int persistent_gnts_c;
>> -unsigned long shadow_free;
>>  unsigned int feature_flush;
>>  unsigned int feature_discard:1;
>>  unsigned int feature_secdiscard:1;
>> @@ -149,7 +157,9 @@ struct blkfront_info
>>  unsigned int feature_persistent:1;
>>  unsigned int max_indirect_segments;
>>  int is_ready;
>> +unsigned int nr_ring_pages;
> 
> Spurious change? You are removing it in the chunk above and adding it
> back here.
> 

Will be fix.

> [...]
> 
>> @@ -246,33 +257,33 @@ out_of_memory:
>>  }
>>  
>>  static struct grant *get_grant(grant_ref_t *gref_head,
>> -   unsigned long pfn,
>> -   struct blkfront_info *info)
>> +   unsigned long pfn,
>> +   struct blkfront_ring_info *rinfo)
> 
> Indentation? (or my email client is mangling emails one more time...)
> 

Will be fix.

> In order to make this easier to review, do you think you can leave
> blkfront_info as "info" for now, and do the renaming to dinfo in a later
> patch. That would hel

Re: [Xen-devel] [PATCH v3 2/9] xen-block: add document for mutli hardware queues/rings

[Bob Liu]

On 10/03/2015 12:22 AM, Roger Pau Monné wrote:
> El 02/10/15 a les 18.12, Wei Liu ha escrit:
>> On Fri, Oct 02, 2015 at 06:04:35PM +0200, Roger Pau Monné wrote:
>>> El 05/09/15 a les 14.39, Bob Liu ha escrit:
 Document multi queues/rings of xen-block.

 Signed-off-by: Bob Liu 
>>>
>>> As said by Konrad, you should send this against the Xen public headers
>>> also (or even before). I have a comment below.
>>>

Sure, I'll do that and also rebase this series after get more comments.

 ---
  include/xen/interface/io/blkif.h |   32 
  1 file changed, 32 insertions(+)

 diff --git a/include/xen/interface/io/blkif.h 
 b/include/xen/interface/io/blkif.h
 index c33e1c4..b453b70 100644
 --- a/include/xen/interface/io/blkif.h
 +++ b/include/xen/interface/io/blkif.h
 @@ -28,6 +28,38 @@ typedef uint16_t blkif_vdev_t;
  typedef uint64_t blkif_sector_t;
  
  /*
 + * Multiple hardware queues/rings:
 + * If supported, the backend will write the key "multi-queue-max-queues" 
 to
 + * the directory for that vbd, and set its value to the maximum supported
 + * number of queues.
 + * Frontends that are aware of this feature and wish to use it can write 
 the
 + * key "multi-queue-num-queues", set to the number they wish to use, which
 + * must be greater than zero, and no more than the value reported by the 
 backend
 + * in "multi-queue-max-queues".
 + *
 + * For frontends requesting just one queue, the usual event-channel and
 + * ring-ref keys are written as before, simplifying the backend processing
 + * to avoid distinguishing between a frontend that doesn't understand the
 + * multi-queue feature, and one that does, but requested only one queue.
 + *
 + * Frontends requesting two or more queues must not write the toplevel
 + * event-channeland ring-ref keys, instead writing those keys under 
 sub-keys
 + * having the name "queue-N" where N is the integer ID of the queue/ring 
 for
 + * which those keys belong. Queues are indexed from zero.
 + * For example, a frontend with two queues must write the following set of
 + * queue-related keys:
 + *
 + * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2"
 + * /local/domain/1/device/vbd/0/queue-0 = ""
 + * /local/domain/1/device/vbd/0/queue-0/ring-ref = ""
 + * /local/domain/1/device/vbd/0/queue-0/event-channel = ""
 + * /local/domain/1/device/vbd/0/queue-1 = ""
 + * /local/domain/1/device/vbd/0/queue-1/ring-ref = ""
 + * /local/domain/1/device/vbd/0/queue-1/event-channel = ""
>>>
>>> AFAICT, it's impossible by design to use multiple queues together with
>>> multipage rings, is that right?
>>>
>>
>> As far as I can tell, these two features are not inherently coupled.
>> Whether you want to make (by design) them coupled together or not is
>> another matter. :-)
> 
> I haven't looked at the implementation yet, but some mention of whether
> multipage-rings are allowed with multiqueue would be good. For example
> if both can indeed be used in conjunction I would mention:
> 
> If multi-page rings are also used, the format of the grant references
> will be:
> 
> /local/domain/1/device/vbd/0/queue-0/ring-ref0 = ""
> /local/domain/1/device/vbd/0/queue-0/ring-ref1 = ""
> /local/domain/1/device/vbd/0/queue-0/ring-ref2 = ""
> [...]
> 

True, and this is already supported. I'll update the document next version.

-- 
Regards,
-Bob

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 62468
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 62468
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 62468
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 62468
 test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start.2 fail REGR. vs. 62468

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-raw  6 xen-boot  fail REGR. vs. 62468
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 62468
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail REGR. vs. 62468
 test-armhf-armhf-xl-cubietruck  6 xen-boot   fail blocked in 62468
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail blocked in 62468
 test-armhf-armhf-xl-xsm   6 xen-boot fail   like 62468
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62468
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 62468
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62468

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 linuxf0378dad70c154395ffb593f1d3eca08bc249723
baseline version:
 linux097f70b3c4d84ffccca15195bdfde3a37c0a7c0f

Last test of basis  (not found) 
Failing since 0  1970-01-01 00:00:00 Z 16710 days
Testing same since62568  2015-09-30 15:14:59 Z2 days1 attempts

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

Re: [Xen-devel] [PATCH] xen:arm: use SMC64 version function id on ARM64

[Julien Grall]

Hi,

FIY, the xen-arm mailing has been removed a year ago and was only 
targeting the Xen ARM PV port.


On 02/10/2015 22:36, Brijesh Singh wrote:

On AMD Seattle, Xen failed to boot secondary CPU's. This patch fixes it.

As per PSCI spec, If CPU_ON entry_point_address is 64-bit then function id 
parameter should be set to SMC64 version (0xC403).


The line in the commit message should never go above 72 characters. 
Please split it.




Signed-off-by: Brijesh Singh 
---
  xen/arch/arm/psci.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 7ad6a43..117c6a9 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -116,7 +116,11 @@ int __init psci_init_0_2(void)
  return -EOPNOTSUPP;
  }

+#ifdef CONFIG_ARM_64
+psci_cpu_on_nr = PSCI_0_2_FN64_CPU_ON;
+#else
  psci_cpu_on_nr = PSCI_0_2_FN_CPU_ON;
+#endif


Rather than open coding the function ID in the code, I would prefer to 
introduce a define/macro similar to the Linux one (see 
drivers/firmware/psci.c) which will return the 64-bit function ID for 
ARM64 and 32-bit one for ARM32:


#ifdef CONFIG_ARM_64
#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN64_#name
#else
#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN_#name
#endif

And then:

psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON);

A comment on top for the macro would also be welcome for future 
reference explaining why.


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH] xen:arm: use SMC64 version function id on ARM64

[Brijesh Singh]

On AMD Seattle, Xen failed to boot secondary CPU's. This patch fixes it.

As per PSCI spec, If CPU_ON entry_point_address is 64-bit then function id 
parameter should be set to SMC64 version (0xC403).

Signed-off-by: Brijesh Singh 
---
 xen/arch/arm/psci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 7ad6a43..117c6a9 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -116,7 +116,11 @@ int __init psci_init_0_2(void)
 return -EOPNOTSUPP;
 }
 
+#ifdef CONFIG_ARM_64
+psci_cpu_on_nr = PSCI_0_2_FN64_CPU_ON;
+#else
 psci_cpu_on_nr = PSCI_0_2_FN_CPU_ON;
+#endif
 
 printk(XENLOG_INFO "Using PSCI-0.2 for SMP bringup\n");
 
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v7 13/32] xen/vlapic: fixes for HVM code when running without a vlapic

[Boris Ostrovsky]

On 10/02/2015 11:48 AM, Roger Pau Monne wrote:

The HVM related code (SVM, VMX) generally assumed that a local apic is
always present. With the introduction of a HVM mode were the local apic can
be removed, some of this broken code paths arised.

The SVM exit/resume paths unconditionally checked the state of the lapic,
which is wrong if it's been disabled by hardware, fix this by adding the
necessary checks. On the VMX side, make sure we don't add mappings for a
local apic if it's disabled.

In the generic vlapic code, add checks to prevent setting the TSC deadline
timer if the lapic is disabled, and also prevent trying to inject interrupts
from the PIC is the lapic is also disabled.

Signed-off-by: Roger Pau Monné 
Cc: Boris Ostrovsky 
Cc: Suravee Suthikulpanit 
Cc: Aravind Gopalakrishnan 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Eddie Dong 
Cc: Kevin Tian 
---
  xen/arch/x86/hvm/svm/svm.c | 18 ++
  xen/arch/x86/hvm/vlapic.c  |  7 ++-
  xen/arch/x86/hvm/vmx/vmx.c |  3 ++-
  3 files changed, 18 insertions(+), 10 deletions(-)




Reviewed-by: Boris Ostrovsky 

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

Re: [Xen-devel] [PATCH v7 32/32] libxl: add support for migrating HVM guests without a device model

[Andrew Cooper]

On 02/10/15 16:49, Roger Pau Monne wrote:
> Only some minor libxl changes are needed in order to be able to migrate HVM
> guests without a device model, no hypervisor changes are needed.
>
> This change prevents sending the emulator context if the device model
> version is set to none.
>
> Signed-off-by: Roger Pau Monné 
> Cc: Ian Jackson 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> ---
>  tools/libxl/libxl_dom.c  | 3 +++
>  tools/libxl/libxl_dom_suspend.c  | 2 ++
>  tools/libxl/libxl_stream_write.c | 8 +++-
>  3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 7e8ae14..b40d744 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -1310,6 +1310,9 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
>  case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
>  domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
>  break;
> +case LIBXL_DEVICE_MODEL_VERSION_NONE:
> +libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
> +break;
>  default:
>  LOG(ERROR,"logdirty switch failed"
>  ", no valid device model version found, abandoning suspend");
> diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
> index 4cc01ad..3313ad1 100644
> --- a/tools/libxl/libxl_dom_suspend.c
> +++ b/tools/libxl/libxl_dom_suspend.c
> @@ -43,6 +43,8 @@ int libxl__domain_suspend_device_model(libxl__gc *gc,
>  if (ret)
>  unlink(filename);
>  break;
> +case LIBXL_DEVICE_MODEL_VERSION_NONE:
> +break;
>  default:
>  return ERROR_INVAL;
>  }
> diff --git a/tools/libxl/libxl_stream_write.c 
> b/tools/libxl/libxl_stream_write.c
> index 52a60d7..5551560 100644
> --- a/tools/libxl/libxl_stream_write.c
> +++ b/tools/libxl/libxl_stream_write.c
> @@ -232,6 +232,9 @@ void libxl__stream_write_start(libxl__egc *egc,
>  stream->emu_sub_hdr.id = EMULATOR_QEMU_UPSTREAM;
>  break;
>  
> +case LIBXL_DEVICE_MODEL_VERSION_NONE:
> +break;
> +
>  default:
>  rc = ERROR_FAIL;
>  LOG(ERROR, "Unknown emulator for HVM domain");
> @@ -387,8 +390,11 @@ static void emulator_xenstore_record_done(libxl__egc 
> *egc,
>libxl__stream_write_state *stream)
>  {
>  libxl__domain_suspend_state *dss = stream->dss;
> +STATE_AO_GC(stream->ao);
>  
> -if (dss->type == LIBXL_DOMAIN_TYPE_HVM)
> +if (dss->type == LIBXL_DOMAIN_TYPE_HVM &&
> +libxl__device_model_version_running(gc, dss->domid) !=
> +LIBXL_DEVICE_MODEL_VERSION_NONE)
>  write_emulator_context_record(egc, stream);
>  else {
>  if (stream->in_checkpoint)

I think a few more changes are needed to make this robust.

write_emulator_xenstore_record() needs an early check for
LIBXL_DEVICE_MODEL_VERSION_NONE and omit the call to
libxl__save_emulator_xenstore_data() (which is only needed because
qemu-upstream has a layering violation in its save format)

Instead of patching emulator_xenstore_record_done(), in the hunk above,
I would suggest having another early check and continue in
write_emulator_context_record()

Also, you need to patch the EMULATOR_* cases in
libxl_stream_read.c:process_record() to bail with a hard error if
records received for a domain configured to have no emulators.

~Andrew

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

Re: [Xen-devel] [PATCH v7 23/32] xen/x86: make sure the HVM callback vector is correctly set

[Andrew Cooper]

On 02/10/15 16:48, Roger Pau Monne wrote:
> If certain devices (like the local or the io apic) are disabled some modes
> of operation of the HVM event channel callback cannot be used. Make sure Xen
> doesn't try to setup them.
>
> Signed-off-by: Roger Pau Monné 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/hvm/irq.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> index 990a2ca..0f3ab6c 100644
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -330,6 +330,10 @@ void hvm_set_callback_via(struct domain *d, uint64_t via)
>   (via_type > HVMIRQ_callback_vector) )
>  via_type = HVMIRQ_callback_none;
>  
> +if ( via_type != HVMIRQ_callback_vector &&
> + (!has_vlapic(d) || !has_vioapic(d) || !has_vpic(d)) )
> +return;

I think the logic needs to be slightly more complicated.

Without a vlapic, all callback types are invalid.

Without an ioapic/pic, _gsi and _pci_intx are invalid, but _vector is
possible.

Other issues with this area of code (not caused by you) are the fact
there is no error flagged from this setup, and that via_type is not
exposed in the Xen ABI.  Both of these should be looked into by someone
with some copious free time, but are not impediments to this patch series.

~Andrew

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

Re: [Xen-devel] [PATCH v7 13/32] xen/vlapic: fixes for HVM code when running without a vlapic

[Andrew Cooper]

On 02/10/15 16:48, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index bbec0e8..63b7a24 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2412,7 +2412,8 @@ static void vmx_install_vlapic_mapping(struct vcpu *v)
>  {
>  paddr_t virt_page_ma, apic_page_ma;
>  
> -if ( !cpu_has_vmx_virtualize_apic_accesses )
> +if ( !cpu_has_vmx_virtualize_apic_accesses ||
> + v->domain->arch.hvm_domain.vmx.apic_access_mfn == 0 )

0 is a valid (albeit very unlikely) mfn.  The unused sentinel value
should be INVALID_MFN.  It appears that all the current uses of
apic_access_mfn are buggy.


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

Re: [Xen-devel] [PATCH v7 01/32] xen/vcpu: add missing dummy_vcpu_info to compat VCPUOP_initialise

[Andrew Cooper]

On 02/10/15 16:48, Roger Pau Monne wrote:
> This check is missing from the compat version when compared to the
> non-compat version.
>
> Signed-off-by: Roger Pau Monné 
> Cc: Ian Campbell 
> Cc: Jan Beulich 
> Cc: Tim Deegan 
> Cc: Andrew Cooper 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] RFC: change to 6 months release cycle

[Andrew Cooper]

On 02/10/15 18:52, Juergen Gross wrote:
> On 10/02/2015 07:43 PM, Wei Liu wrote:
>> Hi all
>>
>> As I understand it in the past there were discussions on release every
>> 6 months. I would like to revisit this topic.
>>
>> # Rationale for a shorter release cycle
>>
>> The current 9 months cadence is too long. That create at least two
>> problems for us.
>>
>> The first problem is that Xen delivers features much slower than other
>> projects. Linux kernel releases every 3 months. QEMU releases every 4
>> months. They deliver new features at a much higher frequency.
>>
>> The second problem is that the opportunity cost for vendors to miss a
>> release is very high. When combined with the freeze exception scheme,
>> tension quickly builds up around cut-off point, which creates
>> frictions and frustrations for both contributors and maintainers. This
>> is detrimental to the project in the long run.
>>
>> Having a shorter release cycle plus some other measures seem to make
>> sense.
>>
>> The main objection from previous discussion seems to be that "shorter
>> release cycle creates burdens for downstream projects". I couldn't
>> quite get the idea, but I think we can figure out a way to sort that
>> out once we know what exactly the burdens are.
>>
>> A side note is that if we really go down this route we need to stick
>> with it for a few releases to let people get used to it. Any change to
>> the release process is going to cause some issues.
>>
>> # Proposed release cycle
>>
>> Aim for 6 months release cycle -- 4 months development period, 2
>> months hardening period. Make two releases per year.
>>
>> Fixed hard cut-off date, no more freeze exception. Arrange RCs
>> immediately after cut-off.
>>
>> Take into account holiday seasons in US, Europe and China, the two
>> cut-off dates are the Fridays in which that last day of March and
>> September are in.
>>
>> Targeted release date is two months after cut-off date. Still, we pick
>> a Friday using the same rule. We can also release a bit earlier if
>> everything goes well. If we somehow fail to release on time, we eat
>> into next development cycle. The next cut-off date will still be
>> fixed.
>>
>> With the proposed scheme, the dates will be:
>>
>>   - 4.7 cut-off date: April 1, 2016
>>   - 4.7 release date: June 1, 2016
>>
>>   - 4.8 cut-off date: September 30, 2016
>>   - 4.8 release date: December 2, 2016
>>
>>   - 4.9 cut-off date: March 31, 2017
>>   - 4.9 release date: June 2, 2017
>>
>> and it goes on.
>>
>> # Feasibility analysis
>>
>> Xen 4.6 is almost out of the door. I think it's convenient to use it
>> as one
>> data point about how we can achieve the proposed plan.
>>
>> Xen 4.6 release time line broken down:
>>
>>   - developemnt: 6 months
>>   - consideration for freeze exception: 1 week
>>   - applying patches with free exception: 1 week
>>   - fix major bugs: 2 weeks
>>   - RCs: every 1 to 2 weeks
>>
>> We aimed for a 9 months release cycle. That means we have 3 months for
>> stabilisation and RCs.
>>
>> Note that the 2 weeks used to fix bugs were mostly for bugs introduced
>> during free exception.
>>
>> The riddance of freeze exception saves us at least the first 2 weeks.
>> And because there are less changes due to shorter development cycle and
>> no freeze exception, there are probably less bugs, which means we can
>> potentially save another week or two. So the 6 months time line is
>> realistic to achieve.
>
> Expecting less bugs due to a shorter development cycle is strange. I'd
> expect more bugs as large features have less time to be stabilized. Or
> are you expecting only small features in the future? I don't hope so.

The expectation is that with a shorter release cycle, there will be less
pressure to push large series in at the last minute, as deferring them
to the next release comes with a substantially smaller penalty.  As a
result, large series will (hopefully) be better baked when they do get
accepted.

~Andrew

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

Re: [Xen-devel] RFC: change to 6 months release cycle

[Andrew Cooper]

On 02/10/15 18:43, Wei Liu wrote:
> Hi all
>
> 
>
> Comments are welcome!

+1.

We have consistently hit certain problems for the past few releases.  A
6 month cycle offers a plausible easing of some of the problems, and if
the worst comes to the worst we can always decide to move back to a 9
month cycle if 6 causes more problems than expected.

~Andrew

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

Re: [Xen-devel] RFC: change to 6 months release cycle

[Juergen Gross]

On 10/02/2015 07:43 PM, Wei Liu wrote:

Hi all

As I understand it in the past there were discussions on release every
6 months. I would like to revisit this topic.

# Rationale for a shorter release cycle

The current 9 months cadence is too long. That create at least two
problems for us.

The first problem is that Xen delivers features much slower than other
projects. Linux kernel releases every 3 months. QEMU releases every 4
months. They deliver new features at a much higher frequency.

The second problem is that the opportunity cost for vendors to miss a
release is very high. When combined with the freeze exception scheme,
tension quickly builds up around cut-off point, which creates
frictions and frustrations for both contributors and maintainers. This
is detrimental to the project in the long run.

Having a shorter release cycle plus some other measures seem to make
sense.

The main objection from previous discussion seems to be that "shorter
release cycle creates burdens for downstream projects". I couldn't
quite get the idea, but I think we can figure out a way to sort that
out once we know what exactly the burdens are.

A side note is that if we really go down this route we need to stick
with it for a few releases to let people get used to it. Any change to
the release process is going to cause some issues.

# Proposed release cycle

Aim for 6 months release cycle -- 4 months development period, 2
months hardening period. Make two releases per year.

Fixed hard cut-off date, no more freeze exception. Arrange RCs
immediately after cut-off.

Take into account holiday seasons in US, Europe and China, the two
cut-off dates are the Fridays in which that last day of March and
September are in.

Targeted release date is two months after cut-off date. Still, we pick
a Friday using the same rule. We can also release a bit earlier if
everything goes well. If we somehow fail to release on time, we eat
into next development cycle. The next cut-off date will still be
fixed.

With the proposed scheme, the dates will be:

  - 4.7 cut-off date: April 1, 2016
  - 4.7 release date: June 1, 2016

  - 4.8 cut-off date: September 30, 2016
  - 4.8 release date: December 2, 2016

  - 4.9 cut-off date: March 31, 2017
  - 4.9 release date: June 2, 2017

and it goes on.

# Feasibility analysis

Xen 4.6 is almost out of the door. I think it's convenient to use it as one
data point about how we can achieve the proposed plan.

Xen 4.6 release time line broken down:

  - developemnt: 6 months
  - consideration for freeze exception: 1 week
  - applying patches with free exception: 1 week
  - fix major bugs: 2 weeks
  - RCs: every 1 to 2 weeks

We aimed for a 9 months release cycle. That means we have 3 months for
stabilisation and RCs.

Note that the 2 weeks used to fix bugs were mostly for bugs introduced
during free exception.

The riddance of freeze exception saves us at least the first 2 weeks.
And because there are less changes due to shorter development cycle and
no freeze exception, there are probably less bugs, which means we can
potentially save another week or two. So the 6 months time line is
realistic to achieve.


Expecting less bugs due to a shorter development cycle is strange. I'd
expect more bugs as large features have less time to be stabilized. Or
are you expecting only small features in the future? I don't hope so.


Juergen

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

[Xen-devel] RFC: change to 6 months release cycle

[Wei Liu]

Hi all

As I understand it in the past there were discussions on release every
6 months. I would like to revisit this topic.

# Rationale for a shorter release cycle

The current 9 months cadence is too long. That create at least two
problems for us.

The first problem is that Xen delivers features much slower than other
projects. Linux kernel releases every 3 months. QEMU releases every 4
months. They deliver new features at a much higher frequency.

The second problem is that the opportunity cost for vendors to miss a
release is very high. When combined with the freeze exception scheme,
tension quickly builds up around cut-off point, which creates
frictions and frustrations for both contributors and maintainers. This
is detrimental to the project in the long run.

Having a shorter release cycle plus some other measures seem to make
sense.

The main objection from previous discussion seems to be that "shorter
release cycle creates burdens for downstream projects". I couldn't
quite get the idea, but I think we can figure out a way to sort that
out once we know what exactly the burdens are.

A side note is that if we really go down this route we need to stick
with it for a few releases to let people get used to it. Any change to
the release process is going to cause some issues.

# Proposed release cycle

Aim for 6 months release cycle -- 4 months development period, 2
months hardening period. Make two releases per year.

Fixed hard cut-off date, no more freeze exception. Arrange RCs
immediately after cut-off.

Take into account holiday seasons in US, Europe and China, the two
cut-off dates are the Fridays in which that last day of March and
September are in.

Targeted release date is two months after cut-off date. Still, we pick
a Friday using the same rule. We can also release a bit earlier if
everything goes well. If we somehow fail to release on time, we eat
into next development cycle. The next cut-off date will still be
fixed.

With the proposed scheme, the dates will be:

 - 4.7 cut-off date: April 1, 2016
 - 4.7 release date: June 1, 2016

 - 4.8 cut-off date: September 30, 2016
 - 4.8 release date: December 2, 2016

 - 4.9 cut-off date: March 31, 2017
 - 4.9 release date: June 2, 2017

and it goes on.

# Feasibility analysis

Xen 4.6 is almost out of the door. I think it's convenient to use it as one
data point about how we can achieve the proposed plan.

Xen 4.6 release time line broken down:

 - developemnt: 6 months
 - consideration for freeze exception: 1 week
 - applying patches with free exception: 1 week
 - fix major bugs: 2 weeks
 - RCs: every 1 to 2 weeks

We aimed for a 9 months release cycle. That means we have 3 months for
stabilisation and RCs.

Note that the 2 weeks used to fix bugs were mostly for bugs introduced
during free exception.

The riddance of freeze exception saves us at least the first 2 weeks.
And because there are less changes due to shorter development cycle and
no freeze exception, there are probably less bugs, which means we can
potentially save another week or two. So the 6 months time line is
realistic to achieve.

We branched and reopened xen-unstable at RC3 on September 9, which is
more or less two months after freeze (July 10) and one month before
anticipated release date (October 9).  With the new release cycle, we
can probably reopen the tree after 4 to 6 weeks of frozen state. This
helps our contributors upstream their code faster.

Comments are welcome!

Wei.

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

Re: [Xen-devel] [PATCH v3 3/9] xen/blkfront: separate per ring information out of device info

[Roger Pau Monné]

El 05/09/15 a les 14.39, Bob Liu ha escrit:
> Split per ring information to an new structure:blkfront_ring_info, also rename
> per blkfront_info to blkfront_dev_info.
  ^ removed.
> 
> A ring is the representation of a hardware queue, every vbd device can 
> associate
> with one or more blkfront_ring_info depending on how many hardware
> queues/rings to be used.
> 
> This patch is a preparation for supporting real multi hardware queues/rings.
> 
> Signed-off-by: Arianna Avanzini 
> Signed-off-by: Bob Liu 
> ---
>  drivers/block/xen-blkfront.c |  854 
> ++
>  1 file changed, 445 insertions(+), 409 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 5dd591d..bf416d5 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -107,7 +107,7 @@ static unsigned int xen_blkif_max_ring_order;
>  module_param_named(max_ring_page_order, xen_blkif_max_ring_order, int, 
> S_IRUGO);
>  MODULE_PARM_DESC(max_ring_page_order, "Maximum order of pages to be used for 
> the shared ring");
>  
> -#define BLK_RING_SIZE(info) __CONST_RING_SIZE(blkif, PAGE_SIZE * 
> (info)->nr_ring_pages)
> +#define BLK_RING_SIZE(dinfo) __CONST_RING_SIZE(blkif, PAGE_SIZE * 
> (dinfo)->nr_ring_pages)

This change looks pointless, any reason to use dinfo instead of info?

>  #define BLK_MAX_RING_SIZE __CONST_RING_SIZE(blkif, PAGE_SIZE * 
> XENBUS_MAX_RING_PAGES)
>  /*
>   * ring-ref%i i=(-1UL) would take 11 characters + 'ring-ref' is 8, so 19
> @@ -116,12 +116,31 @@ MODULE_PARM_DESC(max_ring_page_order, "Maximum order of 
> pages to be used for the
>  #define RINGREF_NAME_LEN (20)
>  
>  /*
> + *  Per-ring info.
> + *  Every blkfront device can associate with one or more blkfront_ring_info,
> + *  depending on how many hardware queues to be used.
> + */
> +struct blkfront_ring_info
> +{
> + struct blkif_front_ring ring;
> + unsigned int ring_ref[XENBUS_MAX_RING_PAGES];
> + unsigned int evtchn, irq;
> + struct work_struct work;
> + struct gnttab_free_callback callback;
> + struct blk_shadow shadow[BLK_MAX_RING_SIZE];
> + struct list_head grants;
> + struct list_head indirect_pages;
> + unsigned int persistent_gnts_c;

persistent grants should be per-device, not per-queue IMHO. Is it really
hard to make this global instead of per-queue?

> + unsigned long shadow_free;
> + struct blkfront_dev_info *dinfo;
> +};
> +
> +/*
>   * We have one of these per vbd, whether ide, scsi or 'other'.  They
>   * hang in private_data off the gendisk structure. We may end up
>   * putting all kinds of interesting stuff here :-)
>   */
> -struct blkfront_info
> -{
> +struct blkfront_dev_info {

IMHO, you can leave this as blkfront_info (unless I'm missing something).

>   spinlock_t io_lock;

Shouldn't the spinlock be per-queue instead of per-device?

>   struct mutex mutex;
>   struct xenbus_device *xbdev;
> @@ -129,18 +148,7 @@ struct blkfront_info
>   int vdevice;
>   blkif_vdev_t handle;
>   enum blkif_state connected;
> - int ring_ref[XENBUS_MAX_RING_PAGES];
> - unsigned int nr_ring_pages;
> - struct blkif_front_ring ring;
> - unsigned int evtchn, irq;
>   struct request_queue *rq;
> - struct work_struct work;
> - struct gnttab_free_callback callback;
> - struct blk_shadow shadow[BLK_MAX_RING_SIZE];
> - struct list_head grants;
> - struct list_head indirect_pages;
> - unsigned int persistent_gnts_c;
> - unsigned long shadow_free;
>   unsigned int feature_flush;
>   unsigned int feature_discard:1;
>   unsigned int feature_secdiscard:1;
> @@ -149,7 +157,9 @@ struct blkfront_info
>   unsigned int feature_persistent:1;
>   unsigned int max_indirect_segments;
>   int is_ready;
> + unsigned int nr_ring_pages;

Spurious change? You are removing it in the chunk above and adding it
back here.

[...]

> @@ -246,33 +257,33 @@ out_of_memory:
>  }
>  
>  static struct grant *get_grant(grant_ref_t *gref_head,
> -   unsigned long pfn,
> -   struct blkfront_info *info)
> +unsigned long pfn,
> +struct blkfront_ring_info *rinfo)

Indentation? (or my email client is mangling emails one more time...)

In order to make this easier to review, do you think you can leave
blkfront_info as "info" for now, and do the renaming to dinfo in a later
patch. That would help figuring out mechanical name changes from the
actual meat of the patch.

Roger.

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

Re: [Xen-devel] [PATCH 1/3] x86/p2m: tighten conditions of IOMMU mapping updates

[Jiang, Yunhong]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 30, 2015 2:58 AM
> To: Jiang, Yunhong
> Cc: Andrew Cooper; George Dunlap; Nakajima, Jun; Tian, Kevin; xen-devel;
> KeirFraser
> Subject: RE: [Xen-devel] [PATCH 1/3] x86/p2m: tighten conditions of IOMMU
> mapping updates
> 
> >>> On 30.09.15 at 02:02,  wrote:
> 
> >
> >> -Original Message-
> >> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> >> boun...@lists.xen.org] On Behalf Of Jan Beulich
> >> Sent: Tuesday, September 29, 2015 12:59 AM
> >> To: xen-devel
> >> Cc: George Dunlap; Andrew Cooper; Tian, Kevin; Keir Fraser; Nakajima, Jun
> >> Subject: Re: [Xen-devel] [PATCH 1/3] x86/p2m: tighten conditions of IOMMU
> >> mapping updates
> >>
> >> >>> On 21.09.15 at 16:02,  wrote:
> >> > In the EPT case permission changes should also result in updates or
> >> > TLB flushes.
> >> >
> >> > In the NPT case the old MFN does not depend on the new entry being
> >> > valid (but solely on the old one), and the need to update or TLB-flush
> >> > again also depends on permission changes.
> >> >
> >> > In the shadow mode case, iommu_hap_pt_share should be ignored.
> >> >
> >> > Furthermore in the NPT/shadow case old intermediate page tables must
> >> > be freed only after IOMMU side updates/flushes have got carried out.
> >> >
> >> > Signed-off-by: Jan Beulich 
> >> > ---
> >> > In addition to the fixes here it looks to me as if both EPT and
> >> > NPT/shadow code lack invalidation of IOMMU side paging structure
> >> > caches, i.e. further changes may be needed. Am I overlooking something?
> >>
> >> Okay, I think I finally figured it myself (with the help of the partial
> >> patch presented yesterday): There is no need for more flushing
> >> in the current model, where we only ever split large pages or fully
> >> replace sub-hierarchies with large pages (accompanied by a suitable
> >> flush already). More flushing would only be needed if we were to
> >> add code to re-establish large pages if an intermediate page table
> >> re-gained a state where this would be possible (quite desirable
> >> in a situation where log-dirty mode got temporarily enabled on a
> >> domain, but I'm not sure how common an operation that would be).
> >> When splitting large pages, all the hardware can have cached are
> >> - leaf entries the size of the page being split
> >
> > I'm not sure if there is an offset-1 issue.
> 
> offset-1 ?
> 
> > Basically I think we depends on the "Invalidation Hint" being cleared so
> > that all the paging structure cache are cleared. That should work if there 
> > is
> > no split happen.
> > However, in the split situation, I suspect that the entry that was split is
> > not covered by the ADDR/AM combination since the AM, based on
> > iommu_flush_iotlb_psi(), is in fact the "order" parameter for
> > ept_set_entry(). I'm not sure if I missed anything.
> 
> IH is always clear in Xen right now. And the address covers both -
> leaf entries as well as intermediate ones. Yet as explained before
> we don't even care about intermediate ones in the split case.

Yes, that's it. So as your statement before, there is no need for paging 
structure flush.

--jyh

> 
> Jan


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

Re: [Xen-devel] [PATCH v2 3/5] libxc: create unmapped initrd in domain builder if supported

[Juergen Gross]

On 10/02/2015 05:21 PM, Ian Campbell wrote:

On Fri, 2015-10-02 at 17:13 +0200, Juergen Gross wrote:

On 10/02/2015 04:56 PM, Ian Campbell wrote:

On Fri, 2015-10-02 at 16:46 +0200, Juergen Gross wrote:

On 10/02/2015 02:59 PM, Ian Campbell wrote:

On Fri, 2015-10-02 at 07:49 +0200, Juergen Gross wrote:

In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the
initrd,
but allocate only guest physical memory for it.

Signed-off-by: Juergen Gross 
---
tools/libxc/xc_dom_core.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_dom_core.c
b/tools/libxc/xc_dom_core.c
index b510bbd..85b531a 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1019,8 +1019,9 @@ int xc_dom_build_image(struct xc_dom_image
*dom)
if ( dom->kernel_loader->loader(dom) != 0 )
goto err;

-/* load ramdisk */
-if ( dom->ramdisk_blob )
+/* Load ramdisk if initial mapping required. */
+if ( dom->ramdisk_blob &&
+ (!dom->parms.mod_start_pfn || dom->ramdisk_seg.vstart)
)
{
if ( xc_dom_build_ramdisk(dom) != 0 )
goto err;
@@ -1063,6 +1064,23 @@ int xc_dom_build_image(struct xc_dom_image
*dom)
  __FUNCTION__, dom->virt_alloc_end);
DOMPRINTF("%-20s: virt_pgtab_end : 0x%" PRIx64 "",
  __FUNCTION__, dom->virt_pgtab_end);
+
+/* Prepare allocating unmapped memory. */
+if ( dom->virt_pgtab_end )
+dom->virt_alloc_end = dom->virt_pgtab_end;
+
+/* Load ramdisk if no initial mapping required. */
+if ( dom->ramdisk_blob && !dom->ramdisk_seg.vstart &&
+ dom->parms.mod_start_pfn )
+{
+if ( xc_dom_build_ramdisk(dom) != 0 )
+goto err;
+dom->flags |= SIF_MOD_START_PFN;
+dom->ramdisk_seg.vend = dom->ramdisk_seg.vend - dom
->ramdisk_seg.vstart;
+dom->ramdisk_seg.vstart = dom->ramdisk_seg.pfn;
+dom->ramdisk_seg.vend += dom->ramdisk_seg.vstart;


This seems like it is trying to do something clever, like partially
reversing something which the xc_dom_alloc_segment call in
xc_dom_build_ramdisk has done.


It's just changing the boundaries of the initrd to fit the interface
for it being not mapped (indicated by the SIF_MOD_START_PFN flag).


So something has initialised these fields as if it were mapped and we
are
now undoing it because in reality it is not? IOW something has arranged
things such that vstart and vend are invalid before this adjustment.

So whatever is making these allocations and mapping (or not) them
should
instead be fixed to just do things correctly from the start.

Am I correct that after this the vstart and vend actually contain
physical
addresses? Does anything use them that way, and how does it know if
they
are physical or virtual?

Perhaps the right answer is to add pstart and pend and to initialise
those
correctly (for everything) while leaving the v* ones set to some
sentinel
value to indicate when things are unmapped?


I want to do something like this, yes.


It looks like the vend handling in particular is just a complicated
way
of
subtracting vstart and adding pfn, with the aim of rebasing from
virt
to
phys world.


Hmm, not more complicated as:

len = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
dom->ramdisk_seg.vstart = dom->ramdisk_seg.pfn;
dom->ramdisk_seg.vend = dom->ramdisk_seg.pfn + len;

I have to admit that above variant might be easier to understand. :-)


It is, much easier.


:-)


Plus vstart/end are addresses, while presumably pfn is a page
number,
so
I'm confused about that as well.


The naming is irritating, yes.


Are you saying that pfn is actually a physical address?


It's a page number.

The start_info page data regarding the initrd is taken from
dom->ramdisk_seg. The length is computed from vend - vstart and the
start of the initrd is either a virtual address or a pfn.


So are vend and vstart frame numbers then?

They had better be, because otherwise the length you are computing is in
bytes, so adding it to a frame number in vstart makes no sense.


The length is always in bytes. The start is either a virtual address or
a frame number. vend is making only sense if you subtract vstart.

I think we can stop discussing this now, as the next version of the
series should be much clearer in this regard.


Juergen

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

Re: [Xen-devel] [PATCH v3 2/9] xen-block: add document for mutli hardware queues/rings

[Roger Pau Monné]

El 02/10/15 a les 18.12, Wei Liu ha escrit:
> On Fri, Oct 02, 2015 at 06:04:35PM +0200, Roger Pau Monné wrote:
>> El 05/09/15 a les 14.39, Bob Liu ha escrit:
>>> Document multi queues/rings of xen-block.
>>>
>>> Signed-off-by: Bob Liu 
>>
>> As said by Konrad, you should send this against the Xen public headers
>> also (or even before). I have a comment below.
>>
>>> ---
>>>  include/xen/interface/io/blkif.h |   32 
>>>  1 file changed, 32 insertions(+)
>>>
>>> diff --git a/include/xen/interface/io/blkif.h 
>>> b/include/xen/interface/io/blkif.h
>>> index c33e1c4..b453b70 100644
>>> --- a/include/xen/interface/io/blkif.h
>>> +++ b/include/xen/interface/io/blkif.h
>>> @@ -28,6 +28,38 @@ typedef uint16_t blkif_vdev_t;
>>>  typedef uint64_t blkif_sector_t;
>>>  
>>>  /*
>>> + * Multiple hardware queues/rings:
>>> + * If supported, the backend will write the key "multi-queue-max-queues" to
>>> + * the directory for that vbd, and set its value to the maximum supported
>>> + * number of queues.
>>> + * Frontends that are aware of this feature and wish to use it can write 
>>> the
>>> + * key "multi-queue-num-queues", set to the number they wish to use, which
>>> + * must be greater than zero, and no more than the value reported by the 
>>> backend
>>> + * in "multi-queue-max-queues".
>>> + *
>>> + * For frontends requesting just one queue, the usual event-channel and
>>> + * ring-ref keys are written as before, simplifying the backend processing
>>> + * to avoid distinguishing between a frontend that doesn't understand the
>>> + * multi-queue feature, and one that does, but requested only one queue.
>>> + *
>>> + * Frontends requesting two or more queues must not write the toplevel
>>> + * event-channeland ring-ref keys, instead writing those keys under 
>>> sub-keys
>>> + * having the name "queue-N" where N is the integer ID of the queue/ring 
>>> for
>>> + * which those keys belong. Queues are indexed from zero.
>>> + * For example, a frontend with two queues must write the following set of
>>> + * queue-related keys:
>>> + *
>>> + * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2"
>>> + * /local/domain/1/device/vbd/0/queue-0 = ""
>>> + * /local/domain/1/device/vbd/0/queue-0/ring-ref = ""
>>> + * /local/domain/1/device/vbd/0/queue-0/event-channel = ""
>>> + * /local/domain/1/device/vbd/0/queue-1 = ""
>>> + * /local/domain/1/device/vbd/0/queue-1/ring-ref = ""
>>> + * /local/domain/1/device/vbd/0/queue-1/event-channel = ""
>>
>> AFAICT, it's impossible by design to use multiple queues together with
>> multipage rings, is that right?
>>
> 
> As far as I can tell, these two features are not inherently coupled.
> Whether you want to make (by design) them coupled together or not is
> another matter. :-)

I haven't looked at the implementation yet, but some mention of whether
multipage-rings are allowed with multiqueue would be good. For example
if both can indeed be used in conjunction I would mention:

If multi-page rings are also used, the format of the grant references
will be:

/local/domain/1/device/vbd/0/queue-0/ring-ref0 = ""
/local/domain/1/device/vbd/0/queue-0/ring-ref1 = ""
/local/domain/1/device/vbd/0/queue-0/ring-ref2 = ""
[...]

Roger.


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

Re: [Xen-devel] [PATCH v3 2/9] xen-block: add document for mutli hardware queues/rings

[Wei Liu]

On Fri, Oct 02, 2015 at 06:04:35PM +0200, Roger Pau Monné wrote:
> El 05/09/15 a les 14.39, Bob Liu ha escrit:
> > Document multi queues/rings of xen-block.
> > 
> > Signed-off-by: Bob Liu 
> 
> As said by Konrad, you should send this against the Xen public headers
> also (or even before). I have a comment below.
> 
> > ---
> >  include/xen/interface/io/blkif.h |   32 
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/include/xen/interface/io/blkif.h 
> > b/include/xen/interface/io/blkif.h
> > index c33e1c4..b453b70 100644
> > --- a/include/xen/interface/io/blkif.h
> > +++ b/include/xen/interface/io/blkif.h
> > @@ -28,6 +28,38 @@ typedef uint16_t blkif_vdev_t;
> >  typedef uint64_t blkif_sector_t;
> >  
> >  /*
> > + * Multiple hardware queues/rings:
> > + * If supported, the backend will write the key "multi-queue-max-queues" to
> > + * the directory for that vbd, and set its value to the maximum supported
> > + * number of queues.
> > + * Frontends that are aware of this feature and wish to use it can write 
> > the
> > + * key "multi-queue-num-queues", set to the number they wish to use, which
> > + * must be greater than zero, and no more than the value reported by the 
> > backend
> > + * in "multi-queue-max-queues".
> > + *
> > + * For frontends requesting just one queue, the usual event-channel and
> > + * ring-ref keys are written as before, simplifying the backend processing
> > + * to avoid distinguishing between a frontend that doesn't understand the
> > + * multi-queue feature, and one that does, but requested only one queue.
> > + *
> > + * Frontends requesting two or more queues must not write the toplevel
> > + * event-channeland ring-ref keys, instead writing those keys under 
> > sub-keys
> > + * having the name "queue-N" where N is the integer ID of the queue/ring 
> > for
> > + * which those keys belong. Queues are indexed from zero.
> > + * For example, a frontend with two queues must write the following set of
> > + * queue-related keys:
> > + *
> > + * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2"
> > + * /local/domain/1/device/vbd/0/queue-0 = ""
> > + * /local/domain/1/device/vbd/0/queue-0/ring-ref = ""
> > + * /local/domain/1/device/vbd/0/queue-0/event-channel = ""
> > + * /local/domain/1/device/vbd/0/queue-1 = ""
> > + * /local/domain/1/device/vbd/0/queue-1/ring-ref = ""
> > + * /local/domain/1/device/vbd/0/queue-1/event-channel = ""
> 
> AFAICT, it's impossible by design to use multiple queues together with
> multipage rings, is that right?
> 

As far as I can tell, these two features are not inherently coupled.
Whether you want to make (by design) them coupled together or not is
another matter. :-)

> Roger.
> 
> 
> ___
> 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 v3 2/9] xen-block: add document for mutli hardware queues/rings

[Roger Pau Monné]

El 05/09/15 a les 14.39, Bob Liu ha escrit:
> Document multi queues/rings of xen-block.
> 
> Signed-off-by: Bob Liu 

As said by Konrad, you should send this against the Xen public headers
also (or even before). I have a comment below.

> ---
>  include/xen/interface/io/blkif.h |   32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/include/xen/interface/io/blkif.h 
> b/include/xen/interface/io/blkif.h
> index c33e1c4..b453b70 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -28,6 +28,38 @@ typedef uint16_t blkif_vdev_t;
>  typedef uint64_t blkif_sector_t;
>  
>  /*
> + * Multiple hardware queues/rings:
> + * If supported, the backend will write the key "multi-queue-max-queues" to
> + * the directory for that vbd, and set its value to the maximum supported
> + * number of queues.
> + * Frontends that are aware of this feature and wish to use it can write the
> + * key "multi-queue-num-queues", set to the number they wish to use, which
> + * must be greater than zero, and no more than the value reported by the 
> backend
> + * in "multi-queue-max-queues".
> + *
> + * For frontends requesting just one queue, the usual event-channel and
> + * ring-ref keys are written as before, simplifying the backend processing
> + * to avoid distinguishing between a frontend that doesn't understand the
> + * multi-queue feature, and one that does, but requested only one queue.
> + *
> + * Frontends requesting two or more queues must not write the toplevel
> + * event-channeland ring-ref keys, instead writing those keys under sub-keys
> + * having the name "queue-N" where N is the integer ID of the queue/ring for
> + * which those keys belong. Queues are indexed from zero.
> + * For example, a frontend with two queues must write the following set of
> + * queue-related keys:
> + *
> + * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2"
> + * /local/domain/1/device/vbd/0/queue-0 = ""
> + * /local/domain/1/device/vbd/0/queue-0/ring-ref = ""
> + * /local/domain/1/device/vbd/0/queue-0/event-channel = ""
> + * /local/domain/1/device/vbd/0/queue-1 = ""
> + * /local/domain/1/device/vbd/0/queue-1/ring-ref = ""
> + * /local/domain/1/device/vbd/0/queue-1/event-channel = ""

AFAICT, it's impossible by design to use multiple queues together with
multipage rings, is that right?

Roger.


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

[Xen-devel] [PATCH v7 04/32] libxc: introduce the notion of a container type

[Roger Pau Monne]

Introduce the notion of a container type into xc_dom_image. This will be
needed by later changes that will also use xc_dom_image in order to build
HVM guests.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v3:
 - Add Andrew Cooper Reviewed-by.
 - Add Wei Acked-by.
---
 tools/libxc/include/xc_dom.h | 6 ++
 tools/libxc/xc_dom_x86.c | 4 
 tools/libxl/libxl_dom.c  | 1 +
 3 files changed, 11 insertions(+)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index e794a13..30fa8c5 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -177,6 +177,12 @@ struct xc_dom_image {
 struct xc_dom_arch *arch_hooks;
 /* allocate up to virt_alloc_end */
 int (*allocate) (struct xc_dom_image * dom, xen_vaddr_t up_to);
+
+/* Container type (HVM or PV). */
+enum {
+XC_DOM_PV_CONTAINER,
+XC_DOM_HVM_CONTAINER,
+} container_type;
 };
 
 /* --- pluggable kernel loader - */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index f3962cd..d306475 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -1069,6 +1069,10 @@ int arch_setup_bootlate(struct xc_dom_image *dom)
 
 int xc_dom_feature_translated(struct xc_dom_image *dom)
 {
+/* Guests running inside HVM containers are always auto-translated. */
+if ( dom->container_type == XC_DOM_HVM_CONTAINER )
+return 1;
+
 return elf_xen_feature_get(XENFEAT_auto_translated_physmap, dom->f_active);
 }
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 286df93..01172b0 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -620,6 +620,7 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 }
 
 dom->pvh_enabled = state->pvh_enabled;
+dom->container_type = XC_DOM_PV_CONTAINER;
 
 LOG(DEBUG, "pv kernel mapped %d path %s", state->pv_kernel.mapped, 
state->pv_kernel.path);
 
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 22/32] xen/x86: allow disabling the emulated IOMMU

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
Acked-by: Andrew Cooper 
Acked-by: Aravind Gopalakrishnan 
Cc: Suravee Suthikulpanit 
Cc: Aravind Gopalakrishnan 
---
Changes since v4:
 - Add Andrew Cooper Acked-by.
---
 xen/drivers/passthrough/amd/iommu_guest.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/amd/iommu_guest.c 
b/xen/drivers/passthrough/amd/iommu_guest.c
index e74f469..b4e75ac 100644
--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++ b/xen/drivers/passthrough/amd/iommu_guest.c
@@ -887,7 +887,8 @@ int guest_iommu_init(struct domain* d)
 struct guest_iommu *iommu;
 struct hvm_iommu *hd  = domain_hvm_iommu(d);
 
-if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
+if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled ||
+ !has_viommu(d) )
 return 0;
 
 iommu = xzalloc(struct guest_iommu);
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 18/32] xen/x86: allow disabling the emulated IO APIC

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
Acked-by: Andrew Cooper 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v6:
 - Return ENODEV in ioapic_load if the ioapic is disabled.
 - Add an assert to make sure vioapic_update_EOI and
   vioapic_irq_positive_edge is only called when the vioapic is enabled.

Changes since v4:
 - Add Andrew Cooper Acked-by.
---
 xen/arch/x86/hvm/vioapic.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
index d348235..611be87 100644
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -365,6 +365,8 @@ void vioapic_irq_positive_edge(struct domain *d, unsigned 
int irq)
 struct hvm_hw_vioapic *vioapic = domain_vioapic(d);
 union vioapic_redir_entry *ent;
 
+ASSERT(has_vioapic(d));
+
 HVM_DBG_LOG(DBG_LEVEL_IOAPIC, "irq %x", irq);
 
 ASSERT(irq < VIOAPIC_NUM_PINS);
@@ -392,6 +394,8 @@ void vioapic_update_EOI(struct domain *d, u8 vector)
 union vioapic_redir_entry *ent;
 int gsi;
 
+ASSERT(has_vioapic(d));
+
 spin_lock(&d->arch.hvm_domain.irq_lock);
 
 for ( gsi = 0; gsi < VIOAPIC_NUM_PINS; gsi++ )
@@ -424,12 +428,20 @@ void vioapic_update_EOI(struct domain *d, u8 vector)
 static int ioapic_save(struct domain *d, hvm_domain_context_t *h)
 {
 struct hvm_hw_vioapic *s = domain_vioapic(d);
+
+if ( !has_vioapic(d) )
+return 0;
+
 return hvm_save_entry(IOAPIC, 0, h, s);
 }
 
 static int ioapic_load(struct domain *d, hvm_domain_context_t *h)
 {
 struct hvm_hw_vioapic *s = domain_vioapic(d);
+
+if ( !has_vioapic(d) )
+return -ENODEV;
+
 return hvm_load_entry(IOAPIC, h, s);
 }
 
@@ -440,6 +452,9 @@ void vioapic_reset(struct domain *d)
 struct hvm_vioapic *vioapic = d->arch.hvm_domain.vioapic;
 int i;
 
+if ( !has_vioapic(d) )
+return;
+
 memset(&vioapic->hvm_hw_vioapic, 0, sizeof(vioapic->hvm_hw_vioapic));
 for ( i = 0; i < VIOAPIC_NUM_PINS; i++ )
 vioapic->hvm_hw_vioapic.redirtbl[i].fields.mask = 1;
@@ -448,6 +463,9 @@ void vioapic_reset(struct domain *d)
 
 int vioapic_init(struct domain *d)
 {
+if ( !has_vioapic(d) )
+return 0;
+
 if ( (d->arch.hvm_domain.vioapic == NULL) &&
  ((d->arch.hvm_domain.vioapic = xmalloc(struct hvm_vioapic)) == NULL) )
 return -ENOMEM;
@@ -462,6 +480,9 @@ int vioapic_init(struct domain *d)
 
 void vioapic_deinit(struct domain *d)
 {
+if ( !has_vioapic(d) )
+return;
+
 xfree(d->arch.hvm_domain.vioapic);
 d->arch.hvm_domain.vioapic = NULL;
 }
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 27/32] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs

[Roger Pau Monne]

Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down and
VCPUOP_is_up hypercalls from HVM guests.

This patch introduces a new structure (vcpu_hvm_context) that should be used
in conjuction with the VCPUOP_initialise hypercall in order to initialize
vCPUs for HVM guests.

Signed-off-by: Roger Pau Monné 
Signed-off-by: Andrew Cooper 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Campbell 
Cc: Stefano Stabellini 
---
Changes since v6:
 - Add comments to clarify some initializations.
 - Introduce a generic default_initialize_vcpu that's used to initialize a
   ARM vCPU or a x86 PV vCPU.
 - Move the undef of the SEG macro.
 - Fix the size of the eflags register, it should be 32bits.
 - Add a comment regarding the value of the 12-15 bits of the _ar fields.
 - Remove the 16bit strucutre, the 32bit one can be used to start the cpu in
   real mode.
 - Add some sanity checks to the values passed in.
 - Add paddings to vcpu_hvm_context so the layout on 32/64bits is the same.
 - Add support for the compat version of VCPUOP_initialise.

Changes since v5:
 - Fix a coding style issue.
 - Merge the code from wip-dmlite-v5-refactor by Andrew in order to reduce
   bloat.
 - Print the offending %cr3 in case of error when using shadow.
 - Reduce the scope of local variables in arch_initialize_vcpu.
 - s/current->domain/v->domain/g in arch_initialize_vcpu.
 - Expand the comment in public/vcpu.h to document the usage of
   vcpu_hvm_context for HVM guests.
 - Add myself as the copyright holder for the public hvm_vcpu.h header.

Changes since v4:
 - Don't assume mode is 64B, add an explicit check.
 - Don't set TF_kernel_mode, it is only needed for PV guests.
 - Don't set CR0_ET unconditionally.
---
 xen/arch/x86/domain.c | 185 ++
 xen/arch/x86/hvm/hvm.c|   8 ++
 xen/common/compat/domain.c|  71 +++
 xen/common/domain.c   |  56 +---
 xen/include/Makefile  |   1 +
 xen/include/asm-x86/domain.h  |   3 +
 xen/include/public/hvm/hvm_vcpu.h | 144 +
 xen/include/public/vcpu.h |   6 +-
 xen/include/xlat.lst  |   3 +
 9 files changed, 448 insertions(+), 29 deletions(-)
 create mode 100644 xen/include/public/hvm/hvm_vcpu.h

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a3b1c9b..af5feea 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1176,6 +1177,190 @@ int arch_set_info_guest(
 #undef c
 }
 
+/* Called by VCPUOP_initialise for HVM guests. */
+int arch_set_info_hvm_guest(struct vcpu *v, vcpu_hvm_context_t *ctx)
+{
+struct cpu_user_regs *uregs = &v->arch.user_regs;
+struct segment_register cs, ds, ss, es, tr;
+
+switch ( ctx->mode )
+{
+default:
+return -EINVAL;
+
+case VCPU_HVM_MODE_32B:
+{
+const struct vcpu_hvm_x86_32 *regs = &ctx->cpu_regs.x86_32;
+uint32_t limit;
+
+#define SEG(s, r)   \
+(struct segment_register){ .sel = 0, .base = (r)->s ## _base,   \
+.limit = (r)->s ## _limit, .attr.bytes = (r)->s ## _ar }
+cs = SEG(cs, regs);
+ds = SEG(ds, regs);
+ss = SEG(ss, regs);
+es = SEG(es, regs);
+tr = SEG(tr, regs);
+#undef SEG
+
+/* Basic sanity checks. */
+if ( cs.attr.fields.pad != 0 || ds.attr.fields.pad != 0 ||
+ ss.attr.fields.pad != 0 || es.attr.fields.pad != 0 ||
+ tr.attr.fields.pad != 0 )
+{
+gprintk(XENLOG_ERR, "Attribute bits 12-15 of the segments are not 
null\n");
+return -EINVAL;
+}
+
+limit = cs.limit * (cs.attr.fields.g ? PAGE_SIZE : 1);
+if ( regs->eip > limit )
+{
+gprintk(XENLOG_ERR, "EIP address is outside of the CS limit\n");
+return -EINVAL;
+}
+
+if ( ds.attr.fields.dpl > cs.attr.fields.dpl )
+{
+gprintk(XENLOG_ERR, "DPL of DS is greater than DPL of CS\n");
+return -EINVAL;
+}
+
+if ( ss.attr.fields.dpl != cs.attr.fields.dpl )
+{
+gprintk(XENLOG_ERR, "DPL of SS is different than DPL of CS\n");
+return -EINVAL;
+}
+
+if ( es.attr.fields.dpl > cs.attr.fields.dpl )
+{
+gprintk(XENLOG_ERR, "DPL of ES is greater than DPL of CS\n");
+return -EINVAL;
+}
+
+if ( ((regs->efer & EFER_LMA) && !(regs->efer & EFER_LME)) ||
+ ((regs->efer & EFER_LME) && !(regs->efer & EFER_LMA)) )
+{
+gprintk(XENLOG_ERR, "EFER.LMA and EFER.LME must be both set\n");
+return -EINVAL;
+}
+
+uregs->rax= regs->eax;
+uregs->rcx= regs->ecx;
+uregs->rdx= regs->edx;
+uregs->rbx= regs->ebx;
+uregs->rsp

[Xen-devel] [PATCH v7 30/32] libxc: switch xc_dom_elfloader to be used with HVMlite domains

[Roger Pau Monne]

Allow xc_dom_elfloader to report a guest type as hvm-3.0-x86_32 if it's
running inside of a HVM container and has the PHYS32_ENTRY elfnote set.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Only xc_dom_elfloader has been switched to support HVMlite, other loaders
should also be switched once we have a HVMlite compatible kernel that uses
them.
---
Changes since v5:
 - Add Wei Liu Ack.

Changes since v4:
 - Add Andrew Cooper Reviewed-by.
---
 tools/libxc/xc_dom_elfloader.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 82524c9..8ba45ef 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -56,6 +56,10 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
 {
 uint64_t machine = elf_uval(elf, elf->ehdr, e_machine);
 
+if ( dom->container_type == XC_DOM_HVM_CONTAINER &&
+ dom->parms.phys_entry != UNSET_ADDR )
+return "hvm-3.0-x86_32";
+
 switch ( machine )
 {
 case EM_386:
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 28/32] xenconsole: try to attach to PV console if HVM fails

[Roger Pau Monne]

HVM guests have always used the emulated serial console by default, but if
the emulated serial pty cannot be fetched from xenstore try to use the PV
console instead.

Signed-off-by: Roger Pau Monné 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v4:
 - Add Wei Liu Acked-by.

Changes since v3:
 - Drop the usage of a label and instead use if conditions.
---
 tools/console/client/main.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/tools/console/client/main.c b/tools/console/client/main.c
index f130a60..d006fdc 100644
--- a/tools/console/client/main.c
+++ b/tools/console/client/main.c
@@ -333,7 +333,7 @@ int main(int argc, char **argv)
{ 0 },
 
};
-   char *dom_path = NULL, *path = NULL;
+   char *dom_path = NULL, *path = NULL, *test = NULL;
int spty, xsfd;
struct xs_handle *xs;
char *end;
@@ -415,9 +415,15 @@ int main(int argc, char **argv)
path = malloc(strlen(dom_path) + strlen("/device/console/0/tty") + 5);
if (path == NULL)
err(ENOMEM, "malloc");
-   if (type == CONSOLE_SERIAL)
+   if (type == CONSOLE_SERIAL) {
snprintf(path, strlen(dom_path) + strlen("/serial/0/tty") + 5, 
"%s/serial/%d/tty", dom_path, num);
-   else {
+   test = xs_read(xs, XBT_NULL, path, NULL);
+   free(test);
+   if (test == NULL)
+   type = CONSOLE_PV;
+   }
+   if (type == CONSOLE_PV) {
+
if (num == 0)
snprintf(path, strlen(dom_path) + 
strlen("/console/tty") + 1, "%s/console/tty", dom_path);
else
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 00/32] Introduce HVM without dm and new boot ABI

[Roger Pau Monne]

This series is split in the following order:

 - Patch 1 is a fix for the compat layer VCPUOP_initialise hypercall.
 - Patches from 2 to 11 switch HVM domain contruction to use the xc_dom_*
   family of functions, like they are used to build PV domains. This batch
   of patches can go in regardless of the status of the rest of the series
   IMHO, and in fact would help me quite a lot with the rebasing.
 - Patches from 12 to 24 allow disabling the devices emulated inside of Xen, 
   with the exception of patch 13 which is a bugfix for the vlapic.
 - Patches from 25 to 32 introduce the creation of HVM guests without a
   device model and without the devices emulated inside of Xen.

This series has been successfully tested on the following hardware:

 - Intel Xeon W3550.
 - AMD Opteron 4184.

With both hap=0 and hap=1 in the configuration file. I've been able to boot
a SMP guest in this mode with a virtual hard drive and a virtual network
card, all working fine AFAICT. Migration/save/restore has also been tested 
with a SMP guest using the FreeBSD kernel provided below.

The series has been compile tested on arm32.

The series can also be found in the following git repo:

git://xenbits.xen.org/people/royger/xen.git branch hvm_without_dm_v7

And for the FreeBSD part:

git://xenbits.xen.org/people/royger/freebsd.git branch new_entry_point_v5

In case someone wants to give it a try, I've uploaded a FreeBSD kernel that
should work when booted into this mode:

https://people.freebsd.org/~royger/kernel_no_dm

This FreeBSD kernel starts the APs in long mode. There are examples for 
starting the APs in other modes in the sys/x86/xen/pv.c file.

The config file that I've used is:


kernel="/path/to/kernel_no_dm"

builder="hvm"
device_model_version="none"

memory=128
vcpus=2
name = "freebsd"


Of course if you have a FreeBSD disk already setup it can also be added to
the configuration file, and the following line can be used to point FreeBSD
to the disk:

extra="vfs.root.mountfrom=ufs:/dev/ufsid/"

As usual, each patch has it's own changelog.

  N  01/32 xen/vcpu: add missing dummy_vcpu_info to compat
AW   02/32 libxc: split x86 HVM setup_guest into smaller
AW   03/32 libxc: unify xc_dom_p2m_{host/guest}
AW   04/32 libxc: introduce the notion of a container type
AW   05/32 libxc: introduce a domain loader for HVM guest
AW   06/32 libxc: make arch_setup_meminit a xc_dom_arch hook
AW   07/32 libxc: make arch_setup_boot{init/late} xc_dom_arch
AW   08/32 libxc: rework BSP initialization
AW M 09/32 libxc: introduce a xc_dom_arch for hvm-3.0-x86_32
AW M 10/32 libxl: switch HVM domain building to use xc_dom_*
AW   11/32 libxc: remove dead HVM building code
 W M 12/32 xen/x86: add bitmap of enabled emulated devices
  N  13/32 xen/vlapic: fixes for HVM code when running without
   M 14/32 xen/x86: allow disabling the emulated local apic
A  M 15/32 xen/x86: allow disabling the emulated HPET
   M 16/32 xen/x86: allow disabling the pmtimer
A  M 17/32 xen/x86: allow disabling the emulated RTC
A  M 18/32 xen/x86: allow disabling the emulated IO APIC
A  M 19/32 xen/x86: allow disabling the emulated PIC
   M 20/32 xen/x86: set the vPMU interface based on the
A21/32 xen/x86: allow disabling the emulated VGA
A22/32 xen/x86: allow disabling the emulated IOMMU
  N  23/32 xen/x86: make sure the HVM callback vector is
A24/32 xen/x86: allow disabling all emulated devices inside
AW M 25/32 elfnotes: intorduce a new PHYS_ENTRY elfnote
AW   26/32 libxc: allow creating domains without emulated
   M 27/32 xen/x86: allow HVM guests to use hypercalls to bring *
A28/32 xenconsole: try to attach to PV console if HVM fails
   M 29/32 libxc/xen: introduce a start info structure for
AW   30/32 libxc: switch xc_dom_elfloader to be used with
A31/32 libxl: allow the creation of HVM domains without a
   M 32/32 libxl: add support for migrating HVM guests without

A = Acked/Reviewed by Andrew Cooper.
W = Acked/Reviewed by Wei Liu.
N = New in this version.
M = Modified in this version.

* Regarding patch 27/32, with the fixes in order to support the compat layer 
the code is getting quite convoluted, so I think I would rather introduce a 
new VCPUOP_hvm_initialise hypercall, LMKWYT.

Thanks, Roger.

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

[Xen-devel] [PATCH v7 19/32] xen/x86: allow disabling the emulated PIC

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
Acked-by: Andrew Cooper 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v6:
 - Return ENODEV in vpic_load if the vpic is disabled.
 - Add asserts to vpic_irq_{negative/positive}_edge and vpic_ack_pending_irq
   to make sure they are not called when the vpic is disabled.
 - Add a check to vpic_reset in order to prevent calling it with the vpic
   disabled.

Changes since v4:
 - Add Andrew Cooper Acked-by.
---
 xen/arch/x86/hvm/vpic.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vpic.c b/xen/arch/x86/hvm/vpic.c
index 7c2edc8..6a2e87b 100644
--- a/xen/arch/x86/hvm/vpic.c
+++ b/xen/arch/x86/hvm/vpic.c
@@ -377,6 +377,9 @@ static int vpic_save(struct domain *d, hvm_domain_context_t 
*h)
 struct hvm_hw_vpic *s;
 int i;
 
+if ( !has_vpic(d) )
+return 0;
+
 /* Save the state of both PICs */
 for ( i = 0; i < 2 ; i++ )
 {
@@ -392,7 +395,10 @@ static int vpic_load(struct domain *d, 
hvm_domain_context_t *h)
 {
 struct hvm_hw_vpic *s;
 uint16_t inst;
-
+
+if ( !has_vpic(d) )
+return -ENODEV;
+
 /* Which PIC is this? */
 inst = hvm_load_instance(h);
 if ( inst > 1 )
@@ -412,6 +418,9 @@ void vpic_reset(struct domain *d)
 {
 struct hvm_hw_vpic *vpic;
 
+if ( !has_vpic(d) )
+return;
+
 /* Master PIC. */
 vpic = &d->arch.hvm_domain.vpic[0];
 memset(vpic, 0, sizeof(*vpic));
@@ -425,6 +434,9 @@ void vpic_reset(struct domain *d)
 
 void vpic_init(struct domain *d)
 {
+if ( !has_vpic(d) )
+return;
+
 vpic_reset(d);
 
 register_portio_handler(d, 0x20, 2, vpic_intercept_pic_io);
@@ -439,6 +451,7 @@ void vpic_irq_positive_edge(struct domain *d, int irq)
 struct hvm_hw_vpic *vpic = &d->arch.hvm_domain.vpic[irq >> 3];
 uint8_t mask = 1 << (irq & 7);
 
+ASSERT(has_vpic(d));
 ASSERT(irq <= 15);
 ASSERT(vpic_is_locked(vpic));
 
@@ -456,6 +469,7 @@ void vpic_irq_negative_edge(struct domain *d, int irq)
 struct hvm_hw_vpic *vpic = &d->arch.hvm_domain.vpic[irq >> 3];
 uint8_t mask = 1 << (irq & 7);
 
+ASSERT(has_vpic(d));
 ASSERT(irq <= 15);
 ASSERT(vpic_is_locked(vpic));
 
@@ -473,6 +487,8 @@ int vpic_ack_pending_irq(struct vcpu *v)
 int irq, vector;
 struct hvm_hw_vpic *vpic = &v->domain->arch.hvm_domain.vpic[0];
 
+ASSERT(has_vpic(v->domain));
+
 TRACE_2D(TRC_HVM_EMUL_PIC_PEND_IRQ_CALL, vlapic_accept_pic_intr(v),
  vpic->int_output);
 if ( !vlapic_accept_pic_intr(v) || !vpic->int_output )
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 20/32] xen/x86: set the vPMU interface based on the presence of a lapic

[Roger Pau Monne]

Instead of choosing the interface to expose to guests based on the guest
type, do it based on whether the guest has an emulated local apic or not.

Signed-off-by: Roger Pau Monné 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v6:
 - Major rework of the approach.
 - Drop Andrew Cooper Acked-by.

Changes since v4:
 - Add Andrew Cooper Acked-by.
---
 xen/arch/x86/cpu/vpmu.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 8af3df1..e5fe4ef 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -94,7 +94,7 @@ void vpmu_lvtpc_update(uint32_t val)
 vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
 
 /* Postpone APIC updates for PV(H) guests if PMU interrupt is pending */
-if ( is_hvm_vcpu(curr) || !vpmu->xenpmu_data ||
+if ( has_vlapic(curr->domain) || !vpmu->xenpmu_data ||
  !vpmu_is_set(vpmu, VPMU_CACHED) )
 apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
@@ -129,7 +129,7 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
  * and since do_wr/rdmsr may load VPMU context we should save
  * (and unload) it again.
  */
-if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+if ( !has_vlapic(curr->domain) && vpmu->xenpmu_data &&
 vpmu_is_set(vpmu, VPMU_CACHED) )
 {
 vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
@@ -184,7 +184,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 return;
 
 /* PV(H) guest */
-if ( !is_hvm_vcpu(sampling) || (vpmu_mode & XENPMU_MODE_ALL) )
+if ( !has_vlapic(sampling->domain) || (vpmu_mode & XENPMU_MODE_ALL) )
 {
 const struct cpu_user_regs *cur_regs;
 uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
@@ -411,7 +411,8 @@ int vpmu_load(struct vcpu *v, bool_t from_guest)
 
 /* Only when PMU is counting, we load PMU context immediately. */
 if ( !vpmu_is_set(vpmu, VPMU_RUNNING) ||
- (!is_hvm_vcpu(vpmu_vcpu(vpmu)) && vpmu_is_set(vpmu, VPMU_CACHED)) )
+ (!has_vlapic(vpmu_vcpu(vpmu)->domain) &&
+ vpmu_is_set(vpmu, VPMU_CACHED)) )
 return 0;
 
 if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 26/32] libxc: allow creating domains without emulated devices.

[Roger Pau Monne]

Introduce a new flag in xc_dom_image that turns on and off the emulated
devices. This prevents creating the VGA hole, the hvm_info page and the
ioreq server pages. libxl unconditionally sets it to true for all HVM
domains at the moment.

Signed-off-by: Roger Pau Monné 
Acked-by: Wei Liu 
Reviewed-by: Andrew Cooper 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v5:
 - Add Andrew Cooper Reviewed-by.

Changes since v4:
 - Store the size of the VGA hole inside of the xc_dom_image struct and set
   it from libxl.
 - Rename dom->emulation to dom->device_model (no functional change).
 - Add Wei Liu Acked-by.

Changes since v3:
 - Explain the meaning of the "emulation" xc_dom_image field.
---
 tools/libxc/include/xc_dom.h |  4 +++
 tools/libxc/xc_dom_x86.c | 73 
 tools/libxl/libxl_dom.c  |  2 ++
 tools/libxl/libxl_internal.h |  1 +
 4 files changed, 47 insertions(+), 33 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index e52b023..720b218 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -191,6 +191,10 @@ struct xc_dom_image {
 xen_pfn_t mmio_size;
 xen_pfn_t lowmem_end;
 xen_pfn_t highmem_end;
+xen_pfn_t vga_hole_size;
+
+/* If unset disables the setup of the IOREQ pages. */
+bool device_model;
 
 /* Extra ACPI tables passed to HVMLOADER */
 struct xc_hvm_firmware_module acpi_module;
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index dd331bf..85b8288 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -49,8 +49,6 @@
 #define X86_CR0_PE 0x01
 #define X86_CR0_ET 0x10
 
-#define VGA_HOLE_SIZE (0x20)
-
 #define SPECIALPAGE_PAGING   0
 #define SPECIALPAGE_ACCESS   1
 #define SPECIALPAGE_SHARING  2
@@ -523,12 +521,15 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
 xc_interface *xch = dom->xch;
 
-if ( (hvm_info_page = xc_map_foreign_range(
-  xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
-  HVM_INFO_PFN)) == NULL )
-goto error_out;
-build_hvm_info(hvm_info_page, dom);
-munmap(hvm_info_page, PAGE_SIZE);
+if ( dom->device_model )
+{
+if ( (hvm_info_page = xc_map_foreign_range(
+  xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
+  HVM_INFO_PFN)) == NULL )
+goto error_out;
+build_hvm_info(hvm_info_page, dom);
+munmap(hvm_info_page, PAGE_SIZE);
+}
 
 /* Allocate and clear special pages. */
 for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
@@ -560,30 +561,33 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
  special_pfn(SPECIALPAGE_SHARING));
 
-/*
- * Allocate and clear additional ioreq server pages. The default
- * server will use the IOREQ and BUFIOREQ special pages above.
- */
-for ( i = 0; i < NR_IOREQ_SERVER_PAGES; i++ )
-ioreq_server_array[i] = ioreq_server_pfn(i);
-
-rc = xc_domain_populate_physmap_exact(xch, domid, NR_IOREQ_SERVER_PAGES, 0,
-  0, ioreq_server_array);
-if ( rc != 0 )
+if ( dom->device_model )
 {
-DOMPRINTF("Could not allocate ioreq server pages.");
-goto error_out;
-}
+/*
+ * Allocate and clear additional ioreq server pages. The default
+ * server will use the IOREQ and BUFIOREQ special pages above.
+ */
+for ( i = 0; i < NR_IOREQ_SERVER_PAGES; i++ )
+ioreq_server_array[i] = ioreq_server_pfn(i);
 
-if ( xc_clear_domain_pages(xch, domid, ioreq_server_pfn(0),
-   NR_IOREQ_SERVER_PAGES) )
+rc = xc_domain_populate_physmap_exact(xch, domid, 
NR_IOREQ_SERVER_PAGES, 0,
+  0, ioreq_server_array);
+if ( rc != 0 )
+{
+DOMPRINTF("Could not allocate ioreq server pages.");
 goto error_out;
+}
 
-/* Tell the domain where the pages are and how many there are */
-xc_hvm_param_set(xch, domid, HVM_PARAM_IOREQ_SERVER_PFN,
- ioreq_server_pfn(0));
-xc_hvm_param_set(xch, domid, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
- NR_IOREQ_SERVER_PAGES);
+if ( xc_clear_domain_pages(xch, domid, ioreq_server_pfn(0),
+   NR_IOREQ_SERVER_PAGES) )
+goto error_out;
+
+/* Tell the domain where the pages are and how many there are */
+xc_hvm_param_set(xch, domid, HVM_PARAM_IOREQ_SERVER_PFN,
+ ioreq_server_pfn(0));
+xc_hvm_param_set(xch, domid, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+ NR_IOREQ_SERVER_PAGES);
+}
 
 /*
  * Identity-map page table is required for 

[Xen-devel] [PATCH v7 13/32] xen/vlapic: fixes for HVM code when running without a vlapic

[Roger Pau Monne]

The HVM related code (SVM, VMX) generally assumed that a local apic is
always present. With the introduction of a HVM mode were the local apic can
be removed, some of this broken code paths arised.

The SVM exit/resume paths unconditionally checked the state of the lapic,
which is wrong if it's been disabled by hardware, fix this by adding the
necessary checks. On the VMX side, make sure we don't add mappings for a
local apic if it's disabled.

In the generic vlapic code, add checks to prevent setting the TSC deadline
timer if the lapic is disabled, and also prevent trying to inject interrupts
from the PIC is the lapic is also disabled.

Signed-off-by: Roger Pau Monné 
Cc: Boris Ostrovsky 
Cc: Suravee Suthikulpanit 
Cc: Aravind Gopalakrishnan 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Eddie Dong 
Cc: Kevin Tian 
---
 xen/arch/x86/hvm/svm/svm.c | 18 ++
 xen/arch/x86/hvm/vlapic.c  |  7 ++-
 xen/arch/x86/hvm/vmx/vmx.c |  3 ++-
 3 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 8de41fa..404634b 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1035,6 +1035,7 @@ static void noreturn svm_do_resume(struct vcpu *v)
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
 bool_t debug_state = v->domain->debugger_attached;
 bool_t vcpu_guestmode = 0;
+struct vlapic *vlapic = vcpu_vlapic(v);
 
 if ( nestedhvm_enabled(v->domain) && nestedhvm_vcpu_in_guestmode(v) )
 vcpu_guestmode = 1;
@@ -1058,14 +1059,14 @@ static void noreturn svm_do_resume(struct vcpu *v)
 hvm_asid_flush_vcpu(v);
 }
 
-if ( !vcpu_guestmode )
+if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) )
 {
 vintr_t intr;
 
 /* Reflect the vlapic's TPR in the hardware vtpr */
 intr = vmcb_get_vintr(vmcb);
 intr.fields.tpr =
-(vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) & 0xFF) >> 4;
+(vlapic_get_reg(vlapic, APIC_TASKPRI) & 0xFF) >> 4;
 vmcb_set_vintr(vmcb, intr);
 }
 
@@ -2294,6 +2295,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 int inst_len, rc;
 vintr_t intr;
 bool_t vcpu_guestmode = 0;
+struct vlapic *vlapic = vcpu_vlapic(v);
 
 hvm_invalidate_regs_fields(regs);
 
@@ -2311,11 +2313,12 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
  * NB. We need to preserve the low bits of the TPR to make checked builds
  * of Windows work, even though they don't actually do anything.
  */
-if ( !vcpu_guestmode ) {
+if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) )
+{
 intr = vmcb_get_vintr(vmcb);
-vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI,
+vlapic_set_reg(vlapic, APIC_TASKPRI,
((intr.fields.tpr & 0x0F) << 4) |
-   (vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) & 0x0F));
+   (vlapic_get_reg(vlapic, APIC_TASKPRI) & 0x0F));
 }
 
 exit_reason = vmcb->exitcode;
@@ -2697,14 +2700,13 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 }
 
   out:
-if ( vcpu_guestmode )
-/* Don't clobber TPR of the nested guest. */
+if ( vcpu_guestmode || vlapic_hw_disabled(vlapic) )
 return;
 
 /* The exit may have updated the TPR: reflect this in the hardware vtpr */
 intr = vmcb_get_vintr(vmcb);
 intr.fields.tpr =
-(vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) & 0xFF) >> 4;
+(vlapic_get_reg(vlapic, APIC_TASKPRI) & 0xFF) >> 4;
 vmcb_set_vintr(vmcb, intr);
 }
 
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index b893b40..229f122 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1042,7 +1042,9 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t 
value)
 uint64_t guest_tsc;
 struct vcpu *v = vlapic_vcpu(vlapic);
 
-/* may need to exclude some other conditions like vlapic->hw.disabled */
+if ( vlapic_hw_disabled(vlapic) )
+return;
+
 if ( !vlapic_lvtt_tdt(vlapic) )
 {
 HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "ignore tsc deadline msr write");
@@ -1118,6 +1120,9 @@ static int __vlapic_accept_pic_intr(struct vcpu *v)
 
 int vlapic_accept_pic_intr(struct vcpu *v)
 {
+if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
+return -ENODEV;
+
 TRACE_2D(TRC_HVM_EMUL_LAPIC_PIC_INTR,
  (v == v->domain->arch.hvm_domain.i8259_target),
  v ? __vlapic_accept_pic_intr(v) : -1);
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index bbec0e8..63b7a24 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2412,7 +2412,8 @@ static void vmx_install_vlapic_mapping(struct vcpu *v)
 {
 paddr_t virt_page_ma, apic_page_ma;
 
-if ( !cpu_has_vmx_virtualize_apic_accesses )
+if ( !cpu_has_vmx_virtualize_apic_accesses ||
+ v->domain->arch.hvm_domain.vmx.apic_access_mfn == 0 )
 r

[Xen-devel] [PATCH v7 23/32] xen/x86: make sure the HVM callback vector is correctly set

[Roger Pau Monne]

If certain devices (like the local or the io apic) are disabled some modes
of operation of the HVM event channel callback cannot be used. Make sure Xen
doesn't try to setup them.

Signed-off-by: Roger Pau Monné 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/irq.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 990a2ca..0f3ab6c 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -330,6 +330,10 @@ void hvm_set_callback_via(struct domain *d, uint64_t via)
  (via_type > HVMIRQ_callback_vector) )
 via_type = HVMIRQ_callback_none;
 
+if ( via_type != HVMIRQ_callback_vector &&
+ (!has_vlapic(d) || !has_vioapic(d) || !has_vpic(d)) )
+return;
+
 spin_lock(&d->arch.hvm_domain.irq_lock);
 
 /* Tear down old callback via. */
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 21/32] xen/x86: allow disabling the emulated VGA

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
Acked-by: Andrew Cooper 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - Add Andrew Cooper Acked-by.
---
 xen/arch/x86/hvm/stdvga.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/x86/hvm/stdvga.c b/xen/arch/x86/hvm/stdvga.c
index f50bff7..a3296bd 100644
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -555,6 +555,9 @@ void stdvga_init(struct domain *d)
 void *p;
 int i;
 
+if ( !has_vvga(d) )
+return;
+
 memset(s, 0, sizeof(*s));
 spin_lock_init(&s->lock);
 
@@ -594,6 +597,9 @@ void stdvga_deinit(struct domain *d)
 struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
 int i;
 
+if ( !has_vvga(d) )
+return;
+
 for ( i = 0; i != ARRAY_SIZE(s->vram_page); i++ )
 {
 if ( s->vram_page[i] == NULL )
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 25/32] elfnotes: intorduce a new PHYS_ENTRY elfnote

[Roger Pau Monne]

This new elfnote contains the 32bit entry point into the kernel. Xen will
use this entry point in order to launch the guest kernel in 32bit protected
mode with paging disabled.

Signed-off-by: Roger Pau Monné 
Acked-by: Wei Liu 
Reviewed-by: Andrew Cooper 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v6:
 - Reword a comment.

Changes since v4:
 - Add Andrew Cooper Reviewed-by and Wei Liu Acked-by.
---
 tools/xcutils/readnotes.c  |  3 +++
 xen/common/libelf/libelf-dominfo.c |  4 
 xen/include/public/elfnote.h   | 12 +++-
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/xcutils/readnotes.c b/tools/xcutils/readnotes.c
index 5fa445e..e682dd1 100644
--- a/tools/xcutils/readnotes.c
+++ b/tools/xcutils/readnotes.c
@@ -159,6 +159,9 @@ static unsigned print_notes(struct elf_binary *elf, 
ELF_HANDLE_DECL(elf_note) st
case XEN_ELFNOTE_L1_MFN_VALID:
print_l1_mfn_valid_note("L1_MFN_VALID", elf , note);
break;
+   case XEN_ELFNOTE_PHYS32_ENTRY:
+   print_numeric_note("PHYS32_ENTRY", elf , note);
+   break;
default:
printf("unknown note type %#x\n",
   (unsigned)elf_uval(elf, note, type));
diff --git a/xen/common/libelf/libelf-dominfo.c 
b/xen/common/libelf/libelf-dominfo.c
index 3de1c23..dacd4ba 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -119,6 +119,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
 [XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", 1},
 [XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", 0 },
 [XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", 0 },
+[XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", 0 },
 };
 /* *INDENT-ON* */
 
@@ -212,6 +213,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
 elf, note, sizeof(*parms->f_supported), i);
 break;
 
+case XEN_ELFNOTE_PHYS32_ENTRY:
+parms->phys_entry = val;
+break;
 }
 return 0;
 }
diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 3824a94..353985f 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -200,9 +200,19 @@
 #define XEN_ELFNOTE_SUPPORTED_FEATURES 17
 
 /*
+ * Physical entry point into the kernel.
+ *
+ * 32bit entry point into the kernel. When requested to launch the
+ * guest kernel in a HVM container, Xen will use this entry point to
+ * launch the guest in 32bit protected mode with paging disabled.
+ * Ignored otherwise.
+ */
+#define XEN_ELFNOTE_PHYS32_ENTRY 18
+
+/*
  * The number of the highest elfnote defined.
  */
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_SUPPORTED_FEATURES
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
 
 /*
  * System information exported through crash notes.
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 05/32] libxc: introduce a domain loader for HVM guest firmware

[Roger Pau Monne]

Introduce a very simple (and dummy) domain loader to be used to load the
firmware (hvmloader) into HVM guests. Since hmvloader is just a 32bit elf
executable the loader is fairly simple.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v3:
 - s/__FUNCTION__/__func__/g
 - Fix style errors in xc_dom_hvmloader.c.
 - Add Andrew Cooper Reviewed-by.
 - Add Wei Acked-by.
---
 tools/libxc/Makefile   |   1 +
 tools/libxc/include/xc_dom.h   |   8 ++
 tools/libxc/xc_dom_hvmloader.c | 313 +
 xen/include/xen/libelf.h   |   1 +
 4 files changed, 323 insertions(+)
 create mode 100644 tools/libxc/xc_dom_hvmloader.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index a0f899b..baaadd6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -84,6 +84,7 @@ GUEST_SRCS-y += xc_dom_core.c xc_dom_boot.c
 GUEST_SRCS-y += xc_dom_elfloader.c
 GUEST_SRCS-$(CONFIG_X86) += xc_dom_bzimageloader.c
 GUEST_SRCS-$(CONFIG_X86) += xc_dom_decompress_lz4.c
+GUEST_SRCS-$(CONFIG_X86) += xc_dom_hvmloader.c
 GUEST_SRCS-$(CONFIG_ARM) += xc_dom_armzimageloader.c
 GUEST_SRCS-y += xc_dom_binloader.c
 GUEST_SRCS-y += xc_dom_compat_linux.c
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 30fa8c5..88c5c80 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -14,6 +14,7 @@
  */
 
 #include 
+#include 
 
 #define INVALID_P2M_ENTRY   ((xen_pfn_t)-1)
 
@@ -183,6 +184,13 @@ struct xc_dom_image {
 XC_DOM_PV_CONTAINER,
 XC_DOM_HVM_CONTAINER,
 } container_type;
+
+/* HVM specific fields. */
+/* Extra ACPI tables passed to HVMLOADER */
+struct xc_hvm_firmware_module acpi_module;
+
+/* Extra SMBIOS structures passed to HVMLOADER */
+struct xc_hvm_firmware_module smbios_module;
 };
 
 /* --- pluggable kernel loader - */
diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
new file mode 100644
index 000..79a3b99
--- /dev/null
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -0,0 +1,313 @@
+/*
+ * Xen domain builder -- HVM specific bits.
+ *
+ * Parse and load ELF firmware images for HVM domains.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  
USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xg_private.h"
+#include "xc_dom.h"
+#include "xc_bitops.h"
+
+/*  */
+/* parse elf binary */
+
+static elf_negerrnoval check_elf_kernel(struct xc_dom_image *dom, bool verbose)
+{
+if ( dom->kernel_blob == NULL )
+{
+if ( verbose )
+xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+ "%s: no kernel image loaded", __func__);
+return -EINVAL;
+}
+
+if ( !elf_is_elfbinary(dom->kernel_blob, dom->kernel_size) )
+{
+if ( verbose )
+xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
+ "%s: kernel is not an ELF image", __func__);
+return -EINVAL;
+}
+return 0;
+}
+
+static elf_negerrnoval xc_dom_probe_hvm_kernel(struct xc_dom_image *dom)
+{
+struct elf_binary elf;
+int rc;
+
+/* This loader is designed for HVM guest firmware. */
+if ( dom->container_type != XC_DOM_HVM_CONTAINER )
+return -EINVAL;
+
+rc = check_elf_kernel(dom, 0);
+if ( rc != 0 )
+return rc;
+
+rc = elf_init(&elf, dom->kernel_blob, dom->kernel_size);
+if ( rc != 0 )
+return rc;
+
+/*
+ * We need to check that there are no Xen ELFNOTES, or
+ * else we might be trying to load a PV kernel.
+ */
+elf_parse_binary(&elf);
+rc = elf_xen_parse(&elf, &dom->parms);
+if ( rc == 0 )
+return -EINVAL;
+
+return 0;
+}
+
+static elf_errorstatus xc_dom_parse_hvm_kernel(struct xc_dom_image *dom)
+/*
+ * This function sometimes returns -1 for error and sometimes
+ * an errno value.  ?!?!
+ */
+{
+struct elf_binary *elf;
+elf_errorstatus rc;
+
+rc = check_elf_kernel(dom, 1);
+if ( 

[Xen-devel] [PATCH v7 32/32] libxl: add support for migrating HVM guests without a device model

[Roger Pau Monne]

Only some minor libxl changes are needed in order to be able to migrate HVM
guests without a device model, no hypervisor changes are needed.

This change prevents sending the emulator context if the device model
version is set to none.

Signed-off-by: Roger Pau Monné 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl_dom.c  | 3 +++
 tools/libxl/libxl_dom_suspend.c  | 2 ++
 tools/libxl/libxl_stream_write.c | 8 +++-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7e8ae14..b40d744 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1310,6 +1310,9 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
 case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
 domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
 break;
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
+break;
 default:
 LOG(ERROR,"logdirty switch failed"
 ", no valid device model version found, abandoning suspend");
diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index 4cc01ad..3313ad1 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -43,6 +43,8 @@ int libxl__domain_suspend_device_model(libxl__gc *gc,
 if (ret)
 unlink(filename);
 break;
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+break;
 default:
 return ERROR_INVAL;
 }
diff --git a/tools/libxl/libxl_stream_write.c b/tools/libxl/libxl_stream_write.c
index 52a60d7..5551560 100644
--- a/tools/libxl/libxl_stream_write.c
+++ b/tools/libxl/libxl_stream_write.c
@@ -232,6 +232,9 @@ void libxl__stream_write_start(libxl__egc *egc,
 stream->emu_sub_hdr.id = EMULATOR_QEMU_UPSTREAM;
 break;
 
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+break;
+
 default:
 rc = ERROR_FAIL;
 LOG(ERROR, "Unknown emulator for HVM domain");
@@ -387,8 +390,11 @@ static void emulator_xenstore_record_done(libxl__egc *egc,
   libxl__stream_write_state *stream)
 {
 libxl__domain_suspend_state *dss = stream->dss;
+STATE_AO_GC(stream->ao);
 
-if (dss->type == LIBXL_DOMAIN_TYPE_HVM)
+if (dss->type == LIBXL_DOMAIN_TYPE_HVM &&
+libxl__device_model_version_running(gc, dss->domid) !=
+LIBXL_DEVICE_MODEL_VERSION_NONE)
 write_emulator_context_record(egc, stream);
 else {
 if (stream->in_checkpoint)
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 24/32] xen/x86: allow disabling all emulated devices inside of Xen

[Roger Pau Monne]

Only allow enabling or disabling all the emulated devices inside of Xen,
right now Xen doesn't support enabling specific emulated devices only.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v5:
 - Add Andrew Cooper Reviewed-by.
---
 xen/arch/x86/domain.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 79182a4..a3b1c9b 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -526,7 +526,8 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
d->domain_id, config->emulation_flags);
 return -EINVAL;
 }
-if ( (is_hvm_domain(d) && config->emulation_flags != XEN_X86_EMU_ALL) ||
+if ( (is_hvm_domain(d) && config->emulation_flags != XEN_X86_EMU_ALL &&
+ config->emulation_flags != 0) ||
  (is_pv_domain(d) && config->emulation_flags != 0) )
 {
 printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation with "
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 31/32] libxl: allow the creation of HVM domains without a device model.

[Roger Pau Monne]

Replace the firmware loaded into HVM guests with an OS kernel. Since the HVM
builder now uses the PV xc_dom_* set of functions this kernel will be parsed
and loaded inside the guest like on PV, but the container is a pure HVM
guest.

Also, if device_model_version is set to none or a device model for the
specified domain is not present unconditinally set the nic type to
LIBXL_NIC_TYPE_VIF.

Signed-off-by: Roger Pau Monné 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v5:
 - Add Wei Liu Acked-by.

Changes since v4:
 - Set dom->mmio_size to match the size of the special pages if there's no
   device model for the guest. This implies moving NR_SPECIAL_PAGES and
   X86_HVM_END_SPECIAL_REGION to a public header so they can be known by
   libxl when creating the memory map.
 - Reword the xl.cfg man page description of the "none" device model option.
 - Use libxl__device_model_version_running instead of creating a new
   function.

Changes since v3:
 - Add explicit /* fall through */ comments.
 - Expand libxl__device_nic_setdefault so that it sets the right nic type
   for HVMlite guests.
 - Remove stray space in hvm_build_set_params.
 - Fix the error paths of libxl__domain_firmware.
---
 docs/man/xl.cfg.pod.5|  5 +++
 tools/libxc/include/xc_dom.h |  2 ++
 tools/libxc/xc_dom_x86.c | 15 -
 tools/libxl/libxl.c  | 44 ++
 tools/libxl/libxl_create.c   | 16 +-
 tools/libxl/libxl_dm.c   |  3 +-
 tools/libxl/libxl_dom.c  | 74 ++--
 tools/libxl/libxl_internal.h |  9 +-
 tools/libxl/libxl_types.idl  |  1 +
 tools/libxl/libxl_x86.c  | 15 ++---
 tools/libxl/xl_cmdimpl.c |  2 ++
 11 files changed, 136 insertions(+), 50 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index f8fa48f..f627ac6 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1781,6 +1781,11 @@ This device-model is the default for Linux dom0.
 Use the device-model based upon the historical Xen fork of Qemu.
 This device-model is still the default for NetBSD dom0.
 
+=item B
+
+Don't use any device model. This requires a kernel capable of booting
+without emulated devices.
+
 =back
 
 It is recommended to accept the default value for new guests.  If
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 720b218..4939f76 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -17,6 +17,8 @@
 #include 
 
 #define INVALID_P2M_ENTRY   ((xen_pfn_t)-1)
+#define X86_HVM_NR_SPECIAL_PAGES8
+#define X86_HVM_END_SPECIAL_REGION  0xff000u
 
 /* --- typedefs and structs  */
 
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 20a39b7..c3bb7a3 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -57,8 +57,8 @@
 #define SPECIALPAGE_IOREQ5
 #define SPECIALPAGE_IDENT_PT 6
 #define SPECIALPAGE_CONSOLE  7
-#define NR_SPECIAL_PAGES 8
-#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+#define special_pfn(x) \
+(X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES + (x))
 
 #define NR_IOREQ_SERVER_PAGES 8
 #define ioreq_server_pfn(x) (special_pfn(0) - NR_IOREQ_SERVER_PAGES + (x))
@@ -517,7 +517,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 void *hvm_info_page;
 uint32_t *ident_pt, domid = dom->guest_domid;
 int rc;
-xen_pfn_t special_array[NR_SPECIAL_PAGES];
+xen_pfn_t special_array[X86_HVM_NR_SPECIAL_PAGES];
 xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
 xc_interface *xch = dom->xch;
 
@@ -532,18 +532,19 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 }
 
 /* Allocate and clear special pages. */
-for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
+for ( i = 0; i < X86_HVM_NR_SPECIAL_PAGES; i++ )
 special_array[i] = special_pfn(i);
 
-rc = xc_domain_populate_physmap_exact(xch, domid, NR_SPECIAL_PAGES, 0, 0,
-  special_array);
+rc = xc_domain_populate_physmap_exact(xch, domid, X86_HVM_NR_SPECIAL_PAGES,
+  0, 0, special_array);
 if ( rc != 0 )
 {
 DOMPRINTF("Could not allocate special pages.");
 goto error_out;
 }
 
-if ( xc_clear_domain_pages(xch, domid, special_pfn(0), NR_SPECIAL_PAGES) )
+if ( xc_clear_domain_pages(xch, domid, special_pfn(0),
+   X86_HVM_NR_SPECIAL_PAGES) )
 goto error_out;
 
 xc_hvm_param_set(xch, domid, HVM_PARAM_STORE_PFN,
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e4ea476..0948b9d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1044,11 +1044,14 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
 }
 
 if (type == LIBXL_DOMAIN_TYPE_HVM) {
-rc = libxl__domain_resume_device_model(gc, domid);

[Xen-devel] [PATCH v7 01/32] xen/vcpu: add missing dummy_vcpu_info to compat VCPUOP_initialise

[Roger Pau Monne]

This check is missing from the compat version when compared to the
non-compat version.

Signed-off-by: Roger Pau Monné 
Cc: Ian Campbell 
Cc: Jan Beulich 
Cc: Tim Deegan 
Cc: Andrew Cooper 
---
 xen/common/compat/domain.c | 5 +
 xen/common/domain.c| 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/common/compat/domain.c b/xen/common/compat/domain.c
index 3ca4ef7..5dc7d94 100644
--- a/xen/common/compat/domain.c
+++ b/xen/common/compat/domain.c
@@ -23,6 +23,8 @@ CHECK_SIZE_(struct, vcpu_info);
 CHECK_vcpu_register_vcpu_info;
 #undef xen_vcpu_register_vcpu_info
 
+extern vcpu_info_t dummy_vcpu_info;
+
 int compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 {
 struct domain *d = current->domain;
@@ -38,6 +40,9 @@ int compat_vcpu_op(int cmd, unsigned int vcpuid, 
XEN_GUEST_HANDLE_PARAM(void) ar
 {
 struct compat_vcpu_guest_context *cmp_ctxt;
 
+if ( v->vcpu_info == &dummy_vcpu_info )
+return -EINVAL;
+
 if ( (cmp_ctxt = xmalloc(struct compat_vcpu_guest_context)) == NULL )
 {
 rc = -ENOMEM;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index cda60a9..cec0dcf 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -70,7 +70,7 @@ integer_param("hardware_dom", hardware_domid);
 
 struct vcpu *idle_vcpu[NR_CPUS] __read_mostly;
 
-static vcpu_info_t dummy_vcpu_info;
+vcpu_info_t dummy_vcpu_info;
 
 static void __domain_finalise_shutdown(struct domain *d)
 {
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 02/32] libxc: split x86 HVM setup_guest into smaller logical functions

[Roger Pau Monne]

This is just a preparatory change to clean up the code in setup_guest.
Should not introduce any functional changes.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v3:
 - Add Andrew Cooper Reviewed-by.
 - Add Wei Acked-by.
---
 tools/libxc/xc_hvm_build_x86.c | 198 -
 1 file changed, 117 insertions(+), 81 deletions(-)

diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index ea250dd..4d3736b 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -231,28 +231,20 @@ static int check_mmio_hole(uint64_t start, uint64_t 
memsize,
 return 1;
 }
 
-static int setup_guest(xc_interface *xch,
-   uint32_t dom, struct xc_hvm_build_args *args,
-   char *image, unsigned long image_size)
+static int xc_hvm_populate_memory(xc_interface *xch, uint32_t dom,
+  struct xc_hvm_build_args *args,
+  xen_pfn_t *page_array)
 {
-xen_pfn_t *page_array = NULL;
 unsigned long i, vmemid, nr_pages = args->mem_size >> PAGE_SHIFT;
 unsigned long p2m_size;
 unsigned long target_pages = args->mem_target >> PAGE_SHIFT;
-unsigned long entry_eip, cur_pages, cur_pfn;
-void *hvm_info_page;
-uint32_t *ident_pt;
-struct elf_binary elf;
-uint64_t v_start, v_end;
-uint64_t m_start = 0, m_end = 0;
+unsigned long cur_pages, cur_pfn;
 int rc;
 xen_capabilities_info_t caps;
 unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
 stat_1gb_pages = 0;
 unsigned int memflags = 0;
 int claim_enabled = args->claim_enabled;
-xen_pfn_t special_array[NR_SPECIAL_PAGES];
-xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
 uint64_t total_pages;
 xen_vmemrange_t dummy_vmemrange[2];
 unsigned int dummy_vnode_to_pnode[1];
@@ -260,19 +252,6 @@ static int setup_guest(xc_interface *xch,
 unsigned int *vnode_to_pnode;
 unsigned int nr_vmemranges, nr_vnodes;
 
-memset(&elf, 0, sizeof(elf));
-if ( elf_init(&elf, image, image_size) != 0 )
-{
-PERROR("Could not initialise ELF image");
-goto error_out;
-}
-
-xc_elf_set_logfile(xch, &elf, 1);
-
-elf_parse_binary(&elf);
-v_start = 0;
-v_end = args->mem_size;
-
 if ( nr_pages > target_pages )
 memflags |= XENMEMF_populate_on_demand;
 
@@ -345,24 +324,6 @@ static int setup_guest(xc_interface *xch,
 goto error_out;
 }
 
-if ( modules_init(args, v_end, &elf, &m_start, &m_end) != 0 )
-{
-ERROR("Insufficient space to load modules.");
-goto error_out;
-}
-
-DPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n");
-DPRINTF("  Loader:   %016"PRIx64"->%016"PRIx64"\n", elf.pstart, elf.pend);
-DPRINTF("  Modules:  %016"PRIx64"->%016"PRIx64"\n", m_start, m_end);
-DPRINTF("  TOTAL:%016"PRIx64"->%016"PRIx64"\n", v_start, v_end);
-DPRINTF("  ENTRY:%016"PRIx64"\n", elf_uval(&elf, elf.ehdr, e_entry));
-
-if ( (page_array = malloc(p2m_size * sizeof(xen_pfn_t))) == NULL )
-{
-PERROR("Could not allocate memory.");
-goto error_out;
-}
-
 for ( i = 0; i < p2m_size; i++ )
 page_array[i] = ((xen_pfn_t)-1);
 for ( vmemid = 0; vmemid < nr_vmemranges; vmemid++ )
@@ -564,7 +525,54 @@ static int setup_guest(xc_interface *xch,
 DPRINTF("  4KB PAGES: 0x%016lx\n", stat_normal_pages);
 DPRINTF("  2MB PAGES: 0x%016lx\n", stat_2mb_pages);
 DPRINTF("  1GB PAGES: 0x%016lx\n", stat_1gb_pages);
-
+
+rc = 0;
+goto out;
+ error_out:
+rc = -1;
+ out:
+
+/* ensure no unclaimed pages are left unused */
+xc_domain_claim_pages(xch, dom, 0 /* cancels the claim */);
+
+return rc;
+}
+
+static int xc_hvm_load_image(xc_interface *xch,
+   uint32_t dom, struct xc_hvm_build_args *args,
+   xen_pfn_t *page_array)
+{
+unsigned long entry_eip, image_size;
+struct elf_binary elf;
+uint64_t v_start, v_end;
+uint64_t m_start = 0, m_end = 0;
+char *image;
+int rc;
+
+image = xc_read_image(xch, args->image_file_name, &image_size);
+if ( image == NULL )
+return -1;
+
+memset(&elf, 0, sizeof(elf));
+if ( elf_init(&elf, image, image_size) != 0 )
+goto error_out;
+
+xc_elf_set_logfile(xch, &elf, 1);
+
+elf_parse_binary(&elf);
+v_start = 0;
+v_end = args->mem_size;
+
+if ( modules_init(args, v_end, &elf, &m_start, &m_end) != 0 )
+{
+ERROR("Insufficient space to load modules.");
+goto error_out;
+}
+
+DPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n");
+DPRINTF("  Loader:   %016"PRIx64"->%016"PRIx64"\n", elf.pstart, elf.pend);
+DPRINTF("  Modules:  %016"PRIx64"->%016"PRIx64"\n", m_start, m_end);
+
 if ( loadelfimage(xch, &elf, dom

[Xen-devel] [PATCH v7 11/32] libxc: remove dead HVM building code

[Roger Pau Monne]

Remove xc_hvm_build_x86.c and xc_hvm_build_arm.c since xc_hvm_build is not
longer used in order to create HVM guests.

Signed-off-by: Roger Pau Monné 
Acked-by: Wei Liu 
Reviewed-by: Andrew Cooper 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v4:
 - Add Wei Liu Acked-by and Andrew Cooper Reviewed-by.
---
 tools/libxc/Makefile  |   2 -
 tools/libxc/include/xenguest.h|  44 ---
 tools/libxc/xc_hvm_build_arm.c|  48 ---
 tools/libxc/xc_hvm_build_x86.c| 808 --
 tools/libxc/xg_private.c  |   9 -
 tools/python/xen/lowlevel/xc/xc.c |  81 
 6 files changed, 992 deletions(-)
 delete mode 100644 tools/libxc/xc_hvm_build_arm.c
 delete mode 100644 tools/libxc/xc_hvm_build_x86.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index baaadd6..818f2e4 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -91,9 +91,7 @@ GUEST_SRCS-y += xc_dom_compat_linux.c
 
 GUEST_SRCS-$(CONFIG_X86) += xc_dom_x86.c
 GUEST_SRCS-$(CONFIG_X86) += xc_cpuid_x86.c
-GUEST_SRCS-$(CONFIG_X86) += xc_hvm_build_x86.c
 GUEST_SRCS-$(CONFIG_ARM) += xc_dom_arm.c
-GUEST_SRCS-$(CONFIG_ARM) += xc_hvm_build_arm.c
 
 ifeq ($(CONFIG_LIBXC_MINIOS),y)
 GUEST_SRCS-y += xc_dom_decompress_unsafe.c
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 1a1a185..ec67fbd 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -205,50 +205,6 @@ struct xc_hvm_firmware_module {
 uint64_t  guest_addr_out;
 };
 
-struct xc_hvm_build_args {
-uint64_t mem_size;   /* Memory size in bytes. */
-uint64_t mem_target; /* Memory target in bytes. */
-uint64_t mmio_size;  /* Size of the MMIO hole in bytes. */
-const char *image_file_name; /* File name of the image to load. */
-
-/* Extra ACPI tables passed to HVMLOADER */
-struct xc_hvm_firmware_module acpi_module;
-
-/* Extra SMBIOS structures passed to HVMLOADER */
-struct xc_hvm_firmware_module smbios_module;
-/* Whether to use claim hypercall (1 - enable, 0 - disable). */
-int claim_enabled;
-
-/* vNUMA information*/
-xen_vmemrange_t *vmemranges;
-unsigned int nr_vmemranges;
-unsigned int *vnode_to_pnode;
-unsigned int nr_vnodes;
-
-/* Out parameters  */
-uint64_t lowmem_end;
-uint64_t highmem_end;
-uint64_t mmio_start;
-};
-
-/**
- * Build a HVM domain.
- * @parm xch  libxc context handle.
- * @parm domiddomain ID for the new domain.
- * @parm hvm_args parameters for the new domain.
- *
- * The memory size and image file parameters are required, the rest
- * are optional.
- */
-int xc_hvm_build(xc_interface *xch, uint32_t domid,
- struct xc_hvm_build_args *hvm_args);
-
-int xc_hvm_build_target_mem(xc_interface *xch,
-uint32_t domid,
-int memsize,
-int target,
-const char *image_name);
-
 /*
  * Sets *lockfd to -1.
  * Has deallocated everything even on error.
diff --git a/tools/libxc/xc_hvm_build_arm.c b/tools/libxc/xc_hvm_build_arm.c
deleted file mode 100644
index 14f7c45..000
--- a/tools/libxc/xc_hvm_build_arm.c
+++ /dev/null
@@ -1,48 +0,0 @@
-/**
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; If not, see .
- *
- * Copyright (c) 2011, Citrix Systems
- */
-
-#include 
-#include 
-#include 
-#include 
-
-int xc_hvm_build(xc_interface *xch, uint32_t domid,
- struct xc_hvm_build_args *hvm_args)
-{
-errno = ENOSYS;
-return -1;
-}
-
-int xc_hvm_build_target_mem(xc_interface *xch,
-   uint32_t domid,
-   int memsize,
-   int target,
-   const char *image_name)
-{
-errno = ENOSYS;
-return -1;
-}
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
deleted file mode 100644
index 4d3736b..000
--- a/tools/libxc/xc_hvm_build_x86.c
+++ /dev/null
@@ -1,808 +0,0 @@
-/

[Xen-devel] [PATCH v7 29/32] libxc/xen: introduce a start info structure for HVMlite guests

[Roger Pau Monne]

This structure contains the physical address of the command line, as well as
the physical address of the list of loaded modules. The physical address of
this structure is passed to the guest at boot time in the %ebx register.

Signed-off-by: Roger Pau Monné 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v6:
 - Add a check to make sure the start info data is placed below 4GB.
 - Make sure byte addresses are treated as uintptr_t.
 - Fix single-line comment.

Changes since v5:
 - Change some of the calculations performed to get the total size of the
   start_info region.
 - Replace the mention of HVMlite in a comment with PVH.
 - Don't use 64bit integers in hvm_modlist_entry.
---
 tools/libxc/xc_dom_x86.c | 68 +++-
 xen/include/public/xen.h | 17 
 2 files changed, 84 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 85b8288..20a39b7 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -561,7 +561,70 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
  special_pfn(SPECIALPAGE_SHARING));
 
-if ( dom->device_model )
+if ( !dom->device_model )
+{
+struct xc_dom_seg seg;
+struct hvm_start_info *start_info;
+char *cmdline;
+struct hvm_modlist_entry *modlist;
+void *start_page;
+size_t cmdline_size = 0;
+size_t start_info_size = sizeof(*start_info);
+
+if ( dom->cmdline )
+{
+cmdline_size = ROUNDUP(strlen(dom->cmdline) + 1, 8);
+start_info_size += cmdline_size;
+
+}
+if ( dom->ramdisk_blob )
+start_info_size += sizeof(*modlist); /* Limited to one module. */
+
+rc = xc_dom_alloc_segment(dom, &seg, "HVMlite start info", 0,
+  start_info_size);
+if ( rc != 0 )
+{
+DOMPRINTF("Unable to reserve memory for the start info");
+goto out;
+}
+
+start_page = xc_map_foreign_range(xch, domid, start_info_size,
+  PROT_READ | PROT_WRITE,
+  seg.pfn);
+if ( start_page == NULL )
+{
+DOMPRINTF("Unable to map HVM start info page");
+goto error_out;
+}
+
+start_info = start_page;
+cmdline = start_page + sizeof(*start_info);
+modlist = start_page + sizeof(*start_info) + cmdline_size;
+
+if ( dom->cmdline )
+{
+strncpy(cmdline, dom->cmdline, MAX_GUEST_CMDLINE);
+cmdline[MAX_GUEST_CMDLINE - 1] = '\0';
+start_info->cmdline_paddr = (seg.pfn << PAGE_SHIFT) +
+((uintptr_t)cmdline - (uintptr_t)start_info);
+}
+
+if ( dom->ramdisk_blob )
+{
+modlist[0].paddr = dom->ramdisk_seg.vstart - dom->parms.virt_base;
+modlist[0].size = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
+start_info->modlist_paddr = (seg.pfn << PAGE_SHIFT) +
+((uintptr_t)modlist - (uintptr_t)start_info);
+start_info->nr_modules = 1;
+}
+
+start_info->magic = HVM_START_MAGIC_VALUE;
+
+munmap(start_page, start_info_size);
+
+dom->start_info_pfn = seg.pfn;
+}
+else
 {
 /*
  * Allocate and clear additional ioreq server pages. The default
@@ -915,6 +978,9 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 /* Set the IP. */
 bsp_ctx.cpu.rip = dom->parms.phys_entry;
 
+if ( dom->start_info_pfn )
+bsp_ctx.cpu.rbx = dom->start_info_pfn << PAGE_SHIFT;
+
 /* Set the end descriptor. */
 bsp_ctx.end_d.typecode = HVM_SAVE_CODE(END);
 bsp_ctx.end_d.instance = 0;
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index ff5547e..709e12c 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -784,6 +784,23 @@ struct start_info {
 };
 typedef struct start_info start_info_t;
 
+/* Start of day structure passed to PVH guests in %ebx. */
+struct hvm_start_info {
+#define HVM_START_MAGIC_VALUE 0x336ec578
+uint32_t magic; /* Contains the magic value 0x336ec578   */
+/* ("xEn3" with the 0x80 bit of the "E" set).*/
+uint32_t flags; /* SIF_xxx flags.*/
+uint32_t cmdline_paddr; /* Physical address of the command line. */
+uint32_t nr_modules;/* Number of modules passed to the kernel.   */
+uint32_t modlist_paddr; /* Physical address of an array of   */
+/* hvm_modlist_entry.*/
+};
+
+struct hvm_modlist_entry {
+uint32_t paddr;  

[Xen-devel] [PATCH v7 03/32] libxc: unify xc_dom_p2m_{host/guest}

[Roger Pau Monne]

Unify both functions into xc_dom_p2m. Should not introduce any functional
change.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Samuel Thibault 
---
Changes since v3:
 - Add Andrew Cooper Reviewed-by.
 - Add Wei Acked-by.
---
 stubdom/grub/kexec.c  |  4 ++--
 tools/libxc/include/xc_dom.h  | 14 ++
 tools/libxc/xc_dom_boot.c | 10 +-
 tools/libxc/xc_dom_compat_linux.c |  4 ++--
 tools/libxc/xc_dom_x86.c  | 32 
 tools/libxl/libxl_dom.c   |  4 ++--
 6 files changed, 29 insertions(+), 39 deletions(-)

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 4c33b25..0b2f4f3 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -358,9 +358,9 @@ void kexec(void *kernel, long kernel_size, void *module, 
long module_size, char
 #ifdef __x86_64__
 MMUEXT_PIN_L4_TABLE,
 #endif
-xc_dom_p2m_host(dom, dom->pgtables_seg.pfn),
+xc_dom_p2m(dom, dom->pgtables_seg.pfn),
 dom->guest_domid)) != 0 ) {
-grub_printf("pin_table(%lx) returned %d\n", xc_dom_p2m_host(dom,
+grub_printf("pin_table(%lx) returned %d\n", xc_dom_p2m(dom,
 dom->pgtables_seg.pfn), rc);
 errnum = ERR_BOOT_FAILURE;
 goto out_remap;
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 602c5cd..e794a13 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -373,19 +373,9 @@ static inline void *xc_dom_vaddr_to_ptr(struct 
xc_dom_image *dom,
 return ptr + offset;
 }
 
-static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t 
pfn)
+static inline xen_pfn_t xc_dom_p2m(struct xc_dom_image *dom, xen_pfn_t pfn)
 {
-if (dom->shadow_enabled)
-return pfn;
-if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + dom->total_pages)
-return INVALID_MFN;
-return dom->p2m_host[pfn - dom->rambase_pfn];
-}
-
-static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
- xen_pfn_t pfn)
-{
-if (xc_dom_feature_translated(dom))
+if ( dom->shadow_enabled || xc_dom_feature_translated(dom) )
 return pfn;
 if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + dom->total_pages)
 return INVALID_MFN;
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 8e06406..7c30f96 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -53,7 +53,7 @@ static int setup_hypercall_page(struct xc_dom_image *dom)
   dom->parms.virt_hypercall, pfn);
 domctl.cmd = XEN_DOMCTL_hypercall_init;
 domctl.domain = dom->guest_domid;
-domctl.u.hypercall_init.gmfn = xc_dom_p2m_guest(dom, pfn);
+domctl.u.hypercall_init.gmfn = xc_dom_p2m(dom, pfn);
 rc = do_domctl(dom->xch, &domctl);
 if ( rc != 0 )
 xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
@@ -83,7 +83,7 @@ static int clear_page(struct xc_dom_image *dom, xen_pfn_t pfn)
 if ( pfn == 0 )
 return 0;
 
-dst = xc_dom_p2m_host(dom, pfn);
+dst = xc_dom_p2m(dom, pfn);
 DOMPRINTF("%s: pfn 0x%" PRIpfn ", mfn 0x%" PRIpfn "",
   __FUNCTION__, pfn, dst);
 rc = xc_clear_domain_page(dom->xch, dom->guest_domid, dst);
@@ -177,7 +177,7 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, 
xen_pfn_t pfn,
 }
 
 for ( i = 0; i < count; i++ )
-entries[i].mfn = xc_dom_p2m_host(dom, pfn + i);
+entries[i].mfn = xc_dom_p2m(dom, pfn + i);
 
 ptr = xc_map_foreign_ranges(dom->xch, dom->guest_domid,
 count << page_shift, PROT_READ | PROT_WRITE, 1 << page_shift,
@@ -434,8 +434,8 @@ int xc_dom_gnttab_init(struct xc_dom_image *dom)
   dom->console_domid, dom->xenstore_domid);
 } else {
 return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
-  xc_dom_p2m_host(dom, dom->console_pfn),
-  xc_dom_p2m_host(dom, dom->xenstore_pfn),
+  xc_dom_p2m(dom, dom->console_pfn),
+  xc_dom_p2m(dom, dom->xenstore_pfn),
   dom->console_domid, dom->xenstore_domid);
 }
 }
diff --git a/tools/libxc/xc_dom_compat_linux.c 
b/tools/libxc/xc_dom_compat_linux.c
index a3abb99..5c1f043 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -64,8 +64,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
 if ( (rc = xc_dom_gnttab_init(dom)) != 0)
 goto out;
 
-*console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
-*store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
+*console_mfn = xc_dom_p2m(dom, dom->console_pfn);
+*store_mfn = xc_dom_p2m(dom, dom->xenstore_pfn);
 
  out:
 

[Xen-devel] [PATCH v7 07/32] libxc: make arch_setup_boot{init/late} xc_dom_arch hooks

[Roger Pau Monne]

This should not introduce any functional change.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v3:
 - Add Andrew Cooper Reviewed-by.
 - Add Wei Acked-by.
---
 tools/libxc/include/xc_dom.h |  7 ++-
 tools/libxc/xc_dom_arm.c | 20 +---
 tools/libxc/xc_dom_boot.c|  4 ++--
 tools/libxc/xc_dom_x86.c | 10 --
 4 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 01739fa..ced6ae2 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -220,6 +220,8 @@ struct xc_dom_arch {
 int (*start_info) (struct xc_dom_image * dom);
 int (*shared_info) (struct xc_dom_image * dom, void *shared_info);
 int (*vcpu) (struct xc_dom_image * dom, void *vcpu_ctxt);
+int (*bootearly) (struct xc_dom_image * dom);
+int (*bootlate) (struct xc_dom_image * dom);
 
 /* arch-specific memory initialization. */
 int (*meminit) (struct xc_dom_image * dom);
@@ -399,11 +401,6 @@ static inline xen_pfn_t xc_dom_p2m(struct xc_dom_image 
*dom, xen_pfn_t pfn)
 return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
-/* --- arch bits --- */
-
-int arch_setup_bootearly(struct xc_dom_image *dom);
-int arch_setup_bootlate(struct xc_dom_image *dom);
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index e8a0756..ec3a757 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -489,13 +489,20 @@ static int meminit(struct xc_dom_image *dom)
 return 0;
 }
 
-int arch_setup_bootearly(struct xc_dom_image *dom)
+int xc_dom_feature_translated(struct xc_dom_image *dom)
+{
+return 1;
+}
+
+/*  */
+
+static int bootearly(struct xc_dom_image *dom)
 {
 DOMPRINTF("%s: doing nothing", __FUNCTION__);
 return 0;
 }
 
-int arch_setup_bootlate(struct xc_dom_image *dom)
+static int bootlate(struct xc_dom_image *dom)
 {
 /* XXX
  *   map shared info
@@ -505,11 +512,6 @@ int arch_setup_bootlate(struct xc_dom_image *dom)
 return 0;
 }
 
-int xc_dom_feature_translated(struct xc_dom_image *dom)
-{
-return 1;
-}
-
 /*  */
 
 static struct xc_dom_arch xc_dom_32 = {
@@ -524,6 +526,8 @@ static struct xc_dom_arch xc_dom_32 = {
 .shared_info = shared_info_arm,
 .vcpu = vcpu_arm32,
 .meminit = meminit,
+.bootearly = bootearly,
+.bootlate = bootlate,
 };
 
 static struct xc_dom_arch xc_dom_64 = {
@@ -538,6 +542,8 @@ static struct xc_dom_arch xc_dom_64 = {
 .shared_info = shared_info_arm,
 .vcpu = vcpu_arm64,
 .meminit = meminit,
+.bootearly = bootearly,
+.bootlate = bootlate,
 };
 
 static void __init register_arch_hooks(void)
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index bf2cd7b..e6f7794 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -208,7 +208,7 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
 DOMPRINTF_CALLED(dom->xch);
 
 /* misc stuff*/
-if ( (rc = arch_setup_bootearly(dom)) != 0 )
+if ( (rc = dom->arch_hooks->bootearly(dom)) != 0 )
 return rc;
 
 /* collect some info */
@@ -255,7 +255,7 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
 xc_dom_log_memory_footprint(dom);
 
 /* misc x86 stuff */
-if ( (rc = arch_setup_bootlate(dom)) != 0 )
+if ( (rc = dom->arch_hooks->bootlate(dom)) != 0 )
 return rc;
 
 /* let the vm run */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index fbedf85..b48dc1b 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -922,7 +922,9 @@ static int meminit_pv(struct xc_dom_image *dom)
 return rc;
 }
 
-int arch_setup_bootearly(struct xc_dom_image *dom)
+/*  */
+
+static int bootearly(struct xc_dom_image *dom)
 {
 DOMPRINTF("%s: doing nothing", __FUNCTION__);
 return 0;
@@ -961,7 +963,7 @@ static int map_grant_table_frames(struct xc_dom_image *dom)
 return 0;
 }
 
-int arch_setup_bootlate(struct xc_dom_image *dom)
+static int bootlate_pv(struct xc_dom_image *dom)
 {
 static const struct {
 char *guest;
@@ -1057,6 +1059,8 @@ static struct xc_dom_arch xc_dom_32_pae = {
 .shared_info = shared_info_x86_32,
 .vcpu = vcpu_x86_32,
 .meminit = meminit_pv,
+.bootearly = bootearly,
+.bootlate = bootlate_pv,
 };
 
 static struct xc_dom_arch xc_dom_64 = {
@@ -1071,6 +1075,8 @@ static struct xc_dom_arch xc_dom_64 = {
 .shared_info = shared_info_x86_64,
 .vcpu = vcpu_x86_64,
 .meminit = meminit_pv,
+.bootearly = bootearly,
+.bootlate = bootlate_pv,
 };
 
 static void __init r

[Xen-devel] [PATCH v7 15/32] xen/x86: allow disabling the emulated HPET

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
Acked-by: Andrew Cooper 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v6:
 - Return ENODEV in hpet_load if the vhpet is disabled.

Changes since v4:
 - Add Andrew Cooper Acked-by.
---
 xen/arch/x86/hvm/hpet.c | 13 +
 xen/arch/x86/hvm/hvm.c  |  1 -
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index facab83..5e020ae 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -517,6 +517,9 @@ static int hpet_save(struct domain *d, hvm_domain_context_t 
*h)
 int rc;
 uint64_t guest_time;
 
+if ( !has_vhpet(d) )
+return 0;
+
 write_lock(&hp->lock);
 guest_time = (v->arch.hvm_vcpu.guest_time ?: hvm_get_guest_time(v)) /
  STIME_PER_HPET_TICK;
@@ -577,6 +580,9 @@ static int hpet_load(struct domain *d, hvm_domain_context_t 
*h)
 uint64_t guest_time;
 int i;
 
+if ( !has_vhpet(d) )
+return -ENODEV;
+
 write_lock(&hp->lock);
 
 /* Reload the HPET registers */
@@ -635,6 +641,9 @@ void hpet_init(struct domain *d)
 HPETState *h = domain_vhpet(d);
 int i;
 
+if ( !has_vhpet(d) )
+return;
+
 memset(h, 0, sizeof(HPETState));
 
 rwlock_init(&h->lock);
@@ -662,6 +671,7 @@ void hpet_init(struct domain *d)
 }
 
 register_mmio_handler(d, &hpet_mmio_ops);
+d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
 }
 
 void hpet_deinit(struct domain *d)
@@ -669,6 +679,9 @@ void hpet_deinit(struct domain *d)
 int i;
 HPETState *h = domain_vhpet(d);
 
+if ( !has_vhpet(d) )
+return;
+
 write_lock(&h->lock);
 
 if ( hpet_enabled(h) )
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6afc344..b4d8475 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1603,7 +1603,6 @@ int hvm_domain_initialise(struct domain *d)
 
 hvm_init_guest_time(d);
 
-d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
 d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] = SHUTDOWN_reboot;
 
 vpic_init(d);
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 16/32] xen/x86: allow disabling the pmtimer

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v6:
 - Return ENODEV in pmtimer_load if the timer is disabled.
 - hvm_acpi_power_button and hvm_acpi_sleep_button become noops if the
   pmtimer is disabled.
 - Return ENODEV if pmtimer_change_ioport is called with the pmtimer
   disabled.
 - Add a check for disabled pmtimer in pmtimer_reset. Although it's safe to
   execute this function now, it might change in the future.
 - Drop Andrew's Ack due to the changes.

Changes since v4:
 - Add Andrew Cooper Acked-by.
---
 xen/arch/x86/hvm/pmtimer.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/xen/arch/x86/hvm/pmtimer.c b/xen/arch/x86/hvm/pmtimer.c
index c8229e0..a06d183 100644
--- a/xen/arch/x86/hvm/pmtimer.c
+++ b/xen/arch/x86/hvm/pmtimer.c
@@ -67,6 +67,10 @@ static void pmt_update_sci(PMTState *s)
 void hvm_acpi_power_button(struct domain *d)
 {
 PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
+
+if ( !has_vpmtimer(d) )
+return;
+
 spin_lock(&s->lock);
 s->pm.pm1a_sts |= PWRBTN_STS;
 pmt_update_sci(s);
@@ -76,6 +80,10 @@ void hvm_acpi_power_button(struct domain *d)
 void hvm_acpi_sleep_button(struct domain *d)
 {
 PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
+
+if ( !has_vpmtimer(d) )
+return;
+
 spin_lock(&s->lock);
 s->pm.pm1a_sts |= SLPBTN_STS;
 pmt_update_sci(s);
@@ -247,6 +255,9 @@ static int pmtimer_save(struct domain *d, 
hvm_domain_context_t *h)
 uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
 int rc;
 
+if ( !has_vpmtimer(d) )
+return 0;
+
 spin_lock(&s->lock);
 
 /*
@@ -273,6 +284,9 @@ static int pmtimer_load(struct domain *d, 
hvm_domain_context_t *h)
 {
 PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
 
+if ( !has_vpmtimer(d) )
+return -ENODEV;
+
 spin_lock(&s->lock);
 
 /* Reload the registers */
@@ -301,6 +315,9 @@ int pmtimer_change_ioport(struct domain *d, unsigned int 
version)
 {
 unsigned int old_version;
 
+if ( !has_vpmtimer(d) )
+return -ENODEV;
+
 /* Check that version is changing. */
 old_version = d->arch.hvm_domain.params[HVM_PARAM_ACPI_IOPORTS_LOCATION];
 if ( version == old_version )
@@ -330,6 +347,9 @@ void pmtimer_init(struct vcpu *v)
 {
 PMTState *s = &v->domain->arch.hvm_domain.pl_time.vpmt;
 
+if ( !has_vpmtimer(v->domain) )
+return;
+
 spin_lock_init(&s->lock);
 
 s->scale = ((uint64_t)FREQUENCE_PMTIMER << 32) / SYSTEM_TIME_HZ;
@@ -350,11 +370,18 @@ void pmtimer_init(struct vcpu *v)
 void pmtimer_deinit(struct domain *d)
 {
 PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
+
+if ( !has_vpmtimer(d) )
+return;
+
 kill_timer(&s->timer);
 }
 
 void pmtimer_reset(struct domain *d)
 {
+if ( !has_vpmtimer(d) )
+return;
+
 /* Reset the counter. */
 d->arch.hvm_domain.pl_time.vpmt.pm.tmr_val = 0;
 }
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 17/32] xen/x86: allow disabling the emulated RTC

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
Acked-by: Andrew Cooper 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v6:
 - Return ENODEV in rtc_load if rtc is disabled.
 - Add checks to rtc_reset and rtc_update_clock to prevent calling them if
   rtc is disabled.

Changes since v4:
 - Add Andrew Cooper Acked-by.
---
 xen/arch/x86/hvm/rtc.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c
index a9efeaf..d391e38 100644
--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -726,6 +726,9 @@ void rtc_migrate_timers(struct vcpu *v)
 {
 RTCState *s = vcpu_vrtc(v);
 
+if ( !has_vrtc(v->domain) )
+return;
+
 if ( v->vcpu_id == 0 )
 {
 migrate_timer(&s->update_timer, v->processor);;
@@ -739,6 +742,10 @@ static int rtc_save(struct domain *d, hvm_domain_context_t 
*h)
 {
 RTCState *s = domain_vrtc(d);
 int rc;
+
+if ( !has_vrtc(d) )
+return 0;
+
 spin_lock(&s->lock);
 rc = hvm_save_entry(RTC, 0, h, &s->hw);
 spin_unlock(&s->lock);
@@ -750,6 +757,9 @@ static int rtc_load(struct domain *d, hvm_domain_context_t 
*h)
 {
 RTCState *s = domain_vrtc(d);
 
+if ( !has_vrtc(d) )
+return -ENODEV;
+
 spin_lock(&s->lock);
 
 /* Restore the registers */
@@ -780,6 +790,9 @@ void rtc_reset(struct domain *d)
 {
 RTCState *s = domain_vrtc(d);
 
+if ( !has_vrtc(d) )
+return;
+
 TRACE_0D(TRC_HVM_EMUL_RTC_STOP_TIMER);
 destroy_periodic_time(&s->pt);
 s->period = 0;
@@ -790,6 +803,9 @@ void rtc_init(struct domain *d)
 {
 RTCState *s = domain_vrtc(d);
 
+if ( !has_vrtc(d) )
+return;
+
 spin_lock_init(&s->lock);
 
 init_timer(&s->update_timer, rtc_update_timer, s, smp_processor_id());
@@ -820,6 +836,9 @@ void rtc_deinit(struct domain *d)
 {
 RTCState *s = domain_vrtc(d);
 
+if ( !has_vrtc(d) )
+return;
+
 spin_barrier(&s->lock);
 
 TRACE_0D(TRC_HVM_EMUL_RTC_STOP_TIMER);
@@ -833,6 +852,9 @@ void rtc_update_clock(struct domain *d)
 {
 RTCState *s = domain_vrtc(d);
 
+if ( !has_vrtc(d) )
+return;
+
 spin_lock(&s->lock);
 s->current_tm = gmtime(get_localtime(d));
 spin_unlock(&s->lock);
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v7 10/32] libxl: switch HVM domain building to use xc_dom_* helpers

[Roger Pau Monne]

Now that we have all the code in place HVM domain building in libxl can be
switched to use the xc_dom_* family of functions, just like they are used in
order to build PV guests.

Signed-off-by: Roger Pau Monné 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v6:
 - Fix uninitialized usage of rc in libxl__build_hvm.

Changes since v4:
 - Add Wei Liu Acked-by.
---
 tools/libxl/libxl_arch.h |   2 +-
 tools/libxl/libxl_arm.c  |   2 +-
 tools/libxl/libxl_dm.c   |  18 ++--
 tools/libxl/libxl_dom.c  | 228 +--
 tools/libxl/libxl_internal.h |   4 +-
 tools/libxl/libxl_vnuma.c|  12 ++-
 tools/libxl/libxl_x86.c  |   8 +-
 7 files changed, 157 insertions(+), 117 deletions(-)

diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index bd030b6..34a853c 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -60,6 +60,6 @@ _hidden
 int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 libxl_domain_config *d_config,
 uint32_t domid,
-struct xc_hvm_build_args *args);
+struct xc_dom_image *dom);
 
 #endif
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 0af8010..1195b37 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -974,7 +974,7 @@ int libxl__arch_domain_map_irq(libxl__gc *gc, uint32_t 
domid, int irq)
 int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 libxl_domain_config *d_config,
 uint32_t domid,
-struct xc_hvm_build_args *args)
+struct xc_dom_image *dom)
 {
 return 0;
 }
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 71a1a3e..8e337de 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -18,6 +18,8 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
+
+#include 
 #include 
 
 static const char *libxl_tapif_script(libxl__gc *gc)
@@ -181,7 +183,7 @@ add_rdm_entry(libxl__gc *gc, libxl_domain_config *d_config,
 int libxl__domain_device_construct_rdm(libxl__gc *gc,
libxl_domain_config *d_config,
uint64_t rdm_mem_boundary,
-   struct xc_hvm_build_args *args)
+   struct xc_dom_image *dom)
 {
 int i, j, conflict, rc;
 struct xen_reserved_device_memory *xrdm = NULL;
@@ -189,7 +191,7 @@ int libxl__domain_device_construct_rdm(libxl__gc *gc,
 uint16_t seg;
 uint8_t bus, devfn;
 uint64_t rdm_start, rdm_size;
-uint64_t highmem_end = args->highmem_end ? args->highmem_end : (1ull<<32);
+uint64_t highmem_end = dom->highmem_end ? dom->highmem_end : (1ull<<32);
 
 /*
  * We just want to construct RDM once since RDM is specific to the
@@ -303,7 +305,7 @@ int libxl__domain_device_construct_rdm(libxl__gc *gc,
 for (i = 0; i < d_config->num_rdms; i++) {
 rdm_start = d_config->rdms[i].start;
 rdm_size = d_config->rdms[i].size;
-conflict = overlaps_rdm(0, args->lowmem_end, rdm_start, rdm_size);
+conflict = overlaps_rdm(0, dom->lowmem_end, rdm_start, rdm_size);
 
 if (!conflict)
 continue;
@@ -314,14 +316,14 @@ int libxl__domain_device_construct_rdm(libxl__gc *gc,
  * We will move downwards lowmem_end so we have to expand
  * highmem_end.
  */
-highmem_end += (args->lowmem_end - rdm_start);
+highmem_end += (dom->lowmem_end - rdm_start);
 /* Now move downwards lowmem_end. */
-args->lowmem_end = rdm_start;
+dom->lowmem_end = rdm_start;
 }
 }
 
 /* Sync highmem_end. */
-args->highmem_end = highmem_end;
+dom->highmem_end = highmem_end;
 
 /*
  * Finally we can take same policy to check lowmem(< 2G) and
@@ -331,11 +333,11 @@ int libxl__domain_device_construct_rdm(libxl__gc *gc,
 rdm_start = d_config->rdms[i].start;
 rdm_size = d_config->rdms[i].size;
 /* Does this entry conflict with lowmem? */
-conflict = overlaps_rdm(0, args->lowmem_end,
+conflict = overlaps_rdm(0, dom->lowmem_end,
 rdm_start, rdm_size);
 /* Does this entry conflict with highmem? */
 conflict |= overlaps_rdm((1ULL<<32),
- args->highmem_end - (1ULL<<32),
+ dom->highmem_end - (1ULL<<32),
  rdm_start, rdm_size);
 
 if (!conflict)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 01172b0..a9925b7 100644
--- a/too

[Xen-devel] [PATCH v7 08/32] libxc: rework BSP initialization

[Roger Pau Monne]

Place the calls to xc_vcpu_setcontext and the allocation of the hypercall
buffer into the arch-specific vcpu hooks. This is needed in order to
introduce a new builder, so x86 HVM guests can initialize the BSP using
XEN_DOMCTL_sethvmcontext instead of XEN_DOMCTL_setvcpucontext.

This patch should not introduce any functional change.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v5:
 - Reword commit message to remove a reference to "next patch".

Changes since v4:
 - Add Andrew Cooper Reviewed-by.
---
 tools/libxc/include/xc_dom.h |  2 +-
 tools/libxc/xc_dom_arm.c | 26 ++--
 tools/libxc/xc_dom_boot.c| 23 +
 tools/libxc/xc_dom_x86.c | 48 
 4 files changed, 53 insertions(+), 46 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index ced6ae2..2498cf7 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -219,7 +219,7 @@ struct xc_dom_arch {
 /* arch-specific data structs setup */
 int (*start_info) (struct xc_dom_image * dom);
 int (*shared_info) (struct xc_dom_image * dom, void *shared_info);
-int (*vcpu) (struct xc_dom_image * dom, void *vcpu_ctxt);
+int (*vcpu) (struct xc_dom_image * dom);
 int (*bootearly) (struct xc_dom_image * dom);
 int (*bootlate) (struct xc_dom_image * dom);
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index ec3a757..397eef0 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -119,9 +119,11 @@ static int shared_info_arm(struct xc_dom_image *dom, void 
*ptr)
 
 /*  */
 
-static int vcpu_arm32(struct xc_dom_image *dom, void *ptr)
+static int vcpu_arm32(struct xc_dom_image *dom)
 {
-vcpu_guest_context_t *ctxt = ptr;
+vcpu_guest_context_any_t any_ctx;
+vcpu_guest_context_t *ctxt = &any_ctx.c;
+int rc;
 
 DOMPRINTF_CALLED(dom->xch);
 
@@ -154,12 +156,19 @@ static int vcpu_arm32(struct xc_dom_image *dom, void *ptr)
 DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
ctxt->user_regs.cpsr, ctxt->user_regs.pc32);
 
-return 0;
+rc = xc_vcpu_setcontext(dom->xch, dom->guest_domid, 0, &any_ctx);
+if ( rc != 0 )
+xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+ "%s: SETVCPUCONTEXT failed (rc=%d)", __func__, rc);
+
+return rc;
 }
 
-static int vcpu_arm64(struct xc_dom_image *dom, void *ptr)
+static int vcpu_arm64(struct xc_dom_image *dom)
 {
-vcpu_guest_context_t *ctxt = ptr;
+vcpu_guest_context_any_t any_ctx;
+vcpu_guest_context_t *ctxt = &any_ctx.c;
+int rc;
 
 DOMPRINTF_CALLED(dom->xch);
 /* clear everything */
@@ -189,7 +198,12 @@ static int vcpu_arm64(struct xc_dom_image *dom, void *ptr)
 DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx64,
ctxt->user_regs.cpsr, ctxt->user_regs.pc64);
 
-return 0;
+rc = xc_vcpu_setcontext(dom->xch, dom->guest_domid, 0, &any_ctx);
+if ( rc != 0 )
+xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+ "%s: SETVCPUCONTEXT failed (rc=%d)", __func__, rc);
+
+return rc;
 }
 
 /*  */
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index e6f7794..791041b 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -62,19 +62,6 @@ static int setup_hypercall_page(struct xc_dom_image *dom)
 return rc;
 }
 
-static int launch_vm(xc_interface *xch, domid_t domid,
- vcpu_guest_context_any_t *ctxt)
-{
-int rc;
-
-xc_dom_printf(xch, "%s: called, ctxt=%p", __FUNCTION__, ctxt);
-rc = xc_vcpu_setcontext(xch, domid, 0, ctxt);
-if ( rc != 0 )
-xc_dom_panic(xch, XC_INTERNAL_ERROR,
- "%s: SETVCPUCONTEXT failed (rc=%d)", __FUNCTION__, rc);
-return rc;
-}
-
 static int clear_page(struct xc_dom_image *dom, xen_pfn_t pfn)
 {
 xen_pfn_t dst;
@@ -197,14 +184,9 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, 
xen_pfn_t pfn,
 
 int xc_dom_boot_image(struct xc_dom_image *dom)
 {
-DECLARE_HYPERCALL_BUFFER(vcpu_guest_context_any_t, ctxt);
 xc_dominfo_t info;
 int rc;
 
-ctxt = xc_hypercall_buffer_alloc(dom->xch, ctxt, sizeof(*ctxt));
-if ( ctxt == NULL )
-return -1;
-
 DOMPRINTF_CALLED(dom->xch);
 
 /* misc stuff*/
@@ -259,13 +241,10 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
 return rc;
 
 /* let the vm run */
-memset(ctxt, 0, sizeof(*ctxt));
-if ( (rc = dom->arch_hooks->vcpu(dom, ctxt)) != 0 )
+if ( (rc = dom->arch_hooks->vcpu(dom)) != 0 )
 return rc;
 xc_dom_unmap_all(dom);
-rc = launch_vm(dom->xch, dom->guest_domid, ctxt);
 
-xc_hypercall_buffer_free(d

[Xen-devel] [PATCH v7 06/32] libxc: make arch_setup_meminit a xc_dom_arch hook

[Roger Pau Monne]

This allows having different arch_setup_meminit implementations based on the
guest type. It should not introduce any functional changes.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v3:
 - Add Andrew Cooper Reviewed-by.
 - Move xc_dom_arch definitions to the end of the xc_dom_.c files in
   order to reduce the spurious diffs in the comming patches.
 - Add Wei Acked-by.
---
 tools/libxc/include/xc_dom.h |  4 ++-
 tools/libxc/xc_dom_arm.c | 70 +++
 tools/libxc/xc_dom_boot.c|  2 +-
 tools/libxc/xc_dom_x86.c | 71 +++-
 4 files changed, 78 insertions(+), 69 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 88c5c80..01739fa 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -221,6 +221,9 @@ struct xc_dom_arch {
 int (*shared_info) (struct xc_dom_image * dom, void *shared_info);
 int (*vcpu) (struct xc_dom_image * dom, void *vcpu_ctxt);
 
+/* arch-specific memory initialization. */
+int (*meminit) (struct xc_dom_image * dom);
+
 char *guest_type;
 char *native_protocol;
 int page_shift;
@@ -398,7 +401,6 @@ static inline xen_pfn_t xc_dom_p2m(struct xc_dom_image 
*dom, xen_pfn_t pfn)
 
 /* --- arch bits --- */
 
-int arch_setup_meminit(struct xc_dom_image *dom);
 int arch_setup_bootearly(struct xc_dom_image *dom);
 int arch_setup_bootlate(struct xc_dom_image *dom);
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index aeaba54..e8a0756 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -194,38 +194,6 @@ static int vcpu_arm64(struct xc_dom_image *dom, void *ptr)
 
 /*  */
 
-static struct xc_dom_arch xc_dom_32 = {
-.guest_type = "xen-3.0-armv7l",
-.native_protocol = XEN_IO_PROTO_ABI_ARM,
-.page_shift = PAGE_SHIFT_ARM,
-.sizeof_pfn = 8,
-.alloc_magic_pages = alloc_magic_pages,
-.count_pgtables = count_pgtables_arm,
-.setup_pgtables = setup_pgtables_arm,
-.start_info = start_info_arm,
-.shared_info = shared_info_arm,
-.vcpu = vcpu_arm32,
-};
-
-static struct xc_dom_arch xc_dom_64 = {
-.guest_type = "xen-3.0-aarch64",
-.native_protocol = XEN_IO_PROTO_ABI_ARM,
-.page_shift = PAGE_SHIFT_ARM,
-.sizeof_pfn = 8,
-.alloc_magic_pages = alloc_magic_pages,
-.count_pgtables = count_pgtables_arm,
-.setup_pgtables = setup_pgtables_arm,
-.start_info = start_info_arm,
-.shared_info = shared_info_arm,
-.vcpu = vcpu_arm64,
-};
-
-static void __init register_arch_hooks(void)
-{
-xc_dom_register_arch_hooks(&xc_dom_32);
-xc_dom_register_arch_hooks(&xc_dom_64);
-}
-
 static int set_mode(xc_interface *xch, domid_t domid, char *guest_type)
 {
 static const struct {
@@ -384,7 +352,7 @@ out:
 return rc < 0 ? rc : 0;
 }
 
-int arch_setup_meminit(struct xc_dom_image *dom)
+static int meminit(struct xc_dom_image *dom)
 {
 int i, rc;
 xen_pfn_t pfn;
@@ -542,6 +510,42 @@ int xc_dom_feature_translated(struct xc_dom_image *dom)
 return 1;
 }
 
+/*  */
+
+static struct xc_dom_arch xc_dom_32 = {
+.guest_type = "xen-3.0-armv7l",
+.native_protocol = XEN_IO_PROTO_ABI_ARM,
+.page_shift = PAGE_SHIFT_ARM,
+.sizeof_pfn = 8,
+.alloc_magic_pages = alloc_magic_pages,
+.count_pgtables = count_pgtables_arm,
+.setup_pgtables = setup_pgtables_arm,
+.start_info = start_info_arm,
+.shared_info = shared_info_arm,
+.vcpu = vcpu_arm32,
+.meminit = meminit,
+};
+
+static struct xc_dom_arch xc_dom_64 = {
+.guest_type = "xen-3.0-aarch64",
+.native_protocol = XEN_IO_PROTO_ABI_ARM,
+.page_shift = PAGE_SHIFT_ARM,
+.sizeof_pfn = 8,
+.alloc_magic_pages = alloc_magic_pages,
+.count_pgtables = count_pgtables_arm,
+.setup_pgtables = setup_pgtables_arm,
+.start_info = start_info_arm,
+.shared_info = shared_info_arm,
+.vcpu = vcpu_arm64,
+.meminit = meminit,
+};
+
+static void __init register_arch_hooks(void)
+{
+xc_dom_register_arch_hooks(&xc_dom_32);
+xc_dom_register_arch_hooks(&xc_dom_64);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 7c30f96..bf2cd7b 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -146,7 +146,7 @@ int xc_dom_boot_mem_init(struct xc_dom_image *dom)
 
 DOMPRINTF_CALLED(dom->xch);
 
-rc = arch_setup_meminit(dom);
+rc = dom->arch_hooks->meminit(dom);
 if ( rc != 0 )
 {
 xc_dom_panic(dom->xch, XC_OUT_OF_MEMORY,
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index d306475..fbedf85 100644
--- 

[Xen-devel] [PATCH v7 09/32] libxc: introduce a xc_dom_arch for hvm-3.0-x86_32 guests

[Roger Pau Monne]

This xc_dom_arch will be used in order to build HVM domains. The code is
based on the existing xc_hvm_populate_memory and xc_hvm_populate_params
functions.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v6:
 - Fix incorrect printf conversion specification.

Changes since v5:
 - Set tr limit to 0x67.
 - Use "goto out" consistently in vcpu_hvm.
 - Unconditionally call free(full_ctx) before exiting vcpu_hvm.
 - Add Wei Liu Ack.

Changes since v4:
 - Replace a malloc+memset with a calloc.
 - Remove a != NULL check.
 - Add Andrew Cooper Reviewed-by.

Changes since v3:
 - Make sure c/s b9dbe33 is not reverted on this patch.
 - Set the initial BSP state using {get/set}hvmcontext.
---
 tools/libxc/include/xc_dom.h |   6 +
 tools/libxc/xc_dom_x86.c | 618 ++-
 2 files changed, 613 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 2498cf7..e52b023 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -186,6 +186,12 @@ struct xc_dom_image {
 } container_type;
 
 /* HVM specific fields. */
+xen_pfn_t target_pages;
+xen_pfn_t mmio_start;
+xen_pfn_t mmio_size;
+xen_pfn_t lowmem_end;
+xen_pfn_t highmem_end;
+
 /* Extra ACPI tables passed to HVMLOADER */
 struct xc_hvm_firmware_module acpi_module;
 
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index ab88996..dd331bf 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -39,10 +39,32 @@
 
 /*  */
 
-#define SUPERPAGE_PFN_SHIFT  9
-#define SUPERPAGE_NR_PFNS(1UL << SUPERPAGE_PFN_SHIFT)
 #define SUPERPAGE_BATCH_SIZE 512
 
+#define SUPERPAGE_2MB_SHIFT   9
+#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT   18
+#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
+
+#define X86_CR0_PE 0x01
+#define X86_CR0_ET 0x10
+
+#define VGA_HOLE_SIZE (0x20)
+
+#define SPECIALPAGE_PAGING   0
+#define SPECIALPAGE_ACCESS   1
+#define SPECIALPAGE_SHARING  2
+#define SPECIALPAGE_BUFIOREQ 3
+#define SPECIALPAGE_XENSTORE 4
+#define SPECIALPAGE_IOREQ5
+#define SPECIALPAGE_IDENT_PT 6
+#define SPECIALPAGE_CONSOLE  7
+#define NR_SPECIAL_PAGES 8
+#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+
+#define NR_IOREQ_SERVER_PAGES 8
+#define ioreq_server_pfn(x) (special_pfn(0) - NR_IOREQ_SERVER_PAGES + (x))
+
 #define bits_to_mask(bits)   (((xen_vaddr_t)1 << (bits))-1)
 #define round_down(addr, mask)   ((addr) & ~(mask))
 #define round_up(addr, mask) ((addr) | (mask))
@@ -462,6 +484,135 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 return 0;
 }
 
+static void build_hvm_info(void *hvm_info_page, struct xc_dom_image *dom)
+{
+struct hvm_info_table *hvm_info = (struct hvm_info_table *)
+(((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
+uint8_t sum;
+int i;
+
+memset(hvm_info_page, 0, PAGE_SIZE);
+
+/* Fill in the header. */
+memcpy(hvm_info->signature, "HVM INFO", sizeof(hvm_info->signature));
+hvm_info->length = sizeof(struct hvm_info_table);
+
+/* Sensible defaults: these can be overridden by the caller. */
+hvm_info->apic_mode = 1;
+hvm_info->nr_vcpus = 1;
+memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
+
+/* Memory parameters. */
+hvm_info->low_mem_pgend = dom->lowmem_end >> PAGE_SHIFT;
+hvm_info->high_mem_pgend = dom->highmem_end >> PAGE_SHIFT;
+hvm_info->reserved_mem_pgstart = ioreq_server_pfn(0);
+
+/* Finish with the checksum. */
+for ( i = 0, sum = 0; i < hvm_info->length; i++ )
+sum += ((uint8_t *)hvm_info)[i];
+hvm_info->checksum = -sum;
+}
+
+static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
+{
+unsigned long i;
+void *hvm_info_page;
+uint32_t *ident_pt, domid = dom->guest_domid;
+int rc;
+xen_pfn_t special_array[NR_SPECIAL_PAGES];
+xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
+xc_interface *xch = dom->xch;
+
+if ( (hvm_info_page = xc_map_foreign_range(
+  xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
+  HVM_INFO_PFN)) == NULL )
+goto error_out;
+build_hvm_info(hvm_info_page, dom);
+munmap(hvm_info_page, PAGE_SIZE);
+
+/* Allocate and clear special pages. */
+for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
+special_array[i] = special_pfn(i);
+
+rc = xc_domain_populate_physmap_exact(xch, domid, NR_SPECIAL_PAGES, 0, 0,
+  special_array);
+if ( rc != 0 )
+{
+DOMPRINTF("Could not allocate special pages.");
+goto error_out;
+}
+
+if ( xc_clear_domain_pages(xch, domid, special_pfn(0), NR_SPECIAL_PAGES) )
+goto error_out;
+
+ 

[Xen-devel] [PATCH v7 12/32] xen/x86: add bitmap of enabled emulated devices

[Roger Pau Monne]

Introduce a bitmap in x86 xen_arch_domainconfig that allows enabling or
disabling specific devices emulated inside of Xen for HVM guests.

Signed-off-by: Roger Pau Monné 
Acked-by: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
---
Changes since v6:
 - Define XEN_X86_EMU_ALL to contain all the possible emulated devices.
 - Remove full stops form the printks added to arch_domain_create.
 - Add Wei Liu Acked-by.
 - Added a check to x86 arch_domain_create in order to make sure a non-null
   config is always provided.
 - Check that emulation_flags is always 0 for PV guests.
 - Fix x86 callers of domain_create in order to make sure a non-null arch
   config is always provided.
 - Removed XEN_X86_EMU_PMU.
 - Removed Andrew Cooper's Reviewed-by, since the hypervisor side code has
   changed substantially.

Changes since v4:
 - Add a check to make sure the emulation bitmap is sane (undefined bits are
   all 0s).
 - Add Andrew Cooper Reviewed-by.

Changes since v3:
 - Return EOPNOTSUPP instead of ENOPERM if an invalid emulation mask is
   used.
 - Fix error messages (prefix them with d%d and use %#x instead of 0x%x).
 - Clearly state in the public header that emulation_flags should only be
   used with HVM guests.
 - Add a XEN_X86 prefix to the emulation flags defines.
 - Properly parenthese the has_* marcos.
---
 tools/libxl/libxl_x86.c   |  5 -
 xen/arch/x86/domain.c | 19 +++
 xen/arch/x86/mm.c |  7 ---
 xen/arch/x86/setup.c  |  3 ++-
 xen/common/schedule.c |  8 +++-
 xen/include/asm-x86/domain.h  | 12 
 xen/include/public/arch-x86/xen.h | 23 ++-
 7 files changed, 70 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 9276126..e71f80e 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -7,7 +7,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
   libxl_domain_config *d_config,
   xc_domain_configuration_t *xc_config)
 {
-/* No specific configuration right now */
+if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
+xc_config->emulation_flags = XEN_X86_EMU_ALL;
+else
+xc_config->emulation_flags = 0;
 
 return 0;
 }
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index dc3bb08..79182a4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -496,6 +496,9 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 int i, paging_initialised = 0;
 int rc = -ENOMEM;
 
+if ( config == NULL )
+return -EINVAL;
+
 d->arch.s3_integrity = !!(domcr_flags & DOMCRF_s3_integrity);
 
 INIT_LIST_HEAD(&d->arch.pdev_list);
@@ -517,6 +520,22 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
d->domain_id);
 }
 
+if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
+{
+printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
+   d->domain_id, config->emulation_flags);
+return -EINVAL;
+}
+if ( (is_hvm_domain(d) && config->emulation_flags != XEN_X86_EMU_ALL) ||
+ (is_pv_domain(d) && config->emulation_flags != 0) )
+{
+printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation with "
+   "the current selection of emulators: %#x\n", d->domain_id,
+   is_hvm_domain(d) ? "HVM" : "PV", config->emulation_flags);
+return -EOPNOTSUPP;
+}
+d->arch.emulation_flags = config->emulation_flags;
+
 if ( has_hvm_container_domain(d) )
 {
 d->arch.hvm_domain.hap_enabled =
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 327b837..b0873f6 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -255,6 +255,7 @@ static l4_pgentry_t __read_mostly split_l4e;
 void __init arch_init_memory(void)
 {
 unsigned long i, pfn, rstart_pfn, rend_pfn, iostart_pfn, ioend_pfn;
+struct xen_arch_domainconfig config = { .emulation_flags = 0 };
 
 /* Basic guest-accessible flags: PRESENT, R/W, USER, A/D, AVAIL[0,1,2] */
 base_disallow_mask = ~(_PAGE_PRESENT|_PAGE_RW|_PAGE_USER|
@@ -272,7 +273,7 @@ void __init arch_init_memory(void)
  * Hidden PCI devices will also be associated with this domain
  * (but be [partly] controlled by Dom0 nevertheless).
  */
-dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0, NULL);
+dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0, &config);
 BUG_ON(IS_ERR(dom_xen));
 INIT_LIST_HEAD(&dom_xen->arch.pdev_list);
 
@@ -281,14 +282,14 @@ void __init arch_init_memory(void)
  * This domain owns I/O pages that are within the range of the page_info
  * array. Mappings occur at the priv of the caller.
  */
-dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0, NULL);
+dom_

[Xen-devel] [PATCH v7 14/32] xen/x86: allow disabling the emulated local apic

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Eddie Dong 
Cc: Kevin Tian 
---
Changes since v6:
 - Remove stall comments.
 - Adds checks for has_vlapic in the msixtbl_pt_{un}register functions.
 - Simplify the is_pvh_domain(d) || !has_vlapic(d) to !has_vlapic(d) when
   appropriate.
 - Split parts of this patch that can be considered bug fixes to a
   pre-patch.
 - Removed Acks since the patch changed substantially.

Changes since v5:
 - Add Boris Ostrovsky Reviewed-by.

Changes since v4:
 - Split the is_pvh_domain check into two, so part of the code can be shared
   with the !has_lapic case.
 - Add Andrew Cooper Acked-by.
---
 xen/arch/x86/hvm/vlapic.c   | 27 ---
 xen/arch/x86/hvm/vmsi.c | 12 
 xen/arch/x86/hvm/vmx/vmcs.c |  5 -
 xen/arch/x86/hvm/vmx/vmx.c  |  6 ++
 4 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 229f122..f8a84d5 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -993,6 +993,9 @@ static void set_x2apic_id(struct vlapic *vlapic)
 
 bool_t vlapic_msr_set(struct vlapic *vlapic, uint64_t value)
 {
+if ( !has_vlapic(vlapic_domain(vlapic)) )
+return -ENODEV;
+
 if ( (vlapic->hw.apic_base_msr ^ value) & MSR_IA32_APICBASE_ENABLE )
 {
 if ( unlikely(value & MSR_IA32_APICBASE_EXTD) )
@@ -1205,6 +1208,9 @@ void vlapic_reset(struct vlapic *vlapic)
 struct vcpu *v = vlapic_vcpu(vlapic);
 int i;
 
+if ( !has_vlapic(v->domain) )
+return;
+
 vlapic_set_reg(vlapic, APIC_ID,  (v->vcpu_id * 2) << 24);
 vlapic_set_reg(vlapic, APIC_LVR, VLAPIC_VERSION);
 
@@ -1270,6 +1276,9 @@ static int lapic_save_hidden(struct domain *d, 
hvm_domain_context_t *h)
 struct vlapic *s;
 int rc = 0;
 
+if ( !has_vlapic(d) )
+return 0;
+
 for_each_vcpu ( d, v )
 {
 s = vcpu_vlapic(v);
@@ -1286,6 +1295,9 @@ static int lapic_save_regs(struct domain *d, 
hvm_domain_context_t *h)
 struct vlapic *s;
 int rc = 0;
 
+if ( !has_vlapic(d) )
+return 0;
+
 for_each_vcpu ( d, v )
 {
 if ( hvm_funcs.sync_pir_to_irr )
@@ -1333,7 +1345,10 @@ static int lapic_load_hidden(struct domain *d, 
hvm_domain_context_t *h)
 uint16_t vcpuid;
 struct vcpu *v;
 struct vlapic *s;
-
+
+if ( !has_vlapic(d) )
+return -ENODEV;
+
 /* Which vlapic to load? */
 vcpuid = hvm_load_instance(h); 
 if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
@@ -1365,7 +1380,10 @@ static int lapic_load_regs(struct domain *d, 
hvm_domain_context_t *h)
 uint16_t vcpuid;
 struct vcpu *v;
 struct vlapic *s;
-
+
+if ( !has_vlapic(d) )
+return -ENODEV;
+
 /* Which vlapic to load? */
 vcpuid = hvm_load_instance(h); 
 if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
@@ -1404,7 +1422,7 @@ int vlapic_init(struct vcpu *v)
 
 HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "%d", v->vcpu_id);
 
-if ( is_pvh_vcpu(v) )
+if ( !has_vlapic(v->domain) )
 {
 vlapic->hw.disabled = VLAPIC_HW_DISABLED;
 return 0;
@@ -1457,6 +1475,9 @@ void vlapic_destroy(struct vcpu *v)
 {
 struct vlapic *vlapic = vcpu_vlapic(v);
 
+if ( !has_vlapic(v->domain) )
+return;
+
 tasklet_kill(&vlapic->init_sipi.tasklet);
 TRACE_0D(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
 destroy_periodic_time(&vlapic->pt);
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index ac838a9..499151e 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -391,6 +391,9 @@ int msixtbl_pt_register(struct domain *d, struct pirq 
*pirq, uint64_t gtable)
 ASSERT(spin_is_locked(&pcidevs_lock));
 ASSERT(spin_is_locked(&d->event_lock));
 
+if ( !has_vlapic(d) )
+return -ENODEV;
+
 /*
  * xmalloc() with irq_disabled causes the failure of check_lock() 
  * for xenpool->lock. So we allocate an entry beforehand.
@@ -446,6 +449,9 @@ void msixtbl_pt_unregister(struct domain *d, struct pirq 
*pirq)
 ASSERT(spin_is_locked(&pcidevs_lock));
 ASSERT(spin_is_locked(&d->event_lock));
 
+if ( !has_vlapic(d) )
+return;
+
 irq_desc = pirq_spin_lock_irq_desc(pirq, NULL);
 if ( !irq_desc )
 return;
@@ -482,6 +488,9 @@ found:
 
 void msixtbl_init(struct domain *d)
 {
+if ( !has_vlapic(d) )
+return;
+
 INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
 spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
 
@@ -493,6 +502,9 @@ void msixtbl_pt_cleanup(struct domain *d)
 struct msixtbl_entry *entry, *temp;
 unsigned long flags;
 
+if ( !has_vlapic(d) )
+return;
+
 /* msixtbl_list_lock must be acquired with irq_disabled for check_lock() */
 local_irq_save(flags); 
 spin_lock(&d->arch.hvm_domain.msixtbl_list_lock);
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.

[Xen-devel] [Resend Fix PATCH] Qemu/Xen: Fix early freeing MSIX MMIO memory region

[Lan Tianyu]

MSIX MMIO memory region is added to pt device's obj as property.
When pt device is unplugged, all properties will be deleted and
memory region's obj is needed at that point(refer 
object_finalize_child_property()).
But current code frees MSIX MMIO memory region in the xen_pt_msix_delete()
before deleting pt device's properties, this will cause segment fault.
Reproduce the bug via hotplugging device frequently.

This patch is to fix the issue via moving MSIX MMIO memory region into
struct XenPCIPassthroughState and free it together with pt device's obj.

Signed-off-by: Lan Tianyu 
---
Cc Xen devel maillist

 hw/xen/xen_pt.c |4 ++--
 hw/xen/xen_pt.h |2 +-
 hw/xen/xen_pt_msi.c |6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 2b54f52..0c11069 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -587,11 +587,11 @@ static void xen_pt_region_update(XenPCIPassthroughState 
*s,
 };
 
 bar = xen_pt_bar_from_region(s, mr);
-if (bar == -1 && (!s->msix || &s->msix->mmio != mr)) {
+if (bar == -1 && (!s->msix || &s->msix_mmio != mr)) {
 return;
 }
 
-if (s->msix && &s->msix->mmio == mr) {
+if (s->msix && &s->msix_mmio == mr) {
 if (adding) {
 s->msix->mmio_base_addr = sec->offset_within_address_space;
 rc = xen_pt_msix_update_remap(s, s->msix->bar_index);
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 3bc22eb..3569c2c 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -199,7 +199,6 @@ typedef struct XenPTMSIX {
 uint64_t table_base;
 uint32_t table_offset_adjust; /* page align mmap */
 uint64_t mmio_base_addr;
-MemoryRegion mmio;
 void *phys_iomem_base;
 XenPTMSIXEntry msix_entry[0];
 } XenPTMSIX;
@@ -222,6 +221,7 @@ struct XenPCIPassthroughState {
 
 MemoryRegion bar[PCI_NUM_REGIONS - 1];
 MemoryRegion rom;
+MemoryRegion msix_mmio;
 
 MemoryListener memory_listener;
 MemoryListener io_listener;
diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index e3d7194..ae39ab3 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -558,7 +558,7 @@ int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t 
base)
 msix->msix_entry[i].pirq = XEN_PT_UNASSIGNED_PIRQ;
 }
 
-memory_region_init_io(&msix->mmio, OBJECT(s), &pci_msix_ops,
+memory_region_init_io(&s->msix_mmio, OBJECT(s), &pci_msix_ops,
   s, "xen-pci-pt-msix",
   (total_entries * PCI_MSIX_ENTRY_SIZE
+ XC_PAGE_SIZE - 1)
@@ -599,7 +599,7 @@ int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t 
base)
msix->phys_iomem_base);
 
 memory_region_add_subregion_overlap(&s->bar[bar_index], table_off,
-&msix->mmio,
+&s->msix_mmio,
 2); /* Priority: pci default + 1 */
 
 return 0;
@@ -626,7 +626,7 @@ void xen_pt_msix_delete(XenPCIPassthroughState *s)
+ msix->table_offset_adjust);
 }
 
-memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+memory_region_del_subregion(&s->bar[msix->bar_index], &s->msix_mmio);
 
 g_free(s->msix);
 s->msix = NULL;
-- 
1.7.9.5


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  90f2e2a307fc6a6258c39cc87b3b2bf9441c0fa7
baseline version:
 xen  810a50db69703f715d199d6b3a5f08193155d48b

Last test of basis62599  2015-10-01 13:52:38 Z1 days
Testing same since62622  2015-10-02 13:52:59 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  Ian Campbell 
  Jan Beulich 
  Juergen Gross 
  Ross Lagerwall 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH V7 5/7] xl: add pvusb commands

[Ian Campbell]

On Fri, 2015-10-02 at 16:17 +0100, George Dunlap wrote:
> On Fri, Oct 2, 2015 at 2:35 PM, Ian Campbell 
> wrote:
> > On Thu, 2015-10-01 at 18:02 +0100, George Dunlap wrote:
> > > On 25/09/15 03:11, Chunyan Liu wrote:
> > > > Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list,
> > > > usb-attach and usb-detach.
> > > > 
> > > > To attach a usb device to guest through pvusb, one could follow
> > > > following example:
> > > > 
> > > >  #xl usb-ctrl-attach test_vm version=1 num_ports=8
> > > 
> > > So all the way back in v2 of this series, I suggested making the
> > > arguments for usb-ctrl-attach and usb-attach mirror the format that
> > > is
> > > found in the config file[1]
> > > [...]
> > > [1]
> > > marc.info/?i=<
> > > caflbxzb1n3_9pvvg-yc8dyvaiyszvra3h2e8496vhnefvrm...@mail.gmail.com>
> > 
> > Re: xl usb-ctrl-attach test_vm name=pv-1,type=pv,version=1,ports=8
> > 
> > FWIW I think most of the existing ones allow (but don't require) a
> > slight
> > difference in the cli version, which is that they allow space spearated
> > lists as well as command separate, which ends up a bit more natural:
> > 
> > xl usb-ctrl-attach test_vm name=pv-1 type=pv version=1 ports=8
> > 
[...]

BTW this is generally pretty easy to arrange, You have a helper:
parse_foo(const char *s, libxl_foo *foo) 
which takes a comma separate list "s" and _incremntally_ updates the object
"foo" which it was given.

Then when parsing the cfg file you call parse_foo on the string and when
parsing the command line you call parse_foo for every argv (with the same
object).

See e.g. parse_nic_config in xl_cmdimpl.c.

Disk does it a bit differently with parse_disk_config and
parse_disk_config_multistring, where the latter effectively incorporates
the loop over argv.

Ian.

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

Re: [Xen-devel] [PATCH v2 3/5] libxc: create unmapped initrd in domain builder if supported

[Ian Campbell]

On Fri, 2015-10-02 at 17:13 +0200, Juergen Gross wrote:
> On 10/02/2015 04:56 PM, Ian Campbell wrote:
> > On Fri, 2015-10-02 at 16:46 +0200, Juergen Gross wrote:
> > > On 10/02/2015 02:59 PM, Ian Campbell wrote:
> > > > On Fri, 2015-10-02 at 07:49 +0200, Juergen Gross wrote:
> > > > > In case the kernel of a new pv-domU indicates it is supporting an
> > > > > unmapped initrd, don't waste precious virtual space for the
> > > > > initrd,
> > > > > but allocate only guest physical memory for it.
> > > > > 
> > > > > Signed-off-by: Juergen Gross 
> > > > > ---
> > > > >tools/libxc/xc_dom_core.c | 22 --
> > > > >1 file changed, 20 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/tools/libxc/xc_dom_core.c
> > > > > b/tools/libxc/xc_dom_core.c
> > > > > index b510bbd..85b531a 100644
> > > > > --- a/tools/libxc/xc_dom_core.c
> > > > > +++ b/tools/libxc/xc_dom_core.c
> > > > > @@ -1019,8 +1019,9 @@ int xc_dom_build_image(struct xc_dom_image
> > > > > *dom)
> > > > >if ( dom->kernel_loader->loader(dom) != 0 )
> > > > >goto err;
> > > > > 
> > > > > -/* load ramdisk */
> > > > > -if ( dom->ramdisk_blob )
> > > > > +/* Load ramdisk if initial mapping required. */
> > > > > +if ( dom->ramdisk_blob &&
> > > > > + (!dom->parms.mod_start_pfn || dom->ramdisk_seg.vstart)
> > > > > )
> > > > >{
> > > > >if ( xc_dom_build_ramdisk(dom) != 0 )
> > > > >goto err;
> > > > > @@ -1063,6 +1064,23 @@ int xc_dom_build_image(struct xc_dom_image
> > > > > *dom)
> > > > >  __FUNCTION__, dom->virt_alloc_end);
> > > > >DOMPRINTF("%-20s: virt_pgtab_end : 0x%" PRIx64 "",
> > > > >  __FUNCTION__, dom->virt_pgtab_end);
> > > > > +
> > > > > +/* Prepare allocating unmapped memory. */
> > > > > +if ( dom->virt_pgtab_end )
> > > > > +dom->virt_alloc_end = dom->virt_pgtab_end;
> > > > > +
> > > > > +/* Load ramdisk if no initial mapping required. */
> > > > > +if ( dom->ramdisk_blob && !dom->ramdisk_seg.vstart &&
> > > > > + dom->parms.mod_start_pfn )
> > > > > +{
> > > > > +if ( xc_dom_build_ramdisk(dom) != 0 )
> > > > > +goto err;
> > > > > +dom->flags |= SIF_MOD_START_PFN;
> > > > > +dom->ramdisk_seg.vend = dom->ramdisk_seg.vend - dom
> > > > > ->ramdisk_seg.vstart;
> > > > > +dom->ramdisk_seg.vstart = dom->ramdisk_seg.pfn;
> > > > > +dom->ramdisk_seg.vend += dom->ramdisk_seg.vstart;
> > > > 
> > > > This seems like it is trying to do something clever, like partially
> > > > reversing something which the xc_dom_alloc_segment call in
> > > >xc_dom_build_ramdisk has done.
> > > 
> > > It's just changing the boundaries of the initrd to fit the interface
> > > for it being not mapped (indicated by the SIF_MOD_START_PFN flag).
> > 
> > So something has initialised these fields as if it were mapped and we
> > are
> > now undoing it because in reality it is not? IOW something has arranged
> > things such that vstart and vend are invalid before this adjustment.
> > 
> > So whatever is making these allocations and mapping (or not) them
> > should
> > instead be fixed to just do things correctly from the start.
> > 
> > Am I correct that after this the vstart and vend actually contain
> > physical
> > addresses? Does anything use them that way, and how does it know if
> > they
> > are physical or virtual?
> > 
> > Perhaps the right answer is to add pstart and pend and to initialise
> > those
> > correctly (for everything) while leaving the v* ones set to some
> > sentinel
> > value to indicate when things are unmapped?
> 
> I want to do something like this, yes.
> 
> > > > It looks like the vend handling in particular is just a complicated
> > > > way
> > > > of
> > > > subtracting vstart and adding pfn, with the aim of rebasing from
> > > > virt
> > > > to
> > > > phys world.
> > > 
> > > Hmm, not more complicated as:
> > > 
> > > len = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
> > > dom->ramdisk_seg.vstart = dom->ramdisk_seg.pfn;
> > > dom->ramdisk_seg.vend = dom->ramdisk_seg.pfn + len;
> > > 
> > > I have to admit that above variant might be easier to understand. :-)
> > 
> > It is, much easier.
> 
> :-)
> 
> > > > Plus vstart/end are addresses, while presumably pfn is a page
> > > > number,
> > > > so
> > > > I'm confused about that as well.
> > > 
> > > The naming is irritating, yes.
> > 
> > Are you saying that pfn is actually a physical address?
> 
> It's a page number.
> 
> The start_info page data regarding the initrd is taken from
> dom->ramdisk_seg. The length is computed from vend - vstart and the
> start of the initrd is either a virtual address or a pfn.

So are vend and vstart frame numbers then?

They had better be, because otherwise the length you are computing is in
bytes, so adding it to a frame number in vstart makes no sense.

Ian.

Re: [Xen-devel] [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity is the same for Xen and Linux

[Boris Ostrovsky]

On 10/02/2015 10:52 AM, Julien Grall wrote:

On 02/10/15 15:31, Julien Grall wrote:

Hi David,

On 02/10/15 15:09, David Vrabel wrote:

On 30/09/15 11:45, Julien Grall wrote:

For ARM64 guests, Linux is able to support either 64K or 4K page
granularity. Although, the hypercall interface is always based on 4K
page granularity.

With 64K page granularity, a single page will be spread over multiple
Xen frame.

To avoid splitting the page into 4K frame, take advantage of the
extent_order field to directly allocate/free chunk of the Linux page
size.

Note that PVMMU is only used for PV guest (which is x86) and the page
granularity is always 4KB. Some BUILD_BUG_ON has been added to ensure
that because the code has not been modified.

This causes a BUG() in x86 PV guests when decreasing the reservation.

Xen says:

(XEN) d0v2 Error pfn 0: rd=0 od=32753 caf=8001
taf=7401
(XEN) memory.c:250:d0v2 Bad page free for domain 0

And Linux BUGs with:

[   82.032654] kernel BUG at
/anfs/drall/scratch/davidvr/x86/linux/drivers/xen/balloon.c:540!

Which is a non-zero return value from the decrease_reservation hypercall.

The frame_list[] has been incorrectly populated.  The below patch fixes
it for me.  Please test as well.

FIY, I've just tested with the patch on ARM64 and I haven't see any issue.



I had a quick one-off test and this fixes it on x86. I'll schedule it 
for the overnight run too.


-boris





Sorry for the breakage, I think I haven't spot the bug on my board
because most the PV drivers are allocating one balloon page at the time
by default.

This patch looks valid to me. i was resetting and incremented for each
loop on an early version. Although I dropped it by mistake when I use a
different way to decrease the reservation.







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

Re: [Xen-devel] [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity is the same for Xen and Linux

[David Vrabel]

On 02/10/15 15:52, Julien Grall wrote:
> On 02/10/15 15:31, Julien Grall wrote:
>> Hi David,
>>
>> On 02/10/15 15:09, David Vrabel wrote:
>>> On 30/09/15 11:45, Julien Grall wrote:
 For ARM64 guests, Linux is able to support either 64K or 4K page
 granularity. Although, the hypercall interface is always based on 4K
 page granularity.

 With 64K page granularity, a single page will be spread over multiple
 Xen frame.

 To avoid splitting the page into 4K frame, take advantage of the
 extent_order field to directly allocate/free chunk of the Linux page
 size.

 Note that PVMMU is only used for PV guest (which is x86) and the page
 granularity is always 4KB. Some BUILD_BUG_ON has been added to ensure
 that because the code has not been modified.
>>>
>>> This causes a BUG() in x86 PV guests when decreasing the reservation.
>>>
>>> Xen says:
>>>
>>> (XEN) d0v2 Error pfn 0: rd=0 od=32753 caf=8001
>>> taf=7401
>>> (XEN) memory.c:250:d0v2 Bad page free for domain 0
>>>
>>> And Linux BUGs with:
>>>
>>> [   82.032654] kernel BUG at
>>> /anfs/drall/scratch/davidvr/x86/linux/drivers/xen/balloon.c:540!
>>>
>>> Which is a non-zero return value from the decrease_reservation hypercall.
>>>
>>> The frame_list[] has been incorrectly populated.  The below patch fixes
>>> it for me.  Please test as well.
> 
> FIY, I've just tested with the patch on ARM64 and I haven't see any issue.

Thanks, I've folded it in.

Boris, can we get another test run on the for-linus-4.4 branch, please?

David

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

Re: [Xen-devel] [PATCH V7 5/7] xl: add pvusb commands

[George Dunlap]

On Fri, Oct 2, 2015 at 2:35 PM, Ian Campbell  wrote:
> On Thu, 2015-10-01 at 18:02 +0100, George Dunlap wrote:
>> On 25/09/15 03:11, Chunyan Liu wrote:
>> > Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list,
>> > usb-attach and usb-detach.
>> >
>> > To attach a usb device to guest through pvusb, one could follow
>> > following example:
>> >
>> >  #xl usb-ctrl-attach test_vm version=1 num_ports=8
>>
>> So all the way back in v2 of this series, I suggested making the
>> arguments for usb-ctrl-attach and usb-attach mirror the format that is
>> found in the config file[1]
>> [...]
>> [1]
>> marc.info/?i=<
>> caflbxzb1n3_9pvvg-yc8dyvaiyszvra3h2e8496vhnefvrm...@mail.gmail.com>
>
> Re: xl usb-ctrl-attach test_vm name=pv-1,type=pv,version=1,ports=8
>
> FWIW I think most of the existing ones allow (but don't require) a slight
> difference in the cli version, which is that they allow space spearated
> lists as well as command separate, which ends up a bit more natural:
>
> xl usb-ctrl-attach test_vm name=pv-1 type=pv version=1 ports=8
>
> I also agree that we should try and do something similar here unless there
> is a compelling reason we can't.

I didn't realize that. +1

 -George

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

Re: [Xen-devel] [PATCH v1 5/5] xsplice: Use ld-embedded build-ids

[Jan Beulich]

>>> On 16.09.15 at 23:01,  wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -108,11 +108,11 @@ $(TARGET)-syms: prelink.o xen.lds 
> $(BASEDIR)/common/symbols-dummy.o
>   $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
>   $(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
>   $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
> - $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> + $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
>   $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
>   $(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
>   $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
> - $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> + $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
>   $(@D)/.$(@F).1.o -o $@
>   rm -f $(@D)/.$(@F).[0-9]*

Which raises the question: What about xen.efi?

> @@ -44,6 +46,36 @@ struct payload {
>  struct tasklet tasklet;
>  };
>  
> +#ifdef CONFIG_ARM
> +static int build_id(char **p, unsigned int *len)
> +{
> +return 0;
> +}
> +#else

Any reason not to make the build logic common, in order to avoid such
#ifdef-ery?


> +extern char * __note_gnu_build_id_start;  /* defined in linker script */

const, and I think you mean the type to be Elf_Note[].

> @@ -68,9 +100,31 @@ static const char *status2str(int64_t status)
>  return names[status];
>  }
>  
> +#define LEN 128

Because of?

>  void xsplice_printall(unsigned char key)
>  {
>  struct payload *data;
> +char *binary_id = NULL;
> +unsigned int len = 0;
> +int rc;
> +
> +rc = build_id(&binary_id, &len);
> +printk("build-id: ");
> +if ( !rc )
> +{
> +unsigned int i;
> +
> +if ( len > LEN )
> +len = LEN;
> +
> +for ( i = 0; i < len; i++ )
> +{
> + uint8_t c = binary_id[i];
> + printk("%02x", c);

Hard tabs.

> +}
> + printk("\n");
> +} else if ( rc < 0 )

Coding style.

> @@ -415,6 +470,34 @@ static int xsplice_action(xen_sysctl_xsplice_action_t 
> *action)
>  return rc;
>  }
>  
> +static int xsplice_info(xen_sysctl_xsplice_info_t *info)
> +{
> +int rc;
> +unsigned int len = 0;
> +char *p = NULL;
> +
> +if ( info->cmd != XEN_SYSCTL_XSPLICE_INFO_BUILD_ID )
> +return -EINVAL;
> +
> +if ( info->size == 0 )
> +return -EINVAL;
> +
> +if ( !guest_handle_okay(info->u.info, info->size) )
> +return -EFAULT;
> +
> +rc = build_id(&p, &len);
> +if ( rc )
> +return rc;
> +
> +if ( len > info->size )
> +return -ENOMEM;
> +
> +if ( copy_to_guest(info->u.info, p, len) )
> +return -EFAULT;

So how does the caller know how much data got copied?

Jan


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

Re: [Xen-devel] [PATCH v1 2/5] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

[Jan Beulich]

>>> On 16.09.15 at 23:01,  wrote:
> --- /dev/null
> +++ b/xen/common/xsplice.c
> @@ -0,0 +1,442 @@
> +/*
> + * xSplice - Copyright Oracle Corp. Inc 2015.
> + *
> + * Author: Konrad Rzeszutek Wilk 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

No. This header should only be used in a very limited set up cases
(namely source code shared with the tools). Looks like we accumulated
a few other violations.

> +struct payload {
> +char  *id;  /* Name of it. Past this structure. */
> +ssize_t id_len; /* Length of the name. */
> +
> +uint8_t *raw;   /* Pointer to Elf file. Past 'id'*/
> +ssize_t raw_len;/* Size of 'raw'. */
> +
> +int32_t status; /* XSPLICE_STATUS_* or Exx type value. */
> +int32_t old_status; /* XSPLICE_STATUS_* or Exx type value. */
> +
> +struct spinlock cmd_lock; /* Lock against the action. */
> +uint32_t cmd;   /* Action request. XSPLICE_ACTION_* */
> +
> +/* Boring things below: */
> +struct list_head   list;   /* Linked to 'payload_list'. */
> +ssize_t len;/* This structure + raw_len + id_len + 1. */
> +
> +struct tasklet tasklet;

char name[]; here would avoid some casting further down.

> +static const char *status2str(int64_t status)
> +{
> +#define STATUS(x) [XSPLICE_STATUS_##x] = #x
> +static const char *const names[] = {
> +STATUS(LOADED),
> +STATUS(PROGRESS),
> +STATUS(CHECKED),
> +STATUS(APPLIED),
> +STATUS(REVERTED),
> +};

This array will grow unreasonably once we gain a few more
XSPLICE_STATUS_* values (which are bits masks, not enum like
values).

> +int find_payload(xen_xsplice_id_t *id, bool_t need_lock, struct payload **f)

static?

> +{
> +struct payload *data;
> +XEN_GUEST_HANDLE_PARAM(char) str;
> +char name[XEN_XSPLICE_ID_SIZE]; /* 128 bytes on stack. Perhaps kzalloc? 
> */

I don't think 128 bytes are a significant problem, unless this could
be run in the context of an interrupt.

> +static int xsplice_upload(xen_sysctl_xsplice_upload_t *upload)
> +{
> +struct payload *data = NULL;
> +int rc;
> +ssize_t len;
> +
> +rc = verify_payload(upload);
> +if ( rc )
> +return rc;
> +
> +rc = find_payload(&upload->id, true, &data);
> +if ( rc == 0 /* Found. */ )
> +return -EEXIST;
> +
> +if ( rc != -ENOENT )
> +return rc;
> +
> +/*
> + * Compute the size of the structures which need to be verified.
> + * The 1 is for the extra \0 in case name does not have it.
> + */
> +len = sizeof(*data) + upload->id.size + 1 + upload->size;
> +data = alloc_xenheap_pages(get_order_from_bytes(len), 0);
> +if ( !data )
> +return -ENOMEM;
> +
> +memset(data, 0, len);
> +data->len = len;
> +
> +/* At the end of structure we put the name. */
> +data->id = (char *)data + sizeof(*data);
> +data->id_len = upload->id.size;
> +/* And after the name + \0 we stick the raw ELF data. */
> +data->raw = (uint8_t *)data + sizeof(*data) + data->id_len + 1;

Please use data->id here to shorten the expression.

> +static int xsplice_list(xen_sysctl_xsplice_list_t *list)
> +{
> +xen_xsplice_status_t status;
> +struct payload *data;
> +unsigned int idx = 0, i = 0;
> +int rc = 0;
> +unsigned int ver = payload_version;

Is it correct to latch this before taking the lock?

> +// TODO: Increase to a 64 or other value. Leave 4 for debug.
> +if ( list->nr > 4 )
> +return -E2BIG;

Command line driven?

> +if ( list->_pad != 0 )
> +return -EINVAL;
> +
> +if ( guest_handle_is_null(list->status) ||
> + guest_handle_is_null(list->id) ||
> + guest_handle_is_null(list->len) )
> +return -EINVAL;

Are these really useful?

> +if ( !guest_handle_okay(list->status, sizeof(status) * list->nr) ||
> + !guest_handle_okay(list->id, XEN_XSPLICE_ID_SIZE * list->nr) ||
> + !guest_handle_okay(list->len, sizeof(uint32_t) * list->nr) )
> +return -EINVAL;
> +
> +spin_lock(&payload_list_lock);
> +if ( list->idx > payload_cnt )
> +{
> +spin_unlock(&payload_list_lock);
> +return -EINVAL;
> +}
> +
> +status._pad = 0; /* No stack leaking. */
> +list_for_each_entry( data, &payload_list, list )
> +{
> +uint32_t len;
> +
> +if ( list->idx > i++ )
> +continue;
> +
> +status.status = data->status;
> +len = data->id_len;
> +
> +/* N.B. 'idx' != 'i'. */
> +if ( copy_to_guest_offset(list->id, idx * XEN_XSPLICE_ID_SIZE,
> +  data->id, len) ||
> + copy_to_guest_offset(list->len, idx, &len, 1) ||
> + copy_to_guest_offset(list->status, idx, &status, 1) )
> +{
> +rc = -EFAULT;
> +break;
> +}
> +idx ++;
> +if ( hyperc

Re: [Xen-devel] [PATCH v2 3/5] libxc: create unmapped initrd in domain builder if supported

[Juergen Gross]

On 10/02/2015 04:56 PM, Ian Campbell wrote:

On Fri, 2015-10-02 at 16:46 +0200, Juergen Gross wrote:

On 10/02/2015 02:59 PM, Ian Campbell wrote:

On Fri, 2015-10-02 at 07:49 +0200, Juergen Gross wrote:

In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the initrd,
but allocate only guest physical memory for it.

Signed-off-by: Juergen Gross 
---
   tools/libxc/xc_dom_core.c | 22 --
   1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index b510bbd..85b531a 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1019,8 +1019,9 @@ int xc_dom_build_image(struct xc_dom_image
*dom)
   if ( dom->kernel_loader->loader(dom) != 0 )
   goto err;

-/* load ramdisk */
-if ( dom->ramdisk_blob )
+/* Load ramdisk if initial mapping required. */
+if ( dom->ramdisk_blob &&
+ (!dom->parms.mod_start_pfn || dom->ramdisk_seg.vstart) )
   {
   if ( xc_dom_build_ramdisk(dom) != 0 )
   goto err;
@@ -1063,6 +1064,23 @@ int xc_dom_build_image(struct xc_dom_image
*dom)
 __FUNCTION__, dom->virt_alloc_end);
   DOMPRINTF("%-20s: virt_pgtab_end : 0x%" PRIx64 "",
 __FUNCTION__, dom->virt_pgtab_end);
+
+/* Prepare allocating unmapped memory. */
+if ( dom->virt_pgtab_end )
+dom->virt_alloc_end = dom->virt_pgtab_end;
+
+/* Load ramdisk if no initial mapping required. */
+if ( dom->ramdisk_blob && !dom->ramdisk_seg.vstart &&
+ dom->parms.mod_start_pfn )
+{
+if ( xc_dom_build_ramdisk(dom) != 0 )
+goto err;
+dom->flags |= SIF_MOD_START_PFN;
+dom->ramdisk_seg.vend = dom->ramdisk_seg.vend - dom
->ramdisk_seg.vstart;
+dom->ramdisk_seg.vstart = dom->ramdisk_seg.pfn;
+dom->ramdisk_seg.vend += dom->ramdisk_seg.vstart;


This seems like it is trying to do something clever, like partially
reversing something which the xc_dom_alloc_segment call in
   xc_dom_build_ramdisk has done.


It's just changing the boundaries of the initrd to fit the interface
for it being not mapped (indicated by the SIF_MOD_START_PFN flag).


So something has initialised these fields as if it were mapped and we are
now undoing it because in reality it is not? IOW something has arranged
things such that vstart and vend are invalid before this adjustment.

So whatever is making these allocations and mapping (or not) them should
instead be fixed to just do things correctly from the start.

Am I correct that after this the vstart and vend actually contain physical
addresses? Does anything use them that way, and how does it know if they
are physical or virtual?

Perhaps the right answer is to add pstart and pend and to initialise those
correctly (for everything) while leaving the v* ones set to some sentinel
value to indicate when things are unmapped?


I want to do something like this, yes.


It looks like the vend handling in particular is just a complicated way
of
subtracting vstart and adding pfn, with the aim of rebasing from virt
to
phys world.


Hmm, not more complicated as:

len = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
dom->ramdisk_seg.vstart = dom->ramdisk_seg.pfn;
dom->ramdisk_seg.vend = dom->ramdisk_seg.pfn + len;

I have to admit that above variant might be easier to understand. :-)


It is, much easier.


:-)


Plus vstart/end are addresses, while presumably pfn is a page number,
so
I'm confused about that as well.


The naming is irritating, yes.


Are you saying that pfn is actually a physical address?


It's a page number.

The start_info page data regarding the initrd is taken from
dom->ramdisk_seg. The length is computed from vend - vstart and the
start of the initrd is either a virtual address or a pfn.

I guess it would be a good idea to add something like mod_start and
mod_len to struct xc_dom_image and init those according to the
allocation (virtual or physical). start_info can then be filled from
those new members.


Juergen


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

Re: [Xen-devel] [PATCH v2 1/5] libxc: remove allocate member from struct xc_dom_image

[Juergen Gross]

On 10/02/2015 04:47 PM, Ian Campbell wrote:

On Fri, 2015-10-02 at 16:25 +0200, Juergen Gross wrote:

On 10/02/2015 03:01 PM, Ian Campbell wrote:

On Fri, 2015-10-02 at 07:49 +0200, Juergen Gross wrote:

The allocate() callback in struct xc_dom_image is never set. Remove
it.

Signed-off-by: Juergen Gross 
Acked-by: Ian Jackson 


This breaks the stubdom build:

kexec.c: In function ‘kexec’:
kexec.c:221:78: warning: taking address of expression of type ‘void’
   xen_pfn_t boot_page_mfn = virt_to_mfn(&_boot_page);

 ^
kexec.c:230:8: error: ‘struct xc_dom_image’ has no member named
‘allocate’
   dom->allocate = kexec_allocate;
  ^
kexec.c:318:60: warning: taking address of expression of type ‘void’
   virt_to_mfn(&_boot_page));
  ^
Makefile:79: recipe for target '/local/scratch/ianc/devel/committer
-amd64.git/stubdom/grub-x86_64/kexec.o' failed

On i386 too.

And in fact that hook looks useful in that context, so either it needs
to
stay of stubdom kexec needs changing to work some other way.


Too bad.

I wanted to remove the allocate callback as it will conflict with the
allocations of memory outside the initial default mapping.

Just to make sure I understand this correctly:

stubdom is used in this context to support grub running as a pv domain
capable to start another pv domain.


Correct.


So as long as stubdom doesn't support mapping the p2m list outside the
default mapping it makes no sense to support this feature for any domain
started via stubdom/grub (the main reason to use this feature is the
support of huge memory causing the p2m list to exceed the available
virtual address space of the default mapping).


By "default mapping" you mean the mapping established by the domain builder
which made the domain, as distinct from any mapping which the guest kernel
might establish by itself later, right?


Yes.


I'm not sure that there is any link between the stubdomain's own p2m and
the default mapping of that and the p2m which it is building for use of the
domain it is going to kexec and the default mappings of that p2m-to-be from
the PoV of the to-be-kexec'd guest kernel.


I just checked it again. Initially I thought stubdom would have the same
limitations as Linux regarding the p2m size. But this is not true, as
stubdom's virt_base is 0, while Linux is using 8000.


I'm not sure how kexec operates in this regard.


So the easy solution would be to not support initrd and p2m outside the
default mapping when the allocate callback is set. Do you think this
solution is okay?


Irrespective of the above just not supporting this mode would be one way to
avoid the issue. It would make domains using pvgrub1 have different
limitations than domains built directly. IOW users will have to trade off
the security benefits of pvgrub vs the size of the domain they wish to
build, which is a shame.


Hmm, maybe it's possible to add the support to stubdom. With the limit
of the p2m size not hitting stubdom it might be rather easy. I'll try
it.


On the other hand pvgrub2 now exists as a separate (out of tree, it's in
grub.git) thing anyway which doesn't use this domain builder at all AFAIK
and that's the one I expect people are using going forward anyway.


Hmm, another place where huge domain support is to be added, I guess.


Juergen


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

Re: [Xen-devel] [PATCH v2 3/5] libxc: create unmapped initrd in domain builder if supported

[Ian Campbell]

On Fri, 2015-10-02 at 16:46 +0200, Juergen Gross wrote:
> On 10/02/2015 02:59 PM, Ian Campbell wrote:
> > On Fri, 2015-10-02 at 07:49 +0200, Juergen Gross wrote:
> > > In case the kernel of a new pv-domU indicates it is supporting an
> > > unmapped initrd, don't waste precious virtual space for the initrd,
> > > but allocate only guest physical memory for it.
> > > 
> > > Signed-off-by: Juergen Gross 
> > > ---
> > >   tools/libxc/xc_dom_core.c | 22 --
> > >   1 file changed, 20 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> > > index b510bbd..85b531a 100644
> > > --- a/tools/libxc/xc_dom_core.c
> > > +++ b/tools/libxc/xc_dom_core.c
> > > @@ -1019,8 +1019,9 @@ int xc_dom_build_image(struct xc_dom_image
> > > *dom)
> > >   if ( dom->kernel_loader->loader(dom) != 0 )
> > >   goto err;
> > > 
> > > -/* load ramdisk */
> > > -if ( dom->ramdisk_blob )
> > > +/* Load ramdisk if initial mapping required. */
> > > +if ( dom->ramdisk_blob &&
> > > + (!dom->parms.mod_start_pfn || dom->ramdisk_seg.vstart) )
> > >   {
> > >   if ( xc_dom_build_ramdisk(dom) != 0 )
> > >   goto err;
> > > @@ -1063,6 +1064,23 @@ int xc_dom_build_image(struct xc_dom_image
> > > *dom)
> > > __FUNCTION__, dom->virt_alloc_end);
> > >   DOMPRINTF("%-20s: virt_pgtab_end : 0x%" PRIx64 "",
> > > __FUNCTION__, dom->virt_pgtab_end);
> > > +
> > > +/* Prepare allocating unmapped memory. */
> > > +if ( dom->virt_pgtab_end )
> > > +dom->virt_alloc_end = dom->virt_pgtab_end;
> > > +
> > > +/* Load ramdisk if no initial mapping required. */
> > > +if ( dom->ramdisk_blob && !dom->ramdisk_seg.vstart &&
> > > + dom->parms.mod_start_pfn )
> > > +{
> > > +if ( xc_dom_build_ramdisk(dom) != 0 )
> > > +goto err;
> > > +dom->flags |= SIF_MOD_START_PFN;
> > > +dom->ramdisk_seg.vend = dom->ramdisk_seg.vend - dom
> > > ->ramdisk_seg.vstart;
> > > +dom->ramdisk_seg.vstart = dom->ramdisk_seg.pfn;
> > > +dom->ramdisk_seg.vend += dom->ramdisk_seg.vstart;
> > 
> > This seems like it is trying to do something clever, like partially
> > reversing something which the xc_dom_alloc_segment call in
> >   xc_dom_build_ramdisk has done.
> 
> It's just changing the boundaries of the initrd to fit the interface
> for it being not mapped (indicated by the SIF_MOD_START_PFN flag).

So something has initialised these fields as if it were mapped and we are
now undoing it because in reality it is not? IOW something has arranged
things such that vstart and vend are invalid before this adjustment.

So whatever is making these allocations and mapping (or not) them should
instead be fixed to just do things correctly from the start.

Am I correct that after this the vstart and vend actually contain physical
addresses? Does anything use them that way, and how does it know if they
are physical or virtual?

Perhaps the right answer is to add pstart and pend and to initialise those
correctly (for everything) while leaving the v* ones set to some sentinel
value to indicate when things are unmapped?


> > It looks like the vend handling in particular is just a complicated way
> > of
> > subtracting vstart and adding pfn, with the aim of rebasing from virt
> > to
> > phys world.
> 
> Hmm, not more complicated as:
> 
> len = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
> dom->ramdisk_seg.vstart = dom->ramdisk_seg.pfn;
> dom->ramdisk_seg.vend = dom->ramdisk_seg.pfn + len;
> 
> I have to admit that above variant might be easier to understand. :-)

It is, much easier.


> > Plus vstart/end are addresses, while presumably pfn is a page number,
> > so
> > I'm confused about that as well.
> 
> The naming is irritating, yes.

Are you saying that pfn is actually a physical address?

Ian.

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

[Xen-devel] [PATCH v2 1/4] libxl: convert to use LOG() macro

[Wei Liu]

This patch converts most LIBXL__LOG* macros to LOG macro. It's done with
spatch plus some hand coding.

Using spatch rune:

spatch --in-place --no-includes --include-headers \
--sp-file libxl.spatch \
tools/libxl/libxl*.c

with some exceptions.

libxl_json.c is untouched because the notion of ctx is in fact referring
to yajl context.

libxl_qmp.c is untouched because libxl ctx is buried in qmp context.

libxl_fork.c is untouched because it's clearer to just use original
code.

Some fallouts are dealt with manually. There are three categories.

Functions that don't have gc defined. Add gc definition with GC_INIT.
Also try my best to make them conform with libxl coding style.

 * libxl_list_domain
 * libxl_domain_info
 * libxl_domain_pause
 * libxl_get_physinfo
 * libxl_domain_set_nodeaffinity
 * libxl_domain_get_nodeaffinity
 * libxl_get_scheduler
 * libxl_sched_credit_params_get
 * libxl_sched_credit_params_set
 * libxl_send_debug_keys
 * libxl_xen_console_read_line
 * libxl_tmem_list
 * libxl_tmem_freeze
 * libxl_tmem_thaw
 * libxl_tmem_set
 * libxl_tmem_shared_auth
 * libxl_tmem_freeable
 * libxl_fd_set_cloexec
 * libxl_fd_set_nonblock
 * libxl__init_recursive_mutex
 * READ_WRITE_EXACTLY
 * libxl__ao_complete_check_progress_reports

Functions don't need ctx variable anymore after conversion. Delete that
variable.

 * libxl__device_from_disk
 * domcreate_rebuild_done
 * domcreate_devmodel_started
 * domcreate_attach_pci
 * libxl__domain_device_model
 * libxl__build_device_model_args_new
 * libxl__build_device_model_args
 * libxl__create_pci_backend
 * libxl__device_pci_add_xenstore
 * sysfs_write_bdf
 * sysfs_dev_unbind
 * pciback_dev_has_slot
 * pciback_dev_is_assigned
 * pciback_dev_assign
 * pciback_dev_unassign
 * pci_assignable_driver_path_write
 * libxl__device_pci_assignable_remove
 * libxl__xenstore_child_wait_deprecated
 * libxl__xs_libxl_path
 * libxl__device_model_version_running

Special handling for some functions.

 * ao__abort: easier to just use original code.
 * e820_sanitize: should have taken gc instead of ctx

=
virtual patch
virtual context
virtual org
virtual report

@level1@
identifier FN =~ "LIBXL__LOG|LIBXL__LOG_ERRNO|LIBXL__LOG_ERRNOVAL";
constant l1 =~ "(LIBXL__LOG|XTL)_(DEBUG|INFO|WARNING|ERROR)";
expression ctx;
@@
FN(ctx, l1, ...);

@script:python level2@
l1 << level1.l1;
l2;
@@

import re
coccinelle.l2 = re.sub("LIBXL__LOG_|XTL_", "", l1);
if coccinelle.l2 == "WARNING": coccinelle.l2 = "WARN"

@log10@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
@@
-LIBXL__LOG(ctx, l1, fmt);
+LOG(l2, fmt);

@log11@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression arg1;
@@
-LIBXL__LOG(ctx, l1, fmt, arg1);
+LOG(l2, fmt, arg1);

@log12@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression arg1, arg2;
@@
-LIBXL__LOG(ctx, l1, fmt, arg1, arg2);
+LOG(l2, fmt, arg1, arg2);

@log13@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression arg1, arg2, arg3;
@@
-LIBXL__LOG(ctx, l1, fmt, arg1, arg2, arg3);
+LOG(l2, fmt, arg1, arg2, arg3);

@log20@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
@@
-LIBXL__LOG_ERRNO(ctx, l1, fmt);
+LOGE(l2, fmt);

@log21@
expression ctx;
expression fmt;
constant level1.l1;
identifier level2.l2;
expression arg1;
@@
-LIBXL__LOG_ERRNO(ctx, l1, fmt, arg1);
+LOGE(l2, fmt, arg1);

@log22@
expression ctx;
expression fmt;
constant level1.l1;
identifier level2.l2;
expression arg1, arg2;
@@
-LIBXL__LOG_ERRNO(ctx, l1, fmt, arg1, arg2);
+LOGE(l2, fmt, arg1, arg2);

@log23@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression arg1, arg2, arg3;
@@
-LIBXL__LOG_ERRNO(ctx, l1, fmt, arg1, arg2, arg3);
+LOGE(l2, fmt, arg1, arg2, arg3);

@log30@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression errnoval;
@@
-LIBXL__LOG_ERRNOVAL(ctx, l1, errnoval, fmt);
+LOGEV(l2, errnoval, fmt);

@log31@
expression fmt;
expression arg1;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression errnoval;
@@
-LIBXL__LOG_ERRNOVAL(ctx, l1, errnoval, fmt, arg1);
+LOGEV(l2, errnoval, fmt, arg1);

@log32@
expression fmt;
expression arg1, arg2;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression errnoval;
@@
-LIBXL__LOG_ERRNOVAL(ctx, l1, errnoval, fmt, arg1, arg2);
+LOGEV(l2, errnoval, fmt, arg1, arg2);
=

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl.c  | 386 +++
 tools/libxl/libxl_create.c   |  37 ++---
 tools/libxl/libxl_dm.c   |  50 +++---
 tools/libxl/libxl_dom.c  |  17 +-
 tools/libxl/libxl_event.c|  48 +++---
 tools/libxl/libxl_exec.c |   5 +-
 tools/libxl/libxl_internal.c |  17 +-
 tools/libxl/libxl_pci.c  | 158 --
 tools/libxl/libxl_utils.c|  17 +-
 tools/libxl/libxl_x86.c  |  18 +-
 tools/libxl/libxl_xshelp.c   |   6 +-
 1

[Xen-devel] [PATCH v2 3/4] libxl: map LIBXL__LOG_VERBOSE to XTL_VERBOSE

[Wei Liu]

There is code in libxl using XTL_VERBOSE. We should provide a libxl
mapping for it.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_internal.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c2413c2..d035b6d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1637,6 +1637,7 @@ _hidden const libxl_vnc_info *libxl__dm_vnc(const 
libxl_domain_config *g_cfg);
 _hidden char *libxl__abs_path(libxl__gc *gc, const char *s, const char *path);
 
 #define LIBXL__LOG_DEBUG   XTL_DEBUG
+#define LIBXL__LOG_VERBOSE XTL_VERBOSE
 #define LIBXL__LOG_INFOXTL_INFO
 #define LIBXL__LOG_WARNING XTL_WARN
 #define LIBXL__LOG_ERROR   XTL_ERROR
-- 
2.1.4


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

[Xen-devel] [PATCH v2 4/4] libxl: fix places missed by spatch

[Wei Liu]

The spatch provided in previous patch didn't handle all sites that need
transformation.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl.c| 17 -
 tools/libxl/libxl_create.c |  4 ++--
 tools/libxl/libxl_pci.c| 43 +++
 tools/libxl/libxl_x86.c| 10 +-
 4 files changed, 34 insertions(+), 40 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ca725a9..22bbc29 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1221,11 +1221,10 @@ static void domain_death_xswatch_callback(libxl__egc 
*egc, libxl__ev_xswatch *w,
 }
 gotend = &domaininfos[rc];
 
-LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "[evg=%p:%"PRIu32"]"
-   " nentries=%d rc=%d %ld..%ld",
-   evg, evg->domid, nentries, rc,
-   rc>0 ? (long)domaininfos[0].domain : 0,
-   rc>0 ? (long)domaininfos[rc-1].domain : 0);
+LOG(DEBUG, "[evg=%p:%"PRIu32"] nentries=%d rc=%d %ld..%ld",
+evg, evg->domid, nentries, rc,
+rc>0 ? (long)domaininfos[0].domain : 0,
+rc>0 ? (long)domaininfos[rc-1].domain : 0);
 
 for (;;) {
 if (!evg) {
@@ -1233,10 +1232,10 @@ static void domain_death_xswatch_callback(libxl__egc 
*egc, libxl__ev_xswatch *w,
 goto all_reported;
 }
 
-LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "[evg=%p:%"PRIu32"]"
-   "   got=domaininfos[%d] got->domain=%ld",
-   evg, evg->domid, (int)(got - domaininfos),
-   got < gotend ? (long)got->domain : -1L);
+LOG(DEBUG, "[evg=%p:%"PRIu32"]"
+"   got=domaininfos[%d] got->domain=%ld",
+evg, evg->domid, (int)(got - domaininfos),
+got < gotend ? (long)got->domain : -1L);
 
 if (!rc) {
 domain_death_occurred(egc, &evg, "empty list");
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 30380ec..f0fee00 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -97,8 +97,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 if (rc < 0) {
 /* qemu-xen unavailable, use qemu-xen-traditional */
 if (errno == ENOENT) {
-LIBXL__LOG_ERRNO(CTX, XTL_VERBOSE, "qemu-xen is 
unavailable"
- ", use qemu-xen-traditional instead");
+LOGE(VERBOSE, "qemu-xen is unavailable"
+ ", use qemu-xen-traditional instead");
 b_info->device_model_version =
 LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
 } else {
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 378f6b0..fad2eb6 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -768,7 +768,6 @@ static int libxl__device_pci_assignable_add(libxl__gc *gc,
 libxl_device_pci *pcidev,
 int rebind)
 {
-libxl_ctx *ctx = libxl__gc_owner(gc);
 unsigned dom, bus, dev, func;
 char *spath, *driver_path = NULL;
 int rc;
@@ -793,16 +792,14 @@ static int libxl__device_pci_assignable_add(libxl__gc *gc,
 return ERROR_FAIL;
 }
 if ( rc ) {
-LIBXL__LOG(ctx, LIBXL__LOG_WARNING, PCI_BDF" already assigned to 
pciback",
-   dom, bus, dev, func);
+LOG(WARN, PCI_BDF" already assigned to pciback", dom, bus, dev, func);
 return 0;
 }
 
 /* Check to see if there's already a driver that we need to unbind from */
 if ( sysfs_dev_unbind(gc, pcidev, &driver_path ) ) {
-LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-   "Couldn't unbind "PCI_BDF" from driver",
-   dom, bus, dev, func);
+LOG(ERROR, "Couldn't unbind "PCI_BDF" from driver",
+dom, bus, dev, func);
 return ERROR_FAIL;
 }
 
@@ -812,13 +809,11 @@ static int libxl__device_pci_assignable_add(libxl__gc *gc,
 pci_assignable_driver_path_write(gc, pcidev, driver_path);
 } else if ( (driver_path =
  pci_assignable_driver_path_read(gc, pcidev)) != NULL ) {
-LIBXL__LOG(ctx, LIBXL__LOG_INFO,
-   PCI_BDF" not bound to a driver, will be rebound to %s",
-   dom, bus, dev, func, driver_path);
+LOG(INFO, PCI_BDF" not bound to a driver, will be rebound to %s",
+dom, bus, dev, func, driver_path);
 } else {
-LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
-   PCI_BDF" not bound to a driver, will not be rebound.",
-   dom, bus, dev, func);
+LOG(WARN, PCI_BDF" not bound to a driver, will not be rebound.",
+dom, bus, dev, func);
 }
 } else

[Xen-devel] [PATCH v2 2/4] libxl: fix long lines and delete extraneous quotes

[Wei Liu]

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl.c   | 21 +
 tools/libxl/libxl_utils.c |  8 ++--
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1b754c8..ca725a9 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -420,14 +420,14 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 if (rc == ERROR_INVAL) {
 /* no such domain, good */
 } else if (rc != 0) {
-LOG(ERROR, "unexpected error""checking for existing domain");
+LOG(ERROR, "unexpected error checking for existing domain");
 goto x_rc;
 } else if (domid_e == domid) {
 /* domain already has this name, ok (but we do still
  * need the rest of the code as we may need to check
  * old_name, for example). */
 } else {
-LOG(ERROR, "domain with name \"%s\""" already exists.", new_name);
+LOG(ERROR, "domain with name \"%s\" already exists.", new_name);
 rc = ERROR_INVAL;
 goto x_rc;
 }
@@ -437,14 +437,15 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 got_old_name = xs_read(ctx->xsh, trans, name_path, &got_old_len);
 if (!got_old_name) {
 LOGEV(ERROR, errno,
-  "check old name"" for domain %"PRIu32" allegedly named `%s'",
+  "check old name for domain %"PRIu32" allegedly named `%s'",
   domid,
   old_name);
 goto x_fail;
 }
 if (strcmp(old_name, got_old_name)) {
 LOG(ERROR,
-"domain %"PRIu32" allegedly named ""`%s' is actually named 
`%s' - racing ?",
+"domain %"PRIu32" allegedly named "
+"`%s' is actually named `%s' - racing ?",
 domid,
 old_name,
 got_old_name);
@@ -456,7 +457,8 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 if (!xs_write(ctx->xsh, trans, name_path,
   new_name, strlen(new_name))) {
 LOG(ERROR,
-"failed to write new name `%s'"" for domain %"PRIu32" previously 
named `%s'",
+"failed to write new name `%s'"
+" for domain %"PRIu32" previously named `%s'",
 new_name,
 domid,
 old_name);
@@ -489,14 +491,16 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 trans = our_trans = 0;
 if (errno != EAGAIN) {
 LOG(ERROR,
-"failed to commit new name `%s'"" for domain %"PRIu32" 
previously named `%s'",
+"failed to commit new name `%s'"
+" for domain %"PRIu32" previously named `%s'",
 new_name,
 domid,
 old_name);
 goto x_fail;
 }
 LOG(DEBUG,
-"need to retry rename transaction"" for domain %"PRIu32" 
(name_path=\"%s\", new_name=\"%s\")",
+"need to retry rename transaction"
+" for domain %"PRIu32" (name_path=\"%s\", new_name=\"%s\")",
 domid,
 name_path,
 new_name);
@@ -4802,7 +4806,8 @@ retry_transaction:
 new_target_memkb = target_memkb - videoram;
 if (new_target_memkb > memorykb) {
 LOG(ERROR,
-"memory_dynamic_max must be less than or equal to"" 
memory_static_max\n");
+"memory_dynamic_max must be less than or equal to"
+" memory_static_max\n");
 abort_transaction = 1;
 goto out;
 }
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 2eba584..e42422a 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -409,13 +409,17 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char 
*filename,
   if (got == -1) {\
   if (errno == EINTR) continue;   \
   if (!ctx) { GC_FREE; return errno; }\
-  LOGE(ERROR, "failed to "#rw" %s%s%s", what ? what : "", what ? " 
from " : "", source);   \
+  LOGE(ERROR, "failed to "#rw" %s%s%s",   \
+   what ? what : "", what ? " from " : "", source);   \
   GC_FREE;\
   return errno;   \
   }   \
   if (got == 0) { \
   if (!ctx) { GC_FREE; return  EPROTO; }  \
-  LOG(ERROR, zero_is_eof ? "file/stream truncated reading %s%s%s" 
: "file/stream write returned 0! writing %s%s%s", what ? what : 

[Xen-devel] [PATCH v2 0/4] libxl: use LOG() macro where appropriate

[Wei Liu]

There are mixed usage of different logging macros. Ideally we only use one
style to avoid confusion.

Rebased on top of staging.

Wei Liu (4):
  libxl: convert to use LOG() macro
  libxl: fix long lines and delete extraneous quotes
  libxl: map LIBXL__LOG_VERBOSE to XTL_VERBOSE
  libxl: fix places missed by spatch

 tools/libxl/libxl.c  | 408 +++
 tools/libxl/libxl_create.c   |  41 ++---
 tools/libxl/libxl_dm.c   |  50 +++---
 tools/libxl/libxl_dom.c  |  17 +-
 tools/libxl/libxl_event.c|  48 +++--
 tools/libxl/libxl_exec.c |   5 +-
 tools/libxl/libxl_internal.c |  17 +-
 tools/libxl/libxl_internal.h |   1 +
 tools/libxl/libxl_pci.c  | 201 ++---
 tools/libxl/libxl_utils.c|  21 ++-
 tools/libxl/libxl_x86.c  |  26 ++-
 tools/libxl/libxl_xshelp.c   |   6 +-
 12 files changed, 415 insertions(+), 426 deletions(-)

-- 
2.1.4


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

Re: [Xen-devel] [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity is the same for Xen and Linux

[Julien Grall]

On 02/10/15 15:31, Julien Grall wrote:
> Hi David,
> 
> On 02/10/15 15:09, David Vrabel wrote:
>> On 30/09/15 11:45, Julien Grall wrote:
>>> For ARM64 guests, Linux is able to support either 64K or 4K page
>>> granularity. Although, the hypercall interface is always based on 4K
>>> page granularity.
>>>
>>> With 64K page granularity, a single page will be spread over multiple
>>> Xen frame.
>>>
>>> To avoid splitting the page into 4K frame, take advantage of the
>>> extent_order field to directly allocate/free chunk of the Linux page
>>> size.
>>>
>>> Note that PVMMU is only used for PV guest (which is x86) and the page
>>> granularity is always 4KB. Some BUILD_BUG_ON has been added to ensure
>>> that because the code has not been modified.
>>
>> This causes a BUG() in x86 PV guests when decreasing the reservation.
>>
>> Xen says:
>>
>> (XEN) d0v2 Error pfn 0: rd=0 od=32753 caf=8001
>> taf=7401
>> (XEN) memory.c:250:d0v2 Bad page free for domain 0
>>
>> And Linux BUGs with:
>>
>> [   82.032654] kernel BUG at
>> /anfs/drall/scratch/davidvr/x86/linux/drivers/xen/balloon.c:540!
>>
>> Which is a non-zero return value from the decrease_reservation hypercall.
>>
>> The frame_list[] has been incorrectly populated.  The below patch fixes
>> it for me.  Please test as well.

FIY, I've just tested with the patch on ARM64 and I haven't see any issue.

> Sorry for the breakage, I think I haven't spot the bug on my board
> because most the PV drivers are allocating one balloon page at the time
> by default.
> 
> This patch looks valid to me. i was resetting and incremented for each
> loop on an early version. Although I dropped it by mistake when I use a
> different way to decrease the reservation.




-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v1] xSplice initial foundation patches.

[Konrad Rzeszutek Wilk]

On Wed, Sep 16, 2015 at 05:01:11PM -0400, Konrad Rzeszutek Wilk wrote:
> 
> *OK, what do you have?*
> 
> They are located at a git tree:
>   git://xenbits.xen.org/people/konradwilk/xen.git xsplice.v1

I've created another branch 'xsplice.v1.1' which has some bug-fixes
and improvements. Will be posting it soonish when I am done
with testing.

But more importantly I would like to setup an IRC meeting
so that we may coordinate.

I've used doodle, and the link is:

 http://doodle.com/poll/adtuwr4hs5m4i9y6

The times I've put in there are geared towards earlier hours
but please feel free to propose other times.


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

Re: [Xen-devel] [PATCH v2 1/5] libxc: remove allocate member from struct xc_dom_image

[Ian Campbell]

On Fri, 2015-10-02 at 16:25 +0200, Juergen Gross wrote:
> On 10/02/2015 03:01 PM, Ian Campbell wrote:
> > On Fri, 2015-10-02 at 07:49 +0200, Juergen Gross wrote:
> > > The allocate() callback in struct xc_dom_image is never set. Remove
> > > it.
> > > 
> > > Signed-off-by: Juergen Gross 
> > > Acked-by: Ian Jackson 
> > 
> > This breaks the stubdom build:
> > 
> > kexec.c: In function ‘kexec’:
> > kexec.c:221:78: warning: taking address of expression of type ‘void’
> >   xen_pfn_t boot_page_mfn = virt_to_mfn(&_boot_page);
> >
> > ^
> > kexec.c:230:8: error: ‘struct xc_dom_image’ has no member named
> > ‘allocate’
> >   dom->allocate = kexec_allocate;
> >  ^
> > kexec.c:318:60: warning: taking address of expression of type ‘void’
> >   virt_to_mfn(&_boot_page));
> >  ^
> > Makefile:79: recipe for target '/local/scratch/ianc/devel/committer
> > -amd64.git/stubdom/grub-x86_64/kexec.o' failed
> > 
> > On i386 too.
> > 
> > And in fact that hook looks useful in that context, so either it needs
> > to
> > stay of stubdom kexec needs changing to work some other way.
> 
> Too bad.
> 
> I wanted to remove the allocate callback as it will conflict with the
> allocations of memory outside the initial default mapping.
> 
> Just to make sure I understand this correctly:
> 
> stubdom is used in this context to support grub running as a pv domain
> capable to start another pv domain.

Correct.

> So as long as stubdom doesn't support mapping the p2m list outside the
> default mapping it makes no sense to support this feature for any domain
> started via stubdom/grub (the main reason to use this feature is the
> support of huge memory causing the p2m list to exceed the available
> virtual address space of the default mapping).

By "default mapping" you mean the mapping established by the domain builder
which made the domain, as distinct from any mapping which the guest kernel
might establish by itself later, right?

I'm not sure that there is any link between the stubdomain's own p2m and
the default mapping of that and the p2m which it is building for use of the
domain it is going to kexec and the default mappings of that p2m-to-be from
the PoV of the to-be-kexec'd guest kernel.

I'm not sure how kexec operates in this regard.

> So the easy solution would be to not support initrd and p2m outside the
> default mapping when the allocate callback is set. Do you think this
> solution is okay?

Irrespective of the above just not supporting this mode would be one way to
avoid the issue. It would make domains using pvgrub1 have different
limitations than domains built directly. IOW users will have to trade off
the security benefits of pvgrub vs the size of the domain they wish to
build, which is a shame.

On the other hand pvgrub2 now exists as a separate (out of tree, it's in
grub.git) thing anyway which doesn't use this domain builder at all AFAIK
and that's the one I expect people are using going forward anyway.

Ian.

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

Re: [Xen-devel] [PATCH v2 3/5] libxc: create unmapped initrd in domain builder if supported

[Juergen Gross]

On 10/02/2015 02:59 PM, Ian Campbell wrote:

On Fri, 2015-10-02 at 07:49 +0200, Juergen Gross wrote:

In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the initrd,
but allocate only guest physical memory for it.

Signed-off-by: Juergen Gross 
---
  tools/libxc/xc_dom_core.c | 22 --
  1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index b510bbd..85b531a 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1019,8 +1019,9 @@ int xc_dom_build_image(struct xc_dom_image *dom)
  if ( dom->kernel_loader->loader(dom) != 0 )
  goto err;

-/* load ramdisk */
-if ( dom->ramdisk_blob )
+/* Load ramdisk if initial mapping required. */
+if ( dom->ramdisk_blob &&
+ (!dom->parms.mod_start_pfn || dom->ramdisk_seg.vstart) )
  {
  if ( xc_dom_build_ramdisk(dom) != 0 )
  goto err;
@@ -1063,6 +1064,23 @@ int xc_dom_build_image(struct xc_dom_image *dom)
__FUNCTION__, dom->virt_alloc_end);
  DOMPRINTF("%-20s: virt_pgtab_end : 0x%" PRIx64 "",
__FUNCTION__, dom->virt_pgtab_end);
+
+/* Prepare allocating unmapped memory. */
+if ( dom->virt_pgtab_end )
+dom->virt_alloc_end = dom->virt_pgtab_end;
+
+/* Load ramdisk if no initial mapping required. */
+if ( dom->ramdisk_blob && !dom->ramdisk_seg.vstart &&
+ dom->parms.mod_start_pfn )
+{
+if ( xc_dom_build_ramdisk(dom) != 0 )
+goto err;
+dom->flags |= SIF_MOD_START_PFN;
+dom->ramdisk_seg.vend = dom->ramdisk_seg.vend - 
dom->ramdisk_seg.vstart;
+dom->ramdisk_seg.vstart = dom->ramdisk_seg.pfn;
+dom->ramdisk_seg.vend += dom->ramdisk_seg.vstart;


This seems like it is trying to do something clever, like partially
reversing something which the xc_dom_alloc_segment call in
  xc_dom_build_ramdisk has done.


It's just changing the boundaries of the initrd to fit the interface
for it being not mapped (indicated by the SIF_MOD_START_PFN flag).


It looks like the vend handling in particular is just a complicated way of
subtracting vstart and adding pfn, with the aim of rebasing from virt to
phys world.


Hmm, not more complicated as:

len = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
dom->ramdisk_seg.vstart = dom->ramdisk_seg.pfn;
dom->ramdisk_seg.vend = dom->ramdisk_seg.pfn + len;

I have to admit that above variant might be easier to understand. :-)


Plus vstart/end are addresses, while presumably pfn is a page number, so
I'm confused about that as well.


The naming is irritating, yes. I think I'll change this when I'm
modifying the allocation interface (see my answer to patch 5).


I'm also not clear how/where the virtual mapping is avoided, given that
this code here does strictly more than the original code above which is now
made conditional does.


The page tables are built before. So they don't cover the initrd memory.


Juergen


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

Re: [Xen-devel] [PATCH v2 5/5] libxc: create p2m list outside of kernel mapping if supported

[Juergen Gross]

On 10/02/2015 03:16 PM, Ian Campbell wrote:

On Fri, 2015-10-02 at 07:49 +0200, Juergen Gross wrote:


+/* Allocate p2m list if outside of initial kernel mapping. */
+if ( dom->arch_hooks->alloc_p2m_list && dom->parms.p2m_base != UNSET_ADDR )
+{
+if ( dom->arch_hooks->alloc_p2m_list(dom) != 0 )
+goto err;
+dom->p2m_seg.vend = dom->p2m_seg.vend - dom->p2m_seg.vstart;
+dom->p2m_seg.vstart = dom->parms.p2m_base;
+dom->p2m_seg.vend += dom->p2m_seg.vstart;


Here is this strange pattern again.

It seems like you should be adding new APIs to the dom builder's VA/PA
allocation stuff and using those instead of working around the behaviour of
the existing ones.


Okay. I'll split allocation into two layers (virtual and physical)
and make the virtual one accessible for other functions. I'll need
to keep track of physical and virtual allocation boundaries, of
course.




+}
+/*
+ * Build the page tables for mapping the p2m list at an address
+ * specified by the to be loaded kernel.
+ * l1pfn holds the pfn of the next page table to allocate.
+ * At each level we might already have an entry filled when setting
+ * up the initial kernel mapping. This can happen for the last entry
+ * of each level only!
+ */
+l3tab = NULL;
+l2tab = NULL;
+l1tab = NULL;
+l1pfn = round_pfn(dom->p2m_size * dom->arch_hooks->sizeof_pfn) +
+dom->p2m_seg.pfn;
+
+for ( addr = dom->parms.p2m_base;
+  addr < dom->parms.p2m_base +
+ dom->p2m_size * dom->arch_hooks->sizeof_pfn;
+  addr += PAGE_SIZE_X86 )


This is replicating a bunch of existing setup_pgtable_* code.

Please refactor into a helper (one per PT layout) to map a region and use
that for the existing and new use cases.


Hmm, I thought about this, too. The problem is there are subtle
differences between both variants. I can give it a try and see how
the code looks like.




+{
+if ( l3tab == NULL )
+{
+l4off = l4_table_offset_x86_64(addr);
+l3pfn = l4tab[l4off] ? l4pfn + dom->pg_l4 : l1pfn++;
+l3tab = xc_dom_pfn_to_ptr(dom, l3pfn, 1);
+if ( l3tab == NULL )
+goto pfn_error;
+l4tab[l4off] =
+pfn_to_paddr(xc_dom_p2m_guest(dom, l3pfn)) | L4_PROT;
+}
+
+if ( l2tab == NULL )
+{
+l3off = l3_table_offset_x86_64(addr);
+l2pfn = l3tab[l3off] ? l3pfn + dom->pg_l3 : l1pfn++;
+l2tab = xc_dom_pfn_to_ptr(dom, l2pfn, 1);
+if ( l2tab == NULL )
+goto pfn_error;
+l3tab[l3off] =
+pfn_to_paddr(xc_dom_p2m_guest(dom, l2pfn)) | L3_PROT;
+}
+
+if ( l1tab == NULL )
+{
+l2off = l2_table_offset_x86_64(addr);
+l1pfn = l2tab[l2off] ? l2pfn + dom->pg_l2 : l1pfn;
+l1tab = xc_dom_pfn_to_ptr(dom, l1pfn, 1);
+if ( l1tab == NULL )
+goto pfn_error;
+l2tab[l2off] =
+pfn_to_paddr(xc_dom_p2m_guest(dom, l1pfn)) | L2_PROT;
+l1pfn++;
+}
+
+l1off = l1_table_offset_x86_64(addr);
+pgpfn = ((addr - dom->parms.p2m_base) >> PAGE_SHIFT_X86) +
+dom->p2m_seg.pfn;
+l1tab[l1off] =
+pfn_to_paddr(xc_dom_p2m_guest(dom, pgpfn)) | L1_PROT;
+
+if ( l1off == (L1_PAGETABLE_ENTRIES_X86_64 - 1) )
+{
+l1tab = NULL;
+if ( l2off == (L2_PAGETABLE_ENTRIES_X86_64 - 1) )
+{
+l2tab = NULL;
+if ( l3off == (L3_PAGETABLE_ENTRIES_X86_64 - 1) )
+l3tab = NULL;
+}
+}
+}
+
  return 0;

  pfn_error:
@@ -442,6 +519,27 @@ pfn_error:
  static int alloc_p2m_list(struct xc_dom_image *dom)
  {
  size_t p2m_alloc_size = dom->p2m_size * dom->arch_hooks->sizeof_pfn;
+xen_vaddr_t from, to;
+xen_pfn_t tables;
+
+p2m_alloc_size = round_pg(p2m_alloc_size);
+if ( dom->parms.p2m_base != UNSET_ADDR )
+{
+/* Add space for page tables, 64 bit only. */


Please make an alloc_p2m_list_x86_64 which does this and then calls the
common code and then use the appropriate hook for each sub arch.


Okay.


+from = dom->parms.p2m_base;
+to = from + p2m_alloc_size - 1;
+tables = 0;
+tables += nr_page_tables(dom, from, to,
L4_PAGETABLE_SHIFT_X86_64);
+if ( to > (xen_vaddr_t)(~0ULL << L4_PAGETABLE_SHIFT_X86_64) )
+tables--;
+tables += nr_page_tables(dom, from, to,
L3_PAGETABLE_SHIFT_X86_64);
+if ( to > (xen_vaddr_t)(~0ULL << L3_PAGETABLE_SHIFT_X86_64) )
+tables--;
+tables += nr_page_tables(dom, from, to,
L2_PAGETABLE_SHIFT_X86_64);
+if ( to > (xen_vaddr_t)(~0ULL << L2_PAGETABLE_SHIFT_X86_64) )
+tables--;
+p2m_alloc_size += tables << PAGE_SHIFT_X86;
+}

  

Re: [Xen-devel] [PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux

[Konrad Rzeszutek Wilk]

On Fri, Oct 02, 2015 at 09:25:15AM -0400, Boris Ostrovsky wrote:
> 
> 
> On 10/02/2015 05:51 AM, Ian Campbell wrote:
> >(trimming and reordering To/Cc)
> >
> >On Thu, 2015-10-01 at 16:15 +0100, David Vrabel wrote:
> >>On 30/09/15 11:45, Julien Grall wrote:
> >>>Hi all,
> >>>
> >>>ARM64 Linux is supporting both 4KB and 64KB page granularity. Although,
> >>>Xen
> >>>hypercall interface and PV protocol are always based on 4KB page
> >>>granularity.
> >>>
> >>>Any attempt to boot a Linux guest with 64KB pages enabled will result
> >>>to a
> >>>guest crash.
> >>>
> >>>This series is a first attempt to allow those Linux running with the
> >>>current
> >>>hypercall interface and PV protocol.
> >>>
> >>>This solution has been chosen because we want to run Linux 64KB in
> >>>released
> >>>Xen ARM version or/and platform using an old version of Linux DOM0.
> >>Applied to for-linus-4.4, thanks.
> >>
> >>Boris, can you kick off a set of tests for this branch, please?
> >@Boris,
> >
> >Would it be possible to have the results of this test framework posted to
> >the list, like osstest does?
> 
> Not in the way it is currently set up --- we have 7 or 8 test systems and
> each one generates an email with results. It may not be too bad if all tests
> pass but if they fail each email may have as much as 2-3 MB of logs (we
> don't upload them anywhere).
> 
> I could generate a summary of a nightly run but then we have some
> intermittent failures mostly on some older distros (like Fedora 15) that we
> are unlikely to ever look into so that may make things confusing (Yes, the
> question is then -- why do we even bother running it).

Lets kill it. I thought it was Fedora 16 though?

> 
> 
> >
> >@Linux-Maintainers,
> >
> >It occurs to me that osstest doesn't have a branch which is testing your
> >kernel tree. Do you have a fast-forwarding branch in git
> >://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git which merges up some
> >forward looking set of changes? If so I can pretty trivially arrange an
> >osstest branch to track it.
> >
> >(If there isn't a f-forwarding one maybe it would still be worth testing
> >something, it just probably wouldn't get bisected in any useful way if it
> >broke).
> 
> Yes, perhaps have a devel/oss branch that tracks the latest
> devel/for-linus-? David?
> 
> -boris
> 
> 

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

Re: [Xen-devel] [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity is the same for Xen and Linux

[Julien Grall]

Hi David,

On 02/10/15 15:09, David Vrabel wrote:
> On 30/09/15 11:45, Julien Grall wrote:
>> For ARM64 guests, Linux is able to support either 64K or 4K page
>> granularity. Although, the hypercall interface is always based on 4K
>> page granularity.
>>
>> With 64K page granularity, a single page will be spread over multiple
>> Xen frame.
>>
>> To avoid splitting the page into 4K frame, take advantage of the
>> extent_order field to directly allocate/free chunk of the Linux page
>> size.
>>
>> Note that PVMMU is only used for PV guest (which is x86) and the page
>> granularity is always 4KB. Some BUILD_BUG_ON has been added to ensure
>> that because the code has not been modified.
> 
> This causes a BUG() in x86 PV guests when decreasing the reservation.
> 
> Xen says:
> 
> (XEN) d0v2 Error pfn 0: rd=0 od=32753 caf=8001
> taf=7401
> (XEN) memory.c:250:d0v2 Bad page free for domain 0
> 
> And Linux BUGs with:
> 
> [   82.032654] kernel BUG at
> /anfs/drall/scratch/davidvr/x86/linux/drivers/xen/balloon.c:540!
> 
> Which is a non-zero return value from the decrease_reservation hypercall.
> 
> The frame_list[] has been incorrectly populated.  The below patch fixes
> it for me.  Please test as well.

Sorry for the breakage, I think I haven't spot the bug on my board
because most the PV drivers are allocating one balloon page at the time
by default.

This patch looks valid to me. i was resetting and incremented for each
loop on an early version. Although I dropped it by mistake when I use a
different way to decrease the reservation.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/5] libxc: remove allocate member from struct xc_dom_image

[Juergen Gross]

On 10/02/2015 03:01 PM, Ian Campbell wrote:

On Fri, 2015-10-02 at 07:49 +0200, Juergen Gross wrote:

The allocate() callback in struct xc_dom_image is never set. Remove it.

Signed-off-by: Juergen Gross 
Acked-by: Ian Jackson 


This breaks the stubdom build:

kexec.c: In function ‘kexec’:
kexec.c:221:78: warning: taking address of expression of type ‘void’
  xen_pfn_t boot_page_mfn = virt_to_mfn(&_boot_page);
   ^
kexec.c:230:8: error: ‘struct xc_dom_image’ has no member named ‘allocate’
  dom->allocate = kexec_allocate;
 ^
kexec.c:318:60: warning: taking address of expression of type ‘void’
  virt_to_mfn(&_boot_page));
 ^
Makefile:79: recipe for target 
'/local/scratch/ianc/devel/committer-amd64.git/stubdom/grub-x86_64/kexec.o' 
failed

On i386 too.

And in fact that hook looks useful in that context, so either it needs to
stay of stubdom kexec needs changing to work some other way.


Too bad.

I wanted to remove the allocate callback as it will conflict with the
allocations of memory outside the initial default mapping.

Just to make sure I understand this correctly:

stubdom is used in this context to support grub running as a pv domain
capable to start another pv domain.

So as long as stubdom doesn't support mapping the p2m list outside the
default mapping it makes no sense to support this feature for any domain
started via stubdom/grub (the main reason to use this feature is the
support of huge memory causing the p2m list to exceed the available
virtual address space of the default mapping).

So the easy solution would be to not support initrd and p2m outside the
default mapping when the allocate callback is set. Do you think this
solution is okay?


Juergen

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

[Xen-devel] [PATCH v3 0/1] Block script performance with shared image files

[Mike Latimer]

Hi,

V3 of this patch modifies the comments on check_sharing to document the
change in the return string. This change was necessary to allow the error
string in check_file_sharing to return the device causing the sharing
conflict.

Thanks,
Mike

Mike Latimer (1):
  tools/hotplug: Scan xenstore once when attaching shared images files

 tools/hotplug/Linux/block | 89 ++-
 1 file changed, 57 insertions(+), 32 deletions(-)

-- 
1.8.4.5


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

[Xen-devel] [PATCH v3 1/1] tools/hotplug: Scan xenstore once when attaching shared images files

[Mike Latimer]

During the attachment of a loopback mounted image file, the mode of all
curent instances of this device already attached to other domains must be
checked. This requires finding all loopback devices pointing to the inode
of the shared image file, and then comparing the major and minor number of
these devices to the major and minor number of every vbd device found in the
xenstore database.

Prior to this patch, the entire xenstore database is walked for every instance
of every loopback device pointing to the same shared image file. This process
causes the block attachment process to becomes exponentially slower with every
additional attachment of a shared image.

Rather than scanning all of xenstore for every instance of a shared loopback
device, this patch creates a list of the major and minor numbers from all
matching loopback devices. After generating this list, Xenstore is walked
once, and major and minor numbers from every vbd are checked against the list.
If a match is found, the mode of that vbd is checked for compatibility with
the mode of the device being attached.

Signed-off-by: Mike Latimer 
---
 tools/hotplug/Linux/block | 89 ++-
 1 file changed, 57 insertions(+), 32 deletions(-)

diff --git a/tools/hotplug/Linux/block b/tools/hotplug/Linux/block
index 8d2ee9d..2691b56 100644
--- a/tools/hotplug/Linux/block
+++ b/tools/hotplug/Linux/block
@@ -38,7 +38,7 @@ find_free_loopback_dev() {
 }
 
 ##
-# check_sharing device mode
+# check_sharing devtype device mode [inode]
 #
 # Check whether the device requested is already in use.  To use the device in
 # read-only mode, it may be in use in read-only mode, but may not be in use in
@@ -47,19 +47,44 @@ find_free_loopback_dev() {
 #
 # Prints one of
 #
-#'local': the device may not be used because it is mounted in the current
-# (i.e. the privileged domain) in a way incompatible with the
-# requested mode;
-#'guest': the device may not be used because it already mounted by a guest
-# in a way incompatible with the requested mode; or
-#'ok':the device may be used.
+#'local $d': the device ($d) may not be used because it is mounted in the
+#current (i.e. the privileged domain) in a way incompatible
+#with the requested mode;
+#'guest $d': the device may not be used because it is already mounted
+#through device $d by a guest in a way incompatible with the
+#requested mode; or
+#'ok':   the device may be used.
 #
 check_sharing()
 {
-  local dev="$1"
-  local mode="$2"
+  local devtype=$1
+  local dev="$2"
+  local mode="$3"
+  local devmm=","
+
+  if [ "$devtype" = "file" ];
+  then
+local inode="$4"
+
+shared_list=$(losetup -a |
+  sed -n -e 
"s@^\([^:]\+\)\(:[[:blank:]]\[0*${dev}\]:${inode}[[:blank:]](.*)\)@\1@p" )
+for dev in $shared_list
+do
+  if [ -n "$dev" ]
+  then
+devmm="${devmm}$(device_major_minor $dev),"
+  fi
+done
+# if $devmm is unchanged, file being checked is not a shared loopback 
device
+if [ "$devmm" = "," ];
+then
+  echo 'ok'
+  return
+fi
+  else
+devmm=${devmm}$(device_major_minor "$dev")","
+  fi
 
-  local devmm=$(device_major_minor "$dev")
   local file
 
   if [ "$mode" = 'w' ]
@@ -75,9 +100,10 @@ check_sharing()
 then
   local d=$(device_major_minor "$file")
 
-  if [ "$d" = "$devmm" ]
+  # checking for $d in $devmm is best through the [[...]] bashism
+  if [[ "$devmm" == *",$d,"* ]]
   then
-echo 'local'
+echo "local $d"
 return
   fi
 fi
@@ -90,13 +116,14 @@ check_sharing()
 do
   d=$(xenstore_read_default "$base_path/$dom/$dev/physical-device" "")
 
-  if [ "$d" = "$devmm" ]
+  # checking for $d in $devmm is best through the [[...]] bashism
+  if [ -n "$d" ] && [[ "$devmm" == *",$d,"* ]]
   then
 if [ "$mode" = 'w' ]
 then
   if ! same_vm $dom
   then
-echo 'guest'
+echo "guest $d"
 return
   fi
 else
@@ -107,7 +134,7 @@ check_sharing()
   then
 if ! same_vm $dom
 then
-  echo 'guest'
+  echo "guest $d"
   return
 fi
   fi
@@ -129,6 +156,7 @@ check_device_sharing()
 {
   local dev="$1"
   local mode=$(canonicalise_mode "$2")
+  local type="device"
   local result
 
   if [ "x$mode" = 'x!' ]
@@ -136,33 +164,38 @@ check_device_sharing()
 return 0
   fi
 
-  result=$(check_sharing "$dev" "$mode")
+  result=$(check_sharing "$type" "$dev" "$mode")
 
   if [ "$result" != 'ok' ]
   then
-do_ebusy "Device $dev is mounted " "$mode" "$result"
+do_ebusy "Device $dev is mounted " "$mode" "${result%% *}"
   fi
 }
 
 
 ##
-# check_device_sharing file dev mode
+# check_device_sharing file dev mode inode
 #
-# Perform the sharing check

Re: [Xen-devel] [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity is the same for Xen and Linux

[David Vrabel]

On 30/09/15 11:45, Julien Grall wrote:
> For ARM64 guests, Linux is able to support either 64K or 4K page
> granularity. Although, the hypercall interface is always based on 4K
> page granularity.
> 
> With 64K page granularity, a single page will be spread over multiple
> Xen frame.
> 
> To avoid splitting the page into 4K frame, take advantage of the
> extent_order field to directly allocate/free chunk of the Linux page
> size.
> 
> Note that PVMMU is only used for PV guest (which is x86) and the page
> granularity is always 4KB. Some BUILD_BUG_ON has been added to ensure
> that because the code has not been modified.

This causes a BUG() in x86 PV guests when decreasing the reservation.

Xen says:

(XEN) d0v2 Error pfn 0: rd=0 od=32753 caf=8001
taf=7401
(XEN) memory.c:250:d0v2 Bad page free for domain 0

And Linux BUGs with:

[   82.032654] kernel BUG at
/anfs/drall/scratch/davidvr/x86/linux/drivers/xen/balloon.c:540!

Which is a non-zero return value from the decrease_reservation hypercall.

The frame_list[] has been incorrectly populated.  The below patch fixes
it for me.  Please test as well.

--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -504,9 +504,10 @@ static enum bp_state decrease_reservation(unsigned
long nr_pages, gfp_t gfp)
 * Setup the frame, update direct mapping, invalidate P2M,
 * and add to balloon.
 */
+   i = 0;
list_for_each_entry_safe(page, tmp, &pages, lru) {
/* XENMEM_decrease_reservation requires a GFN */
-   frame_list[i] = xen_page_to_gfn(page);
+   frame_list[i++] = xen_page_to_gfn(page);

 #ifdef CONFIG_XEN_HAVE_PVMMU
/*

David

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

[Xen-devel] [distros-debian-jessie test] 38116: regressions - FAIL

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-amd64-jessie-netboot-pygrub 9 debian-di-install fail REGR. vs. 
38030

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail 
never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail 
never pass

baseline version:
 flight   38030

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  fail
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



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

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

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


Push not applicable.


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

[Xen-devel] ANNOUNCEMENT: Xen 4.6 RC5

[Wei Liu]

Hi all

Xen 4.6 RC5 has been tagged. You can check out the tag 4.6.0-rc5 in xen.git.

The tarball can be downloaded from:

http://bits.xensource.com/oss-xen/release/4.6.0-rc5/xen-4.6.0-rc5.tar.gz

Signature for tarball:

http://bits.xensource.com/oss-xen/release/4.6.0-rc5/xen-4.6.0-rc5.tar.gz.sig

When reporting bugs, please send your bug report to
xen-de...@lists.xenproject.org, present as much information as possible, tag it
with "BUG-4.6" and CC release manager (wei.l...@citrix.com) and relevant
maintainers.

Note that this RC is tagged on staging-4.6 branch for the benefit of
earlier testing. We're positive that OSSTest (our CI infrastructure) is
going to get a push to stable-4.6 at some point, because OSSTest
couldn't really test the last few patches added.

We don't arrange test day for this RC, feel free to report issues
anytime.

Test instructions on:

http://wiki.xenproject.org/wiki/Xen_4.6_RC5_test_instructions

Wei.

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

Re: [Xen-devel] [PATCH OSSTEST] Switch to merged qemu-xen{, -traditional}.git trees

[Ian Campbell]

On Fri, 2015-10-02 at 14:43 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST] Switch to merged qemu-xen{,
> -traditional}.git trees"):
> > $branch is a bit wordy at this point, but $branchcore is usable for
> > both
> > cases incrementally:
> 
> LGTM.
> 
> Acked-by: Ian Jackson 
> 
> (I assume you'll fold this in.)

Yes, v2 is below for completeness. I rebased this over the smoketest stuff
which added $xenbranch_forqemu which of course is now no longer needed so
the rebase just involved taking my version of each conflict and removing
the initialisation of xenbranch_forqemu. Accordingly I've retained your
Ack, I hope that is ok.

We discussed on IRC with you and Stefano and are going to aim to push this
in the w/c 19 October.

Cheers,
Ian.

---8<---

>From faa826a104a1e6c7e357870a843777887b55a3ef Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Thu, 30 Jul 2015 13:42:03 +0100
Subject: [PATCH v2] Switch to merged qemu-xen{,-traditional}.git trees

The qemu-mainline flights now push to the upstream-tested branch of
qemu-xen.git (while still pulling from upstream).

The qemu-upstream-unstable flights pull from staging and push to
master in qemu-xen.git

All of the qemu-upstream-X.Y-testing pull from staging-X.Y and push to
stable-X.Y branch in qemu-xen.git.

For now we also continue pushing to the old trees for qemu-upstream
4.2 through to 4.6-testing. Once those branches have updated their
Config.mk and done a point release we can consider removing these.

Abolish $LOCALREV_QEMU_MAINLINE in favour of $LOCALREV_QEMU_UPSTREAM,
it was used inconsistently.

While changing things ensure all pushes are done to refs/heads/$thing
to avoid issues when output branches to not exist.

Note that xenbranch_forqemu is no longer needed.

Signed-off-by: Ian Campbell 
Acked-by: Ian Jackson 
---
v2: Use branchcore for old tree pushes.
---
 ap-common| 12 +++-
 ap-fetch-version | 10 --
 ap-fetch-version-old | 14 +-
 ap-push  | 23 +++
 4 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/ap-common b/ap-common
index 91425a9..2cba7f8 100644
--- a/ap-common
+++ b/ap-common
@@ -19,8 +19,6 @@
 
 # $xenbranch must already be set
 
-xenbranch_forqemu=${xenbranch/xen-unstable-smoke/xen-unstable}
-
 : ${XENBITS:=osst...@xenbits.xen.org}
 
 : ${TREEBRANCH_OSSTEST_UPSTREAM=`getconfig OsstestUpstream`}
@@ -28,9 +26,7 @@ xenbranch_forqemu=${xenbranch/xen-unstable-smoke/xen-unstable}
 : ${TREE_XEN:=git://xenbits.xen.org/xen.git}
 : ${PUSH_TREE_XEN:=$XENBITS:/home/xen/git/xen.git}
 
-#: ${TREE_QEMU:=git://mariner.uk.xensource.com/qemu-$xenbranch_forqemu.git}
-: ${TREE_QEMU:=git://xenbits.xen.org/staging/qemu-$xenbranch_forqemu.git}
-
+: ${TREE_QEMU:=git://xenbits.xen.org/qemu-xen-traditional.git}
 
 : ${GIT_KERNEL_ORG:=git://git.kernel.org}
 : ${KERNEL_SCM:=${GIT_KERNEL_ORG}/pub/scm/linux/kernel/git}
@@ -89,13 +85,11 @@ fi
 
 : ${TREEBASE_LINUX_XCP:=http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27}
 
-: 
${TREE_QEMU_UPSTREAM:=git://xenbits.xen.org/staging/qemu-upstream-${xenbranch_forqemu#xen-}.git}
+: ${TREE_QEMU_UPSTREAM:=git://xenbits.xen.org/qemu-xen.git}
+: ${PUSH_TREE_QEMU_UPSTREAM=$XENBITS:/home/xen/git/qemu-xen.git
 : ${LOCALREV_QEMU_UPSTREAM:=daily-cron.$branch}
 
 : ${TREE_QEMU_MAINLINE:=git://git.qemu.org/qemu.git}
-: ${BASE_TREE_QEMU_MAINLINE:=git://xenbits.xen.org/osstest/qemu.git}
-: ${PUSH_TREE_QEMU_MAINLINE:=$XENBITS:/home/xen/git/osstest/qemu.git}
-: ${LOCALREV_QEMU_MAINLINE:=daily-cron.$branch}
 
 info_linux_tree () {
case $1 in
diff --git a/ap-fetch-version b/ap-fetch-version
index 6fa7588..973c30e 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -55,9 +55,15 @@ qemu-mainline)
repo_tree_rev_fetch_git $branch \
$TREE_QEMU_MAINLINE master $LOCALREV_QEMU_UPSTREAM
;;
-qemu-upstream-*)
+qemu-upstream-unstable)
 repo_tree_rev_fetch_git $branch \
-   $TREE_QEMU_UPSTREAM master $LOCALREV_QEMU_UPSTREAM
+   $TREE_QEMU_UPSTREAM staging $LOCALREV_QEMU_UPSTREAM
+;;
+qemu-upstream-*-testing)
+   branchcore=${branch#qemu-upstream-}
+   branchcore=${branchcore%-testing}
+repo_tree_rev_fetch_git $branch \
+   $TREE_QEMU_UPSTREAM staging-$branchcore $LOCALREV_QEMU_UPSTREAM
 ;;
 linux)
repo_tree_rev_fetch_git linux \
diff --git a/ap-fetch-version-old b/ap-fetch-version-old
index 66d51f8..511c1fc 100755
--- a/ap-fetch-version-old
+++ b/ap-fetch-version-old
@@ -32,8 +32,6 @@ select_xenbranch
 : ${BASE_LOCALREV_SEABIOS:=daily-cron.$branch.old}
 : ${BASE_LOCALREV_OVMF:=daily-cron.$branch.old}
 
-: ${BASE_TREE_QEMU_UPSTREAM:=${TREE_QEMU_UPSTREAM/\/staging\//\/}}
-
 if info_linux_tree "$branch"; then
repo_tree_rev_fetch_git linux \
$BASE_TREE_LINUX_THIS $BASE_TAG_LINUX_THIS $BASE_LOCALREV_LINUX
@@ -61,11 +59,17 @@ xen-4.*-testing)
;;
 qemu-mainline)
 repo_tree

Re: [Xen-devel] [PATCH OSSTEST] Switch to merged qemu-xen{, -traditional}.git trees

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH OSSTEST] Switch to merged 
qemu-xen{,-traditional}.git trees"):
> $branch is a bit wordy at this point, but $branchcore is usable for both
> cases incrementally:

LGTM.

Acked-by: Ian Jackson 

(I assume you'll fold this in.)

Ian.

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

[Xen-devel] [qemu-upstream-4.6-testing baseline-only test] 38115: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38115 qemu-upstream-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38115/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail never pass


jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-

Re: [Xen-devel] [PATCH v1 1/5] xsplice: Design document.

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  09/16/15 11:02 PM >>>
>+struct xsplice {
>+const char *name; /* A sensible name for the patch. Up to 40 characters. 
>*/  

Any reason not to make this a 40-character array right in the structure then?
It would seem to me the fewer relocation the better.

>+const char *build_id; /* ID of the hypervisor this binary was built 
>against. */  

For this one this might be true to, if the linker can be made emit the build ID 
at
place we want it (which seems unlikely).

>+uint32_t version; /* Version of payload. */  
>+uint32_t id_size; /* Size of the ID. */  

Which "the ID"?

>+struct xsplice_code *new; /* Pointer to the new code & data to be 
>patched. */  
>+struct xsplice_code *old; /* Pointer to the old code & data to be checked 
>against. */  

Considering you use "const" above, any reason not to here (and elsewhere below)?

>+struct xsplice_code {  
>+struct xsplice_reloc *relocs; /* How to patch it. */  
>+struct xsplice_section *sections; /* Safety data. */  
>+struct xsplice_patch *patches; /* Patch code and data */  
>+uint32_t n_relocs;  
>+uint32_t n_sections;  
>+uint32_t n_patches;  
>+uint8_t pad[28]; /* Must be zero. */  
>+};
>+
>+
>+The size of this structure is 64 bytes.
>+
>+There can be at most two of those structures in the payload.
>+One for the `new` and another for the `old` (optional).
>+
>+If it is for the old code the relocs, and relocs_end values will be ignored.

s/relocs_end/n_relocs/

>+### xsplice_reloc
>+
>+The `xsplice_code` defines an array of these structures. As such
>+an singular structure defines an singular point where to patch the
>+hypervisor.
>+
>+The structure contains the address of the hypervisor (if known),
>+the symbol associated with this address, how the patching is to
>+be done, and platform specific details.
>+
>+The `isns_added` is an value to be used to compute the new offset

I think you mean addend here. And what is isns supposed to stand for?

>+#define XSPLICE_SECTION_TEXT   0x0001 /* Section is in .text */  
>+#define XSPLICE_SECTION_RODATA 0x0002 /* Section is in .rodata */  
>+#define XSPLICE_SECTION_DATA   0x0004 /* Section is in .data */  
>+#define XSPLICE_SECTION_STRING 0x0008 /* Section is in .str */  

As said before - this enumeration of sections seems too limiting to me. Plus -
who is ".str"?

>+#define XSPLICE_PATCH_INLINE_TEXT   0x1
>+#define XSPLICE_PATCH_INLINE_DATA   0x2

Why do code and data need separate flags here?

>+
>+struct xsplice_symbol {  
>+const char *name; /* The ELF name of the symbol. */  
>+const char *label; /* A unique xSplice name for the symbol. */  
>+uint8_t pad[16]; /* Must be zero. */  
>+};  
>+
>+
>+The size of this structure is 32 bytes.

I only notice this now - do these statements make sense, given that
they assume a 64-bit architecture?

>+### xsplice_reloc_howto
>+
>+The howto defines in the detail the change. It contains the type,
>+whether the relocation is relative, the size of the relocation,
>+bitmask for which parts of the instruction or data are to be replaced,
>+amount the final relocation is shifted by (to drop unwanted data), and
>+whether the replacement should be interpreted as signed value.
>+
>+The structure is as follow:
>+
>+
>+#define XSPLICE_HOWTO_INLINE0x1 /* It is an inline replacement. */  
>+#define XSPLICE_HOWTO_RELOC_PATCH   0x2 /* Add a trampoline. */  
>+
>+#define XSPLICE_HOWTO_FLAG_PC_REL0x1 /* Is PC relative. */  
>+#define XSPLICE_HOWOT_FLAG_SIGN  0x2 /* Should the new value be treated 
>as signed value. */  
>+
>+struct xsplice_reloc_howto {  
>+uint32_thowto; /* XSPLICE_HOWTO_* */  
>+uint32_tflag; /* XSPLICE_HOWTO_FLAG_* */  
>+uint32_tsize; /* Size, in bytes, of the item to be relocated. */  
>+uint32_tr_shift; /* The value the final relocation is shifted right 
>by; used to drop unwanted data from the relocation. */  

Surely a uint8_t would suffice here?

>+uint64_tmask; /* Bitmask for which parts of the instruction or data 
>are replaced with the relocated value. */  

Does that mean "size" is limited to 8? The example below only uses
the trivial values (r_shift=0, mask=~0), so the real meaning of these
isn't clear. In particular I can't see what good right shifting a
relocated value can do. Furthermore all this is very x86-centric;
(almost) all other architectures I know a little about won't get away
with such simple relocations, since immediates/displacements are
scattered around an instruction word there.

>+## Signature checking requirements.
>+
>+The signature checking requires that the layout of the data in memory
>+**MUST** be same for signature to be verified. This means that the payload
>+data layout in ELF format **MUST** match what the hypervisor would be
>+expecting such that it can properly do signature verification.
>+
>+The signature is based on the all of the payloads continuously laid out
>+in

[Xen-devel] [PATCH] xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)

[Konrad Rzeszutek Wilk]

From: Cathy Avery 

xen-blkfront will crash if the check to talk_to_blkback()
in blkback_changed()(XenbusStateInitWait) returns an error.
The driver data is freed and info is set to NULL. Later during
the close process via talk_to_blkback's call to xenbus_dev_fatal()
the null pointer is passed to and dereference in blkfront_closing.

Signed-off-by: Cathy Avery 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/block/xen-blkfront.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 0823a96..04fc7b4 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1955,7 +1955,8 @@ static void blkback_changed(struct xenbus_device *dev,
break;
/* Missed the backend's Closing state -- fallthrough */
case XenbusStateClosing:
-   blkfront_closing(info);
+   if (info)
+   blkfront_closing(info);
break;
}
 }
-- 
2.4.3


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

Re: [Xen-devel] [PATCH V7 5/7] xl: add pvusb commands

[Ian Campbell]

On Thu, 2015-10-01 at 18:02 +0100, George Dunlap wrote:
> On 25/09/15 03:11, Chunyan Liu wrote:
> > Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list,
> > usb-attach and usb-detach.
> > 
> > To attach a usb device to guest through pvusb, one could follow
> > following example:
> > 
> >  #xl usb-ctrl-attach test_vm version=1 num_ports=8
> 
> So all the way back in v2 of this series, I suggested making the
> arguments for usb-ctrl-attach and usb-attach mirror the format that is
> found in the config file[1]
> [...]
> [1]
> marc.info/?i=<
> caflbxzb1n3_9pvvg-yc8dyvaiyszvra3h2e8496vhnefvrm...@mail.gmail.com>

Re: xl usb-ctrl-attach test_vm name=pv-1,type=pv,version=1,ports=8

FWIW I think most of the existing ones allow (but don't require) a slight
difference in the cli version, which is that they allow space spearated
lists as well as command separate, which ends up a bit more natural:

xl usb-ctrl-attach test_vm name=pv-1 type=pv version=1 ports=8

I also agree that we should try and do something similar here unless there
is a compelling reason we can't.

Ian.

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

Re: [Xen-devel] [PATCH V7 3/7] libxl: add pvusb API

[Ian Campbell]

On Wed, 2015-09-30 at 18:55 +0100, George Dunlap wrote:

> > +int libxl_devid_to_device_usbctrl(libxl_ctx *ctx,
> > +  uint32_t domid,
> > +  int devid,
> > +  libxl_device_usbctrl *usbctrl)
> > +{
> > +GC_INIT(ctx);
> > +libxl_device_usbctrl *usbctrls;
> > +int nb = 0;
> > +int i, rc = -1;
> > +
> > +usbctrls = libxl_device_usbctrl_list(ctx, domid, &nb);
> > +if (!nb) goto out;
> > +
> > +for (i = 0; i < nb; i++) {
> > +if (devid == usbctrls[i].devid) {
> > +*usbctrl = usbctrls[i];
> 
> libxl maintainers: Is this kind of copying OK?
> 
> The analog functions for vtpm and nic both take very different
> approaches; both call libxl_device_[type]_init() and then fill in
> individual elements (albeit in different ways).

That depends on the memory lifecycle situation of usbctrls[i] and *usbctrl
vis-a-vis the gc and when they are frred.

Cut out of the context here is a 
+libxl_device_usbctrl_list_free(usbctrls, nb);

which is going to free any of the pointers in usbctrls[i] which have been
copied to usbctrl. So in this case no it is not ok.

You can't avoid the libxl_device_usbctrl_list_free, since you don't want to
leak all the other elements on the list, so copying seems to be the way to
go.

The IDL should have generated a copy function which can be used (by the
vtpm one too, but it predates the IDL making such things I think).

> 
> > +/*
> > + * USB add
> > + */
> > +static int do_usb_add(libxl__gc *gc, uint32_t domid,
> > +  libxl_device_usb *usbdev,
> > +  libxl__ao_device *aodev)
> > +{
> > +libxl_ctx *ctx = CTX;
> > +libxl_usbctrlinfo usbctrlinfo;
> > +libxl_device_usbctrl usbctrl;
> > +int rc;
> > +
> > +libxl_usbctrlinfo_init(&usbctrlinfo);
> > +usbctrl.devid = usbdev->ctrl;
> > +rc = libxl_device_usbctrl_getinfo(ctx, domid, &usbctrl,
> > &usbctrlinfo);
> > +if (rc)
> > +goto out;
> > +
> > +switch (usbctrlinfo.type) {
> > +case LIBXL_USBCTRL_TYPE_DEVICEMODEL:
> > +LOG(ERROR, "Not supported");
> > +break;
> > +case LIBXL_USBCTRL_TYPE_PV:
> > +rc = libxl__device_usb_add_xenstore(gc, domid, usbdev,
> > +aodev->update_json);
> > +if (rc) goto out;
> > +
> > +rc = usbback_dev_assign(gc, usbdev);
> 
> This assumes that the usb controller is dom0; but the interface
> explicitly allows pvusb driver domains.
> 
> I think it would be enough here to do this check if the usbctrl device
> is dom0.  We should then assume that a pvusb driver domain will be
> configured with all usb devices assigned to usbback already.
> 
> I assume that there's a feedback mechanisms for backends for situations
> where the requested device can't be made, right?  For example, if you
> have a network driver domain and request a non-existent bridge?  If so,
> I think we can let the same mechanism worth for pvusb backends to say "I
> don't have that device available".

I think the b/e writes an error node in xenstore, which we already pickup
iirc.


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