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

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 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-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-armhf-armhf-libvirt 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-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  cbc45525cb21988599c5eb58c31ef858e401a465
baseline version:
 libvirt  b29f7528ec044060304d0f540a36a68c2f1076d9

Last test of basis   104110  2017-01-11 04:19:54 Z1 days
Testing same since   104134  2017-01-12 04:20:25 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cédric Bosdonnat 
  John Ferlan 
  Laine Stump 
  Michal Privoznik 
  Pino Toscano 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=cbc45525cb21988599c5eb58c31ef858e401a465
+ . ./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-

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-stop   fail REGR. vs. 104119

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

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-xsm 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-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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt 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-libvirt-xsm 12 migrate-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
 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-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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

version targeted for testing:
 xen  0d045d65c19ac48b31344b566cbf82a0270e6e44
baseline version:
 xen  ffc103c223a6d12e5221f66b7e96396a61ba1b20

Last test of basis   104119  2017-01-11 06:45:46 Z0 days
Failing since104126  2017-01-11 16:44:54 Z0 days2 attempts
Testing same since   104131  2017-01-11 22:43:41 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Kevin Tian 
  Stefano Stabellini 
  Wei Liu 

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

Re: [Xen-devel] [PATCH 1/2] xen/kbdif: update protocol documentation

[Oleksandr Andrushchenko]

On 01/12/2017 12:50 AM, Dario Faggioli wrote:

On Wed, 2017-01-11 at 20:40 +0200, Oleksandr Andrushchenko wrote:

On 01/11/2017 07:35 PM, Dario Faggioli wrote:
  
It's indeed a repetition, but a good one, IMO: it helps the reader,

as
she won't have to go back to figure out how big the struct was, how
the
macro was call and to what value it was defined).

I am still not convinced that we should put it.
Probably we can go the way other RFCs do, like TCP [1], 802.11 [2]
etc:
those do not define any reserved fields at the bottom of structures,
(which are effectively padding?) but are limited to only those fields
which are defined.


In principle, I like the idea of following the example of those RFCs.
However, I'd say that what we should value most is consistency within
our own source tree.

But, TBH, there aren't many binary diagram already committed in
include/public/io, so it's hard to tell.

FWIW, I still think that providing a clue to the reader about the size
--even if already specified somewhere else-- would be beneficial, but
it's a rather minor thing, and I certainly can leave with whatever you
and the maintainer(s) agree upon.

fair enough

Regards,
Dario

Konrad, could you please define what that ASCII box
notation should look like?

Thank you,
Oleksandr

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf bf3b7aae7100b60ff8a387f0b7604dbb6ff29fc9
baseline version:
 ovmf 713e4b007cb791829397522ad8f366dd1e08bee6

Last test of basis   104133  2017-01-12 01:46:27 Z0 days
Testing same since   104135  2017-01-12 04:44:52 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=bf3b7aae7100b60ff8a387f0b7604dbb6ff29fc9
+ . ./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 
bf3b7aae7100b60ff8a387f0b7604dbb6ff29fc9
+ branch=ovmf
+ revision=bf3b7aae7100b60ff8a387f0b7604dbb6ff29fc9
+ . ./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
+ '[' xbf3b7aae7100b60ff8a387f0b7604dbb6ff29fc9 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/

[Xen-devel] [PATCH V3] x86/HVM: Introduce struct hvm_pi_ops

[Suravee Suthikulpanit]

The current function pointers in struct vmx_domain for managing hvm
posted interrupt can be used also by SVM AVIC. Therefore, this patch
introduces the struct hvm_pi_ops in the struct hvm_domain to hold them.

Signed-off-by: Suravee Suthikulpanit 
Cc: Andrew Cooper 
Cc: Konrad Rzeszutek Wilk 
Cc: Jan Beulich 
Cc: Kevin Tian 
Cc: Jun Nakajima 
---
Changes from V2:
* Remove "pi_" prefix from the function pointers.
* Reword and move VMX-specific description.

NOTE: I have separated this patch out from the AMD AVIC patch series
  since this mainly affects HVM and VMX code.

 xen/arch/x86/hvm/vmx/vmx.c | 73 +-
 xen/include/asm-x86/hvm/domain.h   | 34 ++
 xen/include/asm-x86/hvm/hvm.h  |  4 +--
 xen/include/asm-x86/hvm/vmx/vmcs.h | 59 --
 4 files changed, 93 insertions(+), 77 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 7b2c50c..0854e17 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -103,6 +103,47 @@ void vmx_pi_per_cpu_init(unsigned int cpu)
 spin_lock_init(&per_cpu(vmx_pi_blocking, cpu).lock);
 }
 
+/*
+ * 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
+ *
+ * VMX implements the runstate transitions as the following:
+ *
+ * A: runnable -> running
+ *  - SN = 0
+ *  - NDST = v->processor
+ *  If a VM is currently running, we want the PI delivered to the guest vcpu
+ *  on the proper pcpu.
+ *
+ * B: running -> runnable
+ *  - SN = 1
+ *
+ * C: running -> blocked
+ *  - SN = 0
+ *  - NV = pi_wakeup_vector
+ *  - Add vcpu to blocked list
+ *  If the vm is blocked, we want the PI delivered to Xen so that it can
+ *  wake it up.
+ *
+ * D: blocked -> runnable
+ *  - SN = 0
+ *  - NV = posted_intr_vector
+ *  - Take vcpu off blocked 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).
+ */
 static void vmx_vcpu_block(struct vcpu *v)
 {
 unsigned long flags;
@@ -204,12 +245,12 @@ void vmx_pi_hooks_assign(struct domain *d)
 if ( !iommu_intpost || !has_hvm_container_domain(d) )
 return;
 
-ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
+ASSERT(!d->arch.hvm_domain.pi_ops.vcpu_block);
 
-d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
-d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
-d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
-d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
+d->arch.hvm_domain.pi_ops.vcpu_block = vmx_vcpu_block;
+d->arch.hvm_domain.pi_ops.switch_from = vmx_pi_switch_from;
+d->arch.hvm_domain.pi_ops.switch_to = vmx_pi_switch_to;
+d->arch.hvm_domain.pi_ops.do_resume = vmx_pi_do_resume;
 }
 
 /* This function is called when pcidevs_lock is held */
@@ -218,12 +259,12 @@ void vmx_pi_hooks_deassign(struct domain *d)
 if ( !iommu_intpost || !has_hvm_container_domain(d) )
 return;
 
-ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
+ASSERT(d->arch.hvm_domain.pi_ops.vcpu_block);
 
-d->arch.hvm_domain.vmx.vcpu_block = NULL;
-d->arch.hvm_domain.vmx.pi_switch_from = NULL;
-d->arch.hvm_domain.vmx.pi_switch_to = NULL;
-d->arch.hvm_domain.vmx.pi_do_resume = NULL;
+d->arch.hvm_domain.pi_ops.vcpu_block = NULL;
+d->arch.hvm_domain.pi_ops.switch_from = NULL;
+d->arch.hvm_domain.pi_ops.switch_to = NULL;
+d->arch.hvm_domain.pi_ops.do_resume = NULL;
 }
 
 static int vmx_domain_initialise(struct domain *d)
@@ -901,8 +942,8 @@ static void vmx_ctxt_switch_from(struct vcpu *v)
 vmx_restore_host_msrs();
 vmx_save_dr(v);
 
-if ( v->domain->arch.hvm_domain.vmx.pi_switch_from )
-v->domain->arch.hvm_domain.vmx.pi_switch_from(v);
+if ( v->domain->arch.hvm_domain.pi_ops.switch_from )
+v->domain->arch.hvm_domain.pi_ops.switch_from(v);
 }
 
 static void vmx_ctxt_switch_to(struct vcpu *v)
@@ -916,8 +957,8 @@ static void vmx_ctxt_switch_to(struct vcpu *v)
 vmx_restore_guest_msrs(v);
 vmx_restore_dr(v);
 
-if ( v->domain->arch.hvm_domain.vmx.pi_switch_to )
-v->domain->arch.hvm_domain.vmx.pi_switch_to(v);
+if ( v->domain->arch.hvm_domain.pi_ops.switch_to )
+v->domain->arch.hvm_domain.pi_ops.switch_to(v);
 }
 
 
@@ -3963,8 

[Xen-devel] [PATCH] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

During an OOM scenario, request slots could not be created as skb
allocation fails. So the netback cannot pass in packets and netfront
wrongly assumes that there is no more work to be done and it disables
polling. This causes Rx to stall.

Fix is to consider the skb allocation failure as an error and in the
event of this error, re-enable polling so that request slots could be
created when memory is available.

Signed-off-by: Vineeth Remanan Pillai 
---
 drivers/net/xen-netfront.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 40f26b6..8275549 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -277,13 +277,14 @@ static struct sk_buff *xennet_alloc_one_rx_buffer(struct 
netfront_queue *queue)
 }
 
 
-static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
+static int xennet_alloc_rx_buffers(struct netfront_queue *queue)
 {
RING_IDX req_prod = queue->rx.req_prod_pvt;
int notify;
+   int err = 0;
 
if (unlikely(!netif_carrier_ok(queue->info->netdev)))
-   return;
+   return err;
 
for (req_prod = queue->rx.req_prod_pvt;
 req_prod - queue->rx.rsp_cons < NET_RX_RING_SIZE;
@@ -295,8 +296,10 @@ static void xennet_alloc_rx_buffers(struct netfront_queue 
*queue)
struct xen_netif_rx_request *req;
 
skb = xennet_alloc_one_rx_buffer(queue);
-   if (!skb)
+   if (!skb) {
+   err = -ENOMEM;
break;
+   }
 
id = xennet_rxidx(req_prod);
 
@@ -321,9 +324,9 @@ static void xennet_alloc_rx_buffers(struct netfront_queue 
*queue)
queue->rx.req_prod_pvt = req_prod;
 
/* Not enough requests? Try again later. */
-   if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
+   if (req_prod - queue->rx.sring->rsp_prod < NET_RX_SLOTS_MIN) {
mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
-   return;
+   return err;
}
 
wmb();  /* barrier so backend seens requests */
@@ -331,6 +334,8 @@ static void xennet_alloc_rx_buffers(struct netfront_queue 
*queue)
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&queue->rx, notify);
if (notify)
notify_remote_via_irq(queue->rx_irq);
+
+   return err;
 }
 
 static int xennet_open(struct net_device *dev)
@@ -1046,7 +1051,7 @@ static int xennet_poll(struct napi_struct *napi, int 
budget)
 
work_done -= handle_incoming_queue(queue, &rxq);
 
-   xennet_alloc_rx_buffers(queue);
+   err = xennet_alloc_rx_buffers(queue);
 
if (work_done < budget) {
int more_to_do = 0;
@@ -1054,7 +1059,11 @@ static int xennet_poll(struct napi_struct *napi, int 
budget)
napi_complete(napi);
 
RING_FINAL_CHECK_FOR_RESPONSES(&queue->rx, more_to_do);
-   if (more_to_do)
+
+   /* If there is more work to do or could not allocate
+* rx buffers, re-enable polling.
+*/
+   if (more_to_do || err != 0)
napi_schedule(napi);
}
 
-- 
2.1.2.AMZN


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 713e4b007cb791829397522ad8f366dd1e08bee6
baseline version:
 ovmf df3f02df1bde40c2a0d486d3ca6bd529c3654049

Last test of basis   104129  2017-01-11 20:46:03 Z0 days
Testing same since   104133  2017-01-12 01:46:27 Z0 days1 attempts


People who touched revisions under test:
  Augustine Linson P 
  Linson Augustine 

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=713e4b007cb791829397522ad8f366dd1e08bee6
+ . ./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 
713e4b007cb791829397522ad8f366dd1e08bee6
+ branch=ovmf
+ revision=713e4b007cb791829397522ad8f366dd1e08bee6
+ . ./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
+ '[' x713e4b007cb791829397522ad8f366dd1e08bee6 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org

Re: [Xen-devel] [PATCH v4 12/24] x86: refactor psr: set value: implement write msr flow.

[Yi Sun]

