[Xen-devel] [linux-3.18 bisection] complete test-amd64-i386-xl-qemut-win7-amd64

[osstest service owner]

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

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  Bug introduced:  24542192519d21719377d89f14654b3afd993a61
  Bug not present: c6f51aabaf400f357eebe8f8f17e8bb39fc033dc
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103834/


  commit 24542192519d21719377d89f14654b3afd993a61
  Author: Kashyap Desai 
  Date:   Fri Oct 21 06:33:32 2016 -0700
  
  scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) 
devices
  
  [ Upstream commit 1e793f6fc0db920400574211c48f9157a37e3945 ]
  
  Commit 02b01e010afe ("megaraid_sas: return sync cache call with
  success") modified the driver to successfully complete SYNCHRONIZE_CACHE
  commands without passing them to the controller. Disk drive caches are
  only explicitly managed by controller firmware when operating in RAID
  mode. So this commit effectively disabled writeback cache flushing for
  any drives used in JBOD mode, leading to data integrity failures.
  
  [mkp: clarified patch description]
  
  Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
  CC: sta...@vger.kernel.org
  Signed-off-by: Kashyap Desai 
  Signed-off-by: Sumit Saxena 
  Reviewed-by: Tomas Henzl 
  Reviewed-by: Hannes Reinecke 
  Reviewed-by: Ewan D. Milne 
  Signed-off-by: Martin K. Petersen 
  Signed-off-by: Sasha Levin 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-3.18/test-amd64-i386-xl-qemut-win7-amd64.xen-boot
 --summary-out=tmp/103834.bisection-summary --basis-template=101675 
--blessings=real,real-bisect linux-3.18 test-amd64-i386-xl-qemut-win7-amd64 
xen-boot
Searching for failure / basis pass:
 103688 fail [host=elbling1] / 101675 ok.
Failure / basis pass flights: 103688 / 101675
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest ac3d826bef907afe35f80ecccbcdd57223df4b88 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b669e922b37b8957248798a5eb7aa96a666cd3fe 
4220231eb22235e757d269722b9f6a594fbcb70f 
fc9229c4bb35c5474fbc67f78e628dcbcc90afc5
Basis pass a6846cfd266b48af1ee7c3c19d5cb60477ca4469 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
6f9b62ca57322197e26d3b22ff11b629697142bd
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#a6846cfd266b48af1ee7c3c19d5cb60477ca4469-ac3d826bef907afe35f80ecccbcdd57223df4b88
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c4e0d84d3c92923fdbc7fa922638d54e5e834753-b669e922b37b8957248798a5eb7aa96a666cd3fe
 
git://xenbits.xen.org/qemu-xen.git#6cfcdf037edadba984ccf8476b5d1e2a0940b789-4220231eb22235e757d269722b9f6a594fbcb70f
 
git://xenbits.xen.org/xen.git#6f9b62ca57322197e26d3b22ff11b629697142bd-fc9229c4bb35c5474fbc67f78e628dcbcc90afc5
Loaded 6010 nodes in revision graph
Searching for test results:
 101648 pass irrelevant
 101662 pass irrelevant
 101675 pass a6846cfd266b48af1ee7c3c19d5cb60477ca4469 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
6f9b62ca57322197e26d3b22ff11b629697142bd
 102732 []
 102754 fail irrelevant
 102773 fail ac3d826bef907afe35f80ecccbcdd57223df4b88 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
89c4cbe8d234049b0145e4dc5e5d19d626250b57 
4220231eb22235e757d269722b9f6a594fbcb70f 
a7a578ce6b8634eec30cb8445ea98e18d9b4e9b8
 102823 fail ac3d826bef907afe35f80ecccbcdd57223df4b88 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
89c4cbe8d234049b0145e4dc5e5d19d626250b57 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 68230
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 68230
 test-amd64-i386-xl   19 guest-start/debian.repeat fail REGR. vs. 68230
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
68230
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
68230
 test-amd64-i386-qemuu-rhel6hvm-amd 14 leak-check/checkfail REGR. vs. 68230

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386 10 guest-start  fail like 68230
 test-amd64-amd64-qemuu-nested-intel  9 debian-hvm-install  fail like 68230
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail like 68230
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68230

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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-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-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 qemuu82ecffa8c050bf5bbc13329e9b65eac1caa5b55c
baseline version:
 qemuu6a928d25b6d8bc3729c3d28326c6db13b9481059

Last test of basis68230  2016-12-16 14:47:06 Z6 days
Testing same since68261  2016-12-22 23:21:47 Z0 days1 attempts


People who touched revisions under test:
  Stefan Hajnoczi 

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   

Re: [Xen-devel] [PATCH] tpm: Restore functionality to xen vtpm driver.

[Greg KH]

On Thu, Dec 22, 2016 at 02:41:52PM -0600, Dr. Greg Wettstein wrote:
> Functionality of the xen-tpmfront driver was lost secondary to
> the introduction of xenbus multi-page support in the following
> commit:
> 
> ccc9d90a9a8b5c4ad7e9708ec41f75ff9e98d61d
> 
> xenbus_client: Extend interface to support multi-page ring
> 
> In this commit a pointer to the shared page address was being
> passed to the xenbus_grant_ring() function rather then the
> address of the shared page itself.  This resulted in a situation
> where the driver would attach to the vtpm-stubdom but any attempt
> to send a command to the stub domain would timeout.
> 
> A diagnostic finding for this regression is the following error
> message being generated when the xen-tpmfront driver probes for a
> device:
> 
> <3>vtpm vtpm-0: tpm_transmit: tpm_send: error -62
> 
> <3>vtpm vtpm-0: A TPM error (-62) occurred attempting to determine the 
> timeouts
> 
> This fix is relevant to all kernels from 4.1 forward which is the
> release in which multi-page xenbus support was introduced.
> 
> Daniel De Graaf formulated the fix by code inspection after the
> regression point was located.
> 
> Signed-off-by: Dr. Greg Wettstein 



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.



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

[Xen-devel] [linux-4.1 test] 103799: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 101737
 test-amd64-amd64-xl-multivcpu  6 xen-bootfail REGR. vs. 101737
 test-amd64-amd64-xl-pvh-intel  6 xen-bootfail REGR. vs. 101737
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 101737
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot  fail REGR. vs. 101737
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101737
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101737
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 101737
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-boot   fail REGR. vs. 101737
 test-amd64-i386-freebsd10-amd64  6 xen-boot  fail REGR. vs. 101737
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101737
 build-armhf-pvops 5 kernel-build   fail in 102733 REGR. vs. 101737

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 103011 pass in 
103799
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 103011 pass in 
103799
 test-amd64-i386-xl   3 host-install(3) broken in 103011 pass in 103799
 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 103011 pass 
in 103799
 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 103011 pass 
in 103799
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 103011 
pass in 103799
 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken in 103749 pass in 
103799
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 103749 pass in 
103799
 test-amd64-amd64-xl-multivcpu 3 host-install(3) broken in 103784 pass in 103799
 test-amd64-amd64-xl-pvh-intel 3 host-install(3) broken in 103784 pass in 103799
 test-amd64-amd64-xl-xsm  3 host-install(3) broken in 103784 pass in 103799
 test-amd64-i386-libvirt-xsm  3 host-install(3) broken in 103784 pass in 103799
 test-amd64-i386-xl-qemut-win7-amd64 3 host-install(3) broken in 103784 pass in 
103799
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 103784 pass in 
103799
 test-amd64-amd64-i386-pvgrub 3 host-install(3) broken in 103784 pass in 103799
 test-amd64-amd64-pygrub  3 host-install(3) broken in 103784 pass in 103799
 test-amd64-amd64-libvirt-vhd 9 debian-di-install fail in 102733 pass in 102886
 test-amd64-amd64-xl-xsm 19 guest-start/debian.repeat fail in 102755 pass in 
103089
 test-armhf-armhf-libvirt-xsm 14 guest-stop   fail in 102755 pass in 103799
 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 102829 pass in 103799
 test-amd64-i386-xl-xsm6 xen-boot fail in 102886 pass in 103799
 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail in 102886 pass in 
103799
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 102886 pass 
in 103799
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 103011 
pass in 103799
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail in 103011 pass in 103799
 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 103089 pass 
in 103799
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail in 103451 pass in 103799
 test-armhf-armhf-xl-credit2   6 xen-boot fail in 103749 pass in 103799
 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail in 103749 pass in 
103799
 test-armhf-armhf-xl-arndale   5 xen-install  fail in 103749 pass in 103799
 test-armhf-armhf-libvirt 11 guest-start  fail in 103784 pass in 103799
 test-armhf-armhf-xl-rtds  9 debian-install   fail in 103784 pass in 103799
 test-amd64-i386-xl-raw6 xen-boot   fail pass in 102733
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 102733
 test-amd64-amd64-libvirt  6 xen-boot   fail pass in 102733
 test-amd64-i386-libvirt-xsm   6 xen-boot   fail pass in 102755
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot fail pass in 102755
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot   fail pass in 102829
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
102886
 test-amd64-amd64-libvirt-vhd  6 xen-boot   fail pass in 102886
 test-amd64-i386-freebsd10-i386  6 xen-boot fail pass in 103011
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 103089
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail pass in 103089
 test-amd64-amd64-xl-xsm   6 xen-boot   fail pass in 103089
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host   

Re: [Xen-devel] [PATCH 01/10] x86/MSR: introduce MSR access split/fold helpers

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, December 20, 2016 6:36 PM
> 
> This is in preparation of eliminating the mis-naming of 64-bit fields
> with 32-bit register names (eflags instead of rflags etc). Use the
> guaranteed 32-bit underscore prefixed names for now where appropriate.
> 
> Signed-off-by: Jan Beulich 
> 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, December 22, 2016 11:37 PM
> 
> >>> On 22.12.16 at 16:14,  wrote:
> > On 22/12/16 14:58, Jan Beulich wrote:
> > On 22.12.16 at 15:31,  wrote:
> >> On 22.12.16 at 14:47,  wrote:
>  On 22/12/16 08:37, Jan Beulich wrote:
> > Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
> > determine whether to install the hook in the first place.
> >
> > Signed-off-by: Jan Beulich 
>  I am not so sure about this.
> 
>  vmfunc is reachable in the instruction emulator on hardware which
>  doesn't support vmfunc, and there is explicit provision for using vmfunc
>  0 via hypercall on hardware lacking vmfunc support.
> 
>  Given that the #VE part of altp2m is always emulated architecturally, I
>  think there is an argument to be made for also emulating EPTP switching
>  architecturally as well.
> >>> I don't understand this argumentation: Without the patch, the
> >>> hook function checks !cpu_has_vmx_vmfunc (and fails otherwise);
> >>> with the patch the hook isn't being put in place when
> >>> !cpu_has_vmx_vmfunc, and failure occurs in hvmemul_vmfunc().
> >>> I admit there's the difference in error codes, but we could
> >>> certainly make hvmemul_vmfunc() return EXCEPTION when
> >>> there's no hook.
> >> And btw., installing altp2m_vcpu_update_vmfunc_ve is as pointless
> >> in the opposite case, do it bailing early when !cpu_has_vmx_vmfunc.
> >> I guess I'll do both changes for a v2.
> >
> > My argument is that, instead of excluding the hook, the behaviour of the
> > emulation path should be made to function sensibly even on hardware
> > without vmfunc.
> >
> > i.e. drop the cpu_has_vmx_vmfunc check and do nothing else.
> 
> Ah, I see. I guess I'll leave that to someone having an environment
> to test this. The patch's goal was to not change observable behavior.
> 

If later we'll have to again get hook always installed (for hardware w/o 
vmfunc), I'm hesitant to ack this version...

Thanks
Kevin

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

[Xen-devel] [xen-4.6-testing baseline-only test] 68260: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-xtf-amd64-amd64-5   20 xtf/test-hvm32-invlpg~shadow fail   like 68255
 test-xtf-amd64-amd64-5  32 xtf/test-hvm32pae-invlpg~shadow fail like 68255
 test-xtf-amd64-amd64-5   43 xtf/test-hvm64-invlpg~shadow fail   like 68255
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail   like 68255
 test-xtf-amd64-amd64-1   20 xtf/test-hvm32-invlpg~shadow fail   like 68255
 test-xtf-amd64-amd64-3  32 xtf/test-hvm32pae-invlpg~shadow fail like 68255
 test-xtf-amd64-amd64-1  32 xtf/test-hvm32pae-invlpg~shadow fail like 68255
 test-xtf-amd64-amd64-3   43 xtf/test-hvm64-invlpg~shadow fail   like 68255
 test-xtf-amd64-amd64-1   43 xtf/test-hvm64-invlpg~shadow fail   like 68255
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 68255
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 68255
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68255
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 68255
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 68255

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386 10 rumprun-demo-xenstorels/xenstorels fail never 
pass
 test-xtf-amd64-amd64-4   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   62 xtf/test-pv32pae-xsa-194 fail   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-xtf-amd64-amd64-5   62 xtf/test-pv32pae-xsa-194 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-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-xtf-amd64-amd64-3   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   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-amd64-rumprun-amd64 10 rumprun-demo-xenstorels/xenstorels fail 
never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-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-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-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-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  2eb074fddbecf40e0cdac5c5fe28fb6c7b5cc371
baseline version:
 xen  aa281a16db9a46911c78a30998c15810aa8b

Last test of basis68255  2016-12-21 21:17:44 Z1 days
Testing same since68260  2016-12-22 18:47:04 Z0 days1 attempts

Re: [Xen-devel] [PATCH] libxl/libxl_qmp.c: Fix code style in qmp_next()

[Zhang Chen]

On 12/22/2016 06:47 PM, Wei Liu wrote:

Also CC Anthony, who wrote the original code.

On Thu, Dec 22, 2016 at 05:53:07PM +0800, Zhang Chen wrote:

Make select loop more readable.

The behaviour of this function is changed. The changes are not
necessarily wrong, but we need to have clear commit message for why the
change of behaviour is desirable.

Basically you break a big loop into two disjoint ones. I think the
original code handles short-read correctly while this patch doesn't.

See below.

Signed-off-by: Zhang Chen 
---
  tools/libxl/libxl_qmp.c | 123 
  1 file changed, 61 insertions(+), 62 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ad22ad4..123a6bf 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -427,79 +427,78 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler 
*qmp)
  size_t incomplete_size = 0;
  int rc = 0;
  
-do {

-fd_set rfds;
-int ret = 0;
-struct timeval timeout = {
-.tv_sec = qmp->timeout,
-.tv_usec = 0,
-};
+fd_set rfds;
+int ret = 0;
+struct timeval timeout = {
+.tv_sec = qmp->timeout,
+.tv_usec = 0,
+};
  
-FD_ZERO();

-FD_SET(qmp->qmp_fd, );
+FD_ZERO();
+FD_SET(qmp->qmp_fd, );
  
+do {

  ret = select(qmp->qmp_fd + 1, , NULL, NULL, );
-if (ret == 0) {
-LOGD(ERROR, qmp->domid, "timeout");
-return -1;
-} else if (ret < 0) {
-if (errno == EINTR)
-continue;
-LOGED(ERROR, qmp->domid, "Select error");
-return -1;
-}
+} while (ret == -1 && errno == EINTR);
  

A side note.

Select may modify timeout, so I think we need to reset timeout at the
beginning of the loop.


OK, I will fix this in next version.




-rd = read(qmp->qmp_fd, qmp->buffer, QMP_RECEIVE_BUFFER_SIZE);
-if (rd == 0) {
-LOGD(ERROR, qmp->domid, "Unexpected end of socket");
-return -1;
-} else if (rd < 0) {
-LOGED(ERROR, qmp->domid, "Socket read error");
-return rd;
-}
-qmp->buffer[rd] = '\0';
-
-DEBUG_REPORT_RECEIVED(qmp->domid, qmp->buffer, rd);
-
-do {
-char *end = NULL;
-if (incomplete) {
-size_t current_pos = s - incomplete;
-incomplete = libxl__realloc(gc, incomplete,
-incomplete_size + rd + 1);
-strncat(incomplete + incomplete_size, qmp->buffer, rd);
-s = incomplete + current_pos;
-incomplete_size += rd;
-s_end = incomplete + incomplete_size;
-} else {
-incomplete = libxl__strndup(gc, qmp->buffer, rd);
-incomplete_size = rd;
-s = incomplete;
-s_end = s + rd;
-rd = 0;
-}
+if (ret == 0) {
+LOGD(ERROR, qmp->domid, "timeout");
+return -1;
+} else if (ret < 0) {
+LOGED(ERROR, qmp->domid, "Select error");
+return -1;
+}
  
-end = strstr(s, "\r\n");

-if (end) {
-libxl__json_object *o = NULL;
+rd = read(qmp->qmp_fd, qmp->buffer, QMP_RECEIVE_BUFFER_SIZE);
+if (rd == 0) {
+LOGD(ERROR, qmp->domid, "Unexpected end of socket");
+return -1;
+} else if (rd < 0) {
+LOGED(ERROR, qmp->domid, "Socket read error");
+return rd;
+}
+qmp->buffer[rd] = '\0';
+

Here, as I understand it, read can return incomplete message. For
example, when the buffer is not big enough.

And the inner loop in original code handles that by checking if there is
"\r\n". If not, it will read from the socket again.

So I'm afraid this patch is not correct. Please point out if there is
anything I missed.


Yes, this patch have some logic error, but I think the code
looks odd like that:
"
} while (s < s_end);
   } while (s < s_end);
"

The original code use "break" and "continue" to control the double loop
that make people hard to understand.

So, Can I change the code without "break" and "continue" like this?
"
} while (end);
} while (s < s_end);
"

If yes, I will fix this in next version.

Thanks
Zhang Chen


Wei.


.



--
Thanks
Zhang Chen




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

Re: [Xen-devel] [PATCH 1/2] x86/HVM: constify VMFUNC emulation hook

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, December 22, 2016 4:37 PM
> 
> ... to clarify that the register state does not get altered (behind the
> back of the emulator).
> 
> Signed-off-by: Jan Beulich 
> 

Acked-by: Kevin Tian 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 413535bb33d60417d681725af0274086630e7987
baseline version:
 ovmf d0c80b8a2de8ac90f51b86cce24e6c9c267ae5b4

Last test of basis   103787  2016-12-21 12:18:28 Z1 days
Testing same since   103801  2016-12-22 08:42:38 Z0 days1 attempts


People who touched revisions under test:
  Hao Wu 

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

[Xen-devel] [ovmf baseline-only test] 68258: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail like 68251
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail like 68251

version targeted for testing:
 ovmf d0c80b8a2de8ac90f51b86cce24e6c9c267ae5b4
baseline version:
 ovmf 403f54768cd517221143064449ac861f0aac4ec5

Last test of basis68251  2016-12-21 04:48:10 Z1 days
Testing same since68258  2016-12-22 02:17:43 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Eric Dong 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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 d0c80b8a2de8ac90f51b86cce24e6c9c267ae5b4
Author: Dandan Bi 
Date:   Tue Dec 20 15:12:56 2016 +0800

UefiCpuPkg/SmmCpuFeaturesLib: Fix coding style issues

Cc: Michael Kinney 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Michael Kinney 

commit ead54b965fa161f8e56117f1f7e2cc342e44aa37
Author: Dandan Bi 
Date:   Tue Dec 20 15:10:29 2016 +0800

UefiCpuPkg: Add Pcd info to uni file

Add PcdCpuSmmStmExceptionStackSize/PcdCpuMsegSize prompt and help
string to uni file.

Cc: Michael Kinney 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Michael Kinney 

commit 151ca6884580c95aae2b7e7257a1be7b6cd922f7
Author: Eric Dong 
Date:   Tue Dec 20 15:54:37 2016 +0800

SecurityPkg Tcg2ConfigDxe: Force reset when PCR Allocation changed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
Reviewed-by: Jiewen Yao 
Reviewed-by: Star Zeng 

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

[Xen-devel] [libvirt test] 103798: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 103479

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-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-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  83390dac2fe12a79bef5376030a61521b40e43d5
baseline version:
 libvirt  50b2a2375ad0eb26974039647fc705a32b10ac55

Last test of basis   103479  2016-12-16 17:26:38 Z6 days
Failing since103766  2016-12-20 04:20:04 Z2 days2 attempts
Testing same since   103798  2016-12-22 04:20:17 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Boris Fiuczynski 
  Cédric Bosdonnat 
  Daniel P. Berrange 
  Guido Günther 
  Jiri Denemark 
  John Ferlan 
  Marc Hartmayer 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Shivaprasad G Bhat 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu82ecffa8c050bf5bbc13329e9b65eac1caa5b55c
baseline version:
 qemuu6a928d25b6d8bc3729c3d28326c6db13b9481059

Last test of basis   103397  2016-12-15 10:19:00 Z7 days
Testing same since   103785  2016-12-21 12:17:47 Z1 days2 attempts


People who touched revisions under test:
  Stefan Hajnoczi 

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

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

[Alistair Francis]

On Thu, Dec 22, 2016 at 2:11 PM, Alistair Francis
 wrote:
> On Thu, Dec 22, 2016 at 2:00 PM, Doug Goldstein  wrote:
>> On 12/22/16 3:47 PM, Andrew Cooper wrote:
>>> On 22/12/16 21:41, Alistair Francis wrote:
 On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
  wrote:
> On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
>  wrote:
>> On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson
>>  wrote:
>>> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove
>>> hardcoded strict -Werror checking"):
 On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich 
 wrote:
> On 20.12.16 at 20:46,  wrote:
>> Signed-off-by: Alistair Francis 
> Without some rationale given I don't think such changes are
> acceptable at all. And then, as already pointed out others, the
> use of -Werror is there not just for fun. If anything I think an
> override to that default could be acceptable.
 Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
 as I still see warnings/errors when building: tools/kconfig/conf.c.
>>> That sounds like a bug to me.  Do you know why it's not effective
>>> there ?
>> It actually might be an issue in the way buildroot is handling the
>> arguments.
>>
>> I'll look into it and see what I find after the holidays.
 I dug into this a little more. Adding the APPEND_CFLAGS="-Wno-error"
 fixes almost everything. The only problem I see is in the log below,
 where tools/kconfig/conf.c fails to build as the -Wno-error doesn't
 propagate down.

 If I manage to find a fix today I'll send it, otherwise this can wait
 until next year.
>>>
>>> Something like this?
>>>
>>> diff --git a/xen/Makefile b/xen/Makefile
>>> index dc6862e04d..2d7a567c9c 100644
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -253,14 +253,14 @@ kconfig := silentoldconfig oldconfig config
>>> menuconfig defconfig \
>>> randconfig
>>>  .PHONY: $(kconfig)
>>>  $(kconfig):
>>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
>>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" $@
>>>
>>>  include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
>>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>>> silentoldconfig
>>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" silentoldconfig
>>>
>>>  # Allow people to just run `make` as before and not force them to
>>> configure
>>>  $(KCONFIG_CONFIG):
>>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>>> defconfig
>>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" defconfig
>>>
>>>  # Break the dependency chain for the first run
>>>  include/config/auto.conf.cmd: ;
>>>
>>
>> That should do the trick.
>>
>> Reviewed-by: Doug Goldstein 
>
> I got this to work as well:
>
> diff --git a/xen/tools/kconfig/Makefile b/xen/tools/kconfig/Makefile
> index aceaaed..32e2359 100644
> --- a/xen/tools/kconfig/Makefile
> +++ b/xen/tools/kconfig/Makefile
> @@ -155,7 +155,7 @@ check-lxdialog  :=
> $(srctree)/$(src)/lxdialog/check-lxdialog.sh
>  # Use recursively expanded variables so we do not call gcc unless
>  # we really need to do so. (Do not call gcc as part of make mrproper)
>  HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags) \
> --DLOCALE
> +-DLOCALE $(APPEND_CFLAGS)
>
>  # ===
>  # Shared Makefile for the various kconfig executables:
>
> But yours looks like it should work as well.
>
> Do you want to send a patch?

