[Xen-devel] [OSSTEST PATCH 4/8] Schema: Introduce mg-schema-create

[Ian Jackson]

There is a fair amount of option parsing clobber here that will be
relevant shortly.

Signed-off-by: Ian Jackson 
---
 mg-schema-create|   61 +++
 mg-schema-test-database |2 +-
 2 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100755 mg-schema-create

diff --git a/mg-schema-create b/mg-schema-create
new file mode 100755
index 000..54f1c76
--- /dev/null
+++ b/mg-schema-create
@@ -0,0 +1,61 @@
+#!/bin/bash
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2015 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 .
+
+
+# Usages:
+#
+#  ./mg-schema-create []
+#
+#  Database must already exist.  (Ie, mg-schema-create does not
+#  do CREATE DATABASE.)
+#
+#  When setting up a production database, mg-schema-create should
+#  be run *AS THE ROLE USER* who is to own all the resources.
+#
+# Options:
+#
+#  -qdon't print progress messages
+
+set -e
+set -o posix
+set -o pipefail
+
+progress () { printf "%s\n" "$*"; }
+progress=progress
+quietopt=''
+
+while [ $# != 0 ]; do
+arg=$1; shift
+case "$arg" in
+-q)
+progress=:
+quietopt=-q
+;;
+*)
+echo >&2 "bad usage ($arg)"; exit 127
+;;
+esac
+done
+
+. ./cri-getconfig
+
+$progress "Populating database..."
+
+$(get_psql_cmd) $quietopt -f schema/initial.sql
+
+$progress "Database set up."
diff --git a/mg-schema-test-database b/mg-schema-test-database
index c68b1d2..3616c4d 100755
--- a/mg-schema-test-database
+++ b/mg-schema-test-database
@@ -391,7 +391,7 @@ END
psql_do 

[Xen-devel] [OSSTEST PATCH 8/8] Schema: When creating, check that no updates are applied

[Ian Jackson]

If you try to run mg-schema-create on an existing instance it bombs
out right at the beginning because it tries to create the `flights'
table, which already exists.

But in the future the `flights' table might be removed in an update,
which would remove this safety catch.  Then running the create might
partially succeed, leaving debris a production instance.

Detect this situation by looking for applied schema updates, and
bombing out if there are any.

Signed-off-by: Ian Jackson 
Acked-by: Ian Campbell 
---
 mg-schema-create |7 +++
 1 file changed, 7 insertions(+)

diff --git a/mg-schema-create b/mg-schema-create
index df5e215..e15ecb9 100755
--- a/mg-schema-create
+++ b/mg-schema-create
@@ -70,6 +70,13 @@ export OSSTEST_DB_USEREAL_IGNORETEST='.*'
 
 . ./cri-getconfig
 
+updates_applied=$(./mg-schema-update list-applied)
+if [ "x$updates_applied" != x ]; then
+./mg-schema-update show
+echo >&2 'Database already exists with applied updates!'
+exit 127
+fi
+
 ./mg-schema-update $quietopt check-user
 
 $progress "Populating database..."
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 6/8] Schema: Check that schema creation and update runs as the right user

[Ian Jackson]