On 17-01-11 07:01:23, Jan Beulich wrote:
> >>> On 11.01.17 at 07:22,  wrote:
> > On 17-01-10 08:15:15, Jan Beulich wrote:
> >> >>> On 14.12.16 at 05:07,  wrote:
> >> > --- a/xen/arch/x86/psr.c
> >> > +++ b/xen/arch/x86/psr.c
> >> > @@ -186,6 +186,9 @@ struct feat_ops {
> >> >  unsigned int (*exceeds_cos_max)(const uint64_t val[],
> >> >  const struct feat_node *feat,
> >> >  unsigned int cos);
> >> > +/* write_msr is used to write out feature MSR register. */
> >> > +int (*write_msr)(unsigned int cos, const uint64_t val[],
> >> > + struct feat_node *feat);
> >> 
> >> Looks like this function again returns number-of-values, yet this time
> >> without a comment saying so. While you don't need to replicate
> >> that description multiple time, please at least has a brief reference.
> >> That said, with the type checks moved out I think this return value
> >> model won't be needed anymore - the caller, having checked the
> >> type, could then simply call the get-num-val (or however it was
> >> named) hook to know how many array entries to skip.
> >> 
> > For write msr, we may need iterate the whole feature list to write values 
> > for
> > every feature if the input value is not same as old on the COS ID. So, I 
> > prefer
> > to keep current return value, the number-of-values handled. That would be 
> > clear
> > and easy to implement. Of course, we can call get_cos_num to get the returen
> > value or define a macro to replace the digit. How do you think?
> 
> Well, my general reservation here is that this way you require about
> half a dozen functions to all return the same value. If the value
> changes (or if somebody clones the set), there's the risk of one not
> getting properly updated. Therefore I'd much prefer for just one
> function to return the count. And I'm relatively certain that with the
> type checks moved out, this will actually end up being the more
> natural way.
> 
I imagine the way as your suggestion. It might be below flow for this write_msr.

list_for_each_entry(feat...) {
feat->write_msr(..., val_array);
val_array += feat->get_cos_num();
..
}

Is that what you think? Thanks!

> Jan

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

Re: [Xen-devel] [PATCH v4 09/24] x86: refactor psr: set value: assemble features value array.

[Yi Sun]

On 17-01-11 06:57:30, Jan Beulich wrote:
> >>> On 11.01.17 at 07:07,  wrote:
> > On 17-01-10 07:34:00, Jan Beulich wrote:
> >> >>> On 14.12.16 at 05:07,  wrote:
> >> > +static int l3_cat_set_new_val(uint64_t val[],
> >> > +  const struct feat_node *feat,
> >> > +  unsigned int old_cos,
> >> > +  enum cbm_type type,
> >> > +  uint64_t m)
> >> > +{
> >> > +if ( type != PSR_CBM_TYPE_L3 )
> >> > +/* L3 CAT uses one COS. Skip it. */
> >> > +return 1;
> >> 
> >> If this is the wrong type, how can you return 1 (or any positive
> >> value) here? This basically suggests that, as recommended for an
> >> earlier operation already, that you want the type check done in
> >> the caller. Or wait - isn't type not matching an error here, as you
> >> iterate the same list twice in the same order? Which then gets us
> >> back to me mentioning that the set-new-value should really be
> >> done in common code, not in the callbacks; it would really only be
> >> the check (psr_check_cbm() in the L3 case above) which would
> >> require a callback.
> >> 
> > Your understanding is right. The value array will be iterated twice. First,
> > assemble all features old value into it. Second, set the target value into
> > array according to the target feature's position in the array. Because
> > different features may have different behaviors, e.g. CDP uses two entries
> > of the array, I think it would be better to make 'set_new_val' be a callback
> > function.
> 
> Bot for common code to do that, all it takes is knowing the number
> of registers, which you already have a callback for.
> 
Ok, will consider it. Thanks!

> Jan

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

Re: [Xen-devel] [PATCH v4 07/24] x86: refactor psr: implement get value flow.

[Yi Sun]

On 17-01-11 06:54:30, Jan Beulich wrote:
> >>> On 11.01.17 at 06:16,  wrote:
> > On 17-01-10 06:50:36, Jan Beulich wrote:
> >> >>> On 14.12.16 at 05:07,  wrote:
> >> > This patch implements get value flow including L3 CAT callback
> >> > function.
> >> > 
> >> > It also changes domctl interface to make it more general.
> >> > 
> >> > With this patch, 'psr-cat-show' can work for L3 CAT.
> >> 
> >> How about CDP? You don't implement anything for it here, and looking
> >> over the subjects of the remaining patches there also doesn't seem to
> >> be anything to come.
> >> 
> > I split CDP codes out to a few patches from 13 to 16. CDP is a stand alone
> > feature now but not combined with L3 CAT.
> > 
> > [PATCH v4 13/24] x86: refactor psr: implement CPU init and free flow for 
> > CDP.
> 
> So I guess the "get value" part is to be found there then, too?
> Because that's what I was looking for before making the remark.
> 
Yes, you can check this one.
[PATCH v4 15/24] x86: refactor psr: implement get value flow for CDP.

> Jan

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

Re: [Xen-devel] [PATCH v4 06/24] x86: refactor psr: implement get hw info flow.

[Yi Sun]

On 17-01-11 06:53:30, Jan Beulich wrote:
> >>> On 11.01.17 at 06:13,  wrote:
> > On 17-01-10 06:46:03, Jan Beulich wrote:
> >> >>> On 14.12.16 at 05:07,  wrote:
> >> > +int psr_get_info(unsigned int socket, enum cbm_type type,
> >> > + uint32_t dat[], uint32_t array_len)
> >> > +{
> >> > +struct psr_socket_info *info = get_socket_info(socket);
> >> > +struct feat_node *feat_tmp;
> >> 
> >> With the hook function taking a pointer to const I don#t see why
> >> this one can't be const, too.
> >> 
> > Do you mean feat_tmp? Thanks!
> 
> Not sure why you ask - yes, that's why I've placed the comment at
> precisely this line.
> 
Got it, thanks!

> Jan

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

Re: [Xen-devel] [PATCH v4 04/24] x86: refactor psr: implement CPU init and free flow.

[Yi Sun]

On 17-01-11 06:48:27, Jan Beulich wrote:
> >>> On 11.01.17 at 04:14,  wrote:
> > On 17-01-10 04:45:05, Jan Beulich wrote:
> >> >>> On 14.12.16 at 05:07,  wrote:
> >> > +/* L3 CAT callback functions implementation. */
> >> > +static void l3_cat_init_feature(unsigned int eax, unsigned int ebx,
> >> > +unsigned int ecx, unsigned int edx,
> >> 
> >> This is rather unfortunate naming: How does the reader of this code
> >> know what these values represent, without having to first go look in
> >> the caller?
> >> 
> > Do you mean the 'eax'-'edx'?
> 
> Yes.
> 
> > How about 'eax_register'?
> 
> How would that be any better? Perhaps the best way of making the
> naming obvious would be to use the new cpuid_leaf structure here.
> 
Ok, will consider to assemble them into a structure.

> >> > +if ( !cpu_has(c, X86_FEATURE_PQE) || c->cpuid_level < 
> >> > PSR_CPUID_LEVEL_CAT )
> >> > +return;
> >> 
> >> Instead of such a double check, please consider clearing the PQE
> >> feature bit when the maximum CPUID level is too low (which
> >> shouldn't happen anyway).
> >> 
> > Is this the responsibility of psr.c? X86_FEATURE_PQE bit is set by HW. Even 
> > the
> > bit is set but CPUID level is low, I think SW would be better to keep it but
> > not clear it. Because it indicates the HW capability. How do you think? 
> 
> What use if keeping the flag if we can't use the feature? And to
> answer your first question - whether that's being done in psr.c,
> cpu/common.c, or cpu/intel.c I don't really care all that much; it
> would certainly feel most natural to go here.
> 
Ok, will consider it.

> >> > +socket = cpu_to_socket(cpu);
> >> > +info = socket_info + socket;
> >> > +if ( info->feat_mask )
> >> > +return;
> >> > +
> >> > +spin_lock_init(&info->ref_lock);
> >> > +
> >> > +cpuid_count(PSR_CPUID_LEVEL_CAT, 0, &eax, &ebx, &ecx, &edx);
> >> > +if ( ebx & PSR_RESOURCE_TYPE_L3 )
> >> > +{
> >> > +cpuid_count(PSR_CPUID_LEVEL_CAT, 1, &eax, &ebx, &ecx, &edx);
> >> > +
> >> > +feat_tmp = feat_l3_cat;
> >> > +feat_l3_cat = NULL;
> >> > +feat_tmp->ops = l3_cat_ops;
> >> > +
> >> > +feat_tmp->ops.init_feature(eax, ebx, ecx, edx, feat_tmp, info);
> >> 
> >> What's the point of the indirect call here, when you know the
> >> function is l3_cat_init_feature()?
> >> 
> > Hmm, just want to keep the callback function calling style.
> 
> Please don't use indirect calls when you don't need them.
> 
Ok, thanks!

> >> > +static int psr_cpu_prepare(unsigned int cpu)
> >> > +{
> >> > +return cpu_prepare_work(cpu);
> >> > +}
> >> 
> >> What is this wrapper good for?
> >> 
> > Just keep the old codes.
> 
> Well, you're overhauling the old code anyway (and you're actively
> adding this function here), so - please don't introduce pointless
> wrappers like this. They only complicate anyone following call flow,
> even if just slightly.
> 
Sure, thanks!

> Jan

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

[Xen-devel] [PATCH] partially revert "xen: Remove event channel notification through Xen PCI platform device"

[Stefano Stabellini]

The following commit:

commit 72a9b186292d98494f26cfd24a1621796209
Author: KarimAllah Ahmed 
Date:   Fri Aug 26 23:55:36 2016 +0200

xen: Remove event channel notification through Xen PCI platform device

broke Linux when booting as Dom0 on Xen in a nested Xen environment (Xen
installed inside a Xen VM). In this scenario, Linux is a PV guest, but
at the same time it uses the platform-pci driver to receive
notifications from L0 Xen. vector callbacks are not available because L1
Xen doesn't allow them.

Partially revert the offending commit, by restoring IRQ based
notifications for PV guests only. I restored only the code which is
strictly needed and replaced the xen_have_vector_callback checks within
it with xen_pv_domain() checks.

Signed-off-by: Stefano Stabellini 

---
Alternatively, I could also restore the xen_have_vector_callback
checks. In general, it's best to have feature flag checks than umbrella
xen_pv/hvm_domain() checks.
---

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index b59c9455..1477f1d 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -42,6 +42,7 @@
 static unsigned long platform_mmio;
 static unsigned long platform_mmio_alloc;
 static unsigned long platform_mmiolen;
+static uint64_t callback_via;
 
 static unsigned long alloc_xen_mmio(unsigned long len)
 {
@@ -54,6 +55,51 @@ static unsigned long alloc_xen_mmio(unsigned long len)
return addr;
 }
 
+static uint64_t get_callback_via(struct pci_dev *pdev)
+{
+   u8 pin;
+   int irq;
+
+   irq = pdev->irq;
+   if (irq < 16)
+   return irq; /* ISA IRQ */
+
+   pin = pdev->pin;
+
+   /* We don't know the GSI. Specify the PCI INTx line instead. */
+   return ((uint64_t)0x01 << 56) | /* PCI INTx identifier */
+   ((uint64_t)pci_domain_nr(pdev->bus) << 32) |
+   ((uint64_t)pdev->bus->number << 16) |
+   ((uint64_t)(pdev->devfn & 0xff) << 8) |
+   ((uint64_t)(pin - 1) & 3);
+}
+
+static irqreturn_t do_hvm_evtchn_intr(int irq, void *dev_id)
+{
+   xen_hvm_evtchn_do_upcall();
+   return IRQ_HANDLED;
+}
+
+static int xen_allocate_irq(struct pci_dev *pdev)
+{
+   return request_irq(pdev->irq, do_hvm_evtchn_intr,
+   IRQF_NOBALANCING | IRQF_TRIGGER_RISING,
+   "xen-platform-pci", pdev);
+}
+
+static int platform_pci_resume(struct pci_dev *pdev)
+{
+   int err;
+   if (!xen_pv_domain())
+   return 0;
+   err = xen_set_callback_via(callback_via);
+   if (err) {
+   dev_err(&pdev->dev, "platform_pci_resume failure!\n");
+   return err;
+   }
+   return 0;
+}
+
 static int platform_pci_probe(struct pci_dev *pdev,
  const struct pci_device_id *ent)
 {
@@ -92,6 +138,21 @@ static int platform_pci_probe(struct pci_dev *pdev,
platform_mmio = mmio_addr;
platform_mmiolen = mmio_len;
 
+   if (xen_pv_domain()) {
+   ret = xen_allocate_irq(pdev);
+   if (ret) {
+   dev_warn(&pdev->dev, "request_irq failed err=%d\n", 
ret);
+   goto out;
+   }
+   callback_via = get_callback_via(pdev);
+   ret = xen_set_callback_via(callback_via);
+   if (ret) {
+   dev_warn(&pdev->dev, "Unable to set the evtchn callback 
"
+"err=%d\n", ret);
+   goto out;
+   }
+   }
+
max_nr_gframes = gnttab_max_grant_frames();
grant_frames = alloc_xen_mmio(PAGE_SIZE * max_nr_gframes);
ret = gnttab_setup_auto_xlat_frames(grant_frames);
@@ -123,6 +184,9 @@ static int platform_pci_probe(struct pci_dev *pdev,
.name =   DRV_NAME,
.probe =  platform_pci_probe,
.id_table =   platform_pci_tbl,
+#ifdef CONFIG_PM
+   .resume_early =   platform_pci_resume,
+#endif
 };
 
 static int __init platform_pci_init(void)

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

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

[Dan Streetman]

On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini
 wrote:
> On Wed, 11 Jan 2017, Dan Streetman wrote:
>> On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
>>  wrote:
>> > On Tue, 10 Jan 2017, Dan Streetman wrote:
>> >> On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
>> >>  wrote:
>> >> > On Tue, 10 Jan 2017, Dan Streetman wrote:
>> >> >> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman  
>> >> >> wrote:
>> >> >> > On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
>> >> >> >  wrote:
>> >> >> >> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
>> >> >> >>> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
>> >> >> >>> > On Mon, Jan 9, 2017 at 9:59 AM, Boris Ostrovsky
>> >> >> >>> >  wrote:
>> >> >> >>> > > On 01/06/2017 08:06 PM, Konrad Rzeszutek Wilk wrote:
>> >> >> >>> > >> On Thu, Jan 05, 2017 at 02:28:56PM -0500, Dan Streetman wrote:
>> >> >> >>> > >>> 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.
>> >> >> >>> > >> Won't this cause a starvation problem? That is we will run 
>> >> >> >>> > >> out of PIRQs
>> >> >> >>> > >> as we are not reusing them?
>> >> >> >>> > >
>> >> >> >>> > > Don't we free the pirq when we unmap it?
>> >> >> >>> >
>> >> >> >>> > I think this is actually a bit worse than I initially thought.  
>> >> >> >>> > After
>> >> >> >>> > looking a bit closer, and I think there's an asymmetry with pirq
>> >> >> >>> > allocation:
>> >> >> >>>
>> >> >> >>> Lets include Stefano,
>> >> >> >>>
>> >> >> >>> Thank you for digging in this! This has quite the deja-vu
>> >> >> >>> feeling as I believe I hit this at some point in the past and
>> >> >> >>> posted some possible ways of fixing this. But sadly I can't
>> >> >> >>> find the thread.
>> >> >> >>
>> >> >> >> This issue seems to be caused by:
>> >> >> >>
>> >> >> >> commit af42b8d12f8adec6711cb824549a0edac6a4ae8f
>> >> >> >> Author: Stefano Stabellini 
>> >> >> >> Date:   Wed Dec 1 14:51:44 2010 +
>> >> >> >>
>> >> >> >> xen: fix MSI setup and teardown for PV on HVM guests
>> >> >> >>
>> >> >> >> which was a fix to a bug:
>> >> >> >>
>> >> >> >> This fixes a bug in xen_hvm_setup_msi_irqs that manifests 
>> >> >> >> itself when
>> >> >> >> trying to enable the same MSI for the second time: the old MSI 
>> >> >> >> to pirq
>> >> >> >> mapping is still valid at this point but xen_hvm_setup_msi_irqs 
>> >> >> >> would
>> >> >> >> try to assign a new pirq anyway.
>> >> >> >> A simple way to reproduce this bug is to assign an MSI capable 
>> >> >> >> network
>> >> >> >> card to a PV on HVM guest, if the user brings down the 
>> >> >> >> corresponding
>> >> >> >> ethernet interface and up again, Linux would fail to enable 
>> >> >> >> MSIs on the
>> >> >> >> device.
>> >> >> >>
>> >> >> >> I don't remember any of the details. From the description of this 
>> >> >> >> bug,
>> >> >> >> it seems that Xen changed behavior in the past few years: before it 
>> >> >> >> used
>> >> >> >> to keep the pirq-MSI mapping, while today it doesn't. If I wrote 
>> >> >> >> "the
>> >> >> >> old MSI to pirq mapping is still valid at this point", the pirq 
>> >> >> >> couldn't
>> >> >> >> have been completely freed, then reassigned to somebody else the 
>> >> >> >> way it
>> >> >> >> is described in this email.
>> >> >> >>
>> >> >> >> I think we should indentify the changeset or Xen version that 
>> >> >> >> introduced
>> >> >> >> the new behavior. If it is old enough, we might be able to just 
>> >> >> >> revert
>> >> >> >> af42b8d12f8adec6711cb824549a0edac6a4ae8f. Otherwise we could make 
>> >> >> >> the
>> >> >> >> behavior conditional to the Xen version.
>> >> >> >
>> >> >> > Are PT devices the only MSI-capable devices available in a Xen guest?
>> >> >> > That's where I'm seeing this problem, with PT NVMe devices.
>> >> >
>> >> > They are the main ones. It is possible to have emulated virtio devices
>> >> > with emulated MSIs, for example virtio-net. Althought they are not in
>> >> > the Xen Project CI-loop, so I wouldn't be surprised if they are broken
>> >> > too.
>> >> >
>> >> >
>> >> >> > I can say that on the Xen guest with NVMe PT devices I'm testing on,
>> >> >> > with the patch from this thread (which essentially reverts your 
>> >> >> > commit
>> >> >> > above) as well as some added debug to see the pirq numbers, cycles of
>> >> >> > 'modprobe nvme ; rmmod nvme' don't cause pirq starvation, as the
>> >> >> > hypervisor provides essentially the same pirqs for each modprobe,
>> >> >> > since they were freed by the rmmod.
>> >> >
>> >> > I am fine with reverting the old patch, but we need to understa

Re: [Xen-devel] [PATCH 1/2] xen/kbdif: update protocol documentation

[Dario Faggioli]

On Wed, 2017-01-11 at 20:40 +0200, Oleksandr Andrushchenko wrote:
> On 01/11/2017 07:35 PM, Dario Faggioli wrote:
> > 
> > It's indeed a repetition, but a good one, IMO: it helps the reader,
> > as
> > she won't have to go back to figure out how big the struct was, how
> > the
> > macro was call and to what value it was defined).
> I am still not convinced that we should put it.
> Probably we can go the way other RFCs do, like TCP [1], 802.11 [2]
> etc:
> those do not define any reserved fields at the bottom of structures,
> (which are effectively padding?) but are limited to only those fields
> which are defined.
>
In principle, I like the idea of following the example of those RFCs.
However, I'd say that what we should value most is consistency within
our own source tree.

But, TBH, there aren't many binary diagram already committed in
include/public/io, so it's hard to tell.

FWIW, I still think that providing a clue to the reader about the size
--even if already specified somewhere else-- would be beneficial, but
it's a rather minor thing, and I certainly can leave with whatever you
and the maintainer(s) agree upon.

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

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm   6 xen-boot fail REGR. vs. 104119

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

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-xsm 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-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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt 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-libvirt-xsm 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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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

version targeted for testing:
 xen  14a6be89ec04bfadba978dc4c2f1e7f96db8cdf0
baseline version:
 xen  ffc103c223a6d12e5221f66b7e96396a61ba1b20

Last test of basis   104119  2017-01-11 06:45:46 Z0 days
Testing same since   104126  2017-01-11 16:44:54 Z0 days1 attempts


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

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-pvops   

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf df3f02df1bde40c2a0d486d3ca6bd529c3654049
baseline version:
 ovmf e044364b82e63047980606c388f4854b7c41e947

Last test of basis   104128  2017-01-11 18:45:20 Z0 days
Testing same since   104129  2017-01-11 20:46:03 Z0 days1 attempts


People who touched revisions under test:
  Michael Kinney 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=df3f02df1bde40c2a0d486d3ca6bd529c3654049
+ . ./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 
df3f02df1bde40c2a0d486d3ca6bd529c3654049
+ branch=ovmf
+ revision=df3f02df1bde40c2a0d486d3ca6bd529c3654049
+ . ./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
+ '[' xdf3f02df1bde40c2a0d486d3ca6bd529c3654049 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvo

Re: [Xen-devel] [PATCH v11 00/13] x86: multiboot2 protocol support

[Daniel Kiper]

On Mon, Dec 05, 2016 at 11:25:05PM +0100, Daniel Kiper wrote:
> Hi,
>
> I am sending eleventh version of multiboot2 protocol support for
> legacy BIOS and EFI platforms. This patch series release contains
> fixes for all known issues.
>
> The final goal is xen.efi binary file which could be loaded by EFI
> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> multiboot2 protocol. This way we will have:
>   - smaller Xen code base,
>   - one code base for xen.gz and xen.efi,
>   - one build method for xen.gz and xen.efi;
> xen.efi will be extracted from xen(-syms)
> file using objcopy or special custom tool,
>   - xen.efi build will not so strongly depend
> on a given GCC and binutils version.
>
> Here is short list of changes since v10:
>   - changed patches: 06 (small change suggested by Jan).

Guys, I am going to release next version in 1-2 weeks. If you
have more comments for current one please post them ASAP.
I would like to have this patch series come into 4.9.

Thanks,

Daniel

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

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Wed, Jan 11, 2017 at 01:50:56PM -0600, Doug Goldstein wrote:
> On 1/11/17 1:08 PM, Daniel Kiper wrote:
> > On Mon, Jan 09, 2017 at 07:37:59PM -0600, Doug Goldstein wrote:
> >> On 12/5/16 4:25 PM, Daniel Kiper wrote:

[...]

> >>>  /* Populate E820 table and check trampoline area availability. */
> >>>  e = e820map - 1;
> >>> @@ -168,7 +170,8 @@ static void __init 
> >>> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> >>>  /* fall through */
> >>>  case EfiConventionalMemory:
> >>>  if ( !trampoline_phys && desc->PhysicalStart + len <= 
> >>> 0x10 &&
> >>> - len >= cfg.size && desc->PhysicalStart + len > cfg.addr 
> >>> )
> >>> + len >= cfg.size + extra_mem &&
> >>> + desc->PhysicalStart + len > cfg.addr )
> >>>  cfg.addr = (desc->PhysicalStart + len - cfg.size) & 
> >>> PAGE_MASK;
> >>
> >> So this is where the current series blows up and fails on real hardware.
> >> No where in the EFI + MB2 code path is cfg.size ever initialized. Its
> >> only initialized in the straight EFI case. The result is that cfg.addr
> >> is set to the section immediately following this. Took a bit to
> >> trackdown because I checked for memory overlaps with where Xen was
> >> loaded and where it was relocated to but forgot to check for overlaps
> >> with the trampoline code. This is the address where the trampoline jumps
> >> are copied.
> >>
> >> Personally I'd like to see an ASSERT added or the code swizzled around
> >> in such a way that its not possible to get into a bad state. But this is
> >> probably another patch series.
> >
> > Nice catch! Thanks a lot. I think that we should initialize cfg.size = 64 
> > << 10
> > in efi_multiboot2(). It looks like real fix. extra_mem stuff is bogus.
>
> Except in head.S you start the stack 64kb after the end of the
> trampoline size. So cfg.size = (64 << 10); won't work. It needs to be
> the size of the trampoline + 64k.

I will double check it and drop you a line. Probably in 1-2 weeks.
Now I am tidying up my backlog after vacation.

> >>> +efi_tables();
> >>> +setup_efi_pci();
> >>> +efi_variables();
> >>
> >> This is probably where you missed the call to "efi_arch_memory_setup();"
> >> that gave me hell above.
> >
> > This does not work in MB2 case.
>
> You're looking at the oldest email. I've have further follow ups that
> point that out and I've included a patch to fix the issues.

I have tried to reply to all your emails.

> >> So as an aside, IMHO this is where the series should end and the next
> >> set of patches should be a follow on.
> >
> > Hmmm... Why? If you do not apply rest of patches then MB2 does not
> > work on all EFI platforms.
> >
> > Daniel
> >
>
> Q: How do you eat an elephant?
> A: One bite at a time.
>
> The point is we have 0 MB2 support presently. We can add it in
> incremental hunks. Otherwise we get a patch series that's been floating

I think that nothing prevents maintainers to apply my patch series partially.
And many prerequisite patches went that way. However, I think that they should
not apply this patch without the rest (and more importantly patch series should
not end at this patch). If we do that we will provide MB2 functionality which
is broken and confuse users. However, if you think that it make sense please
convince maintainers to do that. Though I will not support such request.

> around for around 3 years and missed at least 2 releases where it should

Do not forget that it required a lot of changes in MB2 protocol, GRUB2 (changes
are in git repository and will come into next release), etc. And I have carried
almost all of that stuff myself. Please, believe me this is not easy task.

> have gotten in. We've only got several weeks before the 4.9 window
> closes as well.

Window closes at the end of the march. I am going to release new version
in 1-2 weeks after clearing my backlog. I hope that this patch series
will go into 4.9. At least I will do all my best to achieve that goal.

Daniel

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

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

[Doug Goldstein]

On 1/11/17 1:08 PM, Daniel Kiper wrote:
> On Mon, Jan 09, 2017 at 07:37:59PM -0600, Doug Goldstein wrote:
>> On 12/5/16 4:25 PM, Daniel Kiper wrote:
> 
> 
>>> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
>>> index 0a93e61..70ed836 100644
>>> --- a/xen/common/efi/boot.c
>>> +++ b/xen/common/efi/boot.c
>>> @@ -79,6 +79,17 @@ static size_t wstrlen(const CHAR16 * s);
>>>  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
>>>  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
>>>
>>> +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
>>> *SystemTable);
>>> +static void efi_console_set_mode(void);
>>> +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
>>> +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
>>> +   UINTN cols, UINTN rows, UINTN depth);
>>> +static void efi_tables(void);
>>> +static void setup_efi_pci(void);
>>> +static void efi_variables(void);
>>> +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN 
>>> gop_mode);
>>> +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
>>> *SystemTable);
>>> +
>>>  static const EFI_BOOT_SERVICES *__initdata efi_bs;
>>>  static UINT32 __initdata efi_bs_revision;
>>>  static EFI_HANDLE __initdata efi_ih;
>>>
>>
>> So as an aside, IMHO this is where the series should end and the next
>> set of patches should be a follow on.
> 
> Hmmm... Why? If you do not apply rest of patches then MB2 does not
> work on all EFI platforms.
> 
> Daniel
> 

So I should have expanded more in my other email. I've got this series
pulled in on top of 4.8 along with different fixes as discussed on this
thread:

https://github.com/cardoe/xen/tree/48-and-daniel

This boots up on my NUC but reports the other CPUs as stuck and the
error is -5. This starts to come up on the Lenovo and it gets to near
where it starts the dom0 kernel and then blanks the screen and hard
hangs. This causes cr0 crashes on the other boards I've got access to.


I've also got the series only to this point with the fixes.

https://github.com/cardoe/xen/tree/48-and-daniel-sans-relocate

The later version boots up on my NUC with all CPUs. It still hangs on
the Lenovo. It works on the other boards. It also appears work under QEMU.

-- 
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] x86/svm: Adjust ModRM Mode check in is_invlpg()

[Boris Ostrovsky]

On 01/11/2017 12:33 PM, Andrew Cooper wrote:
> Coverity points out that x86_insn_modrm() returns -EINVAL for instructions not
> encoded with a ModRM byte.  A consequence is that checking != 3 is
> insufficient to confirm that &ext was actually written to.
>
> In practice, this check is only used after decode has been successful, and
> 0f01 will have a ModRM byte.
>
> Use an unsigned < comparison to exclude the -EINVAL case, guaranteeing that
> ext is only read if it was filled in by x86_insn_modrm(), which should placate
> Coverity.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 
>
> RFC.  I haven't actually checked that this fixes the issue.
>
> An alternative would be to ASSERT() that x86_insn_modrm() is non-negative, but
> I can't nice way of integrating that into the existing logic (without using
> the comma operator, and that isn't nice to read).

how about

return ctxt->opcode == X86EMUL_OPC(0x0f, 0x01) &&
-   x86_insn_modrm(state, NULL, &ext) != 3 &&
+   (mod = x86_insn_modrm(state, NULL, &ext)) >= 0 && mod != 3 &&
(ext & 7) == 7;


(in case x86_insn_modrm decides to return some other errors in the future.)

-boris

> ---
>  xen/arch/x86/hvm/svm/svm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index ae8e2c4..ff134a5 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2162,7 +2162,7 @@ static bool is_invlpg(const struct x86_emulate_state 
> *state,
>  unsigned int ext;
>  
>  return ctxt->opcode == X86EMUL_OPC(0x0f, 0x01) &&
> -   x86_insn_modrm(state, NULL, &ext) != 3 &&
> +   (unsigned int)x86_insn_modrm(state, NULL, &ext) < 3 &&
> (ext & 7) == 7;
>  }
>  



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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf e044364b82e63047980606c388f4854b7c41e947
baseline version:
 ovmf f7c11d9b995cc59cdbda0b790eafbc510b50b82d

Last test of basis   104123  2017-01-11 10:46:13 Z0 days
Testing same since   104128  2017-01-11 18:45:20 Z0 days1 attempts


People who touched revisions under test:
  Michael D Kinney 
  Michael Kinney 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=e044364b82e63047980606c388f4854b7c41e947
+ . ./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 
e044364b82e63047980606c388f4854b7c41e947
+ branch=ovmf
+ revision=e044364b82e63047980606c388f4854b7c41e947
+ . ./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
+ '[' xe044364b82e63047980606c388f4854b7c41e947 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/ho

Re: [Xen-devel] [PATCH v11 11/13] x86: make Xen early boot code relocatable

[Doug Goldstein]

On 1/11/17 2:05 PM, Daniel Kiper wrote:
> On Mon, Jan 09, 2017 at 08:05:01PM -0600, Doug Goldstein wrote:
>> On 12/5/16 4:25 PM, Daniel Kiper wrote:
> 
> [...]
> 
>>>  /* Save trampoline address for later use. */
>>>  shl $4, %ecx
>>> -mov %ecx,sym_phys(trampoline_phys)
>>> +mov %ecx,sym_fs(trampoline_phys)
>>> +
>>> +/* Save Xen image load base address for later use. */
>>> +mov %esi,sym_fs(xen_phys_start)
>>> +mov %esi,sym_fs(trampoline_xen_phys_start)
>>> +
>>> +/* Setup stack. %ss was initialized earlier. */
>>> +lea 1024+sym_esi(cpu0_stack),%esp
>>
>> Not sure if this is the bad code or what but after this patch in the
>> series the stack is at 0xAD000 which is in the middle of VGA memory so
>> the stack is getting screwy (hence my email last week). And the stack is
>> bad in trampoline_setup, before trampoline_setup the stack seems fine.
>>
>> This is from my hacked up version of iPXE...
>>
>> Type / Addr / Number of Pages / Flags
>>
>> Conventional: 0x59000 :  69 : f
>> Reserved: 0x9e000 :   2 : f
>> Conventional: 0x00010 :   65280 : f
>>
>> As you can see from 0xA to 0x10 isn't mentioned but everything I
>> can find on EFI says if the range isn't mentioned you shouldn't use it.
> 
> Could you provide full EFI memory map from this machine?
> 
> Daniel
> 

Its a NUC5i5MYHE with 16gb of RAM. Let me know if you need help
deciphering this. I'm going to convert this output into the same as
Linux's output when I get some time.

Name: Start Addr : Pages : Flags
Conventional: 0x0 :  88 : f
Reserved: 0x58000 :   1 : f
Conventional: 0x59000 :  69 : f
Reserved: 0x9e000 :   2 : f
Conventional: 0x00010 :   65280 : f
BS Code:  0x01000 :  11 : f
Conventional: 0x01000b000 :  547960 : f
BS Data:  0x095c83000 :  64 : f
Conventional: 0x095cc3000 :   30743 : f
Loader Code:  0x09d4da000 : 180 : f
BS Data:  0x09d58e000 : 484 : f
RS Data:  0x09d772000 :1273 : 800f
BS Data:  0x09dc6b000 :   8 : f
Conventional: 0x09dc73000 :2260 : f
BS Data:  0x09e547000 :   13272 : f
Conventional: 0x0a191f000 : 481 : f
BS Code:  0x0a1b0 :1925 : f
Reserved: 0x0a2285000 : 187 : f
ACPI Reclaim: 0x0a234 :  37 : f
ACPI NVS: 0x0a2365000 :2352 : f
RS Data:  0x0a2c95000 : 781 : 800f
RS Code:  0x0a2fa2000 :  93 : 800f
BS Data:  0x0a2fff000 :   1 : f
Conventional: 0x1 : 3497984 : f
Reserved: 0x0a380 :   18432 : 0
MMAP IO:  0x0f800 :   16384 : 8001
MMAP IO:  0x0fec0 :   1 : 8001
MMAP IO:  0x0fed0 :   4 : 8001
MMAP IO:  0x0fed1c000 :   4 : 8001
MMAP IO:  0x0fee0 :   1 : 8001
MMAP IO:  0x0ff00 :4096 : 8001

-- 
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 v11 07/13] x86: add multiboot2 protocol support for EFI platforms

[Doug Goldstein]

On 1/11/17 1:47 PM, Daniel Kiper wrote:
> On Tue, Jan 10, 2017 at 02:51:27PM -0600, Doug Goldstein wrote:
>> On 1/9/17 7:37 PM, Doug Goldstein wrote:
>>> On 12/5/16 4:25 PM, Daniel Kiper wrote:
>>
 diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
 index 62c010e..dc857d8 100644
 --- a/xen/arch/x86/efi/efi-boot.h
 +++ b/xen/arch/x86/efi/efi-boot.h
 @@ -146,6 +146,8 @@ static void __init 
 efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
  {
  struct e820entry *e;
  unsigned int i;
 +/* Check for extra mem for mbi data if Xen is loaded via multiboot2 
 protocol. */
 +UINTN extra_mem = efi_enabled(EFI_LOADER) ? 0 : (64 << 10);
>>>
>>> Just wondering where the constant came from? And if there should be a
>>> little bit of information about it. To me its just weird to shift 64.
>>
>> Its the size of the stack used in the assembly code.
> 
> No, it is trampoline region size.

trampoline + stack in head.S We take the address where we're going to
copy the trampoline and set the stack to 0x1 past it.


> 
  /* Populate E820 table and check trampoline area availability. */
  e = e820map - 1;
 @@ -168,7 +170,8 @@ static void __init 
 efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
  /* fall through */
  case EfiConventionalMemory:
  if ( !trampoline_phys && desc->PhysicalStart + len <= 
 0x10 &&
 - len >= cfg.size && desc->PhysicalStart + len > cfg.addr )
 + len >= cfg.size + extra_mem &&
 + desc->PhysicalStart + len > cfg.addr )
  cfg.addr = (desc->PhysicalStart + len - cfg.size) & 
 PAGE_MASK;