You can add this to it:

Reviewed-by: Alistair Francis 
Tested-by: Alistair Francis 

Thanks,

Alistair

>
> Thanks,
>
> Alistair
>
>>
>> --
>> Doug Goldstein
>>
>>
>> ___
>> 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 v2 1/5] Remove hardcoded strict -Werror checking

[Alistair Francis]

On Thu, Dec 22, 2016 at 2:00 PM, Doug Goldstein  wrote:
> On 12/22/16 3:47 PM, Andrew Cooper wrote:
>> On 22/12/16 21:41, Alistair Francis wrote:
>>> On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
>>>  wrote:
 On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
  wrote:
> On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson
>  wrote:
>> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove
>> hardcoded strict -Werror checking"):
>>> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich 
>>> wrote:
 On 20.12.16 at 20:46,  wrote:
> Signed-off-by: Alistair Francis 
 Without some rationale given I don't think such changes are
 acceptable at all. And then, as already pointed out others, the
 use of -Werror is there not just for fun. If anything I think an
 override to that default could be acceptable.
>>> Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>>> as I still see warnings/errors when building: tools/kconfig/conf.c.
>> That sounds like a bug to me.  Do you know why it's not effective
>> there ?
> It actually might be an issue in the way buildroot is handling the
> arguments.
>
> I'll look into it and see what I find after the holidays.
>>> I dug into this a little more. Adding the APPEND_CFLAGS="-Wno-error"
>>> fixes almost everything. The only problem I see is in the log below,
>>> where tools/kconfig/conf.c fails to build as the -Wno-error doesn't
>>> propagate down.
>>>
>>> If I manage to find a fix today I'll send it, otherwise this can wait
>>> until next year.
>>
>> Something like this?
>>
>> diff --git a/xen/Makefile b/xen/Makefile
>> index dc6862e04d..2d7a567c9c 100644
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -253,14 +253,14 @@ kconfig := silentoldconfig oldconfig config
>> menuconfig defconfig \
>> randconfig
>>  .PHONY: $(kconfig)
>>  $(kconfig):
>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" $@
>>
>>  include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>> silentoldconfig
>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" silentoldconfig
>>
>>  # Allow people to just run `make` as before and not force them to
>> configure
>>  $(KCONFIG_CONFIG):
>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>> defconfig
>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" defconfig
>>
>>  # Break the dependency chain for the first run
>>  include/config/auto.conf.cmd: ;
>>
>
> That should do the trick.
>
> Reviewed-by: Doug Goldstein 

I got this to work as well:

diff --git a/xen/tools/kconfig/Makefile b/xen/tools/kconfig/Makefile
index aceaaed..32e2359 100644
--- a/xen/tools/kconfig/Makefile
+++ b/xen/tools/kconfig/Makefile
@@ -155,7 +155,7 @@ check-lxdialog  :=
$(srctree)/$(src)/lxdialog/check-lxdialog.sh
 # Use recursively expanded variables so we do not call gcc unless
 # we really need to do so. (Do not call gcc as part of make mrproper)
 HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags) \
--DLOCALE
+-DLOCALE $(APPEND_CFLAGS)

 # ===
 # Shared Makefile for the various kconfig executables:

But yours looks like it should work as well.

Do you want to send a patch?

Thanks,

Alistair

>
> --
> Doug Goldstein
>
>
> ___
> 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 v2 1/5] Remove hardcoded strict -Werror checking

[Doug Goldstein]

On 12/22/16 3:47 PM, Andrew Cooper wrote:
> On 22/12/16 21:41, Alistair Francis wrote:
>> On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
>>  wrote:
>>> On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
>>>  wrote:
 On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson
  wrote:
> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove
> hardcoded strict -Werror checking"):
>> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich 
>> wrote:
>>> On 20.12.16 at 20:46,  wrote:
 Signed-off-by: Alistair Francis 
>>> Without some rationale given I don't think such changes are
>>> acceptable at all. And then, as already pointed out others, the
>>> use of -Werror is there not just for fun. If anything I think an
>>> override to that default could be acceptable.
>> Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>> as I still see warnings/errors when building: tools/kconfig/conf.c.
> That sounds like a bug to me.  Do you know why it's not effective
> there ?
 It actually might be an issue in the way buildroot is handling the
 arguments.

 I'll look into it and see what I find after the holidays.
>> I dug into this a little more. Adding the APPEND_CFLAGS="-Wno-error"
>> fixes almost everything. The only problem I see is in the log below,
>> where tools/kconfig/conf.c fails to build as the -Wno-error doesn't
>> propagate down.
>>
>> If I manage to find a fix today I'll send it, otherwise this can wait
>> until next year.
> 
> Something like this?
> 
> diff --git a/xen/Makefile b/xen/Makefile
> index dc6862e04d..2d7a567c9c 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -253,14 +253,14 @@ kconfig := silentoldconfig oldconfig config
> menuconfig defconfig \
> randconfig
>  .PHONY: $(kconfig)
>  $(kconfig):
> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" $@
> 
>  include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
> silentoldconfig
> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" silentoldconfig
> 
>  # Allow people to just run `make` as before and not force them to
> configure
>  $(KCONFIG_CONFIG):
> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
> defconfig
> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" defconfig
> 
>  # Break the dependency chain for the first run
>  include/config/auto.conf.cmd: ;
> 

That should do the trick.

Reviewed-by: Doug Goldstein 

-- 
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 v2 1/5] Remove hardcoded strict -Werror checking

[Andrew Cooper]

On 22/12/16 21:41, Alistair Francis wrote:

On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
 wrote:

On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
 wrote:

On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson  wrote:

Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict 
-Werror checking"):

On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich  wrote:

On 20.12.16 at 20:46,  wrote:

Signed-off-by: Alistair Francis 

Without some rationale given I don't think such changes are
acceptable at all. And then, as already pointed out others, the
use of -Werror is there not just for fun. If anything I think an
override to that default could be acceptable.

Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
as I still see warnings/errors when building: tools/kconfig/conf.c.

That sounds like a bug to me.  Do you know why it's not effective
there ?

It actually might be an issue in the way buildroot is handling the arguments.

I'll look into it and see what I find after the holidays.

I dug into this a little more. Adding the APPEND_CFLAGS="-Wno-error"
fixes almost everything. The only problem I see is in the log below,
where tools/kconfig/conf.c fails to build as the -Wno-error doesn't
propagate down.

If I manage to find a fix today I'll send it, otherwise this can wait
until next year.


Something like this?

diff --git a/xen/Makefile b/xen/Makefile
index dc6862e04d..2d7a567c9c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -253,14 +253,14 @@ kconfig := silentoldconfig oldconfig config 
menuconfig defconfig \

randconfig
 .PHONY: $(kconfig)
 $(kconfig):
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" 
HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" $@


 include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" 
silentoldconfig
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" 
HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" silentoldconfig


 # Allow people to just run `make` as before and not force them to 
configure

 $(KCONFIG_CONFIG):
-   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" 
defconfig
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" 
HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" defconfig


 # Break the dependency chain for the first run
 include/config/auto.conf.cmd: ;


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

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

[Alistair Francis]

On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
 wrote:
> On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
>  wrote:
>> On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson  
>> wrote:
>>> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded 
>>> strict -Werror checking"):
 On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich  wrote:
> On 20.12.16 at 20:46,  wrote:
 >> Signed-off-by: Alistair Francis 
 >
 > Without some rationale given I don't think such changes are
 > acceptable at all. And then, as already pointed out others, the
 > use of -Werror is there not just for fun. If anything I think an
 > override to that default could be acceptable.

 Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
 as I still see warnings/errors when building: tools/kconfig/conf.c.
>>>
>>> That sounds like a bug to me.  Do you know why it's not effective
>>> there ?
>>
>> It actually might be an issue in the way buildroot is handling the arguments.
>>
>> I'll look into it and see what I find after the holidays.

I dug into this a little more. Adding the APPEND_CFLAGS="-Wno-error"
fixes almost everything. The only problem I see is in the log below,
where tools/kconfig/conf.c fails to build as the -Wno-error doesn't
propagate down.

If I manage to find a fix today I'll send it, otherwise this can wait
until next year.

Thanks,

Alistair

>
> Nope, it does look like a Xen build issue. I included the full failing
> log below:
>
> PATH="/work/alistai/software/buildroot/output/host/bin:/work/alistai/software/buildroot/output/host/sbin:/work/alistai/software/buildroot/output/host/usr/bin:/work/alistai/software/buildroot/output/host/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
> XEN_TARGET_ARCH=arm32
> CROSS_COMPILE=/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-
> PATH="/work/alistai/software/buildroot/output/host/bin:/work/alistai/software/buildroot/output/host/sbin:/work/alistai/software/buildroot/output/host/usr/bin:/work/alistai/software/buildroot/output/host/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
> AR="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ar"
> AS="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-as"
> LD="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ld"
> NM="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-nm"
> CC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gcc"
> GCC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gcc"
> CPP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-cpp"
> CXX="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-g++"
> FC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gfortran"
> F77="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gfortran"
> RANLIB="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ranlib"
> READELF="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-readelf"
> STRIP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-strip"
> OBJCOPY="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-objcopy"
> OBJDUMP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-objdump"
> AR_FOR_BUILD="/usr/bin/ar" AS_FOR_BUILD="/usr/bin/as"
> CC_FOR_BUILD="/usr/bin/gcc" GCC_FOR_BUILD="/usr/bin/gcc"
> CXX_FOR_BUILD="/usr/bin/g++" LD_FOR_BUILD="/usr/bin/ld"
> CPPFLAGS_FOR_BUILD="-I/work/alistai/software/buildroot/output/host/usr/include"
> CFLAGS_FOR_BUILD="-O2
> -I/work/alistai/software/buildroot/output/host/usr/include"
> CXXFLAGS_FOR_BUILD="-O2
> -I/work/alistai/software/buildroot/output/host/usr/include"
> LDFLAGS_FOR_BUILD="-L/work/alistai/software/buildroot/output/host/lib
> -L/work/alistai/software/buildroot/output/host/usr/lib
> -Wl,-rpath,/work/alistai/software/buildroot/output/host/usr/lib"
> FCFLAGS_FOR_BUILD=""
> DEFAULT_ASSEMBLER="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-as"
> DEFAULT_LINKER="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ld"
> CPPFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64" APPEND_CFLAGS="-Wno-error -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os "
> CXXFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64  -Os " LDFLAGS="" FAPPEND_CFLAGS="-Wno-error
> -Os " FFLAGS=" -Os "
> PKG_CONFIG="/work/alistai/software/buildroot/output/host/usr/bin/pkg-config"
> STAGING_DIR="/work/alistai/software/buildroot/output/host/usr/arm-buildroot-linux-musleabihf/sysroot"
> INTLTOOL_PERL=/usr/bin/perl /usr/bin/make -j11 dist-xen dist-tools -C
> 

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

[Alistair Francis]

On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
 wrote:
> On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson  
> wrote:
>> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded 
>> strict -Werror checking"):
>>> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich  wrote:
 On 20.12.16 at 20:46,  wrote:
>>> >> Signed-off-by: Alistair Francis 
>>> >
>>> > Without some rationale given I don't think such changes are
>>> > acceptable at all. And then, as already pointed out others, the
>>> > use of -Werror is there not just for fun. If anything I think an
>>> > override to that default could be acceptable.
>>>
>>> Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>>> as I still see warnings/errors when building: tools/kconfig/conf.c.
>>
>> That sounds like a bug to me.  Do you know why it's not effective
>> there ?
>
> It actually might be an issue in the way buildroot is handling the arguments.
>
> I'll look into it and see what I find after the holidays.

Nope, it does look like a Xen build issue. I included the full failing
log below:

PATH="/work/alistai/software/buildroot/output/host/bin:/work/alistai/software/buildroot/output/host/sbin:/work/alistai/software/buildroot/output/host/usr/bin:/work/alistai/software/buildroot/output/host/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
XEN_TARGET_ARCH=arm32
CROSS_COMPILE=/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-
PATH="/work/alistai/software/buildroot/output/host/bin:/work/alistai/software/buildroot/output/host/sbin:/work/alistai/software/buildroot/output/host/usr/bin:/work/alistai/software/buildroot/output/host/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
AR="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ar"
AS="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-as"
LD="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ld"
NM="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-nm"
CC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gcc"
GCC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gcc"
CPP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-cpp"
CXX="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-g++"
FC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gfortran"
F77="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gfortran"
RANLIB="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ranlib"
READELF="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-readelf"
STRIP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-strip"
OBJCOPY="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-objcopy"
OBJDUMP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-objdump"
AR_FOR_BUILD="/usr/bin/ar" AS_FOR_BUILD="/usr/bin/as"
CC_FOR_BUILD="/usr/bin/gcc" GCC_FOR_BUILD="/usr/bin/gcc"
CXX_FOR_BUILD="/usr/bin/g++" LD_FOR_BUILD="/usr/bin/ld"
CPPFLAGS_FOR_BUILD="-I/work/alistai/software/buildroot/output/host/usr/include"
CFLAGS_FOR_BUILD="-O2
-I/work/alistai/software/buildroot/output/host/usr/include"
CXXFLAGS_FOR_BUILD="-O2
-I/work/alistai/software/buildroot/output/host/usr/include"
LDFLAGS_FOR_BUILD="-L/work/alistai/software/buildroot/output/host/lib
-L/work/alistai/software/buildroot/output/host/usr/lib
-Wl,-rpath,/work/alistai/software/buildroot/output/host/usr/lib"
FCFLAGS_FOR_BUILD=""
DEFAULT_ASSEMBLER="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-as"
DEFAULT_LINKER="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ld"
CPPFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64" APPEND_CFLAGS="-Wno-error -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os "
CXXFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -Os " LDFLAGS="" FAPPEND_CFLAGS="-Wno-error
-Os " FFLAGS=" -Os "
PKG_CONFIG="/work/alistai/software/buildroot/output/host/usr/bin/pkg-config"
STAGING_DIR="/work/alistai/software/buildroot/output/host/usr/arm-buildroot-linux-musleabihf/sysroot"
INTLTOOL_PERL=/usr/bin/perl /usr/bin/make -j11 dist-xen dist-tools -C
/work/alistai/software/buildroot/output/build/xen-4.8.0/
make[1]: Entering directory
'/work/alistai/software/buildroot/output/build/xen-4.8.0'
/usr/bin/make -C xen install
/usr/bin/make -C tools install
make[2]: Entering directory
'/work/alistai/software/buildroot/output/build/xen-4.8.0/xen'
make[2]: Entering directory
'/work/alistai/software/buildroot/output/build/xen-4.8.0/tools'
/usr/bin/make -f
/work/alistai/software/buildroot/output/build/xen-4.8.0/xen/tools/kconfig/Makefile.kconfig
ARCH=arm32 SRCARCH=arm HOSTCC="/usr/bin/gcc" HOSTCXX="/usr/bin/g++"
defconfig

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

[Alistair Francis]

On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson  wrote:
> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded 
> strict -Werror checking"):
>> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich  wrote:
>>> On 20.12.16 at 20:46,  wrote:
>> >> Signed-off-by: Alistair Francis 
>> >
>> > Without some rationale given I don't think such changes are
>> > acceptable at all. And then, as already pointed out others, the
>> > use of -Werror is there not just for fun. If anything I think an
>> > override to that default could be acceptable.
>>
>> Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>> as I still see warnings/errors when building: tools/kconfig/conf.c.
>
> That sounds like a bug to me.  Do you know why it's not effective
> there ?

It actually might be an issue in the way buildroot is handling the arguments.

I'll look into it and see what I find after the holidays.

Thanks,

Alistair

>
>> Everyone seems fairly open to an override. Is a environment variable,
>> which if set will disable Werror acceptable? Something like NO_ERROR=Y
>> which will result in no -Werror being appended.
>
> Yes, an environment variable would be acceptable, but it should have
> the right name and semantics and ideally we could reuse an existing
> variable or fix it if it is broken.
>
> How about `APPEND_CFLAGS=-Wno-error' ? :-)
>
> Thanks,
> Ian.
>
> ___
> 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] [PATCH] tpm: Restore functionality to xen vtpm driver.

[Dr. Greg Wettstein]

Functionality of the xen-tpmfront driver was lost secondary to
the introduction of xenbus multi-page support in the following
commit:

ccc9d90a9a8b5c4ad7e9708ec41f75ff9e98d61d

xenbus_client: Extend interface to support multi-page ring

In this commit a pointer to the shared page address was being
passed to the xenbus_grant_ring() function rather then the
address of the shared page itself.  This resulted in a situation
where the driver would attach to the vtpm-stubdom but any attempt
to send a command to the stub domain would timeout.

A diagnostic finding for this regression is the following error
message being generated when the xen-tpmfront driver probes for a
device:

<3>vtpm vtpm-0: tpm_transmit: tpm_send: error -62

<3>vtpm vtpm-0: A TPM error (-62) occurred attempting to determine the timeouts

This fix is relevant to all kernels from 4.1 forward which is the
release in which multi-page xenbus support was introduced.

Daniel De Graaf formulated the fix by code inspection after the
regression point was located.

Signed-off-by: Dr. Greg Wettstein 
---
 drivers/char/tpm/xen-tpmfront.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
index 5aaa268..dd83a07 100644
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c
@@ -203,7 +203,7 @@ static int setup_ring(struct xenbus_device *dev, struct 
tpm_private *priv)
return -ENOMEM;
}
 
-   rv = xenbus_grant_ring(dev, >shr, 1, );
+   rv = xenbus_grant_ring(dev, priv->shr, 1, );
if (rv < 0)
return rv;
 
-- 
2.2.2


-- 

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

[Xen-devel] [xen-4.4-testing test] 103796: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
103782

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail like 103756
 test-xtf-amd64-amd64-4   16 xtf/test-pv32pae-selftestfail  like 103782
 test-xtf-amd64-amd64-2   16 xtf/test-pv32pae-selftestfail  like 103782
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail  like 103782
 test-xtf-amd64-amd64-3 32 xtf/test-hvm32pae-invlpg~shadow fail like 103782
 test-xtf-amd64-amd64-2   53 leak-check/check fail  like 103782
 test-xtf-amd64-amd64-3   43 xtf/test-hvm64-invlpg~shadow fail  like 103782
 test-xtf-amd64-amd64-5   53 leak-check/check fail  like 103782
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103782
 test-xtf-amd64-amd64-4   53 leak-check/check fail  like 103782
 test-xtf-amd64-amd64-3   53 leak-check/check fail  like 103782
 test-xtf-amd64-amd64-1   53 leak-check/check fail  like 103782
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103782

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-1   16 xtf/test-pv32pae-selftestfail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-xtf-amd64-amd64-4 30 xtf/test-hvm32pae-cpuid-faulting fail never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 36 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-1 30 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   40 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 30 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-xtf-amd64-amd64-2 36 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   40 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-1 36 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 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-xtf-amd64-amd64-2   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   40 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-xsa-195   fail   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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-xsa-195   fail   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-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 

[Xen-devel] Bug report

[Ing. Ricardo Brisighelli]

Hi my name is Richard and i suscribe to this list but dont know if this list 
is for reports bugs.

Tnks

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

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

[Ian Jackson]

Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded 
strict -Werror checking"):
> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich  wrote:
>> On 20.12.16 at 20:46,  wrote:
> >> Signed-off-by: Alistair Francis 
> >
> > Without some rationale given I don't think such changes are
> > acceptable at all. And then, as already pointed out others, the
> > use of -Werror is there not just for fun. If anything I think an
> > override to that default could be acceptable.
> 
> Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
> as I still see warnings/errors when building: tools/kconfig/conf.c.

That sounds like a bug to me.  Do you know why it's not effective
there ?

> Everyone seems fairly open to an override. Is a environment variable,
> which if set will disable Werror acceptable? Something like NO_ERROR=Y
> which will result in no -Werror being appended.

Yes, an environment variable would be acceptable, but it should have
the right name and semantics and ideally we could reuse an existing
variable or fix it if it is broken.

How about `APPEND_CFLAGS=-Wno-error' ? :-)

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

[Alistair Francis]

On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich  wrote:
 On 20.12.16 at 20:46,  wrote:
>> Signed-off-by: Alistair Francis 
>
> Without some rationale given I don't think such changes are
> acceptable at all. And then, as already pointed out others, the
> use of -Werror is there not just for fun. If anything I think an
> override to that default could be acceptable.

Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
as I still see warnings/errors when building: tools/kconfig/conf.c.

I understand that you want it in by default.

Everyone seems fairly open to an override. Is a environment variable,
which if set will disable Werror acceptable? Something like NO_ERROR=Y
which will result in no -Werror being appended.

Thanks,

Alistair

>
> Jan
>

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

Re: [Xen-devel] [PATCH] docs: Clarify scope of reboot= and noreboot Xen command line options

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH] docs: Clarify scope of reboot= and noreboot 
Xen command line options"):
> On 22.12.16 at 16:02,  wrote:
> > -Specify the host reboot method.
> > +Specify the host reboot method,
> > +used when Xen crashes.
> > +(This does not affect deliberate reboots initiated by dom0.)
> 
> This should be moved down to where `no` is being described, as
> it affects only that sub-option. The reboot methods, otoh, affect
> all kinds of reboots.

So you might say
  reboot=triple reboot=efi reboot=no
and this would mean to do requested reboots with efi and crash reboots
not at all, with `reboot=triple' being completely ignored ?

This is ... a funny way for an option with a `=' to behave.
Perhaps we should deprecate this.

Ian.

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

[Xen-devel] [xen-4.6-testing test] 103795: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  2eb074fddbecf40e0cdac5c5fe28fb6c7b5cc371
baseline version:
 xen  aa281a16db9a46911c78a30998c15810aa8b

Last test of basis   103783  2016-12-21 12:14:12 Z1 days
Testing same since   103795  2016-12-21 21:38:08 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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

[Xen-devel] [RFC PATCH v2 22/26] ARM: vITS: handle INV command

[Andre Przywara]

The INV command instructs the ITS to update the configuration data for
a given LPI by re-reading its entry from the property table.
We don't need to care so much about the priority value, but enabling
or disabling an LPI has some effect: We remove or push virtual LPIs
to their VCPUs, also check the virtual pending bit if an LPI gets enabled.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c  |  2 +-
 xen/arch/arm/vgic-its.c | 72 +
 2 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index 1da28b9..7dbb9e6 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -248,7 +248,7 @@ static uint64_t encode_phys_addr(paddr_t addr, int 
page_bits)
 {
 uint64_t ret;
 
-if ( page_bits < 16)
+if ( page_bits < 16 )
 return (uint64_t)addr & GENMASK(47, page_bits);
 
 ret = addr & GENMASK(47, 16);
diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index 52c660a..bcabb04 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -228,6 +228,75 @@ out_unlock:
 return ret;
 }
 
