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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 9fba84ac6ef01a0debf0cb823dd9eedb491bf1de
baseline version:
 ovmf 42b85551615d62fb68f0dbd63c068445c4d3c511

Last test of basis   104052  2017-01-06 02:01:09 Z0 days
Testing same since   104054  2017-01-06 05:45:08 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

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



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

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

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

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


Pushing revision :

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 42b85551615d62fb68f0dbd63c068445c4d3c511
baseline version:
 ovmf 74e2b93496778d3242fdb76d2f741365d79222a0

Last test of basis   104038  2017-01-05 07:14:47 Z0 days
Testing same since   104052  2017-01-06 02:01:09 Z0 days1 attempts


People who touched revisions under test:
  Chao Zhang 
  Zhang, Chao B 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [PATCH] 16550: Add command line parsing adjustments

[Swapnil Paratey]

Add parsing options for reg_width and reg_shift in bootup command line
parameters. This adds flexibility in setting register values
for MMIO UART devices.

Increase length of opt_com1 and opt_com2 buffer to accommodate more
command line parameters.

eg. com1=115200,8n1,0x3f8,4 (legacy IO)
eg. com1=115200/300/4/2,8n1,0xfedc9000,4 (MMIO adjustments)

Reviewed-by: Suravee Suthikulpanit 
Signed-off-by: Swapnil Paratey 
---
 docs/misc/xen-command-line.markdown |  2 +-
 xen/drivers/char/ns16550.c  | 20 +---
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 0138978..3297646 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -291,7 +291,7 @@ Flag to indicate whether to probe for a CMOS Real Time 
Clock irrespective of
 ACPI indicating none to be there.
 
 ### com1,com2
-> `= 
[/][,[DPS][,[|pci|amt][,[][,[][,[]]`
+> `= 
[/[][/[][/[[,DPS[,[,[,[,]`
 
 Both option `com1` and `com2` follow the same format.
 
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 1da103a..e076b29 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -33,14 +33,14 @@
 
 /*
  * Configure serial port with a string:
- *   
[/][,DPS[,[,[,[,].
+ *   
[/[][/[][/[[,DPS[,[,[,[,].
  * The tail of the string can be omitted if platform defaults are sufficient.
  * If the baud rate is pre-configured, perhaps by a bootloader, then 'auto'
  * can be specified in place of a numeric baud rate. Polled mode is specified
  * by requesting irq 0.
  */
-static char __initdata opt_com1[30] = "";
-static char __initdata opt_com2[30] = "";
+static char __initdata opt_com1[50] = "";
+static char __initdata opt_com2[50] = "";
 string_param("com1", opt_com1);
 string_param("com2", opt_com2);
 
@@ -1118,6 +1118,20 @@ static void __init ns16550_parse_port_config(
 uart->clock_hz = simple_strtoul(conf, , 0) << 4;
 }
 
+if ( *conf == '/' )
+{
+conf++;
+if ( *conf != '/' && *conf != ',' )
+uart->reg_width = simple_strtol(conf, , 0);
+}
+
+if ( *conf == '/' )
+{
+conf++;
+if ( *conf != '/' && *conf != ',' )
+uart->reg_shift = simple_strtol(conf, , 0);
+}
+
 if ( *conf == ',' && *++conf != ',' )
 {
 uart->data_bits = simple_strtoul(conf, , 10);
-- 
1.9.1


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

[Xen-devel] [PATCH RESEND] ns16550: Add command line parsing adjustments

[Swapnil Paratey]

Add parsing options for reg_width and reg_shift in bootup command line
parameters. This adds flexibility in setting register values
for MMIO UART devices.

Increase length of opt_com1 and opt_com2 buffer to accommodate more
command line parameters.

eg. com1=115200,8n1,0x3f8,4 (legacy IO)
eg. com1=115200/300/4/2,8n1,0xfedc9000,4 (MMIO adjustments)

Reviewed-by: Suravee Suthikulpanit 
Signed-off-by: Swapnil Paratey 
---
 docs/misc/xen-command-line.markdown |  2 +-
 xen/drivers/char/ns16550.c  | 20 +---
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 0138978..3297646 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -291,7 +291,7 @@ Flag to indicate whether to probe for a CMOS Real Time 
Clock irrespective of
 ACPI indicating none to be there.
 
 ### com1,com2
-> `= 
[/][,[DPS][,[|pci|amt][,[][,[][,[]]`
+> `= 
[/[][/[][/[[,DPS[,[,[,[,]`
 
 Both option `com1` and `com2` follow the same format.
 
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 1da103a..e076b29 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -33,14 +33,14 @@
 
 /*
  * Configure serial port with a string:
- *   
[/][,DPS[,[,[,[,].
+ *   
[/[][/[][/[[,DPS[,[,[,[,].
  * The tail of the string can be omitted if platform defaults are sufficient.
  * If the baud rate is pre-configured, perhaps by a bootloader, then 'auto'
  * can be specified in place of a numeric baud rate. Polled mode is specified
  * by requesting irq 0.
  */
-static char __initdata opt_com1[30] = "";
-static char __initdata opt_com2[30] = "";
+static char __initdata opt_com1[50] = "";
+static char __initdata opt_com2[50] = "";
 string_param("com1", opt_com1);
 string_param("com2", opt_com2);
 
@@ -1118,6 +1118,20 @@ static void __init ns16550_parse_port_config(
 uart->clock_hz = simple_strtoul(conf, , 0) << 4;
 }
 
+if ( *conf == '/' )
+{
+conf++;
+if ( *conf != '/' && *conf != ',' )
+uart->reg_width = simple_strtol(conf, , 0);
+}
+
+if ( *conf == '/' )
+{
+conf++;
+if ( *conf != '/' && *conf != ',' )
+uart->reg_shift = simple_strtol(conf, , 0);
+}
+
 if ( *conf == ',' && *++conf != ',' )
 {
 uart->data_bits = simple_strtoul(conf, , 10);
-- 
1.9.1


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

[Xen-devel] [PATCH v2] ns16550: Add command line parsing adjustments

[Swapnil Paratey]

Add parsing options for reg_width and reg_shift in bootup command line
parameters. This adds flexibility in setting register values
for MMIO UART devices.

Increase length of opt_com1 and opt_com2 buffer to accommodate more
command line parameters.

eg. com1=115200,8n1,0x3f8,4 (legacy IO)
eg. com1=115200/300/4/2,8n1,0xfedc9000,4 (MMIO adjustments)

Reviewed-by: Suravee Suthikulpanit 
Signed-off-by: Swapnil Paratey 

---
Changed since v1:
  * Changed opt_com1 and opt_com2 array size to 64 (power of 2).
  * Added descriptions for reg_width and reg_shift in
docs/misc/xen-command-line.markdown
  * Changed subject to ns16550 from 16550 for better tracking.
---
 docs/misc/xen-command-line.markdown | 11 ++-
 xen/drivers/char/ns16550.c  | 20 +---
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 0138978..9ab7ead 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -291,7 +291,7 @@ Flag to indicate whether to probe for a CMOS Real Time 
Clock irrespective of
 ACPI indicating none to be there.
 
 ### com1,com2
-> `= 
[/][,[DPS][,[|pci|amt][,[][,[][,[]]`
+> `= 
[/[][/[][/[[,DPS[,[,[,[,]`
 
 Both option `com1` and `com2` follow the same format.
 
@@ -299,6 +299,15 @@ Both option `com1` and `com2` follow the same format.
   the bootloader or other earlier firmware has already set it up.
 * Optionally, the base baud rate (usually the highest baud rate the
   device can communicate at) can be specified.
+* `` is the access size, or width, for programming
+  the UART device registers.  Accepted values are 1 and 4 (bytes).
+  The UART device datasheet defines the register width to be used when
+  reading or writing the registers. This field is optional.
+  The default value is 1.
+* `` is the number of bits to shift the register offset value
+  for programming the UART device registers. The UART device datasheet
+  defines the register shift needed to access the registers properly.
+  This field is optional. The default value is 0.
 * `DPS` represents the number of data bits, the parity, and the number
   of stop bits.
   * `D` is an integer between 5 and 8 for the number of data bits.
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 1da103a..0e80bce 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -33,14 +33,14 @@
 
 /*
  * Configure serial port with a string:
- *   
[/][,DPS[,[,[,[,].
+ *   
[/[][/[][/[[,DPS[,[,[,[,].
  * The tail of the string can be omitted if platform defaults are sufficient.
  * If the baud rate is pre-configured, perhaps by a bootloader, then 'auto'
  * can be specified in place of a numeric baud rate. Polled mode is specified
  * by requesting irq 0.
  */
-static char __initdata opt_com1[30] = "";
-static char __initdata opt_com2[30] = "";
+static char __initdata opt_com1[64] = "";
+static char __initdata opt_com2[64] = "";
 string_param("com1", opt_com1);
 string_param("com2", opt_com2);
 
@@ -1118,6 +1118,20 @@ static void __init ns16550_parse_port_config(
 uart->clock_hz = simple_strtoul(conf, , 0) << 4;
 }
 
+if ( *conf == '/' )
+{
+conf++;
+if ( *conf != '/' && *conf != ',' )
+uart->reg_width = simple_strtol(conf, , 0);
+}
+
+if ( *conf == '/' )
+{
+conf++;
+if ( *conf != '/' && *conf != ',' )
+uart->reg_shift = simple_strtol(conf, , 0);
+}
+
 if ( *conf == ',' && *++conf != ',' )
 {
 uart->data_bits = simple_strtoul(conf, , 10);
-- 
1.9.1


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

[Xen-devel] [qemu-mainline baseline-only test] 68325: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68325 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68325/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  9 debian-di-install fail REGR. vs. 68287

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68287
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68287

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

version targeted for testing:
 qemuu12597061b3fd71f8f97c18acf508241f290d55d5
baseline version:
 qemuudbe2b65566e76d3c3a0c3358285c0336ac61e757

Last test of basis68287  2016-12-29 07:48:22 Z7 days
Testing same since68325  2017-01-05 16:44:59 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Li Qiang 
  Peter Maydell 
  Prasad J Pandit 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuue92fbc753df4fab9ee524b5ea07a51bee8b6bae4
baseline version:
 qemuu12597061b3fd71f8f97c18acf508241f290d55d5

Last test of basis   104044  2017-01-05 11:14:12 Z0 days
Testing same since   104049  2017-01-05 17:13:53 Z0 days1 attempts


People who touched revisions under test:
  Greg Kurz 
  Peter Maydell 
  Stefan Hajnoczi 
  Stefano Stabellini 

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

[Xen-devel] [DOC v3] Xen transport for 9pfs

[Stefano Stabellini]

Changes in v3:
- clarify a few statements
- rename port- to event-channel-
- use grant_ref_t ref[1] instead of ref[]

Changes in v2:
- fix copy/paste error
- rename ring-ref- to ring-ref
- fix memory barriers
- add "verify prod/cons against local copy"
- add a paragraph on high level design
- add a note on the maximum possible max-ring-page-order value
- add mechanisms to avoid unnecessary evtchn notifications

---

# Xen transport for 9pfs version 1 

## Background

9pfs is a network filesystem protocol developed for Plan 9. 9pfs is very
simple and describes a series of commands and responses. It is
completely independent from the communication channels, in fact many
clients and servers support multiple channels, usually called
"transports". For example the Linux client supports tcp and unix
sockets, fds, virtio and rdma.


### 9pfs protocol

This document won't cover the full 9pfs specification. Please refer to
this [paper] and this [website] for a detailed description of it.
However it is useful to know that each 9pfs request and response has the
following header:

struct header {
uint32_t size;
uint8_t id;
uint16_t tag;
} __attribute__((packed));

0 4  57
+-+--++
|  size   |id|tag |
+-+--++

- *size*
The size of the request or response.

- *id*
The 9pfs request or response operation.

- *tag*
Unique id that identifies a specific request/response pair. It is used
to multiplex operations on a single channel.

It is possible to have multiple requests in-flight at any given time.


## Rationale

This document describes a Xen based transport for 9pfs, in the
traditional PV frontend and backend format. The PV frontend is used by
the client to send commands to the server. The PV backend is used by the
9pfs server to receive commands from clients and send back responses.

The transport protocol supports multiple rings up to the maximum
supported by the backend. The size of every ring is also configurable
and can span multiple pages, up to the maximum supported by the backend
(although it cannot be more than 2MB). The design is to exploit
parallelism at the vCPU level and support multiple outstanding requests
simultaneously.

This document does not cover the 9pfs client/server design or
implementation, only the transport for it.


## Xenstore

The frontend and the backend connect via xenstore to exchange
information. The toolstack creates front and back nodes with state
[XenbusStateInitialising]. The protocol node name is **9pfs**.

Multiple rings are supported for each frontend and backend connection.

The following are mandatory xenstore nodes for this protocol.


### Frontend XenBus Nodes

num-rings
 Values: 

 Number of rings. It needs to be lower or equal to max-rings.

event-channel- (event-channel-0, event-channel-1, etc)
 Values: 

 The identifier of the Xen event channel used to signal activity
 in the ring buffer. One for each ring.

ring-ref (ring-ref0, ring-ref1, etc)
 Values: 

 The Xen grant reference granting permission for the backend to
 map a page with information to setup a share ring. One for each
 ring.

### Backend XenBus Nodes

Backend specific properties, written by the backend, read by the
frontend:

version
 Values: 

 Protocol version supported by the backend. Currently the value is
 1.

max-rings
 Values: 

 The maximum supported number of rings per frontend.

max-ring-page-order
 Values: 

 The maximum supported size of a memory allocation in units of
 lb(machine pages), e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
 etc.

Backend configuration nodes, written by the toolstack, read by the
backend:

path
 Values: 

 Host filesystem path to share.

tag
 Values: 

 Alphanumeric tag that identifies the 9pfs share. The client needs
 to know the tag to be able to mount it.

security_model
 Values: "none"

 *none*: files are stored using the same credentials as they are
 created on the guest
 Only "none" is supported in this version of the protocol.


### State Machine

Initialization:

*Front*   *Back*
XenbusStateInitialising   XenbusStateInitialising
- Query virtual device- Query backend device
  properties.   identification data.
- Setup OS device instance.   - Publish backend features
- Allocate and initialize the   and transport parameters
  request ring.  |
- Publish transport parameters   |
  that will be in effect during  

Re: [Xen-devel] [RFC] netif: staging grants for requests

[Stefano Stabellini]

On Thu, 5 Jan 2017, Joao Martins wrote:
> Hey Stefano,
> 
> Thanks a lot for the review and the comments!!
> 
> On 01/04/2017 07:40 PM, Stefano Stabellini wrote:
> > On Wed, 14 Dec 2016, Joao Martins wrote:
> >> # Proposed Extension
> >>
> >> ## Terminology
> >>
> >> `data gref` refers to the reusable/staging grants, whereas `gref` are the
> >> ones that are granted/revoked for each packet being sent. `command ring`
> >> refers to the current ring, whereas `data list` refers to the one proposed
> >> below.
> >>
> >> ## Xenstore
> >>
> >> "feature-staging-grants" is a capability to allow the use of a set of
> >> recycled buffers permanently mapped at the device setup. If
> >> advertised, the frontend will grant a region equivalent to ```maximum 
> >> number
> >> of slots per ring * size of buffer``` where:
> >>
> >>  * `maximum number of slots per ring` is the number of request structure
> >>that can be fit within the command ring. By default a request
> >>structure consumes 16 bytes. The first 64 bytes of a ring are used by
> >>producer and consumer indicies.
> > 
> > This means that by default the number of slots is (4096-64)/16 = 252,
> > correct?
> That would be correct but I made a few mistakes in the writing, despite a
> following paragraph mentioning the correct ring size for both TX and RX.
> The ring slot size is determined by the size of the request or response 
> (being a
> union of request and response structures). This means the ring slot would 
> either
> 8 octets for RX ring or 12 octets for TX ring which in effect translates to:
> 
> RX := (4096 - 64) / 8 = 504
> TX := (4096 - 64) / 12 = 336
> 
> And as Wei correctly mentions both values are rounded down to a power of 2.
> Which results in 256 slots for each ring. I will fix this in the spec.
> 
> >>  * `size of buffer` is the maximum portion of the packet the backend (and
> >>frontend) have negotiated which will be put for each slot of the
> >>`data ring`.
> >>
> >> Which means that for 256 possible packets in ring with 256 bytes of
> >> chosen size the amount of memory to be permanently granted is a region of
> >> 64KB i.e. 16 grefs.
> >>
> >> The lack of "feature-staging-grants" or a value of 0 means that it's not
> >> supported. If feature is present then a second entry "staging-grants-sizes"
> >> must exist and it contains the sizes that can be used per slot. To avoid
> >> frontend clobbering with various different values, we limit to a set of 
> >> fixed
> >> ones semi-colon delimited.
> >>
> >> The allowed values are implementation specific. Examples of good values
> >> include: 256 (protocol/header region), 2048 (fits 1 MSS which is common to 
> >> be
> >> in the linear part of linux packets), 4096 (grant per packet if 
> >> feature-sg=0, for
> >> DPDK/XDP/netmap buffers) and 65535 (maximum packet size i.e.
> >> ```NETIF_NR_SLOTS_MIN * XEN_PAGE_SIZE``` for feature-sg=1).
> > 
> > I am not following. So far we have been talking about two values:
> > - maximum number of slots per ring
> > - size of buffer
> > We have also discussed the number of bytes used for indexes at the
> > beginning of the command ring, which is 64 bytes.
> Right, but these 64 bytes were only mentioned to describe the calculation of
> number of slots.
> 
> > 
> > But now you are introducing a few other values:
> > - protocol/header region
> > - fits 1 MSS which is common to be in the linear part of linux packets
> > - grant per packet
> > - maximum packet size (I take this is the same as size of buffer)
> > 
> > Could you please described what these values represent in more details
> > and how they relate to the two previous values?
> These values I give above are examples/recomendations of valid "size of the
> buffer" values. That multiplied for the number of slots gives how much it is
> granted by the frontend.
> 
> Though I want to be able to say that the backend will copy up to N much bytes 
> to
> these staging grants (or data grefs as terminology used in the doc), before it
> resorts to grant ops.

I think I understand.


> Hence the value of 65536 is the same as 4096 in terms of
> number of data grefs provided, but the backend will just copy less from/to the
> staging area leaving the rest to be used with the command ring grefs (grant
> map/unmap/etc). Does this answer your question?

Which value of 65536 is the same as 4096?  Packet size? Because up to
4096 bytes are copied to staging grants, the rest is dealt with as
usual?


> I went with the simple approach to start with, but I also thought of having a
> small descriptor to describe how much of this staging area is used for packet,
> instead of a fixed negotiated value. But it would leave me with only a length
> field. Unless we could have a hader with the most commonly used extra info 
> slot
> (GSO) as part of this descriptor too, and save 1 slot per packet for GSO/GRO
> packets.

I think that a fixed size is OK. I'll call "N" the max number of bytes
copied to the staging grants. 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  e5ca20e0f6212dffaba2d3a0b966b71d9ab1ea91
baseline version:
 xen  44325775f7241311087558bb895d1a18100d589f

Last test of basis   104040  2017-01-05 08:35:30 Z0 days
Testing same since   104047  2017-01-05 15:43:30 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chao Gao 
  Jan Beulich 
  Kevin Tian 
  Quan Xu 

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

[Xen-devel] [xen-unstable baseline-only test] 68323: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68323 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68323/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 68319
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 68319

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 68319
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68319
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68319
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 68319

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   6 xen-buildfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-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-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-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-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 build-i386-rumprun6 xen-buildfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  44325775f7241311087558bb895d1a18100d589f
baseline version:
 xen  e03d4e867456cf4e288aee79b04da05d3626c242

Last test of basis68319  2017-01-04 18:18:45 Z1 days
Testing same since68323  2017-01-05 09:47:43 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andy Shevchenko 
  Jan Beulich 
  Len Brown 
  Piotr Luc 

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

Re: [Xen-devel] [RFC PATCH v2 23/26] ARM: vITS: handle INVALL command

[Stefano Stabellini]

On Thu, 22 Dec 2016, Andre Przywara wrote:
> The INVALL command instructs an ITS to invalidate the configuration
> data for all LPIs associated with a given redistributor (read: VCPU).
> This is nasty to emulate exactly with our architecture, so we just scan
> the pending table and inject _every_ LPI found there that got enabled.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/vgic-its.c | 36 
>  1 file changed, 36 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index bcabb04..c130d98 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -297,6 +297,39 @@ out_unlock:
>  return ret;
>  }
>  
> +/* INVALL updates the per-LPI configuration status for every LPI mapped to
> + * a particular redistributor. Since our property table is referenced when
> + * needed, we don't need to sync anything, really. But we have to take care
> + * of LPIs getting enabled if there is an interrupt pending.
> + * To catch every LPI without iterating through the device table we just
> + * look for set bits in our virtual pending table and check the status of
> + * the enabled bit in the respective property table entry.
> + * This actually covers every (pending) LPI from every redistributor,
> + * but update_lpi_enabled_status() is a NOP for LPIs not being mapped
> + * to the redistributor/VCPU we are interested in.
> + */
> +static int its_handle_invall(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t collid = its_cmd_get_collection(cmdptr);
> +struct vcpu *vcpu;
> +int vlpi = 0;
> +
> +spin_lock(>its_lock);
> +vcpu = get_vcpu_from_collection(its, collid);
> +spin_unlock(>its_lock);
> +
> +do {
> +vlpi = find_next_bit(vcpu->arch.vgic.pendtable,
> + its->d->arch.vgic.nr_lpis, vlpi);
> +if (vlpi >= its->d->arch.vgic.nr_lpis)
> +break;
> +
> +update_lpi_enabled_status(its, vcpu, vlpi);
> +} while (1);

Looks much better than before


> +return 0;
> +}
> +
>  static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
>  {
>  uint32_t collid = its_cmd_get_collection(cmdptr);
> @@ -490,6 +523,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
> virt_its *its,
>  case GITS_CMD_INV:
>  its_handle_inv(its, cmdptr);
>   break;
> +case GITS_CMD_INVALL:
> +its_handle_invall(its, cmdptr);
> + break;
>  case GITS_CMD_MAPC:
>  its_handle_mapc(its, cmdptr);
>  break;
> -- 
> 2.9.0
> 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  c1450c53d9c82f0cf126454eca92f93158fbb773
baseline version:
 xen  f50e4912b763df0c56c01c163a3d9427794a6905

Last test of basis   104048  2017-01-05 17:01:45 Z0 days
Testing same since   104050  2017-01-05 21:01:55 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Doug Goldstein 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v2] ns16550: Add command line parsing adjustments

[Andrew Cooper]

On 05/01/17 22:39, Swapnil Paratey wrote:
> Add parsing options for reg_width and reg_shift in bootup command line
> parameters. This adds flexibility in setting register values
> for MMIO UART devices.
>
> Increase length of opt_com1 and opt_com2 buffer to accommodate more
> command line parameters.
>
> eg. com1=115200,8n1,0x3f8,4 (legacy IO)
> eg. com1=115200/300/4/2,8n1,0xfedc9000,4 (MMIO adjustments)
>
> Reviewed-by: Suravee Suthikulpanit 
> Signed-off-by: Swapnil Paratey 

Much better, thanks.

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 1/3] x86emul: support load forms of {, V}MOV{D, Q}

[Andrew Cooper]

On 14/12/16 09:55, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -4995,6 +4995,12 @@ x86_emulate(
>   /* vmovntdq ymm,m256 */
>  fail_if(ea.type != OP_MEM);
>  /* fall through */
> +case X86EMUL_OPC(0x0f, 0x6e):/* movd r/m32,mm */
> + /* movq r/m64,mm */
> +case X86EMUL_OPC_66(0x0f, 0x6e): /* movd r/m32,xmm */
> + /* movq r/m64,xmm */
> +case X86EMUL_OPC_VEX_66(0x0f, 0x6e): /* vmovd r/m32,xmm */
> + /* vmovq r/m64,xmm */
>  case X86EMUL_OPC(0x0f, 0x6f):/* movq mm/m64,mm */
>  case X86EMUL_OPC_66(0x0f, 0x6f): /* movdqa xmm/m128,xmm */
>  case X86EMUL_OPC_F3(0x0f, 0x6f): /* movdqu xmm/m128,xmm */
> @@ -5008,6 +5014,8 @@ x86_emulate(
>   /* movq xmm,r/m64 */
>  case X86EMUL_OPC_VEX_66(0x0f, 0x7e): /* vmovd xmm,r/m32 */
>   /* vmovq xmm,r/m64 */
> +case X86EMUL_OPC_F3(0x0f, 0x7e): /* movq xmm/m64,xmm */
> +case X86EMUL_OPC_VEX_F3(0x0f, 0x7e): /* vmovq xmm/m64,xmm */
>  case X86EMUL_OPC(0x0f, 0x7f):/* movq mm,mm/m64 */
>  case X86EMUL_OPC_66(0x0f, 0x7f): /* movdqa xmm,xmm/m128 */
>  case X86EMUL_OPC_VEX_66(0x0f, 0x7f): /* vmovdqa xmm,xmm/m128 */
> @@ -5019,6 +5027,7 @@ x86_emulate(
>  case X86EMUL_OPC_VEX_66(0x0f, 0xd6): /* vmovq xmm,xmm/m64 */
>  {
>  uint8_t *buf = get_stub(stub);
> +bool load = false;

I am afraid that this logic is already almost-opaque, and these change
make it even more complicated to follow.  Sufficiently so that I can't
review it; I have tried and failed to look at the end result and
conclude whether it is correct or not.

(I have no specific reasons to think that it isn't correct, but I can't
claim to have reviewed it with integrity.)

This block of code in particular has a higher security risk than most in
x86_emulate(), because of the risk of accidentally executing a stub with
a modrm which selects anything other than SIMD register or (%rax) r/m
destination.

Therefore, I'd like to see what we can do to make the logic easier to
follow.


This block deals with 3 kinds of operations, load / move / store,
depending on the whether the source operand is memory, both operands are
registers, or the destination operand is memory.  Beyond that however,
there doesn't appear to be any consistency to the required adjustments
to make the stub safe.

At a start, vex.pfx continues to be a source of confusion as it refers
to legacy prefixes rather than the vex prefix, and vex.opcx being the
entity which refers to legacy/vex/evex/xop encoding.  Renaming these
constants alone would be a help.

I wonder if doing things like this would help?

enum { LOAD, MOVE, STORE } type;

switch ( b )
{
case ...
type = LOAD;
break;
case ...
type = MOVE;
break;
case ...
type = STORE;
break;
}

In particular, having a 128 line case statement (before this patch, 149
after), with most semantics based on b == one of 5 (before, 7 after)
different raw numbers, is too much cognitive context to hold.

~Andrew

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

Re: [Xen-devel] [RFC PATCH v2 13/26] ARM: vGICv3: Handle disabled LPIso

[Stefano Stabellini]

On Thu, 22 Dec 2016, Andre Przywara wrote:
> If a guest disables an LPI, we do not forward this to the associated
> host LPI to avoid queueing commands to the host ITS command queue.
> So it may happen that an LPI fires nevertheless on the host. In this
> case we can bail out early, but have to save the pending state on the
> virtual side.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/gic-its.c |  8 
>  xen/arch/arm/vgic-v3.c | 12 
>  xen/include/asm-arm/vgic.h |  1 +
>  3 files changed, 21 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> index 602e19a..54e604a 100644
> --- a/xen/arch/arm/gic-its.c
> +++ b/xen/arch/arm/gic-its.c
> @@ -104,6 +104,14 @@ void do_LPI(unsigned int lpi)
>  
>  vcpu = d->vcpu[hlpi.vcpu_id];
>  
> +/*
> + * We keep all host LPIs enabled, so check if it's disabled on the guest
> + * side and just record this LPI in the virtual pending table in this 
> case.
> + * The guest picks it up once it gets enabled again.
> + */
> +if ( !vgic_can_inject_lpi(vcpu, hlpi.virt_lpi) )
> +return;

I suggest vgic_can_inject_lpi doesn't only return true or false, but
also if the vlpi is already set to pending. In that case, I think we
should disable the plpi to avoid storms (also see
http://marc.info/?l=xen-devel=148055519432739).


>  vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
>  }
>  
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index b981d4e..206e00b 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -483,6 +483,18 @@ bool vgic_lpi_is_enabled(struct domain *d, uint32_t vlpi)
>  return d->arch.vgic.proptable[vlpi - 8192] & LPI_PROP_ENABLED;
>  }
>  
> +bool vgic_can_inject_lpi(struct vcpu *vcpu, uint32_t vlpi)
> +{
> +if ( vlpi >= vcpu->domain->arch.vgic.nr_lpis )
> +return false;
> +
> +if ( vgic_lpi_is_enabled(vcpu->domain, vlpi) )
> +return true;
> +
> +set_bit(vlpi - 8192, vcpu->arch.vgic.pendtable);
> +return false;
> +}
> +
>  static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
>uint32_t gicr_reg,
>register_t r)
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 1c157d3..73291dd 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -317,6 +317,7 @@ extern void vgic_disable_irqs(struct vcpu *v, uint32_t r, 
> int n);
>  extern void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n);
>  extern bool vgic_lpi_is_enabled(struct domain *d, uint32_t vlpi);
>  extern int vgic_lpi_get_priority(struct domain *d, uint32_t vlpi);
> +extern bool vgic_can_inject_lpi(struct vcpu *v, uint32_t vlpi);
>  extern void register_vgic_ops(struct domain *d, const struct vgic_ops *ops);
>  int vgic_v2_init(struct domain *d, int *mmio_count);
>  int vgic_v3_init(struct domain *d, int *mmio_count);
> -- 
> 2.9.0
> 

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

Re: [Xen-devel] [RFC PATCH v2 12/26] ARM: vGICv3: handle virtual LPI pending and property tables

[Stefano Stabellini]

On Thu, 22 Dec 2016, Andre Przywara wrote:
> Allow a guest to provide the address and size for the memory regions
> it has reserved for the GICv3 pending and property tables.
> We sanitise the various fields of the respective redistributor
> registers and map those pages into Xen's address space to have easy
> access.

Many comments still unaddressed


> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/vgic-v3.c   | 202 
> ---
>  xen/arch/arm/vgic.c  |   4 +
>  xen/include/asm-arm/domain.h |   8 +-
>  xen/include/asm-arm/vgic.h   |   4 +
>  4 files changed, 203 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index 0ffde74..b981d4e 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -20,12 +20,14 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -229,12 +231,14 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu 
> *v, mmio_info_t *info,
>  goto read_reserved;
>  
>  case VREG64(GICR_PROPBASER):
> -/* LPI's not implemented */
> -goto read_as_zero_64;
> +if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> +*r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);
> +return 1;
>  
>  case VREG64(GICR_PENDBASER):
> -/* LPI's not implemented */
> -goto read_as_zero_64;
> +if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> +*r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
> +return 1;
>  
>  case 0x0080:
>  goto read_reserved;
> @@ -302,11 +306,6 @@ bad_width:
>  domain_crash_synchronous();
>  return 0;
>  
> -read_as_zero_64:
> -if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> -*r = 0;
> -return 1;
> -
>  read_as_zero_32:
>  if ( dabt.size != DABT_WORD ) goto bad_width;
>  *r = 0;
> @@ -331,6 +330,143 @@ read_unknown:
>  return 1;
>  }
>  
> +static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
> +int field_shift,
> +uint64_t (*sanitise_fn)(uint64_t))
> +{
> +uint64_t field = (reg & field_mask) >> field_shift;
> +
> +field = sanitise_fn(field) << field_shift;
> +return (reg & ~field_mask) | field;
> +}
> +
> +/* We want to avoid outer shareable. */
> +static uint64_t vgic_sanitise_shareability(uint64_t field)
> +{
> +switch (field) {
> +case GIC_BASER_OuterShareable:
> +return GIC_BASER_InnerShareable;
> +default:
> +return field;
> +}
> +}
> +
> +/* Avoid any inner non-cacheable mapping. */
> +static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
> +{
> +switch (field) {
> +case GIC_BASER_CACHE_nCnB:
> +case GIC_BASER_CACHE_nC:
> +return GIC_BASER_CACHE_RaWb;
> +default:
> +return field;
> +}
> +}
> +
> +/* Non-cacheable or same-as-inner are OK. */
> +static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
> +{
> +switch (field) {
> +case GIC_BASER_CACHE_SameAsInner:
> +case GIC_BASER_CACHE_nC:
> +return field;
> +default:
> +return GIC_BASER_CACHE_nC;
> +}
> +}
> +
> +static uint64_t sanitize_propbaser(uint64_t reg)
> +{
> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
> +  GICR_PROPBASER_SHAREABILITY_SHIFT,
> +  vgic_sanitise_shareability);
> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
> +  GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
> +  vgic_sanitise_inner_cacheability);
> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
> +  GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
> +  vgic_sanitise_outer_cacheability);
> +
> +reg &= ~PROPBASER_RES0_MASK;
> +reg &= ~GENMASK(51, 48);
> +return reg;
> +}
> +
> +static uint64_t sanitize_pendbaser(uint64_t reg)
> +{
> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
> +  GICR_PENDBASER_SHAREABILITY_SHIFT,
> +  vgic_sanitise_shareability);
> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_INNER_CACHEABILITY_MASK,
> +  GICR_PENDBASER_INNER_CACHEABILITY_SHIFT,
> +  vgic_sanitise_inner_cacheability);
> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_OUTER_CACHEABILITY_MASK,
> +  GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT,
> +  vgic_sanitise_outer_cacheability);
> +
> +reg &= ~PENDBASER_RES0_MASK;
> +reg &= ~GENMASK(51, 48);
> +return reg;
> +}
> 