>>>
>>> So this is where the current series blows up and fails on real hardware.
>>
>> Honestly this was my misunderstanding and this shouldn't ever be used to
>> get memory for the trampoline. This also has the bug in it that it needs
>> to be:
>>
>> ASSERT(cfg.size > 0);
>> cfg.addr = (desc->PhysicalStart + len - (cfg.size + extra_mem) & PAGE_MASK;
> 
> As I said earlier. This extra_mem stuff is (maybe) wrong and should be fixed
> in one way or another. Hmmm... It looks OK. I will double check it because
> I do not looked at this code long time and maybe I am missing something.

cfg.size needs to be the size of the trampolines + stack.


>>> No where in the EFI + MB2 code path is cfg.size ever initialized. Its
>>> only initialized in the straight EFI case. The result is that cfg.addr
>>> is set to the section immediately following this. Took a bit to
>>> trackdown because I checked for memory overlaps with where Xen was
>>> loaded and where it was relocated to but forgot to check for overlaps
>>> with the trampoline code. This is the address where the trampoline jumps
>>> are copied.
>>>
>>> Personally I'd like to see an ASSERT added or the code swizzled around
>>> in such a way that its not possible to get into a bad state. But this is
>>> probably another patch series.
>>>
  /* fall through */
  case EfiLoaderCode:
 @@ -210,12 +213,14 @@ static void *__init 
 efi_arch_allocate_mmap_buffer(UINTN map_size)

  static void __init efi_arch_pre_exit_boot(void)
  {
 -if ( !trampoline_phys )
 -{
 -if ( !cfg.addr )
 -blexit(L"No memory for trampoline");
 +if ( trampoline_phys )
 +return;
 +
 +if ( !cfg.addr )
 +blexit(L"No memory for trampoline");
 +
 +if ( efi_enabled(EFI_LOADER) )
  relocate_trampoline(cfg.addr);
>>
>> Why is this call even here anymore? Its called in
>> efi_arch_memory_setup() already. If it was unable to allocate memory
>> under the 1mb region its just going to trample over ANY conventional
>> memory region that might be in use.
> 
> Trampoline is relocated in xen/arch/x86/boot/head.S.

For the MB2/MB case. But for the straight EFI case its called in
efi_arch_memory_setup() and then you've added the wrapper of
efi_enabled(EFI_LOADER) which in theory would have it called again in
the straight EFI case if trampoline_phys isn't set and cfg.addr is set.


> 
 -}
  }

  static void __init noreturn efi_arch_post_exit_boot(void)
 @@ -653,6 +658,43 @@ static bool_t __init 
 efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)

  static void efi_arch_flush_dcache_area(const void *vaddr, UINTN size) { }

 +paddr_t __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
 +{
 +EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
 +UINTN cols, gop_mode = ~0, rows;
 +
 +__set_bit(EFI_BOOT, &efi_flags);
 +__set_bit(EFI_RS, &efi_flags);
 +
 +efi_init(ImageHandle, SystemTable);
 +
 +efi_console_set_mode();
 +
 +if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
 +

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

[Oleksandr Andrushchenko]

I know it is cumbersome, and I might not be a fun of it myself, but it
is required for new Xen protocol changes. I wrote all of the binary
representations manually but if you find a tool to do it, please let me
know :-)

Letting you know ;) there is a project in Python which can do this [1]
I'm going to give it a try

[1] https://github.com/luismartingarcia/protocol


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

Re: [Xen-devel] [PATCH v11 11/13] x86: make Xen early boot code relocatable

[Daniel Kiper]

On Mon, Jan 09, 2017 at 08:05:01PM -0600, Doug Goldstein wrote:
> On 12/5/16 4:25 PM, Daniel Kiper wrote:

[...]

> >  /* Save trampoline address for later use. */
> >  shl $4, %ecx
> > -mov %ecx,sym_phys(trampoline_phys)
> > +mov %ecx,sym_fs(trampoline_phys)
> > +
> > +/* Save Xen image load base address for later use. */
> > +mov %esi,sym_fs(xen_phys_start)
> > +mov %esi,sym_fs(trampoline_xen_phys_start)
> > +
> > +/* Setup stack. %ss was initialized earlier. */
> > +lea 1024+sym_esi(cpu0_stack),%esp
>
> Not sure if this is the bad code or what but after this patch in the
> series the stack is at 0xAD000 which is in the middle of VGA memory so
> the stack is getting screwy (hence my email last week). And the stack is
> bad in trampoline_setup, before trampoline_setup the stack seems fine.
>
> This is from my hacked up version of iPXE...
>
> Type / Addr / Number of Pages / Flags
>
> Conventional: 0x59000 :  69 : f
> Reserved: 0x9e000 :   2 : f
> Conventional: 0x00010 :   65280 : f
>
> As you can see from 0xA to 0x10 isn't mentioned but everything I
> can find on EFI says if the range isn't mentioned you shouldn't use it.

Could you provide full EFI memory map from this machine?

Daniel

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

Re: [Xen-devel] [RFC v2] Xen PV Drivers Lifecycle

[Konrad Rzeszutek Wilk]

On Wed, Jan 11, 2017 at 10:49:15AM -0800, Stefano Stabellini wrote:
> On Wed, 4 Jan 2017, Stefano Stabellini wrote:
> > On Wed, 4 Jan 2017, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jan 04, 2017 at 10:00:01AM -0800, Stefano Stabellini wrote:
> > > > Hi all,
> > > > 
> > > > as you know, we have an issue with the speed of review and acceptance of
> > > > new PV drivers. In a discussion among committers, George wrote an email
> > > > with a short proposal to clarify the development lifecycle of new PV
> > > > drivers and the different expectations at each stage of the process. I
> > > > took that email, polished it and turned it into markdown. Here it is.
> > > > 
> > > > ---
> > > > Acks:
> > > > +1 from Wei Liu
> > > 
> > > +1.
> > > 
> > > Albeit I am concerned about the 
> > > ..
> > > > from one stage to the next within a reasonable time frame unless someone
> > > 
> > > .. of what 'reasonable time' is when somebody is on vacation
> > > or sick.
> > > 
> > > Is it worth spelling that out?
> > 
> > I don't think we should introduce hard time limits, but it should be in
> > terms of few months, not years.
> 
> We have only had positive feedback so far and two explicit +1's. Should
> we call "lazy-consensus" and commit it?

Yes!

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

Re: [Xen-devel] [libvirt] Question about hypervisor that are not tristate

[Konrad Rzeszutek Wilk]

On Wed, Jan 11, 2017 at 10:49:48AM -0700, Jim Fehlig wrote:
> On 01/06/2017 05:31 PM, Jim Fehlig wrote:
> 
> Adding xen-devel for a question below...
> 
> > Happy new year!
> > 
> > Nearly a year ago I reported an issue with the  hypervisor feature on 
> > Xen
> > [1] and am now seeing a similar issue with the  feature. Setting the
> > default value of pae changed between xend and libxl. When not specified, 
> > xend
> > would enable pae for HVM domains. Clients such as xm and the old libvirt 
> > driver
> > did not have to explicitly enable it. In libxl, the pae field within
> > libxl_domain_build_info is initialized to 0. Clients must enable pae, and 
> > indeed
> > xl will do so if pae=1 is not specified in the xl.cfg.
> > 
> > The xend behavior prevents libvirt from disabling pae, whereas the libxl 
> > behvior
> > causes a guest ABI change (config that worked with libvirt+xend doesn't with
> > libvirt+libxl). The libxl behavior also forces management software (e.g.
> > OpenStack nova) to add  where it wasn't needed before.
> > 
> > To solve this problem for , it was changed it to a tristate [2], 
> > allowing
> > it to be turned off with explicit , and on if not 
> > specified or
> >  or . Should  (and the remaining hypervisor 
> > features
> > that are not tristate) be converted to tristate similar to ? 
> > Alternatively,
> > I could simply set pae=1 for all HVM domains in the libxl driver. Like the 
> > old
> > libvirt+xend behavior it couldn't be turned off, but I don't think there is 
> > a
> > practical use-case to do so. At least no one has complained over all the 
> > years
> > of libvirt+xend use.
> 
> Xen folks, what is your opinion of always enabling pae for HVM domains in
> the libvirt libxl driver? Is there a need these days to disable it?

No. I think it should be enabled all the time.
> 
> Jan had mentioned that some old, buggy guest OS's (Win 9x) might need it
> disabled, and perhaps some cases where it may be desirable to suppress a
> guest OS entering 64-bit mode. But in practice do you think it is necessary
> to expose this knob to users?

Um, Win 98? People use that? Microsoft doesn't even support that.

I would ignore such ancient OSes.
> 
> Thanks for your comments!
> 
> Regards,
> Jim
> 
> > [1] https://www.redhat.com/archives/libvir-list/2016-February/msg00197.html
> > [2] https://www.redhat.com/archives/libvir-list/2016-March/msg1.html
> 
> 
> ___
> 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 v11 07/13] x86: add multiboot2 protocol support for EFI platforms

[Doug Goldstein]

On 1/11/17 1:08 PM, Daniel Kiper wrote:
> On Mon, Jan 09, 2017 at 07:37:59PM -0600, Doug Goldstein wrote:
>> On 12/5/16 4:25 PM, Daniel Kiper wrote:
> 
> [...]
> 
>>> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
>>> index 62c010e..dc857d8 100644
>>> --- a/xen/arch/x86/efi/efi-boot.h
>>> +++ b/xen/arch/x86/efi/efi-boot.h
>>> @@ -146,6 +146,8 @@ static void __init 
>>> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>>>  {
>>>  struct e820entry *e;
>>>  unsigned int i;
>>> +/* Check for extra mem for mbi data if Xen is loaded via multiboot2 
>>> protocol. */
>>> +UINTN extra_mem = efi_enabled(EFI_LOADER) ? 0 : (64 << 10);
>>
>> Just wondering where the constant came from? And if there should be a
>> little bit of information about it. To me its just weird to shift 64.
> 
> 64 << 10 == 64 KiB which is the size of trampoline region reserved in
> xen/arch/x86/boot/head.S. Though I think that we should reserve real
> size needed for trampoline code. IIRC, it was discussed here earlier
> but there is no go for it in this patch series.

See my comments below but that's not entirely correct. But yes I would
avoid doing those changes in this series.

> 
>>>  /* Populate E820 table and check trampoline area availability. */
>>>  e = e820map - 1;
>>> @@ -168,7 +170,8 @@ static void __init 
>>> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>>>  /* fall through */
>>>  case EfiConventionalMemory:
>>>  if ( !trampoline_phys && desc->PhysicalStart + len <= 0x10 
>>> &&
>>> - len >= cfg.size && desc->PhysicalStart + len > cfg.addr )
>>> + len >= cfg.size + extra_mem &&
>>> + desc->PhysicalStart + len > cfg.addr )
>>>  cfg.addr = (desc->PhysicalStart + len - cfg.size) & 
>>> PAGE_MASK;
>>
>> So this is where the current series blows up and fails on real hardware.
>> No where in the EFI + MB2 code path is cfg.size ever initialized. Its
>> only initialized in the straight EFI case. The result is that cfg.addr
>> is set to the section immediately following this. Took a bit to
>> trackdown because I checked for memory overlaps with where Xen was
>> loaded and where it was relocated to but forgot to check for overlaps
>> with the trampoline code. This is the address where the trampoline jumps
>> are copied.
>>
>> Personally I'd like to see an ASSERT added or the code swizzled around
>> in such a way that its not possible to get into a bad state. But this is
>> probably another patch series.
> 
> Nice catch! Thanks a lot. I think that we should initialize cfg.size = 64 << 
> 10
> in efi_multiboot2(). It looks like real fix. extra_mem stuff is bogus.
> 

Except in head.S you start the stack 64kb after the end of the
trampoline size. So cfg.size = (64 << 10); won't work. It needs to be
the size of the trampoline + 64k.


>>> +efi_tables();
>>> +setup_efi_pci();
>>> +efi_variables();
>>
>> This is probably where you missed the call to "efi_arch_memory_setup();"
>> that gave me hell above.
> 
> This does not work in MB2 case.

You're looking at the oldest email. I've have further follow ups that
point that out and I've included a patch to fix the issues.

>>
>> So as an aside, IMHO this is where the series should end and the next
>> set of patches should be a follow on.
> 
> Hmmm... Why? If you do not apply rest of patches then MB2 does not
> work on all EFI platforms.
> 
> Daniel
> 

Q: How do you eat an elephant?
A: One bite at a time.

The point is we have 0 MB2 support presently. We can add it in
incremental hunks. Otherwise we get a patch series that's been floating
around for around 3 years and missed at least 2 releases where it should
have gotten in. We've only got several weeks before the 4.9 window
closes as well.

-- 
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 v11 07/13] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Tue, Jan 10, 2017 at 02:51:27PM -0600, Doug Goldstein wrote:
> On 1/9/17 7:37 PM, Doug Goldstein wrote:
> > On 12/5/16 4:25 PM, Daniel Kiper wrote:
>
> >> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> >> index 62c010e..dc857d8 100644
> >> --- a/xen/arch/x86/efi/efi-boot.h
> >> +++ b/xen/arch/x86/efi/efi-boot.h
> >> @@ -146,6 +146,8 @@ static void __init 
> >> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> >>  {
> >>  struct e820entry *e;
> >>  unsigned int i;
> >> +/* Check for extra mem for mbi data if Xen is loaded via multiboot2 
> >> protocol. */
> >> +UINTN extra_mem = efi_enabled(EFI_LOADER) ? 0 : (64 << 10);
> >
> > Just wondering where the constant came from? And if there should be a
> > little bit of information about it. To me its just weird to shift 64.
>
> Its the size of the stack used in the assembly code.

No, it is trampoline region size.

> >>  /* Populate E820 table and check trampoline area availability. */
> >>  e = e820map - 1;
> >> @@ -168,7 +170,8 @@ static void __init 
> >> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> >>  /* fall through */
> >>  case EfiConventionalMemory:
> >>  if ( !trampoline_phys && desc->PhysicalStart + len <= 
> >> 0x10 &&
> >> - len >= cfg.size && desc->PhysicalStart + len > cfg.addr )
> >> + len >= cfg.size + extra_mem &&
> >> + desc->PhysicalStart + len > cfg.addr )
> >>  cfg.addr = (desc->PhysicalStart + len - cfg.size) & 
> >> PAGE_MASK;
> >
> > So this is where the current series blows up and fails on real hardware.
>
> Honestly this was my misunderstanding and this shouldn't ever be used to
> get memory for the trampoline. This also has the bug in it that it needs
> to be:
>
> ASSERT(cfg.size > 0);
> cfg.addr = (desc->PhysicalStart + len - (cfg.size + extra_mem) & PAGE_MASK;

As I said earlier. This extra_mem stuff is (maybe) wrong and should be fixed
in one way or another. Hmmm... It looks OK. I will double check it because
I do not looked at this code long time and maybe I am missing something.

> > No where in the EFI + MB2 code path is cfg.size ever initialized. Its
> > only initialized in the straight EFI case. The result is that cfg.addr
> > is set to the section immediately following this. Took a bit to
> > trackdown because I checked for memory overlaps with where Xen was
> > loaded and where it was relocated to but forgot to check for overlaps
> > with the trampoline code. This is the address where the trampoline jumps
> > are copied.
> >
> > Personally I'd like to see an ASSERT added or the code swizzled around
> > in such a way that its not possible to get into a bad state. But this is
> > probably another patch series.
> >
> >>  /* fall through */
> >>  case EfiLoaderCode:
> >> @@ -210,12 +213,14 @@ static void *__init 
> >> efi_arch_allocate_mmap_buffer(UINTN map_size)
> >>
> >>  static void __init efi_arch_pre_exit_boot(void)
> >>  {
> >> -if ( !trampoline_phys )
> >> -{
> >> -if ( !cfg.addr )
> >> -blexit(L"No memory for trampoline");
> >> +if ( trampoline_phys )
> >> +return;
> >> +
> >> +if ( !cfg.addr )
> >> +blexit(L"No memory for trampoline");
> >> +
> >> +if ( efi_enabled(EFI_LOADER) )
> >>  relocate_trampoline(cfg.addr);
>
> Why is this call even here anymore? Its called in
> efi_arch_memory_setup() already. If it was unable to allocate memory
> under the 1mb region its just going to trample over ANY conventional
> memory region that might be in use.

Trampoline is relocated in xen/arch/x86/boot/head.S.

> >> -}
> >>  }
> >>
> >>  static void __init noreturn efi_arch_post_exit_boot(void)
> >> @@ -653,6 +658,43 @@ static bool_t __init 
> >> efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
> >>
> >>  static void efi_arch_flush_dcache_area(const void *vaddr, UINTN size) { }
> >>
> >> +paddr_t __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> >> *SystemTable)
> >> +{
> >> +EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
> >> +UINTN cols, gop_mode = ~0, rows;
> >> +
> >> +__set_bit(EFI_BOOT, &efi_flags);
> >> +__set_bit(EFI_RS, &efi_flags);
> >> +
> >> +efi_init(ImageHandle, SystemTable);
> >> +
> >> +efi_console_set_mode();
> >> +
> >> +if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
> >> +   &cols, &rows) == EFI_SUCCESS )
> >> +efi_arch_console_init(cols, rows);
> >> +
> >> +gop = efi_get_gop();
> >> +
> >> +if ( gop )
> >> +gop_mode = efi_find_gop_mode(gop, 0, 0, 0);
> >> +
> >> +efi_arch_edd();
> >> +efi_arch_cpu();
> >> +
> >> +efi_tables();
> >> +setup_efi_pci();
> >> +efi_variables();
> >
> > This is probably where you missed the call to "efi_arch_memory_setup();"
> > that gave me hell above.
>
> Well it turns out that calling "efi_arch_memory_setup()" is

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

[osstest service owner]

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

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  0d045d65c19ac48b31344b566cbf82a0270e6e44
baseline version:
 xen  14a6be89ec04bfadba978dc4c2f1e7f96db8cdf0

Last test of basis   104125  2017-01-11 15:01:20 Z0 days
Testing same since   104127  2017-01-11 17:01:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  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=0d045d65c19ac48b31344b566cbf82a0270e6e44
+ . ./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 
0d045d65c19ac48b31344b566cbf82a0270e6e44
+ branch=xen-unstable-smoke
+ revision=0d045d65c19ac48b31344b566cbf82a0270e6e44
+ . ./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
+ '[' x0d045d65c19ac48b31344b566cbf82a0270e6e44 = 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/

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Mon, Jan 09, 2017 at 07:37:59PM -0600, Doug Goldstein wrote:
> On 12/5/16 4:25 PM, Daniel Kiper wrote:

[...]

> > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> > index 62c010e..dc857d8 100644
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
> > @@ -146,6 +146,8 @@ static void __init 
> > efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> >  {
> >  struct e820entry *e;
> >  unsigned int i;
> > +/* Check for extra mem for mbi data if Xen is loaded via multiboot2 
> > protocol. */
> > +UINTN extra_mem = efi_enabled(EFI_LOADER) ? 0 : (64 << 10);
>
> Just wondering where the constant came from? And if there should be a
> little bit of information about it. To me its just weird to shift 64.

64 << 10 == 64 KiB which is the size of trampoline region reserved in
xen/arch/x86/boot/head.S. Though I think that we should reserve real
size needed for trampoline code. IIRC, it was discussed here earlier
but there is no go for it in this patch series.

> >  /* Populate E820 table and check trampoline area availability. */
> >  e = e820map - 1;
> > @@ -168,7 +170,8 @@ static void __init 
> > efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> >  /* fall through */
> >  case EfiConventionalMemory:
> >  if ( !trampoline_phys && desc->PhysicalStart + len <= 0x10 
> > &&
> > - len >= cfg.size && desc->PhysicalStart + len > cfg.addr )
> > + len >= cfg.size + extra_mem &&
> > + desc->PhysicalStart + len > cfg.addr )
> >  cfg.addr = (desc->PhysicalStart + len - cfg.size) & 
> > PAGE_MASK;
>
> So this is where the current series blows up and fails on real hardware.
> No where in the EFI + MB2 code path is cfg.size ever initialized. Its
> only initialized in the straight EFI case. The result is that cfg.addr
> is set to the section immediately following this. Took a bit to
> trackdown because I checked for memory overlaps with where Xen was
> loaded and where it was relocated to but forgot to check for overlaps
> with the trampoline code. This is the address where the trampoline jumps
> are copied.
>
> Personally I'd like to see an ASSERT added or the code swizzled around
> in such a way that its not possible to get into a bad state. But this is
> probably another patch series.

Nice catch! Thanks a lot. I think that we should initialize cfg.size = 64 << 10
in efi_multiboot2(). It looks like real fix. extra_mem stuff is bogus.

[...]

> > +paddr_t __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> > *SystemTable)
> > +{
> > +EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
> > +UINTN cols, gop_mode = ~0, rows;
> > +
> > +__set_bit(EFI_BOOT, &efi_flags);
> > +__set_bit(EFI_RS, &efi_flags);
> > +
> > +efi_init(ImageHandle, SystemTable);
> > +
> > +efi_console_set_mode();
> > +
> > +if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
> > +   &cols, &rows) == EFI_SUCCESS )
> > +efi_arch_console_init(cols, rows);
> > +
> > +gop = efi_get_gop();
> > +
> > +if ( gop )
> > +gop_mode = efi_find_gop_mode(gop, 0, 0, 0);
> > +
> > +efi_arch_edd();
> > +efi_arch_cpu();
> > +
> > +efi_tables();
> > +setup_efi_pci();
> > +efi_variables();
>
> This is probably where you missed the call to "efi_arch_memory_setup();"
> that gave me hell above.

This does not work in MB2 case.

[...]

> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > index 0a93e61..70ed836 100644
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -79,6 +79,17 @@ static size_t wstrlen(const CHAR16 * s);
> >  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
> >  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
> >
> > +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> > *SystemTable);
> > +static void efi_console_set_mode(void);
> > +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
> > +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> > +   UINTN cols, UINTN rows, UINTN depth);
> > +static void efi_tables(void);
> > +static void setup_efi_pci(void);
> > +static void efi_variables(void);
> > +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN 
> > gop_mode);
> > +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> > *SystemTable);
> > +
> >  static const EFI_BOOT_SERVICES *__initdata efi_bs;
> >  static UINT32 __initdata efi_bs_revision;
> >  static EFI_HANDLE __initdata efi_ih;
> >
>
> So as an aside, IMHO this is where the series should end and the next
> set of patches should be a follow on.

Hmmm... Why? If you do not apply rest of patches then MB2 does not
work on all EFI platforms.

Daniel

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

Re: [Xen-devel] [RFC v2] Xen PV Drivers Lifecycle

[Stefano Stabellini]

On Wed, 4 Jan 2017, Stefano Stabellini wrote:
> On Wed, 4 Jan 2017, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 04, 2017 at 10:00:01AM -0800, Stefano Stabellini wrote:
> > > Hi all,
> > > 
> > > as you know, we have an issue with the speed of review and acceptance of
> > > new PV drivers. In a discussion among committers, George wrote an email
> > > with a short proposal to clarify the development lifecycle of new PV
> > > drivers and the different expectations at each stage of the process. I
> > > took that email, polished it and turned it into markdown. Here it is.
> > > 
> > > ---
> > > Acks:
> > > +1 from Wei Liu
> > 
> > +1.
> > 
> > Albeit I am concerned about the 
> > ..
> > > from one stage to the next within a reasonable time frame unless someone
> > 
> > .. of what 'reasonable time' is when somebody is on vacation
> > or sick.
> > 
> > Is it worth spelling that out?
> 
> I don't think we should introduce hard time limits, but it should be in
> terms of few months, not years.

We have only had positive feedback so far and two explicit +1's. Should
we call "lazy-consensus" and commit it?

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

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

[Stefano Stabellini]