Signed-off-by: Ian Jackson 
Acked-by: Ian Campbell 
---
 Osstest/Executive.pm|1 +
 README  |5 +
 mg-schema-create|4 +++-
 mg-schema-test-database |1 +
 mg-schema-update|   16 
 5 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index e1fbe3b..f2d29ef 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -105,6 +105,7 @@ augmentconfigdefaults(
 QueuePlanUpdateInterval => 300, # seconds
 Repos => "$ENV{'HOME'}/repos",
 BisectionRevisonGraphSize => '600x300',
+ExecutiveDbOwningRoleRegexp => 'osstest',
 );
 
 augmentconfigdefaults(
diff --git a/README b/README
index 5740ac0..0a346dc 100644
--- a/README
+++ b/README
@@ -571,6 +571,11 @@ ExecutiveDbname_
PostgreSQL dbname string for the database .  Default is to use
ExecutiveDbnamePat.
 
+ExecutiveDbOwningRoleRegexp
+   Regexp which is supposed to match the database user used for schema
+   changes - because, that role will end up owning the database objects.
+   Defaults to `osstest'.
+
 Adhoc/Custom Flights
 
 
diff --git a/mg-schema-create b/mg-schema-create
index 1ee007b..df5e215 100755
--- a/mg-schema-create
+++ b/mg-schema-create
@@ -25,7 +25,7 @@
 #  do CREATE DATABASE.)
 #
 #  When setting up a production database, mg-schema-create should
-#  be run *AS THE ROLE USER* who is to own all the resources.
+#  be run as the role user who is to own all the resources.
 #
 # Options:
 #
@@ -70,6 +70,8 @@ export OSSTEST_DB_USEREAL_IGNORETEST='.*'
 
 . ./cri-getconfig
 
+./mg-schema-update $quietopt check-user
+
 $progress "Populating database..."
 
 $(get_psql_cmd) $quietopt -f schema/initial.sql
diff --git a/mg-schema-test-database b/mg-schema-test-database
index 5c6a935..bf82c75 100755
--- a/mg-schema-test-database
+++ b/mg-schema-test-database
@@ -335,6 +335,7 @@ OwnerDaemonHost $ctrlhost
 QueueDaemonHost $ctrlhost
 OwnerDaemonPort ${ctrlports%,*}
 QueueDaemonPort ${ctrlports#*,}
+ExecutiveDbOwningRoleRegexp .*
 END
mv -f $tcfg.tmp $tcfg
 
diff --git a/mg-schema-update b/mg-schema-update
index 2b472fc..1819b3a 100755
--- a/mg-schema-update
+++ b/mg-schema-update
@@ -22,6 +22,7 @@
 #  ./mg-schema-update [] apply [...]
 #  ./mg-schema-update [] show
 #  ./mg-schema-update [] apply-all
+#  ./mg-schema-update [] check-user
 #
 # Usual rune for applying updates:
 #
@@ -119,6 +120,13 @@ sub getstate () {
 @state = sort { $a->{Sortkey} <=> $b->{Sortkey} } values %state;
 }
 
+sub check_user () {
+my $user = $dbh_tests->{pg_user};
+my $re = $c{ExecutiveDbOwningRoleRegexp};
+return if $user =~ m/^$re$/o;
+die "running as wrong user \`$user', expected to match \`$re'\n";
+}
+
 sub cmd_list_applied () {
 die if @ARGV;
 getstate();
@@ -170,6 +178,8 @@ sub applyone ($) {
 die "Will not apply $v->{Name}.sql: $v->{Msg}\n"
unless want_apply($v);
 
+check_user();
+
 my $fn = $v->{File};
 
 db_retry($dbh_tests, \@all_lock_tables, sub {
@@ -242,6 +252,12 @@ sub cmd_apply_all () {
 print "Appropriate updates applied.\n" unless $quiet;
 }
 
+sub cmd_check_user () {
+die "too many arguments\n" if @ARGV>1;
+$c{ExecutiveDbOwningRoleRegexp} = shift @ARGV if @ARGV;
+check_user();
+}
+
 GetOptions('f|force+' => \$force,
   'q+' => \$quiet,
   'o|oldest=s' => \$there);
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 7/8] Schema: drop old resource_log table

[Ian Jackson]

Signed-off-by: Ian Jackson 
Acked-by: Ian Campbell 
---
 schema/drop-old-resource-log.sql |8 
 1 file changed, 8 insertions(+)
 create mode 100644 schema/drop-old-resource-log.sql

diff --git a/schema/drop-old-resource-log.sql b/schema/drop-old-resource-log.sql
new file mode 100644
index 000..9494e1b
--- /dev/null
+++ b/schema/drop-old-resource-log.sql
@@ -0,0 +1,8 @@
+-- ##OSSTEST## 002 Harmless
+--
+-- This table and associated constraints and indices is from a previous
+-- aborted attempt at resource logging.  Nothing actually reads or
+-- writes it.
+
+DROP TABLE resource_log;
+DROP SEQUENCE resource_log_evid_seq;
-- 
1.7.10.4


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

Re: [Xen-devel] [V3 PATCH 4/9] x86/hvm: pkeys, add functions to get pkeys value from PTE

[Andrew Cooper]

On 10/12/15 15:48, George Dunlap wrote:
> On 07/12/15 09:16, Huaitong Han wrote:
>> This patch adds functions to get pkeys value from PTE.
>>
>> Signed-off-by: Huaitong Han 
>> ---
>>  xen/include/asm-x86/guest_pt.h|  7 +++
>>  xen/include/asm-x86/page.h|  5 +
>>  xen/include/asm-x86/x86_64/page.h | 12 
>>  3 files changed, 24 insertions(+)
>>
>> diff --git a/xen/include/asm-x86/guest_pt.h b/xen/include/asm-x86/guest_pt.h
>> index 3447973..6b0af70 100644
>> --- a/xen/include/asm-x86/guest_pt.h
>> +++ b/xen/include/asm-x86/guest_pt.h
>> @@ -154,6 +154,13 @@ static inline u32 guest_l4e_get_flags(guest_l4e_t gl4e)
>>  { return l4e_get_flags(gl4e); }
>>  #endif
>>  
>> +static inline u32 guest_l1e_get_pkeys(guest_l1e_t gl1e)
>> +{ return l1e_get_pkeys(gl1e); }
>> +static inline u32 guest_l2e_get_pkeys(guest_l2e_t gl2e)
>> +{ return l2e_get_pkeys(gl2e); }
>> +static inline u32 guest_l3e_get_pkeys(guest_l3e_t gl3e)
>> +{ return l3e_get_pkeys(gl3e); }
>> +
>>  static inline guest_l1e_t guest_l1e_from_gfn(gfn_t gfn, u32 flags)
>>  { return l1e_from_pfn(gfn_x(gfn), flags); }
>>  static inline guest_l2e_t guest_l2e_from_gfn(gfn_t gfn, u32 flags)
>> diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
>> index a095a93..93a0db0 100644
>> --- a/xen/include/asm-x86/page.h
>> +++ b/xen/include/asm-x86/page.h
>> @@ -93,6 +93,11 @@
>>  #define l3e_get_flags(x)   (get_pte_flags((x).l3))
>>  #define l4e_get_flags(x)   (get_pte_flags((x).l4))
>>  
>> +/* Get pte pkeys (unsigned int). */
>> +#define l1e_get_pkeys(x)   (get_pte_pkeys((x).l1))
>> +#define l2e_get_pkeys(x)   (get_pte_pkeys((x).l2))
>> +#define l3e_get_pkeys(x)   (get_pte_pkeys((x).l3))
>> +
>>  /* Construct an empty pte. */
>>  #define l1e_empty()((l1_pgentry_t) { 0 })
>>  #define l2e_empty()((l2_pgentry_t) { 0 })
>> diff --git a/xen/include/asm-x86/x86_64/page.h 
>> b/xen/include/asm-x86/x86_64/page.h
>> index 19ab4d0..3ca489a 100644
>> --- a/xen/include/asm-x86/x86_64/page.h
>> +++ b/xen/include/asm-x86/x86_64/page.h
>> @@ -134,6 +134,18 @@ typedef l4_pgentry_t root_pgentry_t;
>>  #define get_pte_flags(x) (((int)((x) >> 40) & ~0xFFF) | ((int)(x) & 0xFFF))
>>  #define put_pte_flags(x) (((intpte_t)((x) & ~0xFFF) << 40) | ((x) & 0xFFF))
>>  
>> +/*
>> + * Protection keys define a new 4-bit protection key field
>> + * (PKEY) in bits 62:59 of leaf entries of the page tables.
>> + * This corresponds to bit 22:19 of a 24-bit flags.
>> + *
>> + * Notice: Bit 22 is used by _PAGE_GNTTAB which is visible to PV guests,
>> + * so Protection keys must be disabled on PV guests.
>> + */
>> +#define _PAGE_PKEY_BITS  (0x78)  /* Protection Keys, 22:19 */
>> +
>> +#define get_pte_pkeys(x) (MASK_EXTR(get_pte_flags(x), _PAGE_PKEY_BITS))
> Sorry if I'm getting nit-picky here, but any given pte will only have a
> single pkey, right?  Would it be better if these were "get_pte_pkey()"
> (i.e., singular)?

Correct.  An individual pte contains 4 bits which is "the protection
key", an index (in the range 0-15) into the protection key register,
which ultimately determines access-denied/write-denied on the linear
address.

~Andrew

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

[Xen-devel] [PATCH] scripts: Add a script to build and submit to coverity.

[Ian Campbell]

From: Andrew Cooper 

The submission requires a token and email address, which must be
registered as a project admin with the Coverity system. Nonetheless
this is a convenient place to keep it.

Signed-off-by: Andrew Cooper 

Took Andy script and:

- Wrote commit message.
- Generalised the settings handling.
- Added code to call the various steps based on the command line.
- Refactored construction of the curl command line (mainly in order to
  quote the email address).
- Clone mini-os before build.
- Make the upload stage unconditionally to the upload, but not that it
  still isn't in the default set of actions.

Signed-off-by: Ian Campbell 
---
ijc: Maybe we can think of a way to add this to osstest while still
keeping the coverity token private?
---
 scripts/coverity-build.sh | 108 ++
 1 file changed, 108 insertions(+)
 create mode 100755 scripts/coverity-build.sh

diff --git a/scripts/coverity-build.sh b/scripts/coverity-build.sh
new file mode 100755
index 000..91defed
--- /dev/null
+++ b/scripts/coverity-build.sh
@@ -0,0 +1,108 @@
+#!/bin/bash -e
+#
+# Copyright 2015 Andrew Cooper 
+#
+# WARNING: This script will blow away any changes in your git working
+# directory. It should probably be run in a dedicated checkout.
+#
+# Requires the coverity tools (e.g. cov-build) to be in $PATH.
+#
+# Set $COV_EMAIL and $COV_TOKEN to credentials, otherwise it will
+# prompt for them.
+#
+# ./scripts/coverity-build.sh 
+#
+# By default  is to do all the prep and build, but not to upload.
+#
+
+function checktools ()
+{
+if ! command -v cov-build ; then
+echo "Coverity tools (cov-build, ...) must be in \$PATH"
+exit 1
+fi
+}
+function hardclean ()
+{
+echo "Cleaning working tree"
+git reset --hard
+make distclean -j8
+}
+
+function update ()
+{
+echo "Pulling latest staging"
+git fetch --all
+git checkout master
+git pull --ff
+git checkout staging
+git pull --ff
+}
+
+function softclean ()
+{
+echo "Removing any remaining junk"
+git clean -dxf
+}
+
+function vars ()
+{
+export COV_HEAD=$(git rev-parse HEAD)
+export COV_TARBALL="xen-coverity-$COV_HEAD.tgz"
+export COV_VERSION="Xen-$(make -C xen xenversion --no-print-directory)"
+}
+
+function prebuild ()
+{
+echo "Running the pre-build"
+
+./configure
+make -C tools/firmware/etherboot all -j4
+make mini-os-dir
+}
+
+function build ()
+{
+echo "Starting Coverity build from $(pwd)"
+
+cov-build --dir cov-int make -C extras/mini-os/
+cov-build --dir cov-int make xen tools -j4
+tar czvf $COV_TARBALL cov-int
+}
+
+function upload ()
+{
+if [ -z "$COV_EMAIL" ] ; then
+   read -p "Email: " COV_EMAIL
+fi
+if [ -z "$COV_TOKEN" ] ; then
+   read -p "Form token: " COV_TOKEN
+fi
+
+declare -a curl_args
+curl_args+=("--form" "token=$COV_TOKEN")
+curl_args+=("--form" "email=$COV_EMAIL")
+curl_args+=("--form" "file=@$COV_TARBALL")
+curl_args+=("--form" "version=$COV_VERSION")
+curl_args+=("--form" "description=$COV_HEAD")
+curl_args+=("https://scan.coverity.com/builds?project=XenProject;)
+
+echo "Uploading... curl ${curl_args[@]}"
+echo curl "${curl_args[@]}" | tee cov-upload.log
+}
+
+function all ()
+{
+checktools
+hardclean
+softclean
+update
+softclean
+vars
+prebuild
+build
+}
+
+for cmd in ${@:-all} ; do
+eval $cmd
+done
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] x86/HVM: Merge HVM and PVH hypercall tables

[Boris Ostrovsky]

On 12/10/2015 07:30 AM, Jan Beulich wrote:

On 08.12.15 at 15:20,  wrote:

The tables are almost identical and therefore there is little reason to
keep both sets.

PVH needs 3 extra hypercalls:
* mmuext_op. PVH uses MMUEXT_TLB_FLUSH_MULTI and MMUEXT_INVLPG_MULTI to
   optimize TLB flushing. Since HVMlite guests may decide to use them as
   well we can allow these two commands for all guests in an HVM container.

I must be missing something here: Especially for the INVLPG variant
I can't see what use it could be for a PVH guest, as it necessarily
would act on a different address space (the other one may have at
least some effect due to hvm_flush_guest_tlbs()).


This is done out of xen_flush_tlb_others(), which is what PVH guests use.

And yes --- there indeed seems to be little reason to do that. But it is 
there now so I am not sure we can make this not work anymore for PVH guests.




And then, if those two really are meant to be enabled, why would
their _LOCAL and _ALL counterparts not be? And similarly,
MMUEXT_FLUSH_CACHE{,_GLOBAL} may then be valid to expose.


This is only used by PVH guests as optimization (see comment in 
xen_init_mmu_ops()). So there is no need to do a hypercall for LOCAL 
operations. For ALL/GLOBAL --- maybe we should allow those too, even 
though they are not currently used (in Linux).


(In principle we could allow LOCAL ones too. Assuming this all is needed 
at all)




Wasn't it much rather that PVH Dom0 needed e.g. MMUEXT_PIN_Ln_TABLE
to deal with foreign guests' page tables?


That I haven't considered.

Especially given that PVH dom0 is not booting for me, as I just found out:

...
(XEN) d0v0 EPT violation 0x1aa (-w-/r-x) gpa 0x00c0008116 mfn 
0xc0008 type 5

(XEN) d0v0 Walking EPT tables for GFN c0008:
(XEN) d0v0  epte 80082bf50007
(XEN) d0v0  epte 80082bf19007
(XEN) d0v0  epte 80043c6f9007
(XEN) d0v0  epte 8050c0008805
(XEN) d0v0  --- GLA 0xc90020008116
(XEN) domain_crash called from vmx.c:2816
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) [ Xen-4.7-unstable  x86_64  debug=y  Tainted:C ]
(XEN) CPU:0
(XEN) RIP:0010:[]
(XEN) RFLAGS: 00010046   CONTEXT: hvm guest (d0v0)
(XEN) rax: 001d   rbx:    rcx: 88014700f9b8
(XEN) rdx: 00ff   rsi:    rdi: 
(XEN) rbp: 88014700fa18   rsp: 88014700f9e8   r8: 88014700f9c0
(XEN) r9:  001d   r10: 8189c7f0   r11: 
(XEN) r12: c90020008000   r13: c90020008116   r14: 0002
(XEN) r15: 001d   cr0: 80050033   cr4: 000406f0
(XEN) cr3: 01c0e000   cr2: 
(XEN) ds:    es:    fs:    gs:    ss:    cs: 0010
(XEN) Guest stack trace from rsp=88014700f9e8:
(XEN)   Fault while accessing guest memory.
(XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.


We haven't been running regression tests for PVH dom0 so I don't know 
how long this has been broken.


-boris


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

Re: [Xen-devel] [PATCH v7 00/28] Kconfig conversion

[Jan Beulich]

>>> On 10.12.15 at 17:48,  wrote:
> - added initial x86_128 support

You're kidding?

Jan


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

[Xen-devel] [OSSTEST PATCH 5/8] Schema: Support database schema updates

[Ian Jackson]

See schema/README.schema, introduced in this patch, for the design.

Signed-off-by: Ian Jackson 
---
v2: Slight increase schema update name length format.
Docs fixes:
Change erroneous `three' to `four'.
Change `state' to `status' throghout.
Explain scope of .
Sort out (and renumber) `Update order for Populate-then-rely'.
Sort out "Statuses" explanations.
Encourage use of DML update, rather than ad-hoc scripts,
 for populating new columns.
---
 Osstest/Executive.pm  |   82 +++
 mg-schema-create  |   20 
 mg-schema-test-database   |6 +-
 mg-schema-update  |  255 +
 schema/README.updates |  179 +++
 schema/schema-updates.sql |6 ++
 6 files changed, 547 insertions(+), 1 deletion(-)
 create mode 100755 mg-schema-update
 create mode 100644 schema/README.updates
 create mode 100644 schema/schema-updates.sql

diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index fcef83f..e1fbe3b 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -56,6 +56,7 @@ BEGIN {
   resource_check_allocated resource_shared_mark_ready
   duration_estimator
   db_pg_dsn opendb opendb_state
+  db_schema_updates_applied db_schema_updates_intree
   );
 %EXPORT_TAGS = ( colours => [qw($green $red $yellow $purple $blue)] );
 
@@ -128,6 +129,87 @@ sub grabrepolock_reexec {
 }
 }
 
+sub db_schema_updates_applied (;$) {
+my ($cond) = @_;
+my $r;
+$cond //= '1=1';
+eval {
+   local $dbh_tests->{PrintError} = 0;
+   $r = $dbh_tests->selectall_arrayref(<err()==7 && # DBD::Pg(3pm)
+   $dbh_tests->state() eq '42P01';
+   # http://www.postgresql.org/docs/current/static/errcodes-appendix.html
+   $r = [ ];
+}
+my @r;
+foreach (@$r) {
+   push @r, { Name => $_->[0], Applied => $_->[1] };
+}
+return \@r;
+}
+
+sub db_schema_updates_intree (;$) {
+my ($incommit) = @_;
+# ->[]{Name}
+# ->[]{Seq}
+# ->[]{State}
+
+my @results;
+
+my @files;
+if (!$incommit) {
+   @files = ;
+} else {
+   local $/ = "\0";
+   open GLF, "-|", qw(git ls-tree -z), $incommit, "schema/" or die $!;
+   while () {
+   chomp;
+   next unless s/^\d+ blob \w+\t//;
+   push @files, $_;
+   }
+   $!=0; $?=0; close GLF or die "$! $? ($incommit)";
+}
+
+  FILE: foreach my $f (@files) {
+$f =~ m/\.sql$/ or next;
+   $f =~ m#/([a-z][0-9a-z-]+)\.sql$# or die "badly named .sql file $f\n";
+   my $name = $1;
+   next if $name eq 'initial';
+   if ($incommit) {
+   open SQLF, "-|", qw(git cat-file blob), "$incommit:$f" or die $!;
+   } else {
+   open SQLF, "<", $f or die "$f $!";
+   }
+   while () {
+   chomp;
+   my $origl = $_;
+   next unless s/^\s*--\s*##OSSTEST##\s+//;
+   m/^0*([1-9]\d*)\s+(Harmless|Preparatory|Unfinished|Ready|Needed)\b/
+   or die "$origl ?";
+   push @results, {
+   Name => $name,
+   Seq => $1+0,
+   State => $2,
+   };
+   next FILE;
+   }
+   $!=0; $?=0; close SQLF; die "$f \`$name' no token ($! $?)";
+}
+
+@results = sort {
+   $a->{Seq} <=> $b->{Seq} ||
+   die "$a->{Name} $a->{Seq} == $b->{Name} $b->{Seq}"
+} @results;
+
+return \@results;
+}
+
 #-- database access --#
 
 sub opendb_state () {
diff --git a/mg-schema-create b/mg-schema-create
index 54f1c76..1ee007b 100755
--- a/mg-schema-create
+++ b/mg-schema-create
@@ -30,6 +30,9 @@
 # Options:
 #
 #  -qdon't print progress messages
+#  --no-updates  apply no schema updates
+#  --stop-before --stop-afteronly apply some schema updates -
+# see mg-schema-update
 
 set -e
 set -o posix
@@ -38,6 +41,8 @@ set -o pipefail
 progress () { printf "%s\n" "$*"; }
 progress=progress
 quietopt=''
+do_updates=true
+updates=()
 
 while [ $# != 0 ]; do
 arg=$1; shift
@@ -46,16 +51,31 @@ while [ $# != 0 ]; do
 progress=:
 quietopt=-q
 ;;
+--stop-before|--stop-after)
+   updates+=("$arg" "$1"); shift
+   ;;
+--stop-before=*|--stop-after=*)
+   updates+=("$arg"); shift
+   ;;
+--no-updates)
+   do_updates=false
+   ;;
 *)
 echo >&2 "bad usage ($arg)"; exit 127
 ;;
 esac
 done
 
+export OSSTEST_DB_USEREAL_IGNORETEST='.*'
+
 . ./cri-getconfig
 
 $progress "Populating database..."
 
 $(get_psql_cmd) $quietopt -f schema/initial.sql
 
+if $do_updates; then
+   

Re: [Xen-devel] [PATCH] x86/HVM: Merge HVM and PVH hypercall tables

[Jan Beulich]

>>> On 10.12.15 at 17:53,  wrote:
> On 12/10/2015 07:30 AM, Jan Beulich wrote:
> On 08.12.15 at 15:20,  wrote:
>>> The tables are almost identical and therefore there is little reason to
>>> keep both sets.
>>>
>>> PVH needs 3 extra hypercalls:
>>> * mmuext_op. PVH uses MMUEXT_TLB_FLUSH_MULTI and MMUEXT_INVLPG_MULTI to
>>>optimize TLB flushing. Since HVMlite guests may decide to use them as
>>>well we can allow these two commands for all guests in an HVM container.
>> I must be missing something here: Especially for the INVLPG variant
>> I can't see what use it could be for a PVH guest, as it necessarily
>> would act on a different address space (the other one may have at
>> least some effect due to hvm_flush_guest_tlbs()).
> 
> This is done out of xen_flush_tlb_others(), which is what PVH guests use.
> 
> And yes --- there indeed seems to be little reason to do that. But it is 
> there now so I am not sure we can make this not work anymore for PVH guests.

PVH is experimental, so we certainly can. I'm pretty determined that
we shouldn't expose functionality to PVH (or HVMlite) that can't be
actually useful to it. I think it was a mistake to allow PVH general
access to all MMUEXT ops (I thought this had been discussed, but I
can't seem to find that discussion going back to v12 of the PVH series,
and I can't even spot the particular patch earlier than in v12).

Jan


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

Re: [Xen-devel] [PATCH v2 1/2] VT-d: Reduce spin timeout to 1ms, which can be boot-time changed.

[Andrew Cooper]

On 10/12/15 09:33, Quan Xu wrote:
> Signed-off-by: Quan Xu 
> ---
>  xen/drivers/passthrough/vtd/qinval.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/xen/drivers/passthrough/vtd/qinval.c 
> b/xen/drivers/passthrough/vtd/qinval.c
> index b81b0bd..990baf2 100644
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -28,6 +28,11 @@
>  #include "vtd.h"
>  #include "extern.h"
>  
> +static int __read_mostly iommu_qi_timeout_ms = 1;
> +integer_param("iommu_qi_timeout_ms", iommu_qi_timeout_ms);
> +
> +#define IOMMU_QI_TIMEOUT (iommu_qi_timeout_ms * MILLISECS(1))
> +
>  static void print_qi_regs(struct iommu *iommu)
>  {
>  u64 val;
> @@ -167,10 +172,12 @@ static int queue_invalidate_wait(struct iommu *iommu,
>  start_time = NOW();
>  while ( poll_slot != QINVAL_STAT_DONE )
>  {
> -if ( NOW() > (start_time + DMAR_OPERATION_TIMEOUT) )
> +if ( NOW() > (start_time + IOMMU_QI_TIMEOUT) )
>  {
>  print_qi_regs(iommu);
> -panic("queue invalidate wait descriptor was not executed");
> +dprintk(XENLOG_WARNING VTDPREFIX,
> +"Queue invalidate wait descriptor was timeout.\n");
> +return -ETIMEDOUT;
>  }
>  cpu_relax();
>  }

This patch misses a second use of DMAR_OPERATION_TIMEOUT, in
IOMMU_WAIT_OP() which in turn is used in a large number of locations. 
All of these locations equally need to be chopped down to a low number
of milliseconds.

~Andrew

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

Re: [Xen-devel] [PATCH] public/sysctl: Clarifications to XEN_SYSCTL_PHYSCAP_hvm_directio

[Andrew Cooper]

On 01/12/15 13:35, Jan Beulich wrote:
 On 01.12.15 at 12:37,  wrote:
>> --- a/xen/include/public/sysctl.h
>> +++ b/xen/include/public/sysctl.h
>> @@ -89,7 +89,14 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_tbuf_op_t);
>>   /* (x86) The platform supports HVM guests. */
>>  #define _XEN_SYSCTL_PHYSCAP_hvm  0
>>  #define XEN_SYSCTL_PHYSCAP_hvm   (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
>> - /* (x86) The platform supports HVM-guest direct access to I/O devices. */
>> + /*
>> +  * (x86) The platform supports guest direct access to I/O devices.
>> +  *
>> +  * Note that this parameter has been misnamed since its introduction, and 
>> is
>> +  * now too baked into APIs and ABIs to change.  Despite the "hvm" in its
> What do you mean with "too baked into ..."? This is sysctl, which can
> be changed, and I found just two uses (one in the hypervisor, the
> other in libxl), so changing the use sites wouldn't seem all that
> problematic (in the worst case we could also keep to current name
> behind a __XEN_INTERFACE_VERSION__ conditional).

It is libxl which is the problem.  Given its stable API,
libxl_physinfo.cap_hvm_directio can't be changed.

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/2] VT-d: Fix vt-d flush timeout issue.

[Andrew Cooper]

On 10/12/15 09:33, Quan Xu wrote:
> diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
> index a5aef55..0bf6b1a 100644
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -41,6 +41,7 @@
>  struct pci_dev_info {
>  bool_t is_extfn;
>  bool_t is_virtfn;
> +bool_t is_unassignable;
>  struct {
>  u8 bus;
>  u8 devfn;
> @@ -88,6 +89,12 @@ struct pci_dev {
>  #define for_each_pdev(domain, pdev) \
>  list_for_each_entry(pdev, &(domain->arch.pdev_list), domain_list)
>  
> +#define PDEV_UNASSIGNABLE 1
> +#define mark_pdev_unassignable(pdev) \
> +pdev->info.is_unassignable = PDEV_UNASSIGNABLE
> +
> +#define IS_PDEV_UNASSIGNABLE(pdev) pdev->info.is_unassignable

Static inlines please.

These macros lack any hygene whatsoever, but don't need to be macros in
the first place.

~Andrew

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

Re: [Xen-devel] [V3 PATCH 6/9] x86/hvm: pkeys, add xstate support for pkeys

[Andrew Cooper]

On 07/12/15 09:16, Huaitong Han wrote:
> This patch adds xstate support for pkeys.
>
> Signed-off-by: Huaitong Han 
> ---
>  xen/arch/x86/xstate.c| 7 +--
>  xen/include/asm-x86/xstate.h | 4 +++-
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
> index b65da38..db978c4 100644
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -146,12 +146,15 @@ static void __init setup_xstate_comp(void)
>  }
>  }
>  
> -static void *get_xsave_addr(void *xsave, unsigned int xfeature_idx)
> +void *get_xsave_addr(void *xsave, unsigned int xfeature_idx)

This really should take a struct_xsave *xsave, rather than a void pointer.

>  {
>  if ( !((1ul << xfeature_idx) & xfeature_mask) )
>  return NULL;

Now I look at it, this check is bogus.  The check needs to be against
the xsave header in the area, rather than Xen's maximum xfeature_mask. 
A guest might easily have a smaller xcr0 than the maximum Xen is willing
to allow, causing the pointer below to be bogus.

~Andrew

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

[Xen-devel] [PATCH] x86_emulate: Always truncate %eip out of long mode

[Andrew Cooper]

_regs.eip needs to be truncated after having size added to it, or bad
situations can occur. e.g. emulating an instruction which crosses the 4GB
boundary causes _regs.eip to become invalid (have some of the upper 32 bits
set), and fail vmentry checks when returning back to the guest.

The comment /* real hardware doesn't truncate */ seems to appear in c/s
ddef8e16 "Tweak x86 emulator interface." without any justification.

I have not been able to find any information to prove or disprove the claim,
but emulating oneself into a vmentry failure is definitely the wrong thing to
do.

Trucate the instruction pointer at 32 or 16 bits, according to %cs.D.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2: Use def_ad_bytes, to allow truncating to 16 bits for a 16bit code segment.
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index f1454ce..03e7aab 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -570,8 +570,10 @@ do{ asm volatile ( 
 \
 /* Fetch next part of the instruction being emulated. */
 #define insn_fetch_bytes(_size) \
 ({ unsigned long _x = 0, _eip = _regs.eip;  \
-   if ( !mode_64bit() ) _eip = (uint32_t)_eip; /* ignore upper dword */ \
-   _regs.eip += (_size); /* real hardware doesn't truncate */   \
+   _regs.eip += (_size);\
+   if ( !mode_64bit() ) { /* Truncate eip to def_ad_bytes (2 or 4). */  \
+   _eip  &= ~((1UL << (def_ad_bytes * 8)) - 1); \
+   _regs.eip &= ~((1UL << (def_ad_bytes * 8)) - 1); };  \
generate_exception_if((uint8_t)(_regs.eip -  \
ctxt->regs->eip) > MAX_INST_LEN, \
  EXC_GP, 0);\
-- 
2.1.4


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

[Xen-devel] [PATCH] public/hvm: Export the HVM_PARAM_CALLBACK_VIA ABI in the API

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Tim Deegan 
CC: Ian Campbell 
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Shannon Zhao 

v2: Reformat the comments, and note that GSI 0 cannot be used.
---
This ABI is utterly mad.

Despite appearing to be wrong, it is compatible with its implementation of

enum {
HVMIRQ_callback_none,
HVMIRQ_callback_gsi,
HVMIRQ_callback_pci_intx,
HVMIRQ_callback_vector
} callback_via_type;

Because of a sneaky:

via_type = (uint8_t)(via >> 56) + 1;
if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
 (via_type > HVMIRQ_callback_vector) )

I also observe:
 * GSI is actually clipped at 8 bits, rather than the documented 55
 * Xen currently ignores DOMAIN and FUNCTION from PCI_INTX.  As this has been
   broken for a very long time, it probably can't be fixed without breaking
   something else.

but lack sufficient time to fix these issues at the moment.
---
 xen/include/public/hvm/params.h | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index b437444..81f9451 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -29,18 +29,31 @@
  * Parameter space for HVMOP_{set,get}_param.
  */
 
+#define HVM_PARAM_CALLBACK_IRQ 0
 /*
  * How should CPU0 event-channel notifications be delivered?
- * val[63:56] == 0: val[55:0] is a delivery GSI (Global System Interrupt).
- * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
- *  Domain = val[47:32], Bus  = val[31:16],
- *  DevFn  = val[15: 8], IntX = val[ 1: 0]
- * val[63:56] == 2: val[7:0] is a vector number, check for
- *  XENFEAT_hvm_callback_vector to know if this delivery
- *  method is available.
+ *
  * If val == 0 then CPU0 event-channel notifications are not delivered.
+ * If val != 0, val[63:56] encodes the type, as follows:
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_GSI  0
+/*
+ * val[55:0] is a delivery GSI.  GSI 0 cannot be used, as it aliases val == 0,
+ * and disables all notifications.
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1
+/*
+ * val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_VECTOR   2
+/*
+ * val[7:0] is a vector number.  Check for XENFEAT_hvm_callback_vector to know
+ * if this delivery method is available.
  */
-#define HVM_PARAM_CALLBACK_IRQ 0
 
 /*
  * These are not used by Xen. They are here for convenience of HVM-guest
-- 
2.1.4


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

Re: [Xen-devel] [V3 PATCH 7/9] x86/hvm: pkeys, add pkeys support for guest_walk_tables

[Andrew Cooper]

On 07/12/15 09:16, Huaitong Han wrote:
> +
> +/* PKRU dom0 is always zero */
> +if ( likely(!pte_pkeys) )
> +return 0;

This is not an architectural restriction (as far as I can tell).  Xen
must never make assumptions about how a guest chooses to use a feature.

~Andrew

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

Re: [Xen-devel] how can I debug nested xen?

[Konrad Rzeszutek Wilk]

On Thu, Dec 10, 2015 at 02:15:32PM +, quizyjones wrote:
> I can debug xen using console connections. However, HVM nested xen seems to 
> not support 'xl console'. Even though I set the console according to 
> http://www.dedoimedo.com/computers/xen-console.html, it still cannot output 
> xen related infomation. Any suggestions?  
>  

Nonsense - it works.

Did you set on Xen's (the nested one) com1=115200 console=com1?

> ___
> 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 v7 02/28] MAINTAINERS: add myself for kconfig

[Jan Beulich]

>>> On 10.12.15 at 17:48,  wrote:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -226,6 +226,12 @@ F:  xen/include/{kexec,kimage}.h
>  F:  xen/arch/x86/machine_kexec.c
>  F:  xen/arch/x86/x86_64/kexec_reloc.S
>  
> +KCONFIG
> +M:   Doug Goldstein 
> +S:   Supported
> +F:   docs/misc/kconfig{,-language}.txt
> +F:   xen/tools/kconfig/
> +
>  MACHINE CHECK (MCA) & RAS

Pending the decision for you to be the maintainer of that code,
this went one slot too far down (but this can of course be fixed
up upon commit).

Jan


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

Re: [Xen-devel] [OSSTEST PATCH 4/8] Schema: Introduce mg-schema-create

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 4/8] Schema: Introduce 
mg-schema-create"):
> On Thu, 2015-12-10 at 17:12 +, Ian Jackson wrote:
> > There is a fair amount of option parsing clobber here that will be
> > relevant shortly.
> > 
> > Signed-off-by: Ian Jackson 
> 
> Acked-by: Ian Campbell 
> 
> (perhaps assuming #8 goes in in the same batch)

It should do.

Ian.

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

Re: [Xen-devel] [PATCH v7 02/28] MAINTAINERS: add myself for kconfig

[Doug Goldstein]

On 12/10/15 11:21 AM, Jan Beulich wrote:
 On 10.12.15 at 17:48,  wrote:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -226,6 +226,12 @@ F:  xen/include/{kexec,kimage}.h
>>  F:  xen/arch/x86/machine_kexec.c
>>  F:  xen/arch/x86/x86_64/kexec_reloc.S
>>  
>> +KCONFIG
>> +M:  Doug Goldstein 
>> +S:  Supported
>> +F:  docs/misc/kconfig{,-language}.txt
>> +F:  xen/tools/kconfig/
>> +
>>  MACHINE CHECK (MCA) & RAS
> 
> Pending the decision for you to be the maintainer of that code,
> this went one slot too far down (but this can of course be fixed
> up upon commit).
> 
> Jan
> 

Sorry about that. It sounded like you guys wanted me to maintain this so
I submitted this. If that's not the case please feel free to drop the
patch out of the series.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH] scripts: Add a script to build and submit to coverity.

[Ian Jackson]

Ian Jackson writes ("Re: [PATCH] scripts: Add a script to build and submit to 
coverity."):
> If curl can do that then fine.  Given
> 
> > >>> +declare -a curl_args
> > >>> +curl_args+=("--form" "token=$COV_TOKEN")
> > >>> +curl_args+=("--form" "email=$COV_EMAIL")
> 
> this could be achieved by having ts-do-coverity-thing set COV_TOKEN to
> $HOME/.xen-osstest/coverity-secret or whatever.  ts-do-coverity-thing
> would need to set a bunch of other COV_SOMETHING anyay.

It occurs to me that it would be better if
 - the Coverity token did not have to be sent to the build host,
but could remain on the controller
 - the Coverity log file thing could be left in the build logs

But I don't think this means that your script ought not to have an
`upload' function.  It just means that maybe osstest will need what
amounts to a copy of it.

Ian.

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

[Xen-devel] [PATCH v2 2/2] VT-d: Fix vt-d flush timeout issue.

[Quan Xu]

If IOTLB/Context/IETC flush is timeout, we should think
all devices under this IOMMU cannot function correctly.
So for each device under this IOMMU we'll mark it as
unassignable and kill the domain owning the device.

If Device-TLB flush is timeout, we'll mark the target
ATS device as unassignable and kill the domain owning
this device.

If impacted domain is hardware domain, just throw out
a warning. It's an open here whether we want to kill
hardware domain (or directly panic hypervisor). Comments
are welcomed.

Device marked as unassignable will be disallowed to be
further assigned to any domain.

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/extern.h  |  4 ++
 xen/drivers/passthrough/vtd/iommu.c   |  6 +++
 xen/drivers/passthrough/vtd/iommu.h   |  5 ++
 xen/drivers/passthrough/vtd/qinval.c  | 86 ++-
 xen/drivers/passthrough/vtd/x86/ats.c | 16 +++
 xen/include/xen/pci.h |  7 +++
 6 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/extern.h 
b/xen/drivers/passthrough/vtd/extern.h
index 8acf889..0a7d795 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -62,6 +62,10 @@ int dev_invalidate_iotlb(struct iommu *iommu, u16 did,
 int qinval_device_iotlb(struct iommu *iommu,
 u32 max_invs_pend, u16 sid, u16 size, u64 addr);
 
+void invalidate_timeout(struct iommu *iommu, int type, u16 did,
+u16 seg, u8 bus, u8 devfn);
+int invalidate_sync(struct iommu *iommu);
+
 unsigned int get_cache_line_size(void);
 void cacheline_flush(char *);
 void flush_all_cache(void);
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index dd13865..9317adb 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1890,6 +1890,9 @@ static int intel_iommu_add_device(u8 devfn, struct 
pci_dev *pdev)
 if ( !pdev->domain )
 return -EINVAL;
 
+if ( IS_PDEV_UNASSIGNABLE(pdev) )
+return -EACCES;
+
 ret = domain_context_mapping(pdev->domain, devfn, pdev);
 if ( ret )
 {
@@ -2301,6 +2304,9 @@ static int intel_iommu_assign_device(
 if ( list_empty(_drhd_units) )
 return -ENODEV;
 
+if ( IS_PDEV_UNASSIGNABLE(pdev) )
+return -EACCES;
+
 seg = pdev->seg;
 bus = pdev->bus;
 /*
diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index ac71ed1..c3beaa6 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -452,6 +452,11 @@ struct qinval_entry {
 
 #define RESERVED_VAL0
 
+#define INVALID_DID((u16)~0)
+#define INVALID_SEG((u16)~0)
+#define INVALID_BUS((u8)~0)
+#define INVALID_DEVFN  ((u8)~0)
+
 #define TYPE_INVAL_CONTEXT  0x1
 #define TYPE_INVAL_IOTLB0x2
 #define TYPE_INVAL_DEVICE_IOTLB 0x3
diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index 990baf2..bf7f5b0 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -27,12 +27,62 @@
 #include "dmar.h"
 #include "vtd.h"
 #include "extern.h"
+#include "../ats.h"
 
 static int __read_mostly iommu_qi_timeout_ms = 1;
 integer_param("iommu_qi_timeout_ms", iommu_qi_timeout_ms);
 
 #define IOMMU_QI_TIMEOUT (iommu_qi_timeout_ms * MILLISECS(1))
 
+void invalidate_timeout(struct iommu *iommu, int type, u16 did,
+u16 seg, u8 bus, u8 devfn)
+{
+struct domain *d;
+unsigned long nr_dom, i;
+struct pci_dev *pdev;
+
+switch (type) {
+case TYPE_INVAL_IOTLB:
+case TYPE_INVAL_CONTEXT:
+case TYPE_INVAL_IEC:
+nr_dom = cap_ndoms(iommu->cap);
+i = find_first_bit(iommu->domid_bitmap, nr_dom);
+while ( i < nr_dom ) {
+d = rcu_lock_domain_by_id(iommu->domid_map[i]);
+ASSERT(d);
+
+/* Mark the devices as unassignable. */
+for_each_pdev(d, pdev)
+mark_pdev_unassignable(pdev);
+if ( d != hardware_domain )
+domain_kill(d);
+
+rcu_unlock_domain(d);
+i = find_next_bit(iommu->domid_bitmap, nr_dom, i + 1);
+}
+break;
+
+case TYPE_INVAL_DEVICE_IOTLB:
+d = rcu_lock_domain_by_id(iommu->domid_map[did]);
+ASSERT(d);
+for_each_pdev(d, pdev)
+if ( (pdev->seg == seg) &&
+ (pdev->bus == bus) &&
+ (pdev->devfn == devfn) )
+mark_pdev_unassignable(pdev);
+
+if ( d != hardware_domain )
+domain_kill(d);
+rcu_unlock_domain(d);
+break;
+
+default:
+dprintk(XENLOG_WARNING VTDPREFIX, "Invalid VT-d flush type.\n");
+break;
+
+}
+}
+
 static void print_qi_regs(struct iommu *iommu)
 {
 u64 val;
@@ -187,7 +237,7 @@ static int queue_invalidate_wait(struct iommu 

[Xen-devel] [PATCH v2 0/2] VT-d flush issue

[Quan Xu]

This patches are based on Kevin Tian's previous discussion 'Revisit VT-d 
asynchronous flush issue'.
Fix current timeout concern and also allow limited ATS support in a light way:

1. Reduce spin timeout to 1ms, which can be boot-time changed with 
'iommu_qi_timeout_ms'.
   For example:
   multiboot /boot/xen.gz ats=1 iommu_qi_timeout_ms=100

2. Fix vt-d flush timeout issue.

If IOTLB/Context/IETC flush is timeout, we should think all devices under 
this IOMMU cannot function correctly.
So for each device under this IOMMU we'll mark it as unassignable and kill 
the domain owning the device.

If Device-TLB flush is timeout, we'll mark the target ATS device as 
unassignable and kill the domain owning
this device.

If impacted domain is hardware domain, just throw out a warning. It's an 
open here whether we want to kill
hardware domain (or directly panic hypervisor). Comments are welcomed.

Device marked as unassignable will be disallowed to be further assigned to 
any domain.

*Kevin Tian did basic functional review.

--Changes in v2:
1. Checking hardware_domain should be enough.
2. Do timeout check within dev_invalidate_iotlb for each ATS device, to 
identify bogus device accurately.

Quan Xu (2):
  VT-d: Reduce spin timeout to 1ms, which can be boot-time changed.
  VT-d: Fix vt-d flush timeout issue.

 xen/drivers/passthrough/vtd/extern.h  |  4 ++
 xen/drivers/passthrough/vtd/iommu.c   |  6 +++
 xen/drivers/passthrough/vtd/iommu.h   |  5 ++
 xen/drivers/passthrough/vtd/qinval.c  | 97 +--
 xen/drivers/passthrough/vtd/x86/ats.c | 16 ++
 xen/include/xen/pci.h |  7 +++
 6 files changed, 131 insertions(+), 4 deletions(-)

-- 
1.9.1


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

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemut-debianhvm-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-debianhvm-amd64
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  527e9316f8ec44bd53d90fb9f611fa752bb9
  Bug not present: 1cced5015b171415169d938fb179c44fe060dc15
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/65658/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl-qemut-debianhvm-amd64.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-qemut-debianhvm-amd64.xen-boot
 --summary-out=tmp/65658.bisection-summary --basis-template=59254 
--blessings=real,real-bisect linux-linus 
test-amd64-i386-xl-qemut-debianhvm-amd64 xen-boot
Searching for failure / basis pass:
 65459 fail [host=baroque0] / 63536 [host=italia1] 63398 [host=italia0] 63372 
[host=huxelrebe1] 63354 [host=fiano1] 63339 [host=chardonnay0] 63208 
[host=merlot1] 63084 [host=italia1] 63059 [host=pinot0] 63023 [host=rimava1] 
62972 [host=chardonnay1] 62958 [host=elbling1] 62948 [host=fiano1] 62940 
[host=chardonnay0] 62908 [host=pinot1] 62744 [host=huxelrebe0] 62694 
[host=italia1] 62663 [host=italia0] 62615 [host=huxelrebe1] 62544 [host=pinot0] 
62381 [host=huxelrebe0] 62295 [host=elbling0] 62197 [host=fiano1] 62110 
[host=chardonnay1] 62042 [host=fiano0] 61911 [host=italia0] 61780 
[host=rimava1] 61692 [host=rimava1] 61594 [host=huxelrebe0] 61295 
[host=merlot1] 60998 [host=elbling1] 60952 [host=pinot1] 60877 [host=pinot0] 
60840 [host=huxelrebe0] 60807 [host=rimava1] 60773 [host=fiano1] 60709 
[host=chardonnay1] 60680 [host=huxelrebe1] 60659 [host=chardonnay0] 60646 
[host=pinot1] 60621 [host=rimava1] 60594 [host=merlot1] 60389 [host=merlot0] 
60057 [host=merlot0] 59836 [host=chardonnay1] 597
 70 [host=chardonnay0] 59462 [host=italia0] 59426 [host=italia1] 59348 
[host=elbling0] 59254 [host=chardonnay1] 59186 [host=huxelrebe0] 59130 
[host=huxelrebe1] 59086 [host=rimava1] 59036 [host=italia0] 59018 [host=pinot0] 
58981 [host=merlot1] 58966 [host=chardonnay0] 58944 [host=fiano0] 58933 
[host=italia1] 58902 [host=elbling1] 58873 [host=elbling0] 58841 
[host=huxelrebe1] 58793 [host=rimava1] 58766 [host=huxelrebe0] 58737 
[host=italia0] 58620 [host=pinot0] 58522 [host=chardonnay1] 58428 
[host=italia1] 58399 [host=merlot0] 58333 [host=fiano1] 58228 [host=merlot1] 
58128 [host=pinot1] 58057 [host=rimava1] 57931 [host=italia0] 57874 
[host=huxelrebe0] 57824 [host=chardonnay0] 57740 [host=huxelrebe1] 57289 
[host=merlot1] 57205 [host=fiano0] 57123 [host=elbling0] 57031 [host=italia0] 
56964 [host=pinot1] 56791 [host=chardonnay0] 56718 [host=huxelrebe1] 56660 
[host=fiano1] 56589 [host=italia1] 56507 [host=chardonnay1] 56416 
[host=huxelrebe0] 55442 [host=merlot0] 55347 [host=elbling0] 55255 
 [host=pinot0] 54095 [host=fiano0] 53849 [host=italia0] 53720 [host=elbling1] 
53016 [host=fiano1] 52702 [host=pinot1] 50422 [host=pinot0] 50404 
[host=italia1] 50388 [host=fiano0] 50366 [host=fiano1] 50329 ok.
Failure / basis pass flights: 65459 / 50329
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 527e9316f8ec44bd53d90fb9f611fa752bb9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
Basis pass 1cced5015b171415169d938fb179c44fe060dc15 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
a4b276b4ce49c8d70dd841ff885b900ec652b994 
727b998448e852a5e8eb570ac3a259ef62fbdacb 
3a28f760508fb35c430edac17a9efde5aff6d1d5
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#1cced5015b171415169d938fb179c44fe060dc15-527e9316f8ec44bd53d90fb9f611fa752bb9
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#a4b276b4ce49c8d70dd841ff885b900ec652b994-bc00cad75d8bcc3ba696992bec219c21db8406aa
 

Re: [Xen-devel] [PATCH] VT-d: make flush-all actually flush all

[Jan Beulich]

>>> On 10.12.15 at 09:29,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, December 10, 2015 3:39 PM
>> To: Wu, Feng 
>> Cc: Tian, Kevin ; xen-devel > de...@lists.xenproject.org>
>> Subject: RE: [PATCH] VT-d: make flush-all actually flush all
>> 
>> >>> On 10.12.15 at 04:06,  wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Wednesday, December 9, 2015 10:53 PM
>> >> --- a/xen/drivers/passthrough/vtd/iommu.c
>> >> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> >> @@ -583,7 +583,7 @@ static void __intel_iommu_iotlb_flush(st
>> >>  if ( iommu_domid == -1 )
>> >>  continue;
>> >>
>> >> -if ( page_count > 1 || gfn == -1 )
>> >> +if ( page_count != 1 || gfn == INVALID_GFN )
>> >
>> > This patch looks good me, but I think using 'page_count'  to decide
>> > whether using dsi or psi is not a good idea, since psi should also support
>> > invalidate multiple pages from VT-d Spec. (Seems no support in Xen?)
>> 
>> I'm fine with this getting improved in a subsequent patch, but I
>> don't see this to be done here - what you propose is an
>> enhancement, while here I'm fixing a latent bug (which originally
>> got reported to security@, and we were able to discard security
>> concerns merely because the sole intel_iommu_iotlb_flush_all()
>> caller sits on a code path reachable only through an XSA-77
>> covered domctl). The more that there currently is no caller
>> passing in other than 0 or 1.
> 
> In intel_iommu_iotlb_flush_all(), 0 is passed in as the 'page_count',
> but intel_iommu_iotlb_flush() can pass in a value more than 1
> for 'page_count', right?

Ah, yes, it being the .iotlb_flush handler.

Jan


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

[Xen-devel] [PATCH v2 1/2] VT-d: Reduce spin timeout to 1ms, which can be boot-time changed.

[Quan Xu]

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/qinval.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index b81b0bd..990baf2 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -28,6 +28,11 @@
 #include "vtd.h"
 #include "extern.h"
 
+static int __read_mostly iommu_qi_timeout_ms = 1;
+integer_param("iommu_qi_timeout_ms", iommu_qi_timeout_ms);
+
+#define IOMMU_QI_TIMEOUT (iommu_qi_timeout_ms * MILLISECS(1))
+
 static void print_qi_regs(struct iommu *iommu)
 {
 u64 val;
@@ -167,10 +172,12 @@ static int queue_invalidate_wait(struct iommu *iommu,
 start_time = NOW();
 while ( poll_slot != QINVAL_STAT_DONE )
 {
-if ( NOW() > (start_time + DMAR_OPERATION_TIMEOUT) )
+if ( NOW() > (start_time + IOMMU_QI_TIMEOUT) )
 {
 print_qi_regs(iommu);
-panic("queue invalidate wait descriptor was not executed");
+dprintk(XENLOG_WARNING VTDPREFIX,
+"Queue invalidate wait descriptor was timeout.\n");
+return -ETIMEDOUT;
 }
 cpu_relax();
 }
-- 
1.9.1


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

[Xen-devel] [xen-unstable-smoke test] 65657: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ff841cead287d7913901ba5c4e7628a6958b5bea
baseline version:
 xen  a841b1b1286d122fd472b43db3c423b9876262e5

Last test of basis65617  2015-12-09 12:02:58 Z0 days
Testing same since65622  2015-12-09 15:01:14 Z0 days8 attempts


People who touched revisions under test:
  David Scott 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

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



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


Not pushing.


commit ff841cead287d7913901ba5c4e7628a6958b5bea
Author: Jan Beulich 
Date:   Wed Dec 9 13:53:13 2015 +0100

memory: fix XSA-158 fix

For one the uses of domu_max_order and ptdom_max_order were swapped.

And then gcc warns about an unused result of a __must_check function
in the control part of a conditional expression when both other
expressions can be determined by the compiler to produce the same value
(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68039), which happens
when HAS_PASSTHROUGH is undefined (i.e. for ARM on 4.4 and older).

Signed-off-by: Jan Beulich 
Acked-by: Ian Campbell 

commit c7d3afbb44b47af9103be0b914afd588a84d9e62
Author: Ian Campbell 
Date:   Thu Dec 3 11:22:02 2015 +

tools: Refactor "xentoollog" into its own library

In attempting to disaggregate libxenctrl I found that many of the
pieces were going to want access to this library, so split it out (as
it probably should always have been).

Various build adjustments are needed. In particular things which use
xtl_* themselves now need to explicity link against the library.

This has a nice side effect which is that users of libxl no longer
need to link against libxenctrl just to create a logger, which was
counter to the principal that applications using libxl shouldn't be
required to look behind the curtain. This means that xl no longer
links against libxenctrl.

The new library uses a version script to ensure that only expected
symbols are exported and to version them such that ABI guarantees can
be kept in the future.

Signed-off-by: Ian Campbell 
Acked-by: Ian Jackson 
Acked-by: Wei Liu 
[ ijc -- Update QEMU_TRADITIONAL_REVISION and MINIOS_UPSTREAM_REVISION ]

commit 78fb69ad932e012cd27ce9b5b7f8733d08b8061f
Author: Ian Campbell 
Date:   Thu Dec 3 11:22:01 2015 +

tools/Rules.mk: Properly handle libraries with recursive dependencies.

In tree libraries which link against other in tree libraries in a way
which is opaque to their callers need special handling, specifically
correct use of -Wl,-rpath-link for the recusively used libraries.

Currently this is rather simple, but up coming changes are going to
introduce transitive dependencies more than 1 step deep.

Introduce a SHDEPS idiom to contain all the recursive deps for a
library and include those in both LDLIBS (for linking) and SHLIB (for
recursive uses).

Try and document the whole 

Re: [Xen-devel] [PATCH v3] x86: Fixup IRQs when CPUs go down during shutdown

[Ross Lagerwall]

On 12/04/2015 02:42 PM, Jan Beulich wrote:

On 04.12.15 at 15:01,  wrote:

Commit fc0c3fa2ad5c ("x86/IO-APIC: fix setup of Xen internally used IRQs
(take 2)") introduced a regression on some hardware where Xen would hang
during shutdown, repeating the following message:
APIC error on CPU0: 08(08), Receive accept error

This appears to be because an interrupt (in this case from the serial
console) destined for a CPU other than the boot CPU is left unhandled so
an APIC error on CPU 0 is generated instead.

To fix this, before taking down the non-boot CPUs, call fixup_irqs()
with a CPU mask of only the boot CPU to reset the IRQ affinities
correctly.

Signed-off-by: Ross Lagerwall 


Reviewed-by: Jan Beulich 



Is this going to go onto staging?

Thanks,
--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v3] x86: Fixup IRQs when CPUs go down during shutdown

[Ross Lagerwall]

On 12/10/2015 09:28 AM, Jan Beulich wrote:

On 10.12.15 at 10:21,  wrote:

On 12/04/2015 02:42 PM, Jan Beulich wrote:

On 04.12.15 at 15:01,  wrote:

Commit fc0c3fa2ad5c ("x86/IO-APIC: fix setup of Xen internally used IRQs
(take 2)") introduced a regression on some hardware where Xen would hang
during shutdown, repeating the following message:
APIC error on CPU0: 08(08), Receive accept error

This appears to be because an interrupt (in this case from the serial
console) destined for a CPU other than the boot CPU is left unhandled so
an APIC error on CPU 0 is generated instead.

To fix this, before taking down the non-boot CPUs, call fixup_irqs()
with a CPU mask of only the boot CPU to reset the IRQ affinities
correctly.

Signed-off-by: Ross Lagerwall 


Reviewed-by: Jan Beulich 


Is this going to go onto staging?


I really was waiting for some kind of response to


... I really would have wanted the split of the functions to be
undone too (renaming the bool_t function parameter suitably).


in the mail that you just replied to (but stripped those parts off).



Oh, given the Reviewed-by tag, I thought you weren't expecting a 
response. Anyway, I prefer the version split into two functions since it 
is doing two logically separate tasks. I prefer having (arguably) better 
code than having less code churn and a smaller patch size.


--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v3] x86: Fixup IRQs when CPUs go down during shutdown

[Jan Beulich]

>>> On 10.12.15 at 10:21,  wrote:
> On 12/04/2015 02:42 PM, Jan Beulich wrote:
> On 04.12.15 at 15:01,  wrote:
>>> Commit fc0c3fa2ad5c ("x86/IO-APIC: fix setup of Xen internally used IRQs
>>> (take 2)") introduced a regression on some hardware where Xen would hang
>>> during shutdown, repeating the following message:
>>> APIC error on CPU0: 08(08), Receive accept error
>>>
>>> This appears to be because an interrupt (in this case from the serial
>>> console) destined for a CPU other than the boot CPU is left unhandled so
>>> an APIC error on CPU 0 is generated instead.
>>>
>>> To fix this, before taking down the non-boot CPUs, call fixup_irqs()
>>> with a CPU mask of only the boot CPU to reset the IRQ affinities
>>> correctly.
>>>
>>> Signed-off-by: Ross Lagerwall 
>>
>> Reviewed-by: Jan Beulich 
> 
> Is this going to go onto staging?

I really was waiting for some kind of response to

>>... I really would have wanted the split of the functions to be
>>undone too (renaming the bool_t function parameter suitably).

in the mail that you just replied to (but stripped those parts off).

Jan


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

Re: [Xen-devel] [PATCH] VT-d: make flush-all actually flush all

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, December 10, 2015 3:39 PM
> To: Wu, Feng 
> Cc: Tian, Kevin ; xen-devel  de...@lists.xenproject.org>
> Subject: RE: [PATCH] VT-d: make flush-all actually flush all
> 
> >>> On 10.12.15 at 04:06,  wrote:
> 
> >
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Wednesday, December 9, 2015 10:53 PM
> >> To: xen-devel 
> >> Cc: Wu, Feng ; Tian, Kevin 
> >> Subject: [PATCH] VT-d: make flush-all actually flush all
> >>
> >> VT-d: make flush-all actually flush all
> >>
> >> Passing gfn=0 and page_count=0 actually avoids the
> >> iommu_flush_iotlb_dsi() and results in page-specific invalidation
> >> instead.
> >>
> >> Reported-by: "张智" 
> >> Signed-off-by: Jan Beulich 
> >>
> >> --- a/xen/drivers/passthrough/vtd/iommu.c
> >> +++ b/xen/drivers/passthrough/vtd/iommu.c
> >> @@ -583,7 +583,7 @@ static void __intel_iommu_iotlb_flush(st
> >>  if ( iommu_domid == -1 )
> >>  continue;
> >>
> >> -if ( page_count > 1 || gfn == -1 )
> >> +if ( page_count != 1 || gfn == INVALID_GFN )
> >
> > This patch looks good me, but I think using 'page_count'  to decide
> > whether using dsi or psi is not a good idea, since psi should also support
> > invalidate multiple pages from VT-d Spec. (Seems no support in Xen?)
> 
> I'm fine with this getting improved in a subsequent patch, but I
> don't see this to be done here - what you propose is an
> enhancement, while here I'm fixing a latent bug (which originally
> got reported to security@, and we were able to discard security
> concerns merely because the sole intel_iommu_iotlb_flush_all()
> caller sits on a code path reachable only through an XSA-77
> covered domctl). The more that there currently is no caller
> passing in other than 0 or 1.

In intel_iommu_iotlb_flush_all(), 0 is passed in as the 'page_count',
but intel_iommu_iotlb_flush() can pass in a value more than 1
for 'page_count', right?

> 
> In an ideal world, my expectation really would have been for
> you to ack this change (of course unless you see anything
> actively wrong with it) and immediately follow it up with the
> described improvement (with the caveat that - see above -
> you'd have difficulty actually testing such a change).

Acked-by: Feng Wu 

Thanks,
Feng

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

[Xen-devel] [linux-4.1 test] 65632: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 63996
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 63996
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
63996

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 63996
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 63996
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 63996
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 63996

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17)   broken never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt 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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linuxcb371265c2f1a0dd0cee03bd7fff413d671c53f0
baseline version:
 linux1f2ce4a2e7aea3a2123b17aff62a80553df31e21

Last test of basis63996  2015-11-09 23:07:34 Z   30 days
Testing same since65632  2015-12-09 19:33:02 Z1 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Aleksander Morgado 
  Alexander Duyck 
  Alexandre Belloni 
  Alexandre Courbot 
  Amitkumar Karwar 
  Andrei Otcheretianski 
  Andrew Cooper 
  Ani Sinha 
  Ard Biesheuvel 
  Arik Nemtsov 
  Arik Nemtsov 
  Arnd Bergmann 
  Ben McCauley 
  Bjørn Mork 
  Borislav Petkov 
  Carol L Soto 
  Catalin Marinas 
  Christian Borntraeger 
  Christophe Ricard 
  Christophe Ricard 
  Clemens Ladisch 
  Cong Wang 
  Cornelia Huck 
  Dan Carpenter 
  David Herrmann 
  David 

Re: [Xen-devel] xenstore domain

[Doug Goldstein]

On 12/9/15 1:34 AM, Juergen Gross wrote:
> On 08/12/15 17:34, Andrew Cooper wrote:
>> On 08/12/15 16:02, Juergen Gross wrote:
>>> On 08/12/15 16:04, Andrew Cooper wrote:
 On 08/12/15 14:44, Juergen Gross wrote:
> I'm just playing a little bit with xenstore in an own domain.
>
> I've come across some questions I'd like to have some answers to before
> presenting official patches to make this an easy configurable option:
>
> a) As this would need a boot time configuration item I'd like to add
>e.g. /etc/xen/server.conf where such global configuration options
>could be set via directives. Is this generally okay? If yes, which
>format? Easiest way would be entries like
>VAR=value
>which can be either sourced in from shell scripts or can easily be
>parsed in all programming languages. What are the preferences here?
 Any configuration like this going to be toolstack-specific.  I would
 recommend against using a name as generic as that.

 /etc/xl.conf already exists, which IMO would be the natural place for
 this to live, but it isn't parseable by shell, because of vif notation.
>>> OTOH that file wouldn't be just for xl. It would be consumed by e.g.
>>> xencommons. Other configuration options I'd plan to add would be
>>> driver domains dedicated to specific interface cards.
>>
>> It is still logically part of the "xl toolstack infrastructure", but I
>> accept your point.  The current xl.conf is all about how to create
>> domains in general, rather than specifically "how I would like my system
>> configured when starting up".
>>
>>>
 One option might be to alter xl.conf to be compatible with shell
 parsing.  It wouldn't be complicated (even in upgrade situations), and
 would offer rather more flexibility.
>>> Shell parsing could be even handled via a rather simple filter, I guess.
>>>
> b) Today init-xenstore-domain will require flask to be enabled. An
>alternative would be to add a new domain creation flag to allow the
>domains with that flag set calling xc_domain_getinfo(). Thoughts?
 Which flag?
>>> A new domcr_flag.
>>
>> Indicating what, precisely?
> 
> What I need is the capability to do the XEN_DOMCTL_getdomaininfo
> hypercall from the xenstore domain. Question is whether it's better
> to tie this special capability to the flag or to name it "is_xenstore".
> 
> Thinking more about it, especially regarding a possible enhancement
> allowing Dom0 to reboot, I think the is_xenstore variant would be
> better. This would allow to look whether a xenstore domain is already
> running and connect to that rather than try to start a new one.
> 
> 
> Juergen

How would either of these relate to /proc/xen/capabilities and/or
/sys/hypervisor/properties/capabilities?

A number of distros use the former to decide when to start up xenstore
(in fact the in tree scripts do as well).

-- 
Doug Goldstein



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 64456

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 64456
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 64300
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 64456
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 64456

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 linux03ed106ff4c200d01f3c72f71fa9c5b18da07d9b
baseline version:
 linuxbdf8cfb859e9cd265ec1696d9e007fac66e7aea7

Last test of basis64456  2015-11-16 13:37:17 Z   24 days
Testing same since65634  2015-12-09 19:33:01 Z1 days1 attempts


People who touched revisions under test:
  Aleksander Morgado 
  Amitkumar Karwar 
  Andrew Cooper 
  Ani Sinha 
  Bjørn Mork 
  Borislav Petkov 
  Carol L Soto 
  Catalin Marinas 
  Clemens Ladisch 
  Dan Carpenter 
  David Herrmann 
  David S. Miller 
  Eric Dumazet 
  Felipe Balbi 
  Florian Fainelli 
  Greg Kroah-Hartman 
  Gregory CLEMENT 
  Guillaume Nault 
  Jack Morgenstein 
  Jason Wang 
  Jiri Slaby 
  Johan Hovold 
  Johannes Berg 
  Kalle Valo 
  Krzysztof Mazur 
  Larry Finger 
  Marc Kleine-Budde 
  Marcel Holtmann 
  Marek Szyprowski 
  Matt Fleming 
  Maxime Ripard 
  Michael S. Tsirkin 
  Mirza Krak 
  Or Gerlitz 
  Paolo Bonzini 
  Pete Zaitcev 
  Phil Reid 
  Richard Cochran 
  Robin Murphy 
  Russell King 
  Rusty Russell 
  Santosh Shilimkar 
  Sasha Levin 
  Sowmini Varadhan 
  Takashi Iwai 
  Thomas Gleixner 
  Uwe Kleine-König 
  Will Deacon 

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

Re: [Xen-devel] xenstore domain

[Andrew Cooper]

On 09/12/15 07:34, Juergen Gross wrote:
> On 08/12/15 17:34, Andrew Cooper wrote:
>> On 08/12/15 16:02, Juergen Gross wrote:
>>> On 08/12/15 16:04, Andrew Cooper wrote:
 On 08/12/15 14:44, Juergen Gross wrote:
> I'm just playing a little bit with xenstore in an own domain.
>
> I've come across some questions I'd like to have some answers to before
> presenting official patches to make this an easy configurable option:
>
> a) As this would need a boot time configuration item I'd like to add
>e.g. /etc/xen/server.conf where such global configuration options
>could be set via directives. Is this generally okay? If yes, which
>format? Easiest way would be entries like
>VAR=value
>which can be either sourced in from shell scripts or can easily be
>parsed in all programming languages. What are the preferences here?
 Any configuration like this going to be toolstack-specific.  I would
 recommend against using a name as generic as that.

 /etc/xl.conf already exists, which IMO would be the natural place for
 this to live, but it isn't parseable by shell, because of vif notation.
>>> OTOH that file wouldn't be just for xl. It would be consumed by e.g.
>>> xencommons. Other configuration options I'd plan to add would be
>>> driver domains dedicated to specific interface cards.
>> It is still logically part of the "xl toolstack infrastructure", but I
>> accept your point.  The current xl.conf is all about how to create
>> domains in general, rather than specifically "how I would like my system
>> configured when starting up".
>>
 One option might be to alter xl.conf to be compatible with shell
 parsing.  It wouldn't be complicated (even in upgrade situations), and
 would offer rather more flexibility.
>>> Shell parsing could be even handled via a rather simple filter, I guess.
>>>
> b) Today init-xenstore-domain will require flask to be enabled. An
>alternative would be to add a new domain creation flag to allow the
>domains with that flag set calling xc_domain_getinfo(). Thoughts?
 Which flag?
>>> A new domcr_flag.
>> Indicating what, precisely?
> What I need is the capability to do the XEN_DOMCTL_getdomaininfo
> hypercall from the xenstore domain. Question is whether it's better
> to tie this special capability to the flag or to name it "is_xenstore".
>
> Thinking more about it, especially regarding a possible enhancement
> allowing Dom0 to reboot, I think the is_xenstore variant would be
> better. This would allow to look whether a xenstore domain is already
> running and connect to that rather than try to start a new one.

If we do indeed want dom0 to be able to reboot, then we definitely do
need some bit of remaining state indicating where xenstore is.

Currently it is the residual knowledge that dom0 has from whether it
started a local daemon, or a stubdomain, but that information would
disappear on a reboot.

In general, I would be against adding extra magic like this to Xen, but
xenstore is already sufficiently magic and critical in a Xen system that
the benefits of this special case probably do outweigh its downsides. 
(I wonder how long it will be until multiple xenstore domains are
suggested in earnest on xen-devel.)

~Andrew

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

Re: [Xen-devel] [PATCH] VT-d: Correct order of parameters to memset() in setup_posted_irte()

[Wu, Feng]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, December 11, 2015 12:07 AM
> To: Xen-devel 
> Cc: Andrew Cooper ; Jan Beulich
> ; Wu, Feng ; Tian, Kevin
> 
> Subject: [PATCH] VT-d: Correct order of parameters to memset() in
> setup_posted_irte()
> 
> Introduced in c/s 83ea9229 "vt-d: add API to update IRTE when VT-d PI is
> used".  Spotted by Coverity.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Feng Wu 
> CC: Kevin Tian 
> ---
>  xen/drivers/passthrough/vtd/intremap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/intremap.c
> b/xen/drivers/passthrough/vtd/intremap.c
> index 0a48cd4..0ee3fb2 100644
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -910,7 +910,7 @@ static void setup_posted_irte(
>  struct iremap_entry *new_ire, const struct iremap_entry *old_ire,
>  const struct pi_desc *pi_desc, const uint8_t gvec)
>  {
> -memset(new_ire, sizeof(*new_ire), 0);
> +memset(new_ire, 0, sizeof(*new_ire));

Thanks for the fix.

Acked-by: Feng Wu 

Thanks,
Feng

> 
>  /*
>   * 'im' filed decides whether the irte is in posted format (with value 1)
> --
> 2.1.4


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

[Xen-devel] [linux-3.14 test] 65633: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 64562

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 64562
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 64562
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 64562
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 64562
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 64562

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux5d7b0fcc26d66db767a477574effc764022c19ac
baseline version:
 linux769b79eb206ad5b0249a08665fefb913c3d1998e

Last test of basis64562  2015-11-17 09:53:45 Z   23 days
Testing same since65633  2015-12-09 19:33:10 Z1 days1 attempts


People who touched revisions under test:
  Aleksander Morgado 
  Amitkumar Karwar 
  Andrew Cooper 
  Ani Sinha 
  Bjørn Mork 
  Borislav Petkov 
  Carol L Soto 
  Catalin Marinas 
  Clemens Ladisch 
  Dan Carpenter 
  David Herrmann 
  David S. Miller 
  David Woodhouse 
  David Woodhouse 
  Dmitry Tunin 
  Eric Dumazet 
  Felipe Balbi 
  Florian Fainelli 
  Francesco Ruggeri 
  Francesco Ruggeri 
  Greg Kroah-Hartman 
  Gregory CLEMENT 
  Guillaume Nault 
  Jack Morgenstein 
  Jason Wang 
  Jiri Slaby 
  Johan Hovold 
  Johannes Berg 
  Kalle Valo 
  Krzysztof Mazur 
  Larry Finger 
  Marc Kleine-Budde 
  Marcel Holtmann 
  Marek Szyprowski 
  Matt Fleming 
  Maxime Ripard 
  Michael S. Tsirkin 
  Mirza Krak 
  Or Gerlitz 
  Paolo Bonzini 
  Pete Zaitcev 
  Peter Ujfalusi 
  Phil Reid 
  Richard Cochran 
  Robin Murphy 
  Russell King 
  Rusty Russell 
  Santosh Shilimkar 
  Sasha Levin 
  Sowmini Varadhan 
  Takashi Iwai 
  Thomas Gleixner 
  Uwe Kleine-König 
  Vinod Koul 
  Will Deacon 

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

[Xen-devel] [PATCH v3] smpboot: Add CPU hotplug state variables instead of reusing CPU states

[Daniel Wagner]

The cpu hotplug state machine in smpboot.c is reusing the states from
cpu.h. That is confusing when it comes to the CPU_DEAD_FROZEN usage.
Paul explained to me that he was in need of an additional state
for destinguishing between a CPU error states. For this he just
picked CPU_DEAD_FROZEN.

8038dad7e888581266c76df15d70ca457a3c5910 smpboot: Add common code for 
notification from dying CPU
2a442c9c6453d3d043dfd89f2e03a1deff8a6f06 x86: Use common 
outgoing-CPU-notification code

Instead of reusing the states, let's add new definition inside
the smpboot.c file with explenation what those states
mean. Thanks Paul for providing them.

Signed-off-by: Daniel Wagner 
Reviewed-by: "Paul E. McKenney" 
Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
---

v3:
 - initialize cpu_hotplug_state correctly. Bug found by l...@intel.com

 arch/x86/xen/smp.c  |  4 +--
 include/linux/cpu.h |  3 +-
 kernel/smpboot.c| 84 -
 3 files changed, 68 insertions(+), 23 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3f4ebf0..804bf5c 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -495,7 +495,7 @@ static int xen_cpu_up(unsigned int cpu, struct task_struct 
*idle)
rc = HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL);
BUG_ON(rc);
 
-   while (cpu_report_state(cpu) != CPU_ONLINE)
+   while (!cpu_check_online(cpu))
HYPERVISOR_sched_op(SCHEDOP_yield, NULL);
 
return 0;
@@ -767,7 +767,7 @@ static int xen_hvm_cpu_up(unsigned int cpu, struct 
task_struct *tidle)
 * This can happen if CPU was offlined earlier and
 * offlining timed out in common_cpu_die().
 */
-   if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
+   if (cpu_check_timeout(cpu)) {
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
}
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index d2ca8c3..b3cb92d 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -282,7 +282,8 @@ void arch_cpu_idle_dead(void);
 
 DECLARE_PER_CPU(bool, cpu_dead_idle);
 
-int cpu_report_state(int cpu);
+int cpu_check_online(int cpu);
+int cpu_check_timeout(int cpu);
 int cpu_check_up_prepare(int cpu);
 void cpu_set_state_online(int cpu);
 #ifdef CONFIG_HOTPLUG_CPU
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index d264f59..85391ef 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -370,19 +370,63 @@ int smpboot_update_cpumask_percpu_thread(struct 
smp_hotplug_thread *plug_thread,
 }
 EXPORT_SYMBOL_GPL(smpboot_update_cpumask_percpu_thread);
 
-static DEFINE_PER_CPU(atomic_t, cpu_hotplug_state) = 
ATOMIC_INIT(CPU_POST_DEAD);
+/* The CPU is offline, and its last offline operation was
+ * successful and proceeded normally.  (Or, alternatively, the
+ * CPU never has come online, as this is the initial state.)
+ */
+#define CPUHP_POST_DEAD0x01
+
+/* The CPU is in the process of coming online.
+ * Simple architectures can skip this state, and just invoke
+ * cpu_set_state_online() unconditionally instead.
+ */
+#define CPUHP_UP_PREPARE   0x02
+
+/* The CPU is now online.  Simple architectures can skip this
+ * state, and just invoke cpu_wait_death() and cpu_report_death()
+ * unconditionally instead.
+ */
+#define CPUHP_ONLINE   0x03
+
+/* The CPU has gone offline, so that it may now be safely
+ * powered off (or whatever the architecture needs to do to it).
+ */
+#define CPUHP_DEAD 0x04
+
+/* The CPU did not go offline in a timely fashion, if at all,
+ * so it might need special processing at the next online (for
+ * example, simply refusing to bring it online).
+ */
+#define CPUHP_BROKEN   0x05
+
+/* The CPU eventually did go offline, but not in a timely
+ * fashion.  If some sort of reset operation is required before it
+ * can be brought online, that reset operation needs to be carried
+ * out at online time.  (Or, again, the architecture might simply
+ * refuse to bring it online.)
+ */
+#define CPUHP_TIMEOUT  0x06
+
+static DEFINE_PER_CPU(atomic_t, cpu_hotplug_state) = 
ATOMIC_INIT(CPUHP_POST_DEAD);
 
 /*
  * Called to poll specified CPU's state, for example, when waiting for
  * a CPU to come online.
  */
-int cpu_report_state(int cpu)
+int cpu_check_online(int cpu)
+{
+   return atomic_read(_cpu(cpu_hotplug_state, cpu)) ==
+  CPUHP_ONLINE;
+}
+
+int cpu_check_timeout(int cpu)
 {
-   return atomic_read(_cpu(cpu_hotplug_state, cpu));
+   return atomic_read(_cpu(cpu_hotplug_state, cpu)) ==
+  CPUHP_TIMEOUT;
 }
 
 /*
- * If CPU has died properly, set its state to CPU_UP_PREPARE and
+ * If CPU has died properly, set its state to CPUHP_UP_PREPARE and
  * return success.  Otherwise, return -EBUSY if the CPU died after
  * cpu_wait_death() timed out.  And yet otherwise again, return 

Re: [Xen-devel] [Xen-staging] [xen staging] tools: Refactor "xentoollog" into its own library

[Ian Campbell]

On Wed, 2015-12-09 at 12:45 +, patch...@xen.org wrote:
> commit c7d3afbb44b47af9103be0b914afd588a84d9e62
> Author: Ian Campbell 
> AuthorDate: Thu Dec 3 11:22:02 2015 +
> Commit: Ian Campbell 
> CommitDate: Wed Dec 9 12:37:00 2015 +
> 
> tools: Refactor "xentoollog" into its own library

This has broken the libvirt build
http://logs.test-lab.xenproject.org/osstest/logs/65648/build-amd64-libvirt/5.ts-libvirt-build.log

/usr/bin/ld: 
../src/.libs/libvirt_driver_libxl_impl.a(libvirt_driver_libxl_impl_la-libxl_conf.o):
 undefined reference to symbol 'xtl_logger_destroy@@VERS_1.0'
/usr/bin/ld: note: 'xtl_logger_destroy@@VERS_1.0' is defined in DSO 
/home/osstest/build.65648.build-amd64-libvirt/xendist/usr/local/lib//libxentoollog.so.1
 so try adding it to the linker command line

/home/osstest/build.65648.build-amd64-libvirt/xendist/usr/local/lib//libxentoollog.so.1:
 could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

I'm sure I had checked libvirt.git for such usage, but it is obviously
there and has been since 2013, so clearly I was wrong.

I have reverted this commit (see below) while I sort out a libvirt patch. 

Note that I have wound back MINIOS_UPSTREAM_REVISION
and QEMU_TRADITIONAL_REVISION here but I have not rewound their respective
master branches. In the event we need to push something to one of these
before this patch lands again Ian and I have agreed we will do the
necessary revert at that point before stacking any new stuff on top.

Ian.

commit ec0712576198633dd7fbfe25290b030d5a23b252
Author: Ian Campbell 
Date:   Thu Dec 10 10:21:34 2015 +

Revert "tools: Refactor "xentoollog" into its own library"

This reverts commit c7d3afbb44b47af9103be0b914afd588a84d9e62 which
broke the libvirt build, since libvirt uses xtl_* and hence needs
updating to link against the new library when necessary.

Signed-off-by: Ian Campbell 

diff --git a/.gitignore b/.gitignore
index a2c85e1..91e1430 100644
--- a/.gitignore
+++ b/.gitignore
@@ -58,7 +58,6 @@ stubdom/gcc-*
 stubdom/include
 stubdom/ioemu
 stubdom/xenstore
-stubdom/libxentoollog-*
 stubdom/libxc-*
 stubdom/lwip-*
 stubdom/mini-os-*
diff --git a/Config.mk b/Config.mk
index 8fc7767..216a642 100644
--- a/Config.mk
+++ b/Config.mk
@@ -255,9 +255,9 @@ MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
 endif
 OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
 QEMU_UPSTREAM_REVISION ?= master
-MINIOS_UPSTREAM_REVISION ?= d25773c8afa2f4dbbb466116daeb60159ddd22bd
-# Thu Dec 3 11:23:25 2015 +
-# mini-os: Include libxentoollog with libxc
+MINIOS_UPSTREAM_REVISION ?= bccd90071e863ec22216a000f1a07035e2f226ff
+# Mon Nov 23 16:34:31 2015 +
+# Add a .gitignore
 
 SEABIOS_UPSTREAM_REVISION ?= rel-1.9.0
 # Tue Nov 17 09:18:44 2015 -0500
@@ -266,9 +266,9 @@ SEABIOS_UPSTREAM_REVISION ?= rel-1.9.0
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
 
-QEMU_TRADITIONAL_REVISION ?= 9fad9ed285835caef64bb8dab352e287ad8538c2
-# Thu Dec 3 11:23:16 2015 +
-# qemu-xen-traditional: Use xentoollog as a separate library
+QEMU_TRADITIONAL_REVISION ?= 91c15bfaec1764ce2896a393eabee1183afe1130
+# Wed Dec 9 11:47:35 2015 +
+# net: pcnet: add check to validate receive data size(CVE-2015-7504)
 
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 9c923dd..e1359cf 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -313,11 +313,6 @@ mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
      ln -sf $(wildcard $(XEN_ROOT)/tools/include/xen-foreign/*) 
include/xen-foreign/ && \
      $(MAKE) DESTDIR= -C include/xen-foreign/ && \
      ( [ -h include/xen/foreign ] || ln -sf ../xen-foreign 
include/xen/foreign )
-   mkdir -p libs-$(XEN_TARGET_ARCH)/toollog
-   [ -h libs-$(XEN_TARGET_ARCH)/toollog/Makefile ] || ( cd 
libs-$(XEN_TARGET_ARCH)/toollog && \
-     ln -sf $(XEN_ROOT)/tools/libs/toollog/include/*.h . && \
-     ln -sf $(XEN_ROOT)/tools/libs/toollog/*.c . && \
-     ln -sf $(XEN_ROOT)/tools/libs/toollog/Makefile . )
    mkdir -p libxc-$(XEN_TARGET_ARCH)
    [ -h libxc-$(XEN_TARGET_ARCH)/Makefile ] || ( cd 
libxc-$(XEN_TARGET_ARCH) && \
      ln -sf $(XEN_ROOT)/tools/libxc/*.h . && \
@@ -341,23 +336,12 @@ $(TARGETS_MINIOS): mini-os-%:
    done
 
 ###
-# libxentoollog
-###
-
-.PHONY: libxentoollog
-libxentoollog: libs-$(XEN_TARGET_ARCH)/toollog/libxentoollog.a
-libs-$(XEN_TARGET_ARCH)/toollog/libxentoollog.a: $(NEWLIB_STAMPFILE)
-   $(MAKE) -C $(XEN_ROOT)/tools/include
-   $(MAKE) DESTDIR= -C $(MINI_OS) links
-   CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) 
DESTDIR= -C libs-$(XEN_TARGET_ARCH)/toollog
-
-###
 # libxc
 ###
 
 

Re: [Xen-devel] [PATCH v2 12/14] x86/hvm: Detect TSC scaling through hvm_funcs

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Monday, December 07, 2015 4:59 AM
> 
> This patch uses hvm_funcs.tsc_scaling_supported instead of the
> architecture code to detect the TSC scaling support.
> 
> Signed-off-by: Haozhong Zhang 
> Acked-by: Jan Beulich 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v2 00/14] Add VMX TSC scaling support

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, December 08, 2015 1:04 AM
> 
> On 07/12/15 10:16, Haozhong Zhang wrote:
> > On 12/07/15 10:03, Egger, Christoph wrote:
> >> Did you consider nested virtualization?
> >> L1 hypervisor may have a different tsc scaling
> >> and L2 guest again may have a different tsc scale ratio.
> >>
> > Oh, I forgot this. I'll check the nested TSC scaling code (mostly
> > about nested SVM TSC ratio, because this patch series does not expose
> > VMX TSC scaling to L1 guest).
> >
> > BTW, are there any practical usage scenarios of nested TSC scaling? If
> > any, I may also need to consider adding nested virtualization support
> > to VMX TSC scaling.
> 
> I would say that there are genuine uses for nested TSC scaling.  An L1
> hypervisor is going to want to scale for the same reasons as the L0
> hypervisor.
> 
> Having said that, if TSC scaling is correctly hidden from the L1 guests,
> I would advise against conflating the two issues together.  i.e. getting
> nested TSC scaling working is not a prerequisite for accepting this series.
> 

Why is nested TSC scaling even an issue? If L0 hypervisors cross hosts
can always guarantee constant TSC frequency through TSC scaling, L1
hypervisor will never see inconstant TSC frequency so why bother to
expose TSC scaling at all?

Thanks
Kevin

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

Re: [Xen-devel] [PATCH v2 00/14] Add VMX TSC scaling support

[Haozhong Zhang]

On 12/10/15 10:43, Tian, Kevin wrote:
> > From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> > Sent: Tuesday, December 08, 2015 1:04 AM
> > 
> > On 07/12/15 10:16, Haozhong Zhang wrote:
> > > On 12/07/15 10:03, Egger, Christoph wrote:
> > >> Did you consider nested virtualization?
> > >> L1 hypervisor may have a different tsc scaling
> > >> and L2 guest again may have a different tsc scale ratio.
> > >>
> > > Oh, I forgot this. I'll check the nested TSC scaling code (mostly
> > > about nested SVM TSC ratio, because this patch series does not expose
> > > VMX TSC scaling to L1 guest).
> > >
> > > BTW, are there any practical usage scenarios of nested TSC scaling? If
> > > any, I may also need to consider adding nested virtualization support
> > > to VMX TSC scaling.
> > 
> > I would say that there are genuine uses for nested TSC scaling.  An L1
> > hypervisor is going to want to scale for the same reasons as the L0
> > hypervisor.
> > 
> > Having said that, if TSC scaling is correctly hidden from the L1 guests,
> > I would advise against conflating the two issues together.  i.e. getting
> > nested TSC scaling working is not a prerequisite for accepting this series.
> > 
> 
> Why is nested TSC scaling even an issue? If L0 hypervisors cross hosts
> can always guarantee constant TSC frequency through TSC scaling, L1
> hypervisor will never see inconstant TSC frequency so why bother to
> expose TSC scaling at all?
>

If exposing TSC scaling to L1, then L0 hypervisor will need to adapt
the TSC scaling ratio set by L1 hypervisor, which has not been done by
this patch series.

Consider an example that the host TSC frequency is freq_0 and
1. L0 Xen sets TSC scaling ratio to a non-identical one ratio_0.

2. Then L1 hypervisor will observe a "host" TSC frequency (freq_0 * ratio_0).

3. If L1 hypervisor sets a TSC scaling ratio ratio_1, it intends to
   provide a guest TSC frequency (freq_0 * ratio_0 * ratio_1).

   However, if ratio_1 is directly written into nested VMCS that is
   later applied to the host CPU, then the L2 guest will get an
   incorrect guest TSC frequency (freq_0 * ratio_1).


Haozhong

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

Re: [Xen-devel] [PATCH v2 06/14] x86/time.c: Scale host TSC in pvclock properly

[Joao Martins]

On 12/10/2015 12:23 AM, Haozhong Zhang wrote:
> On 12/08/15 14:21, Boris Ostrovsky wrote:
>> On 12/07/2015 08:52 PM, Haozhong Zhang wrote:
>>> On 12/07/15 13:14, Boris Ostrovsky wrote:
 On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
> This patch makes the pvclock return the scaled host TSC and
> corresponding scaling parameters to HVM domains if guest TSC is not
> emulated and TSC scaling is enabled.
>
> Signed-off-by: Haozhong Zhang 
 +Joao who has been staring at this code.

Apologies for late response but I was out in the beginning of the week and was
still catching up.

 Joao, can you run this series through your test with non-native frequency?
 (http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg00683.html
 provides an interface to set it in config file).

OK, I will run it through my time warp tests.


> ---
>  xen/arch/x86/time.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> index 95df4f1..732d1e9 100644
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -815,10 +815,18 @@ static void __update_vcpu_system_time(struct vcpu 
> *v, int force)
>  }
>  else
>  {
> -tsc_stamp = t->local_tsc_stamp;
> -
> -_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
> -_u.tsc_shift = (s8)t->tsc_scale.shift;
> +if ( is_hvm_domain(d) && cpu_has_tsc_ratio )
> +{
> +tsc_stamp= hvm_funcs.scale_tsc(v, 
> t->local_tsc_stamp);
> +_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
> +_u.tsc_shift = d->arch.vtsc_to_ns.shift;
 I am not sure this is correct (which is why I asked Joao to look at this 
 and
 test). The scaler below is calculated as result of TSC calibration across
 physical CPUs and what you use above (vtsc_to_ns) is an uncalibrated value.

>>> Because guest TSC is synchronized among all vcpus of a domain, I think
>>> it's safe to use d->arch.vtsc_to_ns here.
>>
>> This is only guaranteed if we have constant/reliable TSC. So perhaps you
>> should set tsc_scaling_supported only when either (or both?) of these TSC
>> properties are true. Which is probably the case anyway but may be worth
>> explicitly checking in start_svm/vmx?
> 
> Yes, I'll add the additional check in the next version.
> 
I believe constant TSC to be the only feature that is checked on
local_time_calibration.

>> (and use tsc_scaling_supported instead
>> of cpu_has_tsc_ratio in the 'if' statement)
> 
> This one is only for bug fix, so tsc_scaling_supported has not been
> introduced. Patch 8 introduces tsc_scaling_supported and patch 12
> replaces all cpu_has_tsc_ratio with it.
> 
>>
>> And just like I asked in the previous email --- should we then use the same
>> scaler (which would be vtsc_to_ns) in both cases? At least for guests in HVM
>> containers (it may work for PV guests as well, but it would need to be
>> confirmed).
>>
> Yes, but I'll check PV code first.
> 
>> Also, I noticed that this routine uses is_hvm_domain(). I think it should be
>> has_hvm_container_domain().
>>
> forgot updating here, will do in the next version.
> 
> Haozhong
> 
> ___
> 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 v2 08/14] x86/hvm: Collect information of TSC scaling ratio

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Monday, December 07, 2015 4:59 AM
ratio
> 
> Both VMX TSC scaling and SVM TSC ratio use the 64-bit TSC scaling ratio,
> but the number of fractional bits of the ratio is different between VMX
> and SVM. This patch adds the architecture code to collect the number of
> fractional bits and other related information into fields of struct
> hvm_function_table so that they can be used in the common code.
> 
> Signed-off-by: Haozhong Zhang 

Reviewed-by: Kevin Tian , with one comment


> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> index aba63ab..8b10a67 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -100,6 +100,18 @@ struct hvm_function_table {
>  unsigned int hap_capabilities;
> 
>  /*
> + * Parameters of hardware-assisted TSC scaling.
> + */
> +/* is TSC scaling supported? */
> +bool_t   tsc_scaling_supported;
> +/* number of bits of the fractional part of TSC scaling ratio */
> +uint8_t  tsc_scaling_ratio_frac_bits;
> +/* default TSC scaling ratio (no scaling) */
> +uint64_t default_tsc_scaling_ratio;
> +/* maxmimum-allowed TSC scaling ratio */

maxmimum -> maximum

> +uint64_t max_tsc_scaling_ratio;
> +
> +/*
>   * Initialise/destroy HVM domain/vcpu resources
>   */
>  int  (*domain_initialise)(struct domain *d);
> --
> 2.6.3


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

Re: [Xen-devel] [PATCH v2 13/14] vmx: Add VMX RDTSC(P) scaling support

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Monday, December 07, 2015 4:59 AM
>
> This patch adds the initialization and setup code for VMX TSC scaling.
> 
> Signed-off-by: Haozhong Zhang 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v2 09/14] x86/hvm: Setup TSC scaling ratio

[Zhang, Haozhong]

On 12/10/15 18:27, Tian, Kevin wrote:
> > From: Zhang, Haozhong
> > Sent: Monday, December 07, 2015 4:59 AM
> > 
> > This patch adds a field tsc_scaling_ratio in struct hvm_vcpu to
> > record the TSC scaling ratio, and sets it up when tsc_set_info() is
> > called for a vcpu or when a vcpu is restored or reset.
> > 
> > Signed-off-by: Haozhong Zhang 
> > ---
> >  xen/arch/x86/hvm/hvm.c| 30
> > ++
> >  xen/arch/x86/hvm/svm/svm.c|  6 --
> >  xen/arch/x86/time.c   | 13 -
> >  xen/include/asm-x86/hvm/hvm.h |  5 +
> >  xen/include/asm-x86/hvm/svm/svm.h |  3 ---
> >  xen/include/asm-x86/hvm/vcpu.h|  2 ++
> >  xen/include/asm-x86/math64.h  | 30
> > ++
> >  7 files changed, 83 insertions(+), 6 deletions(-)
> >  create mode 100644 xen/include/asm-x86/math64.h
> > 
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 0e63c33..52a0ef8 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -65,6 +65,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -301,6 +302,29 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
> >  return 1;
> >  }
> > 
> > +void hvm_setup_tsc_scaling(struct vcpu *v)
> > +{
> > +u64 ratio;
> > +
> > +if ( !hvm_funcs.tsc_scaling_supported )
> > +return;
> > +
> > +/*
> > + * The multiplication of the first two terms may overflow a 64-bit
> > + * integer, so use mul_u64_u32_div() instead to keep precision.
> > + */
> > +ratio = mul_u64_u32_div(1ULL << hvm_funcs.tsc_scaling_ratio_frac_bits,
> > +v->domain->arch.tsc_khz, cpu_khz);
> > +
> > +if ( ratio == 0 || ratio > hvm_funcs.max_tsc_scaling_ratio )
> > +return;
> 
> How will you check such error in other places? tsc_scaling_ratio is
> left w/ default value, while if you don't detect the issue that that
> ratio will be used for wrong scale...
>

The intention here is to fall back to the default ratio so that it
would work like no TSC scaling is used. However, I forgot here to fall
back v->domain->arch.tsc_khz and others to default values (i.e. values
used when no TSC scaling). I'll add them in the next version.

Haozhong

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

Re: [Xen-devel] [PATCH v10 0/7] Add VT-d Posted-Interrupts support

[Tian, Kevin]

> From: Feng Wu
> Sent: Thursday, December 03, 2015 4:35 PM
> 
> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> With VT-d Posted-Interrupts enabled, external interrupts from
> direct-assigned devices can be delivered to guests without VMM
> intervention when guest is running in non-root mode.
> 
> You can find the VT-d Posted-Interrtups Spec. in the following URL:
> http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-direct
> ed-io-spec.html
> 
> Feng Wu (17):
>  r   VT-d Posted-intterrupt (PI) design
>  ra  vmx: Suppress posting interrupts when 'SN' is set
>  r   vt-d: Add API to update IRTE when VT-d PI is used
>   a  Update IRTE according to guest interrupt config changes
>   a  vmx: Properly handle notification event when vCPU is running
>  vmx: VT-d posted-interrupt core logic handling
>  ra  Add a command line parameter for VT-d posted-interrupts
> 
>  r = has been 'Reviewed-by'
>  a = has been 'Acked-by'
> 
> Feng Wu (7):
>   VT-d Posted-intterrupt (PI) design
>   vmx: Suppress posting interrupts when 'SN' is set
>   vt-d: Add API to update IRTE when VT-d PI is used
>   Update IRTE according to guest interrupt config changes
>   vmx: Properly handle notification event when vCPU is running
>   vmx: VT-d posted-interrupt core logic handling
>   Add a command line parameter for VT-d posted-interrupts

Only 7 patches in this series because other 10 have been checked in?

Thanks
Kevin 

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

Re: [Xen-devel] [PATCH v2 14/14] docs: Add descriptions of TSC scaling in xl.cfg and tscmode.txt

[Zhang, Haozhong]

On 12/10/15 18:40, Tian, Kevin wrote:
> > From: Zhang, Haozhong
> > Sent: Monday, December 07, 2015 4:59 AM
> g and tscmode.txt
> > 
> > Signed-off-by: Haozhong Zhang 
> > ---
> >  docs/man/xl.cfg.pod.5 | 15 ++-
> >  docs/misc/tscmode.txt | 14 ++
> >  2 files changed, 28 insertions(+), 1 deletion(-)
> > 
> > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> > index 2aca8dd..7e19a9b 100644
> > --- a/docs/man/xl.cfg.pod.5
> > +++ b/docs/man/xl.cfg.pod.5
> > @@ -1313,9 +1313,18 @@ deprecated. Options are:
> > 
> >  =item B<"default">
> > 
> > -Guest rdtsc/p executed natively when monotonicity can be guaranteed
> > +Guest rdtsc/p is executed natively when monotonicity can be guaranteed
> >  and emulated otherwise (with frequency scaled if necessary).
> > 
> > +If a HVM container in B TSC mode is not migrated from other hosts
> 
> "migrated from" -> "migrated to"?
>

I mean "migrated from" here. If the current host supports TSC scaling
and a domain is migrated from another host w/ different host TSC
frequency, then domain may have a different guest TSC frequency than
the current host. Thus, "not migrated from other hosts" is used here
to eliminate such case.

> > +and the host TSC monotonicity can be guaranteed, the guest and host TSC
> > +frequencies will be the same.
> > +
> > +If a HVM container in B TSC mode is migrated to a host that can
> > +guarantee the TSC monotonicity and supports Intel VMX TSC scaling/AMD SVM
> 
> and -> or? Do we think TSC scaling a must to ensure TSC monotonicity? It comes
> to the rescue only when host can't ensure monotonicity...
>

No, I intend to describe the guest behavior when hardware TSC scaling is used.

Really I should say "_host_ TSC monotonicity" here.

> > +TSC ratio, guest rdtsc/p will still execute natively after migration and 
> > the
> > +guest TSC frequencies before and after migration will be the same.
> 
> will be the same before and after migration.
>

will modify in the next version.

> > +
> >  =item B<"always_emulate">
> > 
> >  Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
> > @@ -1337,6 +1346,10 @@ determine when a restore/migration has occurred and
> > assumes guest
> >  obtains/uses pvclock-like mechanism to adjust for monotonicity and
> >  frequency changes.
> > 
> > +If a HVM container in B TSC mode can execute both guest
> > +rdtsc and guest rdtscp natively, then the guest TSC frequency will be
> > +determined in the similar way to that of B TSC mode.
> > +
> >  =back
> > 
> >  Please see F for more information on this option.
> > diff --git a/docs/misc/tscmode.txt b/docs/misc/tscmode.txt
> > index e8c84e8..f3b70be 100644
> > --- a/docs/misc/tscmode.txt
> > +++ b/docs/misc/tscmode.txt
> > @@ -297,3 +297,17 @@ and also much faster than nearly all OS-provided time
> > mechanisms.
> >  While pvrtscp is too complex for most apps, certain enterprise
> >  TSC-sensitive high-TSC-frequency apps may find it useful to
> >  obtain a significant performance gain.
> > +
> > +Hardware TSC Scaling
> > +
> > +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read
> > +by guest rdtsc/p increasing in the different frequency than the host
> 
> "in the different" -> "in a different"
>

will modify

> > +TSC frequency.
> > +
> > +For a HVM container is in default TSC mode (tsc_mode=0) or PVRDTSCP
> 
> For a HVM container *which* is
>

stupid error... will modify

> > +mode (tsc_mode=3) and can execute both guest rdtsc and rdtscp
> > +natively, if it is not migrated from other hosts, the guest and host
> > +TSC frequencies will be the same. 
> 
> "the guest and host TSC frequencies remain the same if the guest is
> not migrated to other host."
> 
> and the condition is that the host supports constant TSC feature.
>

Yes, I'll modify in the next version.

Thanks,
Haozhong

> > If it is migrated to a host
> > +supporting Intel VMX TSC scaling/AMD SVM TSC ratio and can still
> > +execute guest rdtsc and rdtscp natively, the guest TSC frequencies
> > +before and after migration will be the same.
> > --
> > 2.6.3
> 

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

[Xen-devel] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.

[Ian Campbell]

Upstream Xen is in the process of splitting the (stable API) xtl_*
interfaces out from the (unstable API) libxenctrl library and into a
new (stable API) libxentoollog.

In order to be compatible with Xen both before and after this
transition check for xtl_createlogger_stdiostream in a libxentoollog
library and use it if present. If it is not present assume it is in
libxenctrl.

Compile tested on Xen 4.6 and a development tree with the split in
place.

Signed-off-by: Ian Campbell 
---
I'm waiting on applying the upstream change until downstreams are
prepared for this. The latest upstream patch is
http://lists.xen.org/archives/html/xen-devel/2015-12/msg00454.html
which had to be reverted because I had somehow not properly checked if
libvirt used this interface
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01153.html

It might be nice to get this into 1.3.0 so that supports Xen 4.7 out
of the box? Not sure what the libvirt stable backport policy is but it
might also be good to eventually consider it for that?
---
 configure.ac | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 98cf210..b641cc7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -883,7 +883,6 @@ if test "$with_libxl" != "no" ; then
 PKG_CHECK_MODULES([LIBXL], [xenlight], [
  LIBXL_FIRMWARE_DIR=`$PKG_CONFIG --variable xenfirmwaredir xenlight`
  LIBXL_EXECBIN_DIR=`$PKG_CONFIG --variable libexec_bin xenlight`
- LIBXL_LIBS="$LIBXL_LIBS -lxenctrl"
  with_libxl=yes
 ], [LIBXL_FOUND=no])
 if test "$LIBXL_FOUND" = "no"; then
@@ -896,7 +895,7 @@ if test "$with_libxl" != "no" ; then
 LIBS="$LIBS $LIBXL_LIBS"
 AC_CHECK_LIB([xenlight], [libxl_ctx_alloc], [
 with_libxl=yes
-LIBXL_LIBS="$LIBXL_LIBS -lxenlight -lxenctrl"
+LIBXL_LIBS="$LIBXL_LIBS -lxenlight"
 ],[
 if test "$with_libxl" = "yes"; then
 fail=1
@@ -924,6 +923,14 @@ if test "$with_libxl" = "yes"; then
 if test "x$LIBXL_EXECBIN_DIR" != "x"; then
 AC_DEFINE_UNQUOTED([LIBXL_EXECBIN_DIR], ["$LIBXL_EXECBIN_DIR"], 
[directory containing Xen libexec binaries])
 fi
+dnl Check if the xtl_* infrastructure is in libxentoollog
+dnl (since Xen 4.7) if not then assume it is in libxenctrl
+dnl (as it was for 4.6 and earler)
+AC_CHECK_LIB([xentoollog], [xtl_createlogger_stdiostream], [
+LIBXL_LIBS="$LIBXL_LIBS -lxentoollog"
+],[
+LIBXL_LIBS="$LIBXL_LIBS -lxenctrl"
+])
 fi
 AM_CONDITIONAL([WITH_LIBXL], [test "$with_libxl" = "yes"])
 
-- 
2.1.4


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

[Xen-devel] [PATCH v10 1/5] libxl: export some functions for pvusb use

[George Dunlap]

From: Chunyan Liu 

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: Wei Liu 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxl/libxl.c  | 5 ++---
 tools/libxl/libxl_internal.h | 3 +++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bd3aac8..36dc37d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2033,7 +2033,7 @@ out:
 }
 
 /* common function to get next device id */
-static int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
+int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
 {
 char *dompath, **l;
 unsigned int nb;
@@ -2052,8 +2052,7 @@ static int libxl__device_nextid(libxl__gc *gc, uint32_t 
domid, char *device)
 return nextid;
 }
 
-static int libxl__resolve_domid(libxl__gc *gc, const char *name,
-uint32_t *domid)
+int libxl__resolve_domid(libxl__gc *gc, const char *name, uint32_t *domid)
 {
 if (!name)
 return 0;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d2bda0a..83a0f34 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1167,6 +1167,9 @@ _hidden int libxl__init_console_from_channel(libxl__gc 
*gc,
  libxl__device_console *console,
  int dev_num,
  libxl_device_channel *channel);
+_hidden int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device);
+_hidden int libxl__resolve_domid(libxl__gc *gc, const char *name,
+ uint32_t *domid);
 
 /*
  * For each aggregate type which can be used as an input we provide:
-- 
2.1.4


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

[Xen-devel] [PATCH v10 2/5] libxl_utils: add internal function to read sysfs file contents

[George Dunlap]

From: Chunyan Liu 

Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.

Signed-off-by: Chunyan Liu 
---
v10:
 - Rebased to staging

CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxl/libxl_internal.h |  4 +++
 tools/libxl/libxl_utils.c| 77 
 2 files changed, 81 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 83a0f34..37a6752 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4024,6 +4024,10 @@ void libxl__bitmap_copy_best_effort(libxl__gc *gc, 
libxl_bitmap *dptr,
 
 int libxl__count_physical_sockets(libxl__gc *gc, int *sockets);
 
+_hidden int libxl__read_sysfs_file_contents(libxl__gc *gc,
+const char *filename,
+void **data_r,
+int *datalen_r);
 
 #define LIBXL_QEMU_USER_PREFIX "xen-qemuuser"
 #define LIBXL_QEMU_USER_BASE   LIBXL_QEMU_USER_PREFIX"-domid"
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index e42422a..7f612a6 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -396,6 +396,83 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char 
*filename,
 return e;
 }
 
+int libxl__read_sysfs_file_contents(libxl__gc *gc, const char *filename,
+void **data_r, int *datalen_r)
+{
+FILE *f = 0;
+uint8_t *data = 0;
+int datalen = 0;
+int e;
+struct stat stab;
+ssize_t rs;
+
+f = fopen(filename, "r");
+if (!f) {
+if (errno == ENOENT) return ENOENT;
+LOGE(ERROR, "failed to open %s", filename);
+goto xe;
+}
+
+if (fstat(fileno(f), )) {
+LOGE(ERROR, "failed to fstat %s", filename);
+goto xe;
+}
+
+if (!S_ISREG(stab.st_mode)) {
+LOGE(ERROR, "%s is not a plain file", filename);
+errno = ENOTTY;
+goto xe;
+}
+
+if (stab.st_size > INT_MAX) {
+LOG(ERROR, "file %s is far too large", filename);
+errno = EFBIG;
+goto xe;
+}
+
+datalen = stab.st_size;
+
+if (stab.st_size && data_r) {
+data = libxl__malloc(gc, datalen);
+if (!data) goto xe;
+
+/* For sysfs file, datalen is always PAGE_SIZE. 'read'
+ * will return the number of bytes of the actual content,
+ * rs <= datalen is expected.
+ */
+rs = fread(data, 1, datalen, f);
+if (rs < datalen) {
+if (ferror(f)) {
+LOGE(ERROR, "failed to read %s", filename);
+goto xe;
+}
+
+datalen = rs;
+data = libxl__realloc(gc, data, datalen);
+if (!data)
+goto xe;
+}
+}
+
+if (fclose(f)) {
+f = 0;
+LOGE(ERROR, "failed to close %s", filename);
+goto xe;
+}
+
+if (data_r) *data_r = data;
+if (datalen_r) *datalen_r = datalen;
+
+return 0;
+
+ xe:
+e = errno;
+assert(e != ENOENT);
+if (f) fclose(f);
+return e;
+}
+
+
 #define READ_WRITE_EXACTLY(rw, zero_is_eof, constdata)\
   \
   int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, \
-- 
2.1.4


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

[Xen-devel] [PATCH v10 5/5] domcreate: support pvusb in configuration file

[George Dunlap]

From: Chunyan Liu 

Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.

One could specify usb controllers and usb devices in config file
like this:
usbctrl=['version=2,ports=4', 'version=1, ports=4', ]
usbdev=['hostbus=2, hostaddr=1, controller=0,port=1', ]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
---
v10:
 - Fixed minor typo

CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
---
 docs/man/xl.cfg.pod.5| 84 
 tools/libxl/libxl_create.c   | 73 --
 tools/libxl/libxl_device.c   |  4 +++
 tools/libxl/libxl_internal.h |  8 +
 tools/libxl/xl_cmdimpl.c | 55 -
 5 files changed, 220 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 3b695bd..db5a443 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -722,6 +722,90 @@ Note this may be overridden by rdm_policy option in PCI 
device configuration.
 
 =back
 
+=item 

Re: [Xen-devel] [PATCH v10 3/5] libxl: add pvusb API

[George Dunlap]

On 10/12/15 12:05, George Dunlap wrote:
> From: Chunyan Liu 
> 
> Add pvusb APIs, including:
>  - attach/detach (create/destroy) virtual usb controller.
>  - attach/detach usb device
>  - list usb controller and usb devices
>  - some other helper functions
> 
> Signed-off-by: Chunyan Liu 
> Signed-off-by: Simon Cao 
> Signed-off-by: George Dunlap 

Attached is a diff of v9 -> v10 for convenience.

One remaining question I had regarding this patch...

> +static int usbdev_get_all_interfaces(libxl__gc *gc, const char *busid,
> + char ***intfs, int *num)
> +{
> +DIR *dir;
> +char *buf;
> +int rc;
> +
> +*intfs = NULL;
> +*num = 0;
> +
> +buf = GCSPRINTF("%s:", busid);
> +
> +dir = opendir(SYSFS_USB_DEV);
> +if (!dir) {
> +LOGE(ERROR, "opendir failed: '%s'", SYSFS_USB_DEV);
> +return ERROR_FAIL;
> +}
> +
> +size_t need = offsetof(struct dirent, d_name) +
> +pathconf(SYSFS_USB_DEV, _PC_NAME_MAX) + 1;
> +struct dirent *de_buf = libxl__zalloc(gc, need);

Is this thing with manually calculating the size of the structure really
necessary?  Could we not just declare "struct dirent de_buf" on the stack?

If it is necessary, it would be better to have it inside a function or
macro called "alloc_dirent" or something like that.

 -George

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a479465..26cd5fa 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3203,7 +3203,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc *egc,
 aodev->dev = device;
 aodev->callback = local_device_detach_cb;
 aodev->force = 0;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 return;
 }
 
@@ -4144,36 +4144,6 @@ out:
 return rc;
 }
 