Re: [Xen-devel] [RFC PATCH v2 10/26] ARM: GICv3: forward pending LPIs to guests

[Stefano Stabellini]

On Thu, 22 Dec 2016, Andre Przywara wrote:
> Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
> number to get this IRQ injected.
> Iterate our two-level LPI table to find this information quickly when
> the host takes an LPI. Call the existing injection function to let the
> GIC emulation deal with this interrupt.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/gic-its.c| 35 +++
>  xen/arch/arm/gic.c|  6 --
>  xen/include/asm-arm/irq.h |  8 
>  3 files changed, 47 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> index e7ddd90..0d4ca1b 100644
> --- a/xen/arch/arm/gic-its.c
> +++ b/xen/arch/arm/gic-its.c
> @@ -72,6 +72,41 @@ static union host_lpi *gic_get_host_lpi(uint32_t plpi)
>  return _data.host_lpis[plpi / HOST_LPIS_PER_PAGE][plpi % 
> HOST_LPIS_PER_PAGE];
>  }
>  
> +/* Handle incoming LPIs, which are a bit special, because they are 
> potentially
> + * numerous and also only get injected into guests. Treat them specially 
> here,
> + * by just looking up their target vCPU and virtual LPI number and hand it
> + * over to the injection function.
> + */
> +void do_LPI(unsigned int lpi)
> +{
> +struct domain *d;
> +union host_lpi *hlpip, hlpi;
> +struct vcpu *vcpu;
> +
> +WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
> +
> +hlpip = gic_get_host_lpi(lpi);
> +if ( !hlpip )
> +return;
> +
> +hlpi.data = hlpip->data;

Why can't we just reference hlpip directly throughout this function? Is
it for atomicity reasons?


> +/* We may have mapped more host LPIs than the guest actually asked for. 
> */
> +if ( !hlpi.virt_lpi )
> +return;
> +
> +d = get_domain_by_id(hlpi.dom_id);
> +if ( !d )
> +return;
> +
> +if ( hlpi.vcpu_id >= d->max_vcpus )
> +return;
> +
> +vcpu = d->vcpu[hlpi.vcpu_id];
> +
> +vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
> +}
> +
>  #define ITS_CMD_QUEUE_SZSZ_64K
>  
>  static int its_send_command(struct host_its *hw_its, void *its_cmd)
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 6f25501..7d428dc 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -700,8 +700,10 @@ void gic_interrupt(struct cpu_user_regs *regs, int 
> is_fiq)
>  local_irq_enable();
>  do_IRQ(regs, irq, is_fiq);
>  local_irq_disable();
> -}
> -else if (unlikely(irq < 16))
> +} else if ( irq >= 8192 )
> +{
> +do_LPI(irq);
> +} else if ( unlikely(irq < 16) )
>  {
>  do_sgi(regs, irq);
>  }
> diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
> index 8f7a167..ee47de8 100644
> --- a/xen/include/asm-arm/irq.h
> +++ b/xen/include/asm-arm/irq.h
> @@ -34,6 +34,14 @@ struct irq_desc *__irq_to_desc(int irq);
>  
>  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
>  
> +#ifdef CONFIG_HAS_ITS
> +void do_LPI(unsigned int irq);
> +#else
> +static inline void do_LPI(unsigned int irq)
> +{
> +}
> +#endif
> +
>  #define domain_pirq_to_irq(d, pirq) (pirq)
>  
>  bool_t is_assignable_irq(unsigned int irq);
> -- 
> 2.9.0
> 

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

Re: [Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability

[Stefano Stabellini]

On Wed, 4 Jan 2017, George Dunlap wrote:
> The Xen Security Team has dealt with a number of issues recently where
> it wasn't exactly clear whether we should issue an advisory or not:
> the Xen Security Response Process only mentiones "'vulnerabilities",
> without specifying what constitutes a vulnerability.
> 
> Issuing advisories has a cost: It costs the security team significant
> amounts of time to craft and send the advisories; it costs many of our
> downstreams time to apply, build, and test patches; and every advisory
> has the risk that it will be picked up and blown out of proportion by
> the media.  So we want to make sure to only issue advisories for
> issues that are worth the cost.
> 
> We would like guidelines from the community about what sorts of issues
> should be considered security issues (and thus will have advisories
> issued).  Below is a draft of a section I* am proposing to be added to
> the Xen Security Policy, just under the section "Specific Process".
> 
> Most of it is just encoding long-established practice.  But there are
> two key changes and / or clarifications that deserve attention and
> discussion: criteria 2c (leaking of mundane information will not be
> considered a security issue unless it may contain sensitive guest or
> user data), and 4 (if no known operating systems are vulnerable to a
> bug, no advisory will be issued).
> 
> Please give feedback.  Thanks!
> 
> * This has my own proposal; it is inspired by discussions the security
> team has had, but it has not been vetted by them.
> 
> 
> 
> # Scope of vulnerabilities covered by this process
> 
> All security issues are bugs, but not all bugs are security issues.
> This section is meant to be a guide from the Xen community to the Xen
> security response team regarding which bugs should have advisories
> issued for them.  Discoverers are encouraged to err on the side of
> caution and report any potential vulnerabilities to the security team.
> These guidelines are not meant to be set in stone; if they do not fit
> your needs as a user, please raise the issue on xen-devel.
> 
> Every potential vulnerability will have a source context, an effect,
> and a target effect context.  For instance, a bug may allow a guest
> user (source context) to escalate their privileges (effect) to that of
> the guest kernel (target context); or it may allow a guest
> administrator (source context) to severely degrade the disk
> performance (effect) of another guest (target context).
> 
> Only the following source/target context pairs will be considered
> vulnerabilities:
> 
> 1a. The source is the guest userspace, guest kernel, or QEMU stubdomain,
> and the target is the hypervisor, dom0 and toolstack.
> 
> 1b. The source is the guest userspace, guest kernel, or QEMU
> stubdomain, and the target is another guest.
> 
> 1c. The source is guest userspace, and the target is the guest kernel,
> or other guest userspace processes.
> 
> This means, for instance, that bug which allows a guest kernel to
> perform a DoS on itself will not be considered a security
> vulnerability.  It also means, at the moment, that the security team
> will not issue advisories for highly disaggregated environments.
> 
> Only some effects are considered vulnerabilities; and whether they are
> vulnerabilities depends on the target context:
> 
> 2a. Privilege escalation: causing arbitrary code to be run in the target
> context.  This will be considered a vulnerability in all cases above (1a-c).
> 
> 2b. Denial of service: Causing termination of or significant
> degradation of performance in the target context.  This will be
> considered a vulnerability in all cases above (1a-c).
> 
> 2c. Information leakage: The attacker in the source context is able to
> obtain information from the target context.  This will be considered a
> vulnerability in all cases in 1b and 1c.  It will only be considered a
> vulnerability in the case of 1a if information obtained is considered
> sensitive in and of itself: for example, host administrator passwords
> or information about other users on the host.
> 
> In particular, information leakage from Xen, domain 0, or the
> toolstack to an unprivileged guest will *not* be considered a
> vulnerability unless there is a chance that that information may
> contain information from a guest, or other sensitive information from
> domain 0.  For instance, copying uninitialized data from Xen's stack
> will generally be considered a vulnerability, because it may contain
> stale guest data.  But if it can be shown that the data copied will
> always be Xen-internal information (for instance, pointers or other
> internal structures), then an advisory will not be issued.  This is
> the case even if that information could be useful in making another
> exploit more effective (for instance, if it exposed virtual addresses
> of sensitive data structures).
> 
> 3. The security team will only issue advisories for certain
> configurations.  Bugs in Xen 

Re: [Xen-devel] [RFC PATCH v2 09/26] ARM: GICv3: introduce separate pending_irq structs for LPIs

[Stefano Stabellini]

On Thu, 22 Dec 2016, Andre Przywara wrote:
> For the same reason that allocating a struct irq_desc for each
> possible LPI is not an option, having a struct pending_irq for each LPI
> is also not feasible. However we actually only need those when an
> interrupt is on a vCPU (or is about to be injected).
> Maintain a list of those structs that we can use for the lifecycle of
> a guest LPI. We allocate new entries if necessary, however reuse
> pre-owned entries whenever possible.
> I added some locking around this list here, however my gut feeling is
> that we don't need one because this a per-VCPU structure anyway.
> If someone could confirm this, I'd be grateful.

I don't think the list should be per-VCPU, because the underlying LPIs
are global. Similarly, the struct pending_irq array is per-domain, only
the first 32 (PPIs) are per vcpu. Besides, it shouldn't be a list :-)


> Teach the existing VGIC functions to find the right pointer when being
> given a virtual LPI number.
> 
> Signed-off-by: Andre Przywara 

Most of my comments on the previous version of the patch are still
unaddressed.


> ---
>  xen/arch/arm/gic.c   |  3 +++
>  xen/arch/arm/vgic-v3.c   | 11 
>  xen/arch/arm/vgic.c  | 64 
> +---
>  xen/include/asm-arm/domain.h |  2 ++
>  xen/include/asm-arm/vgic.h   | 10 +++
>  5 files changed, 87 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index a5348f2..6f25501 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -509,6 +509,9 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>  struct vcpu *v_target = vgic_get_target_vcpu(v, irq);
>  irq_set_affinity(p->desc, cpumask_of(v_target->processor));
>  }
> +/* If this was an LPI, mark this struct as available again. */
> +if ( p->irq >= 8192 )
> +p->irq = 0;
>  }
>  }
>  }
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index d61479d..0ffde74 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -331,6 +331,14 @@ read_unknown:
>  return 1;
>  }
>  
> +int vgic_lpi_get_priority(struct domain *d, uint32_t vlpi)
> +{
> +if ( vlpi >= d->arch.vgic.nr_lpis )
> +return GIC_PRI_IRQ;
> +
> +return d->arch.vgic.proptable[vlpi - 8192] & 0xfc;
> +}
> +
>  static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
>uint32_t gicr_reg,
>register_t r)
> @@ -1426,6 +1434,9 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
>  if ( v->vcpu_id == last_cpu || (v->vcpu_id == (d->max_vcpus - 1)) )
>  v->arch.vgic.flags |= VGIC_V3_RDIST_LAST;
>  
> +spin_lock_init(>arch.vgic.pending_lpi_list_lock);
> +INIT_LIST_HEAD(>arch.vgic.pending_lpi_list);
> +
>  return 0;
>  }
>  
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index de77aaa..f15eb3e 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -31,6 +31,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, int rank)
>  {
> @@ -61,7 +63,7 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, 
> unsigned int irq)
>  return vgic_get_rank(v, rank);
>  }
>  
> -static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
> +void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
>  {
>  INIT_LIST_HEAD(>inflight);
>  INIT_LIST_HEAD(>lr_queue);
> @@ -247,10 +249,14 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v, 
> unsigned int virq)
>  
>  static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
>  {
> -struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
> +struct vgic_irq_rank *rank;
>  unsigned long flags;
>  int priority;
>  
> +if ( virq >= 8192 )
> +return vgic_lpi_get_priority(v->domain, virq);
> +
> +rank = vgic_rank_irq(v, virq);
>  vgic_lock_rank(v, rank, flags);
>  priority = rank->priority[virq & INTERRUPT_RANK_MASK];
>  vgic_unlock_rank(v, rank, flags);
> @@ -449,13 +455,63 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum 
> gic_sgi_mode irqmode,
>  return true;
>  }
>  
> +/*
> + * Holding struct pending_irq's for each possible virtual LPI in each domain
> + * requires too much Xen memory, also a malicious guest could potentially
> + * spam Xen with LPI map requests. We cannot cover those with (guest 
> allocated)
> + * ITS memory, so we use a dynamic scheme of allocating struct pending_irq's
> + * on demand.
> + */
> +struct pending_irq *lpi_to_pending(struct vcpu *v, unsigned int lpi,
> +   bool allocate)
> +{
> +struct lpi_pending_irq *lpi_irq, *empty = NULL;
> +
> +spin_lock(>arch.vgic.pending_lpi_list_lock);
> +

Re: [Xen-devel] [RFC PATCH v2 08/26] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

[Stefano Stabellini]

On Thu, 22 Dec 2016, Andre Przywara wrote:
> To get MSIs from devices forwarded to a CPU, we need to name the device
> and its MSIs by mapping them to an ITS.
> Since this involves queueing commands to the ITS command queue, we can't
> really afford to do this during the guest's runtime, as this would open
> up a denial-of-service attack vector.
> So we require every device with MSI interrupts to be mapped explicitly by
> Dom0. For Dom0 itself we can just use the existing PCI physdev_op
> hypercalls, which the existing Linux kernel issues already.
> So upon receipt of this hypercall we map the device to the hardware ITS
> and prepare it to be later mapped by the virtual ITS by using the very
> same device ID (for Dom0 only).
> Also we ask for mapping 32 LPIs to cover 32 MSIs that the device may
> use.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/physdev.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
> index 27bbbda..d9e6be3 100644
> --- a/xen/arch/arm/physdev.c
> +++ b/xen/arch/arm/physdev.c
> @@ -9,11 +9,35 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  
>  int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
> +struct physdev_manage_pci manage;
> +struct domain *dom0;
> +u32 devid;
> +int ret;
> +
> +switch (cmd)
> +{
> +case PHYSDEVOP_manage_pci_add:
> +case PHYSDEVOP_manage_pci_remove:
> +if ( copy_from_guest(, arg, 1) != 0 )
> +return -EFAULT;
> +
> +dom0 = hardware_domain;

Please don't effectively name dom0 hardware_domain, just use
hardware_domain directly.


> +devid = manage.bus << 8 | manage.devfn;
> +/* Allocate an ITS device table with space for 32 MSIs */
> +ret = gicv3_its_map_device(dom0, devid, devid, 5,
> +   cmd == PHYSDEVOP_manage_pci_add);

Why 32? Is it an arbitrary number? Shouldn't we figure out exactly the
number of events the device need?


> +put_domain(dom0);

Where is the correspondent get_domain?


> +return ret;
> +}
> +
>  gdprintk(XENLOG_DEBUG, "PHYSDEVOP cmd=%d: not implemented\n", cmd);
>  return -ENOSYS;
>  }
> -- 
> 2.9.0
> 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 74e2b93496778d3242fdb76d2f741365d79222a0
baseline version:
 ovmf a6e0e994d0e855f7f65f6fb7e113f061e0b9a242

Last test of basis68321  2017-01-05 05:18:55 Z0 days
Testing same since68324  2017-01-05 12:46:58 Z0 days1 attempts


People who touched revisions under test:
  Chao Zhang 
  Dandan Bi 
  Zhang, Chao B 

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



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

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

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


Push not applicable.


commit 74e2b93496778d3242fdb76d2f741365d79222a0
Author: Dandan Bi 
Date:   Thu Jan 5 10:17:23 2017 +0800

MdeModulePkg/StaControllerDxe: Fix coding style issue

Remove the empty line.

Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Feng Tian 

commit bc83ca81ab3a756f037288b2b4b2fe1d3e8e16c3
Author: Dandan Bi 
Date:   Thu Jan 5 13:03:53 2017 +0800

MdeModulePkg/DxeCapsuleLibFmp: Fix incorrect MODULE_TYPE

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Jiewen Yao 

commit b3724a03d6df2aa5c51c951a14fbbf305bf45d0c
Author: Zhang, Chao B 
Date:   Thu Jan 5 10:16:16 2017 +0800

SecurityPkg: Add Pcd PROMPT/HELP & Chang default setting

Update PCD PcdTcg2PhysicalPresenceFlags default setting. Also add PROMPT,
HELP string.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
Reviewed-by: Star Zeng 

commit 3304abc101a19735c29d8b48a270576e72e7049e
Author: Zhang, Chao B 
Date:   Thu Jan 5 10:11:07 2017 +0800

SecuritPkg: Tcg2: Fix coding style issue

Fix coding style issue

Cc: Bi Dandan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
Reviewed-by: Bi Dandan 

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

Re: [Xen-devel] [RFC] netif: staging grants for requests

[Joao Martins]

Hey Stefano,

Thanks a lot for the review and the comments!!

On 01/04/2017 07:40 PM, Stefano Stabellini wrote:
> On Wed, 14 Dec 2016, Joao Martins wrote:
>> # Proposed Extension
>>
>> ## Terminology
>>
>> `data gref` refers to the reusable/staging grants, whereas `gref` are the
>> ones that are granted/revoked for each packet being sent. `command ring`
>> refers to the current ring, whereas `data list` refers to the one proposed
>> below.
>>
>> ## Xenstore
>>
>> "feature-staging-grants" is a capability to allow the use of a set of
>> recycled buffers permanently mapped at the device setup. If
>> advertised, the frontend will grant a region equivalent to ```maximum number
>> of slots per ring * size of buffer``` where:
>>
>>  * `maximum number of slots per ring` is the number of request structure
>>that can be fit within the command ring. By default a request
>>structure consumes 16 bytes. The first 64 bytes of a ring are used by
>>producer and consumer indicies.
> 
> This means that by default the number of slots is (4096-64)/16 = 252,
> correct?
That would be correct but I made a few mistakes in the writing, despite a
following paragraph mentioning the correct ring size for both TX and RX.
The ring slot size is determined by the size of the request or response (being a
union of request and response structures). This means the ring slot would either
8 octets for RX ring or 12 octets for TX ring which in effect translates to:

RX := (4096 - 64) / 8 = 504
TX := (4096 - 64) / 12 = 336

And as Wei correctly mentions both values are rounded down to a power of 2.
Which results in 256 slots for each ring. I will fix this in the spec.

>>  * `size of buffer` is the maximum portion of the packet the backend (and
>>frontend) have negotiated which will be put for each slot of the
>>`data ring`.
>>
>> Which means that for 256 possible packets in ring with 256 bytes of
>> chosen size the amount of memory to be permanently granted is a region of
>> 64KB i.e. 16 grefs.
>>
>> The lack of "feature-staging-grants" or a value of 0 means that it's not
>> supported. If feature is present then a second entry "staging-grants-sizes"
>> must exist and it contains the sizes that can be used per slot. To avoid
>> frontend clobbering with various different values, we limit to a set of fixed
>> ones semi-colon delimited.
>>
>> The allowed values are implementation specific. Examples of good values
>> include: 256 (protocol/header region), 2048 (fits 1 MSS which is common to be
>> in the linear part of linux packets), 4096 (grant per packet if 
>> feature-sg=0, for
>> DPDK/XDP/netmap buffers) and 65535 (maximum packet size i.e.
>> ```NETIF_NR_SLOTS_MIN * XEN_PAGE_SIZE``` for feature-sg=1).
> 
> I am not following. So far we have been talking about two values:
> - maximum number of slots per ring
> - size of buffer
> We have also discussed the number of bytes used for indexes at the
> beginning of the command ring, which is 64 bytes.
Right, but these 64 bytes were only mentioned to describe the calculation of
number of slots.