On Wed, 11 Jan 2017, Dan Streetman wrote:
> On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
>  wrote:
> > On Tue, 10 Jan 2017, Dan Streetman wrote:
> >> On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
> >>  wrote:
> >> > On Tue, 10 Jan 2017, Dan Streetman wrote:
> >> >> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman  
> >> >> wrote:
> >> >> > On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
> >> >> >  wrote:
> >> >> >> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
> >> >> >>> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
> >> >> >>> > On Mon, Jan 9, 2017 at 9:59 AM, Boris Ostrovsky
> >> >> >>> >  wrote:
> >> >> >>> > > On 01/06/2017 08:06 PM, Konrad Rzeszutek Wilk wrote:
> >> >> >>> > >> On Thu, Jan 05, 2017 at 02:28:56PM -0500, Dan Streetman wrote:
> >> >> >>> > >>> 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.
> >> >> >>> > >> Won't this cause a starvation problem? That is we will run out 
> >> >> >>> > >> of PIRQs
> >> >> >>> > >> as we are not reusing them?
> >> >> >>> > >
> >> >> >>> > > Don't we free the pirq when we unmap it?
> >> >> >>> >
> >> >> >>> > I think this is actually a bit worse than I initially thought.  
> >> >> >>> > After
> >> >> >>> > looking a bit closer, and I think there's an asymmetry with pirq
> >> >> >>> > allocation:
> >> >> >>>
> >> >> >>> Lets include Stefano,
> >> >> >>>
> >> >> >>> Thank you for digging in this! This has quite the deja-vu
> >> >> >>> feeling as I believe I hit this at some point in the past and
> >> >> >>> posted some possible ways of fixing this. But sadly I can't
> >> >> >>> find the thread.
> >> >> >>
> >> >> >> This issue seems to be caused by:
> >> >> >>
> >> >> >> commit af42b8d12f8adec6711cb824549a0edac6a4ae8f
> >> >> >> Author: Stefano Stabellini 
> >> >> >> Date:   Wed Dec 1 14:51:44 2010 +
> >> >> >>
> >> >> >> xen: fix MSI setup and teardown for PV on HVM guests
> >> >> >>
> >> >> >> which was a fix to a bug:
> >> >> >>
> >> >> >> This fixes a bug in xen_hvm_setup_msi_irqs that manifests itself 
> >> >> >> when
> >> >> >> trying to enable the same MSI for the second time: the old MSI 
> >> >> >> to pirq
> >> >> >> mapping is still valid at this point but xen_hvm_setup_msi_irqs 
> >> >> >> would
> >> >> >> try to assign a new pirq anyway.
> >> >> >> A simple way to reproduce this bug is to assign an MSI capable 
> >> >> >> network
> >> >> >> card to a PV on HVM guest, if the user brings down the 
> >> >> >> corresponding
> >> >> >> ethernet interface and up again, Linux would fail to enable MSIs 
> >> >> >> on the
> >> >> >> device.
> >> >> >>
> >> >> >> I don't remember any of the details. From the description of this 
> >> >> >> bug,
> >> >> >> it seems that Xen changed behavior in the past few years: before it 
> >> >> >> used
> >> >> >> to keep the pirq-MSI mapping, while today it doesn't. If I wrote "the
> >> >> >> old MSI to pirq mapping is still valid at this point", the pirq 
> >> >> >> couldn't
> >> >> >> have been completely freed, then reassigned to somebody else the way 
> >> >> >> it
> >> >> >> is described in this email.
> >> >> >>
> >> >> >> I think we should indentify the changeset or Xen version that 
> >> >> >> introduced
> >> >> >> the new behavior. If it is old enough, we might be able to just 
> >> >> >> revert
> >> >> >> af42b8d12f8adec6711cb824549a0edac6a4ae8f. Otherwise we could make the
> >> >> >> behavior conditional to the Xen version.
> >> >> >
> >> >> > Are PT devices the only MSI-capable devices available in a Xen guest?
> >> >> > That's where I'm seeing this problem, with PT NVMe devices.
> >> >
> >> > They are the main ones. It is possible to have emulated virtio devices
> >> > with emulated MSIs, for example virtio-net. Althought they are not in
> >> > the Xen Project CI-loop, so I wouldn't be surprised if they are broken
> >> > too.
> >> >
> >> >
> >> >> > I can say that on the Xen guest with NVMe PT devices I'm testing on,
> >> >> > with the patch from this thread (which essentially reverts your commit
> >> >> > above) as well as some added debug to see the pirq numbers, cycles of
> >> >> > 'modprobe nvme ; rmmod nvme' don't cause pirq starvation, as the
> >> >> > hypervisor provides essentially the same pirqs for each modprobe,
> >> >> > since they were freed by the rmmod.
> >> >
> >> > I am fine with reverting the old patch, but we need to understand what
> >> > caused the change in behavior first. Maybe somebody else with a Xen PCI
> >> > passthrough setup at hand can help with that.
> >> >
> >> > In the Xen code I can still see:
> >> >
> >> >   

Re: [Xen-devel] [PATCH 1/2] xen/kbdif: update protocol documentation

[Oleksandr Andrushchenko]

On 01/11/2017 07:35 PM, Dario Faggioli wrote:

On Tue, 2017-01-10 at 09:21 +0200, Oleksandr Andrushchenko wrote:

On 01/07/2017 12:20 AM, Stefano Stabellini wrote:

On Fri, 6 Jan 2017, Oleksandr Andrushchenko wrote:

|   reserved
|
+ * +-+-+-+
-+
+ *
|/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/|
+ * +-+-+-+
-+

I guess this means that we are skipping some bytes because they are
all
reserved, right?  If so, it would be useful to write the byte count
at this
point. What's the total size of the event struct?


IMO, we shouldn't put any sizes here because:
1. Above we say "All event packets have the same
 length (40 octets)"
2. All the event structures are part of the
union xenkbd_in_event, which has
char pad[XENKBD_IN_EVENT_SIZE];
which effectively regulates the size of the event.


In which case, you can use either 40 or XENKBD_IN_EVENT_SIZE (probably
the latter).

It's indeed a repetition, but a good one, IMO: it helps the reader, as
she won't have to go back to figure out how big the struct was, how the
macro was call and to what value it was defined).

I am still not convinced that we should put it.
Probably we can go the way other RFCs do, like TCP [1], 802.11 [2] etc:
those do not define any reserved fields at the bottom of structures,
(which are effectively padding?) but are limited to only those fields
which are defined. This means that, for example, instead of

 *  0 1  2 3octet
 * 
+-+-+-+-+

 * |   _TYPE_MOTION  | reserved  |
 * 
+-+-+-+-+

 * | rel_x |
 * 
+-+-+-+-+

 * | rel_y |
 * 
+-+-+-+-+

 * | rel_z |
 * 
+-+-+-+-+

 * | reserved|
 * 
+-+-+-+-+
 * 
|/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
 * 
+-+-+-+-+

 * | reserved|
 * 
+-+-+-+-+


simply put

 *  0 1  2 3octet
 * 
+-+-+-+-+

 * |   _TYPE_MOTION  | reserved  |
 * 
+-+-+-+-+

 * | rel_x |
 * 
+-+-+-+-+

 * | rel_y |
 * 
+-+-+-+-+

 * | rel_z |
 * 
+-+-+-+-+


What do you think?


[1] https://www.ietf.org/rfc/rfc793.txt
[2] https://tools.ietf.org/html/rfc5416

Regards,
Dario

Thank you,
Oleksandr

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

Re: [Xen-devel] [Linux-c6x-dev] [PATCH v2 7/7] uapi: export all headers under uapi directories

[Mark Salter]

On Fri, 2017-01-06 at 10:43 +0100, Nicolas Dichtel wrote:
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
> 
> In fact, all headers under uapi directories should be exported, thus it's
> useless to have an exhaustive list.
> 
> After this patch, the following files, which were not exported, are now
> exported (with make headers_install_all):
> asm-unicore32/shmparam.h
> asm-unicore32/ucontext.h
> asm-hexagon/shmparam.h
> asm-mips/ucontext.h
> asm-mips/hwcap.h
> asm-mips/reg.h
> drm/vgem_drm.h
> drm/armada_drm.h
> drm/omap_drm.h
> drm/etnaviv_drm.h
> asm-tile/shmparam.h
> asm-blackfin/shmparam.h
> asm-blackfin/ucontext.h
> asm-powerpc/perf_regs.h
> rdma/qedr-abi.h
> asm-parisc/kvm_para.h
> asm-openrisc/shmparam.h
> asm-nios2/kvm_para.h
> asm-nios2/ucontext.h
> asm-sh/kvm_para.h
> asm-sh/ucontext.h
> asm-xtensa/kvm_para.h
> asm-avr32/kvm_para.h
> asm-m32r/kvm_para.h
> asm-h8300/shmparam.h
> asm-h8300/ucontext.h
> asm-metag/kvm_para.h
> asm-metag/shmparam.h
> asm-metag/ucontext.h
> asm-m68k/kvm_para.h
> asm-m68k/shmparam.h
> linux/bcache.h
> linux/kvm.h
> linux/kvm_para.h
> linux/kfd_ioctl.h
> linux/cryptouser.h
> linux/kcm.h
> linux/kcov.h
> linux/seg6_iptunnel.h
> linux/stm.h
> linux/genwqe
> linux/genwqe/.install
> linux/genwqe/genwqe_card.h
> linux/genwqe/..install.cmd
> linux/seg6.h
> linux/cifs
> linux/cifs/.install
> linux/cifs/cifs_mount.h
> linux/cifs/..install.cmd
> linux/auto_dev-ioctl.h
> 
> Thanks to Julien Floret  for the tip to get all
> subdirs with a pure makefile command.
> 
> Signed-off-by: Nicolas Dichtel 
> ---
>  Documentation/kbuild/makefiles.txt  |  41 ++-
>  arch/alpha/include/uapi/asm/Kbuild  |  41 ---
>  arch/arc/include/uapi/asm/Kbuild|   3 -
>  arch/arm/include/uapi/asm/Kbuild|  17 -
>  arch/arm64/include/uapi/asm/Kbuild  |  18 --
>  arch/avr32/include/uapi/asm/Kbuild  |  20 --
>  arch/blackfin/include/uapi/asm/Kbuild   |  17 -
>  arch/c6x/include/uapi/asm/Kbuild|   8 -
>  arch/cris/include/uapi/arch-v10/arch/Kbuild |   5 -
>  arch/cris/include/uapi/arch-v32/arch/Kbuild |   3 -
>  arch/cris/include/uapi/asm/Kbuild   |  43 +--
>  arch/frv/include/uapi/asm/Kbuild|  33 --
>  arch/h8300/include/uapi/asm/Kbuild  |  28 --
>  arch/hexagon/include/asm/Kbuild |   3 -
>  arch/hexagon/include/uapi/asm/Kbuild|  13 -
>  arch/ia64/include/uapi/asm/Kbuild   |  45 ---
>  arch/m32r/include/uapi/asm/Kbuild   |  31 --
>  arch/m68k/include/uapi/asm/Kbuild   |  24 --
>  arch/metag/include/uapi/asm/Kbuild  |   8 -
>  arch/microblaze/include/uapi/asm/Kbuild |  32 --
>  arch/mips/include/uapi/asm/Kbuild   |  37 ---
>  arch/mn10300/include/uapi/asm/Kbuild|  32 --
>  arch/nios2/include/uapi/asm/Kbuild  |   4 +-
>  arch/openrisc/include/asm/Kbuild|   3 -
>  arch/openrisc/include/uapi/asm/Kbuild   |   8 -
>  arch/parisc/include/uapi/asm/Kbuild |  28 --
>  arch/powerpc/include/uapi/asm/Kbuild|  45 ---
>  arch/s390/include/uapi/asm/Kbuild   |  52 ---
>  arch/score/include/asm/Kbuild   |   4 -
>  arch/score/include/uapi/asm/Kbuild  |  32 --
>  arch/sh/include/uapi/asm/Kbuild |  23 --
>  arch/sparc/include/uapi/asm/Kbuild  |  48 ---
>  arch/tile/include/asm/Kbuild|   3 -
>  arch/tile/include/uapi/arch/Kbuild  |  17 -
>  arch/tile/include/uapi/asm/Kbuild   |  19 +-
>  arch/unicore32/include/uapi/asm/Kbuild  |   6 -
>  arch/x86/include/uapi/asm/Kbuild|  59 
>  arch/xtensa/include/uapi/asm/Kbuild |  23 --
>  include/Kbuild  |   2 -
>  include/asm-generic/Kbuild.asm  |   1 -
>  include/scsi/fc/Kbuild  |   0
>  include/uapi/Kbuild |  15 -
>  include/uapi/asm-generic/Kbuild |  36 ---
>  include/uapi/asm-generic/Kbuild.asm |  62 ++--
>  include/uapi/drm/Kbuild |  22 --
>  include/uapi/linux/Kbuild   | 482 
> 
>  include/uapi/linux/android/Kbuild   |   2 -
>  include/uapi/linux/byteorder/Kbuild |   3 -
>  include/uapi/linux/caif/Kbuild  |   3 -
>  include/uapi/linux/can/Kbuild   |   6 -
>  include/uapi/linux/dvb/Kbuild   |   9 -
>  include/uapi/linux/hdlc/Kbuild  |   2 -
>  include/uapi/linux/hsi/Kbuild   |   2 -
>  include/uapi/linux/iio/Kbuild   |   3 -
>  include/uapi/linux/isdn/Kbuild  |   2 -
>  include/uapi/linux/mmc/Kbuild   |   2 -
>  include/uapi/linux/netfilter/Kbuild |  89 -
>  include/uapi/linux/netfilter/ipset/Kbuild   |   5 -
>  include/uapi/linux/netfilter_arp/Kbuild  

Re: [Xen-devel] [libvirt] Question about hypervisor that are not tristate

[Jim Fehlig]

On 01/11/2017 10:55 AM, Daniel P. Berrange wrote:

On Wed, Jan 11, 2017 at 10:49:48AM -0700, Jim Fehlig wrote:

On 01/06/2017 05:31 PM, Jim Fehlig wrote:

Adding xen-devel for a question below...


Happy new year!

Nearly a year ago I reported an issue with the  hypervisor feature on Xen
[1] and am now seeing a similar issue with the  feature. Setting the
default value of pae changed between xend and libxl. When not specified, xend
would enable pae for HVM domains. Clients such as xm and the old libvirt driver
did not have to explicitly enable it. In libxl, the pae field within
libxl_domain_build_info is initialized to 0. Clients must enable pae, and indeed
xl will do so if pae=1 is not specified in the xl.cfg.

The xend behavior prevents libvirt from disabling pae, whereas the libxl behvior
causes a guest ABI change (config that worked with libvirt+xend doesn't with
libvirt+libxl). The libxl behavior also forces management software (e.g.
OpenStack nova) to add  where it wasn't needed before.

To solve this problem for , it was changed it to a tristate [2], allowing
it to be turned off with explicit , and on if not specified or
 or . Should  (and the remaining hypervisor features
that are not tristate) be converted to tristate similar to ? Alternatively,
I could simply set pae=1 for all HVM domains in the libxl driver. Like the old
libvirt+xend behavior it couldn't be turned off, but I don't think there is a
practical use-case to do so. At least no one has complained over all the years
of libvirt+xend use.


Xen folks, what is your opinion of always enabling pae for HVM domains in
the libvirt libxl driver? Is there a need these days to disable it?

Jan had mentioned that some old, buggy guest OS's (Win 9x) might need it
disabled, and perhaps some cases where it may be desirable to suppress a
guest OS entering 64-bit mode. But in practice do you think it is necessary
to expose this knob to users?


If the guest arch is declared as x86_64, then you should unconditionally
force 'pae' to be present, otherwise you'd be giving the guest an i686
environment.


Right.


The app should request arch == i686 explicitly if they
want an i686 environment. Allowing pae to be toggled for i686 guests
is ok, since that indicates whethre the i686 CPU can address > 2GB
of RAM.


Good point. I'll look into a patch implementing this logic.

Regards,
Jim


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

Re: [Xen-devel] [libvirt] Question about hypervisor that are not tristate

[Jim Fehlig]

On 01/11/2017 11:00 AM, Andrew Cooper wrote:

On 11/01/17 17:49, Jim Fehlig wrote:

On 01/06/2017 05:31 PM, Jim Fehlig wrote:

Adding xen-devel for a question below...


Happy new year!

Nearly a year ago I reported an issue with the  hypervisor
feature on Xen
[1] and am now seeing a similar issue with the  feature. Setting
the
default value of pae changed between xend and libxl. When not
specified, xend
would enable pae for HVM domains. Clients such as xm and the old
libvirt driver
did not have to explicitly enable it. In libxl, the pae field within
libxl_domain_build_info is initialized to 0. Clients must enable pae,
and indeed
xl will do so if pae=1 is not specified in the xl.cfg.

The xend behavior prevents libvirt from disabling pae, whereas the
libxl behvior
causes a guest ABI change (config that worked with libvirt+xend
doesn't with
libvirt+libxl). The libxl behavior also forces management software (e.g.
OpenStack nova) to add  where it wasn't needed before.

To solve this problem for , it was changed it to a tristate [2],
allowing
it to be turned off with explicit , and on if not
specified or
 or . Should  (and the remaining
hypervisor features
that are not tristate) be converted to tristate similar to ?
Alternatively,
I could simply set pae=1 for all HVM domains in the libxl driver.
Like the old
libvirt+xend behavior it couldn't be turned off, but I don't think
there is a
practical use-case to do so. At least no one has complained over all
the years
of libvirt+xend use.


Xen folks, what is your opinion of always enabling pae for HVM domains
in the libvirt libxl driver? Is there a need these days to disable it?

Jan had mentioned that some old, buggy guest OS's (Win 9x) might need
it disabled, and perhaps some cases where it may be desirable to
suppress a guest OS entering 64-bit mode. But in practice do you think
it is necessary to expose this knob to users?


ISTR the main use of this knob being to cause 32bit versions of windows
to avoid using PAE paging, making them more efficient to shadow.

Now that 64bit and EPT/NPT are fairly ubiquitous, there should be no
reason to turn it off.


Okay, thanks.



Can people still play with the CPUID policy if they really need to
disable it?


ATM, not through libvirt. We still have some work to do in this area.


It is unfortunate that this option was ever exposed via a
non-CPUID mechanism, but I am trying to clean this up at the hypervisor
interface to ensure that the *only* way to alter details like this is
via the appropriate interface.


And we'll need to make use of this interface in libvirt.

Regards,
Jim


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

Re: [Xen-devel] [libvirt] Question about hypervisor that are not tristate

[Andrew Cooper]

On 11/01/17 17:49, Jim Fehlig wrote:
> On 01/06/2017 05:31 PM, Jim Fehlig wrote:
>
> Adding xen-devel for a question below...
>
>> Happy new year!
>>
>> Nearly a year ago I reported an issue with the  hypervisor
>> feature on Xen
>> [1] and am now seeing a similar issue with the  feature. Setting
>> the
>> default value of pae changed between xend and libxl. When not
>> specified, xend
>> would enable pae for HVM domains. Clients such as xm and the old
>> libvirt driver
>> did not have to explicitly enable it. In libxl, the pae field within
>> libxl_domain_build_info is initialized to 0. Clients must enable pae,
>> and indeed
>> xl will do so if pae=1 is not specified in the xl.cfg.
>>
>> The xend behavior prevents libvirt from disabling pae, whereas the
>> libxl behvior
>> causes a guest ABI change (config that worked with libvirt+xend
>> doesn't with
>> libvirt+libxl). The libxl behavior also forces management software (e.g.
>> OpenStack nova) to add  where it wasn't needed before.
>>
>> To solve this problem for , it was changed it to a tristate [2],
>> allowing
>> it to be turned off with explicit , and on if not
>> specified or
>>  or . Should  (and the remaining
>> hypervisor features
>> that are not tristate) be converted to tristate similar to ?
>> Alternatively,
>> I could simply set pae=1 for all HVM domains in the libxl driver.
>> Like the old
>> libvirt+xend behavior it couldn't be turned off, but I don't think
>> there is a
>> practical use-case to do so. At least no one has complained over all
>> the years
>> of libvirt+xend use.
>
> Xen folks, what is your opinion of always enabling pae for HVM domains
> in the libvirt libxl driver? Is there a need these days to disable it?
>
> Jan had mentioned that some old, buggy guest OS's (Win 9x) might need
> it disabled, and perhaps some cases where it may be desirable to
> suppress a guest OS entering 64-bit mode. But in practice do you think
> it is necessary to expose this knob to users?

ISTR the main use of this knob being to cause 32bit versions of windows
to avoid using PAE paging, making them more efficient to shadow.

Now that 64bit and EPT/NPT are fairly ubiquitous, there should be no
reason to turn it off.

Can people still play with the CPUID policy if they really need to
disable it?  It is unfortunate that this option was ever exposed via a
non-CPUID mechanism, but I am trying to clean this up at the hypervisor
interface to ensure that the *only* way to alter details like this is
via the appropriate interface.

~Andrew

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

[Xen-devel] [PATCH] x86/sysctl: Fix NULL pointer dereference in error path

[Andrew Cooper]

This was introduced by c/s c38869e711 "x86/cpuid: Drop the temporary linear
feature bitmap from struct cpuid_policy", and caught by Coverity.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/sysctl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 87da541..274ca0c 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -229,7 +229,10 @@ long arch_do_sysctl(
 
 /* Bad featureset index? */
 if ( !p )
+{
 ret = -EINVAL;
+break;
+}
 
 cpuid_policy_to_featureset(p, featureset);
 
-- 
2.1.4


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

Re: [Xen-devel] Granularity of Credit and RTDS Scheduler

[wy11]

Thank you very much.I really appreciate your help.

Best Regards,

Wenqiu

Quoting Dario Faggioli :


On Tue, 2017-01-10 at 15:32 -0600, wy11 wrote:

If the time granularity of RTDS is nanosecond, then it is no longer
a  
problem. Can you please help me to know where I can find it in the  
source code?


If that's what you're interested in, time granularity is nanoseconds
for each and every scheduler.

Look at xen/common/schedule.c, xen/common/sched_credit.c,
xen/common/sched_credit2.c and xen/common/sched_rt.c, and see how they
all use the NOW() macro for reading time.

Then go checking how NOW() is defined.

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





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

Re: [Xen-devel] [libvirt] Question about hypervisor that are not tristate

[Daniel P. Berrange]

On Wed, Jan 11, 2017 at 10:49:48AM -0700, Jim Fehlig wrote:
> On 01/06/2017 05:31 PM, Jim Fehlig wrote:
> 
> Adding xen-devel for a question below...
> 
> > Happy new year!
> > 
> > Nearly a year ago I reported an issue with the  hypervisor feature on 
> > Xen
> > [1] and am now seeing a similar issue with the  feature. Setting the
> > default value of pae changed between xend and libxl. When not specified, 
> > xend
> > would enable pae for HVM domains. Clients such as xm and the old libvirt 
> > driver
> > did not have to explicitly enable it. In libxl, the pae field within
> > libxl_domain_build_info is initialized to 0. Clients must enable pae, and 
> > indeed
> > xl will do so if pae=1 is not specified in the xl.cfg.
> > 
> > The xend behavior prevents libvirt from disabling pae, whereas the libxl 
> > behvior
> > causes a guest ABI change (config that worked with libvirt+xend doesn't with
> > libvirt+libxl). The libxl behavior also forces management software (e.g.
> > OpenStack nova) to add  where it wasn't needed before.
> > 
> > To solve this problem for , it was changed it to a tristate [2], 
> > allowing
> > it to be turned off with explicit , and on if not 
> > specified or
> >  or . Should  (and the remaining hypervisor 
> > features
> > that are not tristate) be converted to tristate similar to ? 
> > Alternatively,
> > I could simply set pae=1 for all HVM domains in the libxl driver. Like the 
> > old
> > libvirt+xend behavior it couldn't be turned off, but I don't think there is 
> > a
> > practical use-case to do so. At least no one has complained over all the 
> > years
> > of libvirt+xend use.
> 
> Xen folks, what is your opinion of always enabling pae for HVM domains in
> the libvirt libxl driver? Is there a need these days to disable it?
> 
> Jan had mentioned that some old, buggy guest OS's (Win 9x) might need it
> disabled, and perhaps some cases where it may be desirable to suppress a
> guest OS entering 64-bit mode. But in practice do you think it is necessary
> to expose this knob to users?