-static void libxl__initiate_device_disk_remove(libxl__egc *egc,
-   libxl__ao_device *aodev)
-{
-return libxl__initiate_device_remove(egc, aodev);
-}
-
-static void libxl__initiate_device_nic_remove(libxl__egc *egc,
-  libxl__ao_device *aodev)
-{
-return libxl__initiate_device_remove(egc, aodev);
-}
-
-static void libxl__initiate_device_vtpm_remove(libxl__egc *egc,
-   libxl__ao_device *aodev)
-{
-return libxl__initiate_device_remove(egc, aodev);
-}
-
-static void libxl__initiate_device_vkb_remove(libxl__egc *egc,
-  libxl__ao_device *aodev)
-{
-return libxl__initiate_device_remove(egc, aodev);
-}
-
-static void libxl__initiate_device_vfb_remove(libxl__egc *egc,
-  libxl__ao_device *aodev)
-{
-return libxl__initiate_device_remove(egc, aodev);
-}
-
 /**/
 
 /* Macro for defining device remove/destroy functions in a compact way */
@@ -4191,7 +4161,7 @@ static void libxl__initiate_device_vfb_remove(libxl__egc *egc,
  * libxl_device_usbctrl_remove
  * libxl_device_usbctrl_destroy
  */
-#define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\
+#define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\
 int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
 uint32_t domid, libxl_device_##type *type,  \
 const libxl_asyncop_how *ao_how)\