> 
> But now you are introducing a few other values:
> - protocol/header region
> - fits 1 MSS which is common to be in the linear part of linux packets
> - grant per packet
> - maximum packet size (I take this is the same as size of buffer)
> 
> Could you please described what these values represent in more details
> and how they relate to the two previous values?
These values I give above are examples/recomendations of valid "size of the
buffer" values. That multiplied for the number of slots gives how much it is
granted by the frontend.

Though I want to be able to say that the backend will copy up to N much bytes to
these staging grants (or data grefs as terminology used in the doc), before it
resorts to grant ops. Hence the value of 65536 is the same as 4096 in terms of
number of data grefs provided, but the backend will just copy less from/to the
staging area leaving the rest to be used with the command ring grefs (grant
map/unmap/etc). Does this answer your question?

I went with the simple approach to start with, but I also thought of having a
small descriptor to describe how much of this staging area is used for packet,
instead of a fixed negotiated value. But it would leave me with only a length
field. Unless we could have a hader with the most commonly used extra info slot
(GSO) as part of this descriptor too, and save 1 slot per packet for GSO/GRO
packets.

>> Individual size covered per entry by frontend is through ```tx-data-len``` or
>> ```rx-data-len``` which contains maximum amount of data on a single packet.
>> Chosen values of "tx-data-len" and "rx-data-len" are asymmetrical (hence can
>> be different between TX and RX) are validated against this list of valid 
>> sizes.
>> For it's use see [datapath](#datapath-changes) section further below.
>>
>>  /local/domain/1/device/vif/0/feature-staging-grants = "1"
>>  /local/domain/1/device/vif/0/staging-grants-sizes = 

Re: [Xen-devel] [RFC] netif: staging grants for requests

[Joao Martins]

On 01/04/2017 01:54 PM, Wei Liu wrote:
> Hey!
Hey!

> Thanks for writing this detailed document!
Thanks a lot for the review and comments!

> 
> On Wed, Dec 14, 2016 at 06:11:12PM +, Joao Martins wrote:
>> Hey,
>>
>> Back in the Xen hackaton '16 networking session there were a couple of ideas
>> brought up. One of them was about exploring permanently mapped grants between
>> xen-netback/xen-netfront.
>>
>> I started experimenting and came up with sort of a design document (in 
>> pandoc)
>> on what it would like to be proposed. This is meant as a seed for discussion
>> and also requesting input to know if this is a good direction. Of course, I
>> am willing to try alternatives that we come up beyond the contents of the
>> spec, or any other suggested changes ;)
>>
>> Any comments or feedback is welcome!
>>
>> Cheers,
>> Joao
>>
>> ---
>> % Staging grants for network I/O requests
>> % Joao Martins <>
>> % Revision 1
>>
>> \clearpage
>>
>> 
>> Status: **Experimental**
>>
>> Architecture(s): x86 and ARM
>>
> 
> Any.
OK.

> 
>> Component(s): Guest
>>
>> Hardware: Intel and AMD
> 
> No need to specify this.
OK.

> 
>> 
>>
>> # Background and Motivation
>>
> 
> I skimmed through the middle -- I think you description of transmissions
> in both directions is accurate.
> 
> The proposal to replace some steps with explicit memcpy is also
> sensible.
Glad to hear that!

> 
>> \clearpage
>>
>> ## Performance
>>
>> Numbers that give a rough idea on the performance benefits of this extension.
>> These are Guest <-> Dom0 which test the communication between backend and
>> frontend, excluding other bottlenecks in the datapath (the software switch).
>>
>> ```
>> # grant copy
>> Guest TX (1vcpu,  64b, UDP in pps):  1 506 170 pps
>> Guest TX (4vcpu,  64b, UDP in pps):  4 988 563 pps
>> Guest TX (1vcpu, 256b, UDP in pps):  1 295 001 pps
>> Guest TX (4vcpu, 256b, UDP in pps):  4 249 211 pps
>>
>> # grant copy + grant map (see next subsection)
>> Guest TX (1vcpu, 260b, UDP in pps):577 782 pps
>> Guest TX (4vcpu, 260b, UDP in pps):  1 218 273 pps
>>
>> # drop at the guest network stack
>> Guest RX (1vcpu,  64b, UDP in pps):  1 549 630 pps
>> Guest RX (4vcpu,  64b, UDP in pps):  2 870 947 pps
>> ```
>>
>> With this extension:
>> ```
>> # memcpy
>> data-len=256 TX (1vcpu,  64b, UDP in pps):  3 759 012 pps
>> data-len=256 TX (4vcpu,  64b, UDP in pps): 12 416 436 pps
> 
> This basically means we can almost get line rate for 10Gb link.
> 
> It is already a  good result. I'm interested in knowing if there is
> possibility to approach 40 or 100 Gb/s?
Certainly, so with bulk transfer we can already saturate a 40 Gbit/s NIC,
sending out from a guest to an external host. I got ~80 Gbit/s too but between
guests on the same host (some time ago back in xen 4.7). 100 Gbit/s is also on
my radar.

The problem comes with smaller packets <= MTU (and request/response workloads
with small payloads) and there is where we lack the performance. Specially
speaking of the workload with the very small packets, linux has a hard time
saturating those NICs (with XDP now rising up to the challenge); I think only
DPDK is able to at this point [*].

[*] Section 7.1,
https://download.01.org/packet-processing/ONPS2.1/Intel_ONP_Release_2.1_Performance_Test_Report_Rev1.0.pdf

> It would be good if we design this extension with higher goals in mind.
Totally agree!

>> data-len=256 TX (1vcpu, 256b, UDP in pps):  3 248 392 pps
>> data-len=256 TX (4vcpu, 256b, UDP in pps): 11 165 355 pps
>>
>> # memcpy + grant map (see next subsection)
>> data-len=256 TX (1vcpu, 260b, UDP in pps):588 428 pps
>> data-len=256 TX (4vcpu, 260b, UDP in pps):  1 668 044 pps
>>
>> # (drop at the guest network stack)
>> data-len=256 RX (1vcpu,  64b, UDP in pps):  3 285 362 pps
>> data-len=256 RX (4vcpu,  64b, UDP in pps): 11 761 847 pps
>>
>> # (drop with guest XDP_DROP prog)
>> data-len=256 RX (1vcpu,  64b, UDP in pps):  9 466 591 pps
>> data-len=256 RX (4vcpu,  64b, UDP in pps): 33 006 157 pps
>> ```
>>
>> Latency measurements (netperf TCP_RR request size 1 and response size 1):
>> ```
>> 24 KTps vs 28 KTps
>> 39 KTps vs 50 KTps (with kernel busy poll)
>> ```
>>
>> TCP Bulk transfer measurements aren't showing a representative increase on
>> maximum throughput (sometimes ~10%), but rather less retransmissions and
>> more stable. This is probably because of being having a slight decrease in 
>> rtt
>> time (i.e. receiver acknowledging data quicker). Currently trying exploring
>> other data list sizes and probably will have a better idea on the effects of
>> this.
>>
>> ## Linux grant copy vs map remark
>>
>> Based on numbers above there's a sudden 2x performance drop when we switch 
>> from
>> grant copy to also grant map the ` gref`: 1 295 001 vs  577 782 for 256 and 
>> 260
>> packets bytes respectivally. Which is 

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

[Oleksandr Andrushchenko]

On 01/05/2017 09:19 PM, Stefano Stabellini wrote:

On Thu, 5 Jan 2017, Oleksandr Andrushchenko wrote:

On 01/04/2017 08:23 PM, Stefano Stabellini wrote:

On Wed, 4 Jan 2017, Oleksandr Andrushchenko wrote:

First of all, thank you for comments

You are welcome :-)



On 01/04/2017 03:03 AM, Stefano Stabellini wrote:

On Tue, 3 Jan 2017, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Signed-off-by: Oleksandr Andrushchenko

---
xen/include/public/io/kbdif.h | 64
+++
1 file changed, 64 insertions(+)

diff --git a/xen/include/public/io/kbdif.h
b/xen/include/public/io/kbdif.h
index 2d2aebd..ad94b53 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -45,6 +45,19 @@
 */
#define XENKBD_TYPE_POS 4
+/*
+ * Multi-touch event
+ * Capable backend sets feature-multi-touch in xenstore.
+ * Frontend requests feature by setting request-multi-touch in
xenstore.
+ * Frontend supports up to XENKBD_MT_NUM_DEV virtual multi-touch
input
devices,
+ * configured by the backend in xenstore under mt-%d folder, %d being
+ * a sequential number of the virtual input device:
+ *   o num-contacts - number of simultaneous touches supported
+ *   o width - width of the touch area in pixels
+ *   o height - height of the touch area in pixels

Please write down the max width and height supported by the protocol,
keeping in mind that motion events below use int32_t for coordinates.

I will put "width(height) of the... in pixels, 32-bit signed integer"

I don't think I understand what you wrote here. To clarify, I meant
that the doc should say what is the theoretical maximum for width and
height, for example INT32_MAX.


How about:
  *   o width - width of the touch area in pixels, in
  *   [INT_LEAST32_MIN; INT32_MAX] range
  *   o height - height of the touch area in pixels, in
  *   [INT_LEAST32_MIN; INT32_MAX] range

Yes, that's what I had in mind. But I think that height and width
shouldn't have negative values here (movements should, but size
measurements shouldn't). Maybe:
   
   width [0, INT32_MAX]

   height [0, INT32_MAX]


even UINT32_MAX I think (width an height will be uint32_t)

Are there any benefits of this compared to just setting up multiple kbd
connections, one per multi-touch device? The only benefit I can think of
is saving few pages.

Well, not only saving a few pages, but somewhat
simplifying handling of the protocol on both back and
front ends. But, you are probably right as current
protocol is capable of holding
(XENKBD_IN_RING_SIZE - XENKBD_IN_RING_OFFS) / XENKBD_IN_EVENT_SIZE ==
(2048 - 1024) / 40 = 25 incoming events which may not be
enough for multiple mt devices delivering hundreds of
events per second.
Will set-up dedicated rings per mt device then.

I think you'll find it is going to be simpler and faster for little
extra memory costs.


Well, I have implemented that yesterday and after some cleanup
it will look ok

Good!



Will also remove
uint8_t dev_idx;/* index of the multi-touch device */
as every device will have its own ring.

Right



Will extend XenStore configuration for mt devices with:
   o page-ref (?)
   o page-gref
   o event-channel
as it is done by the Linux xen-kbdfront driver.

BTW, is there any reason we need "page-ref"? My understanding is
that the pair of page-gref + event-channel is enough to establish
and uniquely identify the connection.

It's page-gref that is superfluous. I don't know why the Linux frontend
writes it, in fact the QEMU backend doesn't even read it.


I'll keep it for consistency. I have refactored the
original kbdfront so there is common code for ring
and event channel handling which creates all the above.
If we decide that page-ref can be dropped it will
be dropped for all the devices at a time.

OK. Unfortunately the xenstore protocol for xenkbd is not documented,
so we'll never be able to get rid of it :-(



+/* Sent when a new touch is made: touch is assigned a unique contact
+ * ID, sent with this and consequent events related to this touch.
+ * Contact ID will be reused after XENKBD_MT_EV_UP event.

Will be reused or can be reused?

I would probably say "may be reused" as it depends on how
and if new touches/contacts are made

Please provide an example of a Contact
ID lifecycle.

Do you want it to be described in the protocol or just here?
If the latter then, for example, as Wayland documentation
describes it [1]:
"Touch interactions can consist of one or more contacts.
   For each contact, a series of events is generated, starting
   with a down event, followed by zero or more motion events,
   and ending with an up event. Events relating to the same
   contact point can be identified by the ID of the sequence."
So, if there is contact/touch a free Contact ID is assigned to
this contact(sequence) and it is "released" when contact is
done, e.g. after up event. 

Re: [Xen-devel] [PATCH] x86/boot/32: Convert the 32-bit pgtable setup code from assembly to C

[kbuild test robot]

Hi Ingo,

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.10-rc2 next-20170105]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ingo-Molnar/x86-boot-32-Convert-the-32-bit-pgtable-setup-code-from-assembly-to-C/20170106-035845
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/kernel/head_32.S: Assembler messages:
>> arch/x86/kernel/head_32.S:612: Error: can't resolve `init_thread_union' 
>> {*UND* section} - `SIZEOF_PTREGS' {*UND* section}

vim +612 arch/x86/kernel/head_32.S

11d4c3f9 arch/x86/kernel/head_32.S H. Peter Anvin 2011-02-04  606  .balign 4
b32f96c7 arch/x86/kernel/head_32.S Josh Poimboeuf 2016-08-18  607  
ENTRY(initial_stack)
22dc3918 arch/x86/kernel/head_32.S Josh Poimboeuf 2016-09-21  608   /*
22dc3918 arch/x86/kernel/head_32.S Josh Poimboeuf 2016-09-21  609* The 
SIZEOF_PTREGS gap is a convention which helps the in-kernel
22dc3918 arch/x86/kernel/head_32.S Josh Poimboeuf 2016-09-21  610* 
unwinder reliably detect the end of the stack.
22dc3918 arch/x86/kernel/head_32.S Josh Poimboeuf 2016-09-21  611*/
22dc3918 arch/x86/kernel/head_32.S Josh Poimboeuf 2016-09-21 @612   .long 
init_thread_union + THREAD_SIZE - SIZEOF_PTREGS - \
22dc3918 arch/x86/kernel/head_32.S Josh Poimboeuf 2016-09-21  613 
TOP_OF_KERNEL_STACK_PADDING;
^1da177e arch/i386/kernel/head.S   Linus Torvalds 2005-04-16  614  
4c5023a3 arch/x86/kernel/head_32.S H. Peter Anvin 2012-04-18  615  __INITRODATA

:: The code at line 612 was first introduced by commit
:: 22dc391865af29a1332bd1d17152f2ca7188bc4a x86/boot: Fix the end of the 
stack for idle tasks

:: TO: Josh Poimboeuf <jpoim...@redhat.com>
:: CC: Ingo Molnar <mi...@kernel.org>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] 16550: Add command line parsing adjustments

[Andrew Cooper]

On 05/01/17 19:47, Swapnil Paratey wrote:
> Add parsing options for reg_width and reg_shift in bootup command line
> parameters. This adds flexibility in setting register values
> for MMIO UART devices.
>
> Increase length of opt_com1 and opt_com2 buffer to accommodate more
> command line parameters.
>
> eg. com1=115200,8n1,0x3f8,4 (legacy IO)
> eg. com1=115200/300/4/2,8n1,0xfedc9000,4 (MMIO adjustments)
>
> Reviewed-by: Suravee Suthikulpanit 
> Signed-off-by: Swapnil Paratey 
> ---
>  docs/misc/xen-command-line.markdown |  2 +-
>  xen/drivers/char/ns16550.c  | 20 +---
>  2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 0138978..3297646 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -291,7 +291,7 @@ Flag to indicate whether to probe for a CMOS Real Time 
> Clock irrespective of
>  ACPI indicating none to be there.
>  
>  ### com1,com2
> -> `= 
> [/][,[DPS][,[|pci|amt][,[][,[][,[]]`
> +> `= 
> [/[][/[][/[[,DPS[,[,[,[,]`
>  
>  Both option `com1` and `com2` follow the same format.
>  

Please also add two bullet points to the list just out of context below
this.

> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
> index 1da103a..e076b29 100644
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -33,14 +33,14 @@
>  
>  /*
>   * Configure serial port with a string:
> - *   
> [/][,DPS[,[,[,[,].
> + *   
> [/[][/[][/[[,DPS[,[,[,[,].
>   * The tail of the string can be omitted if platform defaults are sufficient.
>   * If the baud rate is pre-configured, perhaps by a bootloader, then 'auto'
>   * can be specified in place of a numeric baud rate. Polled mode is specified
>   * by requesting irq 0.
>   */
> -static char __initdata opt_com1[30] = "";
> -static char __initdata opt_com2[30] = "";
> +static char __initdata opt_com1[50] = "";
> +static char __initdata opt_com2[50] = "";

I'd up these to 64, to be a nice power of two.  Its initdata, so size
(on this scale) isn't a problem.

Otherwise, looks good.

~Andrew

>  string_param("com1", opt_com1);
>  string_param("com2", opt_com2);
>  
> @@ -1118,6 +1118,20 @@ static void __init ns16550_parse_port_config(
>  uart->clock_hz = simple_strtoul(conf, , 0) << 4;
>  }
>  
> +if ( *conf == '/' )
> +{
> +conf++;
> +if ( *conf != '/' && *conf != ',' )
> +uart->reg_width = simple_strtol(conf, , 0);
> +}
> +
> +if ( *conf == '/' )
> +{
> +conf++;
> +if ( *conf != '/' && *conf != ',' )
> +uart->reg_shift = simple_strtol(conf, , 0);
> +}
> +
>  if ( *conf == ',' && *++conf != ',' )
>  {
>  uart->data_bits = simple_strtoul(conf, , 10);


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

Re: [Xen-devel] [PATCH] xen: Fix build with older versions of GCC following e34bc403c3

[Boris Ostrovsky]

On 01/05/2017 01:01 PM, Andrew Cooper wrote:
> GCCs of at least 4.4 and earlier do not tollerate the initialisiation of the
> $VENDOR_cpu_dev structures, because of c_ident becoming an anonymous union.
>
> Instead of using an anonymous union, reintepret c_ident[] in its CPUID form
> just in get_cpu_vendor().
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Boris Ostrovsky 
>
> RFC, as I don't have easy access to a compiler which causes this to fail in
> the first place.

Tested-by: Boris Ostrovsky 

with gcc 4.4.4



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

Re: [Xen-devel] [DOC v2] Xen transport for 9pfs

[Stefano Stabellini]

On Wed, 4 Jan 2017, Oleksandr Andrushchenko wrote:
> If this is not too late for comments...
> 
> On 12/06/2016 03:33 AM, Stefano Stabellini wrote:
> > Changes in v2:
> > - fix copy/paste error
> > - rename ring-ref- to ring-ref
> > - fix memory barriers
> > - add "verify prod/cons against local copy"
> > - add a paragraph on high level design
> > - add a note on the maximum possible max-ring-page-order value
> > - add mechanisms to avoid unnecessary evtchn notifications
> > 
> > ---
> > 
> > # Xen transport for 9pfs version 1
> > 
> > ## Background
> > 
> > 9pfs is a network filesystem protocol developed for Plan 9. 9pfs is very
> > simple and describes a series of commands and responses. It is
> > completely independent from the communication channels, in fact many
> > clients and servers support multiple channels, usually called
> > "transports". For example the Linux client supports tcp and unix
> > sockets, fds, virtio and rdma.
> > 
> > 
> > ### 9pfs protocol
> > 
> > This document won't cover the full 9pfs specification. Please refer to
> > this [paper] and this [website] for a detailed description of it.
> > However it is useful to know that each 9pfs request and response has the
> > following header:
> > 
> >  struct header {
> > uint32_t size;
> > uint8_t id;
> > uint16_t tag;
> >  } __attribute__((packed));
> As per my previous experience with sndif/displif
> 
> __attribute__((packed)); is not expected to be in a generic
> protocol

That's right, but this is a description of the existing 9pfs protocol,
there is nothing I can do about that.


> > 
> >  0 4  57
> >  +-+--++
> >  |  size   |id|tag |
> >  +-+--++
> > 
> > - *size*
> > The size of the request or response.
> > 
> > - *id*
> > The 9pfs request or response operation.
> > 
> > - *tag*
> > Unique id that identifies a specific request/response pair. It is used
> > to multiplex operations on a single channel.
> > 
> > It is possible to have multiple requests in-flight at any given time.
> > 
> > 
> > ## Rationale
> > 
> > This document describes a Xen based transport for 9pfs, in the
> > traditional PV frontend and backend format. The PV frontend is used by
> > the client to send commands to the server. The PV backend is used by the
> > 9pfs server to receive commands from clients and send back responses.
> > 
> > The transport protocol supports multiple rings up to the maximum
> > supported by the backend. The size of every ring is also configurable
> > and can span multiple pages, up to the maximum supported by the backend
> > (although it cannot be more than 2MB). The design is to exploit
> > parallelism at the vCPU level and support multiple outstanding requests
> > simultaneously.
> > 
> > This document does not cover the 9pfs client/server design or
> > implementation, only the transport for it.
> > 
> > 
> > ## Xenstore
> > 
> > The frontend and the backend connect via xenstore to exchange
> > information. The toolstack creates front and back nodes with state
> > [XenbusStateInitialising]. The protocol node name is **9pfs**.
> > 
> > Multiple rings are supported for each frontend and backend connection.
> > 
> > ### Frontend XenBus Nodes
> > 
> >  num-rings
> port and ring-ref both have indices, thus allowing to find out how
> many rings are there, so why do we need to specify it explicitly?

For clarity.


> >   Values: 
> >Number of rings. It needs to be lower or equal to max-rings.
> >   port- (port-0, port-1, etc)
> Correct me if I'm wrong, but "event-channel" is most used name in the
> protocols, not "port"

That is true. However, for reasons unknown to me, often in xenstore
protocols the event channel number is specified as "port".  Of course, I
don't have any problems changing port- to event-channel-.


> >   Values: 
> >The identifier of the Xen event channel used to signal
> > activity
> >   in the ring buffer. One for each ring.
> Here you refer to port as to event channel... So, please consider
> changing it accordingly

OK


> >   ring-ref (ring-ref0, ring-ref1, etc)
> >   Values: 
> >The Xen grant reference granting permission for the backend
> > to
> >   map a page with information to setup a share ring. One for each
> >   ring.
> > 
> > ### Backend XenBus Nodes
> > 
> > Backend specific properties, written by the backend, read by the
> > frontend:
> > 
> >  version
> >   Values: 
> >Protocol version supported by the backend. Currently the
> > value is
> >   1.
> >   max-rings
> >   Values: 
> >The maximum supported number of rings.
> Per frontend? If not, how does a frontend know how many
> it is allowed to use?

That's right, per frontend. I'll clarify it.


> >   max-ring-page-order
> Are there 

Re: [Xen-devel] PROBLEM: Kernel BUG with raid5 soft + Xen + DRBD - invalid opcode

[Shaohua Li]

On Thu, Jan 05, 2017 at 03:16:53PM +0100, MasterPrenium wrote:
> Hi Shaohua,
> 
> Thanks for your reply.
> 
> Let me explain my "huge". For example, if I'm making a low rate i/o stream,
> I don't get a crash (<1MB written / sec) with random i/o, but if I'm making
> a random I/O of about 20MB/sec, the kernel crashes in a few minutes (for
> example, making an rsync, or even synchronising my DRBD stack is causing the
> crash).
> I don't know if this can help, but in most of case, when the kernel crashes,
> after a reboot, my raid 5 stack is re-synchronizing.
> 
> I'm not able to reproduce the crash with a raw RAID5 stack (with dd/fio
> ...).
> 
> It seems I need to stack filesystems to help reproduce it:
> 
> Here is a configuration test, command lines to explain (the way I'm able to
> reproduce the crash). Everything is done in dom0.
> - mdadm --create /dev/md10 --raid-devices=3 --level=5 /dev/sdc1 /dev/sdd1
> /dev/sde1
> - mkfs.btrfs /dev/md10
> - mkdir /tmp/btrfs /mnt/XenVM /tmp/ext4
> - mount /dev/md10 /tmp/btrfs
> - btrfs subvolume create /tmp/btrfs/XenVM
> - umount /tmp/btrfs
> - mount /dev/md10 /mnt/XenVM -osubvol=XenVM
> - truncate /mnt/XenVM/VMTestFile.dat -s 800G
> - mkfs.ext4 /mnt/XenVM/VMTestFile.dat
> - mount /mnt/XenVM/VMTestFile.dat /tmp/ext4
> 
> -> Doing this, doesn't seem to crash the kernel :
> fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite
> --rwmixwrite=95 --bs=1M --direct=1 --size=80G --numjobs=8 --runtime=600
> --group_reporting --filename=/mnt/XenVM/Fio.dat
> 
> -> Doing this, is crashing the kernel in a few minutes :
> fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite
> --rwmixwrite=95 --bs=1M --direct=1 --size=80G --numjobs=8 --runtime=600
> --group_reporting --filename=/tmp/ext4/ext4.dat
> 
> Note : --direct=1 or --direct=0 doesn't seem to change the behaviour. Also
> having the raid 5 stack re-synchronizing or already synchronized, doesn't
> change the behaviour.
> 
> Here another "crash" : http://pastebin.com/uqLzL4fn

I'm trying to reproduce, but no success. So
ext4->btrfs->raid5, crash
btrfs->raid5, no crash
right? does subvolume matter? When you create the raid5 array, does adding
'--assume-clean' option change the behavior? I'd like to narrow down the issue.
If you can capture the blktrace to the raid5 array, it would be great to hint
us what kind of IO it is.
 
> Regarding your patch, I can't find it. Is it the one sent by Konstantin
> Khlebnikov ?

Right.

> Do you want the "ext4.dat" fio file ? It will be really difficult for me to
> provide it to you as I've only a poor ADSL network connection.

Not necessary.

Thanks,
Shaohua

> Thanks for your help,
> 
> MasterPrenium
> 
> Le 04/01/2017 à 23:30, Shaohua Li a écrit :
> > On Fri, Dec 23, 2016 at 07:25:56PM +0100, MasterPrenium wrote:
> > > Hello Guys,
> > > 
> > > I've having some trouble on a new system I'm setting up. I'm getting a 
> > > kernel BUG message, seems to be related with the use of Xen (when I boot 
> > > the system _without_ Xen, I don't get any crash).
> > > Here is configuration :
> > > - 3x Hard Drives running on RAID 5 Software raid created by mdadm
> > > - On top of it, DRBD for replication over another node (Active/passive 
> > > cluster)
> > > - On top of it, a BTRFS FileSystem with a few subvolumes
> > > - On top of it, XEN VMs running.
> > > 
> > > The BUG is happening when I'm making "huge" I/O (20MB/s with a rsync for 
> > > example) on the RAID5 stack.
> > > I've to reset system to make it work again.
> > what did you mean 'huge' I/O (20M/s)? Is it possible you can reproduce the
> > issue with a raw raid5 raid? It would be even better if you can give me a 
> > fio
> > job file with the issue, so I can easily debug it.
> > 
> > also please check if upstream patch (e8d7c33 md/raid5: limit request size
> > according to implementation limits) helps.
> > 
> > Thanks,
> > Shaohua
> 

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

[Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

[Dan Streetman]

Do not read a pci device's msi message data to see if a pirq was
previously configured for the device's msi/msix, as the old pirq was
unmapped and may now be in use by another pci device.  The previous
pirq should never be re-used; instead a new pirq should always be
allocated from the hypervisor.

The xen_hvm_setup_msi_irqs() function currently checks the pci device's
msi descriptor message data for each msi/msix vector it sets up, and if
it finds the vector was previously configured with a pirq, and that pirq
is mapped to an irq, it re-uses the pirq instead of requesting a new pirq
from the hypervisor.  However, that pirq was unmapped when the pci device
disabled its msi/msix, and it cannot be re-used; it may have been given
to a different pci device.

This exact situation is happening in a Xen guest where multiple NVMe
controllers (pci devices) are present.  The NVMe driver configures each
pci device's msi/msix twice; first to configure a single vector (to
talk to the controller for its configuration info), and then it disables
that msi/msix and re-configures with all the msi/msix it needs.  When
multiple NVMe controllers are present, this happens concurrently on all
of them, and in the time between controller A calling pci_disable_msix()
and then calling pci_enable_msix_range(), controller B enables its msix
and gets controller A's pirq allocated from the hypervisor.  Then when
controller A re-configures its msix, its first vector tries to re-use
the same pirq that it had before; but that pirq was allocated to
controller B, and thus the Xen event channel for controller A's re-used
pirq fails to map its irq to that pirq; the hypervisor already has the
pirq mapped elsewhere.

Signed-off-by: Dan Streetman 
---
 arch/x86/pci/xen.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index bedfab9..a00a6c0 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -234,23 +234,14 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, 
int nvec, int type)
return 1;
 