If the guest arch is declared as x86_64, then you should unconditionally
force 'pae' to be present, otherwise you'd be giving the guest an i686
environment.  The app should request arch == i686 explicitly if they
want an i686 environment. Allowing pae to be toggled for i686 guests
is ok, since that indicates whethre the i686 CPU can address > 2GB
of RAM.



Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

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

Re: [Xen-devel] [libvirt] Question about hypervisor that are not tristate

[Jim Fehlig]

On 01/06/2017 05:31 PM, Jim Fehlig wrote:

Adding xen-devel for a question below...


Happy new year!

Nearly a year ago I reported an issue with the  hypervisor feature on Xen
[1] and am now seeing a similar issue with the  feature. Setting the
default value of pae changed between xend and libxl. When not specified, xend
would enable pae for HVM domains. Clients such as xm and the old libvirt driver
did not have to explicitly enable it. In libxl, the pae field within
libxl_domain_build_info is initialized to 0. Clients must enable pae, and indeed
xl will do so if pae=1 is not specified in the xl.cfg.

The xend behavior prevents libvirt from disabling pae, whereas the libxl behvior
causes a guest ABI change (config that worked with libvirt+xend doesn't with
libvirt+libxl). The libxl behavior also forces management software (e.g.
OpenStack nova) to add  where it wasn't needed before.

To solve this problem for , it was changed it to a tristate [2], allowing
it to be turned off with explicit , and on if not specified or
 or . Should  (and the remaining hypervisor features
that are not tristate) be converted to tristate similar to ? Alternatively,
I could simply set pae=1 for all HVM domains in the libxl driver. Like the old
libvirt+xend behavior it couldn't be turned off, but I don't think there is a
practical use-case to do so. At least no one has complained over all the years
of libvirt+xend use.


Xen folks, what is your opinion of always enabling pae for HVM domains in the 
libvirt libxl driver? Is there a need these days to disable it?


Jan had mentioned that some old, buggy guest OS's (Win 9x) might need it 
disabled, and perhaps some cases where it may be desirable to suppress a guest 
OS entering 64-bit mode. But in practice do you think it is necessary to expose 
this knob to users?


Thanks for your comments!

Regards,
Jim


[1] https://www.redhat.com/archives/libvir-list/2016-February/msg00197.html
[2] https://www.redhat.com/archives/libvir-list/2016-March/msg1.html



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

[Xen-devel] [PATCH 4/4] x86/cpuid: Move the legacy cpuids array into struct cpuid_policy

[Andrew Cooper]

This hides the legacy details inside the cpuid subsystem, where they will
eventually be dropped entirely.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/cpuid.c | 10 +-
 xen/arch/x86/domain.c| 14 +-
 xen/arch/x86/domctl.c|  4 ++--
 xen/include/asm-x86/cpuid.h  |  4 
 xen/include/asm-x86/domain.h |  5 -
 5 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index e173ff7..20cb25b 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -338,6 +338,8 @@ void recalculate_cpuid_policy(struct domain *d)
 
 int init_domain_cpuid_policy(struct domain *d)
 {
+unsigned int i;
+
 d->arch.cpuid = xmalloc(struct cpuid_policy);
 
 if ( !d->arch.cpuid )
@@ -347,6 +349,12 @@ int init_domain_cpuid_policy(struct domain *d)
 
 recalculate_cpuid_policy(d);
 
+for ( i = 0; i < MAX_CPUID_INPUT; i++ )
+{
+d->arch.cpuid->legacy[i].input[0] = XEN_CPUID_INPUT_UNUSED;
+d->arch.cpuid->legacy[i].input[1] = XEN_CPUID_INPUT_UNUSED;
+}
+
 return 0;
 }
 