@@ -4211,13 +4181,19 @@ static void libxl__initiate_device_vfb_remove(libxl__egc *egc,
 aodev->dev = device;\
 aodev->callback = device_addrm_aocomplete;  \
 aodev->force = f;   \
-libxl__initiate_device_##type##_remove(egc, aodev); \
+libxl__initiate_device_##remtype##_remove(egc, aodev);  \
 \
 out:\
-if (rc) return AO_CREATE_FAIL(rc);\
+if (rc) return AO_CREATE_FAIL(rc);  \
 return AO_INPROGRESS;   \
 }
 
+#define DEFINE_DEVICE_REMOVE(type, removedestroy, f) \
+DEFINE_DEVICE_REMOVE_EXT(type, generic, removedestroy, f)
+
+#define DEFINE_DEVICE_REMOVE_CUSTOM(type, removedestroy, f)  \
+DEFINE_DEVICE_REMOVE_EXT(type, type, removedestroy, f)
+
 /* Define all remove/destroy functions and undef the macro */
 
 /* disk */
@@ -4242,8 +4218,8 @@ DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
 DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
 
 /* usbctrl */
-DEFINE_DEVICE_REMOVE(usbctrl, remove, 0)

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   3 host-install(3) broken REGR. vs. 64766
 build-armhf   5 xen-build fail REGR. vs. 64766

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 64766

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