for_each_pci_msi_entry(msidesc, dev) {
-   __pci_read_msi_msg(msidesc, );
-   pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
-   ((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
-   if (msg.data != XEN_PIRQ_MSI_DATA ||
-   xen_irq_from_pirq(pirq) < 0) {
-   pirq = xen_allocate_pirq_msi(dev, msidesc);
-   if (pirq < 0) {
-   irq = -ENODEV;
-   goto error;
-   }
-   xen_msi_compose_msg(dev, pirq, );
-   __pci_write_msi_msg(msidesc, );
-   dev_dbg(>dev, "xen: msi bound to pirq=%d\n", pirq);
-   } else {
-   dev_dbg(>dev,
-   "xen: msi already bound to pirq=%d\n", pirq);
+   pirq = xen_allocate_pirq_msi(dev, msidesc);
+   if (pirq < 0) {
+   irq = -ENODEV;
+   goto error;
}
+   xen_msi_compose_msg(dev, pirq, );
+   __pci_write_msi_msg(msidesc, );
+   dev_dbg(>dev, "xen: msi bound to pirq=%d\n", pirq);
irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq,
   (type == PCI_CAP_ID_MSI) ? nvec 
: 1,
   (type == PCI_CAP_ID_MSIX) ?
-- 
2.9.3


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

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

[Stefano Stabellini]

On Thu, 5 Jan 2017, Oleksandr Andrushchenko wrote:
> On 01/04/2017 08:23 PM, Stefano Stabellini wrote:
> > On Wed, 4 Jan 2017, Oleksandr Andrushchenko wrote:
> > > First of all, thank you for comments
> > You are welcome :-)
> > 
> > 
> > > On 01/04/2017 03:03 AM, Stefano Stabellini wrote:
> > > > On Tue, 3 Jan 2017, Oleksandr Andrushchenko wrote:
> > > > > From: Oleksandr Andrushchenko 
> > > > > 
> > > > > Signed-off-by: Oleksandr Andrushchenko
> > > > > 
> > > > > ---
> > > > >xen/include/public/io/kbdif.h | 64
> > > > > +++
> > > > >1 file changed, 64 insertions(+)
> > > > > 
> > > > > diff --git a/xen/include/public/io/kbdif.h
> > > > > b/xen/include/public/io/kbdif.h
> > > > > index 2d2aebd..ad94b53 100644
> > > > > --- a/xen/include/public/io/kbdif.h
> > > > > +++ b/xen/include/public/io/kbdif.h
> > > > > @@ -45,6 +45,19 @@
> > > > > */
> > > > >#define XENKBD_TYPE_POS 4
> > > > >+/*
> > > > > + * Multi-touch event
> > > > > + * Capable backend sets feature-multi-touch in xenstore.
> > > > > + * Frontend requests feature by setting request-multi-touch in
> > > > > xenstore.
> > > > > + * Frontend supports up to XENKBD_MT_NUM_DEV virtual multi-touch
> > > > > input
> > > > > devices,
> > > > > + * configured by the backend in xenstore under mt-%d folder, %d being
> > > > > + * a sequential number of the virtual input device:
> > > > > + *   o num-contacts - number of simultaneous touches supported
> > > > > + *   o width - width of the touch area in pixels
> > > > > + *   o height - height of the touch area in pixels
> > > > Please write down the max width and height supported by the protocol,
> > > > keeping in mind that motion events below use int32_t for coordinates.
> > > I will put "width(height) of the... in pixels, 32-bit signed integer"
> > I don't think I understand what you wrote here. To clarify, I meant
> > that the doc should say what is the theoretical maximum for width and
> > height, for example INT32_MAX.
> > 
> How about:
>  *   o width - width of the touch area in pixels, in
>  *   [INT_LEAST32_MIN; INT32_MAX] range
>  *   o height - height of the touch area in pixels, in
>  *   [INT_LEAST32_MIN; INT32_MAX] range

Yes, that's what I had in mind. But I think that height and width
shouldn't have negative values here (movements should, but size
measurements shouldn't). Maybe:
  
  width [0, INT32_MAX]
  height [0, INT32_MAX]


> > > > Are there any benefits of this compared to just setting up multiple kbd
> > > > connections, one per multi-touch device? The only benefit I can think of
> > > > is saving few pages.
> > > Well, not only saving a few pages, but somewhat
> > > simplifying handling of the protocol on both back and
> > > front ends. But, you are probably right as current
> > > protocol is capable of holding
> > > (XENKBD_IN_RING_SIZE - XENKBD_IN_RING_OFFS) / XENKBD_IN_EVENT_SIZE ==
> > > (2048 - 1024) / 40 = 25 incoming events which may not be
> > > enough for multiple mt devices delivering hundreds of
> > > events per second.
> > > Will set-up dedicated rings per mt device then.
> > I think you'll find it is going to be simpler and faster for little
> > extra memory costs.
> > 
> Well, I have implemented that yesterday and after some cleanup
> it will look ok

Good!


> > > Will also remove
> > >uint8_t dev_idx;/* index of the multi-touch device */
> > > as every device will have its own ring.
> > Right
> > 
> > 
> > > Will extend XenStore configuration for mt devices with:
> > >   o page-ref (?)
> > >   o page-gref
> > >   o event-channel
> > > as it is done by the Linux xen-kbdfront driver.
> > > 
> > > BTW, is there any reason we need "page-ref"? My understanding is
> > > that the pair of page-gref + event-channel is enough to establish
> > > and uniquely identify the connection.
> > It's page-gref that is superfluous. I don't know why the Linux frontend
> > writes it, in fact the QEMU backend doesn't even read it.
> > 
> I'll keep it for consistency. I have refactored the
> original kbdfront so there is common code for ring
> and event channel handling which creates all the above.
> If we decide that page-ref can be dropped it will
> be dropped for all the devices at a time.

OK. Unfortunately the xenstore protocol for xenkbd is not documented,
so we'll never be able to get rid of it :-(


> > > > > +/* Sent when a new touch is made: touch is assigned a unique contact
> > > > > + * ID, sent with this and consequent events related to this touch.
> > > > > + * Contact ID will be reused after XENKBD_MT_EV_UP event.
> > > > Will be reused or can be reused?
> > > I would probably say "may be reused" as it depends on how
> > > and if new touches/contacts are made
> > > >Please provide an example of a Contact
> > > > ID lifecycle.
> > > Do you want it to be described in the protocol or just here?
> > > If the latter then, 

Re: [Xen-devel] [PATCH] x86emul: support fencing insns

[Andrew Cooper]

On 14/12/16 09:37, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -5190,8 +5190,26 @@ x86_emulate(
>  case X86EMUL_OPC(0x0f, 0xae): case X86EMUL_OPC_66(0x0f, 0xae): /* Grp15 
> */
>  switch ( modrm_reg & 7 )
>  {
> -case 7: /* clflush{,opt} */
> -fail_if(modrm_mod == 3);
> +case 5: /* lfence */
> +fail_if(modrm_mod != 3);
> +generate_exception_if(vex.pfx, EXC_UD);
> +vcpu_must_have(sse2);
> +asm volatile ( "lfence" ::: "memory" );
> +break;
> +case 6: /* mfence */
> +fail_if(modrm_mod != 3);
> +generate_exception_if(vex.pfx, EXC_UD);
> +vcpu_must_have(sse2);
> +asm volatile ( "mfence" ::: "memory" );
> +break;
> +case 7: /* clflush{,opt} / sfence */
> +if ( modrm_mod == 3 )

Could I talk you into having

if ( modrm_mod == 3 ) /* sfence */

and

> +{
> +generate_exception_if(vex.pfx, EXC_UD);
> +vcpu_must_have(sse);
> +asm volatile ( "sfence" ::: "memory" );
> +break;
> +}

/* else clflush{,opt} */ ?

Even knowing what is going on, this is a little hard to follow.

Otherwise, Reviewed-by: Andrew Cooper 

>  if ( !vex.pfx )
>  vcpu_must_have(clflush);
>  else
>
>
>


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

Re: [Xen-devel] [PATCH 2/3 v2] x86emul: conditionally clear BNDn for branches

[Andrew Cooper]

On 05/01/17 09:13, Jan Beulich wrote:
 On 04.01.17 at 22:11,  wrote:
>> On 12/12/16 10:00, Jan Beulich wrote:
>>> @@ -1791,6 +1795,34 @@ static int inject_swint(enum x86_swint_t
>>>  generate_exception(fault_type, error_code);
>>>  }
>>>  
>>> +static void clear_bnd(struct x86_emulate_ctxt *ctxt,
>>> +  const struct x86_emulate_ops *ops, enum vex_pfx pfx)
>> As with register_address_adjust(), this would be better as adjust_bnd()
>> as we don't necessarily clear them.
> Okay.
>
>>> +{
>>> +uint64_t bndcfg;
>>> +int rc;
>>> +
>>> +if ( pfx == vex_f2 || !vcpu_has_mpx() )
>> This is an awkward edgecase of the rules concerning the host_ variants,
>> but we will take a fault from xsave/xrstor for using XSTATE_BND* if the
>> host doesn't support MPX.
> Right. For now the implication is that guest available MPX implies
> host support.

But the reason for the host_and_vcpu_* predicate is because we cannot
rely on this.

While we are not actually using MPX instructions specifically, we are
using MPX hardware state/mechanisms to perform the emulation.

(MPX is an odd case, as the new MPX instructions are specifically chosen
from things which were nops on older processors, so one single binary
will execute on newer and older hardware.)

>
>>> --- a/xen/arch/x86/xstate.c
>>> +++ b/xen/arch/x86/xstate.c
>>> @@ -723,6 +741,66 @@ int handle_xsetbv(u32 index, u64 new_bv)
>>>  return 0;
>>>  }
>>>  
>>> +uint64_t read_bndcfgu(void)
>>> +{
>>> +unsigned long cr0 = read_cr0();
>>> +struct xsave_struct *xstate
>>> += idle_vcpu[smp_processor_id()]->arch.xsave_area;
>>> +const struct xstate_bndcsr *bndcsr;
>>> +
>>> +ASSERT(cpu_has_mpx);
>>> +clts();
>>> +
>>> +if ( cpu_has_xsavec )
>>> +{
>>> +asm ( ".byte 0x0f,0xc7,0x27\n" /* xsavec */
>>> +  : "=m" (*xstate)
>>> +  : "a" (XSTATE_BNDCSR), "d" (0), "D" (xstate) );
>>> +
>>> +bndcsr = (void *)(xstate + 1);
>>> +}
>>> +else
>>> +{
>>> +alternative_io(".byte 0x0f,0xae,0x27\n", /* xsave */
>>> +   ".byte 0x0f,0xae,0x37\n", /* xsaveopt */
>>> +   X86_FEATURE_XSAVEOPT,
>>> +   "=m" (*xstate),
>>> +   "a" (XSTATE_BNDCSR), "d" (0), "D" (xstate));
>> I am not certain this is safe.  xsaveopt has an extra optimisation to do
>> with whether the state has been internally modified.  Because we use an
>> xsave area from the idle vcpu, I can't see anything which prevents the
>> LAXA (linear address of XSAVE area) optimisation kicking in, causing us
>> to observe a zero in xstate_bv despite BNDCSR having a non-zero value
>> loaded in hardware.
> True - I've dropped the alternative now as well as the use of XSAVEC.

Why drop XSAVEC?  It appears to only be XSAVEOPT and XSAVES which have
the linear address optimisation.  XSAVEC claims only to use the
XINUSE[i] optimisation which is fine for our needs.

Alternatively, the linear address optimisation can be fooled into
working sensibly if we add 64bytes to the idle xstate allocation, and
alternate between using the two.

~Andrew

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

Re: [Xen-devel] [RFC PATCH v2 07/26] ARM: GICv3 ITS: introduce host LPI array

[Stefano Stabellini]

On Thu, 22 Dec 2016, Andre Przywara wrote:
7> The number of LPIs on a host can be potentially huge (millions),
> although in practise will be mostly reasonable. So prematurely allocating
> an array of struct irq_desc's for each LPI is not an option.
> However Xen itself does not care about LPIs, as every LPI will be injected
> into a guest (Dom0 for now).
> Create a dense data structure (8 Bytes) for each LPI which holds just
> enough information to determine the virtual IRQ number and the VCPU into
> which the LPI needs to be injected.
> Also to not artificially limit the number of LPIs, we create a 2-level
> table for holding those structures.
> This patch introduces functions to initialize these tables and to
> create, lookup and destroy entries for a given LPI.
> We allocate and access LPI information in a way that does not require
> a lock.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/gic-its.c| 233 
> +-
>  xen/include/asm-arm/gic-its.h |   1 +
>  2 files changed, 233 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> index e157c6b..e7ddd90 100644
> --- a/xen/arch/arm/gic-its.c
> +++ b/xen/arch/arm/gic-its.c
> @@ -18,21 +18,36 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  
> +/* LPIs on the host always go to a guest, so no struct irq_desc for them. */
> +union host_lpi {
> +uint64_t data;
> +struct {
> +uint64_t virt_lpi:32;
> +uint64_t dom_id:16;
> +uint64_t vcpu_id:16;
> +};
> +};

Just go with a regular struct

struct host_lpi {
uint32_t virt_lpi;
uint16_t dom_id;
uint16_t vcpu_id;
};

The aarch64 C ABI guarantees the alignments of the fields.


>  /* Global state */
>  static struct {
>  uint8_t *lpi_property;
> +union host_lpi **host_lpis;
>  unsigned int host_lpi_bits;
> +/* Protects allocation and deallocation of host LPIs, but not the access 
> */
> +spinlock_t host_lpis_lock;
>  } lpi_data;
>  
>  /* Physical redistributor address */
> @@ -43,6 +58,19 @@ static DEFINE_PER_CPU(uint64_t, rdist_id);
>  static DEFINE_PER_CPU(void *, pending_table);
>  
>  #define MAX_PHYS_LPIS   (BIT_ULL(lpi_data.host_lpi_bits) - 8192)
> +#define HOST_LPIS_PER_PAGE  (PAGE_SIZE / sizeof(union host_lpi))
> +
> +static union host_lpi *gic_get_host_lpi(uint32_t plpi)
> +{
> +if ( plpi < 8192 || plpi >= MAX_PHYS_LPIS + 8192 )
> +return NULL;
> +
> +plpi -= 8192;
> +if ( !lpi_data.host_lpis[plpi / HOST_LPIS_PER_PAGE] )
> +return NULL;
> +
> +return _data.host_lpis[plpi / HOST_LPIS_PER_PAGE][plpi % 
> HOST_LPIS_PER_PAGE];
> +}
>  
>  #define ITS_CMD_QUEUE_SZSZ_64K
>  
> @@ -96,6 +124,20 @@ static int its_send_cmd_sync(struct host_its *its, int 
> cpu)
>  return its_send_command(its, cmd);
>  }
>  
> +static int its_send_cmd_mapti(struct host_its *its,
> +  uint32_t deviceid, uint32_t eventid,
> +  uint32_t pintid, uint16_t icid)
> +{
> +uint64_t cmd[4];
> +
> +cmd[0] = GITS_CMD_MAPTI | ((uint64_t)deviceid << 32);
> +cmd[1] = eventid | ((uint64_t)pintid << 32);
> +cmd[2] = icid;
> +cmd[3] = 0x00;
> +
> +return its_send_command(its, cmd);
> +}
> +
>  static int its_send_cmd_mapc(struct host_its *its, int collection_id, int 
> cpu)
>  {
>  uint64_t cmd[4];
> @@ -124,6 +166,19 @@ static int its_send_cmd_mapd(struct host_its *its, 
> uint32_t deviceid,
>  return its_send_command(its, cmd);
>  }
>  
> +static int its_send_cmd_inv(struct host_its *its,
> +uint32_t deviceid, uint32_t eventid)
> +{
> +uint64_t cmd[4];
> +
> +cmd[0] = GITS_CMD_INV | ((uint64_t)deviceid << 32);
> +cmd[1] = eventid;
> +cmd[2] = 0x00;
> +cmd[3] = 0x00;
> +
> +return its_send_command(its, cmd);
> +}
> +
>  /* Set up the (1:1) collection mapping for the given host CPU. */
>  void gicv3_its_setup_collection(int cpu)
>  {
> @@ -366,21 +421,181 @@ uint64_t gicv3_lpi_get_proptable()
>  static unsigned int max_lpi_bits = CONFIG_MAX_HOST_LPI_BITS;
>  integer_param("max_lpi_bits", max_lpi_bits);
>  
> +/* Allocate the 2nd level array for host LPIs. This one holds pointers
> + * to the page with the actual "union host_lpi" entries. Our LPI limit
> + * avoids excessive memory usage.
> + */
>  int gicv3_lpi_init_host_lpis(unsigned int hw_lpi_bits)
>  {
> +int nr_lpi_ptrs;
> +
>  lpi_data.host_lpi_bits = min(hw_lpi_bits, max_lpi_bits);
>  
> +spin_lock_init(_data.host_lpis_lock);
> +
> +nr_lpi_ptrs = MAX_PHYS_LPIS / (PAGE_SIZE / sizeof(union host_lpi));
> +lpi_data.host_lpis = xzalloc_array(union host_lpi *, nr_lpi_ptrs);
> +if ( !lpi_data.host_lpis )
> +return 

[Xen-devel] [PATCH] x86/VMX: Implement vmptrst

[Anshul Makkar]

Current codebase doesn't implement and use vmptrst. Implementing it as it may
be required in future.

Signed-off-by: Anshul Makkar 
---
 xen/include/asm-x86/hvm/vmx/vmx.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index e5c6499..2db6c1d 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -328,6 +328,28 @@ static always_inline void __vmptrld(u64 addr)
: "memory");
 }
 
+static always_inline u64 __vmptrst(void)
+{
+u64 paddr;
+
+asm volatile (
+#ifdef HAVE_GAS_VMX
+   "vmptrst %0\n"
+#else
+   VMPTRST_OPCODE MODRM_EAX_07
+#endif
+
+#ifdef HAVE_GAS_VMX
+   : "=m" (paddr)
+   :
+#else
+   :
+   : "a" (),
+#endif
+   : "memory");
+return paddr;
+}
+
 static always_inline void __vmpclear(u64 addr)
 {
 asm volatile (
-- 
2.7.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  f50e4912b763df0c56c01c163a3d9427794a6905
baseline version:
 xen  e5ca20e0f6212dffaba2d3a0b966b71d9ab1ea91

Last test of basis   104046  2017-01-05 13:01:29 Z0 days
Testing same since   104048  2017-01-05 17:01:45 Z0 days1 attempts


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

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

[Oleksandr Andrushchenko]

On 01/05/2017 06:12 PM, Jan Beulich wrote:

On 05.01.17 at 17:03,  wrote:

On 01/05/2017 05:45 PM, Jan Beulich wrote:

On 22.12.16 at 09:12,  wrote:

Other than that the primary thing I'm missing (as I think I've
mentioned elsewhere already) is a rationale of why this new
protocol is needed (and the existing xenfb one can't be extended).

"This protocol aims to provide a unified protocol which fits more

sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention to extend:
   o multiple dynamically allocated/destroyed framebuffers
   o buffers of arbitrary sizes
   o better configuration options including multiple display support"

Well, that's all stuff you had spelled out in the accompanying mail,
but that's all items which could be taken care of by a protocol
extension too.

of course

I tried to evaluate what would it be like to extend existing fbif...
It looks like having 2 different protocols in a single file.

This is what I'd like you to expand on.

To start with:

1. In/out event sizes
 o fbif - 40 octets
 o displif - 40 octets
It fits now, but this is only the initial version of the displif protocol
which means that there could be requests which will not fit
(we are thinking of introducing some GPU related functionality
later on). In that case we cannot alter fbif sizes as we need to
be backward compatible an will be forced to handle those
apart of fbif. This makes me believe if we extend fbif it is better
to have separate structures/rings from the start.

2. Shared page
Displif doesn't use anything like struct xenfb_page, but
DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct xendispl_resp);
which I believe is a better and more common way.
Output events use a shared page which only has in_cons and in_prod
and all the rest is used for incoming events. Here struct xenfb_page
could probably be used as is despite the fact that it only has a half
of a page for incoming events which is only 50 events. (consider
something like 60Hz display)

3. Amount of changes.
fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE
events, so it looks like it is easier to get fb support into displif
than vice versa. displif at the moment has 6 requests and 1 event,
multiple connector support, etc.
BTW, I can add framebuffer's update and resize into displif, so
it could  probably supersede fbif at some point


What is more fbif can be used together with displif running at the
same time, e.g. on Linux one provides framebuffer and another DRM

And this is certainly a valid argument (which hence should be
spelled out in the description).

ok

Jan




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

[Xen-devel] [PATCH] xen: Fix build with older versions of GCC following e34bc403c3

[Andrew Cooper]

GCCs of at least 4.4 and earlier do not tollerate the initialisiation of the
$VENDOR_cpu_dev structures, because of c_ident becoming an anonymous union.

Instead of using an anonymous union, reintepret c_ident[] in its CPUID form
just in get_cpu_vendor().

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

RFC, as I don't have easy access to a compiler which causes this to fail in
the first place.
---
 xen/arch/x86/cpu/common.c | 7 +--
 xen/arch/x86/cpu/cpu.h| 8 +---
 2 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index d17a2ee..7d6d024 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -163,8 +163,11 @@ int get_cpu_vendor(uint32_t b, uint32_t c, uint32_t d, 
enum get_cpu_vendor mode)
 
for (i = 0; i < X86_VENDOR_NUM; i++) {
if (cpu_devs[i]) {
-   if (cpu_devs[i]->b == b && cpu_devs[i]->c == c &&
-   cpu_devs[i]->d == d) {
+   struct {
+   uint32_t b, d, c;
+   } *ptr = (void *)cpu_devs[i]->c_ident;
+
+   if (ptr->b == b && ptr->c == c && ptr->d == d) {
if (mode == gcv_host)
this_cpu = cpu_devs[i];
return i;
diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h
index 5a7905c..3eeebe3 100644
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -1,13 +1,7 @@
 /* attempt to consolidate cpu attributes */
 struct cpu_dev {
charc_vendor[8];
-
-   union {
-   charc_ident[13];
-   struct {
-   uint32_t b, d, c;
-   };
-   };
+   charc_ident[13];
 
void(*c_early_init)(struct cpuinfo_x86 *c);
void(*c_init)(struct cpuinfo_x86 * c);
-- 
2.1.4


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

Re: [Xen-devel] [RFC PATCH v2 03/26] ARM: GICv3 ITS: allocate device and collection table

[Andre Przywara]

Hi Stefano,

On 04/01/17 21:47, Stefano Stabellini wrote:
> On Thu, 22 Dec 2016, Andre Przywara wrote:
>> Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
>> an EventID (the MSI payload or interrupt ID) to a pair of LPI number
>> and collection ID, which points to the target CPU.
>> This mapping is stored in the device and collection tables, which software
>> has to provide for the ITS to use.
>> Allocate the required memory and hand it the ITS.
>> The maximum number of devices is limited to a compile-time constant
>> exposed in Kconfig.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/Kconfig  |   6 +++
>>  xen/arch/arm/gic-its.c| 114 
>> ++
>>  xen/arch/arm/gic-v3.c |   5 ++
>>  xen/include/asm-arm/bitops.h  |   1 +
>>  xen/include/asm-arm/gic-its.h |  51 ++-
>>  5 files changed, 176 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index a7d941c..a369305 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -59,6 +59,12 @@ config MAX_HOST_LPI_BITS
>>This can be overriden on the command line with the max_lpi_bits
>>parameter.
>>  
>> +config MAX_ITS_PCI_BUSSES
>> +depends on HAS_ITS
>> +int "Number of PCI busses the ITS supports (4)"
>> +range 1 1024
>> +default "4"
> 
> Given that any kind of devices can be behind an ITS, including non-PCI
> devices, I think it is best to call this MAX_PHYS_ITS_DEVICES.

Good point.

>>  endmenu
>>  
>>  menu "ARM errata workaround via the alternative framework"
>> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
>> index 6c3a35d..f1540b2 100644
>> --- a/xen/arch/arm/gic-its.c
>> +++ b/xen/arch/arm/gic-its.c
>> @@ -22,6 +22,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -37,6 +38,119 @@ static DEFINE_PER_CPU(void *, pending_table);
>>  
>>  #define MAX_PHYS_LPIS   (BIT_ULL(lpi_data.host_lpi_bits) - 8192)
>>  
>> +#define BASER_ATTR_MASK   \
>> +((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
>> + (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
>> + (0x7UL << GITS_BASER_INNER_CACHEABILITY_SHIFT))
>> +#define BASER_RO_MASK   (GENMASK(58, 56) | GENMASK(52, 48))
>> +
>> +static uint64_t encode_phys_addr(paddr_t addr, int page_bits)
>> +{
>> +uint64_t ret;
>> +
>> +if ( page_bits < 16)
>> +return (uint64_t)addr & GENMASK(47, page_bits);
>> +
>> +ret = addr & GENMASK(47, 16);
>> +return ret | (addr & GENMASK(51, 48)) >> (48 - 12);
>> +}
>> +
>> +static int its_map_baser(void __iomem *basereg, uint64_t regc, int nr_items)
>> +{
>> +uint64_t attr;
>> +int entry_size = ((regc >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0x1f) + 1;
>> +int pagesz;
>> +int order;
>> +void *buffer = NULL;
>> +
>> +attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
>> +attr |= GIC_BASER_CACHE_SameAsInner << 
>> GITS_BASER_OUTER_CACHEABILITY_SHIFT;
>> +attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
>> +
>> +/*
>> + * Loop over the page sizes (4K, 16K, 64K) to find out what the host
>> + * supports.
>> + */
>> +for ( pagesz = 0; pagesz < 3; pagesz++ )
>> +{
>> +uint64_t reg;
>> +int nr_bytes;
>> +
>> +nr_bytes = ROUNDUP(nr_items * entry_size, BIT(pagesz * 2 + 12));
> 
> 12/PAGE_SHIFT

Will use a macro to convert the loop counter into the number of bits.

>> +order = get_order_from_bytes(nr_bytes);
>> +
>> +if ( !buffer )
>> +buffer = alloc_xenheap_pages(order, 0);
>> +if ( !buffer )
>> +return -ENOMEM;
>> +
>> +reg  = attr;
>> +reg |= (pagesz << GITS_BASER_PAGE_SIZE_SHIFT);
>> +reg |= nr_bytes >> (pagesz * 2 + 12);
>> +reg |= regc & BASER_RO_MASK;
>> +reg |= GITS_BASER_VALID;
>> +reg |= encode_phys_addr(virt_to_maddr(buffer), pagesz * 2 + 12);
>> +
>> +writeq_relaxed(reg, basereg);
>> +regc = readl_relaxed(basereg);
>> +
>> +/* The host didn't like our attributes, just use what it returned. 
>> */
>> +if ( (regc & BASER_ATTR_MASK) != attr )
>> +attr = regc & BASER_ATTR_MASK;
>> +
>> +/* If the host accepted our page size, we are done. */
>> +if ( (reg & (3UL << GITS_BASER_PAGE_SIZE_SHIFT)) == pagesz )
>> +return 0;
>> +
>> +/* Check whether our buffer is aligned to the next page size 
>> already. */
>> +if ( !(virt_to_maddr(buffer) & (BIT(pagesz * 2 + 12 + 2) - 1)) )
>> +{
>> +free_xenheap_pages(buffer, order);
>> +buffer = NULL;
>> +}
> 
> Regardless of alignment, should we always free buffer here, given that
> we need to allocate the 

Re: [Xen-devel] [RFC PATCH v2 02/26] ARM: GICv3: allocate LPI pending and property table

[Stefano Stabellini]

On Thu, 5 Jan 2017, Andre Przywara wrote:
> Hi,
> 
> On 04/01/17 21:09, Stefano Stabellini wrote:
> > On Thu, 22 Dec 2016, Andre Przywara wrote:
> >> The ARM GICv3 ITS provides a new kind of interrupt called LPIs.
> >> The pending bits and the configuration data (priority, enable bits) for
> >> those LPIs are stored in tables in normal memory, which software has to
> >> provide to the hardware.
> >> Allocate the required memory, initialize it and hand it over to each
> >> ITS. The maximum number of LPIs to be used can be adjusted with the
> >> command line option "max_lpi_bits", which defaults to a compile time
> >> constant exposed in Kconfig.
> >>
> >> Signed-off-by: Andre Przywara 
> >> ---
> >>  xen/arch/arm/Kconfig  | 10 +
> >>  xen/arch/arm/efi/efi-boot.h   |  1 -
> >>  xen/arch/arm/gic-its.c| 94 
> >> +++
> >>  xen/arch/arm/gic-v3.c | 43 ++
> >>  xen/include/asm-arm/bitops.h  |  1 +
> >>  xen/include/asm-arm/cache.h   |  4 ++
> >>  xen/include/asm-arm/gic-its.h | 22 -
> >>  xen/include/asm-arm/gic_v3_defs.h | 48 +++-
> >>  8 files changed, 220 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> >> index bf64c61..a7d941c 100644
> >> --- a/xen/arch/arm/Kconfig
> >> +++ b/xen/arch/arm/Kconfig
> >> @@ -49,6 +49,16 @@ config HAS_ITS
> >>  bool "GICv3 ITS MSI controller support"
> >>  depends on HAS_GICV3
> >>  
> >> +config MAX_HOST_LPI_BITS
> > ^ MAX_PHYS_LPI_BITS
> 
> Right, I missed that symbol.
> 
> >> +depends on HAS_ITS
> >> +int "Maximum bits for GICv3 host LPIs (14-32)"
> >> +range 14 32
> >> +default "20"
> >> +help
> >> +  Specifies the maximum number of LPIs (bits) Xen should take 
> >> care of.
> >> +  This can be overriden on the command line with the max_lpi_bits
> >> +  parameter.
> >> +
> >>  endmenu
> >>  
> >>  menu "ARM errata workaround via the alternative framework"
> >> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> >> index 045d6ce..dc64aec 100644
> >> --- a/xen/arch/arm/efi/efi-boot.h
> >> +++ b/xen/arch/arm/efi/efi-boot.h
> >> @@ -10,7 +10,6 @@
> >>  #include "efi-dom0.h"
> >>  
> >>  void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
> >> -void __flush_dcache_area(const void *vaddr, unsigned long size);
> >>  
> >>  #define DEVICE_TREE_GUID \
> >>  {0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 
> >> 0xe0}}
> >> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> >> index 973f9f9..6c3a35d 100644
> >> --- a/xen/arch/arm/gic-its.c
> >> +++ b/xen/arch/arm/gic-its.c
> >> @@ -20,10 +20,104 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>  
> >> +/* Global state */
> >> +static struct {
> >> +uint8_t *lpi_property;
> >> +unsigned int host_lpi_bits;
> > 
> > I think it is best to rename host_lpi_bits to phys_lpi_bits, or, even
> > better, phys_nr_lpi because it represents the number of LPIs.
> 
> But we need the number of bits in at least one function (for populating
> the PROPBASER register), also the number of bits is the original input
> value and sets the limit on possible values - as it needs to be a power
> of two.
> So shall I use nr_phys_lpi_bits instead?

Let me explain why I made that comment. When I read "host_lpi_bits", it
is not immediately clear that it is strictly related to the number of
physical lpis. If you prefer to store the number of bits, instead of the
number of plpis (althought it is trivial to calculate one from the
other), then add a comment here.


> >> +} lpi_data;
> >> +
> >> +/* Pending table for each redistributor */
> >> +static DEFINE_PER_CPU(void *, pending_table);
> >> +
> >> +#define MAX_PHYS_LPIS   (BIT_ULL(lpi_data.host_lpi_bits) - 8192)
> >> +
> >> +uint64_t gicv3_lpi_allocate_pendtable(void)
> >> +{
> >> +uint64_t reg, attr;
> >> +void *pendtable;
> >> +
> >> +attr  = GIC_BASER_CACHE_RaWaWb << 
> >> GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
> >> +attr |= GIC_BASER_CACHE_SameAsInner << 
> >> GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
> >> +attr |= GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT;
> >> +
> >> +if ( !this_cpu(pending_table) )
> >> +{
> >> +/*
> >> + * The pending table holds one bit per LPI, so we need (2 << 3) 
> >> bits
> >> + * less bytes. The pending table covers even bits for interrupt 
> >> IDs
> >> + * below 8192, so we allocate the full range.
> >> + * The ITS imposes a 64KB alignment requirement.
> >> + */
> >> +pendtable = _xmalloc(BIT_ULL(lpi_data.host_lpi_bits) / 8, SZ_64K);
> > 
> > If we need (2 << 3) less bytes, why are we dividing by 8?
> 
> Because ... I am wrong here 

Re: [Xen-devel] Xenstore/ xenstored

[Wei Liu]

On Thu, Jan 05, 2017 at 04:57:27PM +0100, Yessine Daoud wrote:
> Hello,
> 
> I have a question regarding the daemon xenstored running on dom0.
> Xenstored is responsable for communication with xenstore.
> 
> How xenstored dump the xenstore? for example I send the following path to
> xenstored :
> /local/domain/1/name: normally xenstored will receive this path and will
> search the corresponding value.
> 
> How this mechanism is done ?
> Is there a known algorithm to dump the xenstore content ?
> How to locate the path ? data ?
> 

I'm not sure what you try to do.

Have you tried various xenstore-* utilities? Like xenstore-ls,
xenstore-read, xenstore-write etc.

Wei.

> Best Regards,
> 
> 
> 
> ᐧ

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


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

Re: [Xen-devel] [PATCH] x86/mtrr: use stdbool instead of int + define

[Andrew Cooper]

On 05/01/17 17:17, Doug Goldstein wrote:
> On 1/5/17 11:08 AM, Jan Beulich wrote:
> On 05.01.17 at 17:26,  wrote:
>>> -static void set_fixed_range(int msr, int * changed, unsigned int * 
>>> msrwords)
>>> +static void set_fixed_range(int msr, bool * changed, unsigned int * 
>>> msrwords)
>> Would have been nice to get the stray blanks here and elsewhere
>> dropped, as the lines are being touched anyway.
>>
>> Jan
>>
> I can do that. I went minimal instead of cleanup.

I have already folded those changes in.  No need to resend.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/mtrr: use stdbool instead of int + define

[Doug Goldstein]

On 1/5/17 11:08 AM, Jan Beulich wrote:
 On 05.01.17 at 17:26,  wrote:
>> -static void set_fixed_range(int msr, int * changed, unsigned int * msrwords)
>> +static void set_fixed_range(int msr, bool * changed, unsigned int * 
>> msrwords)
> 
> Would have been nice to get the stray blanks here and elsewhere
> dropped, as the lines are being touched anyway.
> 
> Jan
> 

I can do that. I went minimal instead of cleanup.

-- 
Doug Goldstein



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

Re: [Xen-devel] [RFC PATCH v2 02/26] ARM: GICv3: allocate LPI pending and property table

[Andre Przywara]

Hi,

On 04/01/17 21:09, Stefano Stabellini wrote:
> On Thu, 22 Dec 2016, Andre Przywara wrote:
>> The ARM GICv3 ITS provides a new kind of interrupt called LPIs.
>> The pending bits and the configuration data (priority, enable bits) for
>> those LPIs are stored in tables in normal memory, which software has to
>> provide to the hardware.
>> Allocate the required memory, initialize it and hand it over to each
>> ITS. The maximum number of LPIs to be used can be adjusted with the
>> command line option "max_lpi_bits", which defaults to a compile time
>> constant exposed in Kconfig.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/Kconfig  | 10 +
>>  xen/arch/arm/efi/efi-boot.h   |  1 -
>>  xen/arch/arm/gic-its.c| 94 
>> +++
>>  xen/arch/arm/gic-v3.c | 43 ++
>>  xen/include/asm-arm/bitops.h  |  1 +
>>  xen/include/asm-arm/cache.h   |  4 ++
>>  xen/include/asm-arm/gic-its.h | 22 -
>>  xen/include/asm-arm/gic_v3_defs.h | 48 +++-
>>  8 files changed, 220 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index bf64c61..a7d941c 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -49,6 +49,16 @@ config HAS_ITS
>>  bool "GICv3 ITS MSI controller support"
>>  depends on HAS_GICV3
>>  
>> +config MAX_HOST_LPI_BITS
> ^ MAX_PHYS_LPI_BITS

Right, I missed that symbol.

>> +depends on HAS_ITS
>> +int "Maximum bits for GICv3 host LPIs (14-32)"
>> +range 14 32
>> +default "20"
>> +help
>> +  Specifies the maximum number of LPIs (bits) Xen should take care 
>> of.
>> +  This can be overriden on the command line with the max_lpi_bits
>> +  parameter.
>> +
>>  endmenu
>>  
>>  menu "ARM errata workaround via the alternative framework"
>> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
>> index 045d6ce..dc64aec 100644
>> --- a/xen/arch/arm/efi/efi-boot.h
>> +++ b/xen/arch/arm/efi/efi-boot.h
>> @@ -10,7 +10,6 @@
>>  #include "efi-dom0.h"
>>  
>>  void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
>> -void __flush_dcache_area(const void *vaddr, unsigned long size);
>>  
>>  #define DEVICE_TREE_GUID \
>>  {0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 
>> 0xe0}}
>> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
>> index 973f9f9..6c3a35d 100644
>> --- a/xen/arch/arm/gic-its.c
>> +++ b/xen/arch/arm/gic-its.c
>> @@ -20,10 +20,104 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  
>> +/* Global state */
>> +static struct {
>> +uint8_t *lpi_property;
>> +unsigned int host_lpi_bits;
> 
> I think it is best to rename host_lpi_bits to phys_lpi_bits, or, even
> better, phys_nr_lpi because it represents the number of LPIs.

But we need the number of bits in at least one function (for populating
the PROPBASER register), also the number of bits is the original input
value and sets the limit on possible values - as it needs to be a power
of two.
So shall I use nr_phys_lpi_bits instead?

>> +} lpi_data;
>> +
>> +/* Pending table for each redistributor */
>> +static DEFINE_PER_CPU(void *, pending_table);
>> +
>> +#define MAX_PHYS_LPIS   (BIT_ULL(lpi_data.host_lpi_bits) - 8192)
>> +
>> +uint64_t gicv3_lpi_allocate_pendtable(void)
>> +{
>> +uint64_t reg, attr;
>> +void *pendtable;
>> +
>> +attr  = GIC_BASER_CACHE_RaWaWb << 
>> GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
>> +attr |= GIC_BASER_CACHE_SameAsInner << 
>> GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
>> +attr |= GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT;
>> +
>> +if ( !this_cpu(pending_table) )
>> +{
>> +/*
>> + * The pending table holds one bit per LPI, so we need (2 << 3) bits
>> + * less bytes. The pending table covers even bits for interrupt IDs
>> + * below 8192, so we allocate the full range.
>> + * The ITS imposes a 64KB alignment requirement.
>> + */
>> +pendtable = _xmalloc(BIT_ULL(lpi_data.host_lpi_bits) / 8, SZ_64K);
> 
> If we need (2 << 3) less bytes, why are we dividing by 8?

Because ... I am wrong here ;-)

> Isn't this just a straightforward bits to bytes conversion?

Yes.

> I think the comment is probably wrong or outdated.

Yeah, I tried to make this clearer after your previous comments (where
this simple bits-to-bytes apparently didn't come through) and got
somehow carried away ;-)

>> +if ( !pendtable )
>> +return 0;
>> +
>> +memset(pendtable, 0, BIT_ULL(lpi_data.host_lpi_bits) / 8);
>> +__flush_dcache_area(pendtable, BIT_ULL(lpi_data.host_lpi_bits) / 8);
>> +
>> +this_cpu(pending_table) = pendtable;
>> +}
>> +else
>> +{
>> +pendtable = 

Re: [Xen-devel] [PATCH] x86/mtrr: use stdbool instead of int + define

[Jan Beulich]

>>> On 05.01.17 at 17:26,  wrote:
> -static void set_fixed_range(int msr, int * changed, unsigned int * msrwords)
> +static void set_fixed_range(int msr, bool * changed, unsigned int * msrwords)

Would have been nice to get the stray blanks here and elsewhere
dropped, as the lines are being touched anyway.

Jan


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

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

[Andrew Cooper]

On 05/01/17 16:53, Boris Ostrovsky wrote:
> On 01/04/2017 08:33 AM, Jan Beulich wrote:
> On 03.01.17 at 13:06,  wrote:
>>> --- a/xen/arch/x86/cpu/cpu.h
>>> +++ b/xen/arch/x86/cpu/cpu.h
>>> @@ -1,9 +1,13 @@
>>>  /* attempt to consolidate cpu attributes */
>>>  struct cpu_dev {
>>> -   char* c_vendor;
>>> +   charc_vendor[8];
>>>  
>>> -   /* some have two possibilities for cpuid string */
>>> -   char* c_ident[2];   
>>> +   union {
>>> +   charc_ident[13];
>>> +   struct {
>>> +   uint32_t b, d, c;
>>> +   };
>>> +   };
>> This broke the build with at least gcc 4.3.x, which doesn't allow
>> initializers for unnamed struct/union.
> 4.4 is also broken. I believe anonymous initializers were added in gcc 4.6.

When I am out of meetings, I will post a fix.  I have a plan.

~Andrew

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

Re: [Xen-devel] [edk2] [PATCH RFC 14/14] XenOvmf: Use a different RTC

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> ---
>  OvmfPkg/XenOvmf.dsc | 5 -
>  OvmfPkg/XenOvmf.fdf | 2 +-
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index a7a884e..345157b 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -567,7 +567,10 @@
>}
>MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>MdeModulePkg/Universal/Metronome/Metronome.inf
> -  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +  EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf {
> +
> +  
> RealTimeClockLib|ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> +  }
>MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
>  
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index a500ab6..65db2ba 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -217,7 +217,7 @@ INF  
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
>  INF  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
>  INF  MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>  INF  MdeModulePkg/Universal/Metronome/Metronome.inf
> -INF  
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +INF  EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>  
>  INF  OvmfPkg/BlockMmioToBlockIoDxe/BlockIo.inf
>  INF  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> 

(1) The subject should be

  OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg

or similar.

(2) By tradition, ArmVirtPkg is welcome to consume modules from OvmfPkg,
but not the other way around. If you need

  ArmVirtPkg/Library/XenRealTimeClockLib

in an OvmfPkg platform, please move the library instance first to
OvmfPkg, redirecting the ArmVirtPkg references, and then consume the
library in OvmfPkg, internally to OvmfPkg.

Thanks
Laszlo

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

Re: [Xen-devel] [edk2] [PATCH RFC 13/14] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> This "device" use XenIoMmioLib to reserve some space to be use by grant
> tables. It's use 0xfc00, which might not be a good choice...
> 
> There is probably a better way that using a device for this.
> ---
>  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c   | 263 
> 
>  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf |  45 ++
>  OvmfPkg/XenOvmf.dsc |   2 +
>  OvmfPkg/XenOvmf.fdf |   1 +
>  4 files changed, 311 insertions(+)
>  create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
>  create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf

I recommend to check out the existent use of XenIoMmioLib, namely in
"ArmVirtPkg/XenioFdtDxe".

In brief, for such purposes a DXE_DRIVER is appropriate, where you
simply do the deed (call XenIoMmioInstall()) in the driver's entry point
function. No need for a UEFI_DRIVER module which conforms to the UEFI
Driver Model.

Regarding where to put the area: no clue. If it doesn't overlap any
memory area added in (Xen)PlatformPei with memory resource descriptors,
nor areas added later in DXE, with gDS->AddMemorySpace(), then it should
be fine.

From a quick look, 0xFC00 should work. For completeness, I'd also
modify the (DXE) driver to call gDS->AddMemorySpace() with type
EfiGcdMemoryTypeReserved, and also immediately call
gDS->AllocateMemorySpace() with the same type and EfiGcdAllocateAddress,
in order to allocate the exact reserved chunk.

(See "7.2 Global Coherency Domain Services" in vol2 of the Platform Init
spec for background.)

OTOH, I don't see why a simple AllocateReservedPages() call wouldn't
work (which would carve a chunk out of normal system memory for this).
Why did you comment that out in the code below?

Also, please don't forget the Citrix copyright notice etc etc.

Thanks
Laszlo

> 
> diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c 
> b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> new file mode 100644
> index 000..12e076f
> --- /dev/null
> +++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> @@ -0,0 +1,263 @@
> +/** @file
> +
> +  XXX
> +
> +  XXX
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution. The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* #include  */
> +STATIC BOOLEAN mXenIoInitialized = FALSE;
> +
> +/**
> +
> +  Device probe function for this driver.
> +
> +  The DXE core calls this function for any given device in order to see if 
> the
> +  driver can drive the device.
> +
> +  @param[in]  ThisThe EFI_DRIVER_BINDING_PROTOCOL object
> +  incorporating this driver (independently of
> +  any device).
> +
> +  @param[in] DeviceHandle The device to probe.
> +
> +  @param[in] RemainingDevicePath  Relevant only for bus drivers, ignored.
> +
> +
> +  @retval EFI_SUCCESS  The driver supports the device being probed.
> +
> +  @retval EFI_UNSUPPORTED  The driver does not support the device being 
> probed.
> +
> +  @return  Error codes from the OpenProtocol() boot service 
> or
> +   the PciIo protocol.
> +
> +**/
> +#if 1
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +XenIoPvhDeviceBindingSupported (
> +  IN EFI_DRIVER_BINDING_PROTOCOL *This,
> +  IN EFI_HANDLE  DeviceHandle,
> +  IN EFI_DEVICE_PATH_PROTOCOL*RemainingDevicePath
> +  )
> +{
> +
> +  // XXX check if running Xen PVH
> +  //
> +
> +  if (mXenIoInitialized) {
> +return EFI_ALREADY_STARTED;
> +  }
> +
> +  DEBUG((EFI_D_INFO, "%a %d\n", __FUNCTION__, __LINE__));
> +  return EFI_SUCCESS;
> +}
> +#endif
> +
> +/**
> +
> +  After we've pronounced support for a specific device in
> +  DriverBindingSupported(), we start managing said device (passed in by the
> +  Driver Execution Environment) with the following service.
> +
> +  See DriverBindingSupported() for specification references.
> +
> +  @param[in]  ThisThe EFI_DRIVER_BINDING_PROTOCOL object
> +  incorporating this driver (independently of
> +  any device).
> +
> +  @param[in] DeviceHandle The supported device to drive.
> +
> +  @param[in] RemainingDevicePath  Relevant only for bus drivers, ignored.
> +
> +
> +  @retval EFI_SUCCESS   The device was started.
> +
> +  @retval EFI_OUT_OF_RESOURCES  Memory allocation failed.
> +
> +  @return   Error codes from the OpenProtocol() boot
> +service, the PciIo protocol or the
> +

Re: [Xen-devel] [PATCH] x86/mtrr: use stdbool instead of int + define

[Andrew Cooper]

On 05/01/17 16:26, Doug Goldstein wrote:
> Instead of using an int and providing a define for TRUE and FALSE,
> change the code to use stdbool that Xen provides.
>
> Signed-off-by: Doug Goldstein 

Reviewed-by: Andrew Cooper  and queued

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

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

[Boris Ostrovsky]

On 01/04/2017 08:33 AM, Jan Beulich wrote:
 On 03.01.17 at 13:06,  wrote:
>> --- a/xen/arch/x86/cpu/cpu.h
>> +++ b/xen/arch/x86/cpu/cpu.h
>> @@ -1,9 +1,13 @@
>>  /* attempt to consolidate cpu attributes */
>>  struct cpu_dev {
>> -char* c_vendor;
>> +charc_vendor[8];
>>  
>> -/* some have two possibilities for cpuid string */
>> -char* c_ident[2];   
>> +union {
>> +charc_ident[13];
>> +struct {
>> +uint32_t b, d, c;
>> +};
>> +};
> This broke the build with at least gcc 4.3.x, which doesn't allow
> initializers for unnamed struct/union.

4.4 is also broken. I believe anonymous initializers were added in gcc 4.6.


-boris

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

Re: [Xen-devel] [edk2] [PATCH RFC 12/14] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> and add OvmfPkg/XenConsoleIo/XenConsoleIo to XenOvmf platform.
> 
> It actually look for gEfiSerialIoProtocolGuid.
> ---
>  .../Library/PlatformBootManagerLib/BdsPlatform.c   | 33 
> ++
>  .../PlatformBootManagerLib.inf |  2 ++
>  OvmfPkg/XenOvmf.dsc|  4 +++
>  OvmfPkg/XenOvmf.fdf|  1 +
>  4 files changed, 40 insertions(+)
> 
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> index bd64cc3..b8972f7 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -904,6 +904,31 @@ DetectAndPreparePlatformPciDevicePaths (
>return VisitAllPciInstances (DetectAndPreparePlatformPciDevicePath);
>  }
>  
> +#include 
> +EFI_STATUS
> +EFIAPI
> +add_serial (
> +  IN EFI_HANDLE  DeviceHandle,
> +  IN VOID*Instance,
> +  IN VOID*Context
> +  )
> +{
> +  EFI_DEVICE_PATH_PROTOCOL  *DevicePath = NULL;
> +
> +  DevicePath = DevicePathFromHandle(DeviceHandle);
> +  if (DevicePath == NULL) {
> +return EFI_NOT_FOUND;
> +  }
> +
> +  DevicePath = AppendDevicePathNode (DevicePath, (EFI_DEVICE_PATH_PROTOCOL 
> *));
> +  DEBUG((EFI_D_ERROR, "%a %d: full path: %s\n", __FUNCTION__, __LINE__,
> + ConvertDevicePathToText(DevicePath, TRUE, FALSE)
> + ));
> +  EfiBootManagerUpdateConsoleVariable (ConOut, DevicePath, NULL);
> +  EfiBootManagerUpdateConsoleVariable (ConIn, DevicePath, NULL);
> +  EfiBootManagerUpdateConsoleVariable (ErrOut, DevicePath, NULL);
> +  return EFI_SUCCESS;
> +}
>  
>  VOID
>  PlatformInitializeConsole (
> @@ -931,6 +956,14 @@ Arguments:
>GetEfiGlobalVariable2 (EFI_CON_OUT_VARIABLE_NAME, (VOID **) , 
> NULL);
>GetEfiGlobalVariable2 (EFI_CON_IN_VARIABLE_NAME, (VOID **) , 
> NULL);
>  
> +  // do xen console
> +  //VISIT_PCI_INSTANCE_CALLBACK CallBackFunction
> +  VisitAllInstancesOfProtocol (
> +   ,
> +   add_serial,
> +   (VOID*)NULL
> +   );
> +
>if (VarConout == NULL || VarConin == NULL) {
>  //
>  // Do platform specific PCI Device check and add them to ConOut, ConIn, 
> ErrOut
> diff --git 
> a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index 4a6bece..74ab6b1 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -73,6 +73,8 @@
>gEfiLoadedImageProtocolGuid   # PROTOCOL SOMETIMES_PRODUCED
>gEfiFirmwareVolume2ProtocolGuid   # PROTOCOL SOMETIMES_CONSUMED
>  
> +  gEfiSerialIoProtocolGuid
> +
>  [Guids]
>gEfiXenInfoGuid
>gEfiEndOfDxeEventGroupGuid
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 31a2185..8bce996 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -590,6 +590,10 @@
>OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +  OvmfPkg/XenConsoleIo/XenConsoleIo.inf {
> +
> +  
> SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
> +  }
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
>MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index f6876d7..a40d186 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -223,6 +223,7 @@ INF  OvmfPkg/BlockMmioToBlockIoDxe/BlockIo.inf
>  INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>  INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
>  INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +INF  OvmfPkg/XenConsoleIo/XenConsoleIo.inf
>  
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>INF  
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> 

Okay, so this patch forced me to review the current additions of serial
port devpaths to ConIn, ConOut, ErrOut in

  OvmfPkg/Library/PlatformBootManagerLib/

I think I understand what you intend to do. I'd like to propose an
alternative I feel would be better.

You are introducing a new driver called "XenConsoleIo" which I assume is
a DXE_DRIVER module that produces gEfiSerialIoProtocolGuid. The reason I
can only "assume" is that you apparently forgot to include the driver in
the patch, with "git add". Nonetheless, without having seen the driver,
I claim that it should be unnecessary.

Namely, MdeModulePkg provides a generic platform serial driver, under

  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf

This driver is already used in the ARM Xen guest platform:

  ArmVirtPkg/ArmVirtXen.dsc

with a dependency on

  OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu12597061b3fd71f8f97c18acf508241f290d55d5
baseline version:
 qemuudbe2b65566e76d3c3a0c3358285c0336ac61e757

Last test of basis   103992  2016-12-29 00:42:45 Z7 days
Testing same since   104044  2017-01-05 11:14:12 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Li Qiang 
  Peter Maydell 
  Prasad J Pandit 

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

Re: [Xen-devel] [PATCH v2 2/2] build: use debug_symbols to add -g3

[Ian Jackson]

Wei Liu writes ("Re: [PATCH v2 2/2] build: use debug_symbols to add -g3"):
> On Tue, Jan 03, 2017 at 02:07:31AM -0700, Jan Beulich wrote:
> > On 23.12.16 at 13:24,  wrote:
> > > @@ -146,7 +146,7 @@ SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) 
> > > -Wl,-rpath-link=$(XEN_LIBVCHAN)
> > >  
> > >  ifeq ($(debug),y)
> > >  # Disable optimizations and enable debugging information for macros
> > > -CFLAGS += -O0 -g3 -fno-omit-frame-pointer
> > > +CFLAGS += -O0 -fno-omit-frame-pointer
> > 
> > I think you want to also adjust the comment then.
> > 
> 
> I think I will just change the comment to:
> 
>   # Disable optimizations

With that change,

Acked-by: Ian Jackson 

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

[Xen-devel] [PATCH] x86/mtrr: use stdbool instead of int + define

[Doug Goldstein]

Instead of using an int and providing a define for TRUE and FALSE,
change the code to use stdbool that Xen provides.

Signed-off-by: Doug Goldstein 
---
 xen/arch/x86/cpu/mtrr/generic.c | 21 +++--
 xen/arch/x86/cpu/mtrr/mtrr.h|  5 -
 2 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index 012aca4..2d2eadc 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -237,7 +238,7 @@ static void mtrr_wrmsr(unsigned int msr, uint64_t 
msr_content)
  * \param changed pointer which indicates whether the MTRR needed to be changed
  * \param msrwords pointer to the MSR values which the MSR should have
  */
-static void set_fixed_range(int msr, int * changed, unsigned int * msrwords)
+static void set_fixed_range(int msr, bool * changed, unsigned int * msrwords)
 {
uint64_t msr_content, val;
 
@@ -246,7 +247,7 @@ static void set_fixed_range(int msr, int * changed, 
unsigned int * msrwords)
 
if (msr_content != val) {
mtrr_wrmsr(msr, val);
-   *changed = TRUE;
+   *changed = true;
}
 }
 
@@ -302,10 +303,10 @@ void mtrr_generic_get(unsigned int reg, unsigned long 
*base,
  * Checks and updates the fixed-range MTRRs if they differ from the saved set
  * \param frs pointer to fixed-range MTRR values, saved by get_fixed_ranges()
  */
-static int set_fixed_ranges(mtrr_type * frs)
+static bool set_fixed_ranges(mtrr_type * frs)
 {
unsigned long long *saved = (unsigned long long *) frs;
-   int changed = FALSE;
+   bool changed = false;
int block=-1, range;
 
while (fixed_range_blocks[++block].ranges)
@@ -316,13 +317,13 @@ static int set_fixed_ranges(mtrr_type * frs)
return changed;
 }
 
-/*  Set the MSR pair relating to a var range. Returns TRUE if
+/*  Set the MSR pair relating to a var range. Returns true if
 changes are made  */
-static int set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
+static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
 {
uint32_t lo, hi, base_lo, base_hi, mask_lo, mask_hi;
uint64_t msr_content;
-   int changed = FALSE;
+   bool changed = false;
 
rdmsrl(MSR_IA32_MTRR_PHYSBASE(index), msr_content);
lo = (uint32_t)msr_content;
@@ -337,7 +338,7 @@ static int set_mtrr_var_ranges(unsigned int index, struct 
mtrr_var_range *vr)
 
if ((base_lo != lo) || (base_hi != hi)) {
mtrr_wrmsr(MSR_IA32_MTRR_PHYSBASE(index), vr->base);
-   changed = TRUE;
+   changed = true;
}
 
rdmsrl(MSR_IA32_MTRR_PHYSMASK(index), msr_content);
@@ -353,7 +354,7 @@ static int set_mtrr_var_ranges(unsigned int index, struct 
mtrr_var_range *vr)
 
if ((mask_lo != lo) || (mask_hi != hi)) {
mtrr_wrmsr(MSR_IA32_MTRR_PHYSMASK(index), vr->mask);
-   changed = TRUE;
+   changed = true;
}
return changed;
 }
@@ -478,7 +479,7 @@ void mtrr_generic_set(unsigned int reg, unsigned long base,
  The base address of the region.
  The size of the region. If this is 0 the region is disabled.
  The type of the region.
- If TRUE, do the change safely. If FALSE, safety measures should
+ If true, do the change safely. If false, safety measures should
 be done externally.
 [RETURNS] Nothing.
 */
diff --git a/xen/arch/x86/cpu/mtrr/mtrr.h b/xen/arch/x86/cpu/mtrr/mtrr.h
index 1a3b1e5..9d55c68 100644
--- a/xen/arch/x86/cpu/mtrr/mtrr.h
+++ b/xen/arch/x86/cpu/mtrr/mtrr.h
@@ -2,11 +2,6 @@
  * local mtrr defines.
  */
 
-#ifndef TRUE
-#define TRUE  1
-#define FALSE 0
-#endif
-
 #define MTRR_CHANGE_MASK_FIXED 0x01
 #define MTRR_CHANGE_MASK_VARIABLE  0x02
 #define MTRR_CHANGE_MASK_DEFTYPE   0x04
-- 
2.10.2


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

Re: [Xen-devel] [PATCH v2] build: move setting LTO options to xen/Rules.mk

[Ian Jackson]

Wei Liu writes ("[PATCH v2] build: move setting LTO options to xen/Rules.mk"):
> Having them in StdGNU.mk would affect both hypervisor and tools build.
> However judging from the commit message of e4cdd74f LTO was only meant
> to affect hypvervisor build.
> 
> Move the relevant bits to xen/Rules.mk.

Acked-by: Ian Jackson 

I think -flto is a very bad idea for the tools build and I think we
should backport this change.

Ian.

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

Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

[Jan Beulich]

>>> On 05.01.17 at 17:03,  wrote:
> On 01/05/2017 05:45 PM, Jan Beulich wrote:
> On 22.12.16 at 09:12,  wrote:
>> Other than that the primary thing I'm missing (as I think I've
>> mentioned elsewhere already) is a rationale of why this new
>> protocol is needed (and the existing xenfb one can't be extended).
> "This protocol aims to provide a unified protocol which fits more
> 
> sophisticated use-cases than a framebuffer device can handle. At the
> moment basic functionality is supported with the intention to extend:
>   o multiple dynamically allocated/destroyed framebuffers
>   o buffers of arbitrary sizes
>   o better configuration options including multiple display support"

Well, that's all stuff you had spelled out in the accompanying mail,
but that's all items which could be taken care of by a protocol
extension too.

> I tried to evaluate what would it be like to extend existing fbif...
> It looks like having 2 different protocols in a single file.

This is what I'd like you to expand on.

> What is more fbif can be used together with displif running at the
> same time, e.g. on Linux one provides framebuffer and another DRM

And this is certainly a valid argument (which hence should be
spelled out in the description).

Jan


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

Re: [Xen-devel] [PATCH v2 10/10] x86/SVM: Add AMD AVIC key handler

[Jan Beulich]

>>> On 31.12.16 at 06:46,  wrote:
> +void __init setup_avic_dump(void)
> +{
> +register_keyhandler('j', avic_dump, "dump SVM AVIC", 1);
> +}

For one the description should include the word "stats". And then
I'm rather uncertain this is work burning one of the few remaining
available keys. Could this be made a domctl instead?

Jan


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

Re: [Xen-devel] [PATCH v2 09/10] x86/SVM: Hook up miscellaneous AVIC functions

[Jan Beulich]

>>> On 31.12.16 at 06:46,  wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1438,6 +1438,11 @@ static int svm_cpu_up(void)
>  return 0;
>  }
>  
> +static inline int svm_avic_enabled(void)

bool?

> @@ -1472,16 +1477,27 @@ const struct hvm_function_table * __init 
> start_svm(void)
>  P(cpu_has_svm_decode, "DecodeAssists");
>  P(cpu_has_pause_filter, "Pause-Intercept Filter");
>  P(cpu_has_tsc_ratio, "TSC Rate MSR");
> -P(cpu_has_svm_avic, "AVIC");
> -#undef P
> -
> -if ( !printed )
> -printk(" - none\n");
>  
>  svm_function_table.hap_supported = !!cpu_has_svm_npt;
>  svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
>  ((cpuid_edx(0x8001) & 0x0400) ? HVM_HAP_SUPERPAGE_1GB : 0);
>  
> +if ( !cpu_has_svm_avic )
> +svm_avic = 0;
> +
> +if ( svm_avic )
> +{
> +svm_function_table.deliver_posted_intr  = 
> svm_avic_deliver_posted_intr;
> +svm_function_table.virtual_intr_delivery_enabled = svm_avic_enabled;
> +P(cpu_has_svm_avic, "AVIC (enabled)");
> +}
> +else
> +P(cpu_has_svm_avic, "AVIC (disabled)");
> +#undef P
> +
> +if ( !printed )
> +printk(" - none\n");

Could I talk you into moving this up a few lines, so that effectively
the last four lines here won't need to move at all?

Jan


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

Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

[Oleksandr Andrushchenko]

On 01/05/2017 05:45 PM, Jan Beulich wrote:

On 22.12.16 at 09:12,  wrote:

+struct xendispl_pg_flip_evt {
+uint64_t fb_cookie;

Considering that apparently all operations have this cookie, I think
it would better go ...


+};
+
+struct xendispl_req {
+uint16_t id;
+uint8_t operation;
+uint8_t reserved[5];

... here.

If someone adds another event which doesn't need it?
IMO, this is ok to reside where it is.

Other than that the primary thing I'm missing (as I think I've
mentioned elsewhere already) is a rationale of why this new
protocol is needed (and the existing xenfb one can't be extended).

"This protocol aims to provide a unified protocol which fits more

sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention to extend:
 o multiple dynamically allocated/destroyed framebuffers
 o buffers of arbitrary sizes
 o better configuration options including multiple display support"

I tried to evaluate what would it be like to extend existing fbif...
It looks like having 2 different protocols in a single file.
What is more fbif can be used together with displif running at the
same time, e.g. on Linux one provides framebuffer and another DRM


Jan




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

Re: [Xen-devel] [PATCH v2 08/10] x86/SVM: Add interrupt management code via AVIC

[Jan Beulich]

>>> On 31.12.16 at 06:45,  wrote:
> --- a/xen/arch/x86/hvm/svm/avic.c
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -636,6 +636,34 @@ void svm_avic_vmexit_do_noaccel(struct cpu_user_regs 
> *regs)
>  return;
>  }
>  
> +void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vec)
> +{
> +struct vlapic *vlapic = vcpu_vlapic(v);
> +
> +/* Fallback to use non-AVIC if vcpu is not enabled with AVIC. */
> +if ( !svm_avic_vcpu_enabled(v) )
> +{
> +if ( !vlapic_test_and_set_vector(vec, >regs->data[APIC_IRR]) 
> )
> +vcpu_kick(v);
> +return;
> +}
> +
> +if ( !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) )
> +return;

On top of Andrew's comment, this assumes v == current, which you
neither assert, nor allow the reviewers to verify (as the function has
no caller).

Jan


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

[Xen-devel] Request for help: Help integrating Xen into Google oss-fuzz

[Wei Liu]

Hi all

Oss-fuzz [0] is a continuous fuzzing service for open source
software. During last release cycle we put in a lot of effort to fuzz
Xen, so it would make sense to try to run it in oss-fuzz.

We've already committed two fuzzing targets (x86 emulator and libelf,
both of which happen to get a lot of changes recently) in
xen.git. We're still missing some shell scripts and a dockerfile to
integrate those targets into oss-fuzz (example [1]).

Would anyone be interested in such task?  Drop me a private email if
you're interested in helping. We would need to discuss the interface
between Xen build system and the scripts.

Regards,
Wei.

[0] https://github.com/google/oss-fuzz
[1] https://github.com/google/oss-fuzz/tree/master/projects/expat

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

[Xen-devel] Xenstore/ xenstored

[Yessine Daoud]

Hello,

I have a question regarding the daemon xenstored running on dom0.
Xenstored is responsable for communication with xenstore.

How xenstored dump the xenstore? for example I send the following path to
xenstored :
/local/domain/1/name: normally xenstored will receive this path and will
search the corresponding value.

How this mechanism is done ?
Is there a known algorithm to dump the xenstore content ?
How to locate the path ? data ?

Best Regards,



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

Re: [Xen-devel] [PATCH v2 03/10] x86/HVM: Call vlapic_destroy after vcpu_destroy

[Jan Beulich]

>>> On 31.12.16 at 06:45,  wrote:
> Since vlapic_init() is called before vcpu_initialise().
> We should call the destroy functions in the the reverse order here.

Double "the". And to quote from my RFC reply:

"Also the ordering issue extends to other calls, and I think if at all
 possible we should then do all the teardown in reverse order of
 init."

Is there anything preventing this?

Jan


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

Re: [Xen-devel] [PATCH v2 02/10] x86/vLAPIC: Declare vlapic_read_aligned() and vlapic_reg_write() as non-static

[Jan Beulich]

>>> On 31.12.16 at 06:45,  wrote:
> Expose vlapic_read_aligned and vlapic_reg_write() to be used by AVIC.
> 
> Signed-off-by: Suravee Suthikulpanit 
> Reviewed-by: Konrad Rzeszutek Wilk 

Generally I dislike functions being non-static when all their callers
live in the same file. Therefore it would be better (and hardly
harder to review) if they got made non-static at the point of their
first external use. That'll also help understanding whether that's
an appropriate move.

Jan


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

Re: [Xen-devel] [PATCH v2 01/10] x86/HVM: Introduce struct hvm_pi_ops

[Jan Beulich]

>>> On 31.12.16 at 06:45,  wrote:
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -72,6 +72,67 @@ struct hvm_ioreq_server {
>  bool_t bufioreq_atomic;
>  };
>  
> +struct hvm_pi_ops {
> +/*
> + * To handle posted interrupts correctly, we need to set the following
> + * state:
> + *
> + * * The PI notification vector (NV)
> + * * The PI notification destination processor (NDST)
> + * * The PI "suppress notification" bit (SN)
> + * * The vcpu pi "blocked" list
> + *
> + * If a VM is currently running, we want the PI delivered to the guest 
> vcpu
> + * on the proper pcpu (NDST = v->processor, SN clear).
> + *
> + * If the vm is blocked, we want the PI delivered to Xen so that it can
> + * wake it up  (SN clear, NV = pi_wakeup_vector, vcpu on block list).
> + *
> + * If the VM is currently either preempted or offline (i.e., not running
> + * because of some reason other than blocking waiting for an interrupt),
> + * there's nothing Xen can do -- we want the interrupt pending bit set in
> + * the guest, but we don't want to bother Xen with an interrupt (SN 
> clear).
> + *
> + * There's a brief window of time between vmx_intr_assist() and checking
> + * softirqs where if an interrupt comes in it may be lost; so we need Xen
> + * to get an interrupt and raise a softirq so that it will go through the
> + * vmx_intr_assist() path again (SN clear, NV = posted_interrupt).
> + *
> + * The way we implement this now is by looking at what needs to happen on
> + * the following runstate transitions:
> + *
> + * A: runnable -> running
> + *  - SN = 0
> + *  - NDST = v->processor
> + * B: running -> runnable
> + *  - SN = 1
> + * C: running -> blocked
> + *  - NV = pi_wakeup_vector
> + *  - Add vcpu to blocked list
> + * D: blocked -> runnable
> + *  - NV = posted_intr_vector
> + *  - Take vcpu off blocked list
> + *
> + * For transitions A and B, we add hooks into vmx_ctxt_switch_{from,to}
> + * paths.
> + *
> + * For transition C, we add a new arch hook, arch_vcpu_block(), which is
> + * called from vcpu_block() and vcpu_do_poll().
> + *
> + * For transition D, rather than add an extra arch hook on vcpu_wake, we
> + * add a hook on the vmentry path which checks to see if either of the 
> two
> + * actions need to be taken.
> + *
> + * These hooks only need to be called when the domain in question 
> actually
> + * has a physical device assigned to it, so we set and clear the 
> callbacks
> + * as appropriate when device assignment changes.
> + */
> +void (*vcpu_block) (struct vcpu *);
> +void (*pi_switch_from) (struct vcpu *v);
> +void (*pi_switch_to) (struct vcpu *v);
> +void (*pi_do_resume) (struct vcpu *v);
> +};

While the hooks (as said, with the pi_ prefixes dropped) are
certainly fine to move here, the comment is extremely VMX
centric, and hence doesn't fit in this file. It either needs to be
generalized, or it should remain in VMX specific code, perhaps
with a referral to it added here.

Jan


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

Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

[Jan Beulich]

>>> On 22.12.16 at 09:12,  wrote:
> +struct xendispl_pg_flip_evt {
> +uint64_t fb_cookie;

Considering that apparently all operations have this cookie, I think
it would better go ...

> +};
> +
> +struct xendispl_req {
> +uint16_t id;
> +uint8_t operation;
> +uint8_t reserved[5];

... here.

Other than that the primary thing I'm missing (as I think I've
mentioned elsewhere already) is a rationale of why this new
protocol is needed (and the existing xenfb one can't be extended).

Jan


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

Re: [Xen-devel] [PATCH 22/27] x86/cpuid: Perform max_leaf calculations in guest_cpuid()

[Jan Beulich]

>>> On 05.01.17 at 16:02,  wrote:
> On 05/01/17 14:52, Jan Beulich wrote:
> On 05.01.17 at 15:28,  wrote:
>>> What else would you suggest?  One way or another (better shown in the
>>> context of the following patch), we need one block per union{} to apply
>>> max_leaf calculations and read the base data from p->$FOO.raw[$IDX].
>> Actually, perhaps a mixture: Inside the default case have
>>
>> if ( leaf == 0x7 )
>> {
>> if ( subleaf > p->feat.max_subleaf )
>> return;
>> }
>> else if ( leaf == 0xd)
>> {
>> if ( subleaf > ARRAY_SIZE(p->xstate.raw) )
>> return;
>> }
>> if ( leaf > p->basic.max_leaf )
>> return;
>>
>> Which (by making the last one if rather than else-if) also fixes an
>> issue I've spotted only now: So far you exclude leaves 7 and 0xd
>> from the basic.max_leaf checking. (And this way that check could
>> also go first.)
> 
> Very good point, although I still think I'd still prefer a logic block
> in this form inside a case 0 ... 0x3fff to avoid potential leakage
> if other logic changes.

Well, that's certainly fine with me.

Jan


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

Re: [Xen-devel] [PATCH v2] build: move setting LTO options to xen/Rules.mk

[Jan Beulich]

>>> On 05.01.17 at 16:23,  wrote:
> On 05/01/17 15:09, Wei Liu wrote:
>> On Fri, Dec 23, 2016 at 12:12:36PM +, Wei Liu wrote:
>>> Having them in StdGNU.mk would affect both hypervisor and tools build.
>>> However judging from the commit message of e4cdd74f LTO was only meant
>>> to affect hypvervisor build.
>>>
>>> Move the relevant bits to xen/Rules.mk.
>>>
>>> Signed-off-by: Wei Liu 
>> Ping?
> 
> Reviewed-by: Andrew Cooper 
> 
> /me looks at the date and isn't surprised that this patch slipped
> through the cracks.

I don't even have a patch named like this in my inbox; the only
thing I have is a 2-patch series titled "More fixes for lto option"
from Dec 22nd.

Jan


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

[Xen-devel] [xen-unstable test] 104040: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  44325775f7241311087558bb895d1a18100d589f
baseline version:
 xen  44325775f7241311087558bb895d1a18100d589f

Last test of basis   104040  2017-01-05 08:35:30 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17171 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 

Re: [Xen-devel] [PATCH v2] x86: drop cpu_has_sse{,2}

[Andrew Cooper]

On 05/01/17 15:12, Jan Beulich wrote:
> Commit dc88221c97 ("x86: rename XMM* features to SSE*") pointlessly
> added them - these features are always available on 64-bit CPUs. (Let's
> not assume this for MMX though in at least the insn emulator.)
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 00/11] Convert a few docs/misc pages into man pages

[Wei Liu]

On Thu, Jan 05, 2017 at 04:12:46PM +0100, Cedric Bosdonnat wrote:
> On Thu, 2017-01-05 at 15:01 +, Wei Liu wrote:
> > On Wed, Jan 04, 2017 at 04:49:25PM +0100, Cedric Bosdonnat wrote:
> > > On Wed, 2017-01-04 at 15:07 +, Wei Liu wrote:
> > > > On Fri, Dec 09, 2016 at 05:17:03PM +0100, Cédric Bosdonnat wrote:
> > > > > As pointed out in Ian and Andrew's emails on my recent docs 
> > > > > improvement
> > > > > attempt, getting the documents from docs/misc referenced in man pages
> > > > > as man pages would would make these pages more visible for users. This
> > > > > would also not break the docs html INDEX.
> > > > > 
> > > > > This series adds ability to write markdown man pages. Be aware that
> > > > > markdown man pages can't link to other man pages.
> > > > > 
> > > > > I also added some pages to man 7 (Misc) section.
> > > > > 
> > > > 
> > > > Do you have a git branch that I can pull from?
> > > 
> > > The docs branch on https://github.com/cbosdo/xen
> > 
> > I think I've gone through all of the patches. Please address Daniel's
> > comments and resend this series.
> 
> They were already addressed in the repo I pointed you to.
> 

Right. I missed that, sorry.

I think you need some more renaming. tscmode.7 and vbd-interface.7
should have xen- prefix, too.

Wei.

> --
> Cedric

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

Re: [Xen-devel] [PATCH v2] build: move setting LTO options to xen/Rules.mk

[Andrew Cooper]

On 05/01/17 15:09, Wei Liu wrote:
> On Fri, Dec 23, 2016 at 12:12:36PM +, Wei Liu wrote:
>> Having them in StdGNU.mk would affect both hypervisor and tools build.
>> However judging from the commit message of e4cdd74f LTO was only meant
>> to affect hypvervisor build.
>>
>> Move the relevant bits to xen/Rules.mk.
>>
>> Signed-off-by: Wei Liu 
> Ping?

Reviewed-by: Andrew Cooper 

/me looks at the date and isn't surprised that this patch slipped
through the cracks.

~Andrew

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

Re: [Xen-devel] [BUG] Xen-4.8.0 efi/buildid.o: file not recognized/Ambiguous

[Jan Beulich]

>>> On 05.01.17 at 16:09,  wrote:
> On 12/22/16 8:46 AM, Jan Beulich wrote:
> On 07.12.16 at 16:57,  wrote:
>>>  efi/buildid.o: file not recognized: File format is ambiguous
>>>  efi/buildid.o: matching formats: coff-x86-64 pe-x86-64
>> 
>> Just fyi: After some analysis of the binutils sources I have come to
>> the conclusion that this needs help from the binutils folks. I've just
>> sent
>> https://sourceware.org/ml/binutils/2016-12/msg00374.html 
>> to see if they have any advice.
>> 
> 
> Has anything come of this? I'm not sure how we can use match_priority or
> if they're saying they need to make changes to binutils. At this point
> I'm not able to compile Xen myself without local hackery.

As said on irc, I don't see how the responses we've got so far allow
for progress towards a resolution. However, I also don't see the
value of building binutils in this way, as COFF objects - afaict - would
simply be unusable (without command line override) for anyone else
too. So besides the option of us hacking around the issue, I'd like
distro maintainers of binutils packages to consider correcting their
./configure options, to produce something that's actually usable.

Jan


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

Re: [Xen-devel] [PATCH v2] build: move setting LTO options to xen/Rules.mk

[Wei Liu]

On Fri, Dec 23, 2016 at 12:12:36PM +, Wei Liu wrote:
> Having them in StdGNU.mk would affect both hypervisor and tools build.
> However judging from the commit message of e4cdd74f LTO was only meant
> to affect hypvervisor build.
> 
> Move the relevant bits to xen/Rules.mk.
> 
> Signed-off-by: Wei Liu 

Ping?

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

Re: [Xen-devel] [PATCH v2 2/2] build: use debug_symbols to add -g3

[Wei Liu]

On Tue, Jan 03, 2017 at 02:07:31AM -0700, Jan Beulich wrote:
> >>> On 23.12.16 at 13:24,  wrote:
> > @@ -146,7 +146,7 @@ SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) 
> > -Wl,-rpath-link=$(XEN_LIBVCHAN)
> >  
> >  ifeq ($(debug),y)
> >  # Disable optimizations and enable debugging information for macros
> > -CFLAGS += -O0 -g3 -fno-omit-frame-pointer
> > +CFLAGS += -O0 -fno-omit-frame-pointer
> 
> I think you want to also adjust the comment then.
> 

I think I will just change the comment to:

  # Disable optimizations

Wei.

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

Re: [Xen-devel] [PATCH 27/27] x86/cpuid: Alter the legacy-path prototypes to match guest_cpuid()

[Andrew Cooper]

On 05/01/17 14:19, Jan Beulich wrote:
 On 04.01.17 at 13:39,  wrote:
>> Here and elsewhere, it is becomes very obvious that the PVH path using
>> pv_cpuid() is broken, as the guest_kernel_mode() check using
>> guest_cpu_user_regs() is erroneous.  I am tempted to just switch PVH onto the
>> HVM path, which won't make it any more broken than it currently is.
> Are you sure? There was a reason it had been done this way back then.

Oh yes, the same problem Roger is having with PVHv2.  Only the
pv_cpuid() path has logic to read from native in the case of the control
domain, for whom no policy is constructed.

This series lays a lot of groundwork to fixing the dom0 policy problem,
but wont be fully working for PVHv2 until I remove all of the legacy
path. (and that is at least the same quantity of work again, I reckon).

>
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -337,30 +337,26 @@ int init_domain_cpuid_policy(struct domain *d)
>>  return 0;
>>  }
>>  
>> -static void pv_cpuid(struct cpu_user_regs *regs)
>> +static void pv_cpuid(unsigned int leaf, unsigned int subleaf,
>> + struct cpuid_leaf *res)
>>  {
>> -uint32_t leaf, subleaf, a, b, c, d;
>> +const struct cpu_user_regs *regs = guest_cpu_user_regs();
> Please consider moving this into the !is_pvh_domain() scope,
> open coding the one access outside of that.
>
>> @@ -538,33 +534,33 @@ static void pv_cpuid(struct cpu_user_regs *regs)
>>xstate_sizes[_XSTATE_HI_ZMM]);
>>  }
>>  
>> -a = (uint32_t)xfeature_mask;
>> -d = (uint32_t)(xfeature_mask >> 32);
>> -c = xstate_size;
>> +res->a = (uint32_t)xfeature_mask;
>> +res->d = (uint32_t)(xfeature_mask >> 32);
>> +res->c = xstate_size;
> Please consider at once dropping these pointless casts (also on the
> HVM side then).

I can do, but after this patch, I only ever expect to delete code from
these functions as more leaves move over to the new infrastructure.

>
>> @@ -945,27 +927,7 @@ void guest_cpuid(const struct vcpu *v, unsigned int 
>> leaf,
>>   legacy:
>>  /* {pv,hvm}_cpuid() have this expectation. */
>>  ASSERT(v == curr);
>> -
>> -if ( is_pv_vcpu(v) || is_pvh_vcpu(v) )
>> -{
>> -struct cpu_user_regs regs = *guest_cpu_user_regs();
>> -
>> -regs.rax = leaf;
>> -regs.rcx = subleaf;
>> -
>> -pv_cpuid();
>> -
>> -res->a = regs._eax;
>> -res->b = regs._ebx;
>> -res->c = regs._ecx;
>> -res->d = regs._edx;
>> -}
>> -else
>> -{
>> -res->c = subleaf;
>> -
>> -hvm_cpuid(leaf, >a, >b, >c, >d);
>> -}
>> +(is_pv_vcpu(v) || is_pvh_vcpu(v) ? pv_cpuid : hvm_cpuid)(leaf, subleaf, 
>> res);
> Afaics as of patch 8 you have v->domain already latched into a
> local variable, so please use is_*_domain() here.

Actually, I will switch it around to is_hvm_domain() which is shorter,
and will require no modification when PVHv1 finally gets excised.

~Andrew

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

Re: [Xen-devel] [PATCH 00/11] Convert a few docs/misc pages into man pages

[Cedric Bosdonnat]

On Thu, 2017-01-05 at 15:01 +, Wei Liu wrote:
> On Wed, Jan 04, 2017 at 04:49:25PM +0100, Cedric Bosdonnat wrote:
> > On Wed, 2017-01-04 at 15:07 +, Wei Liu wrote:
> > > On Fri, Dec 09, 2016 at 05:17:03PM +0100, Cédric Bosdonnat wrote:
> > > > As pointed out in Ian and Andrew's emails on my recent docs improvement
> > > > attempt, getting the documents from docs/misc referenced in man pages
> > > > as man pages would would make these pages more visible for users. This
> > > > would also not break the docs html INDEX.
> > > > 
> > > > This series adds ability to write markdown man pages. Be aware that
> > > > markdown man pages can't link to other man pages.
> > > > 
> > > > I also added some pages to man 7 (Misc) section.
> > > > 
> > > 
> > > Do you have a git branch that I can pull from?
> > 
> > The docs branch on https://github.com/cbosdo/xen
> 
> I think I've gone through all of the patches. Please address Daniel's
> comments and resend this series.

They were already addressed in the repo I pointed you to.

--
Cedric

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

[Xen-devel] [PATCH v2] x86: drop cpu_has_sse{,2}

[Jan Beulich]

Commit dc88221c97 ("x86: rename XMM* features to SSE*") pointlessly
added them - these features are always available on 64-bit CPUs. (Let's
not assume this for MMX though in at least the insn emulator.)

Signed-off-by: Jan Beulich 
---
v2: Add a test harness comment clarifying host_and_vcpu_must_have() vs
vcpu_must_have() use there.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1326,6 +1326,11 @@ static bool vcpu_has(
 vcpu_must_have(feat); \
 })
 #else
+/*
+ * For the test harness both are fine to be used interchangeably, i.e.
+ * features known to always be available (e.g. SSE/SSE2) to (64-bit) Xen
+ * may be checked for by just vcpu_must_have().
+ */
 #define host_and_vcpu_must_have(feat) vcpu_must_have(feat)
 #endif
 
@@ -4910,9 +4915,9 @@ x86_emulate(
 if ( vex.opcx == vex_none )
 {
 if ( vex.pfx & VEX_PREFIX_DOUBLE_MASK )
-host_and_vcpu_must_have(sse2);
+vcpu_must_have(sse2);
 else
-host_and_vcpu_must_have(sse);
+vcpu_must_have(sse);
 ea.bytes = 16;
 SET_SSE_PREFIX(buf[0], vex.pfx);
 get_fpu(X86EMUL_FPU_xmm, );
@@ -5183,7 +5188,7 @@ x86_emulate(
 {
 case vex_66:
 case vex_f3:
-host_and_vcpu_must_have(sse2);
+vcpu_must_have(sse2);
 /* Converting movdqu to movdqa here: Our buffer is aligned. */
 buf[0] = 0x66;
 get_fpu(X86EMUL_FPU_xmm, );
@@ -5193,7 +5198,7 @@ x86_emulate(
 if ( b != 0xe7 )
 host_and_vcpu_must_have(mmx);
 else
-host_and_vcpu_must_have(sse);
+vcpu_must_have(sse);
 get_fpu(X86EMUL_FPU_mmx, );
 ea.bytes = 8;
 break;
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -38,8 +38,6 @@
 #define cpu_has_sepboot_cpu_has(X86_FEATURE_SEP)
 #define cpu_has_mtrr   1
 #define cpu_has_mmx1
-#define cpu_has_sseboot_cpu_has(X86_FEATURE_SSE)
-#define cpu_has_sse2   boot_cpu_has(X86_FEATURE_SSE2)
 #define cpu_has_sse3   boot_cpu_has(X86_FEATURE_SSE3)
 #define cpu_has_sse4_2 boot_cpu_has(X86_FEATURE_SSE4_2)
 #define cpu_has_httboot_cpu_has(X86_FEATURE_HTT)



x86: drop cpu_has_sse{,2}

Commit dc88221c97 ("x86: rename XMM* features to SSE*") pointlessly
added them - these features are always available on 64-bit CPUs. (Let's
not assume this for MMX though in at least the insn emulator.)

Signed-off-by: Jan Beulich 
---
v2: Add a test harness comment clarifying host_and_vcpu_must_have() vs
vcpu_must_have() use there.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1326,6 +1326,11 @@ static bool vcpu_has(
 vcpu_must_have(feat); \
 })
 #else
+/*
+ * For the test harness both are fine to be used interchangeably, i.e.
+ * features known to always be available (e.g. SSE/SSE2) to (64-bit) Xen
+ * may be checked for by just vcpu_must_have().
+ */
 #define host_and_vcpu_must_have(feat) vcpu_must_have(feat)
 #endif
 
@@ -4910,9 +4915,9 @@ x86_emulate(
 if ( vex.opcx == vex_none )
 {
 if ( vex.pfx & VEX_PREFIX_DOUBLE_MASK )
-host_and_vcpu_must_have(sse2);
+vcpu_must_have(sse2);
 else
-host_and_vcpu_must_have(sse);
+vcpu_must_have(sse);
 ea.bytes = 16;
 SET_SSE_PREFIX(buf[0], vex.pfx);
 get_fpu(X86EMUL_FPU_xmm, );
@@ -5183,7 +5188,7 @@ x86_emulate(
 {
 case vex_66:
 case vex_f3:
-host_and_vcpu_must_have(sse2);
+vcpu_must_have(sse2);
 /* Converting movdqu to movdqa here: Our buffer is aligned. */
 buf[0] = 0x66;
 get_fpu(X86EMUL_FPU_xmm, );
@@ -5193,7 +5198,7 @@ x86_emulate(
 if ( b != 0xe7 )
 host_and_vcpu_must_have(mmx);
 else
-host_and_vcpu_must_have(sse);
+vcpu_must_have(sse);
 get_fpu(X86EMUL_FPU_mmx, );
 ea.bytes = 8;
 break;
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -38,8 +38,6 @@
 #define cpu_has_sepboot_cpu_has(X86_FEATURE_SEP)
 #define cpu_has_mtrr   1
 #define cpu_has_mmx1
-#define cpu_has_sseboot_cpu_has(X86_FEATURE_SSE)
-#define cpu_has_sse2   boot_cpu_has(X86_FEATURE_SSE2)
 #define cpu_has_sse3   boot_cpu_has(X86_FEATURE_SSE3)
 #define cpu_has_sse4_2 boot_cpu_has(X86_FEATURE_SSE4_2)
 #define cpu_has_httboot_cpu_has(X86_FEATURE_HTT)

Re: [Xen-devel] [BUG] Xen-4.8.0 efi/buildid.o: file not recognized/Ambiguous

[Doug Goldstein]

On 12/22/16 8:46 AM, Jan Beulich wrote:
 On 07.12.16 at 16:57,  wrote:
>>  efi/buildid.o: file not recognized: File format is ambiguous
>>  efi/buildid.o: matching formats: coff-x86-64 pe-x86-64
> 
> Just fyi: After some analysis of the binutils sources I have come to
> the conclusion that this needs help from the binutils folks. I've just
> sent
> https://sourceware.org/ml/binutils/2016-12/msg00374.html
> to see if they have any advice.
> 

Has anything come of this? I'm not sure how we can use match_priority or
if they're saying they need to make changes to binutils. At this point
I'm not able to compile Xen myself without local hackery.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH 22/27] x86/cpuid: Perform max_leaf calculations in guest_cpuid()

[Andrew Cooper]

On 05/01/17 14:52, Jan Beulich wrote:
 On 05.01.17 at 15:28,  wrote:
>> On 05/01/17 13:51, Jan Beulich wrote:
 @@ -333,21 +340,50 @@ void guest_cpuid(const struct vcpu *v, unsigned int 
 leaf,
   unsigned int subleaf, struct cpuid_leaf *res)
  {
  const struct domain *d = v->domain;
 +const struct cpuid_policy *p = d->arch.cpuid;
  
  *res = EMPTY_LEAF;
  
  /*
   * First pass:
   * - Dispatch the virtualised leaves to their respective handlers.
 + * - Perform max_leaf/subleaf calculations, maybe returning early.
   */
  switch ( leaf )
  {
 +case 0x0 ... 0x6:
 +case 0x8 ... 0xc:
 +#if 0 /* For when CPUID_GUEST_NR_BASIC isn't 0xd */
 +case 0xe ... CPUID_GUEST_NR_BASIC - 1:
 +#endif
>>> Perhaps have a BUILD_BUG_ON() in an #else here?
>> The presence of this was to be a reminder to whomever tries upping
>> max_leaf beyond 0xd.  Then again, there is a reasonable chance it will
>> be me.
> Well, that's why the recommendation to add a BUILD_BUG_ON() -
> that's a reminder to that "whoever".

Ok.

>
 +if ( leaf > p->basic.max_leaf )
 +return;
 +break;
 +
 +case 0x7:
 +if ( subleaf > p->feat.max_subleaf )
 +return;
 +break;
 +
 +case 0xd:
>>> XSTATE_CPUID again,
>> I considered this, but having a mix of named an numbered leaves is worse
>> than having them uniformly numbered, especially when visually checking
>> the conditions around the #if 0 case above.
>>
>> I had considered making a cpuid-index.h for leaf names, but most leaves
>> are more commonly referred to by number than name, so I am really not
>> sure if that would be helpful or hindering in the long run.
>>
>>> which raises the question whether switch() really is the best way to deal 
>> with things here.
>>
>> What else would you suggest?  One way or another (better shown in the
>> context of the following patch), we need one block per union{} to apply
>> max_leaf calculations and read the base data from p->$FOO.raw[$IDX].
> Actually, perhaps a mixture: Inside the default case have
>
> if ( leaf == 0x7 )
> {
> if ( subleaf > p->feat.max_subleaf )
> return;
> }
> else if ( leaf == 0xd)
> {
> if ( subleaf > ARRAY_SIZE(p->xstate.raw) )
> return;
> }
> if ( leaf > p->basic.max_leaf )
> return;
>
> Which (by making the last one if rather than else-if) also fixes an
> issue I've spotted only now: So far you exclude leaves 7 and 0xd
> from the basic.max_leaf checking. (And this way that check could
> also go first.)

Very good point, although I still think I'd still prefer a logic block
in this form inside a case 0 ... 0x3fff to avoid potential leakage
if other logic changes.

~Andrew

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

Re: [Xen-devel] [PATCH 00/11] Convert a few docs/misc pages into man pages

[Wei Liu]

On Wed, Jan 04, 2017 at 04:49:25PM +0100, Cedric Bosdonnat wrote:
> On Wed, 2017-01-04 at 15:07 +, Wei Liu wrote:
> > On Fri, Dec 09, 2016 at 05:17:03PM +0100, Cédric Bosdonnat wrote:
> > > As pointed out in Ian and Andrew's emails on my recent docs improvement
> > > attempt, getting the documents from docs/misc referenced in man pages
> > > as man pages would would make these pages more visible for users. This
> > > would also not break the docs html INDEX.
> > > 
> > > This series adds ability to write markdown man pages. Be aware that
> > > markdown man pages can't link to other man pages.
> > > 
> > > I also added some pages to man 7 (Misc) section.
> > > 
> > 
> > Do you have a git branch that I can pull from?
> 
> The docs branch on https://github.com/cbosdo/xen

I think I've gone through all of the patches. Please address Daniel's
comments and resend this series.

Wei.

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

Re: [Xen-devel] [PATCH 22/27] x86/cpuid: Perform max_leaf calculations in guest_cpuid()

[Jan Beulich]

>>> On 05.01.17 at 15:28,  wrote:
> On 05/01/17 13:51, Jan Beulich wrote:
>>> @@ -333,21 +340,50 @@ void guest_cpuid(const struct vcpu *v, unsigned int 
>>> leaf,
>>>   unsigned int subleaf, struct cpuid_leaf *res)
>>>  {
>>>  const struct domain *d = v->domain;
>>> +const struct cpuid_policy *p = d->arch.cpuid;
>>>  
>>>  *res = EMPTY_LEAF;
>>>  
>>>  /*
>>>   * First pass:
>>>   * - Dispatch the virtualised leaves to their respective handlers.
>>> + * - Perform max_leaf/subleaf calculations, maybe returning early.
>>>   */
>>>  switch ( leaf )
>>>  {
>>> +case 0x0 ... 0x6:
>>> +case 0x8 ... 0xc:
>>> +#if 0 /* For when CPUID_GUEST_NR_BASIC isn't 0xd */
>>> +case 0xe ... CPUID_GUEST_NR_BASIC - 1:
>>> +#endif
>> Perhaps have a BUILD_BUG_ON() in an #else here?
> 
> The presence of this was to be a reminder to whomever tries upping
> max_leaf beyond 0xd.  Then again, there is a reasonable chance it will
> be me.

Well, that's why the recommendation to add a BUILD_BUG_ON() -
that's a reminder to that "whoever".

>>> +if ( leaf > p->basic.max_leaf )
>>> +return;
>>> +break;
>>> +
>>> +case 0x7:
>>> +if ( subleaf > p->feat.max_subleaf )
>>> +return;
>>> +break;
>>> +
>>> +case 0xd:
>> XSTATE_CPUID again,
> 
> I considered this, but having a mix of named an numbered leaves is worse
> than having them uniformly numbered, especially when visually checking
> the conditions around the #if 0 case above.
> 
> I had considered making a cpuid-index.h for leaf names, but most leaves
> are more commonly referred to by number than name, so I am really not
> sure if that would be helpful or hindering in the long run.
> 
>> which raises the question whether switch() really is the best way to deal 
> with things here.
> 
> What else would you suggest?  One way or another (better shown in the
> context of the following patch), we need one block per union{} to apply
> max_leaf calculations and read the base data from p->$FOO.raw[$IDX].

Actually, perhaps a mixture: Inside the default case have

if ( leaf == 0x7 )
{
if ( subleaf > p->feat.max_subleaf )
return;
}
else if ( leaf == 0xd)
{
if ( subleaf > ARRAY_SIZE(p->xstate.raw) )
return;
}
if ( leaf > p->basic.max_leaf )
return;

Which (by making the last one if rather than else-if) also fixes an
issue I've spotted only now: So far you exclude leaves 7 and 0xd
from the basic.max_leaf checking. (And this way that check could
also go first.)

>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -3305,27 +3305,6 @@ void hvm_cpuid(unsigned int input, unsigned int 
>>> *eax, unsigned int *ebx,
>>>  if ( !edx )
>>>  edx = 
>>>  
>>> -if ( input & 0x7fff )
>>> -{
>>> -/*
>>> - * Requests outside the supported leaf ranges return zero on AMD
>>> - * and the highest basic leaf output on Intel. Uniformly follow
>>> - * the AMD model as the more sane one.
>>> - */
>> I think this comment would better be moved instead of deleted.
> 
> Where would you like it?  It doesn't have an easy logical place to live
> in guest_cpuid().  The best I can think of is probably as an extension
> of the "First Pass" comment.

Right there, yes, as an extension to the line you're already adding.

Jan


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

Re: [Xen-devel] [PATCH 10/27] x86/cpuid: Introduce named feature bitmaps

[Jan Beulich]

>>> On 05.01.17 at 15:53,  wrote:
> On 05/01/17 08:27, Jan Beulich wrote:
> On 04.01.17 at 18:21,  wrote:
>>> On 04/01/17 15:44, Jan Beulich wrote:
>>> On 04.01.17 at 13:39,  wrote:
> Use anonymous unions to access the feature leaves as complete words, and 
> by
> named individual feature.
>
> A feature name is introduced for every architectural X86_FEATURE_*, other 
> than
> the dynamically calculated values such as APIC, OSXSAVE and OSPKE.
 A rationale for this change would be nice to have here, as the
 redundancy with public/arch-x86/cpufeatureset.h means any
 addition will now need to change two places. Would it be possible
 for gen-cpuid.py to generate these bitfield declarations?
>>> Hmm.  I hadn't considered that as an option.
>>>
>>> Thinking about it however, I'd ideally prefer not to hide the
>>> declarations behind a macro.
>> What's wrong with that?
> 
> My specific dislike of hiding code from tools like grep and cscope.
> 
>> It's surely better than having to keep two pieces of code in sync manually.
> 
> True, but that doesn't come with zero cost.
> 
> Thinking about it, the spanner in the works for easily generating this
> in an automatic way is MAWAU in leaf 7, which is the first non-bit thing
> in the feature leaves.

That's a case needing something new anyway, as you can't even
express it using XEN_CPUFEATURE().

Jan


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

Re: [Xen-devel] [PATCH 11/27] x86/hvm: Improve hvm_efer_valid() using named features

[Andrew Cooper]

On 05/01/17 11:34, Jan Beulich wrote:
 On 04.01.17 at 13:39,  wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -914,56 +914,35 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
>> hvm_domain_context_t *h)
>>  }
>>  
>>  /* Return a string indicating the error, or NULL for valid. */
>> -const char *hvm_efer_valid(const struct vcpu *v, uint64_t value,
>> -   signed int cr0_pg)
>> +const char *hvm_efer_valid(const struct vcpu *v, uint64_t value, int cr0_pg)
> Please can we keep the "signed" here, to make clear signedness
> indeed matters (as opposed to various other uses of plain int we
> still have which could equally well be unsigned int)?

Ok.

>
> Other than that
> Reviewed-by: Jan Beulich 
> albeit I have one more question:
>
>>  if ( (value & EFER_LMSLE) && !cpu_has_lmsl )
>>  return "LMSLE without support";
> Do you have any plans to include such non-CPUID-based features
> into the policy?

That is on my TODO list, because one way or another, I will need it when
doing the migration improvements.

One way or another I think we are going to have to non-architectural
information in our architectural representation of the policy.

~Andrew

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

Re: [Xen-devel] [PATCH 07/27] x86/cpuid: Recalculate a domains CPUID policy when appropriate

[Jan Beulich]

>>> On 05.01.17 at 15:42,  wrote:
> On 05/01/17 08:24, Jan Beulich wrote:
> On 04.01.17 at 18:37,  wrote:
>>> On 04/01/17 16:04, Jan Beulich wrote:
>>> On 04.01.17 at 16:33,  wrote:
> On 04/01/17 15:01, Jan Beulich wrote:
> On 04.01.17 at 13:39,  wrote:
>>>  static void update_domain_cpuid_info(struct domain *d,
>>>   const xen_domctl_cpuid_t *ctl)
>>>  {
>>> +struct cpuid_policy *p = d->arch.cpuid;
>>> +struct cpuid_leaf leaf = { ctl->eax, ctl->ebx, ctl->ecx, ctl->edx 
>>> };
>>> +
>>> +if ( ctl->input[0] < ARRAY_SIZE(p->basic.raw) )
>>> +{
>>> +if ( ctl->input[0] == 7 )
>>> +{
>>> +if ( ctl->input[1] < ARRAY_SIZE(p->feat.raw) )
>>> +p->feat.raw[ctl->input[1]] = leaf;
>>> +}
>>> +else if ( ctl->input[0] == 0xd )
>>> +{
>>> +if ( ctl->input[1] < ARRAY_SIZE(p->xstate.raw) )
>>> +p->xstate.raw[ctl->input[1]] = leaf;
>>> +}
>>> +else
>>> +p->basic.raw[ctl->input[0]] = leaf;
>>> +}
>>> +else if ( (ctl->input[0] - 0x8000) < ARRAY_SIZE(p->extd.raw) )
>>> +p->extd.raw[ctl->input[0] - 0x8000] = leaf;
>> These checks against ARRAY_SIZE() worry me - wouldn't we better
>> refuse any attempts to set values not representable in the policy?
> We can't do that yet, without toolstack side changes.  Currently the
> toolstack can lodge any values it wishes, and all we do is ignore them,
> which can be arbitrary information from a cpuid= clause.
 Hmm, do we really _ignore_ them in all cases (rather than handing
 them through to guests)? If so, that should indeed be good enough
 for now.
>>> Any arbitrary values get can get inserted into the cpuids[] array but,
>>> given your fairly-recent change to check max_leaf, we don't guarantee to
>>> hand the values to a guest.
>> "we don't guarantee" != "we guarantee not to"
>>
>> But my main point here is that a domain's cpuid= may specify a
>> higher than default max leaf, and I think going forward we ought
>> to still return all zero for those leaves in that case, or else the
>> overall spirit of white listing would get violated.
> 
> Does this concern still stand in light of max_leaf handling in patches
> 21 and 22?

Indeed, now that I've seen the full series, this should be fine.

Jan


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

Re: [Xen-devel] [PATCH 23/27] x86/cpuid: Move all leaf 7 handling into guest_cpuid()

[Jan Beulich]

>>> On 05.01.17 at 15:39,  wrote:
> On 05/01/17 14:01, Jan Beulich wrote:
> On 04.01.17 at 13:39,  wrote:
>>> @@ -380,14 +385,42 @@ void guest_cpuid(const struct vcpu *v, unsigned int 
> leaf,
>>>  case 0x8000 ... 0x8000 + CPUID_GUEST_NR_EXTD - 1:
>>>  if ( leaf > p->extd.max_leaf )
>>>  return;
>>> -break;
>>> +goto legacy;
>>>  
>>>  default:
>>>  return;
>>>  }
>>>  
>>> +/* Skip dynamic adjustments if we are in the wrong context. */
>>> +if ( v != curr )
>>> +return;
>>> +
>>> +/*
>>> + * Second pass:
>>> + * - Dynamic adjustments
>>> + */
>>> +switch ( leaf )
>>> +{
>>> +case 0x7:
>>> +switch ( subleaf )
>>> +{
>>> +case 0:
>>> +/* OSPKE clear in policy.  Fast-forward CR4 back in. */
>>> +if ( (is_pv_vcpu(v)
>>> +  ? v->arch.pv_vcpu.ctrlreg[4]
>>> +  : v->arch.hvm_vcpu.guest_cr[4]) & X86_CR4_PKE )
>>> +res->c |= cpufeat_mask(X86_FEATURE_OSPKE);
>> What's wrong with doing this adjustment when v != curr?
> 
> A guests %cr4 is stale if it is running elsewhere.
> 
>> By the time the caller looks at the result, the state of guest
>> software controlled bits can't be relied upon anyway.
> 
> This particular adjustment can be done out of curr context, but others
> are harder.  I have taken the approach that it is better to do nothing
> consistently, than to expend effort filling in data we know is going to
> be wrong for the caller.

May I then suggest to add the early bailing at the time it actually
becomes necessary, or at the very least extend its comment to
make clear that this isn't always strictly needed?

Jan


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

Re: [Xen-devel] [PATCH 10/27] x86/cpuid: Introduce named feature bitmaps

[Andrew Cooper]

On 05/01/17 08:27, Jan Beulich wrote:
 On 04.01.17 at 18:21,  wrote:
>> On 04/01/17 15:44, Jan Beulich wrote:
>> On 04.01.17 at 13:39,  wrote:
 Use anonymous unions to access the feature leaves as complete words, and by
 named individual feature.

 A feature name is introduced for every architectural X86_FEATURE_*, other 
 than
 the dynamically calculated values such as APIC, OSXSAVE and OSPKE.
>>> A rationale for this change would be nice to have here, as the
>>> redundancy with public/arch-x86/cpufeatureset.h means any
>>> addition will now need to change two places. Would it be possible
>>> for gen-cpuid.py to generate these bitfield declarations?
>> Hmm.  I hadn't considered that as an option.
>>
>> Thinking about it however, I'd ideally prefer not to hide the
>> declarations behind a macro.
> What's wrong with that?

My specific dislike of hiding code from tools like grep and cscope.

> It's surely better than having to keep two pieces of code in sync manually.

True, but that doesn't come with zero cost.

Thinking about it, the spanner in the works for easily generating this
in an automatic way is MAWAU in leaf 7, which is the first non-bit thing
in the feature leaves.

 +};
 +};
 +union {
 +uint32_t _7c0;
 +struct {
 +bool prefetchwt1:1, avx512vbmi:1, :1, pku: 1, :1, 
 :1, :1, :1,
 + :1, :1, :1, :1, :1, :1, :1, :1,
 + :1, :1, :1, :1, :1, :1, :1, :1,
 + :1, :1, :1, :1, :1, :1, :1, :1;
>>> This is ugly, but I remember you saying (on irc?) the compiler
>>> doesn't allow bitfields wider than one bit for bool ...
>> Correct.  I was quite surprised by this, but I can understand that bool
>> foo:2 is quite meaningless when foo can strictly only take a binary value.
> Thinking about it another time - what's wrong with using uint32_t
> instead of bool here, allowing consecutive unknown fields to be
> folded?

I first tried using uint32_t and had many problems counting bits
(although this less of an issue if it was automatically generated).

I also wanted to maintain bool properties, but now I think back, I don't
forsee any situation where we would make an assignment to one of these
named features.

~Andrew

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

Re: [Xen-devel] Ping: [PATCH v2 RESEND] x86/time: correctly honor late clearing of TSC related feature flags

[Jan Beulich]

>>> On 20.12.16 at 13:35,  wrote:
> Once we have ever had cause to use time_calibration_tsc_rendezvous,
> there is no situation where it is safe to switch back to
> time_calibration_std_rendezvous, as the choice to use
> time_calibration_tsc_rendezvous means the TSCs aren't in sync, and Xen
> has no practical mechanism to resync them.  (We could guarantee not to
> ever invoke Cstates, including C1E, but this doesn't prevent an SMI
> doing that for us.)

Okay, I think I'm finally following you. Yet ...

> time_calibration_rendezvous_fn should start with the best case scenario,
> and be gradually made worse by our AP discovery, but should never get
> better.

... that's already the case with the patch: CONSTANT_TSC can only
be cleared by command line option (i.e. before any of this code runs)
or in tsc_check_writability() (which runs before clear_tsc_cap() gets
invoked first). Hence the possibility of switching back from tsc to std
depends solely on TSC_RELIABLE potentially getting set during/after
AP bringup. Yet that never happens, we only ever clear that flag
(which is part of the purpose of clear_tsc_cap()).

Bottom line - I don't see how you think we may end up switching back
from tsc to std. Perhaps it is then all just a matter of changing a few
names and/or adding a BUG_ON() or panic() to make things more clear
to you and possible other readers?

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  e5ca20e0f6212dffaba2d3a0b966b71d9ab1ea91
baseline version:
 xen  718dcb95277caf39c3ab946be7352bac9acc5792

Last test of basis   104042  2017-01-05 11:01:05 Z0 days
Testing same since   104046  2017-01-05 13:01:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Kevin Tian 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH 07/27] x86/cpuid: Recalculate a domains CPUID policy when appropriate

[Andrew Cooper]

On 05/01/17 08:24, Jan Beulich wrote:
 On 04.01.17 at 18:37,  wrote:
>> On 04/01/17 16:04, Jan Beulich wrote:
>> On 04.01.17 at 16:33,  wrote:
 On 04/01/17 15:01, Jan Beulich wrote:
 On 04.01.17 at 13:39,  wrote:
>> +/* ... but hide ITSC in the common case. */
>> +if ( !d->disable_migrate && !d->arch.vtsc )
>> +__clear_bit(X86_FEATURE_ITSC, fs);
> The 32-bit PV logic could easily move below here afaics, reducing
> the distance between the two parts of the comment.
>
> Also this requires adjustment of the policy by (the caller of)
> tsc_set_info().
 And also XEN_DOMCTL_set_disable_migrate.

 Currently the various toolstacks issues these hypercalls in the correct
 order, so I was planning to ignore these edge cases until the toolstack
 side work (see below).
>>> Let's not do that - it'll be some time until that other work lands,
>>> I assume, and introducing (further) dependencies on tool stacks
>>> to do things in the right order is quite bad imo.
>> This is code which hasn't changed in years.  But if you insist, then I
>> will see about best to do an x86-only change to the common code.
> The tsc_set_info() would likely be in x86 specific code, but the
> set_disable_migrate would, as you say, presumably want handling
> in/from common code. So unless this would turn out to be a rather
> costly change, I'd indeed prefer if you adjusted these.
>
>>  static void update_domain_cpuid_info(struct domain *d,
>>   const xen_domctl_cpuid_t *ctl)
>>  {
>> +struct cpuid_policy *p = d->arch.cpuid;
>> +struct cpuid_leaf leaf = { ctl->eax, ctl->ebx, ctl->ecx, ctl->edx };
>> +
>> +if ( ctl->input[0] < ARRAY_SIZE(p->basic.raw) )
>> +{
>> +if ( ctl->input[0] == 7 )
>> +{
>> +if ( ctl->input[1] < ARRAY_SIZE(p->feat.raw) )
>> +p->feat.raw[ctl->input[1]] = leaf;
>> +}
>> +else if ( ctl->input[0] == 0xd )
>> +{
>> +if ( ctl->input[1] < ARRAY_SIZE(p->xstate.raw) )
>> +p->xstate.raw[ctl->input[1]] = leaf;
>> +}
>> +else
>> +p->basic.raw[ctl->input[0]] = leaf;
>> +}
>> +else if ( (ctl->input[0] - 0x8000) < ARRAY_SIZE(p->extd.raw) )
>> +p->extd.raw[ctl->input[0] - 0x8000] = leaf;
> These checks against ARRAY_SIZE() worry me - wouldn't we better
> refuse any attempts to set values not representable in the policy?
 We can't do that yet, without toolstack side changes.  Currently the
 toolstack can lodge any values it wishes, and all we do is ignore them,
 which can be arbitrary information from a cpuid= clause.
>>> Hmm, do we really _ignore_ them in all cases (rather than handing
>>> them through to guests)? If so, that should indeed be good enough
>>> for now.
>> Any arbitrary values get can get inserted into the cpuids[] array but,
>> given your fairly-recent change to check max_leaf, we don't guarantee to
>> hand the values to a guest.
> "we don't guarantee" != "we guarantee not to"
>
> But my main point here is that a domain's cpuid= may specify a
> higher than default max leaf, and I think going forward we ought
> to still return all zero for those leaves in that case, or else the
> overall spirit of white listing would get violated.

Does this concern still stand in light of max_leaf handling in patches
21 and 22?

~Andrew

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

Re: [Xen-devel] [PATCH 23/27] x86/cpuid: Move all leaf 7 handling into guest_cpuid()

[Andrew Cooper]

On 05/01/17 14:01, Jan Beulich wrote:
 On 04.01.17 at 13:39,  wrote:
>> @@ -380,14 +385,42 @@ void guest_cpuid(const struct vcpu *v, unsigned int 
>> leaf,
>>  case 0x8000 ... 0x8000 + CPUID_GUEST_NR_EXTD - 1:
>>  if ( leaf > p->extd.max_leaf )
>>  return;
>> -break;
>> +goto legacy;
>>  
>>  default:
>>  return;
>>  }
>>  
>> +/* Skip dynamic adjustments if we are in the wrong context. */
>> +if ( v != curr )
>> +return;
>> +
>> +/*
>> + * Second pass:
>> + * - Dynamic adjustments
>> + */
>> +switch ( leaf )
>> +{
>> +case 0x7:
>> +switch ( subleaf )
>> +{
>> +case 0:
>> +/* OSPKE clear in policy.  Fast-forward CR4 back in. */
>> +if ( (is_pv_vcpu(v)
>> +  ? v->arch.pv_vcpu.ctrlreg[4]
>> +  : v->arch.hvm_vcpu.guest_cr[4]) & X86_CR4_PKE )
>> +res->c |= cpufeat_mask(X86_FEATURE_OSPKE);
> What's wrong with doing this adjustment when v != curr?

A guests %cr4 is stale if it is running elsewhere.

> By the time the caller looks at the result, the state of guest
> software controlled bits can't be relied upon anyway.

This particular adjustment can be done out of curr context, but others
are harder.  I have taken the approach that it is better to do nothing
consistently, than to expend effort filling in data we know is going to
be wrong for the caller.

(I hit a rats nest with the xstate leaf and dynamic %ebx's, which is why
those patches are still pending some more work, and I haven't yet
decided how to do the pv hardware domain leakage.)

> Which then raises the question whether a second switch() statement
> for the a second pass is all that useful in the first place (I
> realize this may depend on future plans of yours).

This switch statement will soon be far larger and more complicated than
the first-pass one, and I think it is important to separate the static
and dynamic nature of the two.

~Andrew

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

Re: [Xen-devel] [PATCH 21/27] x86/cpuid: Calculate appropriate max_leaf values for the global policies

[Jan Beulich]

>>> On 05.01.17 at 15:13,  wrote:
> On 05/01/17 13:43, Jan Beulich wrote:
> On 04.01.17 at 13:39,  wrote:
>>> --- a/xen/include/asm-x86/cpuid.h
>>> +++ b/xen/include/asm-x86/cpuid.h
>>> @@ -78,10 +78,10 @@ struct cpuid_policy
>>>   * Global *_policy objects:
>>>   *
>>>   * - Host accurate:
>>> - *   - max_{,sub}leaf
>>>   *   - {xcr0,xss}_{high,low}
>>>   *
>>>   * - Guest appropriate:
>>> + *   - max_{,sub}leaf
>>>   *   - All FEATURESET_* words
>> I can see the point of the addition, but why the removal?
> 
> Because the max_{,sub}leaf fields are no longer host-accurate.  They are
> min(host, tolerated policy).

Oh, I see.

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 22/27] x86/cpuid: Perform max_leaf calculations in guest_cpuid()

[Andrew Cooper]

On 05/01/17 13:51, Jan Beulich wrote:
>
>> @@ -333,21 +340,50 @@ void guest_cpuid(const struct vcpu *v, unsigned int 
>> leaf,
>>   unsigned int subleaf, struct cpuid_leaf *res)
>>  {
>>  const struct domain *d = v->domain;
>> +const struct cpuid_policy *p = d->arch.cpuid;
>>  
>>  *res = EMPTY_LEAF;
>>  
>>  /*
>>   * First pass:
>>   * - Dispatch the virtualised leaves to their respective handlers.
>> + * - Perform max_leaf/subleaf calculations, maybe returning early.
>>   */
>>  switch ( leaf )
>>  {
>> +case 0x0 ... 0x6:
>> +case 0x8 ... 0xc:
>> +#if 0 /* For when CPUID_GUEST_NR_BASIC isn't 0xd */
>> +case 0xe ... CPUID_GUEST_NR_BASIC - 1:
>> +#endif
> Perhaps have a BUILD_BUG_ON() in an #else here?

The presence of this was to be a reminder to whomever tries upping
max_leaf beyond 0xd.  Then again, there is a reasonable chance it will
be me.

I am half tempted to leave it out.

>
>> +if ( leaf > p->basic.max_leaf )
>> +return;
>> +break;
>> +
>> +case 0x7:
>> +if ( subleaf > p->feat.max_subleaf )
>> +return;
>> +break;
>> +
>> +case 0xd:
> XSTATE_CPUID again,

I considered this, but having a mix of named an numbered leaves is worse
than having them uniformly numbered, especially when visually checking
the conditions around the #if 0 case above.

I had considered making a cpuid-index.h for leaf names, but most leaves
are more commonly referred to by number than name, so I am really not
sure if that would be helpful or hindering in the long run.

> which raises the question whether switch() really is the best way to deal 
> with things here.

What else would you suggest?  One way or another (better shown in the
context of the following patch), we need one block per union{} to apply
max_leaf calculations and read the base data from p->$FOO.raw[$IDX].

>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3305,27 +3305,6 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
>> unsigned int *ebx,
>>  if ( !edx )
>>  edx = 
>>  
>> -if ( input & 0x7fff )
>> -{
>> -/*
>> - * Requests outside the supported leaf ranges return zero on AMD
>> - * and the highest basic leaf output on Intel. Uniformly follow
>> - * the AMD model as the more sane one.
>> - */
> I think this comment would better be moved instead of deleted.

Where would you like it?  It doesn't have an easy logical place to live
in guest_cpuid().  The best I can think of is probably as an extension
of the "First Pass" comment.

~Andrew

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

Re: [Xen-devel] [PATCH 27/27] x86/cpuid: Alter the legacy-path prototypes to match guest_cpuid()

[Jan Beulich]

>>> On 04.01.17 at 13:39,  wrote:
> Here and elsewhere, it is becomes very obvious that the PVH path using
> pv_cpuid() is broken, as the guest_kernel_mode() check using
> guest_cpu_user_regs() is erroneous.  I am tempted to just switch PVH onto the
> HVM path, which won't make it any more broken than it currently is.

Are you sure? There was a reason it had been done this way back then.

> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -337,30 +337,26 @@ int init_domain_cpuid_policy(struct domain *d)
>  return 0;
>  }
>  
> -static void pv_cpuid(struct cpu_user_regs *regs)
> +static void pv_cpuid(unsigned int leaf, unsigned int subleaf,
> + struct cpuid_leaf *res)
>  {
> -uint32_t leaf, subleaf, a, b, c, d;
> +const struct cpu_user_regs *regs = guest_cpu_user_regs();

Please consider moving this into the !is_pvh_domain() scope,
open coding the one access outside of that.

> @@ -538,33 +534,33 @@ static void pv_cpuid(struct cpu_user_regs *regs)
>xstate_sizes[_XSTATE_HI_ZMM]);
>  }
>  
> -a = (uint32_t)xfeature_mask;
> -d = (uint32_t)(xfeature_mask >> 32);
> -c = xstate_size;
> +res->a = (uint32_t)xfeature_mask;
> +res->d = (uint32_t)(xfeature_mask >> 32);
> +res->c = xstate_size;

Please consider at once dropping these pointless casts (also on the
HVM side then).

> @@ -945,27 +927,7 @@ void guest_cpuid(const struct vcpu *v, unsigned int leaf,
>   legacy:
>  /* {pv,hvm}_cpuid() have this expectation. */
>  ASSERT(v == curr);
> -
> -if ( is_pv_vcpu(v) || is_pvh_vcpu(v) )
> -{
> -struct cpu_user_regs regs = *guest_cpu_user_regs();
> -
> -regs.rax = leaf;
> -regs.rcx = subleaf;
> -
> -pv_cpuid();
> -
> -res->a = regs._eax;
> -res->b = regs._ebx;
> -res->c = regs._ecx;
> -res->d = regs._edx;
> -}
> -else
> -{
> -res->c = subleaf;
> -
> -hvm_cpuid(leaf, >a, >b, >c, >d);
> -}
> +(is_pv_vcpu(v) || is_pvh_vcpu(v) ? pv_cpuid : hvm_cpuid)(leaf, subleaf, 
> res);

Afaics as of patch 8 you have v->domain already latched into a
local variable, so please use is_*_domain() here.

In any event
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH] x86/head: Refactor 32-bit pgtable setup

[Boris Ostrovsky]

On 01/05/2017 03:52 AM, Ingo Molnar wrote:
>
> Yeah, so (belatedly) I tried to merge this to latest upstream, via the commit 
> below (note the slight edits to the changelog) - but 32-bit defconfig fails 
> to 
> build:
>
>   arch/x86/kernel/head_32.S:615: Error: can't resolve `init_thread_union' 
> {*UND* section} - `SIZEOF_PTREGS' {*UND* section}

When you dropped MAPPING_BEYOND_END (that I indeed should have removed)
you left comment opening in the wrong place:

> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
> index 4e8577d03372..eca1c93c38e8 100644
> --- a/arch/x86/kernel/head_32.S
> +++ b/arch/x86/kernel/head_32.S
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* Physical address */
>  #define pa(X) ((X) - __PAGE_OFFSET)
> @@ -42,43 +43,8 @@
>  #define X86_VENDOR_IDnew_cpu_data+CPUINFO_x86_vendor_id

This one:

>  
>  /*
> - * This is how much memory in addition to the memory covered up to
> - * and including _end we need mapped initially.
> - * We need:
> - * (KERNEL_IMAGE_SIZE/4096) / 1024 pages (worst case, non PAE)
> - * (KERNEL_IMAGE_SIZE/4096) / 512 + 4 pages (worst case for PAE)
> - *
> - * Modulo rounding, each megabyte assigned here requires a kilobyte of
> - * memory, which is currently unreclaimed.
> - *
> - * This should be a multiple of a page.
> - *
> - * KERNEL_IMAGE_SIZE should be greater than pa(_end)
> - * and small than max_low_pfn, otherwise will waste some page table entries
> - */
> -
> -#if PTRS_PER_PMD > 1
> -#define PAGE_TABLE_SIZE(pages) (((pages) / PTRS_PER_PMD) + PTRS_PER_PGD)
> -#else
> -#define PAGE_TABLE_SIZE(pages) ((pages) / PTRS_PER_PGD)
> -#endif
> -
>  #define SIZEOF_PTREGS 17*4
>  



In other words, this version of the patch needs:

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index eca1c93..1f85ee8 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -42,9 +42,10 @@
 #define X86_CAPABILITY new_cpu_data+CPUINFO_x86_capability
 #define X86_VENDOR_ID  new_cpu_data+CPUINFO_x86_vendor_id
 
-/*
+
 #define SIZEOF_PTREGS 17*4
 
+/*
  * Worst-case size of the kernel mapping we need to make:
  * a relocatable kernel can live anywhere in lowmem, so we need to be able
  * to map all of lowmem.



-boris


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

Re: [Xen-devel] PROBLEM: Kernel BUG with raid5 soft + Xen + DRBD - invalid opcode

[MasterPrenium]

Hi Shaohua,

Thanks for your reply.

Let me explain my "huge". For example, if I'm making a low rate i/o 
stream, I don't get a crash (<1MB written / sec) with random i/o, but if 
I'm making a random I/O of about 20MB/sec, the kernel crashes in a few 
minutes (for example, making an rsync, or even synchronising my DRBD 
stack is causing the crash).
I don't know if this can help, but in most of case, when the kernel 
crashes, after a reboot, my raid 5 stack is re-synchronizing.


I'm not able to reproduce the crash with a raw RAID5 stack (with dd/fio 
...).


It seems I need to stack filesystems to help reproduce it:

Here is a configuration test, command lines to explain (the way I'm able 
to reproduce the crash). Everything is done in dom0.
- mdadm --create /dev/md10 --raid-devices=3 --level=5 /dev/sdc1 
/dev/sdd1 /dev/sde1

- mkfs.btrfs /dev/md10
- mkdir /tmp/btrfs /mnt/XenVM /tmp/ext4
- mount /dev/md10 /tmp/btrfs
- btrfs subvolume create /tmp/btrfs/XenVM
- umount /tmp/btrfs
- mount /dev/md10 /mnt/XenVM -osubvol=XenVM
- truncate /mnt/XenVM/VMTestFile.dat -s 800G
- mkfs.ext4 /mnt/XenVM/VMTestFile.dat
- mount /mnt/XenVM/VMTestFile.dat /tmp/ext4

-> Doing this, doesn't seem to crash the kernel :
fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite 
--rwmixwrite=95 --bs=1M --direct=1 --size=80G --numjobs=8 --runtime=600 
--group_reporting --filename=/mnt/XenVM/Fio.dat


-> Doing this, is crashing the kernel in a few minutes :
fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite 
--rwmixwrite=95 --bs=1M --direct=1 --size=80G --numjobs=8 --runtime=600 
--group_reporting --filename=/tmp/ext4/ext4.dat


Note : --direct=1 or --direct=0 doesn't seem to change the behaviour. 
Also having the raid 5 stack re-synchronizing or already synchronized, 
doesn't change the behaviour.


Here another "crash" : http://pastebin.com/uqLzL4fn

Regarding your patch, I can't find it. Is it the one sent by Konstantin 
Khlebnikov ?


Do you want the "ext4.dat" fio file ? It will be really difficult for me 
to provide it to you as I've only a poor ADSL network connection.


Thanks for your help,

MasterPrenium

Le 04/01/2017 à 23:30, Shaohua Li a écrit :

On Fri, Dec 23, 2016 at 07:25:56PM +0100, MasterPrenium wrote:

Hello Guys,

I've having some trouble on a new system I'm setting up. I'm getting a kernel 
BUG message, seems to be related with the use of Xen (when I boot the system 
_without_ Xen, I don't get any crash).
Here is configuration :
- 3x Hard Drives running on RAID 5 Software raid created by mdadm
- On top of it, DRBD for replication over another node (Active/passive cluster)
- On top of it, a BTRFS FileSystem with a few subvolumes
- On top of it, XEN VMs running.

The BUG is happening when I'm making "huge" I/O (20MB/s with a rsync for 
example) on the RAID5 stack.
I've to reset system to make it work again.

what did you mean 'huge' I/O (20M/s)? Is it possible you can reproduce the
issue with a raw raid5 raid? It would be even better if you can give me a fio
job file with the issue, so I can easily debug it.

also please check if upstream patch (e8d7c33 md/raid5: limit request size
according to implementation limits) helps.

Thanks,
Shaohua



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

Re: [Xen-devel] [PATCH 21/27] x86/cpuid: Calculate appropriate max_leaf values for the global policies

[Andrew Cooper]

On 05/01/17 13:43, Jan Beulich wrote:
 On 04.01.17 at 13:39,  wrote:
>> --- a/xen/include/asm-x86/cpuid.h
>> +++ b/xen/include/asm-x86/cpuid.h
>> @@ -78,10 +78,10 @@ struct cpuid_policy
>>   * Global *_policy objects:
>>   *
>>   * - Host accurate:
>> - *   - max_{,sub}leaf
>>   *   - {xcr0,xss}_{high,low}
>>   *
>>   * - Guest appropriate:
>> + *   - max_{,sub}leaf
>>   *   - All FEATURESET_* words
> I can see the point of the addition, but why the removal?

Because the max_{,sub}leaf fields are no longer host-accurate.  They are
min(host, tolerated policy).

~Andrew

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

Re: [Xen-devel] [PATCH 26/27] x86/cpuid: Effectively remove pv_cpuid() and hvm_cpuid()

[Andrew Cooper]

On 05/01/17 14:06, Jan Beulich wrote:
 On 04.01.17 at 13:39,  wrote:
>> All callers of pv_cpuid() and hvm_cpuid() (other than guest_cpuid() legacy
>> path) have been removed from the codebase.  Move them into cpuid.c to avoid
>> any further use, leaving guest_cpuid() as the sole API to use.
>>
>> Signed-off-by: Andrew Cooper 
> Assuming this is only code movement with no further editing
> (other than possibly for coding style)
> Acked-by: Jan Beulich 

Literally a straight move without any adjustments, other than a static
qualifier.

~Andrew

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

Re: [Xen-devel] [PATCH 26/27] x86/cpuid: Effectively remove pv_cpuid() and hvm_cpuid()

[Jan Beulich]

>>> On 04.01.17 at 13:39,  wrote:
> All callers of pv_cpuid() and hvm_cpuid() (other than guest_cpuid() legacy
> path) have been removed from the codebase.  Move them into cpuid.c to avoid
> any further use, leaving guest_cpuid() as the sole API to use.
> 
> Signed-off-by: Andrew Cooper 

Assuming this is only code movement with no further editing
(other than possibly for coding style)
Acked-by: Jan Beulich 

Jan


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