+/* For a given virtual LPI read the enabled bit from the virtual property
+ * table and update the virtual IRQ's state.
+ * This takes care of removing or pushing of virtual LPIs to their VCPUs.
+ */
+static void update_lpi_enabled_status(struct virt_its* its,
+  struct vcpu *vcpu, uint32_t vlpi)
+{
+struct pending_irq *pirq = lpi_to_pending(vcpu, vlpi, false);
+uint8_t property = its->d->arch.vgic.proptable[vlpi - 8192];
+
+if ( property & LPI_PROP_ENABLED )
+{
+if ( pirq )
+{
+unsigned long flags;
+
+set_bit(GIC_IRQ_GUEST_ENABLED, >status);
+spin_lock_irqsave(>arch.vgic.lock, flags);
+if ( !list_empty(>inflight) &&
+ !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+gic_raise_guest_irq(vcpu, vlpi, property & 0xfc);
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+}
+
+/* Check whether the LPI has fired while the guest had it disabled. */
+if (test_and_clear_bit(vlpi - 8192, vcpu->arch.vgic.pendtable))
+vgic_vcpu_inject_irq(vcpu, vlpi);
+}
+else
+{
+if ( pirq )
+{
+clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
+gic_remove_from_queues(vcpu, vlpi);
+}
+}
+}
+
+static int its_handle_inv(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct vits_itte *itte;
+struct vcpu *vcpu;
+uint32_t vlpi;
+int ret = -1;
+
+spin_lock(>its_lock);
+
+itte = get_devid_evid(its, devid, eventid);
+if ( !itte )
+goto out_unlock;
+
+vcpu = its->d->vcpu[itte->collection];
+vlpi = itte->vlpi;
+
+ret = 0;
+
+put_devid_evid(its, itte);
+
+out_unlock:
+spin_unlock(>its_lock);
+
+if ( !ret )
+update_lpi_enabled_status(its, vcpu, vlpi);
+
+return ret;
+}
+
 static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
 {
 uint32_t collid = its_cmd_get_collection(cmdptr);
@@ -418,6 +487,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_INT:
 its_handle_int(its, cmdptr);
 break;
+case GITS_CMD_INV:
+its_handle_inv(its, cmdptr);
+   break;
 case GITS_CMD_MAPC:
 its_handle_mapc(its, cmdptr);
 break;
-- 
2.9.0


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

[Xen-devel] [RFC PATCH v2 26/26] ARM: vGIC: advertising LPI support

[Andre Przywara]

To let a guest know about the availability of virtual LPIs, set the
respective bits in the virtual GIC registers and let a guest control
the LPI enable bit.
Only report the LPI capability if the host has initialized at least
one ITS.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 1c682d1..7e02da6 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -169,8 +169,10 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 switch ( gicr_reg )
 {
 case VREG32(GICR_CTLR):
-/* We have not implemented LPI's, read zero */
-goto read_as_zero_32;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+*r = vgic_reg32_extract(!!(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED),
+info);
+return 1;
 
 case VREG32(GICR_IIDR):
 if ( dabt.size != DABT_WORD ) goto bad_width;
@@ -182,16 +184,19 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 uint64_t typer, aff;
 
 if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-/* TBD: Update processor id in [23:8] when ITS support is added */
 aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
 typer = aff;
+typer |= (v->vcpu_id & 0x) << 8;
 
 if ( v->arch.vgic.flags & VGIC_V3_RDIST_LAST )
 typer |= GICR_TYPER_LAST;
 
+if ( v->domain->arch.vgic.has_its )
+typer |= GICR_TYPER_PLPIS;
+
 *r = vgic_reg64_extract(typer, info);
 
 return 1;
@@ -497,8 +502,16 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 switch ( gicr_reg )
 {
 case VREG32(GICR_CTLR):
-/* LPI's not implemented */
-goto write_ignore_32;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+if ( !v->domain->arch.vgic.has_its )
+return 1;
+
+if ( r & 1 )
+v->arch.vgic.flags |= VGIC_V3_LPIS_ENABLED;
+else
+v->arch.vgic.flags &= !VGIC_V3_LPIS_ENABLED;
+
+return 1;
 
 case VREG32(GICR_IIDR):
 /* RO */
@@ -1109,6 +1122,11 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 typer = ((ncpus - 1) << GICD_TYPE_CPUS_SHIFT |
  DIV_ROUND_UP(v->domain->arch.vgic.nr_spis, 32));
 
+if ( v->domain->arch.vgic.has_its )
+{
+typer |= GICD_TYPE_LPIS;
+irq_bits = 16;
+}
 typer |= (irq_bits - 1) << GICD_TYPE_ID_BITS_SHIFT;
 
 *r = vgic_reg32_extract(typer, info);
-- 
2.9.0


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

[Xen-devel] [RFC PATCH v2 06/26] ARM: GICv3 ITS: introduce device mapping

[Andre Przywara]

The ITS uses device IDs to map LPIs to a device. Dom0 will later use
those IDs, which we directly pass on to the host.
For this we have to map each device that Dom0 may request to a host
ITS device with the same identifier.
Allocate the respective memory and enter each device into a list to
later be able to iterate over it or to easily teardown guests.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c| 118 ++
 xen/arch/arm/vgic.c   |   3 ++
 xen/include/asm-arm/domain.h  |   2 +
 xen/include/asm-arm/gic-its.h |  22 
 4 files changed, 145 insertions(+)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index d0f5fd1..e157c6b 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -108,6 +109,21 @@ static int its_send_cmd_mapc(struct host_its *its, int 
collection_id, int cpu)
 return its_send_command(its, cmd);
 }
 
+static int its_send_cmd_mapd(struct host_its *its, uint32_t deviceid,
+ int size, uint64_t itt_addr, bool valid)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_MAPD | ((uint64_t)deviceid << 32);
+cmd[1] = size & GENMASK(4, 0);
+cmd[2] = itt_addr & GENMASK(51, 8);
+if ( valid )
+cmd[2] |= BIT_ULL(63);
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
 /* Set up the (1:1) collection mapping for the given host CPU. */
 void gicv3_its_setup_collection(int cpu)
 {
@@ -237,6 +253,7 @@ int gicv3_its_init(struct host_its *hw_its)
 
 reg = readq_relaxed(hw_its->its_base + GITS_TYPER);
 hw_its->pta = !!(reg & GITS_TYPER_PTA);
+hw_its->itte_size = ((reg >> 4) & 0xf) + 1;
 
 for ( i = 0; i < GITS_BASER_NR_REGS; i++ )
 {
@@ -358,6 +375,107 @@ int gicv3_lpi_init_host_lpis(unsigned int hw_lpi_bits)
 return 0;
 }
 
+static void remove_mapped_guest_device(struct its_devices *dev)
+{
+if ( dev->hw_its )
+its_send_cmd_mapd(dev->hw_its, dev->host_devid, 0, 0, false);
+
+xfree(dev->itt_addr);
+xfree(dev);
+}
+
+int gicv3_its_map_device(struct domain *d, int host_devid, int guest_devid,
+ int bits, bool valid)
+{
+void *itt_addr = NULL;
+struct its_devices *dev, *temp;
+struct host_its *hw_its;
+int ret;
+
+/* check for already existing mappings */
+spin_lock(>arch.vgic.its_devices_lock);
+list_for_each_entry_safe(dev, temp, >arch.vgic.its_devices, entry)
+{
+if ( dev->guest_devid != guest_devid )
+continue;
+
+if ( !valid )
+list_del(>entry);
+
+spin_unlock(>arch.vgic.its_devices_lock);
+
+if ( valid )
+return -EBUSY;
+
+remove_mapped_guest_device(dev);
+
+return 0;
+}
+spin_unlock(>arch.vgic.its_devices_lock);
+
+if ( !valid )
+return -ENOENT;
+
+/* TODO: Work out the correct hardware ITS to use here.
+ * Maybe a per-platform function: devid -> ITS?
+ * Or parsing the DT to find the msi_parent?
+ * Or get Dom0 to give us this information?
+ * For now just use the first ITS.
+ */
+hw_its = list_first_entry(_its_list, struct host_its, entry);
+
+itt_addr = _xmalloc(BIT(bits) * hw_its->itte_size, 256);
+if ( !itt_addr )
+return -ENOMEM;
+
+dev = xmalloc(struct its_devices);
+if ( !dev )
+{
+xfree(itt_addr);
+return -ENOMEM;
+}
+
+ret = its_send_cmd_mapd(hw_its, host_devid, bits - 1,
+virt_to_maddr(itt_addr), true);
+if (ret) {
+xfree(itt_addr);
+xfree(dev);
+return ret;
+}
+
+dev->itt_addr = itt_addr;
+dev->hw_its = hw_its;
+dev->guest_devid = guest_devid;
+dev->host_devid = host_devid;
+dev->eventids = BIT(bits);
+
+spin_lock(>arch.vgic.its_devices_lock);
+list_add_tail(>entry, >arch.vgic.its_devices);
+spin_unlock(>arch.vgic.its_devices_lock);
+
+return 0;
+}
+
+/* Removing any connections a domain had to any ITS in the system. */
+int its_remove_domain(struct domain *d)
+{
+struct its_devices *dev, *temp;
+
+retry:
+
+spin_lock(>arch.vgic.its_devices_lock);
+list_for_each_entry_safe(dev, temp, >arch.vgic.its_devices, entry)
+{
+list_del(>entry);
+spin_unlock(>arch.vgic.its_devices_lock);
+
+remove_mapped_guest_device(dev);
+goto retry;
+}
+
+return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 364d5f0..de77aaa 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -156,6 +156,9 @@ int domain_vgic_init(struct domain *d, unsigned int nr_spis)
 for ( i = 0; i < NR_GIC_SGI; i++ )
 set_bit(i, d->arch.vgic.allocated_irqs);
 
+   

[Xen-devel] [RFC PATCH v2 21/26] ARM: vITS: handle DISCARD command

[Andre Przywara]

The DISCARD command drops the connection between a DeviceID/EventID
and an LPI/collection pair.
We mark the respective structure entries as not allocated and make
sure that any queued IRQs are removed.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-its.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index 7c80c17..52c660a 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -351,6 +351,44 @@ out_unlock:
 return 0;
 }
 
+static int its_handle_discard(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct pending_irq *pirq;
+struct vits_itte *itte;
+struct vcpu *vcpu;
+
+spin_lock(>its_lock);
+itte = get_devid_evid(its, devid, eventid);
+if ( !itte )
+goto out_unlock;
+
+vcpu = get_vcpu_from_collection(its, itte->collection);
+
+pirq = lpi_to_pending(vcpu, itte->vlpi, false);
+if ( pirq )
+{
+clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+gic_remove_from_queues(vcpu, itte->vlpi);
+
+/* Mark this pending IRQ struct as availabe again. */
+if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+pirq->irq = 0;
+}
+
+itte->vlpi = 0; /* Mark this ITTE as unused. */
+itte->collection = ~0;
+gicv3_assign_guest_event(its->d, devid, eventid, NULL, 0);
+
+put_devid_evid(its, itte);
+
+out_unlock:
+spin_unlock(>its_lock);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 
 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -374,6 +412,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_CLEAR:
 its_handle_clear(its, cmdptr);
 break;
+case GITS_CMD_DISCARD:
+its_handle_discard(its, cmdptr);
+break;
 case GITS_CMD_INT:
 its_handle_int(its, cmdptr);
 break;
-- 
2.9.0


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

[Xen-devel] [RFC PATCH v2 25/26] ARM: vITS: create ITS subnodes for Dom0 DT

[Andre Przywara]

Dom0 expects all ITSes in the system to be propagated to be able to
use MSIs.
Create Dom0 DT nodes for each hardware ITS, keeping the register frame
address the same, as the doorbell address that the Dom0 drivers program
into the BARs has to match the hardware.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c| 72 +++
 xen/arch/arm/gic-v3.c |  4 ++-
 xen/include/asm-arm/gic-its.h | 13 
 3 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index 7dbb9e6..d5d4d3b 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -817,6 +817,78 @@ int gicv3_lpi_change_vcpu(struct domain *d,
 return 0;
 }
 
+/* Create the respective guest DT nodes for a list of host ITSes.
+ * This copies the reg property, so the guest sees the ITS at the same address
+ * as the host.
+ */
+int gicv3_its_make_dt_nodes(struct list_head *its_list,
+const struct domain *d,
+const struct dt_device_node *gic,
+void *fdt)
+{
+uint32_t len;
+int res;
+const void *prop = NULL;
+const struct dt_device_node *its = NULL;
+const struct host_its *its_data;
+
+if ( list_empty(its_list) )
+return 0;
+
+/* The sub-nodes require the ranges property */
+prop = dt_get_property(gic, "ranges", );
+if ( !prop )
+{
+printk(XENLOG_ERR "Can't find ranges property for the gic node\n");
+return -FDT_ERR_XEN(ENOENT);
+}
+
+res = fdt_property(fdt, "ranges", prop, len);
+if ( res )
+return res;
+
+list_for_each_entry(its_data, its_list, entry)
+{
+its = its_data->dt_node;
+
+res = fdt_begin_node(fdt, its->name);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-v3-its");
+if ( res )
+return res;
+
+res = fdt_property(fdt, "msi-controller", NULL, 0);
+if ( res )
+return res;
+
+if ( its->phandle )
+{
+res = fdt_property_cell(fdt, "phandle", its->phandle);
+if ( res )
+return res;
+}
+
+/* Use the same reg regions as the ITS node in host DTB. */
+prop = dt_get_property(its, "reg", );
+if ( !prop )
+{
+printk(XENLOG_ERR "GICv3: Can't find ITS reg property.\n");
+res = -FDT_ERR_XEN(ENOENT);
+return res;
+}
+
+res = fdt_property(fdt, "reg", prop, len);
+if ( res )
+return res;
+
+fdt_end_node(fdt);
+}
+
+return res;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 5bfdf24..b680a29 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1190,8 +1190,10 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 
 res = fdt_property(fdt, "reg", new_cells, len);
 xfree(new_cells);
+if ( res )
+return res;
 
-return res;
+return gicv3_its_make_dt_nodes(_its_list, d, gic, fdt);
 }
 
 static const hw_irq_controller gicv3_host_irq_type = {
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index 9956afb..bd3af50 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -137,6 +137,12 @@ void gicv3_its_setup_collection(int cpu);
 int vgic_v3_its_init_virtual(struct domain *d, struct host_its *hw_its,
  paddr_t guest_addr);
 
+/* Given a list of ITSes, create the appropriate DT nodes for a domain. */
+int gicv3_its_make_dt_nodes(struct list_head *its_list,
+const struct domain *d,
+const struct dt_device_node *gic,
+void *fdt);
+
 /* Map a device on the host by allocating an ITT on the host (ITS).
  * "bits" specifies how many events (interrupts) this device will need.
  * Setting "valid" to false deallocates the device.
@@ -188,6 +194,13 @@ static inline int vgic_v3_its_init_virtual(struct domain 
*d,
 {
 return 0;
 }
+static inline int gicv3_its_make_dt_nodes(struct list_head *its_list,
+   const struct domain *d,
+   const struct dt_device_node *gic,
+   void *fdt)
+{
+return 0;
+}
 
 #endif /* CONFIG_HAS_ITS */
 
-- 
2.9.0


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

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

[Andre Przywara]

Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
number to get this IRQ injected.
Iterate our two-level LPI table to find this information quickly when
the host takes an LPI. Call the existing injection function to let the
GIC emulation deal with this interrupt.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c| 35 +++
 xen/arch/arm/gic.c|  6 --
 xen/include/asm-arm/irq.h |  8 
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index e7ddd90..0d4ca1b 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -72,6 +72,41 @@ static union host_lpi *gic_get_host_lpi(uint32_t plpi)
 return _data.host_lpis[plpi / HOST_LPIS_PER_PAGE][plpi % 
HOST_LPIS_PER_PAGE];
 }
 
+/* Handle incoming LPIs, which are a bit special, because they are potentially
+ * numerous and also only get injected into guests. Treat them specially here,
+ * by just looking up their target vCPU and virtual LPI number and hand it
+ * over to the injection function.
+ */
+void do_LPI(unsigned int lpi)
+{
+struct domain *d;
+union host_lpi *hlpip, hlpi;
+struct vcpu *vcpu;
+
+WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
+
+hlpip = gic_get_host_lpi(lpi);
+if ( !hlpip )
+return;
+
+hlpi.data = hlpip->data;
+
+/* We may have mapped more host LPIs than the guest actually asked for. */
+if ( !hlpi.virt_lpi )
+return;
+
+d = get_domain_by_id(hlpi.dom_id);
+if ( !d )
+return;
+
+if ( hlpi.vcpu_id >= d->max_vcpus )
+return;
+
+vcpu = d->vcpu[hlpi.vcpu_id];
+
+vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
+}
+
 #define ITS_CMD_QUEUE_SZSZ_64K
 
 static int its_send_command(struct host_its *hw_its, void *its_cmd)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 6f25501..7d428dc 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -700,8 +700,10 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 local_irq_enable();
 do_IRQ(regs, irq, is_fiq);
 local_irq_disable();
-}
-else if (unlikely(irq < 16))
+} else if ( irq >= 8192 )
+{
+do_LPI(irq);
+} else if ( unlikely(irq < 16) )
 {
 do_sgi(regs, irq);
 }
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 8f7a167..ee47de8 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -34,6 +34,14 @@ struct irq_desc *__irq_to_desc(int irq);
 
 void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
 
+#ifdef CONFIG_HAS_ITS
+void do_LPI(unsigned int irq);
+#else
+static inline void do_LPI(unsigned int irq)
+{
+}
+#endif
+
 #define domain_pirq_to_irq(d, pirq) (pirq)
 
 bool_t is_assignable_irq(unsigned int irq);
-- 
2.9.0


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

[Xen-devel] [RFC PATCH v2 24/26] ARM: vITS: create and initialize virtual ITSes for Dom0

[Andre Przywara]

For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-its.c   | 22 ++
 xen/arch/arm/vgic-v3.c| 12 
 xen/include/asm-arm/domain.h  |  1 +
 xen/include/asm-arm/gic-its.h | 13 +
 4 files changed, 48 insertions(+)

diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index c130d98..2eec468 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -810,6 +810,28 @@ static const struct mmio_handler_ops vgic_its_mmio_handler 
= {
 .write = vgic_v3_its_mmio_write,
 };
 
+int vgic_v3_its_init_virtual(struct domain *d, struct host_its *hw_its,
+ paddr_t guest_addr)
+{
+struct virt_its *its;
+
+its = xzalloc(struct virt_its);
+if ( ! its )
+return -ENOMEM;
+
+its->d = d;
+its->hw_its = hw_its;
+its->baser0 = 0x79170400;
+its->baser1 = 0x3c010400;
+its->cbaser = 0x380e0400;
+spin_lock_init(>vcmd_lock);
+spin_lock_init(>its_lock);
+
+register_mmio_handler(d, _its_mmio_handler, guest_addr, SZ_64K, its);
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index a9b04ab..1c682d1 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1644,6 +1645,7 @@ static int vgic_v3_domain_init(struct domain *d)
  */
 if ( is_hardware_domain(d) )
 {
+struct host_its *hw_its;
 unsigned int first_cpu = 0;
 
 d->arch.vgic.dbase = vgic_v3_hw.dbase;
@@ -1669,6 +1671,16 @@ static int vgic_v3_domain_init(struct domain *d)
 
 first_cpu += size / d->arch.vgic.rdist_stride;
 }
+d->arch.vgic.nr_regions = vgic_v3_hw.nr_rdist_regions;
+
+list_for_each_entry(hw_its, _its_list, entry)
+{
+/* Emulate the control registers frame (lower 64K). */
+vgic_v3_its_init_virtual(d, hw_its, hw_its->addr);
+
+d->arch.vgic.has_its = true;
+}
+
 }
 else
 {
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 543d058..6890b3b 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -114,6 +114,7 @@ struct arch_domain
 uint8_t *proptable;
 struct list_head its_devices;   /* devices mapped to an ITS */
 spinlock_t its_devices_lock;/* protects the its_devices list */
+bool has_its;
 #endif
 } vgic;
 
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index c5355f9..9956afb 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -130,6 +130,13 @@ void gicv3_set_redist_addr(paddr_t address, int redist_id);
 /* Map a collection for this host CPU to each host ITS. */
 void gicv3_its_setup_collection(int cpu);
 
+/* Create and register a virtual ITS at the given guest address.
+ * If a host ITS is specified, a hardware domain can reach out to that host
+ * ITS to deal with devices and LPI mappings and can enable/disable LPIs.
+ */
+int vgic_v3_its_init_virtual(struct domain *d, struct host_its *hw_its,
+ paddr_t guest_addr);
+
 /* Map a device on the host by allocating an ITT on the host (ITS).
  * "bits" specifies how many events (interrupts) this device will need.
  * Setting "valid" to false deallocates the device.
@@ -175,6 +182,12 @@ static inline int gicv3_its_map_device(struct domain *d, 
int host_devid,
 {
 return -ENODEV;
 }
+static inline int vgic_v3_its_init_virtual(struct domain *d,
+   struct host_its *hw_its,
+   paddr_t guest_addr)
+{
+return 0;
+}
 
 #endif /* CONFIG_HAS_ITS */
 
-- 
2.9.0


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

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

[Andre Przywara]

The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a given redistributor (read: VCPU).
This is nasty to emulate exactly with our architecture, so we just scan
the pending table and inject _every_ LPI found there that got enabled.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-its.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index bcabb04..c130d98 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -297,6 +297,39 @@ out_unlock:
 return ret;
 }
 
+/* INVALL updates the per-LPI configuration status for every LPI mapped to
+ * a particular redistributor. Since our property table is referenced when
+ * needed, we don't need to sync anything, really. But we have to take care
+ * of LPIs getting enabled if there is an interrupt pending.
+ * To catch every LPI without iterating through the device table we just
+ * look for set bits in our virtual pending table and check the status of
+ * the enabled bit in the respective property table entry.
+ * This actually covers every (pending) LPI from every redistributor,
+ * but update_lpi_enabled_status() is a NOP for LPIs not being mapped
+ * to the redistributor/VCPU we are interested in.
+ */
+static int its_handle_invall(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t collid = its_cmd_get_collection(cmdptr);
+struct vcpu *vcpu;
+int vlpi = 0;
+
+spin_lock(>its_lock);
+vcpu = get_vcpu_from_collection(its, collid);
+spin_unlock(>its_lock);
+
+do {
+vlpi = find_next_bit(vcpu->arch.vgic.pendtable,
+ its->d->arch.vgic.nr_lpis, vlpi);
+if (vlpi >= its->d->arch.vgic.nr_lpis)
+break;
+
+update_lpi_enabled_status(its, vcpu, vlpi);
+} while (1);
+
+return 0;
+}
+
 static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
 {
 uint32_t collid = its_cmd_get_collection(cmdptr);
@@ -490,6 +523,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_INV:
 its_handle_inv(its, cmdptr);
break;
+case GITS_CMD_INVALL:
+its_handle_invall(its, cmdptr);
+   break;
 case GITS_CMD_MAPC:
 its_handle_mapc(its, cmdptr);
 break;
-- 
2.9.0


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

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

[Andre Przywara]

To get MSIs from devices forwarded to a CPU, we need to name the device
and its MSIs by mapping them to an ITS.
Since this involves queueing commands to the ITS command queue, we can't
really afford to do this during the guest's runtime, as this would open
up a denial-of-service attack vector.
So we require every device with MSI interrupts to be mapped explicitly by
Dom0. For Dom0 itself we can just use the existing PCI physdev_op
hypercalls, which the existing Linux kernel issues already.
So upon receipt of this hypercall we map the device to the hardware ITS
and prepare it to be later mapped by the virtual ITS by using the very
same device ID (for Dom0 only).
Also we ask for mapping 32 LPIs to cover 32 MSIs that the device may
use.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/physdev.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
index 27bbbda..d9e6be3 100644
--- a/xen/arch/arm/physdev.c
+++ b/xen/arch/arm/physdev.c
@@ -9,11 +9,35 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 
 int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
+struct physdev_manage_pci manage;
+struct domain *dom0;
+u32 devid;
+int ret;
+
+switch (cmd)
+{
+case PHYSDEVOP_manage_pci_add:
+case PHYSDEVOP_manage_pci_remove:
+if ( copy_from_guest(, arg, 1) != 0 )
+return -EFAULT;
+
+dom0 = hardware_domain;
+devid = manage.bus << 8 | manage.devfn;
+/* Allocate an ITS device table with space for 32 MSIs */
+ret = gicv3_its_map_device(dom0, devid, devid, 5,
+   cmd == PHYSDEVOP_manage_pci_add);
+
+put_domain(dom0);
+return ret;
+}
+
 gdprintk(XENLOG_DEBUG, "PHYSDEVOP cmd=%d: not implemented\n", cmd);
 return -ENOSYS;
 }
-- 
2.9.0


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

[Xen-devel] [RFC PATCH v2 20/26] ARM: vITS: handle MOVI command

[Andre Przywara]

The MOVI command moves the interrupt affinity from one redistributor
(read: VCPU) to another.
For now migration of "live" LPIs is not yet implemented, but we store
the changed affinity in the host LPI structure and in our virtual ITTE.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c| 14 ++
 xen/arch/arm/vgic-its.c   | 41 +
 xen/include/asm-arm/gic-its.h |  2 ++
 3 files changed, 57 insertions(+)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index 0acbd83..1da28b9 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -799,6 +799,20 @@ int gicv3_assign_guest_event(struct domain *d, uint32_t 
devid, uint32_t eventid,
 hlpi.vcpu_id = v->vcpu_id;
 
 hlpip->data = hlpi.data;
+return 0;
+}
+
+/* Changes the target VCPU for a given host LPI assigned to a domain. */
+int gicv3_lpi_change_vcpu(struct domain *d,
+  uint32_t devid, uint32_t eventid, int vcpu_id)
+{
+union host_lpi *hlpip;
+
+hlpip = find_guest_lpi(d, devid, eventid);
+if ( !hlpip )
+return -1;
+
+hlpip->vcpu_id = vcpu_id;
 
 return 0;
 }
diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index f9f438a..7c80c17 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -316,6 +316,41 @@ out_unlock:
 return ret;
 }
 
+static int its_handle_movi(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+int collid = its_cmd_get_collection(cmdptr);
+struct vits_itte *itte;
+struct vcpu *vcpu;
+
+if ( collid >= its->max_collections )
+return -1;
+
+spin_lock(>its_lock);
+
+vcpu = get_vcpu_from_collection(its, collid);
+if ( !vcpu )
+goto out_unlock;
+
+itte = get_devid_evid(its, devid, eventid);
+if ( !itte )
+goto out_unlock;
+
+itte->collection = collid;
+
+/* TODO: lookup currently-in-guest virtual IRQs and migrate them */
+
+put_devid_evid(its, itte);
+
+out_unlock:
+spin_unlock(>its_lock);
+
+gicv3_lpi_change_vcpu(its->d, devid, eventid, vcpu->vcpu_id);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 
 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -352,6 +387,12 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_MAPTI:
 its_handle_mapti(its, cmdptr);
 break;
+case GITS_CMD_MOVALL:
+gdprintk(XENLOG_G_INFO, "ITS: ignoring MOVALL command\n");
+break;
+case GITS_CMD_MOVI:
+its_handle_movi(its, cmdptr);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index 9843674..c5355f9 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -140,6 +140,8 @@ int gicv3_its_map_device(struct domain *d, int host_devid, 
int guest_devid,
 int gicv3_assign_guest_event(struct domain *d,
  uint32_t devid, uint32_t eventid,
  struct vcpu *v, uint32_t virt_lpi);
+int gicv3_lpi_change_vcpu(struct domain *d,
+  uint32_t devid, uint32_t eventid, int vcpu_id);
 
 #else
 
-- 
2.9.0


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

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

[Andre Przywara]

The ARM GICv3 ITS provides a new kind of interrupt called LPIs.
The pending bits and the configuration data (priority, enable bits) for
those LPIs are stored in tables in normal memory, which software has to
provide to the hardware.
Allocate the required memory, initialize it and hand it over to each
ITS. The maximum number of LPIs to be used can be adjusted with the
command line option "max_lpi_bits", which defaults to a compile time
constant exposed in Kconfig.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/Kconfig  | 10 +
 xen/arch/arm/efi/efi-boot.h   |  1 -
 xen/arch/arm/gic-its.c| 94 +++
 xen/arch/arm/gic-v3.c | 43 ++
 xen/include/asm-arm/bitops.h  |  1 +
 xen/include/asm-arm/cache.h   |  4 ++
 xen/include/asm-arm/gic-its.h | 22 -
 xen/include/asm-arm/gic_v3_defs.h | 48 +++-
 8 files changed, 220 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index bf64c61..a7d941c 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -49,6 +49,16 @@ config HAS_ITS
 bool "GICv3 ITS MSI controller support"
 depends on HAS_GICV3
 
+config MAX_HOST_LPI_BITS
+depends on HAS_ITS
+int "Maximum bits for GICv3 host LPIs (14-32)"
+range 14 32
+default "20"
+help
+  Specifies the maximum number of LPIs (bits) Xen should take care of.
+  This can be overriden on the command line with the max_lpi_bits
+  parameter.
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 045d6ce..dc64aec 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -10,7 +10,6 @@
 #include "efi-dom0.h"
 
 void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
-void __flush_dcache_area(const void *vaddr, unsigned long size);
 
 #define DEVICE_TREE_GUID \
 {0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0}}
diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index 973f9f9..6c3a35d 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -20,10 +20,104 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
+/* Global state */
+static struct {
+uint8_t *lpi_property;
+unsigned int host_lpi_bits;
+} lpi_data;
+
+/* Pending table for each redistributor */
+static DEFINE_PER_CPU(void *, pending_table);
+
+#define MAX_PHYS_LPIS   (BIT_ULL(lpi_data.host_lpi_bits) - 8192)
+
+uint64_t gicv3_lpi_allocate_pendtable(void)
+{
+uint64_t reg, attr;
+void *pendtable;
+
+attr  = GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
+attr |= GIC_BASER_CACHE_SameAsInner << 
GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
+attr |= GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT;
+
+if ( !this_cpu(pending_table) )
+{
+/*
+ * The pending table holds one bit per LPI, so we need (2 << 3) bits
+ * less bytes. The pending table covers even bits for interrupt IDs
+ * below 8192, so we allocate the full range.
+ * The ITS imposes a 64KB alignment requirement.
+ */
+pendtable = _xmalloc(BIT_ULL(lpi_data.host_lpi_bits) / 8, SZ_64K);
+if ( !pendtable )
+return 0;
+
+memset(pendtable, 0, BIT_ULL(lpi_data.host_lpi_bits) / 8);
+__flush_dcache_area(pendtable, BIT_ULL(lpi_data.host_lpi_bits) / 8);
+
+this_cpu(pending_table) = pendtable;
+}
+else
+{
+pendtable = this_cpu(pending_table);
+}
+
+reg  = attr | GICR_PENDBASER_PTZ;
+reg |= virt_to_maddr(pendtable) & GENMASK(51, 16);
+
+return reg;
+}
+
+uint64_t gicv3_lpi_get_proptable()
+{
+uint64_t attr, reg;
+
+attr  = GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
+attr |= GIC_BASER_CACHE_SameAsInner << 
GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
+attr |= GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT;
+
+/*
+ * The property table is shared across all redistributors, so allocate
+ * this only once, but return the same value on subsequent calls.
+ */
+if ( !lpi_data.lpi_property )
+{
+/* The property table holds one byte per LPI. */
+void *table = alloc_xenheap_pages(lpi_data.host_lpi_bits - PAGE_SHIFT,
+  0);
+
+if ( !table )
+return 0;
+
+memset(table, GIC_PRI_IRQ | LPI_PROP_RES1, MAX_PHYS_LPIS);
+__flush_dcache_area(table, MAX_PHYS_LPIS);
+lpi_data.lpi_property = table;
+}
+
+reg  = attr | ((lpi_data.host_lpi_bits - 1) << 0);
+reg |= virt_to_maddr(lpi_data.lpi_property) & GENMASK(51, 12);
+
+return reg;
+}
+
+static unsigned int max_lpi_bits = CONFIG_MAX_HOST_LPI_BITS;

[Xen-devel] [RFC PATCH v2 01/26] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT

[Andre Przywara]

Parse the DT GIC subnodes to find every ITS MSI controller the hardware
offers. Store that information in a list to both propagate all of them
later to Dom0, but also to be able to iterate over all ITSes.
This introduces an ITS Kconfig option.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/Kconfig  |  4 +++
 xen/arch/arm/Makefile |  1 +
 xen/arch/arm/gic-its.c| 68 +++
 xen/arch/arm/gic-v3.c |  6 
 xen/include/asm-arm/gic-its.h | 57 
 5 files changed, 136 insertions(+)
 create mode 100644 xen/arch/arm/gic-its.c
 create mode 100644 xen/include/asm-arm/gic-its.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 2e023d1..bf64c61 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -45,6 +45,10 @@ config ACPI
 config HAS_GICV3
bool
 
+config HAS_ITS
+bool "GICv3 ITS MSI controller support"
+depends on HAS_GICV3
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 59b3b53..80c2951 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -18,6 +18,7 @@ obj-$(EARLY_PRINTK) += early_printk.o
 obj-y += gic.o
 obj-y += gic-v2.o
 obj-$(CONFIG_HAS_GICV3) += gic-v3.o
+obj-$(CONFIG_HAS_ITS) += gic-its.o
 obj-y += guestcopy.o
 obj-y += hvm.o
 obj-y += io.o
diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
new file mode 100644
index 000..973f9f9
--- /dev/null
+++ b/xen/arch/arm/gic-its.c
@@ -0,0 +1,68 @@
+/*
+ * xen/arch/arm/gic-its.c
+ *
+ * ARM Generic Interrupt Controller ITS support
+ *
+ * Copyright (C) 2016 - ARM Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
+void gicv3_its_dt_init(const struct dt_device_node *node)
+{
+const struct dt_device_node *its = NULL;
+struct host_its *its_data;
+
+/*
+ * Check for ITS MSI subnodes. If any, add the ITS register
+ * frames to the ITS list.
+ */
+dt_for_each_child_node(node, its)
+{
+paddr_t addr, size;
+
+if ( !dt_device_is_compatible(its, "arm,gic-v3-its") )
+continue;
+
+if ( dt_device_get_address(its, 0, , ) )
+panic("GICv3: Cannot find a valid ITS frame address");
+
+its_data = xzalloc(struct host_its);
+if ( !its_data )
+panic("GICv3: Cannot allocate memory for ITS frame");
+
+its_data->addr = addr;
+its_data->size = size;
+its_data->dt_node = its;
+
+printk("GICv3: Found ITS @0x%lx\n", addr);
+
+list_add_tail(_data->entry, _its_list);
+}
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b8be395..238da84 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -43,9 +43,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+LIST_HEAD(host_its_list);
+
 /* Global state */
 static struct {
 void __iomem *map_dbase;  /* Mapped address of distributor registers */
@@ -1229,6 +1232,9 @@ static void __init gicv3_dt_init(void)
 
 dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
   , );
+
+/* Check for ITS child nodes and build the host ITS list accordingly. */
+gicv3_its_dt_init(node);
 }
 
 static int gicv3_iomem_deny_access(const struct domain *d)
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
new file mode 100644
index 000..2f5c51c
--- /dev/null
+++ b/xen/include/asm-arm/gic-its.h
@@ -0,0 +1,57 @@
+/*
+ * ARM GICv3 ITS support
+ *
+ * Andre Przywara 
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASM_ARM_ITS_H__
+#define 

[Xen-devel] [RFC PATCH v2 14/26] ARM: vGICv3: introduce basic ITS emulation bits

[Andre Przywara]

Create a new file to hold the emulation code for the ITS widget.
For now we emulate the memory mapped ITS registers and provide a stub
to introduce the ITS command handling framework (but without actually
emulating any commands at this time).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/vgic-its.c   | 377 ++
 xen/arch/arm/vgic-v3.c|   9 -
 xen/include/asm-arm/gic_v3_defs.h |  19 ++
 4 files changed, 397 insertions(+), 9 deletions(-)
 create mode 100644 xen/arch/arm/vgic-its.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 80c2951..346454d 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -45,6 +45,7 @@ obj-y += traps.o
 obj-y += vgic.o
 obj-y += vgic-v2.o
 obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
+obj-$(CONFIG_HAS_ITS) += vgic-its.o
 obj-y += vm_event.o
 obj-y += vtimer.o
 obj-y += vpsci.o
diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
new file mode 100644
index 000..e5e9ae4
--- /dev/null
+++ b/xen/arch/arm/vgic-its.c
@@ -0,0 +1,377 @@
+/*
+ * xen/arch/arm/vgic-its.c
+ *
+ * ARM Interrupt Translation Service (ITS) emulation
+ *
+ * Andre Przywara 
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Data structure to describe a virtual ITS */
+struct virt_its {
+struct domain *d;
+struct host_its *hw_its;
+spinlock_t vcmd_lock;   /* protects the virtual command buffer */
+uint64_t cbaser;
+uint64_t *cmdbuf;
+int cwriter;
+int creadr;
+spinlock_t its_lock;/* protects the collection and device tables */
+uint64_t baser0, baser1;
+uint16_t *coll_table;
+int max_collections;
+uint64_t *dev_table;
+int max_devices;
+bool enabled;
+};
+
+/* An Interrupt Translation Table Entry: this is indexed by a
+ * DeviceID/EventID pair and is located in guest memory.
+ */
+struct vits_itte
+{
+uint32_t vlpi;
+uint16_t collection;
+};
+
+/**
+ * Functions that handle ITS commands *
+ **/
+
+static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
+   int word, int shift, int size)
+{
+return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
+}
+
+#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0,  0,  8)
+#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0, 32, 32)
+#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1,  0,  5)
+#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1,  0, 32)
+#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
+#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2,  0, 16)
+#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
+#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
+
+#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
+
+static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
+uint32_t writer)
+{
+uint64_t *cmdptr;
+
+if ( !its->cmdbuf )
+return -1;
+
+if ( writer >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
+return -1;
+
+spin_lock(>vcmd_lock);
+
+while ( its->creadr != writer )
+{
+cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
+switch (its_cmd_get_command(cmdptr))
+{
+case GITS_CMD_SYNC:
+/* We handle ITS commands synchronously, so we ignore SYNC. */
+   break;
+default:
+gdprintk(XENLOG_G_WARNING, "ITS: unhandled ITS command %ld\n",
+   its_cmd_get_command(cmdptr));
+break;
+}
+
+its->creadr += ITS_CMD_SIZE;
+if ( its->creadr == ITS_CMD_BUFFER_SIZE(its->cbaser) )
+its->creadr = 0;
+}
+its->cwriter = writer;
+
+spin_unlock(>vcmd_lock);
+
+return 0;
+}
+
+/*
+ * ITS registers read access *
+ */
+
+/* The physical address is encoded slightly differently depending on
+ * the used page size: the highest four bits are stored in the lowest
+ * four bits of the field for 64K pages.
+ */

[Xen-devel] [RFC PATCH v2 19/26] ARM: vITS: handle MAPTI command

[Andre Przywara]

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts.
We connect the already allocated host LPI to this virtual LPI, so that
any triggering IRQ on the host can be quickly forwarded to
a guest.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c| 49 +++
 xen/arch/arm/vgic-its.c   | 44 ++
 xen/include/asm-arm/gic-its.h |  4 
 3 files changed, 97 insertions(+)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index 54e604a..0acbd83 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -754,6 +754,55 @@ retry:
 return 0;
 }
 