version targeted for testing:
 xen  62dc4c1a96eb9b40ec23bdd1656ece913f540871
baseline version:
 xen  602506b3efa8ddeae2976ec9f15d91366f823919

Last test of basis64766  2015-11-18 17:41:11 Z   21 days
Failing since 65556  2015-12-08 13:46:29 Z1 days2 attempts
Testing same since65612  2015-12-09 09:30:57 Z1 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-armhf  fail
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 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  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  broken  
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 

Re: [Xen-devel] [PATCH v2 11/14] x86/hvm: Move saving/loading vcpu's TSC to common code

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Monday, December 07, 2015 4:59 AM
common code
> 
> Both VMX and SVM save/load vcpu's TSC when saving/loading vcpu's
> context, so this patch moves saving/loading vcpu's TSC to the common
> functions hvm_[save|load]_cpu_ctxt().
> 
> Signed-off-by: Haozhong Zhang 
> Acked-by: Jan Beulich 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling

[Tian, Kevin]

> From: Wu, Feng
> Sent: Thursday, December 03, 2015 4:36 PM
> 
> This is the core logic handling for VT-d posted-interrupts. Basically it
> deals with how and when to update posted-interrupts during the following
> scenarios:
> - vCPU is preempted
> - vCPU is slept
> - vCPU is blocked
> 
> When vCPU is preempted/slept, we update the posted-interrupts during
> scheduling by introducing two new architecutral scheduler hooks:
> vmx_pi_switch_from() and vmx_pi_switch_to(). When vCPU is blocked, we
> introduce a new architectural hooks: arch_vcpu_block() to update

hooks -> hook

> posted-interrupts descriptor.
> 
> Besides that, before VM-entry, we will make sure the 'NV' filed is set
> to 'posted_intr_vector' and the vCPU is not in any blocking lists, which
> is needed when vCPU is running in non-root mode. The reason we do this check
> is because we change the posted-interrupts descriptor in vcpu_block(),
> however, we don't change it back in vcpu_unblock() or when vcpu_block()
> directly returns due to event delivery (in fact, we don't need to do it
> in the two places, that is why we do it before VM-Entry).
> 
> When we handle the lazy context switch for the following two scenarios:
> - Preempted by a tasklet, which uses in an idle context.
> - the prev vcpu is in offline and no new available vcpus in run queue.
> We don't change the 'SN' bit in posted-interrupt descriptor, this
> may incur spurious PI notification events, but since PI notification
> event is only sent when 'ON' is clear, and once the PI notification
> is sent, ON is set by hardware, hence no more notification events
> before 'ON' is clear. Besides that, spurious PI notification events are
> going to happen from time to time in Xen hypervisor, such as, when
> guests trap to Xen and PI notification event happens, there is
> nothing Xen actually needs to do about it, the interrupts will be
> delivered to guest atht the next time we do a VMENTRY.
> 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Kevin Tian 
> CC: George Dunlap 
> CC: Dario Faggioli 
> Suggested-by: Yang Zhang 
> Suggested-by: Dario Faggioli 
> Suggested-by: George Dunlap 
> Suggested-by: Jan Beulich 
> Signed-off-by: Feng Wu 
> ---
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 6c2b512..3368cf2 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -7019,6 +7019,12 @@ void hvm_domain_soft_reset(struct domain *d)
>  hvm_destroy_all_ioreq_servers(d);
>  }
> 
> +void arch_vcpu_block(struct vcpu *v)
> +{
> +if ( v->arch.vcpu_block )
> +v->arch.vcpu_block(v);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index 000d06e..0f23fce 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -676,6 +676,8 @@ int vmx_cpu_up(void)
>  if ( cpu_has_vmx_vpid )
>  vpid_sync_all();
> 
> +vmx_pi_per_cpu_init(cpu);
> +
>  return 0;
>  }
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 39dc500..0d9462e 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -83,7 +83,131 @@ static int vmx_msr_write_intercept(unsigned int msr, 
> uint64_t
> msr_content);
>  static void vmx_invlpg_intercept(unsigned long vaddr);
>  static int vmx_vmfunc_intercept(struct cpu_user_regs *regs);
> 
> +/*
> + * We maintain a per-CPU linked-list of vCPU, so in PI wakeup handler we

vCPU -> vCPUs

> + * can find which vCPU should be woken up.
> + */
> +static DEFINE_PER_CPU(struct list_head, pi_blocked_vcpu);
> +static DEFINE_PER_CPU(spinlock_t, pi_blocked_vcpu_lock);
> +
>  uint8_t __read_mostly posted_intr_vector;
> +uint8_t __read_mostly pi_wakeup_vector;
> +
> +void vmx_pi_per_cpu_init(unsigned int cpu)
> +{
> +INIT_LIST_HEAD(_cpu(pi_blocked_vcpu, cpu));
> +spin_lock_init(_cpu(pi_blocked_vcpu_lock, cpu));
> +}
> +
> +void vmx_vcpu_block(struct vcpu *v)
> +{
> +unsigned long flags;
> +struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
> +
> +if ( !has_arch_pdevs(v->domain) )
> +return;
> +
> +ASSERT(v->arch.hvm_vmx.pi_block_cpu == NR_CPUS);
> +
> +/*
> + * The vCPU is blocking, we need to add it to one of the per pCPU lists.
> + * We save v->processor to v->arch.hvm_vmx.pi_block_cpu and use it for
> + * the per-CPU list, we also save it to posted-interrupt descriptor and
> + * make it as the destination of the wake-up notification event.

the 2nd piece - "we also save it to posted-interrupt descriptor" is not
reflected within this function. Do you mean "we have saved it to..."
or "we will save it later to..." in other places?

> + */
> +

Re: [Xen-devel] [PATCHv6] 03/28] build: use generated Kconfig options for Xen

[Jan Beulich]

>>> On 09.12.15 at 21:53,  wrote:
> On 12/9/15 2:34 PM, Doug Goldstein wrote:
>> So you would like me to add code into xen/Makefile to detect if someone
>> ran "make kexec=X" or added "kexec=X" into top level .config and give
>> them a meaningful error message to tell them to use "make config" instead?
> 
> So I need to clarify here. If you do want this, then do you have a
> suggestion how I can detect when someone uses the .config file to
> override this? $(origin) returns the same value for me in that case. For
> "make kexec=n" I can detect that with $(origin).

Well, it would seem to me that checking for just the non-default case
would be sufficient, i.e. without any $(origin ...), but just looking at
the values.

Jan


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

[Xen-devel] [xen-unstable-smoke test] 65662: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ff841cead287d7913901ba5c4e7628a6958b5bea
baseline version:
 xen  a841b1b1286d122fd472b43db3c423b9876262e5

Last test of basis65617  2015-12-09 12:02:58 Z1 days
Testing same since65622  2015-12-09 15:01:14 Z0 days9 attempts


People who touched revisions under test:
  David Scott 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

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



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


Not pushing.


commit ff841cead287d7913901ba5c4e7628a6958b5bea
Author: Jan Beulich 
Date:   Wed Dec 9 13:53:13 2015 +0100

memory: fix XSA-158 fix

For one the uses of domu_max_order and ptdom_max_order were swapped.

And then gcc warns about an unused result of a __must_check function
in the control part of a conditional expression when both other
expressions can be determined by the compiler to produce the same value
(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68039), which happens
when HAS_PASSTHROUGH is undefined (i.e. for ARM on 4.4 and older).

Signed-off-by: Jan Beulich 
Acked-by: Ian Campbell 

commit c7d3afbb44b47af9103be0b914afd588a84d9e62
Author: Ian Campbell 
Date:   Thu Dec 3 11:22:02 2015 +

tools: Refactor "xentoollog" into its own library

In attempting to disaggregate libxenctrl I found that many of the
pieces were going to want access to this library, so split it out (as
it probably should always have been).

Various build adjustments are needed. In particular things which use
xtl_* themselves now need to explicity link against the library.

This has a nice side effect which is that users of libxl no longer
need to link against libxenctrl just to create a logger, which was
counter to the principal that applications using libxl shouldn't be
required to look behind the curtain. This means that xl no longer
links against libxenctrl.

The new library uses a version script to ensure that only expected
symbols are exported and to version them such that ABI guarantees can
be kept in the future.

Signed-off-by: Ian Campbell 
Acked-by: Ian Jackson 
Acked-by: Wei Liu 
[ ijc -- Update QEMU_TRADITIONAL_REVISION and MINIOS_UPSTREAM_REVISION ]

commit 78fb69ad932e012cd27ce9b5b7f8733d08b8061f
Author: Ian Campbell 
Date:   Thu Dec 3 11:22:01 2015 +

tools/Rules.mk: Properly handle libraries with recursive dependencies.

In tree libraries which link against other in tree libraries in a way
which is opaque to their callers need special handling, specifically
correct use of -Wl,-rpath-link for the recusively used libraries.

Currently this is rather simple, but up coming changes are going to
introduce transitive dependencies more than 1 step deep.

Introduce a SHDEPS idiom to contain all the recursive deps for a
library and include those in both LDLIBS (for linking) and SHLIB (for
recursive uses).

Try and document the whole 