@@ -357,7 +365,7 @@ static void domain_cpuid(const struct domain *d, uint32_t 
leaf,
 
 for ( i = 0; i < MAX_CPUID_INPUT; i++ )
 {
-cpuid_input_t *cpuid = &d->arch.cpuids[i];
+xen_domctl_cpuid_t *cpuid = &d->arch.cpuid->legacy[i];
 
 if ( (cpuid->input[0] == leaf) &&
  ((cpuid->input[1] == XEN_CPUID_INPUT_UNUSED) ||
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 6fc1242..44ee92a 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -503,7 +503,7 @@ static bool emulation_flags_ok(const struct domain *d, 
uint32_t emflags)
 int arch_domain_create(struct domain *d, unsigned int domcr_flags,
struct xen_arch_domainconfig *config)
 {
-int i, paging_initialised = 0;
+int paging_initialised = 0;
 int rc = -ENOMEM;
 
 if ( config == NULL && !is_idle_domain(d) )
@@ -606,16 +606,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( (rc = init_domain_cpuid_policy(d)) )
 goto fail;
 
-d->arch.cpuids = xmalloc_array(cpuid_input_t, MAX_CPUID_INPUT);
-rc = -ENOMEM;
-if ( d->arch.cpuids == NULL )
-goto fail;
-for ( i = 0; i < MAX_CPUID_INPUT; i++ )
-{
-d->arch.cpuids[i].input[0] = XEN_CPUID_INPUT_UNUSED;
-d->arch.cpuids[i].input[1] = XEN_CPUID_INPUT_UNUSED;
-}
-
 d->arch.x86_vendor = boot_cpu_data.x86_vendor;
 d->arch.x86= boot_cpu_data.x86;
 d->arch.x86_model  = boot_cpu_data.x86_model;
@@ -678,7 +668,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 iommu_domain_destroy(d);
 cleanup_domain_irq_mapping(d);
 free_xenheap_page(d->shared_info);
-xfree(d->arch.cpuids);
 xfree(d->arch.cpuid);
 if ( paging_initialised )
 paging_final_teardown(d);
@@ -697,7 +686,6 @@ void arch_domain_destroy(struct domain *d)
 hvm_domain_destroy(d);
 
 xfree(d->arch.e820);
-xfree(d->arch.cpuids);
 xfree(d->arch.cpuid);
 
 free_domain_pirqs(d);
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 038521a..772c5d2 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -51,13 +51,13 @@ static int gdbsx_guest_mem_io(domid_t domid, struct 
xen_domctl_gdbsx_memio *iop)
 static int update_legacy_cpuid_array(struct domain *d,
  const xen_domctl_cpuid_t *ctl)
 {
-cpuid_input_t *cpuid, *unused = NULL;
+xen_domctl_cpuid_t *cpuid, *unused = NULL;
 unsigned int i;
 
 /* Try to insert ctl into d->arch.cpuids[] */
 for ( i = 0; i < MAX_CPUID_INPUT; i++ )
 {
-cpuid = &d->arch.cpuids[i];
+cpuid = &d->arch.cpuid->legacy[i];
 
 if ( cpuid->input[0] == XEN_CPUID_INPUT_UNUSED )
 {
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 38e3975..b359b38 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -203,6 +203,10 @@ struct cpuid_policy
 
 /* Toolstack selected Hypervisor max_leaf (if non-zero). */
 uint8_t hv_limit, hv2_limit;
+
+/* Temporary: Legacy data array. */
+#define MAX_CPUID_INPUT 40
+xen_domctl_cpuid_t legacy[MAX_CPUID_INPUT];
 };
 
 /* Fill in a featureset bitmap from a CPUID policy. */
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 9e3a07b..eb6227d 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -234,9 +234,6 @@ struct paging_vcpu {
 struct shadow_vcpu shadow;
 };
 
-#define MAX_CPUID_INPUT 40
-typedef xen_domctl_cpuid_t cpuid_input_t;
-
 #define MAX_NESTEDP2M 10
 
 #define MAX_ALTP2M  10 /* arbitrary */
@@ -360,8 +357,6 @@ struct arch_domain
  */
 uint8_t x87_fip_width;
 
-cpuid_input_t *cpuids;
-
 /* CPUID Policy. *

[Xen-devel] [PATCH 0/4] x86/cpuid: Hide the legacy cpuids[] infrastructure

[Andrew Cooper]

The purpose of this series is to hide the legacy cpuid implementation entirely
behind the new API.  In particular, hiding domain_cpuid() in the same way that
{pv,hvm}_cpuid() were hidden.

Andrew Cooper (4):
  x86/domctl: Move all CPUID update logic into
update_domain_cpuid_info()
  x86/cpuid: Store the toolstacks choice of hypervisor max leaf
  x86/cpuid: Effectively remove domain_cpuid()
  x86/cpuid: Move the legacy cpuids array into struct cpuid_policy

 xen/arch/x86/cpuid.c |  32 +-
 xen/arch/x86/domain.c|  54 +---
 xen/arch/x86/domctl.c| 148 +++
 xen/arch/x86/traps.c |  19 ++
 xen/include/asm-x86/cpuid.h  |   7 ++
 xen/include/asm-x86/domain.h |  13 
 6 files changed, 137 insertions(+), 136 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 1/4] x86/domctl: Move all CPUID update logic into update_domain_cpuid_info()

[Andrew Cooper]

This simplifies the XEN_DOMCTL_set_cpuid handling, splitting the safety logic
away from the internals of how an update is completed.

The legacy cpuids[] logic is left in alone in a fuction, as it wont survive
very long.  update_domain_cpuid_info() gains a small performance optimisation
to skip all update activites for leaves which won't have any impact on the
guest.  This is temporary until the new hypercall API is completed.

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

The number hypercalls made by the toolstack is quite large, while the number
which we care about will reduce as Xen does more calculations itself, at the
same time as the cost of recaculations growing.
---
 xen/arch/x86/domctl.c | 140 +++---
 1 file changed, 86 insertions(+), 54 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index b01a1f9..a5a56ee 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -48,30 +48,98 @@ static int gdbsx_guest_mem_io(domid_t domid, struct 
xen_domctl_gdbsx_memio *iop)
 return iop->remain ? -EFAULT : 0;
 }
 
-static void update_domain_cpuid_info(struct domain *d,
+static int update_legacy_cpuid_array(struct domain *d,
  const xen_domctl_cpuid_t *ctl)
 {
+cpuid_input_t *cpuid, *unused = NULL;
+unsigned int i;
+
+/* Try to insert ctl into d->arch.cpuids[] */
+for ( i = 0; i < MAX_CPUID_INPUT; i++ )
+{
+cpuid = &d->arch.cpuids[i];
+
+if ( cpuid->input[0] == XEN_CPUID_INPUT_UNUSED )
+{
+if ( !unused )
+unused = cpuid;
+continue;
+}
+
+if ( (cpuid->input[0] == ctl->input[0]) &&
+ ((cpuid->input[1] == XEN_CPUID_INPUT_UNUSED) ||
+  (cpuid->input[1] == ctl->input[1])) )
+break;
+}
+
+if ( !(ctl->eax | ctl->ebx | ctl->ecx | ctl->edx) )
+{
+if ( i < MAX_CPUID_INPUT )
+cpuid->input[0] = XEN_CPUID_INPUT_UNUSED;
+}
+else if ( i < MAX_CPUID_INPUT )
+*cpuid = *ctl;
+else if ( unused )
+*unused = *ctl;
+else
+return -ENOENT;
+
+return 0;
+}
+
+static int update_domain_cpuid_info(struct domain *d,
+const xen_domctl_cpuid_t *ctl)
+{
 struct cpuid_policy *p = d->arch.cpuid;
 const struct cpuid_leaf leaf = { ctl->eax, ctl->ebx, ctl->ecx, ctl->edx };
+int rc;
+
+/*
+ * Skip update for leaves we don't care about.  This avoids the overhead
+ * of recalculate_cpuid_policy() and making d->arch.cpuids[] needlessly
+ * longer to search.
+ */
+switch ( ctl->input[0] )
+{
+case 0x ... ARRAY_SIZE(p->basic.raw) - 1:
+if ( ctl->input[0] == 7 &&
+ ctl->input[1] >= ARRAY_SIZE(p->feat.raw) )
+return 0;
+if ( ctl->input[0] == XSTATE_CPUID &&
+ ctl->input[1] >= ARRAY_SIZE(p->xstate.raw) )
+return 0;
+break;
+
+case 0x4000: case 0x4100:
+/* Only care about the max_leaf limit. */
+
+case 0x8000 ... 0x8000 + ARRAY_SIZE(p->extd.raw) - 1:
+break;
+
+default:
+return 0;
+}
+
+rc = update_legacy_cpuid_array(d, ctl);
+if ( rc )
+return rc;
 
 /* Insert ctl data into cpuid_policy. */
-if ( ctl->input[0] < ARRAY_SIZE(p->basic.raw) )
+switch ( ctl->input[0] )
 {
+case 0x ... ARRAY_SIZE(p->basic.raw) - 1:
 if ( ctl->input[0] == 7 )
-{
-if ( ctl->input[1] < ARRAY_SIZE(p->feat.raw) )
-p->feat.raw[ctl->input[1]] = leaf;
-}
+p->feat.raw[ctl->input[1]] = leaf;
 else if ( ctl->input[0] == XSTATE_CPUID )
-{
-if ( ctl->input[1] < ARRAY_SIZE(p->xstate.raw) )
-p->xstate.raw[ctl->input[1]] = leaf;
-}
+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) )
+break;
+
+case 0x8000 ... 0x8000 + ARRAY_SIZE(p->extd.raw) - 1:
 p->extd.raw[ctl->input[0] - 0x8000] = leaf;
+break;
+}
 
 recalculate_cpuid_policy(d);
 
@@ -243,6 +311,8 @@ static void update_domain_cpuid_info(struct domain *d,
 }
 break;
 }
+
+return 0;
 }
 
 void arch_get_domain_info(const struct domain *d,
@@ -869,53 +939,15 @@ long arch_do_domctl(
 }
 
 case XEN_DOMCTL_set_cpuid:
-{
-const xen_domctl_cpuid_t *ctl = &domctl->u.cpuid;
-cpuid_input_t *cpuid, *unused = NULL;
-
 if ( d == currd ) /* no domain_pause() */
-{
 ret = -EINVAL;
-break;
-}
-
-for ( i = 0; i < MAX_CPUID_INPUT; i++ )
-{
-cpuid = &d->arch.cpuids[i];
-
-if ( cpuid->input[0] == XEN_CPUID_INPUT_UNUSED )
-{
-  

[Xen-devel] [PATCH 2/4] x86/cpuid: Store the toolstacks choice of hypervisor max leaf

[Andrew Cooper]

This removes all dependencies on the legacy cpuids[] array from
cpuid_hypervisor_leaves().  Swap a BUG() to an ASSERT_UNREACHABLE(), because
in the unlikely case that we hit it, returning all zeros to the guest is fine.

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

This maintains the same toolstack-visible behaviour.  The interface will be
altered when doing the toolstack CPUID changes.
---
 xen/arch/x86/domctl.c   |  8 
 xen/arch/x86/traps.c| 19 +--
 xen/include/asm-x86/cpuid.h |  3 +++
 3 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index a5a56ee..038521a 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -136,6 +136,14 @@ static int update_domain_cpuid_info(struct domain *d,
 p->basic.raw[ctl->input[0]] = leaf;
 break;
 
+case 0x4000:
+p->hv_limit = ctl->eax;
+break;
+
+case 0x4100:
+p->hv2_limit = ctl->eax;
+break;
+
 case 0x8000 ... 0x8000 + ARRAY_SIZE(p->extd.raw) - 1:
 p->extd.raw[ctl->input[0] - 0x8000] = leaf;
 break;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 7bb42ac..4f29c3a 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -906,26 +906,17 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, 
uint32_t leaf,
  uint32_t subleaf, struct cpuid_leaf *res)
 {
 const struct domain *d = v->domain;
+const struct cpuid_policy *p = d->arch.cpuid;
 uint32_t base = is_viridian_domain(d) ? 0x4100 : 0x4000;
 uint32_t idx  = leaf - base;
-uint32_t limit, dummy;
+unsigned int limit = is_viridian_domain(d) ? p->hv2_limit : p->hv_limit;
 
-if ( idx > XEN_CPUID_MAX_NUM_LEAVES )
-return; /* Avoid unnecessary pass through domain_cpuid() */
-
-domain_cpuid(d, base, 0, &limit, &dummy, &dummy, &dummy);
 if ( limit == 0 )
 /* Default number of leaves */
 limit = XEN_CPUID_MAX_NUM_LEAVES;
 else
-{
-/* User-specified number of leaves */
-limit &= 0xff;
-if ( limit < 2 )
-limit = 2;
-else if ( limit > XEN_CPUID_MAX_NUM_LEAVES )
-limit = XEN_CPUID_MAX_NUM_LEAVES;
-}
+/* Clamp toolstack value between 2 and MAX_NUM_LEAVES. */
+limit = min(max(limit, 2u), XEN_CPUID_MAX_NUM_LEAVES + 0u);
 
 if ( idx > limit )
 return;
@@ -1015,7 +1006,7 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, 
uint32_t leaf,
 break;
 
 default:
-BUG();
+ASSERT_UNREACHABLE();
 }
 }
 
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 5b1448a..38e3975 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -200,6 +200,9 @@ struct cpuid_policy
 #undef __DECL_BITFIELD
 #undef _DECL_BITFIELD
 #undef DECL_BITFIELD
+
+/* Toolstack selected Hypervisor max_leaf (if non-zero). */
+uint8_t hv_limit, hv2_limit;
 };
 
 /* Fill in a featureset bitmap from a CPUID policy. */
-- 
2.1.4


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

[Xen-devel] [PATCH 3/4] x86/cpuid: Effectively remove domain_cpuid()

[Andrew Cooper]

The only callers of domain_cpuid() are the legacy cpuid path via
{pv,hvm}_cpuid().  Move domain_cpuid() to being private in cpuid.c, with an
adjusted API to use struct cpuid_leaf rather than individual pointers.

The ITSC clobbering logic is dropped.  It is no longer necessary now that the
logic has moved into recalculate_cpuid_policy()

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/cpuid.c | 24 ++--
 xen/arch/x86/domain.c| 40 
 xen/include/asm-x86/domain.h |  8 
 3 files changed, 22 insertions(+), 50 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index b685874..e173ff7 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -350,6 +350,26 @@ int init_domain_cpuid_policy(struct domain *d)
 return 0;
 }
 
+static void domain_cpuid(const struct domain *d, uint32_t leaf,
+ uint32_t subleaf, struct cpuid_leaf *res)
+{
+unsigned int i;
+
+for ( i = 0; i < MAX_CPUID_INPUT; i++ )
+{
+cpuid_input_t *cpuid = &d->arch.cpuids[i];
+
+if ( (cpuid->input[0] == leaf) &&
+ ((cpuid->input[1] == XEN_CPUID_INPUT_UNUSED) ||
+  (cpuid->input[1] == subleaf)) )
+{
+*res = (struct cpuid_leaf){ cpuid->eax, cpuid->ebx,
+cpuid->ecx, cpuid->edx };
+return;
+}
+}
+}
+
 static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res)
 {
 struct vcpu *curr = current;
@@ -357,7 +377,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 const struct cpuid_policy *p = currd->arch.cpuid;
 
 if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
-domain_cpuid(currd, leaf, subleaf, &res->a, &res->b, &res->c, &res->d);
+domain_cpuid(currd, leaf, subleaf, res);
 else
 cpuid_count_leaf(leaf, subleaf, res);
 
@@ -620,7 +640,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 struct domain *d = v->domain;
 const struct cpuid_policy *p = d->arch.cpuid;
 
-domain_cpuid(d, leaf, subleaf, &res->a, &res->b, &res->c, &res->d);
+domain_cpuid(d, leaf, subleaf, res);
 
 switch ( leaf )
 {
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 319cc8a..6fc1242 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2622,46 +2622,6 @@ void arch_dump_vcpu_info(struct vcpu *v)
 vpmu_dump(v);
 }
 
-void domain_cpuid(
-const struct domain *d,
-unsigned int  input,
-unsigned int  sub_input,
-unsigned int  *eax,
-unsigned int  *ebx,
-unsigned int  *ecx,
-unsigned int  *edx)
-{
-cpuid_input_t *cpuid;
-int i;
-
-for ( i = 0; i < MAX_CPUID_INPUT; i++ )
-{
-cpuid = &d->arch.cpuids[i];
-
-if ( (cpuid->input[0] == input) &&
- ((cpuid->input[1] == XEN_CPUID_INPUT_UNUSED) ||
-  (cpuid->input[1] == sub_input)) )
-{
-*eax = cpuid->eax;
-*ebx = cpuid->ebx;
-*ecx = cpuid->ecx;
-*edx = cpuid->edx;
-
-/*
- * Do not advertise host's invariant TSC unless the TSC is
- * emulated, or the domain cannot migrate to other hosts.
- */
-if ( (input == 0x8007) && /* Advanced Power Management */
- !d->disable_migrate && !d->arch.vtsc )
-*edx &= ~cpufeat_mask(X86_FEATURE_ITSC);
-
-return;
-}
-}
-
-*eax = *ebx = *ecx = *edx = 0;
-}
-
 void vcpu_kick(struct vcpu *v)
 {
 /*
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 896e78d..9e3a07b 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -617,14 +617,6 @@ unsigned long pv_guest_cr4_fixup(const struct vcpu *, 
unsigned long guest_cr4);
  X86_CR4_OSXSAVE | X86_CR4_SMEP |   \
  X86_CR4_FSGSBASE | X86_CR4_SMAP))
 
-void domain_cpuid(const struct domain *d,
-  unsigned int  input,
-  unsigned int  sub_input,
-  unsigned int  *eax,
-  unsigned int  *ebx,
-  unsigned int  *ecx,
-  unsigned int  *edx);
-
 #define domain_max_vcpus(d) (is_hvm_domain(d) ? HVM_MAX_VCPUS : MAX_VIRT_CPUS)
 
 static inline struct vcpu_guest_context *alloc_vcpu_guest_context(void)
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 1/2] xen/kbdif: update protocol documentation

[Dario Faggioli]

On Tue, 2017-01-10 at 09:21 +0200, Oleksandr Andrushchenko wrote:
> On 01/07/2017 12:20 AM, Stefano Stabellini wrote:
> > On Fri, 6 Jan 2017, Oleksandr Andrushchenko wrote:
> > > |   reserved 
> > >    |
> > > + * +-+-+-+
> > > -+
> > > + *
> > > |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> > > /\/\/\/|
> > > + * +-+-+-+
> > > -+
> > I guess this means that we are skipping some bytes because they are
> > all
> > reserved, right?  If so, it would be useful to write the byte count
> > at this
> > point. What's the total size of the event struct?
> > 
> IMO, we shouldn't put any sizes here because:
> 1. Above we say "All event packets have the same
> length (40 octets)"
> 2. All the event structures are part of the
> union xenkbd_in_event, which has
> char pad[XENKBD_IN_EVENT_SIZE];
> which effectively regulates the size of the event.
> 
In which case, you can use either 40 or XENKBD_IN_EVENT_SIZE (probably
the latter).

It's indeed a repetition, but a good one, IMO: it helps the reader, as
she won't have to go back to figure out how big the struct was, how the
macro was call and to what value it was defined).

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

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

[Xen-devel] [PATCH] x86/svm: Adjust ModRM Mode check in is_invlpg()

[Andrew Cooper]

Coverity points out that x86_insn_modrm() returns -EINVAL for instructions not
encoded with a ModRM byte.  A consequence is that checking != 3 is
insufficient to confirm that &ext was actually written to.

In practice, this check is only used after decode has been successful, and
0f01 will have a ModRM byte.

Use an unsigned < comparison to exclude the -EINVAL case, guaranteeing that
ext is only read if it was filled in by x86_insn_modrm(), which should placate
Coverity.

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

RFC.  I haven't actually checked that this fixes the issue.

An alternative would be to ASSERT() that x86_insn_modrm() is non-negative, but
I can't nice way of integrating that into the existing logic (without using
the comma operator, and that isn't nice to read).
---
 xen/arch/x86/hvm/svm/svm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index ae8e2c4..ff134a5 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2162,7 +2162,7 @@ static bool is_invlpg(const struct x86_emulate_state 
*state,
 unsigned int ext;
 
 return ctxt->opcode == X86EMUL_OPC(0x0f, 0x01) &&
-   x86_insn_modrm(state, NULL, &ext) != 3 &&
+   (unsigned int)x86_insn_modrm(state, NULL, &ext) < 3 &&
(ext & 7) == 7;
 }
 
-- 
2.1.4


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

Re: [Xen-devel] Granularity of Credit and RTDS Scheduler

[Dario Faggioli]

On Tue, 2017-01-10 at 15:32 -0600, wy11 wrote:
> If the time granularity of RTDS is nanosecond, then it is no longer
> a  
> problem. Can you please help me to know where I can find it in the  
> source code?
> 
If that's what you're interested in, time granularity is nanoseconds
for each and every scheduler.

Look at xen/common/schedule.c, xen/common/sched_credit.c,
xen/common/sched_credit2.c and xen/common/sched_rt.c, and see how they
all use the NOW() macro for reading time.

Then go checking how NOW() is defined.

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

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

Re: [Xen-devel] most stable dom0 kernels + dependencies on Xen versions

[Konrad Rzeszutek Wilk]

On Wed, Jan 11, 2017 at 06:01:59PM +0100, Andreas Kinzler wrote:
> Somehow I cannot find *recent* information on dom0 kernels in the wiki.
> Which dom0 kernels do the Xen developers use for test/production? Are there
> recommended versions (for example 4.4) for production?

I use the latest and greates - so Linux v4.9. But you can pick any version
you are comfortable with.
> 
> Are are any dependencies/incompatibilities between Xen versions and dom0
> kernels (I am only talking about recent kernels >= 4.0)?

None.
> 
> Regards Andreas
> 
> 
> ___
> 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

[Xen-devel] most stable dom0 kernels + dependencies on Xen versions

[Andreas Kinzler]

Somehow I cannot find *recent* information on dom0 kernels in the wiki. 
Which dom0 kernels do the Xen developers use for test/production? Are 
there recommended versions (for example 4.4) for production?


Are are any dependencies/incompatibilities between Xen versions and dom0 
kernels (I am only talking about recent kernels >= 4.0)?


Regards Andreas


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

Re: [Xen-devel] [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

[Juergen Gross]

On 11/01/17 16:29, Boris Ostrovsky wrote:
> 
 +
 +
 +static bool test_reply(struct xb_req_data *req)
 +{
 +  if (req->state == xb_req_state_got_reply || !xenbus_ok())
 +  return true;
 +
 +  /* Make sure to reread req->state each time. */
 +  cpu_relax();
>>> I don't think I understand why this is needed.
>> I need a compiler barrier. Otherwise the compiler read req->state only
>> once outside the while loop.
> 
> 
> Then barrier() looks the right primitive to use here. cpu_relax(), while
> doing what you want, is intended for other purposes.

Hmm, yes, this sounds better.

>>
 +
 +  return false;
 +}
 +
>>>
 +static void xs_send(struct xb_req_data *req, struct xsd_sockmsg *msg)
  {
 -  mutex_lock(&xs_state.transaction_mutex);
 -  atomic_inc(&xs_state.transaction_count);
 -  mutex_unlock(&xs_state.transaction_mutex);
 -}
 +  bool notify;
  
 -static void transaction_end(void)
 -{
 -  if (atomic_dec_and_test(&xs_state.transaction_count))
 -  wake_up(&xs_state.transaction_wq);
 -}
 +  req->msg = *msg;
 +  req->err = 0;
 +  req->state = xb_req_state_queued;
 +  init_waitqueue_head(&req->wq);
  
 -static void transaction_suspend(void)
 -{
 -  mutex_lock(&xs_state.transaction_mutex);
 -  wait_event(xs_state.transaction_wq,
 - atomic_read(&xs_state.transaction_count) == 0);
 -}
 +  xs_request_enter(req);
  
 -static void transaction_resume(void)
 -{
 -  mutex_unlock(&xs_state.transaction_mutex);
 +  req->msg.req_id = xs_request_id++;
>>> Is it safe to do this without a lock?
>> You are right: I should move this to xs_request_enter() inside the
>> lock. I think I'll let return xs_request_enter() the request id.
> 
> 
> Then please move xs_request_id's declaration close to xs_state_lock's
> declaration (just like you are going to move the two other state variables)

Already done. :-)

>>
 +static int xs_reboot_notify(struct notifier_block *nb,
 +  unsigned long code, void *unused)
  {
 -  struct xs_stored_msg *msg;
>>>
>>>
 +  struct xb_req_data *req;
 +
 +  mutex_lock(&xb_write_mutex);
 +  list_for_each_entry(req, &xs_reply_list, list)
 +  wake_up(&req->wq);
 +  list_for_each_entry(req, &xb_write_list, list)
 +  wake_up(&req->wq);
>>> We are waking up waiters here but there is not guarantee that waiting
>>> threads will have a chance to run, is there?
>> You are right. But this isn't the point. We want to avoid blocking a
>> reboot due to some needed thread waiting for xenstore. And this task
>> is being accomplished here.
> 
> 
> I think it's worth adding a comment mentioning this.

Okay.


Juergen


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

Re: [Xen-devel] [PATCH v2 2/2] p2m: split mem_access into separate files

[Konrad Rzeszutek Wilk]

On Tue, Jan 03, 2017 at 08:31:25AM -0700, Tamas K Lengyel wrote:
> On Fri, Dec 9, 2016 at 12:59 PM, Tamas K Lengyel
>  wrote:
> > This patch relocates mem_access components that are currently mixed with p2m
> > code into separate files. This better aligns the code with similar 
> > subsystems,
> > such as mem_sharing and mem_paging, which are already in separate files. 
> > There
> > are no code-changes introduced, the patch is mechanical code movement.
> >
> > On ARM we also relocate the static inline gfn_next_boundary function to 
> > p2m.h
> > as it is a function the mem_access code needs access to.
> >
> > Signed-off-by: Tamas K Lengyel 
> > Acked-by: Razvan Cojocaru 
> 
> Acked-by: George Dunlap 

Acked-by: Konrad Rzeszutek Wilk 


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

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

[osstest service owner]

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

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  14a6be89ec04bfadba978dc4c2f1e7f96db8cdf0
baseline version:
 xen  ffc103c223a6d12e5221f66b7e96396a61ba1b20

Last test of basis   104101  2017-01-10 18:01:05 Z0 days
Testing same since   104124  2017-01-11 13:01:43 Z0 days2 attempts


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

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=14a6be89ec04bfadba978dc4c2f1e7f96db8cdf0
+ . ./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 
14a6be89ec04bfadba978dc4c2f1e7f96db8cdf0
+ branch=xen-unstable-smoke
+ revision=14a6be89ec04bfadba978dc4c2f1e7f96db8cdf0
+ . ./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
+ '[' x14a6be89ec04bfadba978dc4c2f1e7f96db8cdf0 = 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
++ : gi

Re: [Xen-devel] [RFC 0/2] XEN SWIOTLB for ARM dma operations extension

[Konrad Rzeszutek Wilk]

On Wed, Jan 11, 2017 at 06:09:03PM +0200, Andrii Anisov wrote:
> Dear Konrad,
> 
> Please see my comments below:
> > It would be good to have that as part of this patchset, otherwise
> > this is kind of non-compiling type patch.
> I'm not really sure what do you mean.

As in attaching an rework of the patch to this patchset.

> The patch I refer was done for LK 3.4 if I remember, it is not applicable to
> 4.6 I'm currently working with.
> Moreover xen-swiotlb infrastructure changed significantly so the patch is
> completely reworked. The only
> common code is that mmap is defined in ARM specific xen_swiotlb_dma_ops.
> I just refer to it and left author and signed-of-s as a respect to the work
> done few years ago.
> 
> > But more importantly, I think you need to also to take into account
> > Stefano's comments:
> I've encapsulated all the code changes in an arch/arm/xen/mm.c so I don't
> think your doubts and Stephano's comment
> about x86 build impact is relevant here.
> 
> -- 
> 
> *Andrii Anisov*
> 
> *Lead Systems Engineer*
> 
> *Office: *+380 44 390 5457  *x* 66766
> *Cell: *+380 50 5738852 *Email:
> *andrii_ani...@epam.com 
> 
> *Kyiv**,* *Ukraine *(GMT+3)*epam.com *
> 
> CONFIDENTIALITY CAUTION AND DISCLAIMER
> This message is intended only for the use of the individual(s) or
> entity(ies) to which it is addressed and contains information that is
> legally privileged and confidential. If you are not the intended recipient,
> or the person responsible for delivering the message to the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. All unintended
> recipients are obliged to delete this message and destroy any printed
> copies.
> 

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

Re: [Xen-devel] [RFC 0/2] XEN SWIOTLB for ARM dma operations extension

[Andrii Anisov]

Dear Konrad,

Please see my comments below:

It would be good to have that as part of this patchset, otherwise
this is kind of non-compiling type patch.

I'm not really sure what do you mean.
The patch I refer was done for LK 3.4 if I remember, it is not 
applicable to 4.6 I'm currently working with.
Moreover xen-swiotlb infrastructure changed significantly so the patch 
is completely reworked. The only

common code is that mmap is defined in ARM specific xen_swiotlb_dma_ops.
I just refer to it and left author and signed-of-s as a respect to the 
work done few years ago.



But more importantly, I think you need to also to take into account
Stefano's comments:
I've encapsulated all the code changes in an arch/arm/xen/mm.c so I 
don't think your doubts and Stephano's comment

about x86 build impact is relevant here.

--

*Andrii Anisov*

*Lead Systems Engineer*

*Office: *+380 44 390 5457  *x* 66766 
*Cell: *+380 50 5738852 *Email: 
*andrii_ani...@epam.com 


*Kyiv**,* *Ukraine *(GMT+3)*epam.com *

CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s) or 
entity(ies) to which it is addressed and contains information that is 
legally privileged and confidential. If you are not the intended 
recipient, or the person responsible for delivering the message to the 
intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited. 
All unintended recipients are obliged to delete this message and destroy 
any printed copies.



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

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

[Jan Beulich]

>>> On 11.01.17 at 16:40,  wrote:
> On 10/01/17 09:04, Jan Beulich wrote:
>> @@ -1836,6 +1840,34 @@ static int inject_swint(enum x86_swint_t
>>  generate_exception(fault_type, error_code);
>>  }
>>  
>> +static void adjust_bnd(struct x86_emulate_ctxt *ctxt,
>> +   const struct x86_emulate_ops *ops, enum vex_pfx pfx)
>> +{
>> +uint64_t bndcfg;
>> +int rc;
>> +
>> +if ( pfx == vex_f2 || !vcpu_has_mpx() )
>> +return;
> 
> I'm sorry, but I am still going to argue over this.  This needs to be a
> host_and_vcpu check, because we are actually using real host
> state/operations to perform the emulation.
> 
> At the moment, given junk in the vcpu cpuid information, we could still
> hit some assertions.  Furthermore, this is the litmus test I use to
> chose between the two form.  I.e. "If the vcpu information has junk in
> it, will Xen crash when it comes to execute this path?".
> 
> At the point we think the vcpu information is strictly a subset of
> hardware, we could turn the host_and_* side of the check into an
> ASSERT(cpu_has_*) instead, but the difference between the two is still
> semantic relevant.

Okay, I think I finally understand your concern. Originally my
intention was for read_bndcfgu() and xstate_set_init() to be
effectively no-ops with !cpu_has_mpx. I see now that I have
broken this at some point for the former, and the assertion
you had asked me to add also broke it for the latter. So I see
both options as viable: Do as you say and add a cpu_has_mpx
check (which now is much easier than back when I wrote this
patch, as the test harness'es cpu_has_* are now visible in the
main emulator source file afaict), or convert the two functions
back to how they were intended to behave originally.

Jan


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

Re: [Xen-devel] [PATCH v13 0/3] iommu: add rmrr Xen command line option

[Venu Busireddy]

On Wed, Jan 11, 2017 at 05:55:58AM +, Tian, Kevin wrote:
> > From: Venu Busireddy
> > Sent: Wednesday, January 11, 2017 6:58 AM
> > 
> > From: Elena Ufimtseva 
> > 
> > Add Xen command line option rmrr to specify RMRR regions that are not
> > defined in ACPI thus causing IO Page Faults and prevent dom0 from booting
> > if "iommu=dom0-strict" option is specified on the Xen command line.
> > These additional regions will be added to the list of RMRR regions parsed
> > from ACPI.
> > 
> > Changes in v13:
> >  - Implement feedback from Kevin Tian.
> >
> > https://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03169.html
> >
> > https://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03170.html
> >
> > https://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03171.html
> 
> Looks I gave my ack/review to all three patches. But you didn't put my 
> acked-by
> in patch [3/3]. Is there substantial change against v12 which requires my 
> further
> review?

Functionally, nothing changed. But quite a few changes (coding style,
renaming of structures and variables, introduction of new variables to
make code more readable, and such) are made, which changed the
appearance of the code. As a result, a suggestion was made to remove
your "Acked-by", so that you could review the new format. If you are
fine with syntactic changes, you don't need to review it again. 

Regards,

Venu

> 
> >  - Limit all source lines and comments to 80 characters per line.
> >  - Implement coding style suggestions from Konrad Wilk.
> >  - Changed the Author to Elena Ufimtseva 
> > 
> > Changes in v12:
> >  - Mostly cosmetic fixes from Jan's review on v11.
> > 
> > Changes in v11:
> >  - changed macro to print extra RMRR ranges and added argument macro;
> >  - fixed the overlapping check if condition error;
> >  - fixed the loop exit condition when checking pfn in RMRR region;
> > 
> > Elena Ufimtseva (3):
> >   iommu VT-d: separate rmrr addition function.
> >   pci: add wrapper for parse_pci.
> >   iommu: add rmrr Xen command line option for extra rmrrs
> > 
> >  docs/misc/xen-command-line.markdown |  13 ++
> >  xen/drivers/passthrough/vtd/dmar.c  | 324
> > +---
> >  xen/drivers/pci/pci.c   |  11 ++
> >  xen/include/xen/pci.h   |   3 +
> >  4 files changed, 292 insertions(+), 59 deletions(-)
> > 
> > 
> > ___
> > 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 v4 4/6] x86emul: support VME and PVI

[Andrew Cooper]

On 11/01/17 15:26, Jan Beulich wrote:
 On 11.01.17 at 16:15,  wrote:
>> On 10/01/17 09:04, Jan Beulich wrote:
>>> @@ -1178,6 +1180,15 @@ _mode_iopl(
>>>  fail_if(_iopl < 0); \
>>>  _iopl;  \
>>>  })
>>> +#define mode_pvi() ({\
>>> +unsigned long cr4 = 0;   \
>>> +if ( ops->read_cr && get_cpl(ctxt, ops) == 3 )   \
>>> +{\
>>> +rc = ops->read_cr(4, &cr4, ctxt);\
>>> +if ( rc != X86EMUL_OKAY ) goto done; \
>>> +}\
>>> +!!(cr4 & (_regs._eflags & EFLG_VM ? CR4_VME : CR4_PVI)); \
>>> +})
>> The name mode_pvi() is misleading, because VME and PVI behave
>> differently for everything other than cli/sti.
>>
>> mode_vif() would be better IMO, as it describes a condition under which
>> VIF should be used instead of IF.
> I don't mind - if that's the only change you ask for, that's easy
> enough to do.

Well - you snipped the main part of the reply where (I clearly didn't
say obviously enough) that I think this change now regresses our
emulation of pushf.

~Andrew

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

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

[Andrew Cooper]

On 10/01/17 09:04, Jan Beulich wrote:
> @@ -1836,6 +1840,34 @@ static int inject_swint(enum x86_swint_t
>  generate_exception(fault_type, error_code);
>  }
>  
> +static void adjust_bnd(struct x86_emulate_ctxt *ctxt,
> +   const struct x86_emulate_ops *ops, enum vex_pfx pfx)
> +{
> +uint64_t bndcfg;
> +int rc;
> +
> +if ( pfx == vex_f2 || !vcpu_has_mpx() )
> +return;

I'm sorry, but I am still going to argue over this.  This needs to be a
host_and_vcpu check, because we are actually using real host
state/operations to perform the emulation.

At the moment, given junk in the vcpu cpuid information, we could still
hit some assertions.  Furthermore, this is the litmus test I use to
chose between the two form.  I.e. "If the vcpu information has junk in
it, will Xen crash when it comes to execute this path?".

At the point we think the vcpu information is strictly a subset of
hardware, we could turn the host_and_* side of the check into an
ASSERT(cpu_has_*) instead, but the difference between the two is still
semantic relevant.

At some point, if we ever get around supporting features while lacking
hardware support, the host_and_* checks document the areas which need to
split into

vcpu_has_*
if ( cpu_has_* )
/* optimised emulation path with hardware support. */
else
/* unoptimised path without any support. */

Everything else looks fine however.

~Andrew

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

Re: [Xen-devel] [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

[Boris Ostrovsky]

>>> +
>>> +
>>> +static bool test_reply(struct xb_req_data *req)
>>> +{
>>> +   if (req->state == xb_req_state_got_reply || !xenbus_ok())
>>> +   return true;
>>> +
>>> +   /* Make sure to reread req->state each time. */
>>> +   cpu_relax();
>> I don't think I understand why this is needed.
> I need a compiler barrier. Otherwise the compiler read req->state only
> once outside the while loop.


Then barrier() looks the right primitive to use here. cpu_relax(), while
doing what you want, is intended for other purposes.


>
>>> +
>>> +   return false;
>>> +}
>>> +
>>
>>> +static void xs_send(struct xb_req_data *req, struct xsd_sockmsg *msg)
>>>  {
>>> -   mutex_lock(&xs_state.transaction_mutex);
>>> -   atomic_inc(&xs_state.transaction_count);
>>> -   mutex_unlock(&xs_state.transaction_mutex);
>>> -}
>>> +   bool notify;
>>>  
>>> -static void transaction_end(void)
>>> -{
>>> -   if (atomic_dec_and_test(&xs_state.transaction_count))
>>> -   wake_up(&xs_state.transaction_wq);
>>> -}
>>> +   req->msg = *msg;
>>> +   req->err = 0;
>>> +   req->state = xb_req_state_queued;
>>> +   init_waitqueue_head(&req->wq);
>>>  
>>> -static void transaction_suspend(void)
>>> -{
>>> -   mutex_lock(&xs_state.transaction_mutex);
>>> -   wait_event(xs_state.transaction_wq,
>>> -  atomic_read(&xs_state.transaction_count) == 0);
>>> -}
>>> +   xs_request_enter(req);
>>>  
>>> -static void transaction_resume(void)
>>> -{
>>> -   mutex_unlock(&xs_state.transaction_mutex);
>>> +   req->msg.req_id = xs_request_id++;
>> Is it safe to do this without a lock?
> You are right: I should move this to xs_request_enter() inside the
> lock. I think I'll let return xs_request_enter() the request id.


Then please move xs_request_id's declaration close to xs_state_lock's
declaration (just like you are going to move the two other state variables)


>
>>> +static int xs_reboot_notify(struct notifier_block *nb,
>>> +   unsigned long code, void *unused)
>>>  {
>>> -   struct xs_stored_msg *msg;
>>
>>
>>> +   struct xb_req_data *req;
>>> +
>>> +   mutex_lock(&xb_write_mutex);
>>> +   list_for_each_entry(req, &xs_reply_list, list)
>>> +   wake_up(&req->wq);
>>> +   list_for_each_entry(req, &xb_write_list, list)
>>> +   wake_up(&req->wq);
>> We are waking up waiters here but there is not guarantee that waiting
>> threads will have a chance to run, is there?
> You are right. But this isn't the point. We want to avoid blocking a
> reboot due to some needed thread waiting for xenstore. And this task
> is being accomplished here.


I think it's worth adding a comment mentioning this.

-boris


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

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

[Dan Streetman]

On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
 wrote:
> On Tue, 10 Jan 2017, Dan Streetman wrote:
>> On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
>>  wrote:
>> > On Tue, 10 Jan 2017, Dan Streetman wrote:
>> >> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman  wrote:
>> >> > On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
>> >> >  wrote:
>> >> >> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
>> >> >>> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
>> >> >>> > On Mon, Jan 9, 2017 at 9:59 AM, Boris Ostrovsky
>> >> >>> >  wrote:
>> >> >>> > > On 01/06/2017 08:06 PM, Konrad Rzeszutek Wilk wrote:
>> >> >>> > >> On Thu, Jan 05, 2017 at 02:28:56PM -0500, Dan Streetman wrote:
>> >> >>> > >>> 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.
>> >> >>> > >> Won't this cause a starvation problem? That is we will run out 
>> >> >>> > >> of PIRQs
>> >> >>> > >> as we are not reusing them?
>> >> >>> > >
>> >> >>> > > Don't we free the pirq when we unmap it?
>> >> >>> >
>> >> >>> > I think this is actually a bit worse than I initially thought.  
>> >> >>> > After
>> >> >>> > looking a bit closer, and I think there's an asymmetry with pirq
>> >> >>> > allocation:
>> >> >>>
>> >> >>> Lets include Stefano,
>> >> >>>
>> >> >>> Thank you for digging in this! This has quite the deja-vu
>> >> >>> feeling as I believe I hit this at some point in the past and
>> >> >>> posted some possible ways of fixing this. But sadly I can't
>> >> >>> find the thread.
>> >> >>
>> >> >> This issue seems to be caused by:
>> >> >>
>> >> >> commit af42b8d12f8adec6711cb824549a0edac6a4ae8f
>> >> >> Author: Stefano Stabellini 
>> >> >> Date:   Wed Dec 1 14:51:44 2010 +
>> >> >>
>> >> >> xen: fix MSI setup and teardown for PV on HVM guests
>> >> >>
>> >> >> which was a fix to a bug:
>> >> >>
>> >> >> This fixes a bug in xen_hvm_setup_msi_irqs that manifests itself 
>> >> >> when
>> >> >> trying to enable the same MSI for the second time: the old MSI to 
>> >> >> pirq
>> >> >> mapping is still valid at this point but xen_hvm_setup_msi_irqs 
>> >> >> would
>> >> >> try to assign a new pirq anyway.
>> >> >> A simple way to reproduce this bug is to assign an MSI capable 
>> >> >> network
>> >> >> card to a PV on HVM guest, if the user brings down the 
>> >> >> corresponding
>> >> >> ethernet interface and up again, Linux would fail to enable MSIs 
>> >> >> on the
>> >> >> device.
>> >> >>
>> >> >> I don't remember any of the details. From the description of this bug,
>> >> >> it seems that Xen changed behavior in the past few years: before it 
>> >> >> used
>> >> >> to keep the pirq-MSI mapping, while today it doesn't. If I wrote "the
>> >> >> old MSI to pirq mapping is still valid at this point", the pirq 
>> >> >> couldn't
>> >> >> have been completely freed, then reassigned to somebody else the way it
>> >> >> is described in this email.
>> >> >>
>> >> >> I think we should indentify the changeset or Xen version that 
>> >> >> introduced
>> >> >> the new behavior. If it is old enough, we might be able to just revert
>> >> >> af42b8d12f8adec6711cb824549a0edac6a4ae8f. Otherwise we could make the
>> >> >> behavior conditional to the Xen version.
>> >> >
>> >> > Are PT devices the only MSI-capable devices available in a Xen guest?
>> >> > That's where I'm seeing this problem, with PT NVMe devices.
>> >
>> > They are the main ones. It is possible to have emulated virtio devices
>> > with emulated MSIs, for example virtio-net. Althought they are not in
>> > the Xen Project CI-loop, so I wouldn't be surprised if they are broken
>> > too.
>> >
>> >
>> >> > I can say that on the Xen guest with NVMe PT devices I'm testing on,
>> >> > with the patch from this thread (which essentially reverts your commit
>> >> > above) as well as some added debug to see the pirq numbers, cycles of
>> >> > 'modprobe nvme ; rmmod nvme' don't cause pirq starvation, as the
>> >> > hypervisor provides essentially the same pirqs for each modprobe,
>> >> > since they were freed by the rmmod.
>> >
>> > I am fine with reverting the old patch, but we need to understand what
>> > caused the change in behavior first. Maybe somebody else with a Xen PCI
>> > passthrough setup at hand can help with that.
>> >
>> > In the Xen code I can still see:
>> >
>> > case ECS_PIRQ: {
>> > struct pirq *pirq = pirq_info(d1, chn1->u.pirq.irq);
>> >
>> > if ( !pirq )
>> > break;
>> > if ( !is_hvm_domain(d1) )
>> > pirq_guest_unbind(d1, pirq);
>> >
>> > which means that pirq_guest_unbind should only be called on evtchn_close
>> > i

Re: [Xen-devel] [PATCH v4 4/6] x86emul: support VME and PVI

[Jan Beulich]

>>> On 11.01.17 at 16:15,  wrote:
> On 10/01/17 09:04, Jan Beulich wrote:
>> @@ -1178,6 +1180,15 @@ _mode_iopl(
>>  fail_if(_iopl < 0); \
>>  _iopl;  \
>>  })
>> +#define mode_pvi() ({\
>> +unsigned long cr4 = 0;   \
>> +if ( ops->read_cr && get_cpl(ctxt, ops) == 3 )   \
>> +{\
>> +rc = ops->read_cr(4, &cr4, ctxt);\
>> +if ( rc != X86EMUL_OKAY ) goto done; \
>> +}\
>> +!!(cr4 & (_regs._eflags & EFLG_VM ? CR4_VME : CR4_PVI)); \
>> +})
> 
> The name mode_pvi() is misleading, because VME and PVI behave
> differently for everything other than cli/sti.
> 
> mode_vif() would be better IMO, as it describes a condition under which
> VIF should be used instead of IF.

I don't mind - if that's the only change you ask for, that's easy
enough to do.

Jan


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

Re: [Xen-devel] [PATCH v4 4/6] x86emul: support VME and PVI

[Andrew Cooper]

On 10/01/17 09:04, Jan Beulich wrote:
> ... affecting POPF, CLI, and STI.

There seems to be a a discrepancy in Intel documentation.

Vol3 20.3.2 "Class 2—Maskable Hardware Interrupt Handling in
Virtual-8086 Mode Using the Virtual Interrupt Mechanism" says

"Also, if under these circumstances an 8086 program tries to read or
change the IF flag using the PUSHF or POPF instructions, the processor
will change the VIF flag instead, leaving IF unchanged."

which clearly means that pushf/popf fold VIF into IF.  This makes sense,
as the entire point is to let older vm86 tasks play with the interrupt
flag like they used to.

The pseudocode for pushf doesn't indicate this behaviour.


Looking at the AMD documentation, the pseduocode for pushf does
specifically call out folding VIF into IF, and also showing IOPL as 3.


>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -433,6 +433,8 @@ typedef union {
>  #define CR0_EM(1<<2)
>  #define CR0_TS(1<<3)
>  
> +#define CR4_VME(1<<0)
> +#define CR4_PVI(1<<1)
>  #define CR4_TSD(1<<2)
>  #define CR4_OSFXSR (1<<9)
>  #define CR4_OSXMMEXCPT (1<<10)
> @@ -1178,6 +1180,15 @@ _mode_iopl(
>  fail_if(_iopl < 0); \
>  _iopl;  \
>  })
> +#define mode_pvi() ({\
> +unsigned long cr4 = 0;   \
> +if ( ops->read_cr && get_cpl(ctxt, ops) == 3 )   \
> +{\
> +rc = ops->read_cr(4, &cr4, ctxt);\
> +if ( rc != X86EMUL_OKAY ) goto done; \
> +}\
> +!!(cr4 & (_regs._eflags & EFLG_VM ? CR4_VME : CR4_PVI)); \
> +})

The name mode_pvi() is misleading, because VME and PVI behave
differently for everything other than cli/sti.

mode_vif() would be better IMO, as it describes a condition under which
VIF should be used instead of IF.

~Andrew

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 11 guest-start  fail REGR. vs. 104101

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

version targeted for testing:
 xen  14a6be89ec04bfadba978dc4c2f1e7f96db8cdf0
baseline version:
 xen  ffc103c223a6d12e5221f66b7e96396a61ba1b20

Last test of basis   104101  2017-01-10 18:01:05 Z0 days
Testing same since   104124  2017-01-11 13:01:43 Z0 days1 attempts


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

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v6 00/14] linux: generalize sections, ranges and linker tables