+static union host_lpi *find_guest_lpi(struct domain *d,
+  uint32_t devid, uint32_t eventid)
+{
+struct its_devices *dev;
+uint32_t lpi;
+
+list_for_each_entry( dev, >arch.vgic.its_devices, entry )
+{
+if (dev->guest_devid != devid )
+continue;
+
+if ( eventid >= dev->eventids )
+return NULL;
+
+lpi = dev->host_lpis[eventid / 32] + (eventid % 32);
+if (lpi < 8192)
+return NULL;
+
+lpi -= 8192;
+
+return _data.host_lpis[lpi / HOST_LPIS_PER_PAGE][lpi % 
HOST_LPIS_PER_PAGE];
+}
+
+return NULL;
+}
+
+/* Connects the event ID for an already assigned device to the given VCPU/vLPI
+ * pair. The corresponding physical LPI is already mapped on the host side
+ * (when assigning the physical device to the guest), so we just connect the
+ * target VCPU/vLPI pair to that interrupt to inject it properly if it fires.
+ */
+int gicv3_assign_guest_event(struct domain *d, uint32_t devid, uint32_t 
eventid,
+ struct vcpu *v, uint32_t virt_lpi)
+{
+union host_lpi hlpi, *hlpip;
+
+hlpip = find_guest_lpi(d, devid, eventid);
+if ( !hlpip )
+return -1;
+
+hlpi.virt_lpi = virt_lpi;
+hlpi.dom_id = d->domain_id;
+hlpi.vcpu_id = v->vcpu_id;
+
+hlpip->data = hlpi.data;
+
+return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index 918b504..f9f438a 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -276,6 +276,46 @@ static int its_handle_mapd(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }
 
+static int its_handle_mapti(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+uint32_t intid = its_cmd_get_physical_id(cmdptr);
+int collid = its_cmd_get_collection(cmdptr);
+struct vits_itte *itte;
+struct vcpu *vcpu;
+int ret = -1;
+
+if ( its_cmd_get_command(cmdptr) == GITS_CMD_MAPI )
+intid = eventid;
+
+if ( collid >= its->max_collections )
+return -1;
+
+spin_lock(>its_lock);
+vcpu = get_vcpu_from_collection(its, collid);
+if ( !vcpu )
+goto out_unlock;
+
+itte = get_devid_evid(its, devid, eventid);
+if ( !itte )
+goto out_unlock;
+
+itte->vlpi = intid;
+itte->collection = collid;
+
+gicv3_assign_guest_event(its->d, devid, eventid, vcpu, intid);
+
+ret = 0;
+
+put_devid_evid(its, itte);
+
+out_unlock:
+spin_unlock(>its_lock);
+
+return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 
 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -308,6 +348,10 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_MAPD:
 its_handle_mapd(its, cmdptr);
break;
+case GITS_CMD_MAPI:
+case GITS_CMD_MAPTI:
+its_handle_mapti(its, cmdptr);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index d1ebc19..9843674 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -137,6 +137,10 @@ void gicv3_its_setup_collection(int cpu);
 int gicv3_its_map_device(struct domain *d, int host_devid, int guest_devid,
  int bits, bool valid);
 
+int gicv3_assign_guest_event(struct domain *d,
+ uint32_t devid, uint32_t eventid,
+ struct vcpu *v, uint32_t virt_lpi);
+
 #else
 
 static inline void gicv3_its_dt_init(const struct dt_device_node *node)
-- 
2.9.0


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

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

[Andre Przywara]

If a guest disables an LPI, we do not forward this to the associated
host LPI to avoid queueing commands to the host ITS command queue.
So it may happen that an LPI fires nevertheless on the host. In this
case we can bail out early, but have to save the pending state on the
virtual side.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c |  8 
 xen/arch/arm/vgic-v3.c | 12 
 xen/include/asm-arm/vgic.h |  1 +
 3 files changed, 21 insertions(+)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index 602e19a..54e604a 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -104,6 +104,14 @@ void do_LPI(unsigned int lpi)
 
 vcpu = d->vcpu[hlpi.vcpu_id];
 
+/*
+ * We keep all host LPIs enabled, so check if it's disabled on the guest
+ * side and just record this LPI in the virtual pending table in this case.
+ * The guest picks it up once it gets enabled again.
+ */
+if ( !vgic_can_inject_lpi(vcpu, hlpi.virt_lpi) )
+return;
+
 vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
 }
 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index b981d4e..206e00b 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -483,6 +483,18 @@ bool vgic_lpi_is_enabled(struct domain *d, uint32_t vlpi)
 return d->arch.vgic.proptable[vlpi - 8192] & LPI_PROP_ENABLED;
 }
 
+bool vgic_can_inject_lpi(struct vcpu *vcpu, uint32_t vlpi)
+{
+if ( vlpi >= vcpu->domain->arch.vgic.nr_lpis )
+return false;
+
+if ( vgic_lpi_is_enabled(vcpu->domain, vlpi) )
+return true;
+
+set_bit(vlpi - 8192, vcpu->arch.vgic.pendtable);
+return false;
+}
+
 static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
   uint32_t gicr_reg,
   register_t r)
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 1c157d3..73291dd 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -317,6 +317,7 @@ extern void vgic_disable_irqs(struct vcpu *v, uint32_t r, 
int n);
 extern void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n);
 extern bool vgic_lpi_is_enabled(struct domain *d, uint32_t vlpi);
 extern int vgic_lpi_get_priority(struct domain *d, uint32_t vlpi);
+extern bool vgic_can_inject_lpi(struct vcpu *v, uint32_t vlpi);
 extern void register_vgic_ops(struct domain *d, const struct vgic_ops *ops);
 int vgic_v2_init(struct domain *d, int *mmio_count);
 int vgic_v3_init(struct domain *d, int *mmio_count);
-- 
2.9.0


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

[Xen-devel] [RFC PATCH v2 18/26] ARM: vITS: handle MAPD command

[Andre Przywara]

The MAPD command maps a device by associating a memory region for
storing ITTEs with a certain device ID.
We just store the given guest physical address in the device table.
We don't map the device tables permanently, as their alignment
requirement is only 256 Bytes, thus making mapping of several tables
complicated. We map the device tables on demand when we need them later.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-its.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index b425776..918b504 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -255,6 +255,27 @@ static int its_handle_mapc(struct virt_its *its, uint64_t 
*cmdptr)
 return ret;
 }
 