Re: [Xen-devel] [PATCH v2 09/14] x86/hvm: Setup TSC scaling ratio

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Monday, December 07, 2015 4:59 AM
> 
> This patch adds a field tsc_scaling_ratio in struct hvm_vcpu to
> record the TSC scaling ratio, and sets it up when tsc_set_info() is
> called for a vcpu or when a vcpu is restored or reset.
> 
> Signed-off-by: Haozhong Zhang 
> ---
>  xen/arch/x86/hvm/hvm.c| 30
> ++
>  xen/arch/x86/hvm/svm/svm.c|  6 --
>  xen/arch/x86/time.c   | 13 -
>  xen/include/asm-x86/hvm/hvm.h |  5 +
>  xen/include/asm-x86/hvm/svm/svm.h |  3 ---
>  xen/include/asm-x86/hvm/vcpu.h|  2 ++
>  xen/include/asm-x86/math64.h  | 30
> ++
>  7 files changed, 83 insertions(+), 6 deletions(-)
>  create mode 100644 xen/include/asm-x86/math64.h
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 0e63c33..52a0ef8 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -65,6 +65,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -301,6 +302,29 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
>  return 1;
>  }
> 
> +void hvm_setup_tsc_scaling(struct vcpu *v)
> +{
> +u64 ratio;
> +
> +if ( !hvm_funcs.tsc_scaling_supported )
> +return;
> +
> +/*
> + * The multiplication of the first two terms may overflow a 64-bit
> + * integer, so use mul_u64_u32_div() instead to keep precision.
> + */
> +ratio = mul_u64_u32_div(1ULL << hvm_funcs.tsc_scaling_ratio_frac_bits,
> +v->domain->arch.tsc_khz, cpu_khz);
> +
> +if ( ratio == 0 || ratio > hvm_funcs.max_tsc_scaling_ratio )
> +return;

How will you check such error in other places? tsc_scaling_ratio is
left w/ default value, while if you don't detect the issue that that
ratio will be used for wrong scale...

Thanks
Kevin

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

Re: [Xen-devel] [PATCH v2 08/14] x86/hvm: Collect information of TSC scaling ratio

[Zhang, Haozhong]

On 12/10/15 18:19, Tian, Kevin wrote:
> > From: Zhang, Haozhong
> > Sent: Monday, December 07, 2015 4:59 AM
> ratio
> > 
> > Both VMX TSC scaling and SVM TSC ratio use the 64-bit TSC scaling ratio,
> > but the number of fractional bits of the ratio is different between VMX
> > and SVM. This patch adds the architecture code to collect the number of
> > fractional bits and other related information into fields of struct
> > hvm_function_table so that they can be used in the common code.
> > 
> > Signed-off-by: Haozhong Zhang 
> 
> Reviewed-by: Kevin Tian , with one comment
> 
> 
> > diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> > index aba63ab..8b10a67 100644
> > --- a/xen/include/asm-x86/hvm/hvm.h
> > +++ b/xen/include/asm-x86/hvm/hvm.h
> > @@ -100,6 +100,18 @@ struct hvm_function_table {
> >  unsigned int hap_capabilities;
> > 
> >  /*
> > + * Parameters of hardware-assisted TSC scaling.
> > + */
> > +/* is TSC scaling supported? */
> > +bool_t   tsc_scaling_supported;
> > +/* number of bits of the fractional part of TSC scaling ratio */
> > +uint8_t  tsc_scaling_ratio_frac_bits;
> > +/* default TSC scaling ratio (no scaling) */
> > +uint64_t default_tsc_scaling_ratio;
> > +/* maxmimum-allowed TSC scaling ratio */
> 
> maxmimum -> maximum

will fix in the next version

Thanks,
Haozhong

> 
> > +uint64_t max_tsc_scaling_ratio;
> > +
> > +/*
> >   * Initialise/destroy HVM domain/vcpu resources
> >   */
> >  int  (*domain_initialise)(struct domain *d);
> > --
> > 2.6.3
> 

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

Re: [Xen-devel] [PATCH v2 14/14] docs: Add descriptions of TSC scaling in xl.cfg and tscmode.txt

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Monday, December 07, 2015 4:59 AM
g and tscmode.txt
> 
> Signed-off-by: Haozhong Zhang 
> ---
>  docs/man/xl.cfg.pod.5 | 15 ++-
>  docs/misc/tscmode.txt | 14 ++
>  2 files changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 2aca8dd..7e19a9b 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -1313,9 +1313,18 @@ deprecated. Options are:
> 
>  =item B<"default">
> 
> -Guest rdtsc/p executed natively when monotonicity can be guaranteed
> +Guest rdtsc/p is executed natively when monotonicity can be guaranteed
>  and emulated otherwise (with frequency scaled if necessary).
> 
> +If a HVM container in B TSC mode is not migrated from other hosts

"migrated from" -> "migrated to"?

> +and the host TSC monotonicity can be guaranteed, the guest and host TSC
> +frequencies will be the same.
> +
> +If a HVM container in B TSC mode is migrated to a host that can
> +guarantee the TSC monotonicity and supports Intel VMX TSC scaling/AMD SVM

and -> or? Do we think TSC scaling a must to ensure TSC monotonicity? It comes
to the rescue only when host can't ensure monotonicity...

> +TSC ratio, guest rdtsc/p will still execute natively after migration and the
> +guest TSC frequencies before and after migration will be the same.

will be the same before and after migration.

> +
>  =item B<"always_emulate">
> 
>  Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
> @@ -1337,6 +1346,10 @@ determine when a restore/migration has occurred and
> assumes guest
>  obtains/uses pvclock-like mechanism to adjust for monotonicity and
>  frequency changes.
> 
> +If a HVM container in B TSC mode can execute both guest
> +rdtsc and guest rdtscp natively, then the guest TSC frequency will be
> +determined in the similar way to that of B TSC mode.
> +
>  =back
> 
>  Please see F for more information on this option.
> diff --git a/docs/misc/tscmode.txt b/docs/misc/tscmode.txt
> index e8c84e8..f3b70be 100644
> --- a/docs/misc/tscmode.txt
> +++ b/docs/misc/tscmode.txt
> @@ -297,3 +297,17 @@ and also much faster than nearly all OS-provided time
> mechanisms.
>  While pvrtscp is too complex for most apps, certain enterprise
>  TSC-sensitive high-TSC-frequency apps may find it useful to
>  obtain a significant performance gain.
> +
> +Hardware TSC Scaling
> +
> +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read
> +by guest rdtsc/p increasing in the different frequency than the host

"in the different" -> "in a different"

> +TSC frequency.
> +
> +For a HVM container is in default TSC mode (tsc_mode=0) or PVRDTSCP

For a HVM container *which* is

> +mode (tsc_mode=3) and can execute both guest rdtsc and rdtscp
> +natively, if it is not migrated from other hosts, the guest and host
> +TSC frequencies will be the same. 

"the guest and host TSC frequencies remain the same if the guest is
not migrated to other host."

and the condition is that the host supports constant TSC feature.

> If it is migrated to a host
> +supporting Intel VMX TSC scaling/AMD SVM TSC ratio and can still
> +execute guest rdtsc and rdtscp natively, the guest TSC frequencies
> +before and after migration will be the same.
> --
> 2.6.3


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

Re: [Xen-devel] [PATCH v10 4/7] Update IRTE according to guest interrupt config changes

[Tian, Kevin]

> From: Feng Wu
> Sent: Thursday, December 03, 2015 4:36 PM
> 
> When guest changes its interrupt configuration (such as, vector, etc.)
> for direct-assigned devices, we need to update the associated IRTE
> with the new guest vector, so external interrupts from the assigned
> devices can be injected to guests without VM-Exit.
> 
> For lowest-priority interrupts, we use vector-hashing mechamisn to find
> the destination vCPU. This follows the hardware behavior, since modern
> Intel CPUs use vector hashing to handle the lowest-priority interrupt.
> 
> For multicast/broadcast vCPU, we cannot handle it via interrupt posting,
> still use interrupt remapping.
> 
> CC: Jan Beulich 
> Signed-off-by: Feng Wu 
> Acked-by: Jan Beulich 

Reviewed-by: Kevin Tian  

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

Re: [Xen-devel] Taking on a Xen development project

[Wei Liu]

Hello

On Fri, Dec 04, 2015 at 03:26:00PM -0500, jto...@uwaterloo.ca wrote:
> Hi,
> 
> We're a team of three fourth-year undergraduate software engineering
> students at the University of Waterloo in Canada.  We're in the process
> of planning for our capstone design project, and are interested in
> contributing to Xen.  Ideally, we'd like to take on a hypervisor/kernel
> hacking project with roughly the same scope as a Google Summer of Code
> project (like the hypervisor or domain support projects described at
> [0]), following a similar timeline (roughly May to August 2016).  We're
> all broadly interested in systems programming in C, and have each had
> relevant academic and internship experiences.
> 
> Each of projects [1-3] currently on the Wiki look interesting, though
> we'd be completely open to others as well.  In particular, we'd be open
> to picking up Ben Catterall's work on HVM x86 deprivileged mode [4].  Do
> any of these projects seem like a good fit in terms of usefulness to the
> community and our timeline?  If so, we'd love to communicate more with
> any maintainers with projects in mind!  We were also hoping to
> familiarize ourselves with the project by addressing some Coverity
> issues, if any are open at the moment.
> 
> Thanks!
> 
> Harley Armstrong, Chester Lin, Joshua Otto
> 
> [0] http://wiki.xenproject.org/wiki/GSoC_2015
> [1] 
> 
> [2] 
> 
> [3] 
> 
> [4]
> 
> 

The powerclamp project has been taken by our Outreachy intern and the
x86 depriveleged project has been taken by Anthony Perard.

I've CC the mentors of the other two projects for you.

Wei.

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

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

[Xen-devel] [linux-next test] 65611: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 65521
 test-amd64-amd64-rumpuserxen-amd64  6 xen-bootfail REGR. vs. 65521
 test-amd64-amd64-xl-pvh-amd   6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-xl-pvh-intel  6 xen-boot fail REGR. vs. 65521
 build-i386-pvops  5 kernel-build  fail REGR. vs. 65521
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 65521
 test-amd64-amd64-xl-credit2   6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 65521
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 65521
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 65521
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 65521
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot   fail REGR. vs. 65521
 test-amd64-amd64-i386-pvgrub  6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-qemuu-nested-amd  6 xen-boot fail REGR. vs. 65521
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 65521
 test-amd64-amd64-amd64-pvgrub  6 xen-boot fail REGR. vs. 65521
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 65521
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-pygrub   6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 65521

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-pair 4 host-install/dst_host(4) broken REGR. vs. 65521
 test-amd64-amd64-libvirt-vhd  3 host-install(3) broken REGR. vs. 65521
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
65521
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 65521
 test-amd64-amd64-pair10 xen-boot/dst_hostfail blocked in 65521
 test-amd64-amd64-pair 9 xen-boot/src_hostfail blocked in 65521
 test-armhf-armhf-xl-xsm   6 xen-boot fail   like 65521
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 65521
 test-armhf-armhf-xl-vhd   6 xen-boot fail   like 65521
 test-armhf-armhf-xl-rtds  6 xen-boot fail   like 65521
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   like 65521
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 65521
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail   like 65521
 test-armhf-armhf-libvirt  6 xen-boot fail   like 65521
 test-armhf-armhf-xl-arndale   6 xen-boot fail   like 65521
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail like 65521
 test-armhf-armhf-xl   6 xen-boot fail   like 65521
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail like 65521

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   

Re: [Xen-devel] [PATCHv6] 03/28] build: use generated Kconfig options for Xen

[Jan Beulich]

>>> On 09.12.15 at 21:34,  wrote:
> On 12/9/15 2:40 AM, Jan Beulich wrote:
> On 08.12.15 at 20:53,  wrote:
>>> On 11/30/15 8:45 AM, Jan Beulich wrote:
>>> On 24.11.15 at 18:51,  wrote:
> @@ -227,9 +230,14 @@ kconfig := silentoldconfig oldconfig config 
> menuconfig defconfig \
>  $(kconfig):
>   $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) 
> $@
>  
> -$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
> +$(BASEDIR)/include/config/%.conf: 
> $(BASEDIR)/include/config/auto.conf.cmd $(BASEDIR)/.config
>   $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
> ARCH=$(XEN_TARGET_ARCH) silentoldconfig
>  
>  # Allow people to just run `make` as before and not force them to 
> configure
> -$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ;
> +$(BASEDIR)/.config:
>   $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
> ARCH=$(XEN_TARGET_ARCH) defconfig

 This should be one of the oldconfig targets now, shouldn't it?
>>>
>>> oldconfig uses .config. This is the case when the user has checked out
>>> the tree fresh. Its there to not change the workflow of "git clone ...
>>> && cd xen/xen && make"
>> 
>> Okay. But then this is meant to only support the simplest possible
>> form, i.e. without honoring any make command line or ./.config
>> overrides like debug=y or kexec=n? If that understanding of
>> mine is correct, at least the comment should mention such a
>> limitation (even better would be if in such cases unexpected
>> results would be prevented by - as the most trivial solution -
>> failing the build with a meaningful error message).
> 
> So you would like me to add code into xen/Makefile to detect if someone
> ran "make kexec=X" or added "kexec=X" into top level .config and give
> them a meaningful error message to tell them to use "make config" instead?

If you want to do the "(even better ...)" form, yes.

Jan


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

Re: [Xen-devel] [PATCH v10 0/5] xen pvusb toolstack work

[George Dunlap]

On Thu, Dec 10, 2015 at 12:05 PM, George Dunlap
 wrote:
> Chunyan,
>
> I did a thorough review of v3,

I meant "patch 3 of v9"... (the one labelled RESEND, with the updated
naming scheme).

 -George

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

[Xen-devel] [distros-debian-wheezy test] 38481: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

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

baseline version:
 flight   38422

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  fail
 test-amd64-amd64-i386-wheezy-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] [linux-linus test] 65608: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen3 host-install(3) broken REGR. vs. 59254
 test-amd64-amd64-pair4 host-install/dst_host(4) broken REGR. vs. 59254
 test-amd64-amd64-xl-xsm   3 host-install(3) broken REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 59254
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 59254
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-raw6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline 
untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host   fail baseline untested
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host   fail baseline untested
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-amd64-amd64-libvirt-vhd  9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-qcow2  6 xen-boot  fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 linuxaa53685549a2cfb5f175b0c4a20bc9aa1e5a1b85
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  154 days
Failing since 59348  2015-07-10 04:24:05 

Re: [Xen-devel] [PATCH v2 10/14] x86/hvm: Replace architecture TSC scaling by a common function

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Monday, December 07, 2015 4:59 AM
> 
> This patch implements a common function hvm_scale_tsc() to scale TSC by
> using TSC scaling information collected by architecture code.
> 
> Signed-off-by: Haozhong Zhang 

Reviewed-by: Kevin Tian , except the mul64 part.

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

[Xen-devel] [PATCH 12/12] xen-hvm: Mark inappropriate error handling FIXME

[Markus Armbruster]

Cc: Stefano Stabellini 
Cc: xen-de...@lists.xensource.com
Signed-off-by: Markus Armbruster 
---
 xen-hvm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/xen-hvm.c b/xen-hvm.c
index 3d78a0c..2a93390 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -240,6 +240,7 @@ static void xen_ram_init(PCMachineState *pcms,
 
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
 {
+/* FIXME caller ram_block_add() wants error_setg() on failure */
 unsigned long nr_pfn;
 xen_pfn_t *pfn_list;
 int i;
@@ -1192,6 +1193,12 @@ static void xen_wakeup_notifier(Notifier *notifier, void 
*data)
 int xen_hvm_init(PCMachineState *pcms,
  MemoryRegion **ram_memory)
 {
+/*
+ * FIXME Returns -1 without cleaning up on some errors (harmless
+ * as long as the caller exit()s on error), dies with hw_error()
+ * on others.  hw_error() isn't approprate here.  Should probably
+ * simply exit() on all errors.
+ */
 int i, rc;
 xen_pfn_t ioreq_pfn;
 xen_pfn_t bufioreq_pfn;
-- 
2.4.3


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

Re: [Xen-devel] [PATCH v10 3/7] vt-d: Add API to update IRTE when VT-d PI is used

[Tian, Kevin]

> From: Wu, Feng
> Sent: Thursday, December 03, 2015 4:36 PM
is used
> 
> This patch adds an API which is used to update the IRTE
> for posted-interrupt when guest changes MSI/MSI-X information.
> 
> CC: Kevin Tian 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> Signed-off-by: Feng Wu 
> Reviewed-by: Jan Beulich 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v3] x86/VPMU: Support only versions 2 through 4 of architectural performance monitoring

[Tian, Kevin]

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Friday, December 04, 2015 10:08 PM
> 
> We need to have at least version 2 since it's the first version to
> support various control and status registers (such as
> MSR_CORE_PERF_GLOBAL_CTRL) that VPMU relies on always having.
> 
> We don't fully emulate version 4 but since it's back compatible with
> earlier versions we can fall back to v3. At this point there is no
> compatibility statement for v5 so anything above 4 is not supported.
> 
> For guests querying PMU version via CPUID leaf 0xa clip it at v3.
> 
> With explicit testing for PMU version we can now remove CPUID model
> check.
> 
> Signed-off-by: Boris Ostrovsky 

Acked-by: Kevin Tian 


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

[Xen-devel] [PATCH v10 0/5] xen pvusb toolstack work

[George Dunlap]

Chunyan,

I did a thorough review of v3, and almost all the comments I had fell
into two categories:

1. Trivial things that could be easily fixed

2. Complicated things that would be difficult to explain and might
take several rounds to correct.

As such, I hope you don't mind that I took the liberty to simply fix
up the series the way I thought it should be.  I've only
compile-tested this; if you could review it, and test it (and if
necessary give more feedback), and then either ack it or revise and
re-send it, I'd appreciate it.

 -George

Below is Chunyan's original pvusb cover letter.

---
This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.

Changes to V9:
* Rebased to staging (ec0712576198633dd7fbfe25290b030d5a23b252)
* Lots of changes to patch 3/5
* Removed patches related to "list-assignable-devices" functionality

  <<< pvusb work introduction >>>

1. Overview

There are two general methods for passing through individual host
devices to a guest. The first is via an emulated USB device
controller; the second is PVUSB.

Additionally, there are two ways to add USB devices to a guest: via
the config file at domain creation time, and via hot-plug while the VM
is running.

* Emulated USB

In emulated USB, the device model (qemu) presents an emulated USB
controller to the guest. The device model process then grabs control
of the device from domain 0 and and passes the USB commands between
the guest OS and the host USB device.

This method is only available to HVM domains, and is not available for
domains running with device model stubdomains.

* PVUSB

PVUSB uses a paravirtialized front-end/back-end interface, similar to
the traditional Xen PV network and disk protocols. In order to use
PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or
your USB driver domain).

2. Specifying a host USB device

QEMU qmp commands allows USB devices to be specified either by their
bus address (in the form bus.device) or their device tag (in the form
vendorid:deviceid).

Each way of specifying has its advantages:

Specifying by device tag will always get the same device,
regardless of where the device ends up in the USB bus topology.
However, if there are two identical devices, it will not allow you to
specify which one.

Specifying by bus address will always allow you to choose a
specific device, even if you have duplicates. However, the bus address
may change depending on which port you plugged the device into, and
possibly also after a reboot.

To avoid duplication of vendorid:deviceid, we'll use bus address to
specify host USB device in xl toolstack.

You can use lsusb to list the USB devices on the system:

Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0
Hub
Bus 003 Device 002: ID f617:0905
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0
Hub
Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra
Fast Media Reader
Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse

To pass through the Logitec mouse, for instance, you could specify
1.6 (remove leading zeroes).

Note: USB hubs can not be assigned to guest.

3. PVUSB toolstack

* Specify USB device in xl config file

You can just specify usb devices, like:
usbdev=['1.6']

Then it will create a USB controller automatically and attach the USB
device to the first available USB controller:port.

or, you can explicitly specify usb controllers and usb devices, like:
usbctrl=['verison=1, ports=4', 'version=2, ports=8', ]
usbdev=['1.6, controller=0, port=1']

Then it will create two USB controllers as you specified.
And if controller and port are specified in usb config, then it will
attach the USB device to that controller:port. About the controller
and port value:
Each USB controller has a index (or called devid) based on 0. The 1st
controller has index 0, the 2nd controller has index 1, ...
Under controller, each port has a port number based on 1. In above
configuration, the 1st controller will have port 1,2,3,4.

* Hot-Plug USB device

To attach a USB device, you should first create a USB controller.
e.g.
xl usb-ctrl-attach domain [version=1|2] [ports=value]
By default, it will create a USB2.0 controller with 8 ports.

Then you could attach a USB device.
e.g.
xl usb-attach domain 1.6 [controller=index port=number]
By default, it will find the 1st available controller:port to attach
the USB device.

You could view USB device status of the domain by usb-list.
e.g.
xl usb-list domain
It will list USB controllers and USB devices under each controller.

You could detach a USB device with usb-detach command.
e.g.
xl usb-detach domain 1.6

You can also remove the whole USB controller by usb-ctrl-detach
command.
e.g.
xl usb-ctrl-detach domain 0
It will remove the USB controller with index 0 and all USB devices
under 

[Xen-devel] [PATCH v10 3/5] libxl: add pvusb API

[George Dunlap]

From: Chunyan Liu 

Add pvusb APIs, including:
 - attach/detach (create/destroy) virtual usb controller.
 - attach/detach usb device
 - list usb controller and usb devices
 - some other helper functions

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Signed-off-by: George Dunlap 
---
Changes since v9:
- Rework DEFINE_DEVICE_REMOVE
- Got rid of redundant local ctx variable
- Got rid of return [void function] when returning from a void function
- Added spaces between STRING_MACRO and "x", as requested by IanJ when 
reviewing v8
- Got rid of another unnecessary void* -> char* cast
- Make vusb_be_from_xs_fe function to read a backend from a front end and check 
it for sanity
- Refactor libxl__device_usbdev_setdefault() to avoid code duplication for 
{ctrl,port} and {ctrl,NULL} case

CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxl/Makefile |2 +-
 tools/libxl/libxl.c  |   34 +-
 tools/libxl/libxl.h  |   77 ++
 tools/libxl/libxl_device.c   |   13 +-
 tools/libxl/libxl_internal.h |   22 +-
 tools/libxl/libxl_osdeps.h   |   13 +
 tools/libxl/libxl_pvusb.c| 1542 ++
 tools/libxl/libxl_types.idl  |   46 +
 tools/libxl/libxl_types_internal.idl |1 +
 tools/libxl/libxl_utils.c|   18 +
 tools/libxl/libxl_utils.h|5 +
 11 files changed, 1760 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 6ff5bee..a36145a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -103,7 +103,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_stream_read.o libxl_stream_write.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
-   libxl_dom_suspend.o $(LIBXL_OBJS-y)
+   libxl_dom_suspend.o libxl_pvusb.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 36dc37d..0485b04 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3201,7 +3201,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc 
*egc,
 aodev->dev = device;
 aodev->callback = local_device_detach_cb;
 aodev->force = 0;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 return;
 }
 
@@ -4154,8 +4154,10 @@ out:
  * libxl_device_vkb_destroy
  * libxl_device_vfb_remove
  * libxl_device_vfb_destroy
+ * libxl_device_usbctrl_remove
+ * libxl_device_usbctrl_destroy
  */
-#define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\
+#define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\
 int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
 uint32_t domid, libxl_device_##type *type,  \
 const libxl_asyncop_how *ao_how)\
@@ -4175,13 +4177,19 @@ out:
 aodev->dev = device;\
 aodev->callback = device_addrm_aocomplete;  \
 aodev->force = f;   \
-libxl__initiate_device_remove(egc, aodev);  \
+libxl__initiate_device_##remtype##_remove(egc, aodev);  \
 \
 out:\
-if (rc) return AO_CREATE_FAIL(rc);\
+if (rc) return AO_CREATE_FAIL(rc);  \
 return AO_INPROGRESS;   \
 }
 
+#define DEFINE_DEVICE_REMOVE(type, removedestroy, f) \
+DEFINE_DEVICE_REMOVE_EXT(type, generic, removedestroy, f)
+
+#define DEFINE_DEVICE_REMOVE_CUSTOM(type, removedestroy, f)  \
+DEFINE_DEVICE_REMOVE_EXT(type, type, removedestroy, f)
+
 /* Define all remove/destroy functions and undef the macro */
 
 /* disk */
@@ -4205,6 +4213,10 @@ DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
 DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
 
+/* usbctrl */
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, remove, 0)
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, destroy, 1)
+
 /* channel/console hotunplug is not implemented. There are 2 possibilities:
  * 1. add support for secondary consoles to xenconsoled
  * 2. dynamically add/remove qemu chardevs via qmp messages. */
@@ -4218,6 +4230,8 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
  * libxl_device_disk_add
  * 

[Xen-devel] [PATCH v10 4/5] xl: add pvusb commands

[George Dunlap]

From: Chunyan Liu 

Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
usbdev-attach and usbdev-detach.

To attach a usb device to guest through pvusb, one could follow
following example:

 #xl usbctrl-attach test_vm version=1 ports=8

 #xl usb-list test_vm
 will show the usb controllers and port usage under the domain.

 #xl usbdev-attach test_vm hostbus=1 hostaddr=2
 will find the first usable controller:port, and attach usb
 device whose busnum is 1 and devnum is 6.
 One could also specify which  and which .

 #xl usbdev-detach test_vm 0 1
 will detach USB device under controller 0 port 1.

 #xl usbctrl-detach test_vm dev_id
 will destroy the controller with specified dev_id. Dev_id
 can be traced in usb-list info.

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
---
 docs/man/xl.pod.1 |  41 
 tools/libxl/xl.h  |   5 +
 tools/libxl/xl_cmdimpl.c  | 243 ++
 tools/libxl/xl_cmdtable.c |  25 +
 4 files changed, 314 insertions(+)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 4279c7c..746f49f 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1345,6 +1345,47 @@ List pass-through pci devices for a domain.
 
 =back
 
+=head1 USB PASS-THROUGH
+
+=over 4
+
+=item B I 

Re: [Xen-devel] [PATCH v10 0/5] xen pvusb toolstack work

[George Dunlap]

On Thu, Dec 10, 2015 at 12:05 PM, George Dunlap
 wrote:
> Changes to V9:
> * Rebased to staging (ec0712576198633dd7fbfe25290b030d5a23b252)
> * Lots of changes to patch 3/5
> * Removed patches related to "list-assignable-devices" functionality

And this is because, as I have said elsewhere, I think such
functionality should be done with libusb, rather than implemented
directly by reading sysfs, so that it has the potential to work on
non-Linux operating systems.  And I since this functionality is not
critical to the core pvusb functionality (lsusb can cover the
difference in the mean time), it should come in a separate patch
series.

 -George

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

Re: [Xen-devel] [PATCH] x86/HVM: Merge HVM and PVH hypercall tables

[Jan Beulich]

>>> On 08.12.15 at 15:20,  wrote:
> The tables are almost identical and therefore there is little reason to
> keep both sets.
> 
> PVH needs 3 extra hypercalls:
> * mmuext_op. PVH uses MMUEXT_TLB_FLUSH_MULTI and MMUEXT_INVLPG_MULTI to
>   optimize TLB flushing. Since HVMlite guests may decide to use them as
>   well we can allow these two commands for all guests in an HVM container.

I must be missing something here: Especially for the INVLPG variant
I can't see what use it could be for a PVH guest, as it necessarily
would act on a different address space (the other one may have at
least some effect due to hvm_flush_guest_tlbs()).

And then, if those two really are meant to be enabled, why would
their _LOCAL and _ALL counterparts not be? And similarly,
MMUEXT_FLUSH_CACHE{,_GLOBAL} may then be valid to expose.

Wasn't it much rather that PVH Dom0 needed e.g. MMUEXT_PIN_Ln_TABLE
to deal with foreign guests' page tables?

Jan


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

[Xen-devel] [PATCH v7 05/28] build: convert HAS_PASSTHROUGH use to Kconfig

[Doug Goldstein]

Use the Kconfig generated HAS_PASSTHROUGH defines for the code base.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Daniel De Graaf 
Signed-off-by: Doug Goldstein 
---
 xen/Rules.mk|  1 -
 xen/arch/arm/Kconfig|  1 +
 xen/arch/arm/Rules.mk   |  1 -
 xen/arch/x86/Kconfig|  1 +
 xen/arch/x86/Rules.mk   |  1 -
 xen/common/compat/memory.c  |  4 ++--
 xen/common/memory.c |  8 
 xen/drivers/Kconfig |  1 +
 xen/drivers/Makefile|  2 +-
 xen/drivers/passthrough/Kconfig |  4 
 xen/include/xen/sched.h |  4 ++--
 xen/include/xsm/dummy.h |  4 ++--
 xen/include/xsm/xsm.h   |  8 
 xen/xsm/dummy.c |  4 ++--
 xen/xsm/flask/hooks.c   | 10 +-
 15 files changed, 29 insertions(+), 25 deletions(-)
 create mode 100644 xen/drivers/passthrough/Kconfig

diff --git a/xen/Rules.mk b/xen/Rules.mk
index d696206..a822147 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -58,7 +58,6 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)  += -DHAS_ACPI
 CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX
-CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 91b96bc..0fd69a7 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -16,6 +16,7 @@ config ARM_64
 
 config ARM
def_bool y
+   select HAS_PASSTHROUGH
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index b31770c..86d7b81 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -9,7 +9,6 @@
 HAS_DEVICE_TREE := y
 HAS_VIDEO := y
 HAS_ARM_HDLCD := y
-HAS_PASSTHROUGH := y
 HAS_PDX := y
 
 CFLAGS += -I$(BASEDIR)/include
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 9df34a4..3771256 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -3,6 +3,7 @@ config X86_64
 
 config X86
def_bool y
+   select HAS_PASSTHROUGH
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 5b8eaed..09f2844 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -8,7 +8,6 @@ HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
 HAS_PCI := y