[Luis R. Rodriguez]

On Mon, Jan 09, 2017 at 08:29:15PM +0200, Andy Shevchenko wrote:
> On Mon, 2017-01-09 at 19:12 +0200, Andy Shevchenko wrote:
> > On Mon, 2017-01-09 at 18:27 +0200, Andy Shevchenko wrote:
> > > On Mon, 2017-01-09 at 06:58 -0800, Luis R. Rodriguez wrote:
> > > > The only architecture that was not tested was avr32 and that is
> > > > because
> > > > linux-next fails to compile on it. I'd like to greatly thank
> > > > Guenter
> > > > Roeck for
> > > > his help with testing.
> > > 
> > > We have a real board here. I would try to check if you provide a git
> > > url
> > > to your stuff.
> > > 
> > > I can confirm that breakage happened like in last couple of month.
> > > v4.10-rc3 can't be compiled either.
> > 
> > The culprit commit is
> > 
> > commit 3a0af8fd61f90920f6fa04e4f1e9a6a73c1b4fd2
> > Author: Thomas Graf 
> > Date:   Wed Nov 30 17:10:10 2016 +0100
> > 
> > bpf: BPF for lightweight tunnel infrastructure
> > 
> 
> This makes modules closer to each other, so,
> net/socket.c:348: relocation truncated to fit: R_AVR32_11H_PCREL against
> `.text'+2930
> 
> But still the module is too big for AVR to do some jumps.

Well I've reverted your patch and tested on avr32 and all tests
worked successfully. Thanks to Guenter again for helping with his
testbed once again!

  Luis

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

Re: [Xen-devel] [PATCH] tools/libxc: Fix the reported max_leaf values for PV guests

[Wei Liu]

On Wed, Jan 11, 2017 at 12:44:41PM +, Andrew Cooper wrote:
> When iterating through CPUID leaves to generating a policy, libxc will clip
> itself at the hardcoded maxima, meaning that no data outside of the hardcoded
> maxima are provided to Xen (in turn, causing Xen to return zeros if these
> leaves are requested.)
> 
> The HVM code also clips the max_leaf data reported to the guest, but the PV
> side didn't.
> 
> This results in a PV guest using the emulated CPUID, or via Xen using CPUID
> faulting, to observe a max_leaf higher than the toolstack wants, although with
> zeros being returned in the intervening leaves.
> 
> Fix the PV side to behave like the HVM side, and clip the max_leaf values in
> leaf 0 and 0x8000.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 12/24] x86: refactor psr: set value: implement write msr flow.

[Jan Beulich]

>>> On 11.01.17 at 07:22,  wrote:
> On 17-01-10 08:15:15, Jan Beulich wrote:
>> >>> On 14.12.16 at 05:07,  wrote:
>> > --- a/xen/arch/x86/psr.c
>> > +++ b/xen/arch/x86/psr.c
>> > @@ -186,6 +186,9 @@ struct feat_ops {
>> >  unsigned int (*exceeds_cos_max)(const uint64_t val[],
>> >  const struct feat_node *feat,
>> >  unsigned int cos);
>> > +/* write_msr is used to write out feature MSR register. */
>> > +int (*write_msr)(unsigned int cos, const uint64_t val[],
>> > + struct feat_node *feat);
>> 
>> Looks like this function again returns number-of-values, yet this time
>> without a comment saying so. While you don't need to replicate
>> that description multiple time, please at least has a brief reference.
>> That said, with the type checks moved out I think this return value
>> model won't be needed anymore - the caller, having checked the
>> type, could then simply call the get-num-val (or however it was
>> named) hook to know how many array entries to skip.
>> 
> For write msr, we may need iterate the whole feature list to write values for
> every feature if the input value is not same as old on the COS ID. So, I 
> prefer
> to keep current return value, the number-of-values handled. That would be 
> clear
> and easy to implement. Of course, we can call get_cos_num to get the returen
> value or define a macro to replace the digit. How do you think?

Well, my general reservation here is that this way you require about
half a dozen functions to all return the same value. If the value
changes (or if somebody clones the set), there's the risk of one not
getting properly updated. Therefore I'd much prefer for just one
function to return the count. And I'm relatively certain that with the
type checks moved out, this will actually end up being the more
natural way.

Jan


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

Re: [Xen-devel] [PATCH v4 09/24] x86: refactor psr: set value: assemble features value array.

[Jan Beulich]

>>> On 11.01.17 at 07:07,  wrote:
> On 17-01-10 07:34:00, Jan Beulich wrote:
>> >>> On 14.12.16 at 05:07,  wrote:
>> > +static int l3_cat_set_new_val(uint64_t val[],
>> > +  const struct feat_node *feat,
>> > +  unsigned int old_cos,
>> > +  enum cbm_type type,
>> > +  uint64_t m)
>> > +{
>> > +if ( type != PSR_CBM_TYPE_L3 )
>> > +/* L3 CAT uses one COS. Skip it. */
>> > +return 1;
>> 
>> If this is the wrong type, how can you return 1 (or any positive
>> value) here? This basically suggests that, as recommended for an
>> earlier operation already, that you want the type check done in
>> the caller. Or wait - isn't type not matching an error here, as you
>> iterate the same list twice in the same order? Which then gets us
>> back to me mentioning that the set-new-value should really be
>> done in common code, not in the callbacks; it would really only be
>> the check (psr_check_cbm() in the L3 case above) which would
>> require a callback.
>> 
> Your understanding is right. The value array will be iterated twice. First,
> assemble all features old value into it. Second, set the target value into
> array according to the target feature's position in the array. Because
> different features may have different behaviors, e.g. CDP uses two entries
> of the array, I think it would be better to make 'set_new_val' be a callback
> function.

Bot for common code to do that, all it takes is knowing the number
of registers, which you already have a callback for.

Jan


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

Re: [Xen-devel] [PATCH v4 07/24] x86: refactor psr: implement get value flow.

[Jan Beulich]

>>> On 11.01.17 at 06:16,  wrote:
> On 17-01-10 06:50:36, Jan Beulich wrote:
>> >>> On 14.12.16 at 05:07,  wrote:
>> > This patch implements get value flow including L3 CAT callback
>> > function.
>> > 
>> > It also changes domctl interface to make it more general.
>> > 
>> > With this patch, 'psr-cat-show' can work for L3 CAT.
>> 
>> How about CDP? You don't implement anything for it here, and looking
>> over the subjects of the remaining patches there also doesn't seem to
>> be anything to come.
>> 
> I split CDP codes out to a few patches from 13 to 16. CDP is a stand alone
> feature now but not combined with L3 CAT.
> 
> [PATCH v4 13/24] x86: refactor psr: implement CPU init and free flow for 
> CDP.

So I guess the "get value" part is to be found there then, too?
Because that's what I was looking for before making the remark.

Jan


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

Re: [Xen-devel] [PATCH v4 06/24] x86: refactor psr: implement get hw info flow.

[Jan Beulich]

>>> On 11.01.17 at 06:13,  wrote:
> On 17-01-10 06:46:03, Jan Beulich wrote:
>> >>> On 14.12.16 at 05:07,  wrote:
>> > +int psr_get_info(unsigned int socket, enum cbm_type type,
>> > + uint32_t dat[], uint32_t array_len)
>> > +{
>> > +struct psr_socket_info *info = get_socket_info(socket);
>> > +struct feat_node *feat_tmp;
>> 
>> With the hook function taking a pointer to const I don#t see why
>> this one can't be const, too.
>> 
> Do you mean feat_tmp? Thanks!

Not sure why you ask - yes, that's why I've placed the comment at
precisely this line.

Jan


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

Re: [Xen-devel] [PATCH v4 04/24] x86: refactor psr: implement CPU init and free flow.

[Jan Beulich]

>>> On 11.01.17 at 04:14,  wrote:
> On 17-01-10 04:45:05, Jan Beulich wrote:
>> >>> On 14.12.16 at 05:07,  wrote:
>> > +/* L3 CAT callback functions implementation. */
>> > +static void l3_cat_init_feature(unsigned int eax, unsigned int ebx,
>> > +unsigned int ecx, unsigned int edx,
>> 
>> This is rather unfortunate naming: How does the reader of this code
>> know what these values represent, without having to first go look in
>> the caller?
>> 
> Do you mean the 'eax'-'edx'?

Yes.

> How about 'eax_register'?

How would that be any better? Perhaps the best way of making the
naming obvious would be to use the new cpuid_leaf structure here.

>> > +if ( !cpu_has(c, X86_FEATURE_PQE) || c->cpuid_level < 
>> > PSR_CPUID_LEVEL_CAT )
>> > +return;
>> 
>> Instead of such a double check, please consider clearing the PQE
>> feature bit when the maximum CPUID level is too low (which
>> shouldn't happen anyway).
>> 
> Is this the responsibility of psr.c? X86_FEATURE_PQE bit is set by HW. Even 
> the
> bit is set but CPUID level is low, I think SW would be better to keep it but
> not clear it. Because it indicates the HW capability. How do you think? 

What use if keeping the flag if we can't use the feature? And to
answer your first question - whether that's being done in psr.c,
cpu/common.c, or cpu/intel.c I don't really care all that much; it
would certainly feel most natural to go here.

>> > +socket = cpu_to_socket(cpu);
>> > +info = socket_info + socket;
>> > +if ( info->feat_mask )
>> > +return;
>> > +
>> > +spin_lock_init(&info->ref_lock);
>> > +
>> > +cpuid_count(PSR_CPUID_LEVEL_CAT, 0, &eax, &ebx, &ecx, &edx);
>> > +if ( ebx & PSR_RESOURCE_TYPE_L3 )
>> > +{
>> > +cpuid_count(PSR_CPUID_LEVEL_CAT, 1, &eax, &ebx, &ecx, &edx);
>> > +
>> > +feat_tmp = feat_l3_cat;
>> > +feat_l3_cat = NULL;
>> > +feat_tmp->ops = l3_cat_ops;
>> > +
>> > +feat_tmp->ops.init_feature(eax, ebx, ecx, edx, feat_tmp, info);
>> 
>> What's the point of the indirect call here, when you know the
>> function is l3_cat_init_feature()?
>> 
> Hmm, just want to keep the callback function calling style.

Please don't use indirect calls when you don't need them.

>> > +static int psr_cpu_prepare(unsigned int cpu)
>> > +{
>> > +return cpu_prepare_work(cpu);
>> > +}
>> 
>> What is this wrapper good for?
>> 
> Just keep the old codes.

Well, you're overhauling the old code anyway (and you're actively
adding this function here), so - please don't introduce pointless
wrappers like this. They only complicate anyone following call flow,
even if just slightly.

Jan


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

Re: [Xen-devel] [PATCH] tools/libxc: Fix the reported max_leaf values for PV guests

[Jan Beulich]

>>> On 11.01.17 at 13:44,  wrote:
> When iterating through CPUID leaves to generating a policy, libxc will clip
> itself at the hardcoded maxima, meaning that no data outside of the hardcoded
> maxima are provided to Xen (in turn, causing Xen to return zeros if these
> leaves are requested.)
> 
> The HVM code also clips the max_leaf data reported to the guest, but the PV
> side didn't.
> 
> This results in a PV guest using the emulated CPUID, or via Xen using CPUID
> faulting, to observe a max_leaf higher than the toolstack wants, although with
> zeros being returned in the intervening leaves.
> 
> Fix the PV side to behave like the HVM side, and clip the max_leaf values in
> leaf 0 and 0x8000.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f7c11d9b995cc59cdbda0b790eafbc510b50b82d
baseline version:
 ovmf 0772737347816ced8df6299b1c88cccb9de9164c

Last test of basis   104121  2017-01-11 08:45:34 Z0 days
Testing same since   104123  2017-01-11 10:46:13 Z0 days1 attempts


People who touched revisions under test:
  Ruiyu Ni 

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=f7c11d9b995cc59cdbda0b790eafbc510b50b82d
+ . ./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 
f7c11d9b995cc59cdbda0b790eafbc510b50b82d
+ branch=ovmf
+ revision=f7c11d9b995cc59cdbda0b790eafbc510b50b82d
+ . ./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
+ '[' xf7c11d9b995cc59cdbda0b790eafbc510b50b82d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git

Re: [Xen-devel] [PATCH v4 6/6] x86emul: improve CR/DR access handling

[Andrew Cooper]

On 10/01/17 13:01, Jan Beulich wrote:
 On 10.01.17 at 12:59,  wrote:
>> On 10/01/17 09:06, Jan Beulich wrote:
>>> - don't accept LOCK for DR accesses (it's undefined in the manuals)
>>> - only accept LOCK for CR accesses when the respective feature flag is
>>>   set (which would not normally be the case for Intel)
>>> - add (rather than or) 8 when LOCK is present; real hardware #UDs
>>>   when both REX.W and LOCK are present, implying that these would
>>>   rather access hypothetical CR16...23
>>> - eliminate explicit decode_register() calls
>>> - streamline remaining read/write code
>>>
>>> No further functional change, i.e. not addressing the missing exception
>>> generation (#UD for invalid CR/DR encodings, #GP(0) for invalid write
>>> values, #DB for DR accesses with DR7.GD set).
>>>
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -194,7 +194,8 @@ static const opcode_desc_t twobyte_table
>>>  ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, 
>>> ImplicitOps|ModRM,
>>>  ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, 
>>> ImplicitOps|ModRM,
>>>  /* 0x20 - 0x27 */
>>> -ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, 
>>> ImplicitOps|ModRM,
>>> +DstMem|SrcImplicit|ModRM, DstMem|SrcImplicit|ModRM,
>>> +DstImplicit|SrcMem|ModRM, DstImplicit|SrcMem|ModRM,
>> These are Src/Dst Reg rather than Mem, although its not immediately
>> obvious how this would alter the outcome.
> No - SrcReg / DstReg describe operands encoded in bit 3..5 of a
> ModRM byte, whereas SrcMem / DstMem describe such encoded in
> bits 0..2 together with 6..7. The fact that mod is required to be 3
> for these insns isn't being expressed in the static table at all. (And
> I guess you then understand how getting this wrong here would
> affect the outcome.)

Ok.  Reviewed-by: Andrew Cooper 

I will fix the naming here.  The Mem part of {Src,Dst}Mem should be RM
to make things clearer.

~Andrew

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm  6 xen-boot   fail pass in 104104

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 104104 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-amd64-i386-libvirt  12 migrate-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-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-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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt 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-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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass

version targeted for testing:
 xen  ffc103c223a6d12e5221f66b7e96396a61ba1b20
baseline version:
 xen  ffc103c223a6d12e5221f66b7e96396a61ba1b20

Last test of basis   104119  2017-01-11 06:45:46 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17177 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
 bu

[Xen-devel] [PATCH] tools/libxc: Fix the reported max_leaf values for PV guests

[Andrew Cooper]

When iterating through CPUID leaves to generating a policy, libxc will clip
itself at the hardcoded maxima, meaning that no data outside of the hardcoded
maxima are provided to Xen (in turn, causing Xen to return zeros if these
leaves are requested.)

The HVM code also clips the max_leaf data reported to the guest, but the PV
side didn't.

This results in a PV guest using the emulated CPUID, or via Xen using CPUID
faulting, to observe a max_leaf higher than the toolstack wants, although with
zeros being returned in the intervening leaves.

Fix the PV side to behave like the HVM side, and clip the max_leaf values in
leaf 0 and 0x8000.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Ian Jackson 
CC: Wei Liu 

This should be backported to stable trees.

Discovered during my hypervisor-side work which does properly clip the
max_leaf values reported, at which point my diff against the guest-observable
CPUID information at the beginning of the series suddenly became non-zero.
---
 tools/libxc/xc_cpuid_x86.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index e9e3691..b32001b3 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -615,6 +615,11 @@ static void xc_cpuid_pv_policy(xc_interface *xch,
 {
 switch ( input[0] )
 {
+case 0x:
+if ( regs[0] > DEF_MAX_BASE )
+regs[0] = DEF_MAX_BASE;
+break;
+
 case 0x0001:
 {
 /* Host topology exposed to PV guest.  Provide host value. */
@@ -655,6 +660,16 @@ static void xc_cpuid_pv_policy(xc_interface *xch,
 xc_cpuid_config_xsave(xch, info, input, regs);
 break;
 
+case 0x8000:
+{
+unsigned int max = info->vendor == VENDOR_AMD
+? DEF_MAX_AMDEXT : DEF_MAX_INTELEXT;
+
+if ( regs[0] > max )
+regs[0] = max;
+break;
+}
+
 case 0x8001:
 {
 /* Host topology exposed to PV guest.  Provide host CMP_LEGACY value. 
*/
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 0/7] uapi: export all headers under uapi directories

[Jesper Nilsson]

On Mon, Jan 09, 2017 at 12:33:58PM +0100, Arnd Bergmann wrote:
> On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote:
> > Here is the v2 of this series. The first 5 patches are just cleanup: some
> > exported headers were still under a non-uapi directory.
> 
> Since this is meant as a cleanup, I commented on this to point out a cleaner
> way to do the same.
> 
> > The patch 6 was spotted by code review: there is no in-tree user of this
> > functionality.
> > The last patch remove the use of header-y. Now all files under an uapi
> > directory are exported.
> 
> Very nice!
> 
> > asm is a bit special, most of architectures export 
> > asm//include/uapi/asm
> > only, but there is two exceptions:
> >  - cris which exports arch/cris/include/uapi/arch-v[10|32];
> 
> This is interesting, though not your problem. Maybe someone who understands
> cris better can comment on this: How is the decision made about which of
> the arch/user.h headers gets used? I couldn't find that in the sources,
> but it appears to be based on kernel compile-time settings, which is
> wrong for user space header files that should be independent of the kernel
> config.

I believe it's since the CRISv10 and CRISv32 are very different beasts,
and that is selected via kernel config...

This part of the CRIS port has been transformed a couple of times from
the original layout without uapi, and there's still some legacy silliness,
where some files might have been exported but never used from userspace
except for some corner cases.

> >  - tile which exports arch/tile/include/uapi/arch.
> > Because I don't know if the output of 'make headers_install_all' can be 
> > changed,
> > I introduce subdir-y in Kbuild file. The headers_install_all target copies 
> > all
> > asm//include/uapi/asm to usr/include/asm- but
> > arch/cris/include/uapi/arch-v[10|32] and arch/tile/include/uapi/arch are not
> > prefixed (they are put asis in usr/include/). If it's acceptable to modify 
> > the
> > output of 'make headers_install_all' to export asm headers in
> > usr/include/asm-/asm, then I could remove this new subdir-y and 
> > exports
> > everything under arch//include/uapi/.
> 
> I don't know if anyone still uses "make headers_install_all", I suspect
> distros these days all use "make headers_install", so it probably
> doesn't matter much.
> 
> In case of cris, it should be easy enough to move all the contents of the
> uapi/arch-*/*.h headers into the respective uapi/asm/*.h headers, they
> only seem to be referenced from there.

This would seem to be a reasonable change.

> For tile, I suspect that would not work as the arch/*.h headers are
> apparently defined as interfaces for both user space and kernel.
> 
> > Note also that exported files for asm are a mix of files listed by:
> >  - include/uapi/asm-generic/Kbuild.asm;
> >  - arch/x86/include/uapi/asm/Kbuild;
> >  - arch/x86/include/asm/Kbuild.
> > This complicates a lot the processing (arch/x86/include/asm/Kbuild is also
> > used by scripts/Makefile.asm-generic).
> > 
> > This series has been tested with a 'make headers_install' on x86 and a
> > 'make headers_install_all'. I've checked the result of both commands.
> > 
> > This patch is built against linus tree. I don't know if it should be
> > made against antoher tree.
> 
> The series should probably get merged through the kbuild tree, but testing
> it on mainline is fine here.
> 
>   Arnd

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com

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

Re: [Xen-devel] [PATCH v13 1/3] iommu VT-d: separate rmrr addition function.

[Jan Beulich]

>>> On 10.01.17 at 23:57,  wrote:
> @@ -628,65 +690,10 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>  ret = acpi_parse_dev_scope(dev_scope_start, dev_scope_end,
> &rmrru->scope, RMRR_TYPE, rmrr->segment);
>  
> -if ( ret || (rmrru->scope.devices_cnt == 0) )
> -xfree(rmrru);
> +if ( !ret && (rmrru->scope.devices_cnt != 0) )
> +register_one_rmrr(rmrru);

You've lost the return value here.

Jan


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 462a3eba8feaf3716d294111725742ff5aa08488
baseline version:
 ovmf 363dc42226a1d8ae02c73f9dd81da65af91b5fdd

Last test of basis68353  2017-01-10 13:47:36 Z0 days
Testing same since68356  2017-01-10 22:22:03 Z0 days1 attempts


People who touched revisions under test:
  Michael D Kinney 
  Michael Kinney 

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



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

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

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


Push not applicable.


commit 462a3eba8feaf3716d294111725742ff5aa08488
Author: Michael Kinney 
Date:   Sat Jan 7 11:13:32 2017 -0800

Nt32Pkg/WinNtSimpleFileSystemDxe: Fix ASSERT() parsing '\'

https://bugzilla.tianocore.org/show_bug.cgi?id=331

If Nt32 is built using UEFI Shell from the ShellPkg sources,
an ASSERT() is generated when a single '\' character is
entered at the shell prompt.

The WinNtSimpleFileSystemDxe module GetNextFileNameToken()
function breaks a file path up into tokens, but it does not
handle the case where a FileName ends in a '\' character.
It returns an empty string instead of NULL.  The fix is
to set *FileName to NULL if the remaining file path is an
empty string.

Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney 
Reviewed-by: Jaben Carsey 
Reviewed-by: Ruiyu Ni 

commit 0f705029d91559030bfa5f505daca57dcefd1a2e
Author: Michael Kinney 
Date:   Wed Jan 4 09:06:32 2017 -0800

MdePkg/Include: Add include file to FileHandleLib.h

FileHandleLib.h uses the data type EFI_FILE_INFO,
so this library class should include .

Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
Reviewed-by: Liming Gao 

commit 7328295cb247f420e0c465c19184c13ccbed5416
Author: Michael Kinney 
Date:   Wed Jan 4 13:32:53 2017 -0800

MdeModulePkg/DxeCore: Fix ASSERT() from GCD DEBUG() messages

If a BaseAddress of NULL is passed into DXE Core services
CoreAllocateIoSpace() or CoreAllocateMemorySpace(), and
DEBUG() messages are enabled, then a NULL pointer reference
is made.  The parameter check for BaseAddress is performed
in the function CoreAllocateSpace() after the DEBUG()
messages.  A check is added in the DEBUG() messages to
prevent the NULL pointer reference.

This issue was found with PI SCTs with DEBUG messages
enabled in the DXE Core.

Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
Reviewed-by: Star Zeng 
Reviewed-by: Feng Tian 
Reviewed-by: Liming Gao 

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

[Xen-devel] [qemu-mainline baseline-only test] 68355: trouble: broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 68348
 test-amd64-amd64-pair4 host-install/dst_host(4) broken REGR. vs. 68348
 test-amd64-amd64-amd64-pvgrub  3 host-install(3)broken REGR. vs. 68348

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

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-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-libvirt 14 guest-saverestorefail   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-xsm  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-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-amd64-amd64-libvirt 12 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-amd64-amd64-xl-pvh-amd  11 guest-start  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-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:
 qemuuf634151b02ce5c80605383894f1f63f2c12e0033
baseline version:
 qemuu77424a452abe5f941d8cd81f1e85f42bca31c9ef

Last test of basis68348  2017-01-10 00:45:00 Z1 days
Testing same since68355  2017-01-10 16:47:22 Z0 days1 attempts


People who touched revisions under test:
  Aurelien Jarno 
  James Hogan 
  Jin Guojie 
  Peter Maydell 
  Richard Henderson 
  YunQiang Su 

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  

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0772737347816ced8df6299b1c88cccb9de9164c
baseline version:
 ovmf 7c14bc8769fbe1670e3b3d09d6cd531713eb74a4

Last test of basis   104113  2017-01-11 05:45:23 Z0 days
Testing same since   104121  2017-01-11 08:45:34 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=0772737347816ced8df6299b1c88cccb9de9164c
+ . ./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 
0772737347816ced8df6299b1c88cccb9de9164c
+ branch=ovmf
+ revision=0772737347816ced8df6299b1c88cccb9de9164c
+ . ./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
+ '[' x0772737347816ced8df6299b1c88cccb9de9164c = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/

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

[anshul makkar]

On 11/01/17 05:37, Tian, Kevin wrote:

From: Anshul Makkar [mailto:anshul.mak...@citrix.com]
Sent: Friday, January 06, 2017 2:42 AM

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

Signed-off-by: Anshul Makkar 

Then let's do it when it's really required. :-)


I needed it to debug an issue, found it missing and that's why I added.  
I have a sanity test, that continuously uses it.  There may be other 
users out there who can use it for similar or some other purpose. Having 
it in standard code base will do no harm.


Thanks
Kevin

Anshul


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  ffc103c223a6d12e5221f66b7e96396a61ba1b20
baseline version:
 xen  9009ea4706b10798878ab8dfe34e40dbf315c339

Last test of basis   104077  2017-01-08 09:19:43 Z3 days
Testing same since   104122  2017-01-11 09:18:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Cédric Bosdonnat 
  Doug Goldstein 
  Eric DeVolder 
  He Chen 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Suravee Suthikulpanit 
  Wei Liu 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH 2/2] xen/kbdif: add multi-touch support

[Oleksandr Andrushchenko]

On 01/11/2017 02:29 AM, Stefano Stabellini wrote:

On Tue, 10 Jan 2017, Oleksandr Andrushchenko wrote:

On 01/07/2017 12:37 AM, Stefano Stabellini wrote:

On Fri, 6 Jan 2017, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Signed-off-by: Oleksandr Andrushchenko 
---
   xen/include/public/io/kbdif.h | 228
++
   1 file changed, 228 insertions(+)

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index 0e19a40..1b446f9 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -57,6 +57,12 @@
*  Backends, which support reporting of absolute coordinates for
pointer
*  device should set this to 1.
*
+ * feature-multi-touch
+ *  Values: 
+ *
+ *  Backends, which support reporting of multi-touch events
+ *  should set this to 1.
+ *
*- Pointer Device Parameters

*
* width
@@ -87,6 +93,11 @@
*  Request from backend to report absolute pointer coordinates
*  (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION).
*
+ * request-multi-touch
+ *  Values: 
+ *
+ *  Request from backend to report multi-touch events.

I think in English should be "request backend to report multi-touch
events". Same above.

Done

+ *
*--- Request Transport Parameters
---
*
* event-channel
@@ -107,6 +118,43 @@
*  OBSOLETE, not recommended for use.
*  A unique (within the guest domain given) value identifying event
*  channel and page reference pair.
+ *
+ *--- Multi-touch Device Parameters
---
+ *
+ * Every multi-touch input device uses a dedicated event ring and is

For clarity I would say "Every multi-touch input device uses a dedicated
frontend/backend connection". That includes a ring, an event channel,
and xenstore entries.


Done

+ * configured via XenStore properties under XENKBD_PATH_MTOUCH folder.

I don't understand why we need a new xenstore folder. Why do we need
XENKBD_PATH_MTOUCH?

This is just another (IMO, cleaner) approach to define
properties in XenStore for multiple instances.
Let's see what vif does on my PC:
/local/domain/11/device/vif/0/queue-0/tx-ring-ref = "2304"
...
/local/domain/11/device/vif/0/queue-1/tx-ring-ref = "2306"
...
/local/domain/11/device/vif/0/queue-2/tx-ring-ref = "2308"
...
/local/domain/11/device/vif/0/queue-3/tx-ring-ref = "2310"
...
/local/domain/11/device/vif/0/request-rx-copy = "1"

We have folders "queue-%d" per queue which in my case are

under XENKBD_PATH_MTOUCH.

/local/domain/11/device/vkbd/0/mtouch/0/width = "3200"
/local/domain/11/device/vkbd/0/mtouch/0/height = "3200"
/local/domain/11/device/vkbd/0/mtouch/0/num-contacts = "5"
/local/domain/11/device/vkbd/0/mtouch/1/width = "6400"
/local/domain/11/device/vkbd/0/mtouch/1/height = "6400"
/local/domain/11/device/vkbd/0/mtouch/1/num-contacts = "10"

Namely, instead of "mtouch-%d" I use "mtouch/%d/.
This is just like using "/local/domain/%d" but not
"/local/domain-%d", so "mtouch/%d" seem to be more
consistent.

I agree that mtouch/%d is better than mtouch-%d, but it's only necessary
if we have more than one mtouch per vkbd. I would configure it so that
one can only have one mtouch per vkbd:

   /local/domain/11/device/vkbd/0/mtouch/width = "3200"
   /local/domain/11/device/vkbd/0/mtouch/height = "3200"
   /local/domain/11/device/vkbd/1/mtouch/width = "6400"
   /local/domain/11/device/vkbd/1/mtouch/height = "6400"

correct me if I'm wrong, but this notation implies
multiple drivers support, not a single driver with
multiple devices.
If so, *DISCLAIMER* *Linux* I see no simple solution to
do that in the front driver.
Could you please clarify?

This is also what I was referring to when I wrote:


It is useful to distinguish mouse events from keyboard events, from
multitouch events more easily, but I don't think we should support
multiple keyboards or multiple mice on the same xenkbd ring. If we need
two mice, we can setup two xenkdb rings.

The same applies to multitouch devices, I think.

But maybe you have good reasons for supporting multiple multitouch
devices on a single vkbd connection? How many do you expect to have on a
single VM?

well, let me put the whole tree from xenstore:

/local/domain/0/backend/vkbd/2/0/frontend-id = "2"
/local/domain/0/backend/vkbd/2/0/frontend = "/local/domain/2/device/vkbd/0"
/local/domain/0/backend/vkbd/2/0/dev_id = "0"
/local/domain/0/backend/vkbd/2/0/state = "6"
/local/domain/0/backend/vkbd/2/0/feature-abs-pointer = "1"
/local/domain/0/backend/vkbd/2/0/width = "2048"
/local/domain/0/backend/vkbd/2/0/height = "2048"
/local/domain/0/backend/vkbd/2/0/feature-multi-touch = "1"

/local/domain/2/device/vkbd/0/backend-id = "0"
/local/domain/2/device/vkbd/0/backend = "/local/domain/0/backend/vkbd/2/0"
/local/domain/2/device/vkbd/0/state = "6"
/local/domain

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 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-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-armhf-armhf-libvirt 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-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  b29f7528ec044060304d0f540a36a68c2f1076d9
baseline version:
 libvirt  ae16c95f1bb5591c27676c5de8d383e5612c3568

Last test of basis   104093  2017-01-10 04:20:50 Z1 days
Testing same since   104110  2017-01-11 04:19:54 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Chen Hanxiao 
  Dawid Zamirski 
  Eric Blake 
  Jim Fehlig 
  John Ferlan 
  Laine Stump 
  Michal Privoznik 
  Peter Krempa 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=b29f7528ec044060304d0f540a36a68c2f1076d9
+ . ./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=/h

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-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-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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-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-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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuub44486dfb9447c88e4b216e730adcc780190852c
baseline version:
 qemuu41a0e54756a9ae6b60be34bb33302a7e085fdb07

Last test of basis   104100  2017-01-10 16:45:31 Z0 days
Testing same since   104106  2017-01-11 01:46:06 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Daniel P. Berrange 
  Frediano Ziglio 
  Gerd Hoffmann 
  Gonglei 
  Hervé Poussineau 
  Marc-André Lureau 
  OGAWA Hirofumi 
  Peter Maydell 
  Samuel Thibault 
  Stefan Hajnoczi 
  Stefan Weil 
  Thomas Huth 

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 

Re: [Xen-devel] [PATCH 0/2] xen/kbdif: add multi-touch support

[Oleksandr Andrushchenko]

As agreed on PV call PFA pahole results


On 01/06/2017 11:32 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Hi, all!

This series updates existing kbdif protocol documentation
and adds multi-touch support

Thank you,
Oleksandr Andrushchenko

Oleksandr Andrushchenko (2):
   xen/kbdif: update protocol documentation
   xen/kbdif: add multi-touch support

  xen/include/public/io/kbdif.h | 477 +++---
  1 file changed, 450 insertions(+), 27 deletions(-)



struct xenkbd_motion {
uint8_ttype; /* 0 1 */

/* XXX 3 bytes hole, try to pack */

int32_trel_x;/* 4 4 */
int32_trel_y;/* 8 4 */
int32_trel_z;/*12 4 */

/* size: 16, cachelines: 1, members: 4 */
/* sum members: 13, holes: 1, sum holes: 3 */
/* last cacheline: 16 bytes */
};
struct xenkbd_key {
uint8_ttype; /* 0 1 */
uint8_tpressed;  /* 1 1 */

/* XXX 2 bytes hole, try to pack */

uint32_t   keycode;  /* 4 4 */

/* size: 8, cachelines: 1, members: 3 */
/* sum members: 6, holes: 1, sum holes: 2 */
/* last cacheline: 8 bytes */
};
struct xenkbd_position {
uint8_ttype; /* 0 1 */

/* XXX 3 bytes hole, try to pack */

int32_tabs_x;/* 4 4 */
int32_tabs_y;/* 8 4 */
int32_trel_z;/*12 4 */

/* size: 16, cachelines: 1, members: 4 */
/* sum members: 13, holes: 1, sum holes: 3 */
/* last cacheline: 16 bytes */
};
struct xenkbd_mtouch {
uint8_ttype; /* 0 1 */
uint8_tevent_type;   /* 1 1 */
uint8_tcontact_id;   /* 2 1 */
uint8_treserved[5];  /* 3 5 */
union {
struct {
int32_tabs_x;/* 8 4 */
int32_tabs_y;/*12 4 */
} pos;   /*   8 */
struct {
uint32_t   major;/* 8 4 */
uint32_t   minor;/*12 4 */
} shape; /*   8 */
int16_torientation;  /*   2 */
} u; /* 8 8 */

/* size: 16, cachelines: 1, members: 5 */
/* last cacheline: 16 bytes */
};
struct xenkbd_page {
uint32_t   in_cons;  /* 0 4 */
uint32_t   in_prod;  /* 4 4 */
uint32_t   out_cons; /* 8 4 */
uint32_t   out_prod; /*12 4 */

/* size: 16, cachelines: 1, members: 4 */
/* last cacheline: 16 bytes */
};
struct xenkbd_motion {
uint8_ttype; /* 0 1 */

/* XXX 3 bytes hole, try to pack */

int32_trel_x;/* 4 4 */
int32_trel_y;/* 8 4 */
int32_trel_z;/*12 4 */

/* size: 16, cachelines: 1, members: 4 */
/* sum members: 13, holes: 1, sum holes: 3 */
/* last cacheline: 16 bytes */
};
struct xenkbd_key {
uint8_ttype; /* 0 1 */
uint8_tpressed;  /* 1 1 */

/* XXX 2 bytes hole, try to pack */

uint32_t   keycode;  /* 4 4 */

/* size: 8, cachelines: 1, members: 3 */
/* sum members: 6, holes: 1, sum holes: 2 */
/* last cacheline: 8 bytes */
};
struct xenkbd_position {
uint8_ttype; /* 0 1 */

/* XXX 3 bytes hole, try to pack */

int32_tabs_x;/* 4 4 */
int32_tabs_y;/* 8 4 */
int32_trel_z;/*12 4 */

/* size: 16, cachelines: 1, members: 4 */
/* sum members: 13, holes: 1, sum holes: 3 */
/* last cacheline: 16 bytes */
};
struct xenkbd_mtouch {
uint8_t 

Re: [Xen-devel] [PATCH v15] sndif: add ABI for para-virtual sound

[Oleksandr Andrushchenko]

As agreed on PV call PFA pahole results


On 12/05/2016 03:05 PM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Hi, all!

Please find the next version of the ABI for the PV sound
after addressing review comments.

Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov

Oleksandr Andrushchenko (1):
   This is the ABI for the two halves of a para-virtualized sound
 driver to communicate with each to other.

  xen/include/public/io/sndif.h | 671 ++
  1 file changed, 671 insertions(+)
  create mode 100644 xen/include/public/io/sndif.h



struct xensnd_open_req {
uint32_t   pcm_rate; /* 0 4 */
uint8_tpcm_format;   /* 4 1 */
uint8_tpcm_channels; /* 5 1 */
uint16_t   reserved; /* 6 2 */
uint32_t   buffer_sz;/* 8 4 */
grant_ref_tgref_directory_start; /*12 4 */

/* size: 16, cachelines: 1, members: 6 */
/* last cacheline: 16 bytes */
};
struct xensnd_page_directory {
grant_ref_tgref_dir_next_page;   /* 0 4 */
grant_ref_tgref[1];  /* 4 4 */

/* size: 8, cachelines: 1, members: 2 */
/* last cacheline: 8 bytes */
};
struct xensnd_rw_req {
uint32_t   offset;   /* 0 4 */
uint32_t   len;  /* 4 4 */

/* size: 8, cachelines: 1, members: 2 */
/* last cacheline: 8 bytes */
};
struct xensnd_req {
uint16_t   id;   /* 0 2 */
uint8_toperation;/* 2 1 */
uint8_tstream_idx;   /* 3 1 */
uint32_t   reserved; /* 4 4 */
union {
struct xensnd_open_req open; /*  16 */
struct xensnd_rw_req rw; /*   8 */
uint8_treserved[24]; /*  24 */
} op;/* 824 */

/* size: 32, cachelines: 1, members: 5 */
/* last cacheline: 32 bytes */
};
struct xensnd_resp {
uint16_t   id;   /* 0 2 */
uint8_toperation;/* 2 1 */
uint8_tstream_idx;   /* 3 1 */
int8_t status;   /* 4 1 */
uint8_treserved[27]; /* 527 */

/* size: 32, cachelines: 1, members: 5 */
/* last cacheline: 32 bytes */
};
struct xensnd_open_req {
uint32_t   pcm_rate; /* 0 4 */
uint8_tpcm_format;   /* 4 1 */
uint8_tpcm_channels; /* 5 1 */
uint16_t   reserved; /* 6 2 */
uint32_t   buffer_sz;/* 8 4 */
grant_ref_tgref_directory_start; /*12 4 */

/* size: 16, cachelines: 1, members: 6 */
/* last cacheline: 16 bytes */
};
struct xensnd_page_directory {
grant_ref_tgref_dir_next_page;   /* 0 4 */
grant_ref_tgref[1];  /* 4 4 */

/* size: 8, cachelines: 1, members: 2 */
/* last cacheline: 8 bytes */
};
struct xensnd_rw_req {
uint32_t   offset;   /* 0 4 */
uint32_t   len;  /* 4 4 */

/* size: 8, cachelines: 1, members: 2 */
/* last cacheline: 8 bytes */
};
struct xensnd_req {
uint16_t   id;   /* 0 2 */
uint8_toperation;/* 2 1 */
uint8_tstream_idx;   /* 3 1 */
uint32_t   reserved; /* 4 4 */
union {
struct xensnd_open_req open; /*  16 */
struct xensnd_rw_req rw; /*   8 */
uint8_treserved[24]; /*  24 */
} op;/* 824 */

/* size: 32, cachelines: 1, members: 5 */
/* last cacheline: 32 bytes */
};
struct xensnd_resp {
uint16_t   id;   /* 0 2 */
uint8_toperation;/* 2 1 */
uint8_tstream_idx;   /* 3   

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

[Oleksandr Andrushchenko]

As agreed on PV call PFA pahole results


On 12/22/2016 10:12 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

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

Oleksandr Andrushchenko (1):
   displif: add ABI for para-virtual display

  xen/include/public/io/displif.h | 730 
  1 file changed, 730 insertions(+)
  create mode 100644 xen/include/public/io/displif.h



struct xendispl_dbuf_create_req {
uint64_t   dbuf_cookie;  /* 0 8 */
uint32_t   width;/* 8 4 */
uint32_t   height;   /*12 4 */
uint32_t   bpp;  /*16 4 */
uint32_t   buffer_sz;/*20 4 */
uint32_t   flags;/*24 4 */
grant_ref_tgref_directory_start; /*28 4 */

/* size: 32, cachelines: 1, members: 7 */
/* last cacheline: 32 bytes */
};
struct xendispl_page_directory {
grant_ref_tgref_dir_next_page;   /* 0 4 */
grant_ref_tgref[1];  /* 4 4 */

/* size: 8, cachelines: 1, members: 2 */
/* last cacheline: 8 bytes */
};
struct xendispl_dbuf_destroy_req {
uint64_t   dbuf_cookie;  /* 0 8 */

/* size: 8, cachelines: 1, members: 1 */
/* last cacheline: 8 bytes */
};
struct xendispl_fb_attach_req {
uint64_t   dbuf_cookie;  /* 0 8 */
uint64_t   fb_cookie;/* 8 8 */
uint32_t   width;/*16 4 */
uint32_t   height;   /*20 4 */
uint32_t   pixel_format; /*24 4 */

/* size: 28, cachelines: 1, members: 5 */
/* last cacheline: 28 bytes */
};
struct xendispl_fb_detach_req {
uint64_t   fb_cookie;/* 0 8 */

/* size: 8, cachelines: 1, members: 1 */
/* last cacheline: 8 bytes */
};
struct xendispl_set_config_req {
uint64_t   fb_cookie;/* 0 8 */
uint32_t   x;/* 8 4 */
uint32_t   y;/*12 4 */
uint32_t   width;/*16 4 */
uint32_t   height;   /*20 4 */
uint32_t   bpp;  /*24 4 */

/* size: 28, cachelines: 1, members: 6 */
/* last cacheline: 28 bytes */
};
struct xendispl_page_flip_req {
uint64_t   fb_cookie;/* 0 8 */

/* size: 8, cachelines: 1, members: 1 */
/* last cacheline: 8 bytes */
};
struct xendispl_pg_flip_evt {
uint64_t   fb_cookie;/* 0 8 */

/* size: 8, cachelines: 1, members: 1 */
/* last cacheline: 8 bytes */
};
struct xendispl_req {
uint16_t   id;   /* 0 2 */
uint8_toperation;/* 2 1 */
uint8_treserved[5];  /* 3 5 */
union {
struct xendispl_dbuf_create_req dbuf_create; /*  32 */
struct xendispl_dbuf_destroy_req dbuf_destroy; /*   8 */
struct xendispl_fb_attach_req fb_attach; /*  28 */
struct xendispl_fb_detach_req fb_detach; /*   8 */
struct xendispl_set_config_req set_config; /*  28 */
struct xendispl_page_flip_req pg_flip;   /*   8 */
uint8_treserved[56]; /*  56 */
} op;/* 856 */

/* size: 64, cachelines: 1, members: 4 */
};
struct xendispl_resp {
uint16_t   id;   /* 0 2 */
uint8_toperation;/* 2 1 */
int8_t status;   /* 3 1 */
uint8_treserved[60]; /* 460 */

/* size: 64, cachelines: 1, members: 4 */
};
struct xendispl_evt {
uint16_t   id;   /* 0 2 */
uint8_ttype; /*