+static int its_handle_mapd(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+int size = its_cmd_get_size(cmdptr);
+bool valid = its_cmd_get_validbit(cmdptr);
+paddr_t itt_addr = its_cmd_mask_field(cmdptr, 2, 0, 52) & GENMASK(51, 8);
+
+if ( !its->dev_table )
+return -1;
+
+spin_lock(>its_lock);
+if ( valid )
+its->dev_table[devid] = DEV_TABLE_ENTRY(itt_addr, size + 1);
+else
+its->dev_table[devid] = 0;
+
+spin_unlock(>its_lock);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 
 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -284,6 +305,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_MAPC:
 its_handle_mapc(its, cmdptr);
 break;
+case GITS_CMD_MAPD:
+its_handle_mapd(its, cmdptr);
+   break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;
-- 
2.9.0


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

[Xen-devel] [RFC PATCH v2 16/26] ARM: vITS: handle INT command

[Andre Przywara]

The INT command sets a given LPI identified by a DeviceID/EventID pair
as pending and thus triggers it to be injected.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-its.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index e2e94c4..612f55b 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -193,6 +193,41 @@ static int its_handle_clear(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }
 
+static int its_handle_int(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct vits_itte *itte;
+struct vcpu *vcpu;
+int ret = -1;
+uint32_t vlpi;
+
+spin_lock(>its_lock);
+
+itte = get_devid_evid(its, devid, eventid);
+if ( !itte )
+goto out_unlock;
+
+vcpu = its->d->vcpu[itte->collection];
+vlpi = itte->vlpi;
+
+ret = 0;
+
+put_devid_evid(its, itte);
+
+out_unlock:
+spin_unlock(>its_lock);
+
+if ( !ret) {
+if (vcpu->domain->arch.vgic.proptable[vlpi - 8192] & LPI_PROP_ENABLED)
+vgic_vcpu_inject_irq(vcpu, vlpi);
+else
+set_bit(vlpi - 8192, vcpu->arch.vgic.pendtable);
+}
+
+return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 
 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -216,6 +251,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_CLEAR:
 its_handle_clear(its, cmdptr);
 break;
+case GITS_CMD_INT:
+its_handle_int(its, cmdptr);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;
-- 
2.9.0


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

[Xen-devel] [RFC PATCH v2 15/26] ARM: vITS: handle CLEAR command

[Andre Przywara]

This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.

In addition this patch introduces the lookup function which translates
a given DeviceID/EventID pair into a pointer to our vITTE structure.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-its.c | 117 
 1 file changed, 117 insertions(+)

diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index e5e9ae4..e2e94c4 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -60,6 +60,73 @@ struct vits_itte
 uint16_t collection;
 };
 
+#define UNMAPPED_COLLECTION  ((uint16_t)~0)
+
+/* Must be called with the ITS lock held. */
+static struct vcpu *get_vcpu_from_collection(struct virt_its *its, int collid)
+{
+uint16_t vcpu_id;
+
+if ( collid >= its->max_collections )
+return NULL;
+
+vcpu_id = its->coll_table[collid];
+if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
+return NULL;
+
+return its->d->vcpu[vcpu_id];
+}
+
+#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
+#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(7, 0)) + 1))
+#define DEV_TABLE_ENTRY(addr, bits) \
+(((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(7, 0)))
+
+static paddr_t get_itte_address(struct virt_its *its,
+uint32_t devid, uint32_t evid)
+{
+paddr_t addr;
+
+if ( devid >= its->max_devices )
+return ~0;
+
+if ( evid >= DEV_TABLE_ITT_SIZE(its->dev_table[devid]) )
+return ~0;
+
+addr = DEV_TABLE_ITT_ADDR(its->dev_table[devid]);
+
+return addr + evid * sizeof(struct vits_itte);
+}
+
+/* Looks up a given deviceID/eventID pair on an ITS and returns a pointer to
+ * the corresponding ITTE. This maps the respective guest page into Xen.
+ * Once finished with handling the ITTE, call put_devid_evid() to unmap
+ * the page again.
+ * Must be called with the ITS lock held.
+ */
+static struct vits_itte *get_devid_evid(struct virt_its *its,
+uint32_t devid, uint32_t evid)
+{
+paddr_t addr = get_itte_address(its, devid, evid);
+struct vits_itte *itte;
+
+if ( addr == ~0 )
+return NULL;
+
+/* TODO: check locking for map_guest_pages() */
+itte = map_guest_pages(its->d, addr & PAGE_MASK, 1);
+if ( !itte )
+return NULL;
+
+return itte + (addr & ~PAGE_MASK) / sizeof(struct vits_itte);
+}
+
+/* Must be called with the ITS lock held. */
+static void put_devid_evid(struct virt_its *its, struct vits_itte *itte)
+{
+unmap_guest_pages(itte, 1);
+}
+
 /**
  * Functions that handle ITS commands *
  **/
@@ -79,6 +146,53 @@ static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
 #define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
 #define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
 
+static int its_handle_clear(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct pending_irq *pirq;
+struct vits_itte *itte;
+struct vcpu *vcpu;
+uint32_t vlpi;
+
+spin_lock(>its_lock);
+
+itte = get_devid_evid(its, devid, eventid);
+if ( !itte )
+{
+spin_unlock(>its_lock);
+return -1;
+}
+
+vcpu = get_vcpu_from_collection(its, itte->collection);
+if ( !vcpu )
+{
+spin_unlock(>its_lock);
+return -1;
+}
+
+vlpi = itte->vlpi;
+
+put_devid_evid(its, itte);
+spin_unlock(>its_lock);
+
+/* Remove a pending, but not yet injected guest IRQ. */
+pirq = lpi_to_pending(vcpu, vlpi, false);
+if ( pirq )
+{
+clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+gic_remove_from_queues(vcpu, vlpi);
+
+/* Mark this pending IRQ struct as availabe again. */
+if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+pirq->irq = 0;
+}
+
+clear_bit(vlpi - 8192, vcpu->arch.vgic.pendtable);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 
 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -99,6 +213,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
 switch (its_cmd_get_command(cmdptr))
 {
+case GITS_CMD_CLEAR:
+its_handle_clear(its, cmdptr);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;
-- 
2.9.0


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

[Xen-devel] [RFC PATCH v2 04/26] ARM: GICv3 ITS: map ITS command buffer

[Andre Przywara]

Instead of directly manipulating the tables in memory, an ITS driver
sends commands via a ring buffer to the ITS h/w to create or alter the
LPI mappings.
Allocate memory for that buffer and tell the ITS about it to be able
to send ITS commands.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c| 27 +++
 xen/include/asm-arm/gic-its.h |  3 +++
 2 files changed, 30 insertions(+)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index f1540b2..2fb3bcb 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -38,6 +39,8 @@ static DEFINE_PER_CPU(void *, pending_table);
 
 #define MAX_PHYS_LPIS   (BIT_ULL(lpi_data.host_lpi_bits) - 8192)
 
+#define ITS_CMD_QUEUE_SZSZ_64K
+
 #define BASER_ATTR_MASK   \
 ((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
  (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
@@ -55,6 +58,26 @@ static uint64_t encode_phys_addr(paddr_t addr, int page_bits)
 return ret | (addr & GENMASK(51, 48)) >> (48 - 12);
 }
 
+static void *its_map_cbaser(void __iomem *cbasereg)
+{
+uint64_t attr, reg;
+void *buffer;
+
+attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+attr |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+
+buffer = _xzalloc(ITS_CMD_QUEUE_SZ, PAGE_SIZE);
+if ( !buffer )
+return NULL;
+
+reg = attr | BIT_ULL(63) | (virt_to_maddr(buffer) & GENMASK(51, 12));
+reg |= ((ITS_CMD_QUEUE_SZ / PAGE_SIZE) - 1) & GITS_CBASER_SIZE_MASK;
+writeq_relaxed(reg, cbasereg);
+
+return buffer;
+}
+
 static int its_map_baser(void __iomem *basereg, uint64_t regc, int nr_items)
 {
 uint64_t attr;
@@ -148,6 +171,10 @@ int gicv3_its_init(struct host_its *hw_its)
 }
 }
 
+hw_its->cmd_buf = its_map_cbaser(hw_its->its_base + GITS_CBASER);
+if ( !hw_its->cmd_buf )
+return -ENOMEM;
+
 return 0;
 }
 
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index 26b0584..e0fded8 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -61,6 +61,8 @@
 (31UL << GITS_BASER_ENTRY_SIZE_SHIFT) 
|\
 GITS_BASER_INDIRECT)
 
+#define GITS_CBASER_SIZE_MASK   0xff
+
 #ifndef __ASSEMBLY__
 #include 
 
@@ -71,6 +73,7 @@ struct host_its {
 paddr_t addr;
 paddr_t size;
 void __iomem *its_base;
+void *cmd_buf;
 };
 
 extern struct list_head host_its_list;
-- 
2.9.0


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

[Xen-devel] [RFC PATCH v2 00/26] arm64: Dom0 ITS emulation

[Andre Przywara]

Hi,

this is a reworked version of the Dom0 GICv3-ITS emulation series.
This is still not fully where I want it and has some loose bits and
pieces still, but since there are significant changes in the architecture
I wanted to have an opinion before going ahead and replacing every single
number with a named constant ;-) If that smells like a "send out before
the end of the year", you are spot on.

This series introduces ARM GICv3 ITS emulation, for now restricted to
Dom0 only. The ITS is an interrupt controller widget providing a
sophisticated way to deal with MSIs in a scalable manner.
For hardware which relies on the ITS to provide interrupts for its
peripherals this code is needed to get a machine booted into Dom0 at all.
ITS emulation for DomUs is only really useful with PCI passthrough,
which is not yet available for ARM. It is expected that this feature
will be co-developed with the ITS DomU code. However this code drop here
considered DomU emulation already, to keep later architectural changes
to a minimum.

Some generic design principles:

* The current GIC code statically allocates structures for each supported
IRQ (both for the host and the guest), which due to the potentially
millions of LPI interrupts is not feasible to copy for the ITS.
So we refrain from introducing the ITS as a first class Xen interrupt
controller, also we don't hold struct irq_desc's or struct pending_irq's
for each possible LPI.
Fortunately LPIs are only interesting to guests, so we get away with
storing only the virtual IRQ number and the guest VCPU for each allocated
host LPI, which can be stashed into one uint64_t. This data is stored in
a two-level table, which is both memory efficient and quick to access.
We hook into the existing IRQ handling and VGIC code to avoid accessing
the normal structures, providing alternative methods for getting the
needed information (priority, is enabled?) for LPIs.
For interrupts which are queued to or are actually in a guest we
allocate struct pending_irq's on demand. As it is expected that only a
very small number of interrupts is ever on a VCPU at the same time, this
seems like the best approach. For now allocated structs are re-used and
held in a linked list.

* On the guest side we (later will) have to deal with malicious guests
trying to hog Xen with mapping requests for a lot of LPIs, for instance.
As the ITS actually uses system memory for storing status information,
we use this memory (which the guest has to provide) to naturally limit
a guest. For those tables which are page sized (devices, collections (CPUs),
LPI properties) we map those pages into Xen, so we can easily access
them from the virtual GIC code.
Unfortunately the actual interrupt mapping tables are not necessarily
page aligned, also can be much smaller than a page, so mapping all of
them permanently is fiddly. As ITS commands in need to iterate those
tables are pretty rare after all, we for now map them on demand upon
emulating a virtual ITS command.

* An obvious approach to handling some guest ITS commands would be to
propagate them to the host, for instance to map devices and LPIs and
to enable or disable LPIs.
However this (later with DomU support) will create an attack vector, as
a malicious guest could try to fill the host command queue with
propagated commands.
So in contrast to the previous RFC post this version now completely avoids
this situation. For mapping devices and LPIs we rely on this being done
via a hypercall prior to the actual guest run. For enabling and disabling
LPIs we keep this bit on the virtual side and let LPIs always be enabled
on the host side, dealing with the consequences this approach creates.

This series is still a draft, with some known and many unknown issues.
I made ITS support a Kconfig option, also it is only supported on arm64.
This leads to some hideous constructs like an #ifdef'ed header file with
empty function stubs, but I guess we can clean this up later in the
upstreaming process.

There are numerous changes compared to the last post, mainly affecting
the now missing ITS command progagation. I also added locking to the
"usual suspects" data structures.
I picked some low hanging fruits from the review comments.
Things I haven't addresses well is the whole memory management, in terms
of marking pages r/o for a guest or allocating Xen memory from the proper
bucket. This will be addresses with the next post.

For now this code happens to boot Dom0 on an ARM fast model with ITS
support. I still haven't had the chance to get hold of a Xen supported
hardware platform with an ITS yet, so running on real hardware is a bit
terra incognita.

The code can also be found on the its/rfc-v2 branch here:
git://linux-arm.org/xen-ap.git
http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/its/rfc-v2

Cheers,
Andre

Andre Przywara (26):
  ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT
  ARM: GICv3: allocate LPI pending and property table
  ARM: GICv3 ITS: 

[Xen-devel] [RFC PATCH v2 17/26] ARM: vITS: handle MAPC command

[Andre Przywara]

The MAPC command associates a given collection ID with a given
redistributor, thus mapping collections to VCPUs.
We just store the vcpu_id in the collection table for that.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-its.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
index 612f55b..b425776 100644
--- a/xen/arch/arm/vgic-its.c
+++ b/xen/arch/arm/vgic-its.c
@@ -228,6 +228,33 @@ out_unlock:
 return ret;
 }
 
+static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t collid = its_cmd_get_collection(cmdptr);
+uint64_t rdbase = its_cmd_mask_field(cmdptr, 2, 16, 44);
+int ret = -1;
+
+if ( collid >= its->max_collections )
+return ret;
+
+if ( rdbase >= its->d->max_vcpus )
+return ret;
+
+spin_lock(>its_lock);
+if ( its->coll_table )
+{
+if ( its_cmd_get_validbit(cmdptr) )
+its->coll_table[collid] = rdbase;
+else
+its->coll_table[collid] = UNMAPPED_COLLECTION;
+
+ret = 0;
+}
+spin_unlock(>its_lock);
+
+return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 
 static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
@@ -254,6 +281,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its,
 case GITS_CMD_INT:
 its_handle_int(its, cmdptr);
 break;
+case GITS_CMD_MAPC:
+its_handle_mapc(its, cmdptr);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
break;
-- 
2.9.0


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

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

[Andre Przywara]

Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers and map those pages into Xen's address space to have easy
access.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3.c   | 202 ---
 xen/arch/arm/vgic.c  |   4 +
 xen/include/asm-arm/domain.h |   8 +-
 xen/include/asm-arm/vgic.h   |   4 +
 4 files changed, 203 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 0ffde74..b981d4e 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -20,12 +20,14 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -229,12 +231,14 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 goto read_reserved;
 
 case VREG64(GICR_PROPBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+*r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);
+return 1;
 
 case VREG64(GICR_PENDBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+*r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
+return 1;
 
 case 0x0080:
 goto read_reserved;
@@ -302,11 +306,6 @@ bad_width:
 domain_crash_synchronous();
 return 0;
 
-read_as_zero_64:
-if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-*r = 0;
-return 1;
-
 read_as_zero_32:
 if ( dabt.size != DABT_WORD ) goto bad_width;
 *r = 0;
@@ -331,6 +330,143 @@ read_unknown:
 return 1;
 }
 
+static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
+int field_shift,
+uint64_t (*sanitise_fn)(uint64_t))
+{
+uint64_t field = (reg & field_mask) >> field_shift;
+
+field = sanitise_fn(field) << field_shift;
+return (reg & ~field_mask) | field;
+}
+
+/* We want to avoid outer shareable. */
+static uint64_t vgic_sanitise_shareability(uint64_t field)
+{
+switch (field) {
+case GIC_BASER_OuterShareable:
+return GIC_BASER_InnerShareable;
+default:
+return field;
+}
+}
+
+/* Avoid any inner non-cacheable mapping. */
+static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
+{
+switch (field) {
+case GIC_BASER_CACHE_nCnB:
+case GIC_BASER_CACHE_nC:
+return GIC_BASER_CACHE_RaWb;
+default:
+return field;
+}
+}
+
+/* Non-cacheable or same-as-inner are OK. */
+static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
+{
+switch (field) {
+case GIC_BASER_CACHE_SameAsInner:
+case GIC_BASER_CACHE_nC:
+return field;
+default:
+return GIC_BASER_CACHE_nC;
+}
+}
+
+static uint64_t sanitize_propbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
+  GICR_PROPBASER_SHAREABILITY_SHIFT,
+  vgic_sanitise_shareability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
+  GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
+  vgic_sanitise_inner_cacheability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
+  GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
+  vgic_sanitise_outer_cacheability);
+
+reg &= ~PROPBASER_RES0_MASK;
+reg &= ~GENMASK(51, 48);
+return reg;
+}
+
+static uint64_t sanitize_pendbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
+  GICR_PENDBASER_SHAREABILITY_SHIFT,
+  vgic_sanitise_shareability);
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_INNER_CACHEABILITY_MASK,
+  GICR_PENDBASER_INNER_CACHEABILITY_SHIFT,
+  vgic_sanitise_inner_cacheability);
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_OUTER_CACHEABILITY_MASK,
+  GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT,
+  vgic_sanitise_outer_cacheability);
+
+reg &= ~PENDBASER_RES0_MASK;
+reg &= ~GENMASK(51, 48);
+return reg;
+}
+
+/*
+ * Allow mapping some parts of guest memory into Xen's VA space to have easy
+ * access to it. This is to allow ITS configuration data to be held in
+ * guest memory and avoid using Xen memory for that.
+ */
+void *map_guest_pages(struct domain *d, paddr_t guest_addr, int nr_pages)
+{
+mfn_t onepage;
+mfn_t *pages;
+int i;
+void *ptr;
+
+/* 

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

[Andre Przywara]

The number of LPIs on a host can be potentially huge (millions),
although in practise will be mostly reasonable. So prematurely allocating
an array of struct irq_desc's for each LPI is not an option.
However Xen itself does not care about LPIs, as every LPI will be injected
into a guest (Dom0 for now).
Create a dense data structure (8 Bytes) for each LPI which holds just
enough information to determine the virtual IRQ number and the VCPU into
which the LPI needs to be injected.
Also to not artificially limit the number of LPIs, we create a 2-level
table for holding those structures.
This patch introduces functions to initialize these tables and to
create, lookup and destroy entries for a given LPI.
We allocate and access LPI information in a way that does not require
a lock.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c| 233 +-
 xen/include/asm-arm/gic-its.h |   1 +
 2 files changed, 233 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index e157c6b..e7ddd90 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -18,21 +18,36 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+/* LPIs on the host always go to a guest, so no struct irq_desc for them. */
+union host_lpi {
+uint64_t data;
+struct {
+uint64_t virt_lpi:32;
+uint64_t dom_id:16;
+uint64_t vcpu_id:16;
+};
+};
+
 /* Global state */
 static struct {
 uint8_t *lpi_property;
+union host_lpi **host_lpis;
 unsigned int host_lpi_bits;
+/* Protects allocation and deallocation of host LPIs, but not the access */
+spinlock_t host_lpis_lock;
 } lpi_data;
 
 /* Physical redistributor address */
@@ -43,6 +58,19 @@ static DEFINE_PER_CPU(uint64_t, rdist_id);
 static DEFINE_PER_CPU(void *, pending_table);
 
 #define MAX_PHYS_LPIS   (BIT_ULL(lpi_data.host_lpi_bits) - 8192)
+#define HOST_LPIS_PER_PAGE  (PAGE_SIZE / sizeof(union host_lpi))
+
+static union host_lpi *gic_get_host_lpi(uint32_t plpi)
+{
+if ( plpi < 8192 || plpi >= MAX_PHYS_LPIS + 8192 )
+return NULL;
+
+plpi -= 8192;
+if ( !lpi_data.host_lpis[plpi / HOST_LPIS_PER_PAGE] )
+return NULL;
+
+return _data.host_lpis[plpi / HOST_LPIS_PER_PAGE][plpi % 
HOST_LPIS_PER_PAGE];
+}
 
 #define ITS_CMD_QUEUE_SZSZ_64K
 
@@ -96,6 +124,20 @@ static int its_send_cmd_sync(struct host_its *its, int cpu)
 return its_send_command(its, cmd);
 }
 