-HAS_PASSTHROUGH := y
 HAS_NS16550 := y
 HAS_EHCI := y
 HAS_KEXEC := y
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index bb10993..19a914d 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -18,7 +18,7 @@ CHECK_TYPE(domid);
 CHECK_mem_access_op;
 CHECK_vmemrange;
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 struct get_reserved_device_memory {
 struct compat_reserved_device_memory_map map;
 unsigned int used_entries;
@@ -340,7 +340,7 @@ int compat_memory_op(unsigned int cmd, 
XEN_GUEST_HANDLE_PARAM(void) compat)
 break;
 }
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 case XENMEM_reserved_device_memory_map:
 {
 struct get_reserved_device_memory grdm;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index efb6e1a..6b3a755 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -651,7 +651,7 @@ static int xenmem_add_to_physmap(struct domain *d,
 xatp->gpfn += start;
 xatp->size -= start;
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 if ( need_iommu(d) )
 this_cpu(iommu_dont_flush_iotlb) = 1;
 #endif
@@ -674,7 +674,7 @@ static int xenmem_add_to_physmap(struct domain *d,
 }
 }
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 if ( need_iommu(d) )
 {
 this_cpu(iommu_dont_flush_iotlb) = 0;
@@ -801,7 +801,7 @@ static int construct_memop_from_reservation(
 return 0;
 }
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 struct get_reserved_device_memory {
 struct xen_reserved_device_memory_map map;
 unsigned int used_entries;
@@ -1245,7 +1245,7 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 break;
 }
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 case XENMEM_reserved_device_memory_map:
 {
 struct get_reserved_device_memory grdm;
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index 7bc7b6e..57311cc 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -1,3 +1,4 @@
 menu "Device Drivers"
 
+source "drivers/passthrough/Kconfig"
 endmenu
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 9c70f20..e283870 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -1,6 +1,6 @@
 

[Xen-devel] [PATCH v7 15/28] build: convert HAS_PDX use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_PDX defines in the code base.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
---
 xen/Rules.mk  | 1 -
 xen/arch/arm/Kconfig  | 1 +
 xen/arch/arm/Rules.mk | 1 -
 xen/arch/x86/Kconfig  | 1 +
 xen/arch/x86/Rules.mk | 1 -
 xen/common/Kconfig| 4 
 xen/common/Makefile   | 2 +-
 xen/include/xen/pdx.h | 2 +-
 8 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index f572c0d..d55c58c 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -59,7 +59,6 @@ CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
 CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING
-CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index c88a5d8..1ac2233 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -18,6 +18,7 @@ config ARM
def_bool y
select HAS_DEVICE_TREE
select HAS_PASSTHROUGH
+   select HAS_PDX
select HAS_VIDEO
 
 config ARCH_DEFCONFIG
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 90b1f24..52b1ad4 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -7,7 +7,6 @@
 #
 
 HAS_ARM_HDLCD := y
-HAS_PDX := y
 
 CFLAGS += -I$(BASEDIR)/include
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index e95070b..025373a 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -10,6 +10,7 @@ config X86
select HAS_NS16550
select HAS_PASSTHROUGH
select HAS_PCI
+   select HAS_PDX
select HAS_VGA
select HAS_VIDEO
 
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 009f702..193e7ea 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -4,7 +4,6 @@
 HAS_NUMA := y
 HAS_EHCI := y
 HAS_KEXEC := y
-HAS_PDX := y
 HAS_CORE_PARKING := y
 xenoprof := y
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 75edd45..4905574 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -5,6 +5,10 @@ menu "Common Features"
 config HAS_DEVICE_TREE
bool
 
+# Select HAS_PDX if PDX is supported
+config HAS_PDX
+   bool
+
 # Select HAS_GDBSX if GDBSX is supported
 config HAS_GDBSX
bool
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 5dc2bb2..0acd2b0 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -23,7 +23,7 @@ obj-y += memory.o
 obj-y += multicall.o
 obj-y += notifier.o
 obj-y += page_alloc.o
-obj-$(HAS_PDX) += pdx.o
+obj-$(CONFIG_HAS_PDX) += pdx.o
 obj-y += preempt.o
 obj-y += random.o
 obj-y += rangeset.o
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index 18fe8e5..c7c837e 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -1,7 +1,7 @@
 #ifndef __XEN_PDX_H__
 #define __XEN_PDX_H__
 
-#ifdef HAS_PDX
+#ifdef CONFIG_HAS_PDX
 
 extern unsigned long max_pdx;
 extern unsigned long pfn_pdx_bottom_mask, ma_va_bottom_mask;
-- 
2.4.10


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

[Xen-devel] [PATCH v7 12/28] build: convert HAS_VGA use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_VGA defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
---
 xen/arch/x86/Kconfig   | 1 +
 xen/arch/x86/Rules.mk  | 1 -
 xen/drivers/video/Kconfig  | 4 
 xen/drivers/video/Makefile | 4 ++--
 4 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index ee8df87..b03d228 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -8,6 +8,7 @@ config X86
select HAS_NS16550
select HAS_PASSTHROUGH
select HAS_PCI
+   select HAS_VGA
select HAS_VIDEO
 
 config ARCH_DEFCONFIG
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 8fda89e..47d4dc6 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -2,7 +2,6 @@
 # x86-specific definitions
 
 HAS_NUMA := y
-HAS_VGA  := y
 HAS_CPUFREQ := y
 HAS_EHCI := y
 HAS_KEXEC := y
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 7fc7aea..6a7cafc 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -2,3 +2,7 @@
 # Select HAS_VIDEO if video is supported
 config HAS_VIDEO
bool
+
+# Select HAS_VGA if VGA is supported
+config HAS_VGA
+   bool
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 914b6cf..0143c4a 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -1,7 +1,7 @@
-obj-$(HAS_VGA) := vga.o
+obj-$(CONFIG_HAS_VGA) := vga.o
 obj-$(CONFIG_HAS_VIDEO) += font_8x14.o
 obj-$(CONFIG_HAS_VIDEO) += font_8x16.o
 obj-$(CONFIG_HAS_VIDEO) += font_8x8.o
 obj-$(CONFIG_HAS_VIDEO) += lfb.o
-obj-$(HAS_VGA) += vesa.o
+obj-$(CONFIG_HAS_VGA) += vesa.o
 obj-$(HAS_ARM_HDLCD) += arm_hdlcd.o
-- 
2.4.10


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

[Xen-devel] [PATCH v7 19/28] build: convert HAS_PL011 use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_PL011 defines in the code base.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Doug Goldstein 
---
 config/arm32.mk   | 1 -
 config/arm64.mk   | 1 -
 xen/drivers/char/Kconfig  | 9 +
 xen/drivers/char/Makefile | 2 +-
 4 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/config/arm32.mk b/config/arm32.mk
index f963338..3bbdd2d 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -9,7 +9,6 @@ CONFIG_XEN_INSTALL_SUFFIX :=
 # Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
 CFLAGS += -marm
 
-HAS_PL011 := y
 HAS_EXYNOS4210 := y
 HAS_OMAP := y
 HAS_SCIF := y
diff --git a/config/arm64.mk b/config/arm64.mk
index 2d119a6..1b9a47f 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -6,7 +6,6 @@ CONFIG_XEN_INSTALL_SUFFIX :=
 
 CFLAGS += #-marm -march= -mcpu= etc
 
-HAS_PL011 := y
 HAS_MEM_ACCESS := y
 HAS_GICV3 := y
 
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index fc49bd7..e90104b 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -13,3 +13,12 @@ config HAS_CADENCE_UART
help
  This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
  based board, say Y.
+
+# ARM AMBA PL011 UART support
+config HAS_PL011
+   bool
+   default y
+   depends on ARM
+   help
+ This selects the ARM(R) AMBA(R) PrimeCell PL011 UART. If you have
+ an Integrator/PP2, Integrator/CP or Versatile platform, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index e86ba6f..df87594 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,7 +1,7 @@
 obj-y += console.o
 obj-$(CONFIG_HAS_NS16550) += ns16550.o
 obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
-obj-$(HAS_PL011) += pl011.o
+obj-$(CONFIG_HAS_PL011) += pl011.o
 obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
 obj-$(HAS_OMAP) += omap-uart.o
 obj-$(HAS_SCIF) += scif-uart.o
-- 
2.4.10


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

[Xen-devel] [PATCH v7 03/28] build: build Kconfig and config rules

[Doug Goldstein]

Wire in the Kconfig build and makefile rules to be able to generate
valid configuration files to be used by the build process but don't
actually use the output for affecting the Xen build. To avoid dragging
in most of Kbuild from the Linux kernel this adds Makefile.kconfig which
is our real entry point into building kconfig. This attempts to reuse as
much of the Xen build bits as possible and wire them to the bits that
kconfig expects to be provided by Kbuild.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
---
 .gitignore|  6 +++
 xen/Kconfig   | 24 +++
 xen/Makefile  | 22 ++
 xen/arch/arm/Kconfig  | 31 ++
 xen/arch/arm/configs/arm32_defconfig  |  0
 xen/arch/arm/configs/arm64_defconfig  |  0
 xen/arch/x86/Kconfig  | 17 
 xen/arch/x86/configs/x86_64_defconfig |  0
 xen/common/Kconfig|  4 ++
 xen/drivers/Kconfig   |  3 ++
 xen/tools/kconfig/Makefile.kconfig| 76 +++
 11 files changed, 183 insertions(+)
 create mode 100644 xen/Kconfig
 create mode 100644 xen/arch/arm/Kconfig
 create mode 100644 xen/arch/arm/configs/arm32_defconfig
 create mode 100644 xen/arch/arm/configs/arm64_defconfig
 create mode 100644 xen/arch/x86/Kconfig
 create mode 100644 xen/arch/x86/configs/x86_64_defconfig
 create mode 100644 xen/common/Kconfig
 create mode 100644 xen/drivers/Kconfig
 create mode 100644 xen/tools/kconfig/Makefile.kconfig

diff --git a/.gitignore b/.gitignore
index 91e1430..0a0f3ad 100644
--- a/.gitignore
+++ b/.gitignore
@@ -217,6 +217,8 @@ tools/xentrace/tbctl
 tools/xentrace/xenctx
 tools/xentrace/xentrace
 xen/.banner
+xen/.config
+xen/.config.old
 xen/System.map
 xen/arch/arm/asm-offsets.s
 xen/arch/arm/xen.lds
@@ -239,10 +241,14 @@ xen/include/headers++.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
 xen/include/compat/*
+xen/include/config/
+xen/include/generated/
 xen/include/public/public
 xen/include/xen/*.new
 xen/include/xen/acm_policy.h
 xen/include/xen/compile.h
+xen/tools/kconfig/.tmp_gtkcheck
+xen/tools/kconfig/.tmp_qtcheck
 xen/tools/symbols
 xen/xsm/flask/include/av_perm_to_string.h
 xen/xsm/flask/include/av_permissions.h
diff --git a/xen/Kconfig b/xen/Kconfig
new file mode 100644
index 000..ffe3f45
--- /dev/null
+++ b/xen/Kconfig
@@ -0,0 +1,24 @@
+#
+# For a description of the syntax of this configuration file,
+# see docs/misc/kconfig-language.txt
+#
+mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
+
+config SRCARCH
+   string
+   option env="SRCARCH"
+
+config ARCH
+   string
+   option env="ARCH"
+
+source "arch/$SRCARCH/Kconfig"
+
+config XEN_FULLVERSION
+   string
+   option env="XEN_FULLVERSION"
+
+config DEFCONFIG_LIST
+   string
+   option defconfig_list
+   default "$ARCH_DEFCONFIG"
diff --git a/xen/Makefile b/xen/Makefile
index 62c3a6e..1d2c814 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -20,6 +20,14 @@ MAKEFLAGS += -rR
 
 EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
 
+# Don't break if the build process wasn't called from the top level
+# we need XEN_TARGET_ARCH to generate the proper config
+include $(XEN_ROOT)/Config.mk
+
+# Allow someone to change their config file
+KCONFIG_CONFIG ?= .config
+export KCONFIG_CONFIG
+
 .PHONY: default
 default: build
 
@@ -91,6 +99,7 @@ _clean: delete-unfresh-files
$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig clean
find . \( -name "*.o" -o -name ".*.d" \) -exec rm -f {} \;
rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi $(TARGET)-syms 
*~ core
rm -f include/asm-*/asm-offsets.h
@@ -220,3 +229,16 @@ FORCE:
 
 %/: FORCE
$(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
+
+kconfig := silentoldconfig oldconfig config menuconfig defconfig \
+   nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
+.PHONY: $(kconfig)
+$(kconfig):
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(XEN_TARGET_ARCH) $@
+
+include/config/%.conf: include/config/auto.conf.cmd
+   $(Q)$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(XEN_TARGET_ARCH) silentoldconfig
+
+# Allow people to just run `make` as before and not force them to configure
+$(KCONFIG_CONFIG):
+   $(Q)$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(XEN_TARGET_ARCH) defconfig
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
new file mode 100644
index 000..91b96bc
--- /dev/null
+++ b/xen/arch/arm/Kconfig
@@ -0,0 +1,31 @@
+# Select 

Re: [Xen-devel] Taking on a Xen development project

[Andrew Cooper]

On 04/12/15 20:26, jto...@uwaterloo.ca wrote:
> Hi,
>
> We're a team of three fourth-year undergraduate software engineering
> students at the University of Waterloo in Canada.  We're in the process
> of planning for our capstone design project, and are interested in
> contributing to Xen.  Ideally, we'd like to take on a hypervisor/kernel
> hacking project with roughly the same scope as a Google Summer of Code
> project (like the hypervisor or domain support projects described at
> [0]), following a similar timeline (roughly May to August 2016).  We're
> all broadly interested in systems programming in C, and have each had
> relevant academic and internship experiences.
>
> Each of projects [1-3] currently on the Wiki look interesting, though
> we'd be completely open to others as well.  In particular, we'd be open
> to picking up Ben Catterall's work on HVM x86 deprivileged mode [4].  Do
> any of these projects seem like a good fit in terms of usefulness to the
> community and our timeline?  If so, we'd love to communicate more with
> any maintainers with projects in mind!  We were also hoping to
> familiarize ourselves with the project by addressing some Coverity
> issues, if any are open at the moment.
>
> Thanks!
>
> Harley Armstrong, Chester Lin, Joshua Otto

Hello - thankyou for your interest.

One area to look at might be the parameters to the live migration
looping.  As part of the migration v2 rework I did in the 4.6 dev
period, I left all of that alone, and it is in a working but poor state.

In the past, there have been several research investigations into
improving the live migration algorithm, such as tracking the rate of
dirtying of memory, or attempting to resume the domain on the far side
and fault the final memory across.

If you are interested in perusing this, start with reading
docs/features/migration.pandoc in the Xen tree.

~Andrew

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

Re: [Xen-devel] [PATCH v10 5/9] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs

[Jan Beulich]

>>> On 10.12.15 at 18:18,  wrote:
> El 10/12/15 a les 17.53, Jan Beulich ha escrit:
> On 07.12.15 at 17:48,  wrote:
>>> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down,
>>> VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi 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 
>> 
>> Reviewed-by: Jan Beulich 
>> albeit I may fiddle with some of the messages in check_segment()
>> upon committing, and pending clarification on ...
>> 
>>> +if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) )
>>> +{
>>> +/* Shadow-mode CR3 change. Check PDBR and update refcounts. */
>>> +struct page_info *page = get_page_from_gfn(v->domain,
>>> + v->arch.hvm_vcpu.guest_cr[3] >> 
>>> PAGE_SHIFT,
>>> + NULL, P2M_ALLOC);
>>> +if ( !page )
>>> +{
>>> +gprintk(XENLOG_ERR, "Invalid CR3: %#lx\n",
>>> +v->arch.hvm_vcpu.guest_cr[3]);
>>> +domain_crash(v->domain);
>>> +return -EINVAL;
>>> +}
>> 
>> ... why you crash the domain here when you don't on any on the
>> earlier error paths.
> 
> I don't see any reason why we should crash the domain, I'm not sure
> where the domain_crash call it's coming from, it's been here since the
> first version of this patch.
> 
> If you want I can send a new version without the domain crash, or you
> can amend it while committing. AFAICT removing the domain_crash call
> doesn't have any side effects.

I don't see a need for another version, unless other feedback you
might get would make that necessary.

Jan

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

[Xen-devel] nr_pages increase

[Gohar Irfan]

Is it possible to increase the number of pages (or memory size) visible to
the guest OS (domU)? Perhaps at boot-time?
Can this be achieved by increasing the value of nr_pages in the start_info
struct when it is initialized? Where exactly in the code is this happening?

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

Re: [Xen-devel] [V3 PATCH 6/9] x86/hvm: pkeys, add xstate support for pkeys

[George Dunlap]

On 07/12/15 09:16, Huaitong Han wrote:
> This patch adds xstate support for pkeys.

Hey Huaitong,

Hope you don't mind me giving you a little feedback on the way you've
broken down your patches here.  The purpose for breaking a change down
into separate patches like this is to make it easier for people
reviewing (and for people later who come and look at the commits) to
figure out what's going on.  But if you break the patch series down to
much, you go back to making things harder again.

Take this patch, for instance.  You're making get_xsave_addr() global
(non-static), and also making it handle the case where the xsave area
was compressed (which it didn't before).

But as a reviewer, I don't know at this point who is calling
get_xsave_addr() or why; I don't know if this change is necessary, or if
it is correct for all the callers (or if the change wrt compressed xsave
areas is even necessary).

So one problem with this patch is that you don't include that
information in the description.  But part of it is that the change
doesn't really make much sense by itself.

I think I'd squash patches 4-7 into a single patch.

More comments about the approach in patch 7.

 -George


> 
> Signed-off-by: Huaitong Han 
> ---
>  xen/arch/x86/xstate.c| 7 +--
>  xen/include/asm-x86/xstate.h | 4 +++-
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
> index b65da38..db978c4 100644
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -146,12 +146,15 @@ static void __init setup_xstate_comp(void)
>  }
>  }
>  
> -static void *get_xsave_addr(void *xsave, unsigned int xfeature_idx)
> +void *get_xsave_addr(void *xsave, unsigned int xfeature_idx)
>  {
>  if ( !((1ul << xfeature_idx) & xfeature_mask) )
>  return NULL;
>  
> -return xsave + xstate_comp_offsets[xfeature_idx];
> +if ( xsave_area_compressed(xsave) )
> +return xsave + xstate_comp_offsets[xfeature_idx];
> +else
> +return xsave + xstate_offsets[xfeature_idx];
>  }
>  
>  void expand_xsave_states(struct vcpu *v, void *dest, unsigned int size)
> diff --git a/xen/include/asm-x86/xstate.h b/xen/include/asm-x86/xstate.h
> index 12d939b..6536813 100644
> --- a/xen/include/asm-x86/xstate.h
> +++ b/xen/include/asm-x86/xstate.h
> @@ -34,13 +34,14 @@
>  #define XSTATE_OPMASK  (1ULL << 5)
>  #define XSTATE_ZMM (1ULL << 6)
>  #define XSTATE_HI_ZMM  (1ULL << 7)
> +#define XSTATE_PKRU(1ULL << 9)
>  #define XSTATE_LWP (1ULL << 62) /* AMD lightweight profiling */
>  #define XSTATE_FP_SSE  (XSTATE_FP | XSTATE_SSE)
>  #define XCNTXT_MASK(XSTATE_FP | XSTATE_SSE | XSTATE_YMM | XSTATE_OPMASK 
> | \
>  XSTATE_ZMM | XSTATE_HI_ZMM | XSTATE_NONLAZY)
>  
>  #define XSTATE_ALL (~(1ULL << 63))
> -#define XSTATE_NONLAZY (XSTATE_LWP | XSTATE_BNDREGS | XSTATE_BNDCSR)
> +#define XSTATE_NONLAZY (XSTATE_LWP | XSTATE_BNDREGS | XSTATE_BNDCSR | 
> XSTATE_PKRU)
>  #define XSTATE_LAZY(XSTATE_ALL & ~XSTATE_NONLAZY)
>  #define XSTATE_COMPACTION_ENABLED  (1ULL << 63)
>  
> @@ -90,6 +91,7 @@ uint64_t get_msr_xss(void);
>  void xsave(struct vcpu *v, uint64_t mask);
>  void xrstor(struct vcpu *v, uint64_t mask);
>  bool_t xsave_enabled(const struct vcpu *v);
> +void *get_xsave_addr(void *xsave, unsigned int xfeature_idx);
>  int __must_check validate_xstate(u64 xcr0, u64 xcr0_accum, u64 xstate_bv);
>  int __must_check handle_xsetbv(u32 index, u64 new_bv);
>  void expand_xsave_states(struct vcpu *v, void *dest, unsigned int size);
> 


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

Re: [Xen-devel] [PATCH] scripts: Add a script to build and submit to coverity.

[Andrew Cooper]