+static int its_send_cmd_mapti(struct host_its *its,
+  uint32_t deviceid, uint32_t eventid,
+  uint32_t pintid, uint16_t icid)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_MAPTI | ((uint64_t)deviceid << 32);
+cmd[1] = eventid | ((uint64_t)pintid << 32);
+cmd[2] = icid;
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
 static int its_send_cmd_mapc(struct host_its *its, int collection_id, int cpu)
 {
 uint64_t cmd[4];
@@ -124,6 +166,19 @@ static int its_send_cmd_mapd(struct host_its *its, 
uint32_t deviceid,
 return its_send_command(its, cmd);
 }
 
+static int its_send_cmd_inv(struct host_its *its,
+uint32_t deviceid, uint32_t eventid)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_INV | ((uint64_t)deviceid << 32);
+cmd[1] = eventid;
+cmd[2] = 0x00;
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
 /* Set up the (1:1) collection mapping for the given host CPU. */
 void gicv3_its_setup_collection(int cpu)
 {
@@ -366,21 +421,181 @@ uint64_t gicv3_lpi_get_proptable()
 static unsigned int max_lpi_bits = CONFIG_MAX_HOST_LPI_BITS;
 integer_param("max_lpi_bits", max_lpi_bits);
 
+/* Allocate the 2nd level array for host LPIs. This one holds pointers
+ * to the page with the actual "union host_lpi" entries. Our LPI limit
+ * avoids excessive memory usage.
+ */
 int gicv3_lpi_init_host_lpis(unsigned int hw_lpi_bits)
 {
+int nr_lpi_ptrs;
+
 lpi_data.host_lpi_bits = min(hw_lpi_bits, max_lpi_bits);
 
+spin_lock_init(_data.host_lpis_lock);
+
+nr_lpi_ptrs = MAX_PHYS_LPIS / (PAGE_SIZE / sizeof(union host_lpi));
+lpi_data.host_lpis = xzalloc_array(union host_lpi *, nr_lpi_ptrs);
+if ( !lpi_data.host_lpis )
+return -ENOMEM;
+
 printk("GICv3: using at most %lld LPIs on the host.\n", MAX_PHYS_LPIS);
 
 return 0;
 }
 
+#define INVALID_DOMID ((uint16_t)~0)
+#define LPI_BLOCK   32
+
+/* Must be called with host_lpis_lock held. */
+static int find_unused_host_lpi(int start, uint32_t *index)
+{
+int chunk;
+uint32_t i = *index;
+
+for ( chunk = start; chunk < MAX_PHYS_LPIS / HOST_LPIS_PER_PAGE; chunk++ )
+{
+/* If we hit an unallocated chunk, use entry 0 in that one. */
+if ( !lpi_data.host_lpis[chunk] )
+

[Xen-devel] [RFC PATCH v2 11/26] ARM: GICv3: enable ITS and LPIs on the host

[Andre Przywara]

Now that the host part of the ITS code is in place, we can enable the
ITS and also LPIs on each redistributor to get the show rolling.
At this point there would be no LPIs mapped, as guests don't know about
the ITS yet.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c |  4 
 xen/arch/arm/gic-v3.c  | 19 +++
 2 files changed, 23 insertions(+)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index 0d4ca1b..602e19a 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -375,6 +375,10 @@ int gicv3_its_init(struct host_its *hw_its)
 its_send_cmd_mapc(hw_its, smp_processor_id(), smp_processor_id());
 its_send_cmd_sync(hw_its, smp_processor_id());
 
+/* Now enable interrupt translation on that ITS. */
+reg = readl_relaxed(hw_its->its_base + GITS_CTLR);
+writel_relaxed(reg | GITS_CTLR_ENABLE, hw_its->its_base + GITS_CTLR);
+
 return 0;
 }
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index d2461cb..5bfdf24 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -648,6 +648,21 @@ static int gicv3_rdist_init_lpis(void __iomem * rdist_base)
 return 0;
 }
 
+/* Enable LPIs on this redistributor (only useful when the host has an ITS. */
+static bool gicv3_enable_lpis(void)
+{
+uint32_t val;
+
+val = readl_relaxed(GICD_RDIST_BASE + GICR_TYPER);
+if ( !(val & GICR_TYPER_PLPIS) )
+return false;
+
+val = readl_relaxed(GICD_RDIST_BASE + GICR_CTLR);
+writel_relaxed(val | GICR_CTLR_ENABLE_LPIS, GICD_RDIST_BASE + GICR_CTLR);
+
+return true;
+}
+
 static int __init gicv3_populate_rdist(void)
 {
 int i;
@@ -755,6 +770,10 @@ static int gicv3_cpu_init(void)
 if ( gicv3_enable_redist() )
 return -ENODEV;
 
+/* If the host has any ITSes, enable LPIs now. */
+if ( !list_empty(_its_list) )
+gicv3_enable_lpis();
+
 /* Set priority on PPI and SGI interrupts */
 priority = (GIC_PRI_IPI << 24 | GIC_PRI_IPI << 16 | GIC_PRI_IPI << 8 |
 GIC_PRI_IPI);
-- 
2.9.0


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

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

[Andre Przywara]

Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
an EventID (the MSI payload or interrupt ID) to a pair of LPI number
and collection ID, which points to the target CPU.
This mapping is stored in the device and collection tables, which software
has to provide for the ITS to use.
Allocate the required memory and hand it the ITS.
The maximum number of devices is limited to a compile-time constant
exposed in Kconfig.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/Kconfig  |   6 +++
 xen/arch/arm/gic-its.c| 114 ++
 xen/arch/arm/gic-v3.c |   5 ++
 xen/include/asm-arm/bitops.h  |   1 +
 xen/include/asm-arm/gic-its.h |  51 ++-
 5 files changed, 176 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a7d941c..a369305 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -59,6 +59,12 @@ config MAX_HOST_LPI_BITS
   This can be overriden on the command line with the max_lpi_bits
   parameter.
 
+config MAX_ITS_PCI_BUSSES
+depends on HAS_ITS
+int "Number of PCI busses the ITS supports (4)"
+range 1 1024
+default "4"
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index 6c3a35d..f1540b2 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,6 +38,119 @@ static DEFINE_PER_CPU(void *, pending_table);
 
 #define MAX_PHYS_LPIS   (BIT_ULL(lpi_data.host_lpi_bits) - 8192)
 
+#define BASER_ATTR_MASK   \
+((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
+ (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
+ (0x7UL << GITS_BASER_INNER_CACHEABILITY_SHIFT))
+#define BASER_RO_MASK   (GENMASK(58, 56) | GENMASK(52, 48))
+
+static uint64_t encode_phys_addr(paddr_t addr, int page_bits)
+{
+uint64_t ret;
+
+if ( page_bits < 16)
+return (uint64_t)addr & GENMASK(47, page_bits);
+
+ret = addr & GENMASK(47, 16);
+return ret | (addr & GENMASK(51, 48)) >> (48 - 12);
+}
+
+static int its_map_baser(void __iomem *basereg, uint64_t regc, int nr_items)
+{
+uint64_t attr;
+int entry_size = ((regc >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0x1f) + 1;
+int pagesz;
+int order;
+void *buffer = NULL;
+
+attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+attr |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+
+/*
+ * Loop over the page sizes (4K, 16K, 64K) to find out what the host
+ * supports.
+ */
+for ( pagesz = 0; pagesz < 3; pagesz++ )
+{
+uint64_t reg;
+int nr_bytes;
+
+nr_bytes = ROUNDUP(nr_items * entry_size, BIT(pagesz * 2 + 12));
+order = get_order_from_bytes(nr_bytes);
+
+if ( !buffer )
+buffer = alloc_xenheap_pages(order, 0);
+if ( !buffer )
+return -ENOMEM;
+
+reg  = attr;
+reg |= (pagesz << GITS_BASER_PAGE_SIZE_SHIFT);
+reg |= nr_bytes >> (pagesz * 2 + 12);
+reg |= regc & BASER_RO_MASK;
+reg |= GITS_BASER_VALID;
+reg |= encode_phys_addr(virt_to_maddr(buffer), pagesz * 2 + 12);
+
+writeq_relaxed(reg, basereg);
+regc = readl_relaxed(basereg);
+
+/* The host didn't like our attributes, just use what it returned. */
+if ( (regc & BASER_ATTR_MASK) != attr )
+attr = regc & BASER_ATTR_MASK;
+
+/* If the host accepted our page size, we are done. */
+if ( (reg & (3UL << GITS_BASER_PAGE_SIZE_SHIFT)) == pagesz )
+return 0;
+
+/* Check whether our buffer is aligned to the next page size already. 
*/
+if ( !(virt_to_maddr(buffer) & (BIT(pagesz * 2 + 12 + 2) - 1)) )
+{
+free_xenheap_pages(buffer, order);
+buffer = NULL;
+}
+}
+
+if ( buffer )
+free_xenheap_pages(buffer, order);
+
+return -EINVAL;
+}
+
+int gicv3_its_init(struct host_its *hw_its)
+{
+uint64_t reg;
+int i;
+
+hw_its->its_base = ioremap_nocache(hw_its->addr, hw_its->size);
+if ( !hw_its->its_base )
+return -ENOMEM;
+
+for ( i = 0; i < GITS_BASER_NR_REGS; i++ )
+{
+void __iomem *basereg = hw_its->its_base + GITS_BASER0 + i * 8;
+int type;
+
+reg = readq_relaxed(basereg);
+type = (reg & GITS_BASER_TYPE_MASK) >> GITS_BASER_TYPE_SHIFT;
+switch ( type )
+{
+case GITS_BASER_TYPE_NONE:
+continue;
+case GITS_BASER_TYPE_DEVICE:
+/* TODO: find some better way of limiting the number of devices */
+its_map_baser(basereg, reg, 

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

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic.c   |  3 +++
 xen/arch/arm/vgic-v3.c   | 11 
 xen/arch/arm/vgic.c  | 64 +---
 xen/include/asm-arm/domain.h |  2 ++
 xen/include/asm-arm/vgic.h   | 10 +++
 5 files changed, 87 insertions(+), 3 deletions(-)

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

[Xen-devel] [RFC PATCH v2 05/26] ARM: GICv3 ITS: introduce ITS command handling

[Andre Przywara]

To be able to easily send commands to the ITS, create the respective
wrapper functions, which take care of the ring buffer.
The first two commands we implement provide methods to map a collection
to a redistributor (aka host core) and to flush the command queue (SYNC).
Start using these commands for mapping one collection to each host CPU.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-its.c| 100 ++
 xen/arch/arm/gic-v3.c |  15 +++
 xen/include/asm-arm/gic-its.h |  33 ++
 3 files changed, 148 insertions(+)

diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
index 2fb3bcb..d0f5fd1 100644
--- a/xen/arch/arm/gic-its.c
+++ b/xen/arch/arm/gic-its.c
@@ -34,6 +34,10 @@ static struct {
 unsigned int host_lpi_bits;
 } lpi_data;
 
+/* Physical redistributor address */
+static DEFINE_PER_CPU(uint64_t, rdist_addr);
+/* Redistributor ID */
+static DEFINE_PER_CPU(uint64_t, rdist_id);
 /* Pending table for each redistributor */
 static DEFINE_PER_CPU(void *, pending_table);
 
@@ -41,6 +45,85 @@ static DEFINE_PER_CPU(void *, pending_table);
 
 #define ITS_CMD_QUEUE_SZSZ_64K
 
+static int its_send_command(struct host_its *hw_its, void *its_cmd)
+{
+uint64_t readp, writep;
+
+spin_lock(_its->cmd_lock);
+
+readp = readq_relaxed(hw_its->its_base + GITS_CREADR) & GENMASK(19, 5);
+writep = readq_relaxed(hw_its->its_base + GITS_CWRITER) & GENMASK(19, 5);
+
+if ( ((writep + ITS_CMD_SIZE) % ITS_CMD_QUEUE_SZ) == readp )
+{
+spin_unlock(_its->cmd_lock);
+return -EBUSY;
+}
+
+memcpy(hw_its->cmd_buf + writep, its_cmd, ITS_CMD_SIZE);
+__flush_dcache_area(hw_its->cmd_buf + writep, ITS_CMD_SIZE);
+writep = (writep + ITS_CMD_SIZE) % ITS_CMD_QUEUE_SZ;
+
+writeq_relaxed(writep & GENMASK(19, 5), hw_its->its_base + GITS_CWRITER);
+
+spin_unlock(_its->cmd_lock);
+
+return 0;
+}
+
+static uint64_t encode_rdbase(struct host_its *hw_its, int cpu, uint64_t reg)
+{
+reg &= ~GENMASK(51, 16);
+
+if ( hw_its->pta )
+reg |= per_cpu(rdist_addr, cpu) & GENMASK(51, 16);
+else
+reg |= per_cpu(rdist_id, cpu) << 16;
+
+return reg;
+}
+
+static int its_send_cmd_sync(struct host_its *its, int cpu)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_SYNC;
+cmd[1] = 0x00;
+cmd[2] = encode_rdbase(its, cpu, 0x0);
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
+static int its_send_cmd_mapc(struct host_its *its, int collection_id, int cpu)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_MAPC;
+cmd[1] = 0x00;
+cmd[2] = encode_rdbase(its, cpu, (collection_id & GENMASK(15, 0)));
+cmd[2] |= BIT_ULL(63);
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
+/* Set up the (1:1) collection mapping for the given host CPU. */
+void gicv3_its_setup_collection(int cpu)
+{
+struct host_its *its;
+
+list_for_each_entry(its, _its_list, entry)
+{
+/* Only send commands to ITS that have been initialized already. */
+if ( !its->cmd_buf )
+continue;
+
+its_send_cmd_mapc(its, cpu, cpu);
+its_send_cmd_sync(its, cpu);
+}
+}
+
 #define BASER_ATTR_MASK   \
 ((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
  (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
@@ -148,6 +231,13 @@ int gicv3_its_init(struct host_its *hw_its)
 if ( !hw_its->its_base )
 return -ENOMEM;
 
+/* Make sure the ITS is disabled before programming the BASE registers. */
+reg = readl_relaxed(hw_its->its_base + GITS_CTLR);
+writel_relaxed(reg & ~GITS_CTLR_ENABLE, hw_its->its_base + GITS_CTLR);
+
+reg = readq_relaxed(hw_its->its_base + GITS_TYPER);
+hw_its->pta = !!(reg & GITS_TYPER_PTA);
+
 for ( i = 0; i < GITS_BASER_NR_REGS; i++ )
 {
 void __iomem *basereg = hw_its->its_base + GITS_BASER0 + i * 8;
@@ -175,9 +265,18 @@ int gicv3_its_init(struct host_its *hw_its)
 if ( !hw_its->cmd_buf )
 return -ENOMEM;
 
+its_send_cmd_mapc(hw_its, smp_processor_id(), smp_processor_id());
+its_send_cmd_sync(hw_its, smp_processor_id());
+
 return 0;
 }
 
+void gicv3_set_redist_addr(paddr_t address, int redist_id)
+{
+this_cpu(rdist_addr) = address;
+this_cpu(rdist_id) = redist_id;
+}
+
 uint64_t gicv3_lpi_allocate_pendtable(void)
 {
 uint64_t reg, attr;
@@ -286,6 +385,7 @@ void gicv3_its_dt_init(const struct dt_device_node *node)
 its_data->addr = addr;
 its_data->size = size;
 its_data->dt_node = its;
+spin_lock_init(_data->cmd_lock);
 
 printk("GICv3: Found ITS @0x%lx\n", addr);
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 8ca7da2..d2461cb 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -643,6 +643,8 @@ static int gicv3_rdist_init_lpis(void 

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

[Boris Ostrovsky]

On 12/22/2016 11:44 AM, Roger Pau Monne wrote:
> On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
> On 22.12.16 at 17:17,  wrote:
>>> On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
 Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
>>> Why would Xen need to be able to parse the AML that is intended to be
>>> executed by dom0? I'd think that all the hypervisor would need to do is
>>> to load it into memory, not any different from how it's done for regular
>>> guests.
>> Well, if Dom0 executed the unmodified _MAT, it would get back
>> data relating to the physical CPU. Roger is overriding MADT to
>> present virtual CPU information to Dom0, and this would likewise
>> need to happen for the _MAT return value.

By "unmodified _MAT" you mean system's _MAT?  Why can't we provide our
own that will return _MAT object properly adjusted for dom0? We are
going to provide our own (i.e. not system's) DSDT, aren't we?

> This is one of the problems with this Dom/Xen0 split brain problem that we
> have, and cannot get away from.
>
> To clarify a little bit, I'm not overwriting the original MADT in memory, so
> Dom0 should still be able to access it if the implementation of _MAT returns
> data from that area. AFAICT when plugging in a physical CPU (pCPU) into the
> hardware, Dom0 should see "correct" data returned by the _MAT method. However
> (as represented by the " I've used), this data will not match Dom0 vCPU
> topology, and should not be used by Dom0 (only reported to Xen in order to
> bring up the new pCPU).

So the problem seems to be that we need to run both _MATs --- system's
and dom0's.


> Then the problem arises because we have no way to perform vCPU hotplug for
> Dom0, not at least as it is done for DomU (using ACPI), so we would have to 
> use
> an out-of-band method in order to do vCPU hotplug for Dom0, which is a PITA.


I would very much like to avoid this.

-boris



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

Re: [Xen-devel] [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH] tools/tests/x86_emulate: #define unlikely in 
x86 emulator test harness"):
> On 22.12.16 at 16:10,  wrote:
> > I did not find this important build fix for a regression in 4.8.0
> > because:
> 
> I wonder why you consider this important - the harness doesn't
> get built by default, and is of little use for other than smoke
> testing a limited set of changes to the insn emulator.

I think this must be being enabled by something in the Debian package
build.

> > Backporting this is made more awkward by the decision to make the fix
> > a portmanteau.  Do the x86 maintainers intend to provide a
> > ready-to-use backport or shall I try to prepare one ?
> 
> I've pushed one a minute ago to 4.8-staging.

Ah, great, thanks.

> > For now, is there any reason why I should not use my change
> >+#define unlikely(x) (x)
> > in an upload to Debian ?
> 
> I don't see anything speaking against that.

OK, thanks.  I think now there's a fix in 4.8-staging I will cherry
pick that instead.

Ian.

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

Re: [Xen-devel] [PATCH 2/2] x86emul: correct 64-bit mode repeated string insn handling with zero count

[Andrew Cooper]

On 07/12/16 10:22, Jan Beulich wrote:

On 06.12.16 at 17:35,  wrote:

On 06/12/16 13:39, Jan Beulich wrote:

@@ -5424,7 +5436,6 @@ x86_emulate(
  goto cannot_emulate;
  }
  
- writeback:

This removal highlights that the writeback and no_writeback lables are
incorrectly named.

There intended meaning is {no,}dest_writeback, but no_writeback still
performs a full commit of the shadow GPR state, which is what people
logically associate with the term "writeback" in this context.

I think we should have a followup patch renaming the no_writeback label
to to gpr_writeback.

I've done this, but for some of the uses of the label the new name
doesn't appear to be much better than the old one ...


Just had an idea.  How about "complete_insn" ?

~Andrew

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

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

[Roger Pau Monne]

On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
> >>> On 22.12.16 at 17:17,  wrote:
> > On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> >> Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
> > 
> > Why would Xen need to be able to parse the AML that is intended to be
> > executed by dom0? I'd think that all the hypervisor would need to do is
> > to load it into memory, not any different from how it's done for regular
> > guests.
> 
> Well, if Dom0 executed the unmodified _MAT, it would get back
> data relating to the physical CPU. Roger is overriding MADT to
> present virtual CPU information to Dom0, and this would likewise
> need to happen for the _MAT return value.

This is one of the problems with this Dom/Xen0 split brain problem that we
have, and cannot get away from.

To clarify a little bit, I'm not overwriting the original MADT in memory, so
Dom0 should still be able to access it if the implementation of _MAT returns
data from that area. AFAICT when plugging in a physical CPU (pCPU) into the
hardware, Dom0 should see "correct" data returned by the _MAT method. However
(as represented by the " I've used), this data will not match Dom0 vCPU
topology, and should not be used by Dom0 (only reported to Xen in order to
bring up the new pCPU).

Then the problem arises because we have no way to perform vCPU hotplug for
Dom0, not at least as it is done for DomU (using ACPI), so we would have to use
an out-of-band method in order to do vCPU hotplug for Dom0, which is a PITA.

Roger.

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

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

[osstest service owner]

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

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  3ab1876504d409689824e161a8b04e57e1e5dd46
baseline version:
 xen  1226317351b4154ed6460b778f2490614f47b9d4

Last test of basis   103806  2016-12-22 13:02:09 Z0 days
Testing same since   103808  2016-12-22 15:01:57 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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=3ab1876504d409689824e161a8b04e57e1e5dd46
+ . ./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 
3ab1876504d409689824e161a8b04e57e1e5dd46
+ branch=xen-unstable-smoke
+ revision=3ab1876504d409689824e161a8b04e57e1e5dd46
+ . ./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
+ '[' x3ab1876504d409689824e161a8b04e57e1e5dd46 = 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
++ : 

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

[Jan Beulich]

>>> On 22.12.16 at 17:17,  wrote:
> On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
>> Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
> 
> Why would Xen need to be able to parse the AML that is intended to be
> executed by dom0? I'd think that all the hypervisor would need to do is
> to load it into memory, not any different from how it's done for regular
> guests.

Well, if Dom0 executed the unmodified _MAT, it would get back
data relating to the physical CPU. Roger is overriding MADT to
present virtual CPU information to Dom0, and this would likewise
need to happen for the _MAT return value.

Jan


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

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

[Boris Ostrovsky]

On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> On Thu, Dec 22, 2016 at 04:03:12AM -0700, Jan Beulich wrote:
> On 22.12.16 at 11:43,  wrote:
>>> On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
> Since Xen is the one that sets the local APIC address in the MADT, and it
> always matches the position of the emulated local APIC I don't see why we 
> would
> want to use acpi_madt_local_apic_override. I see that your worries are 
> related
> to what would happen if AML tries to modify the MADT, but wouldn't in 
> that case
> modify the native MADT, instead of the crafted one?
 Exactly, so how would you see the modification to get
 propagated?
>>> Please bear with me, by modifications here do you mean what the _MAT method
>>> returns from processor objects?
>>>
>>> The ACPI 6.1 spec has something that worries me quite a lot (page 145):
>>>
>>> "
>>> a) When _MAT (see Section 6.2.10) appears under a Processor Device object 
>>> (see
>>> Section 8.4), OSPM processes the Interrupt Controller Structures returned by
>>> _MAT with the types labeled "yes" and ignores other types.
>>>
>>> b) When _MAT appears under an I/O APIC Device (see Section 9.17), OSPM
>>> processes the Interrupt Controller Structures returned by _MAT with the 
>>> types
>>> labeled "yes" and ignores other types.
>>> "
>>>
>>> Which from my understanding means that almost everything from the original 
>>> MADT
>>> can be overwritten by the returns of _MAT methods. The same seems to be true
>>> for ARM, and I don't see them dealing with this in any way. Is this 
>>> something
>>> that has yet to be implemented by any vendor?
>> I don't understand. For one, I can't see the spec requiring or excluding
>> the in place modification of MADT entries for the purpose of implementing
>> _MAT. Which route is taken is imo an implementation choice. In hvmloader
>> we use the in place modification approach at present. And then looking
>> at the original MADT is a boot time thing, so subsequent modifications
>> should be of no interest to the OS (they'd get those as _MAT return
>> values, not by looking at the static table).
>>
>> The thing that I'm worried about is a physical machine's firmware using
>> the same approach as we do in hvmloader, thus returning from _MAT
>> values which are out of sync with the MADT we present to Dom0.
>> Although - thinking about it a second time now, we'd have the same
>> inconsistency issue if the firmware constructed the _MAT return
>> values from scratch, so this will need dealing with in any case for
>> CPU hotplug to work.
> I don't see an obvious solution to this, those _MAT methods reside in AML, and
> ATM Xen has no way to parse, much even less modify this code. Xen could add 
> the
> Processor device path to the STAO so that Dom0 ignores them, but that would
> also prevent ACPI CPU hotplug from working in Dom0.
>
> Maybe Boris has some ideas about how to do CPU hotplug for Dom0?


Why would Xen need to be able to parse the AML that is intended to be
executed by dom0? I'd think that all the hypervisor would need to do is
to load it into memory, not any different from how it's done for regular
guests.

-boris


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

Re: [Xen-devel] [PATCH v4 03/24] x86: refactor psr: implement main data structures.

[Jan Beulich]

>>> On 14.12.16 at 05:07,  wrote:
> To construct an extendible framework, we need analyze PSR features
> and abstract the common things and feature specific things. Then,
> encapsulate them into different data structures.
> 
> By analyzing PSR features, we can get below map.
> +--+--+--+
>   ->| Dom0 | Dom1 | ...  |
>   | +--+--+--+
>   ||
>   |Dom ID  | cos_id of domain
>   |V
>   |
> +-+
> User ->| PSR  
>  
>   |
>  Socket ID |  +--+---+---+
>|
>|  | Socket0 Info | Socket 1 Info |...|
>|
>|  +--+---+---+
>|
>||   cos_id=0   cos_id=1   
>... |
>||  
> +---+---+---+ |
>||->Ref   : | ref 0 | ref 1
>  | ...   | |
>||  
> +---+---+---+ |
>||  
> +---+---+---+ |
>||->L3 CAT: | cos 0 | cos 1
>  | ...   | |
>||  
> +---+---+---+ |
>||  
> +---+---+---+ |
>||->L2 CAT: | cos 0 | cos 1
>  | ...   | |
>||  
> +---+---+---+ |
>||  
> +---+---+---+---+---+ |
>||->CDP   : | cos0 code | cos0 data | cos1 code | cos1 
> data | ...   | |
>|   
> +---+---+---+---+---+ |
>
> +-+
> 
> So, we need define a socket info data structure, 'struct
> psr_socket_info' to manage information per socket. It contains a
> reference count array according to COS ID and a feature list to
> manage all features enabled. Every entry of the reference count
> array is used to record how many domains are using the COS registers
> according to the COS ID. For example, L3 CAT and L2 CAT are enabled,
> Dom1 uses COS_ID=1 registers of both features to save CBM values, like
> below.
> +---+---+---+-+
> | COS 0 | COS 1 | COS 2 | ... |
> +---+---+---+-+
> L3 CAT  | 0x7ff | 0x1ff | ...   | ... |
> +---+---+---+-+
> L2 CAT  | 0xff  | 0xff  | ...   | ... |
> +---+---+---+-+
> 
> If Dom2 has same CBM values, it can reuse these registers which COS_ID=1.
> That means, both Dom1 and Dom2 use same COS registers(ID=1) to save same
> L3/L2 values. So, the value ref[1] is 2 which means 2 domains are using
> COS_ID 1.
> 
> To manage a feature, we need define a feature node data structure,
> 'struct feat_node', to manage feature's specific HW info, its callback
> functions (all feature's specific behaviors are encapsulated into these
> callback functions), and an array of all COS registers values of this
> feature. CDP is a special feature which uses two entries of the array
> for one COS ID. So, the number of CDP COS registers is the half of L3
> CAT. E.g. L3 CAT has 16 COS registers, then CDP has 8 COS registers if
> it is enabled.

The special nature of CDP will make some special handling necessary,
which may need reflection in data structure arrangement. Would you
mind spelling out here how CDP handling is intended to work?

> +/*
> + * Per SDM 17.17.3.3 'Cache Allocation Technology: Cache Mask Configuration',

I think I've asked before to omit section numbers, which tend to
change. Just the title will be enough.

> +struct feat_node;
> +
> +/*
> + * This structure defines feature operation callback functions. Every feature
> + * enabled MUST implement such callback functions and register them to ops.
> + *
> + * Feature specific behaviors will be encapsulated into these callback
> + * functions. Then, the main flows will not be changed when introducing a new
> + * feature.
> + */
> +struct feat_ops {
> +/*
> + * init_feature is used in cpu initialization process to do feature
> + * specific initialization works.
> + */
> +void (*init_feature)(unsigned int eax, unsigned int ebx,
> + unsigned int ecx, 

Re: [Xen-devel] [PATCH 08/10] x86/vm-event: use unambiguous register names

[Razvan Cojocaru]

On 12/20/2016 12:42 PM, Jan Beulich wrote:
> This is in preparation of eliminating the mis-naming of 64-bit fields
> with 32-bit register names (eflags instead of rflags etc).
> 
> Signed-off-by: Jan Beulich 

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v4 02/24] x86: refactor psr: remove L3 CAT/CDP codes.

[Jan Beulich]

>>> On 14.12.16 at 05:07,  wrote:
> The current cache allocation codes in psr.c do not consider
> future features addition and are not friendly to extend.
> 
> To make psr.c be more flexible to add new features and fulfill
> the program principle, open for extension but closed for
> modification, we have to refactor the psr.c:
> 1. Analyze cache allocation features and abstract general data
>structures.
> 2. Analyze the init and all other functions flow, abstract all
>steps that different features may have different implementations.
>Make these steps be callback functions and register feature
>specific fuctions. Then, the main processes will not be changed
>when introducing a new feature.
> 
> Because the quantity of refactor codes is big and the logics are
> changed a lot, it will cause reviewers confused if just change
> old codes. Reviewers have to understand both old codes and new
> implementations. After review iterations from V1 to V3, Jan has
> proposed to remove all old cache allocation codes firstly, then
> implement new codes step by step. This will help to make codes
> be more easily reviewable.
> 
> There is no construction without destruction. So, this patch
> removes all current L3 CAT/CDP codes in psr.c. The following
> patches will introduce the new mechanism.
> 
> Signed-off-by: Yi Sun 

Acked-by: Jan Beulich 
with one question:

> @@ -738,14 +282,10 @@ static int __init psr_presmp_init(void)
>  if ( (opt_psr & PSR_CMT) && opt_rmid_max )
>  init_psr_cmt(opt_rmid_max);
>  
> -if ( opt_psr & PSR_CAT )
> -init_psr_cat();
> -
> -if ( psr_cpu_prepare(0) )
> -psr_cat_free();
> +psr_cpu_prepare(0);
>  
>  psr_cpu_init();
> -if ( psr_cmt_enabled() || cat_socket_info )
> +if ( psr_cmt_enabled() )
>  register_cpu_notifier(_nfb);

You retain this notifier - do you expect to need it going forward?
Till now it was used to allocate that strange temporary object,
which iirc we've discussed (during the earlier versions) would go
away.

Jan


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

Re: [Xen-devel] [PATCH 2/3] xen: return xenstore command failures via response instead of rc

[Boris Ostrovsky]

On 12/22/2016 10:55 AM, Juergen Gross wrote:
> On 22/12/16 16:49, Boris Ostrovsky wrote:
>> On 12/22/2016 02:19 AM, Juergen Gross wrote:
>>> When the xenbus driver does some special handling for a Xenstore
>>> command any error condition related to the command should be returned
>>> via an error response instead of letting the related write operation
>>> fail. Otherwise the user land handler might take wrong decisions
>>> assuming the connection to Xenstore is broken.
>> Do we expect the user to always read the reply if no error code was
>> returned?
> Absolutely, yes. This is how error reporting of Xenstore is
> working.

Oh, right --- I was thinking about the string that you are passing back
but not the message type (XS_ERROR).

Reviewed-by: Boris Ostrovsky 

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

Re: [Xen-devel] [PATCH 2/3] xen: return xenstore command failures via response instead of rc

[Juergen Gross]

On 22/12/16 16:49, Boris Ostrovsky wrote:
> On 12/22/2016 02:19 AM, Juergen Gross wrote:
>> When the xenbus driver does some special handling for a Xenstore
>> command any error condition related to the command should be returned
>> via an error response instead of letting the related write operation
>> fail. Otherwise the user land handler might take wrong decisions
>> assuming the connection to Xenstore is broken.
> 
> Do we expect the user to always read the reply if no error code was
> returned?

Absolutely, yes. This is how error reporting of Xenstore is
working.


Juergen

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

Re: [Xen-devel] [PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

[Juergen Gross]

On 22/12/16 16:38, Boris Ostrovsky wrote:
> On 12/22/2016 02:19 AM, Juergen Gross wrote:
>> When accessing Xenstore in a transaction the user is specifying a
>> transaction id which he normally obtained from Xenstore when starting
>> the transaction. Xenstore is validating a transaction id against all
>> known transaction ids of the connection the request came in. As all
>> requests of a domain not being the one where Xenstore lives share
>> one connection, validation of transaction ids of different users of
>> Xenstore in that domain should be done by the kernel of that domain
>> being the multiplexer between the Xenstore users in that domain and
>> Xenstore.
>>
>> In order to prohibit one Xenstore user to be able to "hijack" a
>> transaction from another user the xenbus driver has to verify a
>> given transaction id against all known transaction ids of the user
>> before forwarding it to Xenstore.
>>
>> Signed-off-by: Juergen Gross 
> 
> 
> Should this go to stable trees as well?

I don't think it is necessary. First I thought this could be a security
problem, but any user who could make use of that problem could easily
trash complete Xenstore, so there are no additional security concerns
with this "bug" not being handled.

After all it is just a matter of avoiding problems due to buggy Xenstore
users which are probably not existing at all. :-)

> Reviewed-by: Boris Ostrovsky 

Thanks,

Juergen


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

Re: [Xen-devel] [PATCH 3/3] xen: remove stale xs_input_avail() from header

[Boris Ostrovsky]

On 12/22/2016 02:19 AM, Juergen Gross wrote:
> In drivers/xen/xenbus/xenbus_comms.h there is a stale declaration of
> xs_input_avail(). Remove it.
>
> Signed-off-by: Juergen Gross 
>


Reviewed-by: Boris Ostrovsky 

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

Re: [Xen-devel] [PATCH 2/3] xen: return xenstore command failures via response instead of rc

[Boris Ostrovsky]

On 12/22/2016 02:19 AM, Juergen Gross wrote:
> When the xenbus driver does some special handling for a Xenstore
> command any error condition related to the command should be returned
> via an error response instead of letting the related write operation
> fail. Otherwise the user land handler might take wrong decisions
> assuming the connection to Xenstore is broken.

Do we expect the user to always read the reply if no error code was
returned?

-boris

>
> While at it try to return the same error values xenstored would
> return for those cases.
>
> Signed-off-by: Juergen Gross 
> ---
>  drivers/xen/xenbus/xenbus_dev_frontend.c | 47 
> ++--
>  1 file changed, 27 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
> b/drivers/xen/xenbus/xenbus_dev_frontend.c
> index a068281..79130b3 100644
> --- a/drivers/xen/xenbus/xenbus_dev_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
> @@ -302,6 +302,29 @@ static void watch_fired(struct xenbus_watch *watch,
>   mutex_unlock(>dev_data->reply_mutex);
>  }
>  
> +static int xenbus_command_reply(struct xenbus_file_priv *u,
> + unsigned int msg_type, const char *reply)
> +{
> + struct {
> + struct xsd_sockmsg hdr;
> + const char body[16];
> + } msg;
> + int rc;
> +
> + msg.hdr = u->u.msg;
> + msg.hdr.type = msg_type;
> + msg.hdr.len = strlen(reply) + 1;
> + if (msg.hdr.len > sizeof(msg.body))
> + return -E2BIG;
> +
> + mutex_lock(>reply_mutex);
> + rc = queue_reply(>read_buffers, , sizeof(msg.hdr) + msg.hdr.len);
> + wake_up(>read_waitq);
> + mutex_unlock(>reply_mutex);
> +
> + return rc;
> +}
> +
>  static int xenbus_write_transaction(unsigned msg_type,
>   struct xenbus_file_priv *u)
>  {
> @@ -321,7 +344,7 @@ static int xenbus_write_transaction(unsigned msg_type,
>   if (trans->handle.id == u->u.msg.tx_id)
>   break;
>   if (>list == >transactions)
> - return -ESRCH;
> + return xenbus_command_reply(u, XS_ERROR, "ENOENT");
>   }
>  
>   reply = xenbus_dev_request_and_reply(>u.msg);
> @@ -372,12 +395,12 @@ static int xenbus_write_watch(unsigned msg_type, struct 
> xenbus_file_priv *u)
>   path = u->u.buffer + sizeof(u->u.msg);
>   token = memchr(path, 0, u->u.msg.len);
>   if (token == NULL) {
> - rc = -EILSEQ;
> + rc = xenbus_command_reply(u, XS_ERROR, "EINVAL");
>   goto out;
>   }
>   token++;
>   if (memchr(token, 0, u->u.msg.len - (token - path)) == NULL) {
> - rc = -EILSEQ;
> + rc = xenbus_command_reply(u, XS_ERROR, "EINVAL");
>   goto out;
>   }
>  
> @@ -411,23 +434,7 @@ static int xenbus_write_watch(unsigned msg_type, struct 
> xenbus_file_priv *u)
>   }
>  
>   /* Success.  Synthesize a reply to say all is OK. */
> - {
> - struct {
> - struct xsd_sockmsg hdr;
> - char body[3];
> - } __packed reply = {
> - {
> - .type = msg_type,
> - .len = sizeof(reply.body)
> - },
> - "OK"
> - };
> -
> - mutex_lock(>reply_mutex);
> - rc = queue_reply(>read_buffers, , sizeof(reply));
> - wake_up(>read_waitq);
> - mutex_unlock(>reply_mutex);
> - }
> + rc = xenbus_command_reply(u, msg_type, "OK");
>  
>  out:
>   return rc;


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

Re: [Xen-devel] [PATCH v2 5/5] tools/blktap2/drivers: Remove non-existent sys/sysctl.h include

[Doug Goldstein]

On 12/20/16 1:47 PM, Alistair Francis wrote:
> To avoid build errors related to missing file 'sys/sysctl.h' by removing
> the #include statement.
> 
> Signed-off-by: Alistair Francis 
> ---
>  tools/blktap2/drivers/block-remus.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/tools/blktap2/drivers/block-remus.c 
> b/tools/blktap2/drivers/block-remus.c
> index 079588d..7401800 100644
> --- a/tools/blktap2/drivers/block-remus.c
> +++ b/tools/blktap2/drivers/block-remus.c
> @@ -54,7 +54,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> 

A bit late to the party but I also confirmed the header was unused.

Reviewed-by: Doug Goldstein 

-- 
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 v2 5/5] tools/blktap2/drivers: Remove non-existent sys/sysctl.h include

[Alistair Francis]

On Thu, Dec 22, 2016 at 2:54 AM, Wei Liu  wrote:
> On Tue, Dec 20, 2016 at 11:47:00AM -0800, Alistair Francis wrote:
>> To avoid build errors related to missing file 'sys/sysctl.h' by removing
>> the #include statement.
>>
>> Signed-off-by: Alistair Francis 
>
> I can find this in Linux. Maybe this is also due to the libc you're
> using?

Yes, I think you are right. I am using musl when I see the error.

>
> On the flip side, if this header is unused anyway I think I'm fine with
> taking this patch.

Thanks, that is what I was thinking too.

Thanks,

Alistair

>
>> ---
>>  tools/blktap2/drivers/block-remus.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/tools/blktap2/drivers/block-remus.c 
>> b/tools/blktap2/drivers/block-remus.c
>> index 079588d..7401800 100644
>> --- a/tools/blktap2/drivers/block-remus.c
>> +++ b/tools/blktap2/drivers/block-remus.c
>> @@ -54,7 +54,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>
>> --
>> 2.7.4
>>

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

Re: [Xen-devel] [PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

[Boris Ostrovsky]

On 12/22/2016 02:19 AM, Juergen Gross wrote:
> When accessing Xenstore in a transaction the user is specifying a
> transaction id which he normally obtained from Xenstore when starting
> the transaction. Xenstore is validating a transaction id against all
> known transaction ids of the connection the request came in. As all
> requests of a domain not being the one where Xenstore lives share
> one connection, validation of transaction ids of different users of
> Xenstore in that domain should be done by the kernel of that domain
> being the multiplexer between the Xenstore users in that domain and
> Xenstore.
>
> In order to prohibit one Xenstore user to be able to "hijack" a
> transaction from another user the xenbus driver has to verify a
> given transaction id against all known transaction ids of the user
> before forwarding it to Xenstore.
>
> Signed-off-by: Juergen Gross 


Should this go to stable trees as well?


Reviewed-by: Boris Ostrovsky 



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

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

[Jan Beulich]

>>> On 22.12.16 at 16:14,  wrote:
> On 22/12/16 14:58, Jan Beulich wrote:
> On 22.12.16 at 15:31,  wrote:
>> On 22.12.16 at 14:47,  wrote:
 On 22/12/16 08:37, Jan Beulich wrote:
> Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
> determine whether to install the hook in the first place.
>
> Signed-off-by: Jan Beulich 
 I am not so sure about this.

 vmfunc is reachable in the instruction emulator on hardware which
 doesn't support vmfunc, and there is explicit provision for using vmfunc
 0 via hypercall on hardware lacking vmfunc support.

 Given that the #VE part of altp2m is always emulated architecturally, I
 think there is an argument to be made for also emulating EPTP switching
 architecturally as well.
>>> I don't understand this argumentation: Without the patch, the
>>> hook function checks !cpu_has_vmx_vmfunc (and fails otherwise);
>>> with the patch the hook isn't being put in place when
>>> !cpu_has_vmx_vmfunc, and failure occurs in hvmemul_vmfunc().
>>> I admit there's the difference in error codes, but we could
>>> certainly make hvmemul_vmfunc() return EXCEPTION when
>>> there's no hook.
>> And btw., installing altp2m_vcpu_update_vmfunc_ve is as pointless
>> in the opposite case, do it bailing early when !cpu_has_vmx_vmfunc.
>> I guess I'll do both changes for a v2.
> 
> My argument is that, instead of excluding the hook, the behaviour of the 
> emulation path should be made to function sensibly even on hardware 
> without vmfunc.
> 
> i.e. drop the cpu_has_vmx_vmfunc check and do nothing else.

Ah, I see. I guess I'll leave that to someone having an environment
to test this. The patch's goal was to not change observable behavior.

Jan


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

Re: [Xen-devel] [PATCH] xsm: allow relevant permission during migrate and gpu-passthrough.

[Jan Beulich]

>>> On 22.12.16 at 16:28,  wrote:
> On 12/20/16 3:37 AM, Anshul Makkar wrote:
>> On 20/12/2016 04:03, Doug Goldstein wrote:
>>> On 12/19/16 10:02 AM, Doug Goldstein wrote:
 On 12/14/16 3:09 PM, Daniel De Graaf wrote:
> On 12/12/2016 09:00 AM, Anshul Makkar wrote:
>> During guest migrate allow permission to prevent
>> spurious page faults.
>> Prevents these errors:
>> d73: Non-privileged (73) attempt to map I/O space 
>>
>> avc: denied  { set_misc_info } for domid=0 target=11
>> scontext=system_u:system_r:dom0_t
>> tcontext=system_u:system_r:domU_t tclass=domain
>>
>> GPU passthrough for hvm guest:
>> avc:  denied  { send_irq } for domid=0 target=10
>> scontext=system_u:system_r:dom0_t
>> tcontext=system_u:system_r:domU_t tclass=hvm
>>
>> Signed-off-by: Anshul Makkar 
>
> Acked-by: Daniel De Graaf 
>

 Daniel,

 Should this be backported to 4.8?

>>>
>>> FWIW, Daniel's email is bouncing. Anshul, do you want to test/confirm?
>>>
>> 
>> Doug, yes, will backport and test.
>> 
>> Anshul
> 
> CCing Jan for the backport.

Well - I'll wait for the pending confirmation from Anshul (please
Cc me on that one). Or wait - this is under tools/, in which case
I'd rather leave this to Ian (so please Cc him when confirming).

Jan


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

Re: [Xen-devel] [PATCH] docs: Clarify scope of reboot= and noreboot Xen command line options

[Jan Beulich]

>>> On 22.12.16 at 16:02,  wrote:
> @@ -1356,7 +1357,9 @@ The following resources are available:
>  
>  > Default: `0`
>  
> -Specify the host reboot method.
> +Specify the host reboot method,
> +used when Xen crashes.
> +(This does not affect deliberate reboots initiated by dom0.)

This should be moved down to where `no` is being described, as
it affects only that sub-option. The reboot methods, otoh, affect
all kinds of reboots.

Jan


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

Re: [Xen-devel] [PATCH] xsm: allow relevant permission during migrate and gpu-passthrough.

[Doug Goldstein]

On 12/20/16 3:37 AM, Anshul Makkar wrote:
> On 20/12/2016 04:03, Doug Goldstein wrote:
>> On 12/19/16 10:02 AM, Doug Goldstein wrote:
>>> On 12/14/16 3:09 PM, Daniel De Graaf wrote:
 On 12/12/2016 09:00 AM, Anshul Makkar wrote:
> During guest migrate allow permission to prevent
> spurious page faults.
> Prevents these errors:
> d73: Non-privileged (73) attempt to map I/O space 
>
> avc: denied  { set_misc_info } for domid=0 target=11
> scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:domU_t tclass=domain
>
> GPU passthrough for hvm guest:
> avc:  denied  { send_irq } for domid=0 target=10
> scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:domU_t tclass=hvm
>
> Signed-off-by: Anshul Makkar 

 Acked-by: Daniel De Graaf 

>>>
>>> Daniel,
>>>
>>> Should this be backported to 4.8?
>>>
>>
>> FWIW, Daniel's email is bouncing. Anshul, do you want to test/confirm?
>>
> 
> Doug, yes, will backport and test.
> 
> Anshul

CCing Jan for the backport.

-- 
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] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness

[Jan Beulich]

>>> On 22.12.16 at 16:10,  wrote:
> I did not find this important build fix for a regression in 4.8.0
> because:

I wonder why you consider this important - the harness doesn't
get built by default, and is of little use for other than smoke
testing a limited set of changes to the insn emulator.

> Backporting this is made more awkward by the decision to make the fix
> a portmanteau.  Do the x86 maintainers intend to provide a
> ready-to-use backport or shall I try to prepare one ?

I've pushed one a minute ago to 4.8-staging.

> For now, is there any reason why I should not use my change
>+#define unlikely(x) (x)
> in an upload to Debian ?

I don't see anything speaking against that.

Jan


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

[Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

[Ronald Rojas]

Create a basic Makefile to build and install libxenlight Golang
bindings.  Also add a stub package.

---

Eventually this patch will contain the actual bindings package; for
now it just includes a stub package.

To Do:
- Have configure detect golang bindings properly

CC: xen-devel 
CC: Ian Jackson 
CC: Wei Liu 
CC: George Dunlap 
CC: George Dunlap 
---
 tools/Makefile| 16 
 tools/golang/Makefile | 29 +
 tools/golang/xenlight/xenlight.go |  7 +++
 3 files changed, 52 insertions(+)
 create mode 100644 tools/golang/Makefile
 create mode 100644 tools/golang/xenlight/xenlight.go

diff --git a/tools/Makefile b/tools/Makefile
index 71515b4..f2198e0 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -11,6 +11,8 @@ SUBDIRS-y += misc
 SUBDIRS-y += examples
 SUBDIRS-y += hotplug
 SUBDIRS-y += xentrace
+SUBDIRS-y += golang
+#FIXME: Have golang controlled by a configure variable
 SUBDIRS-$(CONFIG_XCUTILS) += xcutils
 SUBDIRS-$(CONFIG_X86) += firmware
 SUBDIRS-y += console
@@ -311,6 +313,20 @@ subdir-install-debugger/gdbsx: .phony
 subdir-all-debugger/gdbsx: .phony
$(MAKE) -C debugger/gdbsx all
 
+subdir-all-golang/xenlight: .phony
+   $(MAKE) -C golang all
+
+subdir-clean-golang/xenlight: .phony
+   $(MAKE) -C golang clean
+
+subdir-install-golang/xenlight: .phony
+   $(MAKE) -C golang install
+
+subdir-build-golang/xenlight: .phony
+   $(MAKE) -C golang build
+
+subdir-distclean-golang/xenlight: .phony
+   $(MAKE) -C golang distclean
 
 subdir-clean-debugger/kdd subdir-distclean-debugger/kdd: .phony
$(MAKE) -C debugger/kdd clean
diff --git a/tools/golang/Makefile b/tools/golang/Makefile
new file mode 100644
index 000..96589c8
--- /dev/null
+++ b/tools/golang/Makefile
@@ -0,0 +1,29 @@
+XEN_ROOT=$(CURDIR)/../..
+GOLANG_SRC=$(GOPATH)/src/xenproject.org/xenlight
+include $(XEN_ROOT)/tools/Rules.mk
+
+BINARY = xenlight.a
+GO ?= go
+
+.PHONY: all
+all: build
+
+.PHONY: build
+build: xenlight/xenlight.a
+
+.PHONY: install
+install: build
+   $(INSTALL_DIR) $(DESTDIR)$(GOLANG_SRC)
+   $(INSTALL_DATA) xenlight/xenlight.go $(DESTDIR)$(GOLANG_SRC)
+
+.PHONY: clean
+clean:
+   $(RM) xenlight/$(BINARY)
+
+.PHONY: distclean
+distclean: clean
+
+xenlight/xenlight.a: xenlight/xenlight.go
+   $(GO) build -o $@ $<
+
+-include $(DEPS)
diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
new file mode 100644
index 000..9136676
--- /dev/null
+++ b/tools/golang/xenlight/xenlight.go
@@ -0,0 +1,7 @@
+package xenlight
+
+import "fmt"
+
+func main() {
+   fmt.Println("go")
+}
-- 
2.7.4


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

Re: [Xen-devel] [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness

[Ian Jackson]

Andrew Cooper writes ("Re: [PATCH] tools/tests/x86_emulate: #define unlikely in 
x86 emulator test harness"):
> On 22/12/16 14:58, Ian Jackson wrote:
> > "x86emul: in_longmode() should not ignore ->read_msr() errors" aka
> > c/s 122dd9575c7a introduced a use of unlikely() in
> > xen/arch/x86/x86_emulate/x86_emulate.c.
> >
> > I think this is probably intentional and fine.  However, there is no
> > definition of unlikely in the x86 emulator test harness, under tools.
> >
> > The result is this error:
> >x86_emulate/x86_emulate.c: In function 'in_longmode':
> >x86_emulate/x86_emulate.c:1300:10: error: implicit declaration of 
> > function 'unlikely' [-Werror=implicit-function-declaration]
> >  unlikely(ops->read_msr(MSR_EFER, , ctxt) != X86EMUL_OKAY) 
> > )
> >  ^~~~
> >
> > Fix this by providing a boring definition of unlikely().
> >
> > Signed-off-by: Ian Jackson 
> 
> This was fixed by 3e84c8da7d2c5442a12789dae7163dca6c0e154f

I did not find this important build fix for a regression in 4.8.0
because:

 * this commit contains a mixture of the build fix and other changes
 * `git log -G unlikely' produced a lot of output: too much to read
   the whole message for each commit through looking for this fix
 * the commit message did not contain a copy of the error message
 * once I had dug into the code myself and found 122dd9575c7a it
   didn't occur to me to `git log --grep 122dd9'.

> Part of that should backported to 4.8, where it is still broken.

Backporting this is made more awkward by the decision to make the fix
a portmanteau.  Do the x86 maintainers intend to provide a
ready-to-use backport or shall I try to prepare one ?

For now, is there any reason why I should not use my change
   +#define unlikely(x) (x)
in an upload to Debian ?

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

[Andrew Cooper]

On 22/12/16 14:58, Jan Beulich wrote:

On 22.12.16 at 15:31,  wrote:

On 22.12.16 at 14:47,  wrote:

On 22/12/16 08:37, Jan Beulich wrote:

Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
determine whether to install the hook in the first place.

Signed-off-by: Jan Beulich 

I am not so sure about this.

vmfunc is reachable in the instruction emulator on hardware which
doesn't support vmfunc, and there is explicit provision for using vmfunc
0 via hypercall on hardware lacking vmfunc support.

Given that the #VE part of altp2m is always emulated architecturally, I
think there is an argument to be made for also emulating EPTP switching
architecturally as well.

I don't understand this argumentation: Without the patch, the
hook function checks !cpu_has_vmx_vmfunc (and fails otherwise);
with the patch the hook isn't being put in place when
!cpu_has_vmx_vmfunc, and failure occurs in hvmemul_vmfunc().
I admit there's the difference in error codes, but we could
certainly make hvmemul_vmfunc() return EXCEPTION when
there's no hook.

And btw., installing altp2m_vcpu_update_vmfunc_ve is as pointless
in the opposite case, do it bailing early when !cpu_has_vmx_vmfunc.
I guess I'll do both changes for a v2.


My argument is that, instead of excluding the hook, the behaviour of the 
emulation path should be made to function sensibly even on hardware 
without vmfunc.


i.e. drop the cpu_has_vmx_vmfunc check and do nothing else.

~Andrew



Jan




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

[Xen-devel] [PATCH] docs: Clarify scope of reboot= and noreboot Xen command line options

[Ian Jackson]

Signed-off-by: Ian Jackson 
CC: Jan Beulich 
---
 docs/misc/xen-command-line.markdown | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 0138978..68c81e6 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1260,6 +1260,7 @@ the **vga** option, which relies on real mode to set the 
video mode.
 Do not automatically reboot after an error.  This is useful for
 catching debug output.  Defaults to automatically reboot after 5
 seconds.
+This is equivalent to `reboot=no`
 
 ### nosmp
 > `= `
@@ -1356,7 +1357,9 @@ The following resources are available:
 
 > Default: `0`
 
-Specify the host reboot method.
+Specify the host reboot method,
+used when Xen crashes.
+(This does not affect deliberate reboots initiated by dom0.)
 
 `warm` instructs Xen to not set the cold reboot flag.
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness

[Andrew Cooper]

On 22/12/16 14:58, Ian Jackson wrote:

"x86emul: in_longmode() should not ignore ->read_msr() errors" aka
c/s 122dd9575c7a introduced a use of unlikely() in
xen/arch/x86/x86_emulate/x86_emulate.c.

I think this is probably intentional and fine.  However, there is no
definition of unlikely in the x86 emulator test harness, under tools.

The result is this error:
   x86_emulate/x86_emulate.c: In function 'in_longmode':
   x86_emulate/x86_emulate.c:1300:10: error: implicit declaration of function 
'unlikely' [-Werror=implicit-function-declaration]
 unlikely(ops->read_msr(MSR_EFER, , ctxt) != X86EMUL_OKAY) )
 ^~~~

Fix this by providing a boring definition of unlikely().

Signed-off-by: Ian Jackson 


This was fixed by 3e84c8da7d2c5442a12789dae7163dca6c0e154f

Part of that should backported to 4.8, where it is still broken.

~Andrew

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

[Xen-devel] [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness

[Ian Jackson]

"x86emul: in_longmode() should not ignore ->read_msr() errors" aka
c/s 122dd9575c7a introduced a use of unlikely() in
xen/arch/x86/x86_emulate/x86_emulate.c.

I think this is probably intentional and fine.  However, there is no
definition of unlikely in the x86 emulator test harness, under tools.

The result is this error:
  x86_emulate/x86_emulate.c: In function 'in_longmode':
  x86_emulate/x86_emulate.c:1300:10: error: implicit declaration of function 
'unlikely' [-Werror=implicit-function-declaration]
unlikely(ops->read_msr(MSR_EFER, , ctxt) != X86EMUL_OKAY) )
^~~~

Fix this by providing a boring definition of unlikely().

Signed-off-by: Ian Jackson 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 tools/tests/x86_emulator/x86_emulate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/tests/x86_emulator/x86_emulate.c 
b/tools/tests/x86_emulator/x86_emulate.c
index c46b7fc..e8f26fe 100644
--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -49,5 +49,6 @@ typedef bool bool_t;
 
 #define __init
 #define __maybe_unused __attribute__((__unused__))
+#define unlikely(x) (x)
 
 #include "x86_emulate/x86_emulate.c"
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

[Jan Beulich]

>>> On 22.12.16 at 15:31,  wrote:
 On 22.12.16 at 14:47,  wrote:
>> On 22/12/16 08:37, Jan Beulich wrote:
>>> Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
>>> determine whether to install the hook in the first place.
>>>
>>> Signed-off-by: Jan Beulich 
>> 
>> I am not so sure about this.
>> 
>> vmfunc is reachable in the instruction emulator on hardware which 
>> doesn't support vmfunc, and there is explicit provision for using vmfunc 
>> 0 via hypercall on hardware lacking vmfunc support.
>> 
>> Given that the #VE part of altp2m is always emulated architecturally, I 
>> think there is an argument to be made for also emulating EPTP switching 
>> architecturally as well.
> 
> I don't understand this argumentation: Without the patch, the
> hook function checks !cpu_has_vmx_vmfunc (and fails otherwise);
> with the patch the hook isn't being put in place when
> !cpu_has_vmx_vmfunc, and failure occurs in hvmemul_vmfunc().
> I admit there's the difference in error codes, but we could
> certainly make hvmemul_vmfunc() return EXCEPTION when
> there's no hook.

And btw., installing altp2m_vcpu_update_vmfunc_ve is as pointless
in the opposite case, do it bailing early when !cpu_has_vmx_vmfunc.
I guess I'll do both changes for a v2.

Jan


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

Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)

[Jan Beulich]

>>> On 22.12.16 at 14:47,  wrote:
> Jan Beulich writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 
> 103788: regressions - trouble: broken/fail/pass)"):
>> On 22.12.16 at 13:19,  wrote:
>> > Perhaps it would be worth telling Xen not to reboot on crash...
>> 
>> I think that's worth giving a try (I assume that some timeout will cause
>> the machine to get rebooted at some point anyway, to make it available
>> again).
> 
> Like this, then, AFAICT from the docs.

Yes.

>  FAOD, this shouldn't affect
> deliberate attempts by the dom0 to reboot the host ?

Correct. (I use "noreboot" or its more modern "reboot=no"
equivalent everywhere, and can confirm deliberate reboots
work fine.)

Jan


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

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

[Jan Beulich]

>>> On 07.12.16 at 16:57,  wrote:
>  efi/buildid.o: file not recognized: File format is ambiguous
>  efi/buildid.o: matching formats: coff-x86-64 pe-x86-64

Just fyi: After some analysis of the binutils sources I have come to
the conclusion that this needs help from the binutils folks. I've just
sent
https://sourceware.org/ml/binutils/2016-12/msg00374.html
to see if they have any advice.

Jan


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

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

[osstest service owner]

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

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  1226317351b4154ed6460b778f2490614f47b9d4
baseline version:
 xen  4a348565b1dcd3980168c176572cee925fcbe6d2

Last test of basis   103804  2016-12-22 10:01:45 Z0 days
Testing same since   103806  2016-12-22 13:02:09 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Eric DeVolder 
  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=1226317351b4154ed6460b778f2490614f47b9d4
+ . ./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 
1226317351b4154ed6460b778f2490614f47b9d4
+ branch=xen-unstable-smoke
+ revision=1226317351b4154ed6460b778f2490614f47b9d4
+ . ./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
+ '[' x1226317351b4154ed6460b778f2490614f47b9d4 = 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
++ : 

[Xen-devel] [distros-debian-wheezy test] 68259: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   68223

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



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

[Jan Beulich]

>>> On 22.12.16 at 14:47,  wrote:
> On 22/12/16 08:37, Jan Beulich wrote:
>> Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
>> determine whether to install the hook in the first place.
>>
>> Signed-off-by: Jan Beulich 
> 
> I am not so sure about this.
> 
> vmfunc is reachable in the instruction emulator on hardware which 
> doesn't support vmfunc, and there is explicit provision for using vmfunc 
> 0 via hypercall on hardware lacking vmfunc support.
> 
> Given that the #VE part of altp2m is always emulated architecturally, I 
> think there is an argument to be made for also emulating EPTP switching 
> architecturally as well.

I don't understand this argumentation: Without the patch, the
hook function checks !cpu_has_vmx_vmfunc (and fails otherwise);
with the patch the hook isn't being put in place when
!cpu_has_vmx_vmfunc, and failure occurs in hvmemul_vmfunc().
I admit there's the difference in error codes, but we could
certainly make hvmemul_vmfunc() return EXCEPTION when
there's no hook.

Jan


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

[Xen-devel] [xen-4.8-testing test] 103792: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-13 host-install(3)broken REGR. vs. 103767

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 103767
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103767
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 103767
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103767

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

version targeted for testing:
 xen  24ccfc33272be300b306873b75352c0de3deca94
baseline version:
 xen  b996efb23864f7135db3578a3a2059fe2f3c1a98

Last test of basis   103767  2016-12-20 04:56:08 Z2 days
Testing same since   103792  2016-12-21 17:10:20 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops 

Re: [Xen-devel] [PATCH v5 09/14] jump_label: port __jump_table to linker tables

[Andy Shevchenko]

On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote:
> Move the __jump_table from the a custom section solution
> to a generic solution, this avoiding extra vmlinux.lds.h
> customizations.
> 
> This also demos the use of the .data linker table and of
> the shared asm call push_section_tbl().
> 

>  {
>   asm_volatile_goto("1:\n\t"
>    WASM(nop) "\n\t"
> -  ".pushsection __jump_table,  \"aw\"\n\t"
> +  push_section_tbl_any(.data, __jump_table, aw)
>    ".word 1b, %l[l_yes], %c0\n\t"
>    ".popsection\n\t"
>    : :  "i" (&((char *)key)[branch]) :  : l_yes);
> @@ -26,7 +28,7 @@ static __always_inline bool
> arch_static_branch_jump(struct static_key *key, bool
>  {
>   asm_volatile_goto("1:\n\t"
>    WASM(b) " %l[l_yes]\n\t"
> -  ".pushsection __jump_table,  \"aw\"\n\t"
> +  push_section_tbl_any(.data, __jump_table, aw)
>    ".word 1b, %l[l_yes], %c0\n\t"
>    ".popsection\n\t"

Does it make sense to introduce something like

#define pop_section_tbl ".popsection\n\t"
#define pop_section_tbl_any pop_section_tbl

?

-- 
Andy Shevchenko 
Intel Finland Oy

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

Re: [Xen-devel] [PATCH v5 04/14] tables.h: add linker table support

[Andy Shevchenko]

On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote:
> A linker table is a data structure that is stitched together from
> items
> in multiple object files. Linux has historically implicitly used
> linker
> tables for ages, however they were all built in an adhoc manner which
> requires linker script modifications, per architecture. This adds a
> general linker table solution so that a new linker table can be
> implemented by changing C code only. The Linux linker table was
> inspired by Michael Brown's iPXE's linker table solution, it has been
> been completely re-written and adapted for integration and use on
> Linux.




> +/**
> + * LINKTABLE_FOR_EACH - iterate through all entries within a linker
> table
> + *
> + * @pointer: entry pointer
> + * @tbl: linker table
> + *
> + * Example usage::
> + *
> + *   struct frobnicator *frob;
> + *
> + *   LINKTABLE_FOR_EACH(frob, frobnicator_fns) {
> + * ...
> + *   }
> + */
> +
> +#define LINKTABLE_FOR_EACH(pointer, tbl) 
> \

Hmm... SOMEONE LIKES CAPITAL LETTERS FOR everything, right? :-)

I would expect more standard 
linktable_for_each()
macro

Same to the rest of similar macros.


> +/**
> + * LINKTABLE_RUN_ERR - run each linker table entry func and return
> error if any
> + *
> + * @tbl: linker table
> + * @func: structure name for the function name we want to call.
> + * @args...: arguments to pass to func
> + *
> + * Example usage::
> + *
> + *   unsigned int err = LINKTABLE_RUN_ERR(frobnicator_fns,
> some_run,);
> + */
> +#define LINKTABLE_RUN_ERR(tbl, func, args...)
> \
> +({   
> \
> + size_t i;   
> \
> + int err = 0;
> \
> + for (i = 0; !err && i < LINKTABLE_SIZE(tbl); i++)   
> \
> + err = (LINKTABLE_START(tbl)[i]).func (args);


> \
> + err;

Indentation here a bit confusing.

> \
> +})


-- 
Andy Shevchenko 
Intel Finland Oy

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

Re: [Xen-devel] Xenstore watch interface in the kernel

[Ian Jackson]

Sander Eikelenboom writes ("Re: [Xen-devel] Xenstore watch interface in the 
kernel"):
> Something I did ran into while trying to use xenstore, was that the
> callbacks don't give back the previous and current value.

Others have replied to this, and I agree with them, but: this makes me
think you are probably writing an incorrect algorithm or state
machine.

The correct way to use a xenstore watch is to treat it a bit like an
interrupt: your code should use it as a prompt to read the value(s) it
cares about.  (In a transaction, if multiple reads are needed.)

The update, which reads the xenstore keys and "makes it so", should be
idempotent.

Obviously your code needs to keep track of what situation it currently
implements, anyway.  So you shouldn't need to explicitly retain the
previous xenstore contents.

Ian.

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

Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 
103788: regressions - trouble: broken/fail/pass)"):
> On 22.12.16 at 13:19,  wrote:
> > Perhaps it would be worth telling Xen not to reboot on crash...
> 
> I think that's worth giving a try (I assume that some timeout will cause
> the machine to get rebooted at some point anyway, to make it available
> again).

Like this, then, AFAICT from the docs.  FAOD, this shouldn't affect
deliberate attempts by the dom0 to reboot the host ?  I found the docs
not quite clear on this point.

Ian.

From acdf52770bbec07680bf4e61ad3984a1d0156af3 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Thu, 22 Dec 2016 13:43:01 +
Subject: [OSSTEST PATCH] ts-xen-install: Pass `noreboot' to Xen

This prevents Xen from rebooting the host, if Xen crashes.

This reboot serves no function in osstest, since a crashed host will
be automatically power cycled to recover it.  (Firstly, during log
collection, a renewed attempt to boot from the hard disk; then, during
the next test, netboot to wipe the machine to reinstall it.)

But the reboot does make logs more confusing, and we suspect that the
reboot loops which can occur (eg if the version of Xen and Linux being
tested always crashes on boot) might be implicated in our test boxes
occasionally forgetting their boot order.

Signed-off-by: Ian Jackson 
---
 ts-xen-install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-xen-install b/ts-xen-install
index 2a1784d..c921e69 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -142,7 +142,7 @@ sub adjustconfig () {
 }
 
 sub setupboot () {
-my $xenhopt= "conswitch=x watchdog";
+my $xenhopt= "conswitch=x watchdog noreboot";
 
 my $cons= get_host_property($ho, 'XenSerialConsole', 'com1');
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 2/2] x86/VMX: don't needlessly install VMFUNC emulation hook

[Andrew Cooper]

On 22/12/16 08:37, Jan Beulich wrote:

Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
determine whether to install the hook in the first place.

Signed-off-by: Jan Beulich 


I am not so sure about this.

vmfunc is reachable in the instruction emulator on hardware which 
doesn't support vmfunc, and there is explicit provision for using vmfunc 
0 via hypercall on hardware lacking vmfunc support.


Given that the #VE part of altp2m is always emulated architecturally, I 
think there is an argument to be made for also emulating EPTP switching 
architecturally as well.


~Andrew

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

Re: [Xen-devel] [PATCH 1/2] x86/HVM: constify VMFUNC emulation hook

[Andrew Cooper]

On 22/12/16 08:36, Jan Beulich wrote:

... to clarify that the register state does not get altered (behind the
back of the emulator).

Signed-off-by: Jan Beulich 


Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] Xenstore watch interface in the kernel

[Andrew Cooper]

On 22/12/16 12:59, Juergen Gross wrote:

On 22/12/16 13:49, Sander Eikelenboom wrote:

Thursday, December 22, 2016, 1:22:06 PM, you wrote:


Juergen Gross writes ("Xenstore watch interface in the kernel"):

While working on the Linux xenbus kernel driver I stumbled over a rather
strange interface: a Xenstore watch event is delivered via a callback
defined as:

void (*callback)(struct xenbus_watch *,
  const char **vec, unsigned int len);

vec is an array of strings and len the number of strings in that
array.

Looking at the Xenstore interface I don't see how there could ever be
an array with another len than 2 be presented (the first string being
the modified path, the second the token specified when registering
the watch).

Yes, this is an anomaly.
IIRC (from the last time I looked at this) a long time ago in a galaxy
far far away someone thought it might be a good idea to introduce some
kind of payload to watch events, so that watches could be explicitly
fired with a payload.
However, this wasn't in any deployed implementation.

Something I did ran into while trying to use xenstore, was that the callbacks
don't give back the previous and current value.
So you don't really know *how* the state changed, unless you keep all change
locally as well.
I have circumvented it the dirty way, by setting the token as the current
value, but it isn't very pretty and all setters must adhere to that, so it's not
working for the general Xen entries and therefor only useful for my own entries.

Any idea as to why the callback doesn't return the current and previous value
directly ?

This can't work: imagine two changes of the same node made in a very
short time. There is no guarantee which watch event would reach you
first, so the information regarding the old and new contents could be
really confusing:

node has value A
is changed to B
and then to C

You could see the watch events:

value changed from B->C
value changed from A->B

So either you would end up with the wrong new value "B" or you could
track the contents in order to detect the reverse order of events,
but this wouldn't be better than now.


You can also set watches on keys which don't exist yet, and have they 
watch fire when the key appears.  Distinguishing between not existing 
and having an empty value can't be done with just the previous content 
being sent.


~Andrew

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

Re: [Xen-devel] [PATCH v15] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Konrad Rzeszutek Wilk]

On December 22, 2016 2:21:26 AM EST, Oleksandr Andrushchenko 
 wrote:
>Hi, Konrad!
>
>I see no comments for almost 3 weeks now, so
>probably there are no objections against this protocol.
>Can we please move on on this?

Sorry, I had been busy with internal high priority items. Let me take a look at 
it this Friday.


>
>Thank you in advance,
>Oleksandr
>
>On 12/08/2016 05:13 PM, Oleksandr Andrushchenko wrote:
>> I'm just wondering if anybody had a chance to look at the patch...


Thanks!


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

Re: [Xen-devel] Xenstore watch interface in the kernel

[Juergen Gross]

On 22/12/16 13:49, Sander Eikelenboom wrote:
> 
> Thursday, December 22, 2016, 1:22:06 PM, you wrote:
> 
>> Juergen Gross writes ("Xenstore watch interface in the kernel"):
>>> While working on the Linux xenbus kernel driver I stumbled over a rather
>>> strange interface: a Xenstore watch event is delivered via a callback
>>> defined as:
>>>
>>> void (*callback)(struct xenbus_watch *,
>>>  const char **vec, unsigned int len);
>>>
>>> vec is an array of strings and len the number of strings in that
>>> array.
>>>
>>> Looking at the Xenstore interface I don't see how there could ever be
>>> an array with another len than 2 be presented (the first string being
>>> the modified path, the second the token specified when registering
>>> the watch).
> 
>> Yes, this is an anomaly.
> 
>> IIRC (from the last time I looked at this) a long time ago in a galaxy
>> far far away someone thought it might be a good idea to introduce some
>> kind of payload to watch events, so that watches could be explicitly
>> fired with a payload.
> 
>> However, this wasn't in any deployed implementation.
> 
> Something I did ran into while trying to use xenstore, was that the callbacks
> don't give back the previous and current value.
> So you don't really know *how* the state changed, unless you keep all change 
> locally as well.
> I have circumvented it the dirty way, by setting the token as the current
> value, but it isn't very pretty and all setters must adhere to that, so it's 
> not 
> working for the general Xen entries and therefor only useful for my own 
> entries.
> 
> Any idea as to why the callback doesn't return the current and previous value
> directly ?

This can't work: imagine two changes of the same node made in a very
short time. There is no guarantee which watch event would reach you
first, so the information regarding the old and new contents could be
really confusing:

node has value A
is changed to B
and then to C

You could see the watch events:

value changed from B->C
value changed from A->B

So either you would end up with the wrong new value "B" or you could
track the contents in order to detect the reverse order of events,
but this wouldn't be better than now.


Juergen

> --
> Sander
> 
>>> I'd like to modify the callback's prototype to:
>>>
>>> void (*callback)(struct xenbus_watch *,
>>>  const char *path, const char *token);
> 
>> I think this would be a fine idea.
> 
>>> Is there any reason not to change the interface in the kernel?
> 
>> No.
> 
>>> BTW: The handling of more than 2 strings as watch event parameters is
>>> even repeated in the interface to libxenstore. I looked through the Xen
>>> sources and could find no use of the number of strings returned in case
>>> of a watch event. While we can't change the interface of libxenstore
>>> I don't think we have to be prepared for an arbitrary number of strings
>>> for a watch event at the kernel interface.
> 
>> Yes.
> 
>> Ian.
> 
> 
> 
> 


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

Re: [Xen-devel] Xenstore watch interface in the kernel

[Sander Eikelenboom]

Thursday, December 22, 2016, 1:22:06 PM, you wrote:

> Juergen Gross writes ("Xenstore watch interface in the kernel"):
>> While working on the Linux xenbus kernel driver I stumbled over a rather
>> strange interface: a Xenstore watch event is delivered via a callback
>> defined as:
>> 
>> void (*callback)(struct xenbus_watch *,
>>  const char **vec, unsigned int len);
>> 
>> vec is an array of strings and len the number of strings in that
>> array.
>> 
>> Looking at the Xenstore interface I don't see how there could ever be
>> an array with another len than 2 be presented (the first string being
>> the modified path, the second the token specified when registering
>> the watch).

> Yes, this is an anomaly.

> IIRC (from the last time I looked at this) a long time ago in a galaxy
> far far away someone thought it might be a good idea to introduce some
> kind of payload to watch events, so that watches could be explicitly
> fired with a payload.

> However, this wasn't in any deployed implementation.

Something I did ran into while trying to use xenstore, was that the callbacks
don't give back the previous and current value.
So you don't really know *how* the state changed, unless you keep all change 
locally as well.
I have circumvented it the dirty way, by setting the token as the current
value, but it isn't very pretty and all setters must adhere to that, so it's 
not 
working for the general Xen entries and therefor only useful for my own entries.

Any idea as to why the callback doesn't return the current and previous value
directly ?
--
Sander

>> I'd like to modify the callback's prototype to:
>> 
>> void (*callback)(struct xenbus_watch *,
>>  const char *path, const char *token);

> I think this would be a fine idea.

>> Is there any reason not to change the interface in the kernel?

> No.

>> BTW: The handling of more than 2 strings as watch event parameters is
>> even repeated in the interface to libxenstore. I looked through the Xen
>> sources and could find no use of the number of strings returned in case
>> of a watch event. While we can't change the interface of libxenstore
>> I don't think we have to be prepared for an arbitrary number of strings
>> for a watch event at the kernel interface.

> Yes.

> Ian.




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