On 10/12/15 17:48, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH] scripts: Add a script to build and submit 
> to coverity."):
>> On 10/12/15 16:53, Ian Campbell wrote:
>>> ijc: Maybe we can think of a way to add this to osstest while still
>>> keeping the coverity token private?
>> This would be ideal.
> It doesn't sound particularly hard, apart from this wrinkle.
>
>>> +# Set $COV_EMAIL and $COV_TOKEN to credentials, otherwise it will
> ...
>>> +declare -a curl_args
>>> +curl_args+=("--form" "token=$COV_TOKEN")
>>> +curl_args+=("--form" "email=$COV_EMAIL")
>>> +curl_args+=("--form" "file=@$COV_TARBALL")
>>> +curl_args+=("--form" "version=$COV_VERSION")
>>> +curl_args+=("--form" "description=$COV_HEAD")
>>> +curl_args+=("https://scan.coverity.com/builds?project=XenProject;)
> Is there a way to do this that does not involve the authentication
> token being passed on curl's command line ?
>
> Ideally there would be a way to get it to read the token from a file
> in $HOME.  We could then provide the token in ~osstest in the
> production colo.

One way or another, the authentication token needs to be in a post
header.  How this script and `curl` make it happen is open to improvement.

Perhaps something like this? (Completely untested)

--form token=@~osstest/coverity-secret-token

~Andrew

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

Re: [Xen-devel] [PATCH] scripts: Add a script to build and submit to coverity.

[Ian Jackson]

Andrew Cooper writes ("Re: [PATCH] scripts: Add a script to build and submit to 
coverity."):
> On 10/12/15 17:48, Ian Jackson wrote:
> > Ideally there would be a way to get it to read the token from a file
> > in $HOME.  We could then provide the token in ~osstest in the
> > production colo.
> 
> One way or another, the authentication token needs to be in a post
> header.  How this script and `curl` make it happen is open to improvement.
> 
> Perhaps something like this? (Completely untested)
> 
> --form token=@~osstest/coverity-secret-token

If curl can do that then fine.  Given

> >>> +declare -a curl_args
> >>> +curl_args+=("--form" "token=$COV_TOKEN")
> >>> +curl_args+=("--form" "email=$COV_EMAIL")

this could be achieved by having ts-do-coverity-thing set COV_TOKEN to
$HOME/.xen-osstest/coverity-secret or whatever.  ts-do-coverity-thing
would need to set a bunch of other COV_SOMETHING anyay.

Ian.

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

Re: [Xen-devel] [V3 PATCH 5/9] x86/hvm: pkeys, add functions to support PKRU access

[Andrew Cooper]

On 07/12/15 09:16, Huaitong Han wrote:
> This patch adds functions to support PKRU access.
>
> Signed-off-by: Huaitong Han 

Reviewed-by: Andrew Cooper , with a suggestion...

> ---
>  xen/include/asm-x86/processor.h | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
> index 3f8411f..c345787 100644
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -342,6 +342,26 @@ static inline void write_cr4(unsigned long val)
>  asm volatile ( "mov %0,%%cr4" : : "r" (val) );
>  }
>  
> +/* Macros for PKRU domain */
> +#define PKRU_READ  (0)
> +#define PKRU_WRITE (1)
> +#define PKRU_ATTRS (2)
> +
> +/*
> + * PKRU defines 32 bits, there are 16 domains and 2 attribute bits per
> + * domain in pkru, pkeys is index to a defined domain, so the value of
> + * pte_pkeys * PKRU_ATTRS + R/W is offset of a defined domain attribute.
> + */
> +static inline bool_t read_pkru_ad(unsigned int pkru, unsigned int pkey)
> +{

ASSERT(pkey < 16);

> +return (pkru >> (pkey * PKRU_ATTRS + PKRU_READ)) & 1;
> +}
> +
> +static inline bool_t read_pkru_wd(unsigned int pkru, unsigned int pkey)
> +{

ASSERT(pkey < 16);

~Andrew

> +return (pkru >> (pkey * PKRU_ATTRS + PKRU_WRITE)) & 1;
> +}
> +
>  /* Clear and set 'TS' bit respectively */
>  static inline void clts(void) 
>  {


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

[Xen-devel] [PATCH v7 18/28] build: convert HAS_CADENCE_UART use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_CADENCE_UART defines in the code base.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Doug Goldstein 
---
 config/arm64.mk   | 1 -
 xen/drivers/char/Kconfig  | 9 +
 xen/drivers/char/Makefile | 2 +-
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/config/arm64.mk b/config/arm64.mk
index f35f6bf..2d119a6 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -7,7 +7,6 @@ CONFIG_XEN_INSTALL_SUFFIX :=
 CFLAGS += #-marm -march= -mcpu= etc
 
 HAS_PL011 := y
-HAS_CADENCE_UART := y
 HAS_MEM_ACCESS := y
 HAS_GICV3 := y
 
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index eb8c3b5..fc49bd7 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -4,3 +4,12 @@ config HAS_NS16550
default y
help
  This selects the 16550-series UART support. For most systems, say Y.
+
+# Xilinx Zynq Cadence UART support
+config HAS_CADENCE_UART
+   bool
+   default y
+   depends on ARM_64
+   help
+ This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
+ based board, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 5e9d271..e86ba6f 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,6 +1,6 @@
 obj-y += console.o
 obj-$(CONFIG_HAS_NS16550) += ns16550.o
-obj-$(HAS_CADENCE_UART) += cadence-uart.o
+obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
 obj-$(HAS_PL011) += pl011.o
 obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
 obj-$(HAS_OMAP) += omap-uart.o
-- 
2.4.10


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

[Xen-devel] [PATCH v7 21/28] build: convert HAS_OMAP use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_OMAP defines in the code base.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Doug Goldstein 
---
 config/arm32.mk   | 1 -
 xen/drivers/char/Kconfig  | 9 +
 xen/drivers/char/Makefile | 2 +-
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/config/arm32.mk b/config/arm32.mk
index 56b71d7..b1de8da 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -9,7 +9,6 @@ CONFIG_XEN_INSTALL_SUFFIX :=
 # Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
 CFLAGS += -marm
 
-HAS_OMAP := y
 HAS_SCIF := y
 HAS_MEM_ACCESS := y
 
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 8f72f68..a424ab2 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -31,3 +31,12 @@ config HAS_EXYNOS4210
help
  This selects the Samsung Exynos 4210 UART. If you have a Samsung
  Exynos based board, say Y.
+
+# OMAP UART support
+config HAS_OMAP
+   bool
+   default y
+   depends on ARM_32
+   help
+ This selects the Texas Instruments OMAP UART. If you have a Texas
+ Instruments based CPU, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index f8e7b44..7118570 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -3,7 +3,7 @@ obj-$(CONFIG_HAS_NS16550) += ns16550.o
 obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
 obj-$(CONFIG_HAS_PL011) += pl011.o
 obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
-obj-$(HAS_OMAP) += omap-uart.o
+obj-$(CONFIG_HAS_OMAP) += omap-uart.o
 obj-$(HAS_SCIF) += scif-uart.o
 obj-$(HAS_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_ARM) += dt-uart.o
-- 
2.4.10


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

[Xen-devel] [PATCH v7 10/28] build: convert HAS_ACPI use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_ACPI defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
---
 xen/Rules.mk | 1 -
 xen/arch/x86/Kconfig | 1 +
 xen/arch/x86/Rules.mk| 1 -
 xen/common/sysctl.c  | 2 +-
 xen/drivers/Kconfig  | 2 ++
 xen/drivers/Makefile | 2 +-
 xen/drivers/acpi/Kconfig | 4 
 7 files changed, 9 insertions(+), 4 deletions(-)
 create mode 100644 xen/drivers/acpi/Kconfig

diff --git a/xen/Rules.mk b/xen/Rules.mk
index b12ad73..09783e7 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,7 +56,6 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
-CFLAGS-$(HAS_ACPI)  += -DHAS_ACPI
 CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index c13ef29..5e6c6c9 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -3,6 +3,7 @@ config X86_64
 
 config X86
def_bool y
+   select HAS_ACPI
select HAS_IOPORTS
select HAS_NS16550
select HAS_PASSTHROUGH
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 151ed25..166deb9 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,7 +1,6 @@
 
 # x86-specific definitions
 
-HAS_ACPI := y
 HAS_NUMA := y
 HAS_VGA  := y
 HAS_VIDEO  := y
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 47d115e..a3007b8 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -171,7 +171,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 op->u.availheap.avail_bytes <<= PAGE_SHIFT;
 break;
 
-#ifdef HAS_ACPI
+#ifdef CONFIG_HAS_ACPI
 case XEN_SYSCTL_get_pmstat:
 ret = do_get_pm_info(>u.get_pmstat);
 break;
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index fe6fcca..eb01d47 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -1,5 +1,7 @@
 menu "Device Drivers"
 
+source "drivers/acpi/Kconfig"
+
 source "drivers/char/Kconfig"
 
 source "drivers/passthrough/Kconfig"
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index eb32d69..9f6c18b 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -2,5 +2,5 @@ subdir-y += char
 subdir-$(HAS_CPUFREQ) += cpufreq
 subdir-$(CONFIG_HAS_PCI) += pci
 subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough
-subdir-$(HAS_ACPI) += acpi
+subdir-$(CONFIG_HAS_ACPI) += acpi
 subdir-$(HAS_VIDEO) += video
diff --git a/xen/drivers/acpi/Kconfig b/xen/drivers/acpi/Kconfig
new file mode 100644
index 000..11ab5e4
--- /dev/null
+++ b/xen/drivers/acpi/Kconfig
@@ -0,0 +1,4 @@
+
+# Select HAS_ACPI if ACPI is supported
+config HAS_ACPI
+   bool
-- 
2.4.10


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

[Xen-devel] [PATCH v7 09/28] build: convert HAS_IOPORTS use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_IOPORTS defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
---
 xen/Rules.mk   |  1 -
 xen/arch/x86/Kconfig   |  1 +
 xen/arch/x86/Rules.mk  |  1 -
 xen/common/Kconfig |  3 +++
 xen/drivers/char/ns16550.c | 10 +-
 5 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 678b1f3..b12ad73 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -61,7 +61,6 @@ CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
 CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING
-CFLAGS-$(HAS_IOPORTS)   += -DHAS_IOPORTS
 CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index e68e35b..c13ef29 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -3,6 +3,7 @@ config X86_64
 
 config X86
def_bool y
+   select HAS_IOPORTS
select HAS_NS16550
select HAS_PASSTHROUGH
select HAS_PCI
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 17d2869..151ed25 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,7 +1,6 @@
 
 # x86-specific definitions
 
-HAS_IOPORTS := y
 HAS_ACPI := y
 HAS_NUMA := y
 HAS_VGA  := y
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 53ca33f..ea04d11 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -5,4 +5,7 @@ menu "Common Features"
 config HAS_DEVICE_TREE
bool
 
+config HAS_IOPORTS
+   bool
+
 endmenu
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 885839c..bc24015 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -348,7 +348,7 @@ static void ns16550_delayed_resume(void *data);
 static u8 ns_read_reg(struct ns16550 *uart, unsigned int reg)
 {
 void __iomem *addr = uart->remapped_io_base + (reg << uart->reg_shift);
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 if ( uart->remapped_io_base == NULL )
 return inb(uart->io_base + reg);
 #endif
@@ -366,7 +366,7 @@ static u8 ns_read_reg(struct ns16550 *uart, unsigned int 
reg)
 static void ns_write_reg(struct ns16550 *uart, unsigned int reg, u8 c)
 {
 void __iomem *addr = uart->remapped_io_base + (reg << uart->reg_shift);
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 if ( uart->remapped_io_base == NULL )
 return outb(c, uart->io_base + reg);
 #endif
@@ -552,7 +552,7 @@ static void __init ns16550_init_preirq(struct serial_port 
*port)
 {
 struct ns16550 *uart = port->uart;
 
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 /* I/O ports are distinguished by their size (16 bits). */
 if ( uart->io_base >= 0x1 )
 #endif
@@ -722,7 +722,7 @@ static void ns16550_resume(struct serial_port *port)
 
 static void __init ns16550_endboot(struct serial_port *port)
 {
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 struct ns16550 *uart = port->uart;
 int rv;
 
@@ -786,7 +786,7 @@ static int __init check_existence(struct ns16550 *uart)
 {
 unsigned char status, scratch, scratch2, scratch3;
 
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 /*
  * We can't poke MMIO UARTs until they get I/O remapped later. Assume that
  * if we're getting MMIO UARTs, the arch code knows what it's doing.
-- 
2.4.10


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

[Xen-devel] [PATCH v7 00/28] Kconfig conversion

[Doug Goldstein]

The following series is a follow on to the Kconfig conversion patch series.
There are still more components to convert however this is the bare minimal
to get everything working and get the options out of the existing makefiles.

The CONFIG_HAS_ variables are there to match the behavior of the Linux
CONFIG_HAVE_ variables. The purpose is to say that this hardware/profile/env
supports this option while the CONFIG_ variable states that this option was
requested on/off by user intervention.

Ultimately my goal is to allow for more parts of the hypervisor to be turned
off at compile time and potentially make it easier to include more
experimental features by others which can be turned off by default. Also to
provide the one true location for all possible knobs in the source code.

The patch series can be grabbed at:
https://github.com/cardoe/xen/tree/kconfig_v7

Change since v6:
- drop UART conversion for ARM to make them selectable
- update to Linux 4.3 copy of kconfig
- sync entire kconfig directory from Linux (not a change but point of order)
- drop changes to #endif comments that added CONFIG_
- add patch to add myself as the maintainer of kconfig bits
- move xen/scripts/kconfig to xen/tools/kconfig
- alphabatized entries in some cases
- dropped Acked-by and Tested-by (minor changes in all to alphabatize)
- added initial x86_128 support

Changes since v5:
- added Andrew Cooper's Acked-by and Tested-by
- rebased to resolve conflict with NUMA changes in staging (minor conflict)

Changes since v4:
- v4 was an oops and was a resend of v3. So the 'Changes since v3' apply here.

Changes since v3:
- fix dependency inversion causing options to appear to flip back on (hi kexec)
- separate out wiring up Kconfig and then using it in the build (added patch 3)
- dropped the old patch 3
- changed UART configs to be prefixed as CONFIG_UART_
- changed ARM UART defaults

Changes since v2:
- drop x86_32 support (patch 2)
- fix make defconfig (patch 2)
- fix 'make -C xen' vs 'cd xen && make' behaving differently (patch 2)
- fix for ARM64 builds (added patch 3)
- At this point all targets are tested on x86_64, arm32, and arm64 with
  fresh clones and rebuilds.

Changes since v1:
- hopefully addressed all review comments
- added CCs to all maintainers from get_maintainer.pl as requested
- drop Kbuild to build Kconfig and instead port the Makefile to the Xen env
- add support for xconfig/gconfig
- include Kconfig docs from Linux


Doug Goldstein (28):
  build: import Kbuild/Kconfig from Linux 4.3
  MAINTAINERS: add myself for kconfig
  build: build Kconfig and config rules
  build: use generated Kconfig options for Xen
  build: convert HAS_PASSTHROUGH use to Kconfig
  build: convert HAS_DEVICE_TREE use to Kconfig
  build: convert HAS_PCI use to Kconfig
  build: convert HAS_NS16550 use to Kconfig
  build: convert HAS_IOPORTS use to Kconfig
  build: convert HAS_ACPI use to Kconfig
  build: convert HAS_VIDEO use to Kconfig
  build: convert HAS_VGA use to Kconfig
  build: convert HAS_CPUFREQ use to Kconfig
  build: convert HAS_GDBSX use to Kconfig
  build: convert HAS_PDX use to Kconfig
  build: convert HAS_KEXEC / KEXEC use to Kconfig
  build: convert HAS_ARM_HDLCD use to Kconfig
  build: convert HAS_CADENCE_UART use to Kconfig
  build: convert HAS_PL011 use to Kconfig
  build: convert HAS_EXYNOS4210 use to Kconfig
  build: convert HAS_OMAP use to Kconfig
  build: convert HAS_SCIF use to Kconfig
  build: convert HAS_EHCI use to Kconfig
  build: convert HAS_MEM_ACCESS use to Kconfig
  build: convert HAS_MEM_PAGING use to Kconfig
  build: convert HAS_MEM_SHARING use to Kconfig
  build: convert HAS_GICV3 use to Kconfig
  build: convert CONFIG_COMPAT to Kconfig

 .gitignore   |6 +
 MAINTAINERS  |6 +
 config/arm32.mk  |5 -
 config/arm64.mk  |4 -
 config/x86_32.mk |2 -
 config/x86_64.mk |3 -
 docs/misc/kconfig-language.txt   |  395 
 docs/misc/kconfig.txt|  237 +++
 xen/Kconfig  |   24 +
 xen/Makefile |   29 +
 xen/Rules.mk |   22 +-
 xen/arch/arm/Kconfig |   42 +
 xen/arch/arm/Makefile|2 +-
 xen/arch/arm/Rules.mk|8 -
 xen/arch/arm/configs/arm32_defconfig |0
 xen/arch/arm/configs/arm64_defconfig |0
 xen/arch/arm/vgic.c  |2 +-
 xen/arch/x86/Kconfig |   39 +
 xen/arch/x86/Rules.mk|   12 -
 xen/arch/x86/configs/x86_64_defconfig|0
 xen/common/Kconfig   |   47 +
 xen/common/Makefile  |8 +-
 xen/common/compat/memory.c   |4 +-
 xen/common/domain.c

[Xen-devel] [PATCH v7 23/28] build: convert HAS_EHCI use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_EHCI defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
---
 xen/arch/x86/Kconfig  | 1 +
 xen/arch/x86/Rules.mk | 1 -
 xen/drivers/char/Kconfig  | 8 
 xen/drivers/char/Makefile | 2 +-
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index a5a0a1b..3b12a9e 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -5,6 +5,7 @@ config X86
def_bool y
select HAS_ACPI
select HAS_CPUFREQ
+   select HAS_EHCI
select HAS_GDBSX
select HAS_IOPORTS
select HAS_KEXEC
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 793e1f7..2f12fe8 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -2,7 +2,6 @@
 # x86-specific definitions
 
 HAS_NUMA := y
-HAS_EHCI := y
 HAS_CORE_PARKING := y
 xenoprof := y
 
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index c81b109..36a742b 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -49,3 +49,11 @@ config HAS_SCIF
help
  This selects the SuperH SCI(F) UART. If you have a SuperH based board,
  say Y.
+
+# USB EHCI debug port support
+config HAS_EHCI
+   bool
+   depends on X86
+   help
+ This selects the USB based EHCI debug port to be used as a UART. If
+ you have an x86 based system with USB, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index f9d9a9c..aa620fc 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -5,6 +5,6 @@ obj-$(CONFIG_HAS_PL011) += pl011.o
 obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
 obj-$(CONFIG_HAS_OMAP) += omap-uart.o
 obj-$(CONFIG_HAS_SCIF) += scif-uart.o
-obj-$(HAS_EHCI) += ehci-dbgp.o
+obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_ARM) += dt-uart.o
 obj-y += serial.o
-- 
2.4.10


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

[Xen-devel] [PATCH v7 08/28] build: convert HAS_NS16550 use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_NS16550 defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
---
 config/arm32.mk   | 1 -
 config/arm64.mk   | 1 -
 xen/arch/x86/Kconfig  | 1 +
 xen/arch/x86/Rules.mk | 1 -
 xen/drivers/Kconfig   | 2 ++
 xen/drivers/char/Kconfig  | 6 ++
 xen/drivers/char/Makefile | 2 +-
 7 files changed, 10 insertions(+), 4 deletions(-)
 create mode 100644 xen/drivers/char/Kconfig

diff --git a/config/arm32.mk b/config/arm32.mk
index cd97e42..f963338 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -13,7 +13,6 @@ HAS_PL011 := y
 HAS_EXYNOS4210 := y
 HAS_OMAP := y
 HAS_SCIF := y
-HAS_NS16550 := y
 HAS_MEM_ACCESS := y
 
 # Use only if calling $(LD) directly.
diff --git a/config/arm64.mk b/config/arm64.mk
index c5deb4e..f35f6bf 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -8,7 +8,6 @@ CFLAGS += #-marm -march= -mcpu= etc
 
 HAS_PL011 := y
 HAS_CADENCE_UART := y
-HAS_NS16550 := y
 HAS_MEM_ACCESS := y
 HAS_GICV3 := y
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 63f2b21..e68e35b 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -3,6 +3,7 @@ config X86_64
 
 config X86
def_bool y
+   select HAS_NS16550
select HAS_PASSTHROUGH
select HAS_PCI
 
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 8743509..17d2869 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -7,7 +7,6 @@ HAS_NUMA := y
 HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
-HAS_NS16550 := y
 HAS_EHCI := y
 HAS_KEXEC := y
 HAS_GDBSX := y
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index 5362e41..fe6fcca 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -1,5 +1,7 @@
 menu "Device Drivers"
 
+source "drivers/char/Kconfig"
+
 source "drivers/passthrough/Kconfig"
 
 source "drivers/pci/Kconfig"
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
new file mode 100644
index 000..eb8c3b5
--- /dev/null
+++ b/xen/drivers/char/Kconfig
@@ -0,0 +1,6 @@
+#  16550-series UART support
+config HAS_NS16550
+   bool
+   default y
+   help
+ This selects the 16550-series UART support. For most systems, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 47fc3f9..5e9d271 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,5 +1,5 @@
 obj-y += console.o
-obj-$(HAS_NS16550) += ns16550.o
+obj-$(CONFIG_HAS_NS16550) += ns16550.o
 obj-$(HAS_CADENCE_UART) += cadence-uart.o
 obj-$(HAS_PL011) += pl011.o
 obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
-- 
2.4.10


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

[Xen-devel] [PATCH v7 27/28] build: convert HAS_GICV3 use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_GICV3 defines in the code base.

CC: Ian Campbell 
CC: Stefano Stabellini 
Signed-off-by: Doug Goldstein 
---
 config/arm64.mk  | 1 -
 xen/arch/arm/Kconfig | 5 +
 xen/arch/arm/Makefile| 2 +-
 xen/arch/arm/Rules.mk| 2 --
 xen/arch/arm/vgic.c  | 2 +-
 xen/include/asm-arm/domain.h | 2 +-
 xen/include/asm-arm/gic.h| 4 ++--
 xen/include/asm-arm/vgic.h   | 2 +-
 8 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/config/arm64.mk b/config/arm64.mk
index 1b9a47f..1d7d81d 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -7,7 +7,6 @@ CONFIG_XEN_INSTALL_SUFFIX :=
 CFLAGS += #-marm -march= -mcpu= etc
 
 HAS_MEM_ACCESS := y
-HAS_GICV3 := y
 
 # Use only if calling $(LD) directly.
 LDFLAGS_DIRECT += -EL
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index ec176a6..2cab17b 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -13,6 +13,7 @@ config ARM_32
 config ARM_64
def_bool y
depends on 64BIT
+   select HAS_GICV3
 
 config ARM
def_bool y
@@ -30,6 +31,10 @@ config ARCH_DEFCONFIG
 
 menu "Architecture Features"
 
+# Select HAS_GICV3 if GICv3 is supported
+config HAS_GICV3
+   bool
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 4ac5edd..2f050f5 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -13,7 +13,7 @@ obj-y += sysctl.o
 obj-y += domain_build.o
 obj-y += gic.o gic-v2.o
 obj-$(CONFIG_ARM_32) += gic-hip04.o
-obj-$(HAS_GICV3) += gic-v3.o
+obj-$(CONFIG_HAS_GICV3) += gic-v3.o
 obj-y += io.o
 obj-y += irq.o
 obj-y += kernel.o
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 2158bd8..4947e64 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -32,8 +32,6 @@ ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
 CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
 endif
 
-CFLAGS-$(HAS_GICV3) += -DHAS_GICV3
-
 EARLY_PRINTK := n
 
 ifeq ($(debug),y)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 531ce5d..ee35683 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -103,7 +103,7 @@ int domain_vgic_init(struct domain *d, unsigned int nr_spis)
 
 switch ( d->arch.vgic.version )
 {
-#ifdef HAS_GICV3
+#ifdef CONFIG_HAS_GICV3
 case GIC_V3:
 if ( vgic_v3_init(d) )
return -ENODEV;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index e7e40da..aa7f283 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -102,7 +102,7 @@ struct arch_domain
 struct pending_irq *pending_irqs;
 /* Base address for guest GIC */
 paddr_t dbase; /* Distributor base address */
-#ifdef HAS_GICV3
+#ifdef CONFIG_HAS_GICV3
 /* GIC V3 addressing */
 /* List of contiguous occupied by the redistributors */
 struct vgic_rdist_region {
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 42a2eec..28935a3 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -167,7 +167,7 @@
 
 #define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3")
 
-#ifdef HAS_GICV3
+#ifdef CONFIG_HAS_GICV3
 /*
  * GICv3 registers that needs to be saved/restored
  */
@@ -195,7 +195,7 @@ struct gic_v2 {
  */
 union gic_state_data {
 struct gic_v2 v2;
-#ifdef HAS_GICV3
+#ifdef CONFIG_HAS_GICV3
 struct gic_v3 v3;
 #endif
 };
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 005f822..a2fccc0 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -336,7 +336,7 @@ extern void vgic_free_virq(struct domain *d, unsigned int 
virq);
 void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
   paddr_t vbase, uint32_t aliased_offset);
 
-#ifdef HAS_GICV3
+#ifdef CONFIG_HAS_GICV3
 struct rdist_region;
 void vgic_v3_setup_hw(paddr_t dbase,
   unsigned int nr_rdist_regions,
-- 
2.4.10


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

[Xen-devel] [PATCH v7 25/28] build: convert HAS_MEM_PAGING use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_MEM_PAGING defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Razvan Cojocaru 
CC: Tamas K Lengyel 
CC: Daniel De Graaf 
Signed-off-by: Doug Goldstein 
---
 config/x86_32.mk| 1 -
 config/x86_64.mk| 1 -
 xen/Rules.mk| 1 -
 xen/arch/x86/Kconfig| 1 +
 xen/common/Kconfig  | 4 
 xen/common/memory.c | 2 +-
 xen/common/vm_event.c   | 8 
 xen/include/xsm/dummy.h | 2 +-
 xen/include/xsm/xsm.h   | 4 ++--
 xen/xsm/dummy.c | 2 +-
 xen/xsm/flask/hooks.c   | 4 ++--
 11 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/config/x86_32.mk b/config/x86_32.mk
index ed69447..cf3d27f 100644
--- a/config/x86_32.mk
+++ b/config/x86_32.mk
@@ -6,7 +6,6 @@ CONFIG_MIGRATE := y
 CONFIG_XCUTILS := y
 
 HAS_MEM_ACCESS := y
-HAS_MEM_PAGING := y
 HAS_MEM_SHARING := y
 
 CFLAGS += -m32 -march=i686
diff --git a/config/x86_64.mk b/config/x86_64.mk
index f74611f..4880681 100644
--- a/config/x86_64.mk
+++ b/config/x86_64.mk
@@ -7,7 +7,6 @@ CONFIG_MIGRATE := y
 CONFIG_XCUTILS := y
 
 HAS_MEM_ACCESS := y
-HAS_MEM_PAGING := y
 HAS_MEM_SHARING := y
 
 CONFIG_XEN_INSTALL_SUFFIX := .gz
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 9e2cff6..38c29b2 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -59,7 +59,6 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
-CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
 CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index bbd278e..acd9cbf 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -10,6 +10,7 @@ config X86
select HAS_IOPORTS
select HAS_KEXEC
select HAS_MEM_ACCESS
+   select HAS_MEM_PAGING
select HAS_NS16550
select HAS_PASSTHROUGH
select HAS_PCI
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 1193bbc..946cca2 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -9,6 +9,10 @@ config HAS_DEVICE_TREE
 config HAS_MEM_ACCESS
bool
 
+# Select HAS_MEM_PAGING if mem paging is supported
+config HAS_MEM_PAGING
+   bool
+
 # Select HAS_PDX if PDX is supported
 config HAS_PDX
bool
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 6b3a755..bd8bf75 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1323,7 +1323,7 @@ int prepare_ring_for_helper(
 
 page = get_page_from_gfn(d, gmfn, , P2M_UNSHARE);
 
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 if ( p2m_is_paging(p2mt) )
 {
 if ( page )
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 0fe93dc..2e59e41 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -403,7 +403,7 @@ void vm_event_resume(struct domain *d, struct 
vm_event_domain *ved)
 break;
 #endif
 
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 case VM_EVENT_REASON_MEM_PAGING:
 p2m_mem_paging_resume(d, );
 break;
@@ -502,7 +502,7 @@ int __vm_event_claim_slot(struct domain *d, struct 
vm_event_domain *ved,
 return vm_event_grab_slot(ved, (current->domain != d));
 }
 
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 /* Registered with Xen-bound event channel for incoming notifications. */
 static void mem_paging_notification(struct vcpu *v, unsigned int port)
 {
@@ -530,7 +530,7 @@ static void mem_sharing_notification(struct vcpu *v, 
unsigned int port)
 /* Clean up on domain destruction */
 void vm_event_cleanup(struct domain *d)
 {
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 if ( d->vm_event->paging.ring_page )
 {
 /* Destroying the wait queue head means waking up all
@@ -592,7 +592,7 @@ int vm_event_domctl(struct domain *d, 
xen_domctl_vm_event_op_t *vec,
 
 switch ( vec->mode )
 {
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 case XEN_DOMCTL_VM_EVENT_OP_PAGING:
 {
 struct vm_event_domain *ved = >vm_event->paging;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index bdc7d1b..2825226 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -568,7 +568,7 @@ static XSM_INLINE int xsm_mem_access(XSM_DEFAULT_ARG struct 
domain *d)
 }
 #endif
 
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 static XSM_INLINE int xsm_mem_paging(XSM_DEFAULT_ARG struct domain *d)
 {
 XSM_ASSERT_ACTION(XSM_DM_PRIV);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 714b3bf..f24b7c3 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -156,7 +156,7 @@ struct xsm_operations {
 int (*mem_access) (struct domain *d);
 #endif
 
-#ifdef 

[Xen-devel] [PATCH v7 28/28] build: convert CONFIG_COMPAT to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_COMPAT defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
---
 config/x86_64.mk | 1 -
 xen/arch/x86/Kconfig | 7 +++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/config/x86_64.mk b/config/x86_64.mk
index ac13bad..a769ea2 100644
--- a/config/x86_64.mk
+++ b/config/x86_64.mk
@@ -2,7 +2,6 @@ CONFIG_X86 := y
 CONFIG_X86_64 := y
 CONFIG_X86_$(XEN_OS) := y
 
-CONFIG_COMPAT := y
 CONFIG_MIGRATE := y
 CONFIG_XCUTILS := y
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 1d8e237..998d494 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -25,6 +25,13 @@ config ARCH_DEFCONFIG
 
 menu "Architecture Features"
 
+config COMPAT
+   def_bool y
+   help
+ 32-bit interface support on 64-bit Xen which is used for both
+ HVM and PV guests. HVMLoader makes 32-bit hypercalls irrespective
+ of the destination runmode of the guest.
+
 endmenu
 
 source "common/Kconfig"
-- 
2.4.10


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