[Xen-devel] [qemu-mainline test] 145975: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 144861
 build-arm64   6 xen-buildfail REGR. vs. 144861
 build-amd64   6 xen-buildfail REGR. vs. 144861
 build-i386-xsm6 xen-buildfail REGR. vs. 144861
 build-armhf   6 xen-buildfail REGR. vs. 144861
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144861
 build-i3866 xen-buildfail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 

[Xen-devel] [qemu-mainline test] 145964: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 144861
 build-arm64   6 xen-buildfail REGR. vs. 144861
 build-amd64   6 xen-buildfail REGR. vs. 144861
 build-i386-xsm6 xen-buildfail REGR. vs. 144861
 build-armhf   6 xen-buildfail REGR. vs. 144861
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144861
 build-i3866 xen-buildfail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 

Re: [Xen-devel] [PATCH v1 1/4] kasan: introduce set_pmd_early_shadow()

[kbuild test robot]

Hi Sergey,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net-next/master]
[also build test ERROR on net/master linus/master v5.5-rc5 next-20200109]
[cannot apply to xen-tip/linux-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Sergey-Dyasli/basic-KASAN-support-for-Xen-PV-domains/20200110-042623
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
4a4a52d49d11f5c4a0df8b9806c8c5563801f753
config: s390-allmodconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 7.5.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=s390 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   mm//kasan/init.c: In function 'set_pmd_early_shadow':
>> mm//kasan/init.c:90:3: error: implicit declaration of function 'set_pmd'; 
>> did you mean 'get_pid'? [-Werror=implicit-function-declaration]
  set_pmd(pmd, __pmd(__pa(early_shadow) | _PAGE_TABLE));
  ^~~
  get_pid
   In file included from arch/s390/include/asm/thread_info.h:26:0,
from include/linux/thread_info.h:38,
from arch/s390/include/asm/preempt.h:6,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:6,
from include/linux/mm.h:10,
from include/linux/memblock.h:13,
from mm//kasan/init.c:14:
   mm//kasan/init.c:90:43: error: '_PAGE_TABLE' undeclared (first use in this 
function); did you mean 'NR_PAGETABLE'?
  set_pmd(pmd, __pmd(__pa(early_shadow) | _PAGE_TABLE));
  ^
   arch/s390/include/asm/page.h:96:37: note: in definition of macro '__pmd'
#define __pmd(x)((pmd_t) { (x) } )
^
   mm//kasan/init.c:90:43: note: each undeclared identifier is reported only 
once for each function it appears in
  set_pmd(pmd, __pmd(__pa(early_shadow) | _PAGE_TABLE));
  ^
   arch/s390/include/asm/page.h:96:37: note: in definition of macro '__pmd'
#define __pmd(x)((pmd_t) { (x) } )
^
   cc1: some warnings being treated as errors

vim +90 mm//kasan/init.c

83  
84  static inline void set_pmd_early_shadow(pmd_t *pmd)
85  {
86  static bool pmd_populated = false;
87  pte_t *early_shadow = lm_alias(kasan_early_shadow_pte);
88  
89  if (likely(pmd_populated)) {
  > 90  set_pmd(pmd, __pmd(__pa(early_shadow) | _PAGE_TABLE));
91  } else {
92  pmd_populate_kernel(_mm, pmd, early_shadow);
93  pmd_populated = true;
94  }
95  }
96  

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation


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

Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests

[Doug Goldstein]

On 1/10/20 4:37 AM, Sergey Dyasli wrote:

Hide the following information that can help identify the running Xen
binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
Add explicit cases for XENVER_commandline and XENVER_build_id as well.

Introduce xsm_filter_denied() to hvmloader to remove "" string
from guest's DMI tables that otherwise would be shown in tools like
dmidecode.

Signed-off-by: Sergey Dyasli 
---
v1 --> v2:
- Added xsm_filter_denied() to hvmloader instead of modifying xen_deny()


So 100% this version of the patch won't fly with the various downstreams 
that run the v1 of this patch. Those various consumers will stick with v1.


If the goal of this is to reduce the burden of the downstreams and their 
customers to carry a patch against Xen then I wouldn't even bother with 
this version.


--
Doug

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

[Xen-devel] [qemu-mainline bisection] complete build-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-amd64-xsm
testid xen-build

Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  b0b74e1f17508cb8cef8afd698558db1bd8999cc
  Bug not present: f17783e706ab9c7b3a2b69cf48e4f0ba40664f54
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/145967/


  commit b0b74e1f17508cb8cef8afd698558db1bd8999cc
  Merge: f17783e706 ddf9069963
  Author: Peter Maydell 
  Date:   Mon Jan 6 11:39:55 2020 +
  
  Merge remote-tracking branch 
'remotes/ehabkost/tags/python-next-pull-request' into staging
  
  Require Python >= 3.5 to build QEMU
  
  Python 2 EOL is 11 days away, we will stop supporting
  it in QEMU 5.0.
  
  # gpg: Signature made Fri 20 Dec 2019 16:49:02 GMT
  # gpg:using RSA key 
5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6
  # gpg:issuer "ehabk...@redhat.com"
  # gpg: Good signature from "Eduardo Habkost " [full]
  # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF  D1AA 2807 936F 984D 
C5A6
  
  * remotes/ehabkost/tags/python-next-pull-request:
configure: Require Python >= 3.5
travis: Replace Python 3.4 build with 3.5
  
  Signed-off-by: Peter Maydell 
  
  commit ddf90699631db53c981b6a5a63d31c08e0eaeec7
  Author: Eduardo Habkost 
  Date:   Wed Oct 16 19:42:37 2019 -0300
  
  configure: Require Python >= 3.5
  
  Python 3.5 is the oldest Python version available on our
  supported build platforms, and Python 2 end of life will be 3
  weeks after the planned release date of QEMU 4.2.0.  Drop Python
  2 support from configure completely, and require Python 3.5 or
  newer.
  
  Signed-off-by: Eduardo Habkost 
  Message-Id: <20191016224237.26180-1-ehabk...@redhat.com>
  Reviewed-by: John Snow 
  Signed-off-by: Eduardo Habkost 
  
  commit 49233804f5c458d61d8eb903c19d62edb3434db2
  Author: Eduardo Habkost 
  Date:   Fri Dec 20 13:45:27 2019 -0300
  
  travis: Replace Python 3.4 build with 3.5
  
  We'll start requiring Python 3.5 to build QEMU.
  
  Signed-off-by: Eduardo Habkost 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/build-amd64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/build-amd64-xsm.xen-build 
--summary-out=tmp/145967.bisection-summary --basis-template=144861 
--blessings=real,real-bisect qemu-mainline build-amd64-xsm xen-build
Searching for failure / basis pass:
 145959 fail [host=godello0] / 145664 ok.
Failure / basis pass flights: 145959 / 145664
(tree with no url: minios)
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 70911f1f4aee0366b6122f2b90d367ec0f066beb 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
dc65a5bdc9fa543690a775b50d4ffbeb22c56d6d 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
fae249d23413b2bf7d98a97d8f649cf7d102c1ae
Basis pass b948a496150f4ae4f656c0f0ab672608723c80e6 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
f17783e706ab9c7b3a2b69cf48e4f0ba40664f54 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
7b3c5b70a32303b46d0d051e695f18d72cce5ed0
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/osstest/ovmf.git#b948a496150f4ae4f656c0f0ab672608723c80e6-70911f1f4aee0366b6122f2b90d367ec0f066beb
 
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://git.qemu.org/qemu.git#f17783e706ab9c7b3a2b69cf48e4f0ba40664f54-dc65a5bdc9fa543690a775b50d4ffbeb22c56d6d
 
git://xenbits.xen.org/osstest/seabios.git#f21b5a4aeb020f2a5e2c6503f906a9349dd2f069-f21\
 b5a4aeb020f2a5e2c6503f906a9349dd2f069 
git://xenbits.xen.org/xen.git#7b3c5b70a32303b46d0d051e695f18d72cce5ed0-fae249d23413b2bf7d98a97d8f649cf7d102c1ae
Loaded 54941 nodes in revision graph
Searching for test results:
 145547 [host=pinot1]
 145535 [host=godello1]
 145573 [host=huxelrebe0]
 145592 [host=godello1]
 145624 [host=godello1]
 145698 [host=godello1]
 145664 pass b948a496150f4ae4f656c0f0ab672608723c80e6 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
f17783e706ab9c7b3a2b69cf48e4f0ba40664f54 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
7b3c5b70a32303b46d0d051e695f18d72cce5ed0
 145649 [host=godello1]
 145692 fail irrelevant
 145681 fail irrelevant
 145685 fail irrelevant
 145716 

Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests

[Doug Goldstein]

On 1/10/20 9:28 AM, George Dunlap wrote:

On 1/10/20 11:02 AM, Andrew Cooper wrote:

On 10/01/2020 10:37, Sergey Dyasli wrote:

Hide the following information that can help identify the running Xen
binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
Add explicit cases for XENVER_commandline and XENVER_build_id as well.

Introduce xsm_filter_denied() to hvmloader to remove "" string
from guest's DMI tables that otherwise would be shown in tools like
dmidecode.

Signed-off-by: Sergey Dyasli 
---
v1 --> v2:
- Added xsm_filter_denied() to hvmloader instead of modifying xen_deny()
- Made behaviour the same for both Release and Debug builds
- XENVER_capabilities is no longer hided

CC: Andrew Cooper 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Julien Grall 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Wei Liu 
CC: Daniel De Graaf 


I realise there are arguments over how to fix this, but we (the Xen
community) have already f*cked up once here, and this is doing so a
second time.

Nack.

Fixing it anywhere other than Xen is simply not appropriate.

The reason for this (which ought to be obvious, but I guess only to
those who actually do customer support) is basic human physiology.
"denied" means something has gone wrong.  It scares people, and causes
them to seek help to change fix whatever is broken.


This seems like a reasonable argument that "" causes issues.
But that doesn't change the fact that "" also causes issues.



I'd be curious to hear the case where the empty string causes issues.

--
Doug

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

[Xen-devel] [PATCH v3] xen-pciback: optionally allow interrupt enable flag writes

[Marek Marczykowski-Górecki]

QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
MSI(-X) enable flags in the PCI config space. This adds an attribute
'allow_interrupt_control' which when set for a PCI device allows writes
to this flag(s). The toolstack will need to set this for stubdoms.
When enabled, guest (stubdomain) will be allowed to set relevant enable
flags, but only one at a time - i.e. it refuses to enable more than one
of INTx, MSI, MSI-X at a time.

This functionality is needed only for config space access done by device
model (stubdomain) serving a HVM with the actual PCI device. It is not
necessary and unsafe to enable direct access to those bits for PV domain
with the device attached. For PV domains, there are separate protocol
messages (XEN_PCI_OP_{enable,disable}_{msi,msix}) for this purpose.
Those ops in addition to setting enable bits, also configure MSI(-X) in
dom0 kernel - which is undesirable for PCI passthrough to HVM guests.

This should not introduce any new security issues since a malicious
guest (or stubdom) can already generate MSIs through other ways, see
[1] page 8. Additionally, when qemu runs in dom0, it already have direct
access to those bits.

This is the second iteration of this feature. First was proposed as a
direct Xen interface through a new hypercall, but ultimately it was
rejected by the maintainer, because of mixing pciback and hypercalls for
PCI config space access isn't a good design. Full discussion at [2].

[1]: 
https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
[2]: https://xen.markmail.org/thread/smpgpws4umdzizze

[part of the commit message and sysfs handling]
Signed-off-by: Simon Gaiser 
[the rest]
Signed-off-by: Marek Marczykowski-Górecki 
---
Changes in v3:
 - return bitmap (or negative error) from
   xen_pcibk_get_interrupt_type(), to implicitly handle cases when
   multiple interrupt types are already enabled - disallow enabling in
   that case
 - add documentation
Changes in v2:
 - introduce xen_pcibk_get_interrupt_type() to deduplicate current
   INTx/MSI/MSI-X state check
 - fix checking MSI/MSI-X state on devices not supporting it

---
 .../ABI/testing/sysfs-driver-pciback  | 13 +++
 drivers/xen/xen-pciback/conf_space.c  | 36 
 drivers/xen/xen-pciback/conf_space.h  |  7 ++
 .../xen/xen-pciback/conf_space_capability.c   | 88 +++
 drivers/xen/xen-pciback/conf_space_header.c   | 18 
 drivers/xen/xen-pciback/pci_stub.c| 66 ++
 drivers/xen/xen-pciback/pciback.h |  1 +
 7 files changed, 229 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-driver-pciback 
b/Documentation/ABI/testing/sysfs-driver-pciback
index 6a733bfa37e6..566a11f2c12f 100644
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testing/sysfs-driver-pciback
@@ -11,3 +11,16 @@ Description:
 #echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
 will allow the guest to read and write to the configuration
 register 0x0E.
+
+What:   /sys/bus/pci/drivers/pciback/allow_interrupt_control
+Date:   Jan 2020
+KernelVersion:  5.5
+Contact:xen-devel@lists.xenproject.org
+Description:
+List of devices which can have interrupt control flag (INTx,
+MSI, MSI-X) set by a connected guest. It is meant to be set
+only when the guest is a stubdomain hosting device model (qemu)
+and the actual device is assigned to a HVM. It is not safe
+(similar to permissive attribute) to set for a devices assigned
+to a PV guest. The device is automatically removed from this
+list when the connected pcifront terminates.
diff --git a/drivers/xen/xen-pciback/conf_space.c 
b/drivers/xen/xen-pciback/conf_space.c
index 60111719b01f..7697001e8ffc 100644
--- a/drivers/xen/xen-pciback/conf_space.c
+++ b/drivers/xen/xen-pciback/conf_space.c
@@ -286,6 +286,42 @@ int xen_pcibk_config_write(struct pci_dev *dev, int 
offset, int size, u32 value)
return xen_pcibios_err_to_errno(err);
 }
 
+int xen_pcibk_get_interrupt_type(struct pci_dev *dev)
+{
+   int err;
+   u16 val;
+   int ret = 0;
+
+   err = pci_read_config_word(dev, PCI_COMMAND, );
+   if (err)
+   return err;
+   if (!(val & PCI_COMMAND_INTX_DISABLE))
+   ret |= INTERRUPT_TYPE_INTX;
+
+   /* Do not trust dev->msi(x)_enabled here, as enabling could be done
+* bypassing the pci_*msi* functions, by the qemu.
+*/
+   if (dev->msi_cap) {
+   err = pci_read_config_word(dev,
+   dev->msi_cap + PCI_MSI_FLAGS,
+   );
+   if (err)
+   return err;
+   if (val & PCI_MSI_FLAGS_ENABLE)
+   ret |= INTERRUPT_TYPE_MSI;
+   }
+   if 

[Xen-devel] [qemu-mainline test] 145959: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 144861
 build-arm64   6 xen-buildfail REGR. vs. 144861
 build-amd64   6 xen-buildfail REGR. vs. 144861
 build-i386-xsm6 xen-buildfail REGR. vs. 144861
 build-armhf   6 xen-buildfail REGR. vs. 144861
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144861
 build-i3866 xen-buildfail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 

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

[Julien Grall]

(+ Meng)

Hi,

Sorry I forgot to cc the RTDS scheduler maintainer.

On 10/01/2020 18:24, Julien Grall wrote:

Hi all,

On 08/01/2020 23:14, Julien Grall wrote:

On Wed, 8 Jan 2020 at 21:40, osstest service owner
 wrote:


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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
  test-amd64-amd64-xl-rtds    15 guest-saverestore fail in 145773 
pass in 145796
  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail in 145773 pass in 145796
  test-armhf-armhf-xl-rtds 12 guest-start  fail in 145773 
pass in 145796


It looks like this test has been failing for a while (although not 
reliably).

I looked at  a few flights, the cause seems to be the same:

Jan  8 15:02:14.700784 (XEN) Assertion '!unit_on_replq(svc)' failed at
sched_rt.c:586
Jan  8 15:02:26.715030 (XEN) [ Xen-4.14-unstable  arm32  debug=y
Not tainted ]
Jan  8 15:02:26.720756 (XEN) CPU:    1
Jan  8 15:02:26.722158 (XEN) PC: 0023a750
common/sched_rt.c#replq_insert+0x7c/0xcc
Jan  8 15:02:26.727851 (XEN) CPSR:   200300da MODE:Hypervisor
Jan  8 15:02:26.731334 (XEN)  R0: 002a51a4 R1: 400614a0 R2:
3d64b900 R3: 40061338
Jan  8 15:02:26.736830 (XEN)  R4: 400614a0 R5: 002a51a4 R6:
3cf1cbf0 R7: 01cb
Jan  8 15:02:26.742600 (XEN)  R8: 4003d1b0 R9: 400614a8
R10:4003d1b0 R11:400ffe54 R12:400ffde4
Jan  8 15:02:26.749119 (XEN) HYP: SP: 400ffe2c LR: 0023b6e8
Jan  8 15:02:26.752296 (XEN)
Jan  8 15:02:26.753036 (XEN)   VTCR_EL2: 80003558
Jan  8 15:02:26.755479 (XEN)  VTTBR_EL2: 0002bbff4000
Jan  8 15:02:26.758757 (XEN)
Jan  8 15:02:26.759366 (XEN)  SCTLR_EL2: 30cd187f
Jan  8 15:02:26.761755 (XEN)    HCR_EL2: 0078663f
Jan  8 15:02:26.764250 (XEN)  TTBR0_EL2: bc029000
Jan  8 15:02:26.767364 (XEN)
Jan  8 15:02:26.767980 (XEN)    ESR_EL2: 
Jan  8 15:02:26.770485 (XEN)  HPFAR_EL2: 00030010
Jan  8 15:02:26.772795 (XEN)  HDFAR: e0800f00
Jan  8 15:02:26.775272 (XEN)  HIFAR: c0605744
Jan  8 15:02:26.48 (XEN)
Jan  8 15:02:26.778505 (XEN) Xen stack trace from sp=400ffe2c:
Jan  8 15:02:26.781910 (XEN)     3cf1cbf0 400614a0 002a51a4
3cf1cbf0 01cb 4003d1b0 6003005a
Jan  8 15:02:26.788991 (XEN)    400613f8 400ffe7c 0023b6e8 002f9300
4004c000 400613f8 3cf1cbf0 01cb
Jan  8 15:02:26.796093 (XEN)    4003d1b0 6003005a 400613f8 400ffeac
00242988 4004c000 002425ac 40058000
Jan  8 15:02:26.803237 (XEN)    4004c000 4004f000 10f45000 10f45008
4004b080 40058000 60030013 400ffebc
Jan  8 15:02:26.810360 (XEN)    00209984 0002 4004f000 400ffedc
0020eddc 0020caf8 db097cd4 0020
Jan  8 15:02:26.817504 (XEN)    c13afbec  db15fd68 400ffee4
0020c9dc 400fff34 0020d5e8 4004e000
Jan  8 15:02:26.824615 (XEN)     400fff44 400fff44 0002
 4004e8fa 4004e8f4 400fff1c
Jan  8 15:02:26.831737 (XEN)    400fff1c 6003005a 0020caf8 400fff58
0020 c13afbec  db15fd68
Jan  8 15:02:26.838798 (XEN)    60030013 400fff54 0026c150 c1204d08
c13afbec   
Jan  8 15:02:26.845877 (XEN)    0002 400fff58 002753b0 0009
db097cd4 db173008 0002 c1204d08
Jan  8 15:02:26.852986 (XEN)     0002 c13afbec 
db15fd68 60030013 db15fd3c 0020
Jan  8 15:02:26.860044 (XEN)     b6cdccb3 c0107ed0 a0030093
4a000ea1 be951568 c136edc0 c010d3a0
Jan  8 15:02:26.867171 (XEN)    db097cd0 c056c7f8 c136edcc c010d720
c136edd8 c010d7e0  
Jan  8 15:02:26.874526 (XEN)       c136ede4
c136ede4 00030030 60070193 80030093
Jan  8 15:02:26.881450 (XEN)    60030193    
0001

Jan  8 15:02:26.886519 (XEN) Xen call trace:
Jan  8 15:02:26.888168 (XEN)    [<0023a750>]
common/sched_rt.c#replq_insert+0x7c/0xcc (PC)
Jan  8 15:02:26.894240 (XEN)    [<0023b6e8>]
common/sched_rt.c#rt_unit_wake+0xf4/0x274 (LR)
Jan  8 15:02:26.900246 (XEN)    [<0023b6e8>]
common/sched_rt.c#rt_unit_wake+0xf4/0x274
Jan  8 15:02:26.905775 (XEN)    [<00242988>] vcpu_wake+0x1e4/0x688
Jan  8 15:02:26.909743 (XEN)    [<00209984>] domain_unpause+0x64/0x84
Jan  8 15:02:26.913956 (XEN)    [<0020eddc>]
common/event_fifo.c#evtchn_fifo_unmask+0xd8/0xf0
Jan  8 15:02:26.920167 (XEN)    [<0020c9dc>] evtchn_unmask+0x7c/0xc0
Jan  8 15:02:26.924173 (XEN)    [<0020d5e8>] 
do_event_channel_op+0xaf0/0xdac
Jan  8 15:02:26.928922 (XEN)    [<0026c150>] 
do_trap_guest_sync+0x350/0x4d0
Jan  8 15:02:26.933647 (XEN)    [<002753b0>] 
entry.o#return_from_trap+0/0x4

Jan  8 15:02:26.938299 (XEN)
Jan  8 15:02:26.939039 (XEN)
Jan  8 15:02:26.939668 (XEN) 
Jan  8 15:02:26.943794 (XEN) Panic on CPU 1:
Jan  8 15:02:26.945872 (XEN) Assertion '!unit_on_replq(svc)' failed at
sched_rt.c:586
Jan  8 15:02:26.951492 (XEN) 

I believe the domain_unpause() is coming from guest_clear_bit(). This
would mean the atomics didn't succeed without 

Re: [Xen-devel] [PATCH] xen/sched: rt: Fix typo in a comment

[Meng Xu]

On Fri, Jan 10, 2020 at 2:23 PM Julien Grall  wrote:
>
> Signed-off-by: Julien Grall 
> ---
>  xen/common/sched_rt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index b2b29481f3..c40a7e4990 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -122,7 +122,7 @@
>   */
>  /*
>   * RTDS_scheduled: Is this unit either running on, or context-switching off,
> - * a phyiscal cpu?
> + * a physical cpu?
>   * + Accessed only with global lock held.
>   * + Set when chosen as next in rt_schedule().
>   * + Cleared after context switch has been saved in rt_context_saved()
> --
> 2.24.0
>

Reviewed-by: Meng Xu 

Cheers,

Meng

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

[Xen-devel] [qemu-mainline test] 145954: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 144861
 build-arm64   6 xen-buildfail REGR. vs. 144861
 build-amd64   6 xen-buildfail REGR. vs. 144861
 build-i386-xsm6 xen-buildfail REGR. vs. 144861
 build-armhf   6 xen-buildfail REGR. vs. 144861
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144861
 build-i3866 xen-buildfail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvshim1 

Re: [Xen-devel] [RFC PATCH V2 09/11] xen: Clear IRQD_IRQ_STARTED flag during shutdown PIRQs

[Anchal Agarwal]

On Fri, Jan 10, 2020 at 08:13:16PM +0100, Thomas Gleixner wrote:
> Anchal,
> 
> Anchal Agarwal  writes:
> > On Thu, Jan 09, 2020 at 01:07:27PM +0100, Thomas Gleixner wrote:
> >> Anchal Agarwal  writes:
> >> So either you can handle it purely on the XEN side without touching any
> >> core state or you need to come up with some way of letting the core code
> >> know that it should invoke shutdown instead of disable.
> >> 
> >> Something like the completely untested patch below.
> >
> > Understandable. Really appreciate the patch suggestion below and i will 
> > test it
> > for sure and see if things can be fixed properly in irq core if thats the 
> > only
> > option. In the meanwhile, I tried to fix it on xen side unless it gives you 
> > the 
> > same feeling as above? MSI-x are just fine, just ioapic ones don't get any 
> > event
> > channel asssigned hence enable_dynirq does nothing. Those needs to be 
> > restarted.
> >
> > diff --git a/drivers/xen/events/events_base.c 
> > b/drivers/xen/events/events_base.c
> > index 1bb0b522d004..2ed152f35816 100644
> > --- a/drivers/xen/events/events_base.c
> > +++ b/drivers/xen/events/events_base.c
> > @@ -575,6 +575,11 @@ static void shutdown_pirq(struct irq_data *data)
> >
> > static void enable_pirq(struct irq_data *data)
> > {
> > +/*ioapic interrupts don't get event channel assigned
> >+ * after being explicitly shutdown during guest
> >+ * hibernation. They need to be restarted*/
> > +   if(!evtchn_from_irq(data->irq))
> > +   startup_pirq(data);
> > enable_dynirq(data);
> >  }
> 
> Interesting patch format :)
Apparently vim and me rushing through the email [did not format the patch]
were the culprit and I only caught it after sending an email
> 
> Doing the shutdown from syscore_ops and the startup conditionally in a
> totaly unrelated function is not really intuitive.
> 
I agree to the point that still the startup is not as synchronous 
to shutdown however, enable_pirq is still invoked during irq_startup
for xen specific code and I was trying to reuse the code path to fix 
within xen. Basically borrowing from what this commit [commit 020db9d3]
changed. Not sure if this could have broken under any other environment
though :(

But anyways I think the patch you suggested is much more clean and 
intuitive.

> So either you do it symmetrically in XEN via syscore_ops callbacks or
> you let the irq core code help you out with the patch I provided
> 
In my understanding, it may not be the right thing as syscore stuff runs
with one cpu online and disabled interrupts. Also I did try it in the past 
and failed horribly unless there is any smarter way of doing it.
It should correctly be done in suspend/resume devices as are other device 
interrupts.

I did test the patch you suggested and it works.
I haven't done large scale testing but it looks like it may just work fine.
I will send out an updated patch for shutdown/startup of pirq after I do some
more testing and will drop patches related to shutdown/startup of pirqs from 
the original series.

Thanks,

Anchal

> Thanks,
> 
> tglx

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

[Xen-devel] [PATCH] xen/sched: rt: Fix typo in a comment

[Julien Grall]

Signed-off-by: Julien Grall 
---
 xen/common/sched_rt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index b2b29481f3..c40a7e4990 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -122,7 +122,7 @@
  */
 /*
  * RTDS_scheduled: Is this unit either running on, or context-switching off,
- * a phyiscal cpu?
+ * a physical cpu?
  * + Accessed only with global lock held.
  * + Set when chosen as next in rt_schedule().
  * + Cleared after context switch has been saved in rt_context_saved()
-- 
2.24.0


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

[Xen-devel] [ovmf test] 145948: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
145767
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767

version targeted for testing:
 ovmf 9d1c9d0379d065ca11bc3354faee2c742e89c005
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z2 days
Failing since145774  2020-01-08 02:50:20 Z2 days   15 attempts
Testing same since   145926  2020-01-10 12:09:33 Z0 days3 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ashish Singhal 
  Eric Dong 
  Jason Voelz 
  Laszlo Ersek 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 
  Vitaly Cheptsov 
  Vitaly Cheptsov via Groups.Io 

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.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

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

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

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


Not pushing.

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

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  ba322a175059a712802401e8337c6c7952b265d1
baseline version:
 xen  fae249d23413b2bf7d98a97d8f649cf7d102c1ae

Last test of basis   145867  2020-01-09 15:00:38 Z1 days
Testing same since   145946  2020-01-10 19:00:23 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Paul Durrant 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 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 :

To xenbits.xen.org:/home/xen/git/xen.git
   fae249d234..ba322a1750  ba322a175059a712802401e8337c6c7952b265d1 -> smoke

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

[Xen-devel] [qemu-mainline test] 145947: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 144861
 build-arm64   6 xen-buildfail REGR. vs. 144861
 build-amd64   6 xen-buildfail REGR. vs. 144861
 build-i386-xsm6 xen-buildfail REGR. vs. 144861
 build-armhf   6 xen-buildfail REGR. vs. 144861
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144861
 build-i3866 xen-buildfail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 

[Xen-devel] [PATCH] get-maintainer.pl: Dont fall over when L: contains a display name

[Lars Kurth]

From: Lars Kurth 

Prior to this change e-mail addresses of the form "display name
" would result into empty output. Also see
https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg00753.html

Signed-off-by: Lars Kurth 
---
CC: jgr...@suse.com
---
 scripts/get_maintainer.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 2e661f47d8..48e07370e8 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -1073,7 +1073,7 @@ sub add_categories {
my $ptype = $1;
my $pvalue = $2;
if ($ptype eq "L") {
-   my $list_address = $pvalue;
+   my ($list_name, $list_address) = parse_email($pvalue);  
  
my $list_additional = "";
my $list_role = get_list_role($i);
 
-- 
2.13.0


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

Re: [Xen-devel] [PATCH v6 00/11] error: auto propagated local_err part I

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200110194158.14190-1-vsement...@virtuozzo.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Xen-devel] [PATCH v6 00/11] error: auto propagated local_err part I
Type: series
Message-id: 20200110194158.14190-1-vsement...@virtuozzo.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Switched to a new branch 'test'
fee0dd2 xen: introduce ERRP_AUTO_PROPAGATE
9074b45 nbd: introduce ERRP_AUTO_PROPAGATE
05632cb TPM: introduce ERRP_AUTO_PROPAGATE
2a019cd virtio-9p: introduce ERRP_AUTO_PROPAGATE
b4e0525 fw_cfg: introduce ERRP_AUTO_PROPAGATE
3a69800 pflash: introduce ERRP_AUTO_PROPAGATE
f4ac870 SD (Secure Card): introduce ERRP_AUTO_PROPAGATE
29fbc1d hw/sd/ssi-sd: fix error handling in ssi_sd_realize
6ebc57a scripts: add coccinelle script to use auto propagated errp
477b9ec error: auto propagated local_err
0c38914 qapi/error: add (Error **errp) cleaning APIs

=== OUTPUT BEGIN ===
1/11 Checking commit 0c389147591a (qapi/error: add (Error **errp) cleaning APIs)
2/11 Checking commit 477b9ec03898 (error: auto propagated local_err)
ERROR: Macros with multiple statements should be enclosed in a do - while loop
#138: FILE: include/qapi/error.h:428:
+#define ERRP_AUTO_PROPAGATE()  \
+g_auto(ErrorPropagator) _auto_errp_prop = {.errp = errp};  \
+errp = ((errp == NULL || *errp == error_fatal) \
+? &_auto_errp_prop.local_err : errp)

total: 1 errors, 0 warnings, 102 lines checked

Patch 2/11 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

3/11 Checking commit 6ebc57a94cf0 (scripts: add coccinelle script to use auto 
propagated errp)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#25: 
new file mode 100644

total: 0 errors, 1 warnings, 148 lines checked

Patch 3/11 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
4/11 Checking commit 29fbc1d61eb1 (hw/sd/ssi-sd: fix error handling in 
ssi_sd_realize)
5/11 Checking commit f4ac87065f2c (SD (Secure Card): introduce 
ERRP_AUTO_PROPAGATE)
6/11 Checking commit 3a69800331a4 (pflash: introduce ERRP_AUTO_PROPAGATE)
7/11 Checking commit b4e0525d3dcf (fw_cfg: introduce ERRP_AUTO_PROPAGATE)
8/11 Checking commit 2a019cd1f992 (virtio-9p: introduce ERRP_AUTO_PROPAGATE)
9/11 Checking commit 05632cbe2d39 (TPM: introduce ERRP_AUTO_PROPAGATE)
10/11 Checking commit 9074b450cb34 (nbd: introduce ERRP_AUTO_PROPAGATE)
11/11 Checking commit fee0dd26ea0b (xen: introduce ERRP_AUTO_PROPAGATE)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20200110194158.14190-1-vsement...@virtuozzo.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] Introduce CHANGELOG.md

[Lars Kurth]

> On 10 Jan 2020, at 17:54, Andrew Cooper  wrote:
> 
> On 10/01/2020 09:12, Paul Durrant wrote:
>> As agreed during the 2020-01 community call [1] this patch introduces a
>> changelog, based on the principles explained at keepachangelog.com [2].
>> A new MAINTAINERS entry is also added, with myself as (currently sole)
>> maintainer.
>> 
>> [1] See C.2 at https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6Htl-AJ/
>> [2] https://keepachangelog.com/en/1.0.0/
>> 
>> Signed-off-by: Paul Durrant 
>> ---
>> Cc: Andrew Cooper 
>> Cc: George Dunlap 
>> Cc: Ian Jackson 
>> Cc: Jan Beulich 
>> Cc: Julien Grall 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Stefano Stabellini 
>> Cc: Wei Liu 
>> Cc: Lars Kurth 
>> 
>> Should there be other maintainers apart from myself (with my RM hat on)?
>> Perhaps Lars should also be added as a designated reviewer?
> 
> Ultimately, the committers are last line of judgement on "whether this
> change should be in the changelog".  Practically, that includes "The
> Rest", but there was an objection to that on the call IIRC.

Am happy to be added

Lars

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

[Xen-devel] [PATCH v6 03/11] scripts: add coccinelle script to use auto propagated errp

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

CC: Cornelia Huck 
CC: Eric Blake 
CC: Kevin Wolf 
CC: Max Reitz 
CC: Greg Kurz 
CC: Stefan Hajnoczi 
CC: Stefano Stabellini 
CC: Anthony Perard 
CC: Paul Durrant 
CC: "Philippe Mathieu-Daudé" 
CC: Laszlo Ersek 
CC: Gerd Hoffmann 
CC: Stefan Berger 
CC: Markus Armbruster 
CC: Michael Roth 
CC: qemu-bl...@nongnu.org
CC: xen-devel@lists.xenproject.org

 include/qapi/error.h  |   3 +
 scripts/coccinelle/auto-propagated-errp.cocci | 139 ++
 2 files changed, 142 insertions(+)
 create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci

diff --git a/include/qapi/error.h b/include/qapi/error.h
index 532b9afb9e..dcfb77e107 100644
--- a/include/qapi/error.h
+++ b/include/qapi/error.h
@@ -141,6 +141,9 @@
  * ...
  * }
  *
+ * For mass conversion use script
+ *   scripts/coccinelle/auto-propagated-errp.cocci
+ *
  *
  * Receive and accumulate multiple errors (first one wins):
  * Error *err = NULL, *local_err = NULL;
diff --git a/scripts/coccinelle/auto-propagated-errp.cocci 
b/scripts/coccinelle/auto-propagated-errp.cocci
new file mode 100644
index 00..6c72a5049f
--- /dev/null
+++ b/scripts/coccinelle/auto-propagated-errp.cocci
@@ -0,0 +1,139 @@
+// Use ERRP_AUTO_PROPAGATE (see include/qapi/error.h)
+//
+// Copyright (c) 2020 Virtuozzo International GmbH.
+//
+// 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.
+//
+// You should have received a copy of the GNU General Public License
+// along with this program.  If not, see .
+//
+// Usage example:
+// spatch --sp-file scripts/coccinelle/auto-propagated-errp.cocci \
+//  --macro-file scripts/cocci-macro-file.h --in-place --no-show-diff \
+//  blockdev-nbd.c qemu-nbd.c {block/nbd*,nbd/*,include/block/nbd*}.[hc]
+
+@@
+// Add invocation to errp-functions where necessary
+// We should skip functions with "Error *const *errp"
+// parameter, but how to do it with coccinelle?
+// I don't know, so, I skip them by function name regex.
+// It's safe: if we not skip some functions with
+// "Error *const *errp", ERRP_AUTO_PROPAGATE invocation
+// will fail to compile, because of const violation.
+identifier fn !~ "error_append_.*_hint";
+identifier local_err, errp;
+@@
+
+ fn(..., Error **errp, ...)
+ {
++   ERRP_AUTO_PROPAGATE();
+<+...
+when != ERRP_AUTO_PROPAGATE();
+(
+error_append_hint(errp, ...);
+|
+error_prepend(errp, ...);
+|
+Error *local_err = NULL;
+)
+...+>
+ }
+
+@rule1@
+// We do not inherit from previous rule, as we want to match
+// also functions, which already had ERRP_AUTO_PROPAGATE
+// invocation.
+identifier fn !~ "error_append_.*_hint";
+identifier local_err, errp;
+@@
+
+ fn(..., Error **errp, ...)
+ {
+ <...
+-Error *local_err = NULL;
+ ...>
+ }
+
+@@
+// Handle pattern with goto, otherwise we'll finish up
+// with labels at function end which will not compile.
+identifier rule1.fn, rule1.local_err, rule1.errp;
+identifier OUT;
+@@
+
+ fn(...)
+ {
+ <...
+-goto OUT;
++return;
+ ...>
+- OUT:
+-error_propagate(errp, local_err);
+ }
+
+@@
+identifier rule1.fn, rule1.local_err, rule1.errp;
+expression list args; // to reindent error_propagate_prepend
+@@
+
+ fn(...)
+ {
+ <...
+(
+-error_free(local_err);
+-local_err = NULL;
++error_free_errp(errp);
+|
+-error_free(local_err);
++error_free_errp(errp);
+|
+-error_report_err(local_err);
++error_report_errp(errp);
+|
+-warn_report_err(local_err);
++warn_report_errp(errp);
+|
+-error_propagate_prepend(errp, local_err, args);
++error_prepend(errp, args);
+|
+-error_propagate(errp, local_err);
+)
+ ...>
+ }
+
+@@
+identifier rule1.fn, rule1.local_err, rule1.errp;
+@@
+
+ fn(...)
+ {
+ <...
+(
+-_err
++errp
+|
+-local_err
++*errp
+)
+ ...>
+ }
+
+@@
+identifier rule1.fn, rule1.errp;
+@@
+
+ fn(...)
+ {
+ <...
+- *errp != NULL
++ *errp
+ ...>
+ }
-- 
2.21.0


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

[Xen-devel] [PATCH v6 00/11] error: auto propagated local_err part I

[Vladimir Sementsov-Ogievskiy]

Hi all!

Now, when preparations from
 [RFC v5 000/126] error: auto propagated local_err
 https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg02771.html
 https://src.openvz.org/scm/~vsementsov/qemu.git #tag up-auto-local-err-v5 
, after some iterations, are finally merged, let's proceed with the
rest. Sorry for a big delay on my part.

As a first step, I decided to take subsystems, each of them covered by
one patch, which get r-b/a-b marks by maintainer of the subsystem in v5.

v6 is available at
 https://src.openvz.org/scm/~vsementsov/qemu.git #tag 
up-auto-local-err-partI-v6 

Changes v5->v6:
01: use errp name for the parameter, add assertion
02: add a lot of text information, drop Eric's r-b.
no semantic changes.
03: add more comments
skip functions with pattern error_append_.*_hint in name
make errp identifier, to match any name of Error ** paramter
some other improvements
04: only commit message changed,
keep Philippe's r-b
05: new, manual update for hw/sd/ssi-sd
06: only commit message changed,
keep Philippe's r-b
07: only commit message changed,
keep Philippe's r-b
08: local_parse_opts() changed, so patch changed in this
function, drop a-b mark
also, indentation fixed, by improvement in coccinelle script
09: only commit message changed,
keep Stefan's r-b
10: commit message and a bit of context changed, still seems
valid to keep Eric's r-b
11: add new hunk: hw/pci-host/xen_igd_pt.c, so, drop r-b
also, indentation fixed, by improvement in coccinelle script

In these series, there is no commit-per-subsystem script, each generated
commit is generated in separate.

Still, generating commands are very similar, and looks like

sed -n '/^$/,/^$/{s/^F: //p}' MAINTAINERS | \
xargs git ls-files | grep '\.[hc]$' | \
xargs spatch \
--sp-file scripts/coccinelle/auto-propagated-errp.cocci \
--macro-file scripts/cocci-macro-file.h \
--in-place --no-show-diff --max-width 80

Note, that in each generated commit, generation command is the only
text, indented by 8 spaces in 'git log -1' output, so, to regenerate all
commits (for example, after rebase, or change in coccinelle script), you
may use the following command:

git rebase -x "sh -c \"git show --pretty= --name-only | xargs git checkout 
HEAD^ -- ; git reset; git log -1 | grep '^' | sh\"" HEAD~7

Which will start automated interactive rebase for generated patches,
which will stop if generated patch changed
(you may do git commit --amend to apply updated generated changes).

Note:
  git show --pretty= --name-only   - lists files, changed in HEAD
  git log -1 | grep '^' | sh   - rerun generation command of HEAD


Check for compilation of changed .c files
git rebase -x "sh -c \"git show --pretty= --name-only | sed -n 's/\.c$/.o/p' | 
xargs make -j9\"" HEAD~7
  

Vladimir Sementsov-Ogievskiy (11):
  qapi/error: add (Error **errp) cleaning APIs
  error: auto propagated local_err
  scripts: add coccinelle script to use auto propagated errp
  hw/sd/ssi-sd: fix error handling in ssi_sd_realize
  SD (Secure Card): introduce ERRP_AUTO_PROPAGATE
  pflash: introduce ERRP_AUTO_PROPAGATE
  fw_cfg: introduce ERRP_AUTO_PROPAGATE
  virtio-9p: introduce ERRP_AUTO_PROPAGATE
  TPM: introduce ERRP_AUTO_PROPAGATE
  nbd: introduce ERRP_AUTO_PROPAGATE
  xen: introduce ERRP_AUTO_PROPAGATE

 include/block/nbd.h   |   1 +
 include/qapi/error.h  | 113 +-
 block/nbd.c   |  49 +++---
 hw/9pfs/9p-local.c|  12 +-
 hw/9pfs/9p.c  |   1 +
 hw/block/dataplane/xen-block.c|  17 +--
 hw/block/pflash_cfi01.c   |   7 +-
 hw/block/pflash_cfi02.c   |   7 +-
 hw/block/xen-block.c  | 125 +++-
 hw/nvram/fw_cfg.c |  14 +-
 hw/pci-host/xen_igd_pt.c  |   7 +-
 hw/sd/sdhci-pci.c |   7 +-
 hw/sd/sdhci.c |  21 ++-
 hw/sd/ssi-sd.c|  26 +++-
 hw/tpm/tpm_util.c |   7 +-
 hw/xen/xen-backend.c  |   7 +-
 hw/xen/xen-bus.c  | 100 ++---
 hw/xen/xen-host-pci-device.c  |  27 ++--
 hw/xen/xen_pt.c   |  25 ++--
 hw/xen/xen_pt_config_init.c   |  20 +--
 nbd/client.c  |   5 +
 nbd/server.c  |   5 +
 tpm.c |   7 +-
 scripts/coccinelle/auto-propagated-errp.cocci | 139 ++
 24 files changed, 482 insertions(+), 267 deletions(-)
 create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci

CC: Cornelia Huck 
CC: Eric Blake 
CC: Kevin Wolf 
CC: Max Reitz 
CC: Greg Kurz 
CC: Stefan 

[Xen-devel] [PATCH v6 01/11] qapi/error: add (Error **errp) cleaning APIs

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

CC: Cornelia Huck 
CC: Eric Blake 
CC: Kevin Wolf 
CC: Max Reitz 
CC: Greg Kurz 
CC: Stefan Hajnoczi 
CC: Stefano Stabellini 
CC: Anthony Perard 
CC: Paul Durrant 
CC: "Philippe Mathieu-Daudé" 
CC: Laszlo Ersek 
CC: Gerd Hoffmann 
CC: Stefan Berger 
CC: Markus Armbruster 
CC: Michael Roth 
CC: qemu-bl...@nongnu.org
CC: xen-devel@lists.xenproject.org

 include/qapi/error.h | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/include/qapi/error.h b/include/qapi/error.h
index ad5b6e896d..fa8d51fd6d 100644
--- a/include/qapi/error.h
+++ b/include/qapi/error.h
@@ -309,6 +309,32 @@ void warn_reportf_err(Error *err, const char *fmt, ...)
 void error_reportf_err(Error *err, const char *fmt, ...)
 GCC_FMT_ATTR(2, 3);
 
+/*
+ * Functions to clean Error **errp: call corresponding Error *err cleaning
+ * function an set pointer to NULL
+ */
+static inline void error_free_errp(Error **errp)
+{
+assert(errp && *errp);
+error_free(*errp);
+*errp = NULL;
+}
+
+static inline void error_report_errp(Error **errp)
+{
+assert(errp && *errp);
+error_report_err(*errp);
+*errp = NULL;
+}
+
+static inline void warn_report_errp(Error **errp)
+{
+assert(errp && *errp);
+warn_report_err(*errp);
+*errp = NULL;
+}
+
+
 /*
  * Just like error_setg(), except you get to specify the error class.
  * Note: use of error classes other than ERROR_CLASS_GENERIC_ERROR is
-- 
2.21.0


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

[Xen-devel] [PATCH v6 02/11] error: auto propagated local_err

[Vladimir Sementsov-Ogievskiy]

Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with errp OUT parameter.

It has three goals:

1. Fix issue with error_fatal & error_prepend/error_append_hint: user
can't see this additional information, because exit() happens in
error_setg earlier than information is added. [Reported by Greg Kurz]

2. Fix issue with error_abort & error_propagate: when we wrap
error_abort by local_err+error_propagate, resulting coredump will
refer to error_propagate and not to the place where error happened.
(the macro itself doesn't fix the issue, but it allows to [3.] drop all
local_err+error_propagate pattern, which will definitely fix the issue)
[Reported by Kevin Wolf]

3. Drop local_err+error_propagate pattern, which is used to workaround
void functions with errp parameter, when caller wants to know resulting
status. (Note: actually these functions could be merely updated to
return int error code).

To achieve these goals, we need to add invocation of the macro at start
of functions, which needs error_prepend/error_append_hint (1.); add
invocation of the macro at start of functions which do
local_err+error_propagate scenario the check errors, drop local errors
from them and just use *errp instead (2., 3.).

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

CC: Cornelia Huck 
CC: Eric Blake 
CC: Kevin Wolf 
CC: Max Reitz 
CC: Greg Kurz 
CC: Stefan Hajnoczi 
CC: Stefano Stabellini 
CC: Anthony Perard 
CC: Paul Durrant 
CC: "Philippe Mathieu-Daudé" 
CC: Laszlo Ersek 
CC: Gerd Hoffmann 
CC: Stefan Berger 
CC: Markus Armbruster 
CC: Michael Roth 
CC: qemu-bl...@nongnu.org
CC: xen-devel@lists.xenproject.org

 include/qapi/error.h | 84 +++-
 1 file changed, 83 insertions(+), 1 deletion(-)

diff --git a/include/qapi/error.h b/include/qapi/error.h
index fa8d51fd6d..532b9afb9e 100644
--- a/include/qapi/error.h
+++ b/include/qapi/error.h
@@ -78,7 +78,7 @@
  * Call a function treating errors as fatal:
  * foo(arg, _fatal);
  *
- * Receive an error and pass it on to the caller:
+ * Receive an error and pass it on to the caller (DEPRECATED*):
  * Error *err = NULL;
  * foo(arg, );
  * if (err) {
@@ -98,6 +98,50 @@
  * foo(arg, errp);
  * for readability.
  *
+ * DEPRECATED* This pattern is deprecated now, use ERRP_AUTO_PROPAGATE macro
+ * instead (defined below).
+ * It's deprecated because of two things:
+ *
+ * 1. Issue with error_abort & error_propagate: when we wrap error_abort by
+ * local_err+error_propagate, resulting coredump will refer to error_propagate
+ * and not to the place where error happened.
+ *
+ * 2. A lot of extra code of the same pattern
+ *
+ * How to update old code to use ERRP_AUTO_PROPAGATE?
+ *
+ * All you need is to add ERRP_AUTO_PROPAGATE() invocation at function start,
+ * than you may safely dereference errp to check errors and do not need any
+ * additional local Error variables or calls to error_propagate().
+ *
+ * Example:
+ *
+ * old code
+ *
+ * void fn(..., Error **errp) {
+ * Error *err = NULL;
+ * foo(arg, );
+ * if (err) {
+ * handle the error...
+ * error_propagate(errp, err);
+ * return;
+ * }
+ * ...
+ * }
+ *
+ * updated code
+ *
+ * void fn(..., Error **errp) {
+ * ERRP_AUTO_PROPAGATE();
+ * foo(arg, errp);
+ * if (*errp) {
+ * handle the error...
+ * return;
+ * }
+ * ...
+ * }
+ *
+ *
  * Receive and accumulate multiple errors (first one wins):
  * Error *err = NULL, *local_err = NULL;
  * foo(arg, );
@@ -348,6 +392,44 @@ void error_set_internal(Error **errp,
 ErrorClass err_class, const char *fmt, ...)
 GCC_FMT_ATTR(6, 7);
 
+typedef struct ErrorPropagator {
+Error *local_err;
+Error **errp;
+} ErrorPropagator;
+
+static inline void error_propagator_cleanup(ErrorPropagator *prop)
+{
+error_propagate(prop->errp, prop->local_err);
+}
+
+G_DEFINE_AUTO_CLEANUP_CLEAR_FUNC(ErrorPropagator, error_propagator_cleanup);
+
+/*
+ * ERRP_AUTO_PROPAGATE
+ *
+ * This macro is created to be the first line of a function which use
+ * Error **errp parameter to report error. It's needed only in cases where we
+ * want to use error_prepend, error_append_hint or dereference *errp. It's
+ * still safe (but useless) in other cases.
+ *
+ * If errp is NULL or points to error_fatal, it is rewritten to point to a
+ * local Error object, which will be automatically propagated to the original
+ * errp on function exit (see error_propagator_cleanup).
+ *
+ * After invocation of this macro it is always safe to dereference errp
+ * (as it's not NULL anymore) and to add information (by error_prepend or
+ * error_append_hint)
+ * (as, if it was error_fatal, we swapped it with a local_error to be
+ * propagated on cleanup).
+ *
+ * Note: we don't wrap the error_abort case, as we want resulting coredump
+ * to point to the 

[Xen-devel] [PATCH v6 11/11] xen: introduce ERRP_AUTO_PROPAGATE

[Vladimir Sementsov-Ogievskiy]

If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _fatal
(the program will exit prior to the error_append_hint() or
error_prepend() call).  Fix such cases.

If we want to check error after errp-function call, we need to
introduce local_err and then propagate it to errp. Instead, use
ERRP_AUTO_PROPAGATE macro, benefits are:
1. No need of explicit error_propagate call
2. No need of explicit local_err variable: use errp directly
3. ERRP_AUTO_PROPAGATE leaves errp as is if it's not NULL or
   _fatal, this means that we don't break error_abort
   (we'll abort on error_set, not on error_propagate)

This commit is generated by command

sed -n '/^X86 Xen CPUs$/,/^$/{s/^F: //p}' MAINTAINERS | \
xargs git ls-files | grep '\.[hc]$' | \
xargs spatch \
--sp-file scripts/coccinelle/auto-propagated-errp.cocci \
--macro-file scripts/cocci-macro-file.h \
--in-place --no-show-diff --max-width 80

Reported-by: Kevin Wolf 
Reported-by: Greg Kurz 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 hw/block/dataplane/xen-block.c |  17 ++---
 hw/block/xen-block.c   | 125 ++---
 hw/pci-host/xen_igd_pt.c   |   7 +-
 hw/xen/xen-backend.c   |   7 +-
 hw/xen/xen-bus.c   | 100 --
 hw/xen/xen-host-pci-device.c   |  27 ---
 hw/xen/xen_pt.c|  25 +++
 hw/xen/xen_pt_config_init.c|  20 +++---
 8 files changed, 142 insertions(+), 186 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index 3b9caeb2fa..c38e3c3d85 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -727,8 +727,8 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane,
unsigned int protocol,
Error **errp)
 {
+ERRP_AUTO_PROPAGATE();
 XenDevice *xendev = dataplane->xendev;
-Error *local_err = NULL;
 unsigned int ring_size;
 unsigned int i;
 
@@ -764,9 +764,8 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane,
 }
 
 xen_device_set_max_grant_refs(xendev, dataplane->nr_ring_ref,
-  _err);
-if (local_err) {
-error_propagate(errp, local_err);
+  errp);
+if (*errp) {
 goto stop;
 }
 
@@ -774,9 +773,8 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane,
   dataplane->ring_ref,
   dataplane->nr_ring_ref,
   PROT_READ | PROT_WRITE,
-  _err);
-if (local_err) {
-error_propagate(errp, local_err);
+  errp);
+if (*errp) {
 goto stop;
 }
 
@@ -809,9 +807,8 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane,
 dataplane->event_channel =
 xen_device_bind_event_channel(xendev, dataplane->ctx, event_channel,
   xen_block_dataplane_event, dataplane,
-  _err);
-if (local_err) {
-error_propagate(errp, local_err);
+  errp);
+if (*errp) {
 goto stop;
 }
 
diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 879fc310a4..70428f5a79 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -194,6 +194,7 @@ static const BlockDevOps xen_block_dev_ops = {
 
 static void xen_block_realize(XenDevice *xendev, Error **errp)
 {
+ERRP_AUTO_PROPAGATE();
 XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
 XenBlockDeviceClass *blockdev_class =
 XEN_BLOCK_DEVICE_GET_CLASS(xendev);
@@ -201,7 +202,6 @@ static void xen_block_realize(XenDevice *xendev, Error 
**errp)
 XenBlockVdev *vdev = >props.vdev;
 BlockConf *conf = >props.conf;
 BlockBackend *blk = conf->blk;
-Error *local_err = NULL;
 
 if (vdev->type == XEN_BLOCK_VDEV_TYPE_INVALID) {
 error_setg(errp, "vdev property not set");
@@ -211,9 +211,8 @@ static void xen_block_realize(XenDevice *xendev, Error 
**errp)
 trace_xen_block_realize(type, vdev->disk, vdev->partition);
 
 if (blockdev_class->realize) {
-blockdev_class->realize(blockdev, _err);
-if (local_err) {
-error_propagate(errp, local_err);
+blockdev_class->realize(blockdev, errp);
+if (*errp) {
 return;
 }
 }
@@ -283,8 +282,8 @@ static void xen_block_frontend_changed(XenDevice *xendev,
enum xenbus_state frontend_state,
Error **errp)
 {
+ERRP_AUTO_PROPAGATE();
 enum xenbus_state backend_state = xen_device_backend_get_state(xendev);
-

Re: [Xen-devel] [RFC PATCH V2 09/11] xen: Clear IRQD_IRQ_STARTED flag during shutdown PIRQs

[Thomas Gleixner]

Anchal,

Anchal Agarwal  writes:
> On Thu, Jan 09, 2020 at 01:07:27PM +0100, Thomas Gleixner wrote:
>> Anchal Agarwal  writes:
>> So either you can handle it purely on the XEN side without touching any
>> core state or you need to come up with some way of letting the core code
>> know that it should invoke shutdown instead of disable.
>> 
>> Something like the completely untested patch below.
>
> Understandable. Really appreciate the patch suggestion below and i will test 
> it
> for sure and see if things can be fixed properly in irq core if thats the only
> option. In the meanwhile, I tried to fix it on xen side unless it gives you 
> the 
> same feeling as above? MSI-x are just fine, just ioapic ones don't get any 
> event
> channel asssigned hence enable_dynirq does nothing. Those needs to be 
> restarted.
>
> diff --git a/drivers/xen/events/events_base.c 
> b/drivers/xen/events/events_base.c
> index 1bb0b522d004..2ed152f35816 100644
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -575,6 +575,11 @@ static void shutdown_pirq(struct irq_data *data)
>
> static void enable_pirq(struct irq_data *data)
> {
> +/*ioapic interrupts don't get event channel assigned
>+ * after being explicitly shutdown during guest
>+ * hibernation. They need to be restarted*/
> +   if(!evtchn_from_irq(data->irq))
> +   startup_pirq(data);
> enable_dynirq(data);
>  }

Interesting patch format :)

Doing the shutdown from syscore_ops and the startup conditionally in a
totaly unrelated function is not really intuitive.

So either you do it symmetrically in XEN via syscore_ops callbacks or
you let the irq core code help you out with the patch I provided

Thanks,

tglx

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

[Xen-devel] [ovmf test] 145935: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
145767
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767

version targeted for testing:
 ovmf 9d1c9d0379d065ca11bc3354faee2c742e89c005
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z2 days
Failing since145774  2020-01-08 02:50:20 Z2 days   14 attempts
Testing same since   145926  2020-01-10 12:09:33 Z0 days2 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ashish Singhal 
  Eric Dong 
  Jason Voelz 
  Laszlo Ersek 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 
  Vitaly Cheptsov 
  Vitaly Cheptsov via Groups.Io 

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.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

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

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

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


Not pushing.

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

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

[Xen-devel] [qemu-mainline test] 145939: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 144861
 build-arm64   6 xen-buildfail REGR. vs. 144861
 build-amd64   6 xen-buildfail REGR. vs. 144861
 build-i386-xsm6 xen-buildfail REGR. vs. 144861
 build-armhf   6 xen-buildfail REGR. vs. 144861
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144861
 build-i3866 xen-buildfail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 

Re: [Xen-devel] [PATCH 2/2] Remove undocumented and unmaintained tools/memshr library

[Tamas K Lengyel]

On Fri, Jan 10, 2020 at 10:59 AM Andrew Cooper
 wrote:
>
> On 10/01/2020 02:30, Tamas K Lengyel wrote:
> > The library has been largely untouched for over a decade at this point, it 
> > is
> > undocumented and it's unclear what it was originally used for. Remove it 
> > from
> > tree, if anyone needs it in the future it can be carved out from git 
> > history.
> >
> > Signed-off-by: Tamas K Lengyel 
>
> Hmm - this is a little awkward.  You remove yourself as maintainer of
> this code, then delete it.
>
> I suspect what you want to do is have patch 1 simply add tools/test
> saying "include other memshr content", and this patch delete
> tools/memshr including the entry in the maintainers file.  (Can be fixed
> up on commit of course, seeing as this is the only issue.)
>
> Overall, I agree with the change, but it will need a tools ack.
>

I was considering just squashing the two patches into one but wasn't
sure if anyone would object to removing dead code (that seems to be
never done). So if there is no objection and the only problem is
"ordering", it would be simpler to just squash the two into one during
commit.

Tamas

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

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

[Julien Grall]

Hi all,

On 08/01/2020 23:14, Julien Grall wrote:

On Wed, 8 Jan 2020 at 21:40, osstest service owner
 wrote:


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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
  test-amd64-amd64-xl-rtds15 guest-saverestore fail in 145773 pass in 145796
  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail in 145773 pass in 145796
  test-armhf-armhf-xl-rtds 12 guest-start  fail in 145773 pass in 145796


It looks like this test has been failing for a while (although not reliably).
I looked at  a few flights, the cause seems to be the same:

Jan  8 15:02:14.700784 (XEN) Assertion '!unit_on_replq(svc)' failed at
sched_rt.c:586
Jan  8 15:02:26.715030 (XEN) [ Xen-4.14-unstable  arm32  debug=y
Not tainted ]
Jan  8 15:02:26.720756 (XEN) CPU:1
Jan  8 15:02:26.722158 (XEN) PC: 0023a750
common/sched_rt.c#replq_insert+0x7c/0xcc
Jan  8 15:02:26.727851 (XEN) CPSR:   200300da MODE:Hypervisor
Jan  8 15:02:26.731334 (XEN)  R0: 002a51a4 R1: 400614a0 R2:
3d64b900 R3: 40061338
Jan  8 15:02:26.736830 (XEN)  R4: 400614a0 R5: 002a51a4 R6:
3cf1cbf0 R7: 01cb
Jan  8 15:02:26.742600 (XEN)  R8: 4003d1b0 R9: 400614a8
R10:4003d1b0 R11:400ffe54 R12:400ffde4
Jan  8 15:02:26.749119 (XEN) HYP: SP: 400ffe2c LR: 0023b6e8
Jan  8 15:02:26.752296 (XEN)
Jan  8 15:02:26.753036 (XEN)   VTCR_EL2: 80003558
Jan  8 15:02:26.755479 (XEN)  VTTBR_EL2: 0002bbff4000
Jan  8 15:02:26.758757 (XEN)
Jan  8 15:02:26.759366 (XEN)  SCTLR_EL2: 30cd187f
Jan  8 15:02:26.761755 (XEN)HCR_EL2: 0078663f
Jan  8 15:02:26.764250 (XEN)  TTBR0_EL2: bc029000
Jan  8 15:02:26.767364 (XEN)
Jan  8 15:02:26.767980 (XEN)ESR_EL2: 
Jan  8 15:02:26.770485 (XEN)  HPFAR_EL2: 00030010
Jan  8 15:02:26.772795 (XEN)  HDFAR: e0800f00
Jan  8 15:02:26.775272 (XEN)  HIFAR: c0605744
Jan  8 15:02:26.48 (XEN)
Jan  8 15:02:26.778505 (XEN) Xen stack trace from sp=400ffe2c:
Jan  8 15:02:26.781910 (XEN) 3cf1cbf0 400614a0 002a51a4
3cf1cbf0 01cb 4003d1b0 6003005a
Jan  8 15:02:26.788991 (XEN)400613f8 400ffe7c 0023b6e8 002f9300
4004c000 400613f8 3cf1cbf0 01cb
Jan  8 15:02:26.796093 (XEN)4003d1b0 6003005a 400613f8 400ffeac
00242988 4004c000 002425ac 40058000
Jan  8 15:02:26.803237 (XEN)4004c000 4004f000 10f45000 10f45008
4004b080 40058000 60030013 400ffebc
Jan  8 15:02:26.810360 (XEN)00209984 0002 4004f000 400ffedc
0020eddc 0020caf8 db097cd4 0020
Jan  8 15:02:26.817504 (XEN)c13afbec  db15fd68 400ffee4
0020c9dc 400fff34 0020d5e8 4004e000
Jan  8 15:02:26.824615 (XEN) 400fff44 400fff44 0002
 4004e8fa 4004e8f4 400fff1c
Jan  8 15:02:26.831737 (XEN)400fff1c 6003005a 0020caf8 400fff58
0020 c13afbec  db15fd68
Jan  8 15:02:26.838798 (XEN)60030013 400fff54 0026c150 c1204d08
c13afbec   
Jan  8 15:02:26.845877 (XEN)0002 400fff58 002753b0 0009
db097cd4 db173008 0002 c1204d08
Jan  8 15:02:26.852986 (XEN) 0002 c13afbec 
db15fd68 60030013 db15fd3c 0020
Jan  8 15:02:26.860044 (XEN) b6cdccb3 c0107ed0 a0030093
4a000ea1 be951568 c136edc0 c010d3a0
Jan  8 15:02:26.867171 (XEN)db097cd0 c056c7f8 c136edcc c010d720
c136edd8 c010d7e0  
Jan  8 15:02:26.874526 (XEN)   c136ede4
c136ede4 00030030 60070193 80030093
Jan  8 15:02:26.881450 (XEN)60030193    0001
Jan  8 15:02:26.886519 (XEN) Xen call trace:
Jan  8 15:02:26.888168 (XEN)[<0023a750>]
common/sched_rt.c#replq_insert+0x7c/0xcc (PC)
Jan  8 15:02:26.894240 (XEN)[<0023b6e8>]
common/sched_rt.c#rt_unit_wake+0xf4/0x274 (LR)
Jan  8 15:02:26.900246 (XEN)[<0023b6e8>]
common/sched_rt.c#rt_unit_wake+0xf4/0x274
Jan  8 15:02:26.905775 (XEN)[<00242988>] vcpu_wake+0x1e4/0x688
Jan  8 15:02:26.909743 (XEN)[<00209984>] domain_unpause+0x64/0x84
Jan  8 15:02:26.913956 (XEN)[<0020eddc>]
common/event_fifo.c#evtchn_fifo_unmask+0xd8/0xf0
Jan  8 15:02:26.920167 (XEN)[<0020c9dc>] evtchn_unmask+0x7c/0xc0
Jan  8 15:02:26.924173 (XEN)[<0020d5e8>] do_event_channel_op+0xaf0/0xdac
Jan  8 15:02:26.928922 (XEN)[<0026c150>] do_trap_guest_sync+0x350/0x4d0
Jan  8 15:02:26.933647 (XEN)[<002753b0>] entry.o#return_from_trap+0/0x4
Jan  8 15:02:26.938299 (XEN)
Jan  8 15:02:26.939039 (XEN)
Jan  8 15:02:26.939668 (XEN) 
Jan  8 15:02:26.943794 (XEN) Panic on CPU 1:
Jan  8 15:02:26.945872 (XEN) Assertion '!unit_on_replq(svc)' failed at
sched_rt.c:586
Jan  8 15:02:26.951492 (XEN) 

I believe the domain_unpause() is coming from guest_clear_bit(). This
would mean the atomics didn't succeed without pausing the domain. This
makes sense as, per the log:

  CPU1: Guest atomics will try 1 times before pausing the domain

Re: [Xen-devel] [PATCH 2/2] Remove undocumented and unmaintained tools/memshr library

[Andrew Cooper]

On 10/01/2020 02:30, Tamas K Lengyel wrote:
> The library has been largely untouched for over a decade at this point, it is
> undocumented and it's unclear what it was originally used for. Remove it from
> tree, if anyone needs it in the future it can be carved out from git history.
>
> Signed-off-by: Tamas K Lengyel 

Hmm - this is a little awkward.  You remove yourself as maintainer of
this code, then delete it.

I suspect what you want to do is have patch 1 simply add tools/test
saying "include other memshr content", and this patch delete
tools/memshr including the entry in the maintainers file.  (Can be fixed
up on commit of course, seeing as this is the only issue.)

Overall, I agree with the change, but it will need a tools ack.

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/2] libxl: Add new "notify-only" childproc mode

[George Dunlap]

On 1/9/20 12:12 PM, George Dunlap wrote:
> libxl needs to be able to know when processes it forks have completed.
> 
> At the moment, libxl has two basic mode (with some variations).  In
> one mode -- libxl_sigchld_owner_libxl* -- libxl sets up its own
> SIGCHLD signal handler, and also handles the event loop that allows
> libxl to safely block until the child in question is finished (using a
> self-pipe for the SIGCHLD handler to notify the waiters that it's time
> to look for reaped children).
> 
> In the other mode, libxl does not set up the SIGCHLD handler, nor does
> it do anything with processing the event loop; it expects the library
> caller to handle the event loop itself.
> 
> The golang runtime manages its own processes, and thus must use
> SIGCHLD itself; and it has an easy way for other users to get SIGCHLD
> notifications.  However, because its event loop is hidden away behind
> abstractions, it's not easy to hook into; and there's no need -- the
> golang runtime assumes that C function calls may block, and handles
> everything behind the scenes.
> 
> Introduce a new mode, libxl_sigchld_owner_notify, in which libxl sets
> up the SIGCHLD event handling machinery, but relies on the caller to
> tell it when a SIGCHLD happens.
> 
> Call these two actions "notify" (for the self-pipe notification
> machinery) and "handler" (for the actual SIGCHLD handler).
> 
> Provide a new external function, libxl_childproc_sigchld_notify(), for
> library users to call when a SIGCHLD happens.  Have this call
> sigchld_handler().
> 
> Rename chldmode_ours() to chldmode_notify(), and use it to determine
> whether to set up the notification chain.
> 
> When setting up the notification chain, do everything except setting
> up the signal handler in "notify-only" mode.
> 
> defer_sigchld() and release_sigchld() do two things: they modify the
> signal handler, and grab and release locks.  Refactor these so that
> they grab and release the locks correctly in "notify-only" mode, but
> don't tweak the signal handler unless it's been set up.
> 
> With the golang bindings ported to use this change, domain creation
> works.
> 
> NB an alternate approach would be to make libxl_sigchld_owner_mainloop
> *always* set up and tear down the self-pipe notification mechanisms,
> and then simply expose libxl_childproc_sigchld_notify().  However,
> this would entail grabbing a libxl-wide global lock (across all libxl
> ctx's) twice on every fork.  This should be avoided for callers which
> don't need it.
> 
> Signed-off-by: George Dunlap 

FAOD, with the fixes in your other series, I consider this patch to now
be moot.

 - George

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

Re: [Xen-devel] [PATCH v2 1/2] libxl: Get rid of some trailing whitespace

[Ian Jackson]

George Dunlap writes ("[PATCH v2 1/2] libxl: Get rid of some trailing 
whitespace"):
> No functional changes.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH] Introduce CHANGELOG.md

[Andrew Cooper]

On 10/01/2020 09:12, Paul Durrant wrote:
> As agreed during the 2020-01 community call [1] this patch introduces a
> changelog, based on the principles explained at keepachangelog.com [2].
> A new MAINTAINERS entry is also added, with myself as (currently sole)
> maintainer.
>
> [1] See C.2 at https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6Htl-AJ/
> [2] https://keepachangelog.com/en/1.0.0/
>
> Signed-off-by: Paul Durrant 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Wei Liu 
> Cc: Lars Kurth 
>
> Should there be other maintainers apart from myself (with my RM hat on)?
> Perhaps Lars should also be added as a designated reviewer?

Ultimately, the committers are last line of judgement on "whether this
change should be in the changelog".  Practically, that includes "The
Rest", but there was an objection to that on the call IIRC.

> ---
>  CHANGELOG.md | 14 ++
>  MAINTAINERS  |  5 +
>  2 files changed, 19 insertions(+)
>  create mode 100644 CHANGELOG.md
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> new file mode 100644
> index 00..ec5e174aa0
> --- /dev/null
> +++ b/CHANGELOG.md
> @@ -0,0 +1,14 @@
> +# Changelog
> +
> +All notable changes to Xen will be documented in this file.
> +
> +The format is based on [Keep a 
> Changelog](https://keepachangelog.com/en/1.0.0/)
> +
> +## [Unreleased](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog)

Has anyone looked over staging to find other noteworthy things?

~Andrew


> +
> +### Added
> + - This file and MAINTAINERS entry.
> +
> +## 
> [4.13.0](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.13.0)
>  - 2019-12-17
> +
> +> Pointer to release from which CHANGELOG tracking starts
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d5bd83073c..68c691361a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -198,6 +198,11 @@ F:   xen/include/asm-arm/
>  F:   xen/include/public/arch-arm/
>  F:   xen/include/public/arch-arm.h
>  
> +Change Log
> +M:   Paul Durrant 
> +S:   Maintained
> +F:   CHANGELOG.md
> +
>  Continuous Integration (CI)
>  M:   Doug Goldstein 
>  W:   https://gitlab.com/xen-project/xen


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

Re: [Xen-devel] [PATCH] tools/Rules.mk: fix distclean

[Ian Jackson]

Paul Durrant writes ("[PATCH] tools/Rules.mk: fix distclean"):
> Running 'make distclean' under tools will currently result in:
> 
> tools/Rules.mk:245: *** You have to run ./configure before building or 
> installing the tools.  Stop.
> 
> This patch adds 'distclean', 'subdir-distclean%' and 'subdir-clean%' to
> no-configure-targets, which allows 'make distclean' to run to completion.

This seems sound to me, even though I think in the case where it makes
a difference, `make distclean' will end up skipping most of the tools
stuff since the makefiles aren't present.

Acked-by: Ian Jackson 

Wei, do you agree with my analysis ?

Ian.

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

Re: [Xen-devel] [PATCH v1 2/4] x86/xen: add basic KASAN support for PV kernel

[kbuild test robot]

Hi Sergey,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net-next/master]
[also build test ERROR on net/master linus/master v5.5-rc5 next-20200109]
[cannot apply to xen-tip/linux-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Sergey-Dyasli/basic-KASAN-support-for-Xen-PV-domains/20200110-042623
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
4a4a52d49d11f5c4a0df8b9806c8c5563801f753
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   arch/x86/xen/mmu_pv.c: In function 'xen_pv_kasan_early_init':
>> arch/x86/xen/mmu_pv.c:1778:16: error: 'kasan_early_shadow_pud' undeclared 
>> (first use in this function); did you mean 'kasan_free_shadow'?
 set_page_prot(kasan_early_shadow_pud, PAGE_KERNEL_RO);
   ^~
   kasan_free_shadow
   arch/x86/xen/mmu_pv.c:1778:16: note: each undeclared identifier is reported 
only once for each function it appears in
>> arch/x86/xen/mmu_pv.c:1779:16: error: 'kasan_early_shadow_pmd' undeclared 
>> (first use in this function); did you mean 'kasan_early_shadow_pud'?
 set_page_prot(kasan_early_shadow_pmd, PAGE_KERNEL_RO);
   ^~
   kasan_early_shadow_pud
>> arch/x86/xen/mmu_pv.c:1780:16: error: 'kasan_early_shadow_pte' undeclared 
>> (first use in this function); did you mean 'kasan_early_shadow_pmd'?
 set_page_prot(kasan_early_shadow_pte, PAGE_KERNEL_RO);
   ^~
   kasan_early_shadow_pmd

vim +1778 arch/x86/xen/mmu_pv.c

  1774  
  1775  pgd_t * __init xen_pv_kasan_early_init(void)
  1776  {
  1777  /* PV page tables must be read-only */
> 1778  set_page_prot(kasan_early_shadow_pud, PAGE_KERNEL_RO);
> 1779  set_page_prot(kasan_early_shadow_pmd, PAGE_KERNEL_RO);
> 1780  set_page_prot(kasan_early_shadow_pte, PAGE_KERNEL_RO);
  1781  
  1782  /* Return a pointer to the initial PV page tables */
  1783  return (pgd_t *)xen_start_info->pt_base;
  1784  }
  1785  

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation


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

Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests

[George Dunlap]

On 1/10/20 4:45 PM, Jürgen Groß wrote:
> On 10.01.20 16:56, Jan Beulich wrote:
>> On 10.01.2020 16:28, George Dunlap wrote:
>>> On 1/10/20 11:02 AM, Andrew Cooper wrote:
 On 10/01/2020 10:37, Sergey Dyasli wrote:
> Hide the following information that can help identify the running Xen
> binary version: XENVER_extraversion, XENVER_compile_info,
> XENVER_changeset.
> Add explicit cases for XENVER_commandline and XENVER_build_id as well.
>
> Introduce xsm_filter_denied() to hvmloader to remove "" string
> from guest's DMI tables that otherwise would be shown in tools like
> dmidecode.
>
> Signed-off-by: Sergey Dyasli 
> ---
> v1 --> v2:
> - Added xsm_filter_denied() to hvmloader instead of modifying
> xen_deny()
> - Made behaviour the same for both Release and Debug builds
> - XENVER_capabilities is no longer hided
>
> CC: Andrew Cooper 
> CC: George Dunlap 
> CC: Ian Jackson 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Wei Liu 
> CC: Daniel De Graaf 

 I realise there are arguments over how to fix this, but we (the Xen
 community) have already f*cked up once here, and this is doing so a
 second time.

 Nack.

 Fixing it anywhere other than Xen is simply not appropriate.
>>
>> (replying here, because the original mail doesn't seem to have
>> made it into my inbox)
>>
>> I've said so to Sergey already on v1: The "fix" you want needs to
>> be at or closer to the presentation layer. From Xen's perspective
>> the request for information was _indeed_ denied.
>>
 The reason for this (which ought to be obvious, but I guess only to
 those who actually do customer support) is basic human physiology.
 "denied" means something has gone wrong.  It scares people, and causes
 them to seek help to change fix whatever is broken.
>>>
>>> This seems like a reasonable argument that "" causes issues.
>>> But that doesn't change the fact that "" also causes issues.
>>>
>>> What about changing the string to "" or something like
>>> that?  That makes it more clear what would have been in that place, and
>>> "hidden" is a lot less scary than "denied".
>>
>> I could live with this. But (judging from the picture that was
>> provided earlier on) it would still require filtering at or close
>> to the presentation layer, and by changing the prior  to
>> different and varying strings may make that job harder (albeit
>> perhaps they could look for any <...>).
> 
> I'd go with "" or "". "" as value for the
> build-id is similar to "LCD-display". And it will certainly not be the
> correct value for other hidden items. :-)

The idea is that in a log, if you see a buildid in context, you can
usually figure out what it is just by looking at it; i.e..:

Xen 4.13.1 8a2a24f4e1

So which is better?

1. Xen 4.13.1

2. Xen 4.13.1 

3 Xen 4.13.1 

4 Xen 4.13.1 

I don't like 1 or 4.  I could live with 2 I guess.

 -George

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

Re: [Xen-devel] [PATCH v2 4/4] x86/boot: Drop INVALID_VCPU

[Jan Beulich]

On 09.01.2020 20:32, Andrew Cooper wrote:
> Now that NULL will fault at boot, there is no need for a special constant to
> signify "current not set up yet".
> 
> Since c/s fae249d23413 "x86/boot: Rationalise stack handling during early
> boot", the BSP cpu_info block is now consistently zero, so drop the adjacent
> re-zeroing.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH v2 2/4] x86/boot: Clean up l?_bootmap[] construction

[Jan Beulich]

On 09.01.2020 20:32, Andrew Cooper wrote:
> The need for Xen to be identity mapped into the bootmap is not obvious, and
> differs between the MB and EFI boot paths.
> 
> The EFI side is further complicated by an attempt to cope with with l2_bootmap
> only being 4k long.  This is undocumented, confusing, only works if Xen is the
> single object wanting mapping.
> 
> The pageables are common to both the MB and EFI builds, so simplify the EFI
> bootmap construction code to make exactly one identity-map of Xen, which now
> makes the two paths consistent.  Comment both pieces of logic, explaining what
> the mappings are needed for.
> 
> Finally, leave a linker assert covering the fact that plenty of code blindly
> assumes that Xen is less that 16M.  This wants fixing in due course.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests

[Jürgen Groß]

On 10.01.20 16:56, Jan Beulich wrote:

On 10.01.2020 16:28, George Dunlap wrote:

On 1/10/20 11:02 AM, Andrew Cooper wrote:

On 10/01/2020 10:37, Sergey Dyasli wrote:

Hide the following information that can help identify the running Xen
binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
Add explicit cases for XENVER_commandline and XENVER_build_id as well.

Introduce xsm_filter_denied() to hvmloader to remove "" string
from guest's DMI tables that otherwise would be shown in tools like
dmidecode.

Signed-off-by: Sergey Dyasli 
---
v1 --> v2:
- Added xsm_filter_denied() to hvmloader instead of modifying xen_deny()
- Made behaviour the same for both Release and Debug builds
- XENVER_capabilities is no longer hided

CC: Andrew Cooper 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Julien Grall 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Wei Liu 
CC: Daniel De Graaf 


I realise there are arguments over how to fix this, but we (the Xen
community) have already f*cked up once here, and this is doing so a
second time.

Nack.

Fixing it anywhere other than Xen is simply not appropriate.


(replying here, because the original mail doesn't seem to have
made it into my inbox)

I've said so to Sergey already on v1: The "fix" you want needs to
be at or closer to the presentation layer. From Xen's perspective
the request for information was _indeed_ denied.


The reason for this (which ought to be obvious, but I guess only to
those who actually do customer support) is basic human physiology.
"denied" means something has gone wrong.  It scares people, and causes
them to seek help to change fix whatever is broken.


This seems like a reasonable argument that "" causes issues.
But that doesn't change the fact that "" also causes issues.

What about changing the string to "" or something like
that?  That makes it more clear what would have been in that place, and
"hidden" is a lot less scary than "denied".


I could live with this. But (judging from the picture that was
provided earlier on) it would still require filtering at or close
to the presentation layer, and by changing the prior  to
different and varying strings may make that job harder (albeit
perhaps they could look for any <...>).


I'd go with "" or "". "" as value for the
build-id is similar to "LCD-display". And it will certainly not be the
correct value for other hidden items. :-)


Juergen

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

Re: [Xen-devel] [BUG] scripts/add_maintainers.pl adding empty Cc: lines

[Lars Kurth]

On 08/01/2020, 16:52, "Jürgen Groß"  wrote:

Just had a chat with Lars on IRC, which might be of common
interest (and Lars asked me to post it to xen-devel):

(17:00:16) juergen_gross: lars_kurth: any idea why 
./scripts/add_maintainers.pl would add a "Cc:" without a mail address to 
a patch? Happened e.g. in my series "[PATCH v2 0/9] xen: scheduler 
cleanups" (cover-letter, patches 1, 2, 7 and 9)
(17:01:58) lars_kurth: juergen_gross: oh, an actual bug! Let me look at 
the code
(17:02:19) lars_kurth: juergen_gross:  is it missing some e-mails?
(17:02:34) juergen_gross: git send-email seems to remove those empty Cc: 
lines
(17:02:53) juergen_gross: I'm not aware of a mail address missing. Let 
me double check
(17:06:56) juergen_gross: lars_kurth: hmm, shouldn't the MAINTAINERS 
entry "L:  DornerWorks Xen-Devel " result 
in a Cc:?
(17:08:17) lars_kurth: Let me have a look
(17:13:16) juergen_gross: lars_kurth: at least the related file is 
touched exactly by the affected patches (and not by any not affected patch)
(17:13:36) lars_kurth: Looking at the series the most likely cause of 
this is the L: entry - need to look at the code
(17:15:21) lars_kurth: juergen_gross: it's also an odd one because it 
changes MAINTAINERS and renames a lot of files, which may be the cause 
for the empty spaces
(17:15:52) juergen_gross: lars_kurth: in Linux MAINTAINERS all "L:" 
entries just have a mail address as first word after the "L:" (not "bla 
bla ")
(17:16:11) lars_kurth: Ah yes: let me look at that code
(17:21:29) lars_kurth: juergen_gross: I think that is in fact the issue
(17:27:16) lars_kurth: juergen_gross: I can't fix this with some 
debugging. Could you copy this conversation into a mail on xen-devel@ 
such that I remember
(17:27:43) lars_kurth: uergen_gross: with=without
(17:29:36) lars_kurth:  juergen_gross: I think what happens is that 
get_maintainer.pl and add_maintainer.pl process these lines differently, 
but add_maintainer.pl also checks against output created from 
get_maintainer.pl
(17:44:58) juergen_gross: lars_kurth: what about doing it the easy way? 
With a modifed MAINTAINERS file (using "L: xen-de...@dornerworks.com") 
everything is fine. I can send a patch in case you agree.
(17:46:41) lars_kurth: juergen_gross: let's do that first, but I still 
would like to fix the underlying issue at some point - asking for you to 
send the IRC log, as I cleared my history by mistake (when I was typing 
a reply I slipped from shift to ctrl, which did it)


For my own reference, the issue is somewhere in get_maintainer.pl, not in 
add_maintainers.pl

In a nutshell, a line such as
L: foo bar  in MAINTAINERS

Will produce an empty line when executing sth like ./scripts/get_maintainer.pl 
< ../patches/test/0001-Add-test-case.patch

In the test case I used, I use
L: xxx yyy  in MAINTAINERS
and get
Andrew Cooper 
...
Wei Liu 

xen-devel@lists.xenproject.org

When I use
L: x...@lists.xenproject.org in MAINTAINERS
I get
Andrew Cooper 
...
Wei Liu 
x...@lists.xenproject.org
xen-devel@lists.xenproject.org

Need to investigate further
Lars

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

Re: [Xen-devel] [PATCH v2 1/4] x86/boot: Remove the preconstructed low 16M superpage mappings

[Jan Beulich]

On 09.01.2020 20:32, Andrew Cooper wrote:
> These are left over from c/s b2804422 "x86: make Xen early boot code
> relocatable", which made it possible for Xen not to be in the bottom 16M.
> 
> Nothing using the mappings any more.  Build them in the directmap when walking
> the E820 table along with everything else.
> 
> Furthermore, it is undefined to have superpages and MTRRs disagree on
> cacheability boundaries, and nothing actually checks.  While we don't fix this
> explicitly, we do at least honour the E820 now if it says there are boundaries
> in this range.
> 
> As a consequence, there are now no _PAGE_PRESENT entries between
> __page_tables_{start,end} which need to skip relocation.  This simplifies the
> MB1/2 entry path logic to remove the l2_identmap[] special case.
> 
> The low 2M (using 4k pages) is retained for now.  Amongst other things, it
> matters for console logging while the legacy VGA hole is in use.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH V7 4/4] x86/mm: Make use of the default access param from xc_altp2m_create_view

[Jan Beulich]

On 08.01.2020 15:08, Alexandru Stefan ISAILA wrote:
> At this moment the default_access param from xc_altp2m_create_view is
> not used.
> 
> This patch assigns default_access to p2m->default_access at the time of
> initializing a new altp2m view.
> 
> Signed-off-by: Alexandru Isaila 

The tiny parts this applies to:
Acked-by: Jan Beulich 

Jan

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

[Xen-devel] [qemu-mainline test] 145934: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 144861
 build-arm64   6 xen-buildfail REGR. vs. 144861
 build-amd64   6 xen-buildfail REGR. vs. 144861
 build-i386-xsm6 xen-buildfail REGR. vs. 144861
 build-armhf   6 xen-buildfail REGR. vs. 144861
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144861
 build-i3866 xen-buildfail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 

Re: [Xen-devel] [PATCH V7 2/4] x86/altp2m: Add hypercall to set a range of sve bits

[Jan Beulich]

On 08.01.2020 15:08, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve bits.
> The core function, p2m_set_suppress_ve_multi(), does not break in case
> of a error and it is doing a best effort for setting the bits in the
> given range. A check for continuation is made in order to have
> preemption on large ranges.
> The gfn of the first error is stored in
> xen_hvm_altp2m_suppress_ve_multi.first_error and the error code is
> stored in xen_hvm_altp2m_suppress_ve_multi.first_error_code.
> If no error occurred the values will be 0.

These last two sentences must have been stale for a while. IOW ...

> Changes since V6:
>   - Fix commit message

... has this really happened?

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -3030,45 +3030,87 @@ out:
>   */
>  int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, bool suppress_ve,
>  unsigned int altp2m_idx)
> +{
> +int rc;
> +struct xen_hvm_altp2m_suppress_ve_multi sve = {0};
> +
> +sve.view = altp2m_idx;
> +sve.suppress_ve = suppress_ve;
> +sve.first_gfn = gfn_x(gfn);
> +sve.last_gfn = gfn_x(gfn);

Can't all of these move into the initializer, instead of the
somewhat odd 0?

> +if ( !(rc = p2m_set_suppress_ve_multi(d, )) && sve.first_error )
> +rc = sve.first_error;

Why the right side of the && ?

> +/*
> + * Set/clear the #VE suppress bit for multiple pages.  Only available on VMX.
> + */
> +int p2m_set_suppress_ve_multi(struct domain *d,
> +  struct xen_hvm_altp2m_suppress_ve_multi *sve)
>  {
>  struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
>  struct p2m_domain *ap2m = NULL;
> -struct p2m_domain *p2m;
> -mfn_t mfn;
> -p2m_access_t a;
> -p2m_type_t t;
> -int rc;
> +struct p2m_domain *p2m = host_p2m;
> +uint64_t start = sve->first_gfn;
> +int rc = 0;
>  
> -if ( altp2m_idx > 0 )
> +if ( sve->view > 0 )
>  {
> -if ( altp2m_idx >= min(ARRAY_SIZE(d->arch.altp2m_p2m), MAX_EPTP) ||
> - d->arch.altp2m_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] ==
> +if ( sve->view >= min(ARRAY_SIZE(d->arch.altp2m_p2m), MAX_EPTP) ||
> + d->arch.altp2m_eptp[array_index_nospec(sve->view, MAX_EPTP)] ==
>   mfn_x(INVALID_MFN) )
>  return -EINVAL;
>  
> -p2m = ap2m = d->arch.altp2m_p2m[array_index_nospec(altp2m_idx,
> +p2m = ap2m = d->arch.altp2m_p2m[array_index_nospec(sve->view,
>  ARRAY_SIZE(d->arch.altp2m_p2m))];
>  }
> -else
> -p2m = host_p2m;
>  
> -gfn_lock(host_p2m, gfn, 0);
> +p2m_lock(host_p2m);
>  
>  if ( ap2m )
>  p2m_lock(ap2m);
>  
> -rc = altp2m_get_effective_entry(p2m, gfn, , , , AP2MGET_query);
> +while ( sve->last_gfn >= start )
> +{
> +p2m_access_t a;
> +p2m_type_t t;
> +mfn_t mfn;
> +int err = 0;
>  
> -if ( rc )
> -goto out;
> +if ( (err = altp2m_get_effective_entry(p2m, _gfn(start), , , 
> ,
> +   AP2MGET_query)) &&
> + !sve->first_error )
> +{
> +sve->first_error_gfn = start; /* Save the gfn of the first error 
> */
> +sve->first_error = err; /* Save the first error code */
> +}
>  
> -rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, t, a, suppress_ve);
> +if ( !err && (err = p2m->set_entry(p2m, _gfn(start), mfn,
> +   PAGE_ORDER_4K, t, a,
> +   sve->suppress_ve)) &&
> + !sve->first_error )
> +{
> +sve->first_error_gfn = start; /* Save the gfn of the first error 
> */
> +sve->first_error = err; /* Save the first error code */
> +}

I think it would help readability if you didn't do this error
saving twice.

Jan

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

Re: [Xen-devel] [PATCH v2 0/3] x86: improve assisted tlb flush and use it in guest mode

[Roger Pau Monné]

On Fri, Jan 10, 2020 at 05:08:16PM +0100, Jan Beulich wrote:
> On 10.01.2020 17:04, Roger Pau Monne wrote:
> > Patch #2 is likely the most controversial one, as it changes the
> > implementation of assisted TLB flushes. I have to admit I haven't been
> > able to figure out why HVM guest context flushes issued a
> > flush_tlb_mask, and the commit introducing such behavior doesn't contain
> > a helpful commit message.
> 
> A shadow mode thing, maybe?

Hm, I could be wrong, but that flush doesn't seem to make sense for
shadow mode either.

If VPID/ASID is used, ticking it will drop all the guest caches, and
if VPID/ASID not used a vmexit/vmentry will clear the cache.
According to my reading of the Intel SDM this applies regardless of
whether HAP (EPT) is used or not.

The flush done by flush_tlb_mask is in root mode, and hence doesn't
affect the guest (non-root) caches when SVM/VTx is used.

Roger.

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

Re: [Xen-devel] [PATCH V7 1/4] x86/mm: Add array_index_nospec to guest provided index values

[Jan Beulich]

On 08.01.2020 15:08, Alexandru Stefan ISAILA wrote:
> Changes since V6:
>   - Remove stray spaces
>   - Use ARRAY_SIZE(d->arch.altp2m_p2m) insead of MAX_ALTP2M.

I'm not utterly confused:

> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -366,11 +366,13 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn, 
> uint32_t nr,
>  #ifdef CONFIG_HVM
>  if ( altp2m_idx )
>  {
> -if ( altp2m_idx >= MAX_ALTP2M ||
> - d->arch.altp2m_eptp[altp2m_idx] == mfn_x(INVALID_MFN) )
> +if ( altp2m_idx >= min(ARRAY_SIZE(d->arch.altp2m_p2m), MAX_EPTP) ||
> + d->arch.altp2m_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] ==
> + mfn_x(INVALID_MFN) )
>  return -EINVAL;
>  
> -ap2m = d->arch.altp2m_p2m[altp2m_idx];
> +ap2m = d->arch.altp2m_p2m[array_index_nospec(altp2m_idx,
> +  ARRAY_SIZE(d->arch.altp2m_p2m))];

Why is this still not

ap2m = array_access_nospec(d->arch.altp2m_p2m, altp2m_idx);

? What am I missing?

Jan

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

Re: [Xen-devel] [PATCH v2 0/3] x86: improve assisted tlb flush and use it in guest mode

[Jan Beulich]

On 10.01.2020 17:04, Roger Pau Monne wrote:
> Patch #2 is likely the most controversial one, as it changes the
> implementation of assisted TLB flushes. I have to admit I haven't been
> able to figure out why HVM guest context flushes issued a
> flush_tlb_mask, and the commit introducing such behavior doesn't contain
> a helpful commit message.

A shadow mode thing, maybe?

Jan

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

[Xen-devel] [PATCH v2 0/3] x86: improve assisted tlb flush and use it in guest mode

[Roger Pau Monne]

Hello,

The following series aims to improve the TLB flush times when running
nested Xen, and it's specially beneficial when running in shim mode.

Patch #2 is likely the most controversial one, as it changes the
implementation of assisted TLB flushes. I have to admit I haven't been
able to figure out why HVM guest context flushes issued a
flush_tlb_mask, and the commit introducing such behavior doesn't contain
a helpful commit message.

See patch #3 for a comparison on the performance of the L0 assisted
flush vs using x2APIC shorthand.

Thanks, Roger.

Roger Pau Monne (3):
  x86/hvm: allow ASID flush when v != current
  x86/hvm: rework HVMOP_flush_tlbs
  x86/tlb: use Xen L0 assisted TLB flush when available

 xen/arch/x86/guest/hypervisor.c|  9 +
 xen/arch/x86/guest/xen/xen.c   |  6 +++
 xen/arch/x86/hvm/asid.c|  6 +--
 xen/arch/x86/hvm/hvm.c | 54 +++---
 xen/arch/x86/hvm/viridian/viridian.c   |  7 +---
 xen/arch/x86/smp.c |  6 +++
 xen/include/asm-x86/guest/hypervisor.h | 13 +++
 xen/include/asm-x86/hvm/hvm.h  |  2 +-
 8 files changed, 62 insertions(+), 41 deletions(-)

-- 
2.24.1


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

[Xen-devel] [PATCH v2 2/3] x86/hvm: rework HVMOP_flush_tlbs

[Roger Pau Monne]

Current implementation of hvm_flush_vcpu_tlb is highly inefficient.

First of all the call to flush_tlb_mask is completely useless when
trying to flush the TLB of HVM guests, as this TLB flush is executed in
root mode, and hence doesn't flush any guest state cache.

Secondly, calling paging_update_cr3 albeit correct, is much more
expensive than strictly required. Instead a TLB flush can be achieved by
calling hvm_asid_flush_vcpu on each pCPU that has a domain vCPU state
currently loaded. This call will invalidate the current non-root
context, thus forcing a clean cache state on vmentry. If the guest is
not using ASIDs, the vmexit caused by the on_selected_cpus IPI will
already force a TLB flush.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/hvm/hvm.c   | 54 
 xen/arch/x86/hvm/viridian/viridian.c |  7 +---
 xen/include/asm-x86/hvm/hvm.h|  2 +-
 3 files changed, 25 insertions(+), 38 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4723f5d09c..e4fef0afcd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3973,7 +3973,21 @@ static void hvm_s3_resume(struct domain *d)
 }
 }
 
-bool hvm_flush_vcpu_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
+static void do_flush(void *data)
+{
+cpumask_t *mask = data;
+unsigned int cpu = smp_processor_id();
+
+ASSERT(cpumask_test_cpu(cpu, mask));
+/*
+ * A vmexit/vmenter (caused by the IPI issued to execute this function) is
+ * enough to force a TLB flush since we have already ticked the vCPU ASID
+ * prior to issuing the IPI.
+ */
+cpumask_clear_cpu(cpu, mask);
+}
+
+void hvm_flush_vcpu_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
 void *ctxt)
 {
 static DEFINE_PER_CPU(cpumask_t, flush_cpumask);
@@ -3981,27 +3995,8 @@ bool hvm_flush_vcpu_tlb(bool (*flush_vcpu)(void *ctxt, 
struct vcpu *v),
 struct domain *d = current->domain;
 struct vcpu *v;
 
-/* Avoid deadlock if more than one vcpu tries this at the same time. */
-if ( !spin_trylock(>hypercall_deadlock_mutex) )
-return false;
-
-/* Pause all other vcpus. */
-for_each_vcpu ( d, v )
-if ( v != current && flush_vcpu(ctxt, v) )
-vcpu_pause_nosync(v);
-
-/* Now that all VCPUs are signalled to deschedule, we wait... */
-for_each_vcpu ( d, v )
-if ( v != current && flush_vcpu(ctxt, v) )
-while ( !vcpu_runnable(v) && v->is_running )
-cpu_relax();
-
-/* All other vcpus are paused, safe to unlock now. */
-spin_unlock(>hypercall_deadlock_mutex);
-
 cpumask_clear(mask);
 
-/* Flush paging-mode soft state (e.g., va->gfn cache; PAE PDPE cache). */
 for_each_vcpu ( d, v )
 {
 unsigned int cpu;
@@ -4009,22 +4004,17 @@ bool hvm_flush_vcpu_tlb(bool (*flush_vcpu)(void *ctxt, 
struct vcpu *v),
 if ( !flush_vcpu(ctxt, v) )
 continue;
 
-paging_update_cr3(v, false);
+hvm_asid_flush_vcpu(v);
 
 cpu = read_atomic(>dirty_cpu);
-if ( is_vcpu_dirty_cpu(cpu) )
+if ( cpu != smp_processor_id() && is_vcpu_dirty_cpu(cpu) )
 __cpumask_set_cpu(cpu, mask);
 }
 
-/* Flush TLBs on all CPUs with dirty vcpu state. */
-flush_tlb_mask(mask);
+on_selected_cpus(mask, do_flush, mask, 0);
 
-/* Done. */
-for_each_vcpu ( d, v )
-if ( v != current && flush_vcpu(ctxt, v) )
-vcpu_unpause(v);
-
-return true;
+while ( !cpumask_empty(mask) )
+cpu_relax();
 }
 
 static bool always_flush(void *ctxt, struct vcpu *v)
@@ -4037,7 +4027,9 @@ static int hvmop_flush_tlb_all(void)
 if ( !is_hvm_domain(current->domain) )
 return -EINVAL;
 
-return hvm_flush_vcpu_tlb(always_flush, NULL) ? 0 : -ERESTART;
+hvm_flush_vcpu_tlb(always_flush, NULL);
+
+return 0;
 }
 
 static int hvmop_set_evtchn_upcall_vector(
diff --git a/xen/arch/x86/hvm/viridian/viridian.c 
b/xen/arch/x86/hvm/viridian/viridian.c
index 44c8e6cac6..ec73361597 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -604,12 +604,7 @@ int viridian_hypercall(struct cpu_user_regs *regs)
 if ( input_params.flags & HV_FLUSH_ALL_PROCESSORS )
 input_params.vcpu_mask = ~0ul;
 
-/*
- * A false return means that another vcpu is currently trying
- * a similar operation, so back off.
- */
-if ( !hvm_flush_vcpu_tlb(need_flush, _params.vcpu_mask) )
-return HVM_HCALL_preempted;
+hvm_flush_vcpu_tlb(need_flush, _params.vcpu_mask);
 
 output.rep_complete = input.rep_count;
 
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 09793c12e9..1f70ee0823 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -333,7 +333,7 @@ const char *hvm_efer_valid(const struct vcpu *v, uint64_t 
value,
   

[Xen-devel] [PATCH v2 3/3] x86/tlb: use Xen L0 assisted TLB flush when available

[Roger Pau Monne]

Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.

The following figures are from a PV guest running `make -j32 xen` in
shim mode with 32 vCPUs.

Using x2APIC and ALLBUT shorthand:
real4m35.973s
user4m35.110s
sys 36m24.117s

Using L0 assisted flush:
real1m14.206s
user4m31.835s
sys 5m45.013s

The implementation adds a new hook to hypervisor_ops so other
enlightenments can also implement such assisted flush just by filling
the hook. Note that the Xen implementation completely ignores the
dirty CPU mask and the linear address passed in, and always performs a
global TLB flush on all vCPUs.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Add a L0 assisted hook to hypervisor ops.
---
 xen/arch/x86/guest/hypervisor.c|  9 +
 xen/arch/x86/guest/xen/xen.c   |  6 ++
 xen/arch/x86/smp.c |  6 ++
 xen/include/asm-x86/guest/hypervisor.h | 13 +
 4 files changed, 34 insertions(+)

diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index 4f27b98740..c793ba51c2 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -18,6 +18,7 @@
  *
  * Copyright (c) 2019 Microsoft.
  */
+#include 
 #include 
 #include 
 
@@ -64,6 +65,14 @@ void hypervisor_resume(void)
 ops->resume();
 }
 
+int hypervisor_flush_tlb(const cpumask_t *mask, const void *va)
+{
+if ( ops && ops->flush_tlb )
+return ops->flush_tlb(mask, va);
+
+return -ENOSYS;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index 6dbc5f953f..47af773aca 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -310,11 +310,17 @@ static void resume(void)
 pv_console_init();
 }
 
+static int flush_tlb(const cpumask_t *mask, const void *va)
+{
+return xen_hypercall_hvm_op(HVMOP_flush_tlbs, NULL);
+}
+
 static const struct hypervisor_ops ops = {
 .name = "Xen",
 .setup = setup,
 .ap_setup = ap_setup,
 .resume = resume,
+.flush_tlb = flush_tlb,
 };
 
 const struct hypervisor_ops *__init xg_probe(void)
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 6510dd84ab..b3cb1ba90f 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -262,6 +263,11 @@ void flush_area_mask(const cpumask_t *mask, const void 
*va, unsigned int flags)
 if ( (flags & ~FLUSH_ORDER_MASK) &&
  !cpumask_subset(mask, cpumask_of(cpu)) )
 {
+if ( cpu_has_hypervisor &&
+ !(flags & ~(FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_VA_VALID)) &&
+ !hypervisor_flush_tlb(mask, va) )
+return;
+
 spin_lock(_lock);
 cpumask_and(_cpumask, mask, _online_map);
 cpumask_clear_cpu(cpu, _cpumask);
diff --git a/xen/include/asm-x86/guest/hypervisor.h 
b/xen/include/asm-x86/guest/hypervisor.h
index 392f4b90ae..b7f1969796 100644
--- a/xen/include/asm-x86/guest/hypervisor.h
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -28,6 +28,8 @@ struct hypervisor_ops {
 void (*ap_setup)(void);
 /* Resume from suspension */
 void (*resume)(void);
+/* L0 assisted TLB flush */
+int (*flush_tlb)(const cpumask_t *mask, const void *va);
 };
 
 #ifdef CONFIG_GUEST
@@ -36,9 +38,16 @@ const char *hypervisor_probe(void);
 void hypervisor_setup(void);
 void hypervisor_ap_setup(void);
 void hypervisor_resume(void);
+/*
+ * L0 assisted TLB flush.
+ * mask: cpumask of the dirty vCPUs that should be flushed.
+ * va: linear address to flush, or NULL for global flushes.
+ */
+int hypervisor_flush_tlb(const cpumask_t *mask, const void *va);
 
 #else
 
+#include 
 #include 
 #include 
 
@@ -46,6 +55,10 @@ static inline const char *hypervisor_probe(void) { return 
NULL; }
 static inline void hypervisor_setup(void) { ASSERT_UNREACHABLE(); }
 static inline void hypervisor_ap_setup(void) { ASSERT_UNREACHABLE(); }
 static inline void hypervisor_resume(void) { ASSERT_UNREACHABLE(); }
+static inline int hypervisor_flush_tlb(const cpumask_t *mask, const void *va)
+{
+return -ENOSYS;
+}
 
 #endif  /* CONFIG_GUEST */
 
-- 
2.24.1


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

[Xen-devel] [PATCH v2 1/3] x86/hvm: allow ASID flush when v != current

[Roger Pau Monne]

Current implementation of hvm_asid_flush_vcpu is not safe to use
unless the target vCPU is either paused or the currently running one,
as it modifies the generation without any locking.

Fix this by using atomic operations when accessing the generation
field, both in hvm_asid_flush_vcpu_asid and other ASID functions. This
allows to safely flush the current ASID generation. Note that for the
flush to take effect if the vCPU is currently running a vmexit is
required.

Note the same could be achieved by introducing an extra field to
hvm_vcpu_asid that signals hvm_asid_handle_vmenter the need to call
hvm_asid_flush_vcpu on the given vCPU before vmentry, this however
seems unnecessary as hvm_asid_flush_vcpu itself only sets two vCPU
fields to 0, so there's no need to delay this to the vmentry ASID
helper.

This is not a bugfix as no callers that would violate the assumptions
listed in the first paragraph have been found, but a preparatory
change in order to allow remote flushing of HVM vCPUs.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/hvm/asid.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/asid.c b/xen/arch/x86/hvm/asid.c
index 9d3c671a5f..80b73da89b 100644
--- a/xen/arch/x86/hvm/asid.c
+++ b/xen/arch/x86/hvm/asid.c
@@ -82,7 +82,7 @@ void hvm_asid_init(int nasids)
 
 void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid)
 {
-asid->generation = 0;
+write_atomic(>generation, 0);
 }
 
 void hvm_asid_flush_vcpu(struct vcpu *v)
@@ -120,7 +120,7 @@ bool_t hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid)
 goto disabled;
 
 /* Test if VCPU has valid ASID. */
-if ( asid->generation == data->core_asid_generation )
+if ( read_atomic(>generation) == data->core_asid_generation )
 return 0;
 
 /* If there are no free ASIDs, need to go to a new generation */
@@ -134,7 +134,7 @@ bool_t hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid)
 
 /* Now guaranteed to be a free ASID. */
 asid->asid = data->next_asid++;
-asid->generation = data->core_asid_generation;
+write_atomic(>generation, data->core_asid_generation);
 
 /*
  * When we assign ASID 1, flush all TLB entries as we are starting a new
-- 
2.24.1


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

Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests

[Jan Beulich]

On 10.01.2020 16:28, George Dunlap wrote:
> On 1/10/20 11:02 AM, Andrew Cooper wrote:
>> On 10/01/2020 10:37, Sergey Dyasli wrote:
>>> Hide the following information that can help identify the running Xen
>>> binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
>>> Add explicit cases for XENVER_commandline and XENVER_build_id as well.
>>>
>>> Introduce xsm_filter_denied() to hvmloader to remove "" string
>>> from guest's DMI tables that otherwise would be shown in tools like
>>> dmidecode.
>>>
>>> Signed-off-by: Sergey Dyasli 
>>> ---
>>> v1 --> v2:
>>> - Added xsm_filter_denied() to hvmloader instead of modifying xen_deny()
>>> - Made behaviour the same for both Release and Debug builds
>>> - XENVER_capabilities is no longer hided
>>>
>>> CC: Andrew Cooper 
>>> CC: George Dunlap 
>>> CC: Ian Jackson 
>>> CC: Jan Beulich 
>>> CC: Julien Grall 
>>> CC: Konrad Rzeszutek Wilk 
>>> CC: Stefano Stabellini 
>>> CC: Wei Liu 
>>> CC: Daniel De Graaf 
>>
>> I realise there are arguments over how to fix this, but we (the Xen
>> community) have already f*cked up once here, and this is doing so a
>> second time.
>>
>> Nack.
>>
>> Fixing it anywhere other than Xen is simply not appropriate.

(replying here, because the original mail doesn't seem to have
made it into my inbox)

I've said so to Sergey already on v1: The "fix" you want needs to
be at or closer to the presentation layer. From Xen's perspective
the request for information was _indeed_ denied.

>> The reason for this (which ought to be obvious, but I guess only to
>> those who actually do customer support) is basic human physiology. 
>> "denied" means something has gone wrong.  It scares people, and causes
>> them to seek help to change fix whatever is broken.
> 
> This seems like a reasonable argument that "" causes issues.
> But that doesn't change the fact that "" also causes issues.
> 
> What about changing the string to "" or something like
> that?  That makes it more clear what would have been in that place, and
> "hidden" is a lot less scary than "denied".

I could live with this. But (judging from the picture that was
provided earlier on) it would still require filtering at or close
to the presentation layer, and by changing the prior  to
different and varying strings may make that job harder (albeit
perhaps they could look for any <...>).

Jan

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

Re: [Xen-devel] [RFC PATCH V2 11/11] x86: tsc: avoid system instability in hibernation

[Eduardo Valentin]

Hey Peter,

On Wed, Jan 08, 2020 at 11:50:11AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 07, 2020 at 11:45:26PM +, Anchal Agarwal wrote:
> > From: Eduardo Valentin 
> > 
> > System instability are seen during resume from hibernation when system
> > is under heavy CPU load. This is due to the lack of update of sched
> > clock data, and the scheduler would then think that heavy CPU hog
> > tasks need more time in CPU, causing the system to freeze
> > during the unfreezing of tasks. For example, threaded irqs,
> > and kernel processes servicing network interface may be delayed
> > for several tens of seconds, causing the system to be unreachable.
> 
> > The fix for this situation is to mark the sched clock as unstable
> > as early as possible in the resume path, leaving it unstable
> > for the duration of the resume process. This will force the
> > scheduler to attempt to align the sched clock across CPUs using
> > the delta with time of day, updating sched clock data. In a post
> > hibernation event, we can then mark the sched clock as stable
> > again, avoiding unnecessary syncs with time of day on systems
> > in which TSC is reliable.
> 
> This makes no frigging sense what so bloody ever. If the clock is
> stable, we don't care about sched_clock_data. When it is stable you get
> a linear function of the TSC without complicated bits on.
> 
> When it is unstable, only then do we care about the sched_clock_data.
> 

Yeah, maybe what is not clear here is that we covering for situation
where clock stability changes over time, e.g. at regular boot clock is
stable, hibernation happens, then restore happens in a non-stable clock.

> > Reviewed-by: Erik Quanstrom 
> > Reviewed-by: Frank van der Linden 
> > Reviewed-by: Balbir Singh 
> > Reviewed-by: Munehisa Kamata 
> > Tested-by: Anchal Agarwal 
> > Signed-off-by: Eduardo Valentin 
> > ---
> 
> NAK, the code very much relies on never getting marked stable again
> after it gets set to unstable.
> 

Well actually, at the PM_POST_HIBERNATION, we do the check and set stable if
known to be stable.

The issue only really happens during the restoration path under scheduling 
pressure,
which takes forever to finish, as described in the commit.

Do you see a better solution for this issue?


> > diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
> > index 1152259a4ca0..374d40e5b1a2 100644
> > --- a/kernel/sched/clock.c
> > +++ b/kernel/sched/clock.c
> > @@ -116,7 +116,7 @@ static void __scd_stamp(struct sched_clock_data *scd)
> > scd->tick_raw = sched_clock();
> >  }
> >  
> > -static void __set_sched_clock_stable(void)
> > +void set_sched_clock_stable(void)
> >  {
> > struct sched_clock_data *scd;
> >  
> > @@ -236,7 +236,7 @@ static int __init sched_clock_init_late(void)
> > smp_mb(); /* matches {set,clear}_sched_clock_stable() */
> >  
> > if (__sched_clock_stable_early)
> > -   __set_sched_clock_stable();
> > +   set_sched_clock_stable();
> >  
> > return 0;
> >  }
> > -- 
> > 2.15.3.AMZN
> > 

-- 
All the best,
Eduardo Valentin

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

Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests

[George Dunlap]

On 1/10/20 11:02 AM, Andrew Cooper wrote:
> On 10/01/2020 10:37, Sergey Dyasli wrote:
>> Hide the following information that can help identify the running Xen
>> binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
>> Add explicit cases for XENVER_commandline and XENVER_build_id as well.
>>
>> Introduce xsm_filter_denied() to hvmloader to remove "" string
>> from guest's DMI tables that otherwise would be shown in tools like
>> dmidecode.
>>
>> Signed-off-by: Sergey Dyasli 
>> ---
>> v1 --> v2:
>> - Added xsm_filter_denied() to hvmloader instead of modifying xen_deny()
>> - Made behaviour the same for both Release and Debug builds
>> - XENVER_capabilities is no longer hided
>>
>> CC: Andrew Cooper 
>> CC: George Dunlap 
>> CC: Ian Jackson 
>> CC: Jan Beulich 
>> CC: Julien Grall 
>> CC: Konrad Rzeszutek Wilk 
>> CC: Stefano Stabellini 
>> CC: Wei Liu 
>> CC: Daniel De Graaf 
> 
> I realise there are arguments over how to fix this, but we (the Xen
> community) have already f*cked up once here, and this is doing so a
> second time.
> 
> Nack.
> 
> Fixing it anywhere other than Xen is simply not appropriate.
> 
> The reason for this (which ought to be obvious, but I guess only to
> those who actually do customer support) is basic human physiology. 
> "denied" means something has gone wrong.  It scares people, and causes
> them to seek help to change fix whatever is broken.

This seems like a reasonable argument that "" causes issues.
But that doesn't change the fact that "" also causes issues.

What about changing the string to "" or something like
that?  That makes it more clear what would have been in that place, and
"hidden" is a lot less scary than "denied".

 -George

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

[Xen-devel] [qemu-mainline test] 145930: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 144861
 build-arm64   6 xen-buildfail REGR. vs. 144861
 build-amd64   6 xen-buildfail REGR. vs. 144861
 build-i386-xsm6 xen-buildfail REGR. vs. 144861
 build-armhf   6 xen-buildfail REGR. vs. 144861
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144861
 build-i3866 xen-buildfail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 

Re: [Xen-devel] [PATCH v1 1/4] kasan: introduce set_pmd_early_shadow()

[kbuild test robot]

Hi Sergey,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net-next/master]
[also build test ERROR on net/master linus/master v5.5-rc5 next-20200109]
[cannot apply to xen-tip/linux-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Sergey-Dyasli/basic-KASAN-support-for-Xen-PV-domains/20200110-042623
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
4a4a52d49d11f5c4a0df8b9806c8c5563801f753
config: arm64-randconfig-a001-20200109 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.5.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=arm64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All error/warnings (new ones prefixed by >>):

   In file included from arch/arm64/include/asm/kasan.h:9:0,
from arch/arm64/include/asm/processor.h:34,
from include/asm-generic/qrwlock.h:14,
from ./arch/arm64/include/generated/asm/qrwlock.h:1,
from arch/arm64/include/asm/spinlock.h:8,
from include/linux/spinlock.h:89,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:6,
from include/linux/mm.h:10,
from include/linux/memblock.h:13,
from mm/kasan/init.c:14:
   mm/kasan/init.c: In function 'set_pmd_early_shadow':
>> mm/kasan/init.c:90:43: error: '_PAGE_TABLE' undeclared (first use in this 
>> function); did you mean 'NR_PAGETABLE'?
  set_pmd(pmd, __pmd(__pa(early_shadow) | _PAGE_TABLE));
  ^
   arch/arm64/include/asm/pgtable-types.h:40:30: note: in definition of macro 
'__pgd'
#define __pgd(x) ((pgd_t) { (x) } )
 ^
>> include/asm-generic/pgtable-nopmd.h:50:32: note: in expansion of macro 
>> '__pud'
#define __pmd(x)((pmd_t) { __pud(x) } )
   ^
>> mm/kasan/init.c:90:16: note: in expansion of macro '__pmd'
  set_pmd(pmd, __pmd(__pa(early_shadow) | _PAGE_TABLE));
   ^
   mm/kasan/init.c:90:43: note: each undeclared identifier is reported only 
once for each function it appears in
  set_pmd(pmd, __pmd(__pa(early_shadow) | _PAGE_TABLE));
  ^
   arch/arm64/include/asm/pgtable-types.h:40:30: note: in definition of macro 
'__pgd'
#define __pgd(x) ((pgd_t) { (x) } )
 ^
>> include/asm-generic/pgtable-nopmd.h:50:32: note: in expansion of macro 
>> '__pud'
#define __pmd(x)((pmd_t) { __pud(x) } )
   ^
>> mm/kasan/init.c:90:16: note: in expansion of macro '__pmd'
  set_pmd(pmd, __pmd(__pa(early_shadow) | _PAGE_TABLE));
   ^
--
   In file included from arch/arm64/include/asm/kasan.h:9:0,
from arch/arm64/include/asm/processor.h:34,
from include/asm-generic/qrwlock.h:14,
from ./arch/arm64/include/generated/asm/qrwlock.h:1,
from arch/arm64/include/asm/spinlock.h:8,
from include/linux/spinlock.h:89,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:6,
from include/linux/mm.h:10,
from include/linux/memblock.h:13,
from mm//kasan/init.c:14:
   mm//kasan/init.c: In function 'set_pmd_early_shadow':
   mm//kasan/init.c:90:43: error: '_PAGE_TABLE' undeclared (first use in this 
function); did you mean 'NR_PAGETABLE'?
  set_pmd(pmd, __pmd(__pa(early_shadow) | _PAGE_TABLE));
  ^
   arch/arm64/include/asm/pgtable-types.h:40:30: note: in definition of macro 
'__pgd'
#define __pgd(x) ((pgd_t) { (x) } )
 ^
>> include/asm-generic/pgtable-nopmd.h:50:32: note: in expansion of macro 
>> '__pud'
#define __pmd(x)((pmd_t) { __pud(x) } )
   ^
   mm//kasan/init.c:90:16: note: in expansion of macro '__pmd'
  set_pmd(pmd, __pmd(__pa(early_shadow) | _PAGE_TABLE));
   ^
   mm//kasan/init.c:90:43: note: each undeclared identifier is reported only 
once for each function it appears in
  set_pmd(pmd, __pmd(__pa(early_shadow) | _PAGE_TABLE));
  ^
   arch/arm64/include/asm/pgtabl

[Xen-devel] [ovmf test] 145926: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
145767
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767

version targeted for testing:
 ovmf 9d1c9d0379d065ca11bc3354faee2c742e89c005
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z2 days
Failing since145774  2020-01-08 02:50:20 Z2 days   13 attempts
Testing same since   145926  2020-01-10 12:09:33 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ashish Singhal 
  Eric Dong 
  Jason Voelz 
  Laszlo Ersek 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 
  Vitaly Cheptsov 
  Vitaly Cheptsov via Groups.Io 

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.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v1 4/4] xen/netback: Fix grant copy across page boundary with KASAN

[Sergey Dyasli]

On 09/01/2020 13:36, Paul Durrant wrote:
> On Wed, 8 Jan 2020 at 15:21, Sergey Dyasli  wrote:
>>
>> From: Ross Lagerwall 
>>
>> When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
>> allocations are aligned to the next power of 2 of the size does not
>> hold. Therefore, handle grant copies that cross page boundaries.
>>
>> Signed-off-by: Ross Lagerwall 
>> Signed-off-by: Sergey Dyasli 
>> ---
>> RFC --> v1:
>> - Added BUILD_BUG_ON to the netback patch
>> - xenvif_idx_release() now located outside the loop
>>
>> CC: Wei Liu 
>> CC: Paul Durrant 
> [snip]
>>
>> +static void __init __maybe_unused build_assertions(void)
>> +{
>> +   BUILD_BUG_ON(sizeof(struct xenvif_tx_cb) > 48);
>
> FIELD_SIZEOF(struct sk_buff, cb) rather than a magic '48' I think.

The macro got renamed recently, so now it should be:

sizeof_field(struct sk_buff, cb))

Thanks for the suggestion.

--
Sergey

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail in 145879 pass in 145903
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail pass in 
145879

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds   16 guest-start/debian.repeat fail blocked in 145879
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail  like 145879
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 145879
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 145879
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 145879
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 145879
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 145879
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 145879
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 145879
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 145879
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 145879
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  fae249d23413b2bf7d98a97d8f649cf7d102c1ae
baseline version:
 xen  fae249d23413b2bf7d98a97d8f649cf7d102c1ae

Last test of basis   145903  2020-01-10 02:58:21 Z0 days
Testing same since  (not found) 0 attempts

jobs:
 

[Xen-devel] [PATCH 8/8] libxl: event: Move poller pipe emptying to the end of afterpoll

[Ian Jackson]

If a timer event callback causes this poller to be woken (not very
unlikely) we would go round the poll loop twice rather than once.

Do the poller pipe emptying at the end; this is slightly more
efficient because it can't cause any callbacks, so it happens after
all the callbacks have been run.

(This pipe-emptying has to happen in afterpoll rather than the
apparently more logical beforepoll, because the application calling
beforepoll doesn't constitute a promise to actually do anything.)

Signed-off-by: Ian Jackson 
---
 tools/libxl/libxl_event.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 4314191c3b..f59fbc719e 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1326,12 +1326,6 @@ static void afterpoll_internal(libxl__egc *egc, 
libxl__poller *poller,
 fd_occurs(egc, efd, revents);
 }
 
-if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-poller->pipe_nonempty = 0;
-int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
-if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
-}
-
 for (;;) {
 libxl__ev_time *etime = LIBXL_TAILQ_FIRST(>etimes);
 if (!etime)
@@ -1346,6 +1340,12 @@ static void afterpoll_internal(libxl__egc *egc, 
libxl__poller *poller,
 
 time_occurs(egc, etime, ERROR_TIMEDOUT);
 }
+
+if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
+poller->pipe_nonempty = 0;
+int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+}
 }
 
 void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd 
*fds,
-- 
2.11.0


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

[Xen-devel] [PATCH 5/8] libxl: event: poller pipe optimisation

[Ian Jackson]

Track in userland whether the poller pipe is nonempty.  This saves us
writing many many bytes to the pipe if nothing ever reads them.

This is going to be relevant in a moment, where we are going to create
a situation where this will happen quite a lot.

Signed-off-by: Ian Jackson 
---
 tools/libxl/libxl_event.c| 2 ++
 tools/libxl/libxl_internal.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 18db091a6e..05559cad9a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1319,6 +1319,7 @@ static void afterpoll_internal(libxl__egc *egc, 
libxl__poller *poller,
 }
 
 if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
+poller->pipe_nonempty = 0;
 int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
 if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
 }
@@ -1713,6 +1714,7 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+if (p->pipe_nonempty++) return;
 int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
 if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b9c4031863..baf7509b1e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -625,6 +625,7 @@ struct libxl__poller {
 int (*fd_rindices)[3]; /* see libxl_event.c:beforepoll_internal */
 
 int wakeup_pipe[2]; /* 0 means no fd allocated */
+bool pipe_nonempty;
 
 /*
  * We also use the poller to record whether any fds have been
-- 
2.11.0


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

[Xen-devel] [PATCH 0/8] libxl: event: Fix hang for some applications

[Ian Jackson]

The meat here, including a description of the bug, is in:
  libxl: event: Fix hang when mixing blocking and eventy calls

I have compiled this but not tested it.  We do not have a good test
suite for this event stuff.  (And races etc are hard to test.)
George, can you check to see whether it fixes the issue you saw ?

If so then I suggest we try to convince ourselves of its correctness
via a second round of code review.  I will certainly want to read it
all again after the weekend, since then I will hopefully have
forgotten enough about this to make that a worthwhile exercise.

Ian Jackson (8):
  libxl: event: Rename poller.fds_changed to .fds_deregistered
  libxl: event: Rename ctx.pollers_fd_changed to .pollers_active
  libxl: event: Introduce CTX_UNLOCK_EGC_FREE
  libxl: event: Fix hang when mixing blocking and eventy calls
  libxl: event: poller pipe optimisation
  libxl: event: Break out baton_wake
  libxl: event: Fix possible hang with libxl_osevent_beforepoll
  libxl: event: Move poller pipe emptying to the end of afterpoll

 tools/libxl/libxl.c  |   4 +-
 tools/libxl/libxl_event.c| 126 ++-
 tools/libxl/libxl_fork.c |   6 +--
 tools/libxl/libxl_internal.h |  42 +++
 4 files changed, 127 insertions(+), 51 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH 6/8] libxl: event: Break out baton_wake

[Ian Jackson]

No functional change.

Signed-off-by: Ian Jackson 
---
 tools/libxl/libxl_event.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 05559cad9a..4d57843cce 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -42,6 +42,18 @@ static void pollers_note_osevent_added(libxl_ctx *ctx) {
 poller->osevents_added = 1;
 }
 
+static void baton_wake(libxl__egc *egc, libxl__poller *wake)
+{
+libxl__poller_wakeup(egc, wake);
+
+wake->osevents_added = 0;
+/* This serves to make _1_baton idempotent.  It is OK even though
+ * that poller may currently be sleeping on only old osevents,
+ * because it is going to wake up because we've just prodded it,
+ * and it pick up new osevents on its next iteration (or pass
+ * on the baton). */
+}
+
 void libxl__egc_cleanup_1_baton(libxl__egc *egc)
 {
 EGC_GC;
@@ -62,14 +74,7 @@ void libxl__egc_cleanup_1_baton(libxl__egc *egc)
 /* no-one in libxl waiting for any events */
 return;
 
-libxl__poller_wakeup(egc, wake);
-
-wake->osevents_added = 0;
-/* This serves to make _1_baton idempotent.  It is OK even though
- * that poller may currently be sleeping on only old osevents,
- * because it is going to wake up because we've just prodded it,
- * and it pick up new osevents on its next iteration (or pass
- * on the baton). */
+baton_wake(egc, wake);
 }
 
 /*
-- 
2.11.0


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

[Xen-devel] [PATCH 3/8] libxl: event: Introduce CTX_UNLOCK_EGC_FREE

[Ian Jackson]

This is a very common exit pattern.  We are going to want to change
this pattern.  So we should make it into a macro of its own.

No functional change.

Signed-off-by: Ian Jackson 
---
 tools/libxl/libxl_event.c| 18 ++
 tools/libxl/libxl_fork.c |  6 ++
 tools/libxl/libxl_internal.h |  2 ++
 3 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5b12a45e70..be37e12bb0 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1152,8 +1152,7 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
 CTX_LOCK;
 int rc = beforepoll_internal(gc, ctx->poller_app,
  nfds_io, fds, timeout_upd, now);
-CTX_UNLOCK;
-EGC_FREE;
+CTX_UNLOCK_EGC_FREE;
 return rc;
 }
 
@@ -1305,8 +1304,7 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, 
const struct pollfd *fds,
 EGC_INIT(ctx);
 CTX_LOCK;
 afterpoll_internal(egc, ctx->poller_app, nfds, fds, now);
-CTX_UNLOCK;
-EGC_FREE;
+CTX_UNLOCK_EGC_FREE;
 }
 
 /*
@@ -1342,8 +1340,7 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void 
*for_libxl,
 fd_occurs(egc, ev, revents_ign);
 
  out:
-CTX_UNLOCK;
-EGC_FREE;
+CTX_UNLOCK_EGC_FREE;
 }
 
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
@@ -1365,8 +1362,7 @@ void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void 
*for_libxl)
 time_occurs(egc, ev, ERROR_TIMEDOUT);
 
  out:
-CTX_UNLOCK;
-EGC_FREE;
+CTX_UNLOCK_EGC_FREE;
 }
 
 void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
@@ -1546,8 +1542,7 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event 
**event_r,
 EGC_INIT(ctx);
 CTX_LOCK;
 int rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
-CTX_UNLOCK;
-EGC_FREE;
+CTX_UNLOCK_EGC_FREE;
 return rc;
 }
 
@@ -1772,8 +1767,7 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event 
**event_r,
  out:
 libxl__poller_put(ctx, poller);
 
-CTX_UNLOCK;
-EGC_FREE;
+CTX_UNLOCK_EGC_FREE;
 return rc;
 }
 
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 0f1b6b518c..cf170b9085 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -483,8 +483,7 @@ int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int 
status)
 assert(CTX->childproc_hooks->chldowner
== libxl_sigchld_owner_mainloop);
 int rc = childproc_reaped(egc, pid, status);
-CTX_UNLOCK;
-EGC_FREE;
+CTX_UNLOCK_EGC_FREE;
 return rc;
 }
 
@@ -529,8 +528,7 @@ void libxl_childproc_sigchld_occurred(libxl_ctx *ctx)
 assert(CTX->childproc_hooks->chldowner
== libxl_sigchld_owner_mainloop);
 childproc_checkall(egc);
-CTX_UNLOCK;
-EGC_FREE;
+CTX_UNLOCK_EGC_FREE;
 }
 
 static void sigchld_selfpipe_handler(libxl__egc *egc, libxl__ev_fd *ev,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 581d64b99c..983fffac7a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2363,6 +2363,8 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 
 #define EGC_FREE   libxl__egc_cleanup(egc)
 
+#define CTX_UNLOCK_EGC_FREE  do{ CTX_UNLOCK; EGC_FREE; }while(0)
+
 
 /*
  * Machinery for asynchronous operations ("ao")
-- 
2.11.0


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

[Xen-devel] [PATCH 2/8] libxl: event: Rename ctx.pollers_fd_changed to .pollers_active

[Ian Jackson]

We are going to use this a bit more widely.  Make the name more
general.

Signed-off-by: Ian Jackson 
---
 tools/libxl/libxl.c  | 4 ++--
 tools/libxl/libxl_event.c| 8 
 tools/libxl/libxl_internal.h | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a0d84281d0..f60fd3e4fd 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -48,7 +48,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 ctx->poller_app = 0;
 LIBXL_LIST_INIT(>pollers_event);
 LIBXL_LIST_INIT(>pollers_idle);
-LIBXL_LIST_INIT(>pollers_fds_changed);
+LIBXL_LIST_INIT(>pollers_active);
 
 LIBXL_LIST_INIT(>efds);
 LIBXL_TAILQ_INIT(>etimes);
@@ -177,7 +177,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
 libxl__poller_put(ctx, ctx->poller_app);
 ctx->poller_app = NULL;
 assert(LIBXL_LIST_EMPTY(>pollers_event));
-assert(LIBXL_LIST_EMPTY(>pollers_fds_changed));
+assert(LIBXL_LIST_EMPTY(>pollers_active));
 libxl__poller *poller, *poller_tmp;
 LIBXL_LIST_FOREACH_SAFE(poller, >pollers_idle, entry, poller_tmp) {
 libxl__poller_dispose(poller);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 1210c1bfb3..5b12a45e70 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -238,7 +238,7 @@ void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd 
*ev)
 LIBXL_LIST_REMOVE(ev, entry);
 ev->fd = -1;
 
-LIBXL_LIST_FOREACH(poller, >pollers_fds_changed, fds_changed_entry)
+LIBXL_LIST_FOREACH(poller, >pollers_active, active_entry)
 poller->fds_deregistered = 1;
 
  out:
@@ -1663,15 +1663,15 @@ libxl__poller *libxl__poller_get(libxl__gc *gc)
 }
 }
 
-LIBXL_LIST_INSERT_HEAD(>pollers_fds_changed, p,
-   fds_changed_entry);
+LIBXL_LIST_INSERT_HEAD(>pollers_active, p,
+   active_entry);
 return p;
 }
 
 void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 {
 if (!p) return;
-LIBXL_LIST_REMOVE(p, fds_changed_entry);
+LIBXL_LIST_REMOVE(p, active_entry);
 LIBXL_LIST_INSERT_HEAD(>pollers_idle, p, entry);
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c5b71d15f0..581d64b99c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -629,13 +629,13 @@ struct libxl__poller {
 /*
  * We also use the poller to record whether any fds have been
  * deregistered since we entered poll.  Each poller which is not
- * idle is on the list pollers_fds_changed.  fds_deregistered is
+ * idle is on the list pollers_active.  fds_deregistered is
  * cleared by beforepoll, and tested by afterpoll.  Whenever an fd
  * event is deregistered, we set the fds_deregistered of all non-idle
  * pollers.  So afterpoll can tell whether any POLLNVAL is
  * plausibly due to an fd being closed and reopened.
  */
-LIBXL_LIST_ENTRY(libxl__poller) fds_changed_entry;
+LIBXL_LIST_ENTRY(libxl__poller) active_entry;
 bool fds_deregistered;
 };
 
@@ -678,7 +678,7 @@ struct libxl__ctx {
 
 libxl__poller *poller_app; /* libxl_osevent_beforepoll and _afterpoll */
 LIBXL_LIST_HEAD(, libxl__poller) pollers_event, pollers_idle;
-LIBXL_LIST_HEAD(, libxl__poller) pollers_fds_changed;
+LIBXL_LIST_HEAD(, libxl__poller) pollers_active;
 
 LIBXL_SLIST_HEAD(libxl__osevent_hook_nexi, libxl__osevent_hook_nexus)
 hook_fd_nexi_idle, hook_timeout_nexi_idle;
-- 
2.11.0


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

[Xen-devel] [PATCH 4/8] libxl: event: Fix hang when mixing blocking and eventy calls

[Ian Jackson]

If the application calls libxl with ao_how==0 and also makes calls
like _occurred, libxl will sometimes get stuck.

The bug happens as follows (for example):

  Thread A
   libxl_do_thing(,ao_how==0)
   libxl_do_thing starts, sets up some callbacks
   libxl_do_thing exit path calls AO_INPROGRESS
   libxl__ao_inprogress goes into event loop
   eventloop_iteration sleeps on:
  - do_thing's current fd set
  - sigchld pipe if applicable
  - its poller

  Thread B
   libxl_something_occurred
   the something is to do with do_thing, above
   do_thing_next_callback does some more work
   do_thing_next_callback becomes interested in fd N
   thread B returns to application

Note that nothing wakes up thread A.  A is not listening on fd N.  So
do_thing_* will not spot when fd N signals.  do_thing will not make
further timely progress.  If there is no timeout thread A will never
wake up.

The problem here occurs because thread A is waiting on an out of date
osevent set.  We need the following property: whenever any thread is
blocking in the libxl event loop, at least one thread must be using an
up to date osevent set.  It is OK for all but one threads to have
stale event sets, because so long as one waiting thread has the right
event set, any actually interesting event will, if nothing else, wake
that "right" thread up.  It will then make some progress and/or, if it
exits, ensure that some other thread becomes the "right" thread.

There is also the possibility that a thread might block waiting for
libxl osevents but outside libxl, eg if the application used
libxl_osevent_beforepoll.  We will deal with that in a moment.

Reported-by: George Dunlap 
Signed-off-by: Ian Jackson 
---
 tools/libxl/libxl_event.c| 72 +---
 tools/libxl/libxl_internal.h | 33 
 2 files changed, 88 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index be37e12bb0..18db091a6e 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -36,6 +36,42 @@ static libxl__ao *ao_nested_root(libxl__ao *ao);
 static void ao__check_destroy(libxl_ctx *ctx, libxl__ao *ao);
 
 
+static void pollers_note_osevent_added(libxl_ctx *ctx) {
+libxl__poller *poller;
+LIBXL_LIST_FOREACH(poller, >pollers_active, active_entry)
+poller->osevents_added = 1;
+}
+
+void libxl__egc_cleanup_1_baton(libxl__egc *egc)
+{
+EGC_GC;
+libxl__poller *search, *wake=0;
+
+LIBXL_LIST_FOREACH(search, >pollers_active, active_entry) {
+if (search == CTX->poller_app)
+/* This one is special.  We can't give it the baton. */
+continue;
+if (!search->osevents_added)
+/* This poller is up to date and will wake up as needed. */
+return;
+if (!wake)
+wake = search;
+}
+
+if (!wake)
+/* no-one in libxl waiting for any events */
+return;
+
+libxl__poller_wakeup(egc, wake);
+
+wake->osevents_added = 0;
+/* This serves to make _1_baton idempotent.  It is OK even though
+ * that poller may currently be sleeping on only old osevents,
+ * because it is going to wake up because we've just prodded it,
+ * and it pick up new osevents on its next iteration (or pass
+ * on the baton). */
+}
+
 /*
  * The counter osevent_in_hook is used to ensure that the application
  * honours the reentrancy restriction documented in libxl_event.h.
@@ -194,6 +230,7 @@ int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
 ev->func = func;
 
 LIBXL_LIST_INSERT_HEAD(>efds, ev, entry);
+pollers_note_osevent_added(CTX);
 
 rc = 0;
 
@@ -214,6 +251,8 @@ int libxl__ev_fd_modify(libxl__gc *gc, libxl__ev_fd *ev, 
short events)
 rc = OSEVENT_HOOK(fd,modify, noop, ev->fd, >nexus->for_app_reg, 
events);
 if (rc) goto out;
 
+if ((events & ~ev->events))
+pollers_note_osevent_added(CTX);
 ev->events = events;
 
 rc = 0;
@@ -315,6 +354,7 @@ static int time_register_finite(libxl__gc *gc, 
libxl__ev_time *ev,
 LIBXL_TAILQ_INSERT_SORTED(>etimes, entry, ev, evsearch, /*empty*/,
   timercmp(>abs, >abs, >));
 
+pollers_note_osevent_added(CTX);
 return 0;
 }
 
@@ -1121,6 +1161,7 @@ static int beforepoll_internal(libxl__gc *gc, 
libxl__poller *poller,
 *nfds_io = used;
 
 poller->fds_deregistered = 0;
+poller->osevents_added = 0;
 
 libxl__ev_time *etime = LIBXL_TAILQ_FIRST(>etimes);
 if (etime) {
@@ -1444,7 +1485,7 @@ static void egc_run_callbacks(libxl__egc *egc)
 }
 }
 
-void libxl__egc_cleanup(libxl__egc *egc)
+void libxl__egc_cleanup_2_ul_cb_gc(libxl__egc *egc)
 {
 EGC_GC;
 egc_run_callbacks(egc);
@@ -1754,13 +1795,15 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event 
**event_r,
 rc = eventloop_iteration(egc, poller);
 if (rc) goto out;
 
-/* we 

[Xen-devel] [PATCH 7/8] libxl: event: Fix possible hang with libxl_osevent_beforepoll

[Ian Jackson]

If the application uses libxl_osevent_beforepoll, a similar hang is
possible to the one described and fixed in
   libxl: event: Fix hang when mixing blocking and eventy calls
Application behaviour would have to be fairly unusual, but it
doesn't seem sensible to just leave this latent bug.

We fix the latent bug by waking up the "poller_app" pipe every time we
add osevents.  If the application does not ever call beforepoll, we
write one byte to the pipe and set pipe_nonempty and then we ignore
it.  We only write another byte if beforepoll is called again.

Normally in an eventy program there would only be one thread calling
libxl_osevent_beforepoll.  The effect in such a program is to
sometimes needlessly go round the poll loop again if a timeout
callback becomes interested in a new osevent.  We'll fix that in a
moment.

Signed-off-by: Ian Jackson 
---
 tools/libxl/libxl_event.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 4d57843cce..4314191c3b 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -59,6 +59,9 @@ void libxl__egc_cleanup_1_baton(libxl__egc *egc)
 EGC_GC;
 libxl__poller *search, *wake=0;
 
+if (CTX->poller_app->osevents_added)
+baton_wake(egc, CTX->poller_app);
+
 LIBXL_LIST_FOREACH(search, >pollers_active, active_entry) {
 if (search == CTX->poller_app)
 /* This one is special.  We can't give it the baton. */
-- 
2.11.0


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

[Xen-devel] [PATCH 1/8] libxl: event: Rename poller.fds_changed to .fds_deregistered

[Ian Jackson]

This is only for deregistration.  We are going to add another variable
for new events, with different semantics, and this overly-general name
will become confusing.

Signed-off-by: Ian Jackson 
---
 tools/libxl/libxl_event.c| 8 
 tools/libxl/libxl_internal.h | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index aa8b7d1945..1210c1bfb3 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -239,7 +239,7 @@ void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd 
*ev)
 ev->fd = -1;
 
 LIBXL_LIST_FOREACH(poller, >pollers_fds_changed, fds_changed_entry)
-poller->fds_changed = 1;
+poller->fds_deregistered = 1;
 
  out:
 CTX_UNLOCK;
@@ -1120,7 +1120,7 @@ static int beforepoll_internal(libxl__gc *gc, 
libxl__poller *poller,
 
 *nfds_io = used;
 
-poller->fds_changed = 0;
+poller->fds_deregistered = 0;
 
 libxl__ev_time *etime = LIBXL_TAILQ_FIRST(>etimes);
 if (etime) {
@@ -1186,7 +1186,7 @@ static int afterpoll_check_fd(libxl__poller *poller,
 /* again, stale slot entry */
 continue;
 
-assert(poller->fds_changed || !(fds[slot].revents & POLLNVAL));
+assert(poller->fds_deregistered || !(fds[slot].revents & POLLNVAL));
 
 /* we mask in case requested events have changed */
 int slot_revents = fds[slot].revents & events;
@@ -1626,7 +1626,7 @@ int libxl__poller_init(libxl__gc *gc, libxl__poller *p)
 int rc;
 p->fd_polls = 0;
 p->fd_rindices = 0;
-p->fds_changed = 0;
+p->fds_deregistered = 0;
 
 rc = libxl__pipe_nonblock(CTX, p->wakeup_pipe);
 if (rc) goto out;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ba8c9b41ab..c5b71d15f0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -629,14 +629,14 @@ struct libxl__poller {
 /*
  * We also use the poller to record whether any fds have been
  * deregistered since we entered poll.  Each poller which is not
- * idle is on the list pollers_fds_changed.  fds_changed is
+ * idle is on the list pollers_fds_changed.  fds_deregistered is
  * cleared by beforepoll, and tested by afterpoll.  Whenever an fd
- * event is deregistered, we set the fds_changed of all non-idle
+ * event is deregistered, we set the fds_deregistered of all non-idle
  * pollers.  So afterpoll can tell whether any POLLNVAL is
  * plausibly due to an fd being closed and reopened.
  */
 LIBXL_LIST_ENTRY(libxl__poller) fds_changed_entry;
-bool fds_changed;
+bool fds_deregistered;
 };
 
 struct libxl__gc {
-- 
2.11.0


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

[Xen-devel] [qemu-mainline test] 145923: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 144861
 build-arm64   6 xen-buildfail REGR. vs. 144861
 build-amd64   6 xen-buildfail REGR. vs. 144861
 build-i386-xsm6 xen-buildfail REGR. vs. 144861
 build-armhf   6 xen-buildfail REGR. vs. 144861
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144861
 build-i3866 xen-buildfail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 

Re: [Xen-devel] [PATCH v1 2/4] x86/xen: add basic KASAN support for PV kernel

[kbuild test robot]

Hi Sergey,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net-next/master]
[also build test ERROR on net/master linus/master v5.5-rc5 next-20200109]
[cannot apply to xen-tip/linux-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Sergey-Dyasli/basic-KASAN-support-for-Xen-PV-domains/20200110-042623
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
4a4a52d49d11f5c4a0df8b9806c8c5563801f753
config: x86_64-randconfig-b003-20200109 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   ld: arch/x86/mm/kasan_init_64.o: in function `kasan_init':
>> kasan_init_64.c:(.init.text+0x83c): undefined reference to 
>> `xen_pv_kasan_pin_pgd'
>> ld: kasan_init_64.c:(.init.text+0xc38): undefined reference to 
>> `xen_pv_kasan_unpin_pgd'

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation


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

Re: [Xen-devel] [RFC PATCH 1/3] x86/setup: Don't skip 2MiB underneath relocated Xen image

[David Woodhouse]

On Fri, 2020-01-10 at 11:15 +, Durrant, Paul wrote:
> > -Original Message-
> > From: Xen-devel  On Behalf
> > Of
> > David Woodhouse
> > Sent: 08 January 2020 17:25
> > To: Xen-devel 
> > Cc: Stefano Stabellini ; Julien Grall
> > ; Wei Liu ; Konrad Rzeszutek Wilk
> > ; George Dunlap <
> > george.dun...@eu.citrix.com>;
> > Andrew Cooper ; p...@xen.org; Ian
> > Jackson
> > ; Jan Beulich ; Roger
> > Pau
> > Monné 
> > Subject: [Xen-devel] [RFC PATCH 1/3] x86/setup: Don't skip 2MiB
> > underneath
> > relocated Xen image
> > 
> > From: David Woodhouse 
> > 
> > Set 'e' correctly to reflect the location that Xen is actually
> > relocated
> > to from its default 2MiB location. Not 2MiB below that.
> > 
> > Signed-off-by: David Woodhouse 
> > ---
> >  xen/arch/x86/setup.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 501f3f5e4b..47e065e5fe 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -1077,9 +1077,9 @@ void __init noreturn __start_xen(unsigned
> > long
> > mbi_p)
> >  unsigned long pte_update_limit;
> > 
> >  /* Select relocation address. */
> > -e = end - reloc_size;
> > -xen_phys_start = e;
> > -bootsym(trampoline_xen_phys_start) = e;
> > +xen_phys_start = end - reloc_size;
> > +e = xen_phys_start + XEN_IMG_OFFSET;
> > +bootsym(trampoline_xen_phys_start) = xen_phys_start;
> > 
> >  /*
> >   * No PTEs pointing above this address are candidates
> > for
> > relocation.
> 
> Do you not also need to adjust the setting of pte_update_limit that's
> just out of context below here?

Yes. I missed that when forward-porting to the master branch. Thanks.



smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v1 2/4] x86/xen: add basic KASAN support for PV kernel

[Sergey Dyasli]

On 09/01/2020 23:27, Boris Ostrovsky wrote:
> 
> 
> On 1/8/20 10:20 AM, Sergey Dyasli wrote:
>> @@ -1943,6 +1973,15 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, 
>> unsigned long max_pfn)
>>   if (i && i < pgd_index(__START_KERNEL_map))
>>   init_top_pgt[i] = ((pgd_t *)xen_start_info->pt_base)[i];
>>   +#ifdef CONFIG_KASAN
>> +    /*
>> + * Copy KASAN mappings
>> + * ec00 - fbff (=44 bits) kasan shadow memory 
>> (16TB)
>> + */
>> +    for (i = 0xec0 >> 3; i < 0xfc0 >> 3; i++)
> 
> Are you referring here to  KASAN_SHADOW_START and KASAN_SHADOW_END? If so, 
> can you use them instead?

Indeed, the following macros make the code neater:

#ifdef CONFIG_KASAN
/* Copy KASAN mappings */
for (i = pgd_index(KASAN_SHADOW_START);
 i < pgd_index(KASAN_SHADOW_END);
 i++)
init_top_pgt[i] = ((pgd_t *)xen_start_info->pt_base)[i];
#endif /* ifdef CONFIG_KASAN */

--
Thanks,
Sergey


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

[Xen-devel] [ovmf test] 145909: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
145767
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767

version targeted for testing:
 ovmf c0328cf3803b215a62f05633024f9dd6e5b805a0
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z2 days
Failing since145774  2020-01-08 02:50:20 Z2 days   12 attempts
Testing same since   145909  2020-01-10 05:39:15 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ashish Singhal 
  Eric Dong 
  Jason Voelz 
  Laszlo Ersek 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 
  Vitaly Cheptsov 
  Vitaly Cheptsov via Groups.Io 

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.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

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

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

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


Not pushing.


commit c0328cf3803b215a62f05633024f9dd6e5b805a0
Author: Philippe Mathieu-Daude 
Date:   Thu Jan 9 18:55:45 2020 +0800

BaseTools/PatchCheck.py: Check the patch author email address

To avoid patches committed with incorrect email address,
use the EmailAddressCheck class on the author email too.

Example:

  $ python BaseTools/Scripts/PatchCheck.py 1a04951309f
  Checking git commit: 1a04951309f
  The 'Author' email address is not valid:
  * The email address cannot contain a space: /o=Intel/ou=External \$
(FYDIBOHF25SPDLT)/cn=Recipients/cn=fe425ca7e5f4401abed22b904fe5d964

Cc: Bob Feng 
Cc: Liming Gao 
Reviewed-by: Bob Feng 
Signed-off-by: Philippe Mathieu-Daude 

commit 8120390aabe6bc6a6ecb5c94a2865a9b55095f9b
Author: Philippe Mathieu-Daude 
Date:   Thu Jan 9 18:55:44 2020 +0800

BaseTools/PatchCheck.py: Let EmailAddressCheck describe email checked

We are checking different emails from the signature list. We are
going to check more. To be able to differency, add a description
field, so the error reported is clearer.

Cc: Bob Feng 
Cc: Liming Gao 
Reviewed-by: Bob Feng 
Signed-off-by: Philippe Mathieu-Daude 

commit 8f38b08b506c0ea602444a09eda2f5ef1099498a
Author: Philippe Mathieu-Daude 
Date:   Thu Jan 9 18:55:46 2020 +0800

BaseTools/PatchCheck.py: Check the committer email address

To avoid patches committed with incorrect email address,
use the EmailAddressCheck class on the committer email too.

Cc: Bob Feng 
Cc: Liming Gao 
Reviewed-by: Bob Feng 
Signed-off-by: Philippe Mathieu-Daude 

commit 8ffa47fb3abd58ded6fe852ee9f518d19f9f9858
Author: Philippe Mathieu-Daude 
Date:   Thu Jan 9 18:55:43 2020 +0800

BaseTools/PatchCheck.py: Extract email check code to EmailAddressCheck

As we are going to reuse this code out of the CommitMessageCheck
class, extract it in a new class: EmailAddressCheck.

Cc: Bob Feng 
Cc: Liming Gao 
Reviewed-by: Bob Feng 
Signed-off-by: Philippe Mathieu-Daude 

commit 1f0d8096291651e6c20dbbc57d108321c1443563
Author: Jason Voelz 
Date:   Mon Dec 23 14:55:37 2019 +0800

UefiCpuPkg/CpuCommonFeaturesLib: SMXE bit of CR4 should set

Add code to set SMXE in CR4 in the SmxInitialize flow when SMX is enabled.

Signed-off-by: Jason Voelz 
Cc: Ray Ni 
Reviewed-by: Ray Ni 

commit 859046e000beecae6903e3f2143ffbd9944c7ee4
Author: Jason Voelz 
Date:   Mon Dec 23 14:55:36 2019 +0800

MdePkg 

Re: [Xen-devel] [RFC PATCH 1/3] x86/setup: Don't skip 2MiB underneath relocated Xen image

[Durrant, Paul]

> -Original Message-
> From: Xen-devel  On Behalf Of
> David Woodhouse
> Sent: 08 January 2020 17:25
> To: Xen-devel 
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George Dunlap ;
> Andrew Cooper ; p...@xen.org; Ian Jackson
> ; Jan Beulich ; Roger Pau
> Monné 
> Subject: [Xen-devel] [RFC PATCH 1/3] x86/setup: Don't skip 2MiB underneath
> relocated Xen image
> 
> From: David Woodhouse 
> 
> Set 'e' correctly to reflect the location that Xen is actually relocated
> to from its default 2MiB location. Not 2MiB below that.
> 
> Signed-off-by: David Woodhouse 
> ---
>  xen/arch/x86/setup.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 501f3f5e4b..47e065e5fe 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1077,9 +1077,9 @@ void __init noreturn __start_xen(unsigned long
> mbi_p)
>  unsigned long pte_update_limit;
> 
>  /* Select relocation address. */
> -e = end - reloc_size;
> -xen_phys_start = e;
> -bootsym(trampoline_xen_phys_start) = e;
> +xen_phys_start = end - reloc_size;
> +e = xen_phys_start + XEN_IMG_OFFSET;
> +bootsym(trampoline_xen_phys_start) = xen_phys_start;
> 
>  /*
>   * No PTEs pointing above this address are candidates for
> relocation.

Do you not also need to adjust the setting of pte_update_limit that's just out 
of context below here?

  Paul
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests

[Jan Beulich]

On 10.01.2020 11:37, Sergey Dyasli wrote:
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -995,6 +995,12 @@ void hvmloader_acpi_build_tables(struct acpi_config 
> *config,
>  hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->vm_gid_addr);
>  }
>  
> +void xsm_filter_denied(char *str, size_t len)
> +{
> +if ( strcmp(str, "") == 0 )
> +memset(str, 0, len);
> +}

I think you can get away without passing in "len":

void xsm_filter_denied(char *str, size_t len)
{
if ( strcmp(str, "") == 0 )
*str = 0;
}

Any reason you think you need to zap the entire buffer?

> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -750,14 +750,17 @@ static XSM_INLINE int xsm_xen_version (XSM_DEFAULT_ARG 
> uint32_t op)
>  case XENVER_get_features:
>  /* These sub-ops ignore the permission checks and return data. */
>  return 0;
> -case XENVER_extraversion:

Could you take the opportunity and also add the missing blank
line here, just like you do below?

> -case XENVER_compile_info:
>  case XENVER_capabilities:
> -case XENVER_changeset:
>  case XENVER_pagesize:
>  case XENVER_guest_handle:
>  /* These MUST always be accessible to any guest by default. */
>  return xsm_default_action(XSM_HOOK, current->domain, NULL);
> +
> +case XENVER_extraversion:
> +case XENVER_compile_info:
> +case XENVER_changeset:
> +case XENVER_commandline:
> +case XENVER_build_id:
>  default:
>  return xsm_default_action(XSM_PRIV, current->domain, NULL);

I continue to not see the need to have "default:" accompanied by
various specific case labels. I don't think we do so elsewhere.
And if you do, "default:" should gain ASSERT_UNREACHABLE() imo. I
also remain unconvinced of the very brief reasoning - as indicated
before, it would seem at least desirable to me to discuss why the
previous decision was wrong (iirc the implication back then was
that anyone wanting to tighten this would be supposed to use a
respective XSM policy).

In any event - if the hvmloader change was submitted as a separate
patch, I'd ack it with the change suggested (or a suitable verbal
clarification in reply to my remark above).

Jan

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

Re: [Xen-devel] [PATCH v1 2/4] x86/xen: add basic KASAN support for PV kernel

[Sergey Dyasli]

On 09/01/2020 09:15, Jürgen Groß wrote:
> On 08.01.20 16:20, Sergey Dyasli wrote:
>> This enables to use Outline instrumentation for Xen PV kernels.
>>
>> KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
>> and hence disabled.
>>
>> Signed-off-by: Sergey Dyasli 
>> ---
>> RFC --> v1:
>> - New functions with declarations in xen/xen-ops.h
>> - Fixed the issue with free_kernel_image_pages() with the help of
>>xen_pv_kasan_unpin_pgd()
>> ---
>>   arch/x86/mm/kasan_init_64.c | 12 
>>   arch/x86/xen/Makefile   |  7 +++
>>   arch/x86/xen/enlighten_pv.c |  3 +++
>>   arch/x86/xen/mmu_pv.c   | 39 +
>>   drivers/xen/Makefile|  2 ++
>>   include/xen/xen-ops.h   |  4 
>>   kernel/Makefile |  2 ++
>>   lib/Kconfig.kasan   |  3 ++-
>>   8 files changed, 71 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
>> index cf5bc37c90ac..902a6a152d33 100644
>> --- a/arch/x86/mm/kasan_init_64.c
>> +++ b/arch/x86/mm/kasan_init_64.c
>> @@ -13,6 +13,9 @@
>>   #include 
>>   #include 
>>   +#include 
>> +#include 
>> +
>>   #include 
>>   #include 
>>   #include 
>> @@ -332,6 +335,11 @@ void __init kasan_early_init(void)
>>   for (i = 0; pgtable_l5_enabled() && i < PTRS_PER_P4D; i++)
>>   kasan_early_shadow_p4d[i] = __p4d(p4d_val);
>>   +if (xen_pv_domain()) {
>> +pgd_t *pv_top_pgt = xen_pv_kasan_early_init();
>
> You are breaking the build with CONFIG_XEN_PV undefined here.

Right, the following is needed:

diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 91d66520f0a3..3d20f000af12 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -241,8 +241,14 @@ static inline void xen_preemptible_hcall_end(void)

 #endif /* CONFIG_PREEMPT */

+#if defined(CONFIG_XEN_PV)
 pgd_t *xen_pv_kasan_early_init(void);
 void xen_pv_kasan_pin_pgd(pgd_t *pgd);
 void xen_pv_kasan_unpin_pgd(pgd_t *pgd);
+#else
+static inline pgd_t *xen_pv_kasan_early_init(void) { return NULL; }
+static inline void xen_pv_kasan_pin_pgd(pgd_t *pgd) { }
+static inline void xen_pv_kasan_unpin_pgd(pgd_t *pgd) { }
+#endif /* defined(CONFIG_XEN_PV) */

 #endif /* INCLUDE_XEN_OPS_H */

--
Thanks,
Sergey

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

[Xen-devel] [qemu-mainline test] 145915: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 144861
 build-arm64   6 xen-buildfail REGR. vs. 144861
 build-amd64   6 xen-buildfail REGR. vs. 144861
 build-i386-xsm6 xen-buildfail REGR. vs. 144861
 build-armhf   6 xen-buildfail REGR. vs. 144861
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144861
 build-i3866 xen-buildfail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 build-armhf-libvirt

Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests

[Andrew Cooper]

On 10/01/2020 10:37, Sergey Dyasli wrote:
> Hide the following information that can help identify the running Xen
> binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
> Add explicit cases for XENVER_commandline and XENVER_build_id as well.
>
> Introduce xsm_filter_denied() to hvmloader to remove "" string
> from guest's DMI tables that otherwise would be shown in tools like
> dmidecode.
>
> Signed-off-by: Sergey Dyasli 
> ---
> v1 --> v2:
> - Added xsm_filter_denied() to hvmloader instead of modifying xen_deny()
> - Made behaviour the same for both Release and Debug builds
> - XENVER_capabilities is no longer hided
>
> CC: Andrew Cooper 
> CC: George Dunlap 
> CC: Ian Jackson 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Wei Liu 
> CC: Daniel De Graaf 

I realise there are arguments over how to fix this, but we (the Xen
community) have already f*cked up once here, and this is doing so a
second time.

Nack.

Fixing it anywhere other than Xen is simply not appropriate.

The reason for this (which ought to be obvious, but I guess only to
those who actually do customer support) is basic human physiology. 
"denied" means something has gone wrong.  It scares people, and causes
them to seek help to change fix whatever is broken.

It is not appropriate for it to find its way into the guest in the first
place, and that includes turning up in `dmesg` and other logs, and
expecting guest runtime to filter for it is complete nonsense.

As said several times before, the empty string is completely fine ABI
wise, doesn't confuse customers, and really really does work in practice.

~Andrew

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

Re: [Xen-devel] [PATCH] tools/Rules.mk: fix distclean

[Wei Liu]

On Thu, Jan 09, 2020 at 04:41:06PM +, Wei Liu wrote:
> On Thu, Jan 09, 2020 at 02:02:55PM +, Durrant, Paul wrote:
> > > -Original Message-
> > > From: Wei Liu 
> > > Sent: 09 January 2020 13:52
> > > To: Durrant, Paul 
> > > Cc: xen-devel@lists.xenproject.org; Ian Jackson
> > > ; Wei Liu ; Anthony PERARD
> > > 
> > > Subject: Re: [PATCH] tools/Rules.mk: fix distclean
> > > 
> > > On Thu, Jan 09, 2020 at 11:15:05AM +, Paul Durrant wrote:
> > > > Running 'make distclean' under tools will currently result in:
> > > >
> > > > tools/Rules.mk:245: *** You have to run ./configure before building or
> > > installing the tools.  Stop.
> > > >
> > > > This patch adds 'distclean', 'subdir-distclean%' and 'subdir-clean%' to
> > > > no-configure-targets, which allows 'make distclean' to run to
> > > completion.
> > > >
> > > > Signed-off-by: Paul Durrant 
> > > 
> > > Fixes: 00691c6c90b
> > > 
> > > Sorry for not noticing the breakage while reviewing that patch.
> > > 
> > 
> > Ok. I'm sure that could be added at commit if there are no other changes 
> > needed.
> 
> Yes. Sure.
> 
> > 
> > > Is there a way to pattern match all targets containing "clean"?
> > > 
> > > (Would have looked into it myself but -ETIME today)
> > 
> > I couldn't persuade filter to match against patterns with multiple %
> > so this was the best I could come up with.
> > 
> 
> OK.

If I hear no objection or suggestion for improvement today I will commit
this patch.

Wei.

> 
> Wei.

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

[Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests

[Sergey Dyasli]

Hide the following information that can help identify the running Xen
binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
Add explicit cases for XENVER_commandline and XENVER_build_id as well.

Introduce xsm_filter_denied() to hvmloader to remove "" string
from guest's DMI tables that otherwise would be shown in tools like
dmidecode.

Signed-off-by: Sergey Dyasli 
---
v1 --> v2:
- Added xsm_filter_denied() to hvmloader instead of modifying xen_deny()
- Made behaviour the same for both Release and Debug builds
- XENVER_capabilities is no longer hided

CC: Andrew Cooper 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Julien Grall 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Wei Liu 
CC: Daniel De Graaf 
---
 tools/firmware/hvmloader/hvmloader.c | 1 +
 tools/firmware/hvmloader/smbios.c| 1 +
 tools/firmware/hvmloader/util.c  | 6 ++
 tools/firmware/hvmloader/util.h  | 2 ++
 xen/include/xsm/dummy.h  | 9 ++---
 5 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 598a226278..e760ed5fa6 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -147,6 +147,7 @@ static void init_hypercalls(void)
 /* Print version information. */
 cpuid(base + 1, , , , );
 hypercall_xen_version(XENVER_extraversion, extraversion);
+xsm_filter_denied(extraversion, sizeof(extraversion));
 printf("Detected Xen v%u.%u%s\n", eax >> 16, eax & 0x, extraversion);
 }
 
diff --git a/tools/firmware/hvmloader/smbios.c 
b/tools/firmware/hvmloader/smbios.c
index 97a054e9e3..1ba352ed2c 100644
--- a/tools/firmware/hvmloader/smbios.c
+++ b/tools/firmware/hvmloader/smbios.c
@@ -275,6 +275,7 @@ hvm_write_smbios_tables(
 xen_minor_version = (uint16_t) xen_version;
 
 hypercall_xen_version(XENVER_extraversion, xen_extra_version);
+xsm_filter_denied(xen_extra_version, sizeof(xen_extra_version));
 
 /* build up human-readable Xen version string */
 p = xen_version_str;
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 0c3f2d24cd..09e355fa3d 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -995,6 +995,12 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->vm_gid_addr);
 }
 
+void xsm_filter_denied(char *str, size_t len)
+{
+if ( strcmp(str, "") == 0 )
+memset(str, 0, len);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 7bca6418d2..f7d907ca00 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -286,6 +286,8 @@ struct acpi_config;
 void hvmloader_acpi_build_tables(struct acpi_config *config,
  unsigned int physical);
 
+void xsm_filter_denied(char *str, size_t len);
+
 #endif /* __HVMLOADER_UTIL_H__ */
 
 /*
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b8e185e6fa..d15b078f10 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -750,14 +750,17 @@ static XSM_INLINE int xsm_xen_version (XSM_DEFAULT_ARG 
uint32_t op)
 case XENVER_get_features:
 /* These sub-ops ignore the permission checks and return data. */
 return 0;
-case XENVER_extraversion:
-case XENVER_compile_info:
 case XENVER_capabilities:
-case XENVER_changeset:
 case XENVER_pagesize:
 case XENVER_guest_handle:
 /* These MUST always be accessible to any guest by default. */
 return xsm_default_action(XSM_HOOK, current->domain, NULL);
+
+case XENVER_extraversion:
+case XENVER_compile_info:
+case XENVER_changeset:
+case XENVER_commandline:
+case XENVER_build_id:
 default:
 return xsm_default_action(XSM_PRIV, current->domain, NULL);
 }
-- 
2.17.1


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 145842
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 145842
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  e90a643c90af66ce146f426861dc9a226c1caf62
baseline version:
 libvirt  832656fa8e6f7bfa6eb5f6f7de5ede697c6392e8

Last test of basis   145842  2020-01-09 04:18:43 Z1 days
Testing same since   145906  2020-01-10 04:18:44 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrangé 
  Michal Privoznik 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-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-arm64-arm64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/libvirt.git
   832656fa8e..e90a643c90  e90a643c90af66ce146f426861dc9a226c1caf62 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH] Introduce CHANGELOG.md

[Durrant, Paul]

> -Original Message-
> From: Jan Beulich 
> Sent: 10 January 2020 09:52
> To: Durrant, Paul 
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ;
> Ian Jackson ; Julien Grall ;
> Konrad Rzeszutek Wilk ; Stefano Stabellini
> ; Wei Liu ; Lars Kurth
> 
> Subject: Re: [PATCH] Introduce CHANGELOG.md
> 
> On 10.01.2020 10:12, Paul Durrant wrote:
> > --- /dev/null
> > +++ b/CHANGELOG.md
> > @@ -0,0 +1,14 @@
> > +# Changelog
> > +
> > +All notable changes to Xen will be documented in this file.
> 
> How do we qualify what's "notable" and what's not? IOW I wonder
> whether "All" should be dropped, or be replaced by "Some".
> 

Agreed that it's debatable. Perhaps just drop the 'All' and say:

'Notable changes to Xen will be documented in this file.'

?

Patch authors ought to update the file if they consider their contribution(s) 
notable but I'd also hope that maintainers will express an opinion as to 
whether something should be included/not included. It's not going to be 
fool-proof but I think it will be better than nothing.

  Paul

> Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] Introduce CHANGELOG.md

[Lars Kurth]

On 10/01/2020, 09:12, "Paul Durrant"  wrote:

As agreed during the 2020-01 community call [1] this patch introduces a
changelog, based on the principles explained at keepachangelog.com [2].
A new MAINTAINERS entry is also added, with myself as (currently sole)
maintainer.

[1] See C.2 at 
https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6Htl-AJ/
[2] https://keepachangelog.com/en/1.0.0/

Signed-off-by: Paul Durrant 


Thank you Paul
Exactly what I was looking for

Reviewed-by: Lars Kurth 

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

Re: [Xen-devel] [PATCH] Introduce CHANGELOG.md

[Jan Beulich]

On 10.01.2020 10:12, Paul Durrant wrote:
> --- /dev/null
> +++ b/CHANGELOG.md
> @@ -0,0 +1,14 @@
> +# Changelog
> +
> +All notable changes to Xen will be documented in this file.

How do we qualify what's "notable" and what's not? IOW I wonder
whether "All" should be dropped, or be replaced by "Some".

Jan

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

[Xen-devel] [PATCH] Introduce CHANGELOG.md

[Paul Durrant]

As agreed during the 2020-01 community call [1] this patch introduces a
changelog, based on the principles explained at keepachangelog.com [2].
A new MAINTAINERS entry is also added, with myself as (currently sole)
maintainer.

[1] See C.2 at https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6Htl-AJ/
[2] https://keepachangelog.com/en/1.0.0/

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Wei Liu 
Cc: Lars Kurth 

Should there be other maintainers apart from myself (with my RM hat on)?
Perhaps Lars should also be added as a designated reviewer?
---
 CHANGELOG.md | 14 ++
 MAINTAINERS  |  5 +
 2 files changed, 19 insertions(+)
 create mode 100644 CHANGELOG.md

diff --git a/CHANGELOG.md b/CHANGELOG.md
new file mode 100644
index 00..ec5e174aa0
--- /dev/null
+++ b/CHANGELOG.md
@@ -0,0 +1,14 @@
+# Changelog
+
+All notable changes to Xen will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
+
+## [Unreleased](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog)
+
+### Added
+ - This file and MAINTAINERS entry.
+
+## 
[4.13.0](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.13.0) 
- 2019-12-17
+
+> Pointer to release from which CHANGELOG tracking starts
diff --git a/MAINTAINERS b/MAINTAINERS
index d5bd83073c..68c691361a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -198,6 +198,11 @@ F: xen/include/asm-arm/
 F: xen/include/public/arch-arm/
 F: xen/include/public/arch-arm.h
 
+Change Log
+M: Paul Durrant 
+S: Maintained
+F: CHANGELOG.md
+
 Continuous Integration (CI)
 M: Doug Goldstein 
 W: https://gitlab.com/xen-project/xen
-- 
2.17.1


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

[Xen-devel] [PATCH] MAINTAINERS: Update my email address

[Paul Durrant]

It is now more covenient for me to use my Amazon address.

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Wei Liu 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a42fef6ab9..d5bd83073c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -480,7 +480,7 @@ F:  tools/tests/cpu-policy/
 F: tools/tests/x86_emulator/
 
 X86 I/O EMULATION
-M: Paul Durrant 
+M: Paul Durrant 
 S: Supported
 F: xen/arch/x86/hvm/emulate.c
 F: xen/arch/x86/hvm/intercept.c
@@ -512,7 +512,7 @@ S:  Maintained
 F: xen/arch/x86/mm/shadow/
 
 X86 VIRIDIAN ENLIGHTENMENTS
-M: Paul Durrant 
+M: Paul Durrant 
 S: Supported
 F: xen/arch/x86/hvm/viridian/
 F: xen/include/asm-x86/hvm/viridian.h
-- 
2.17.1


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

[Xen-devel] [qemu-mainline test] 145908: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 144861
 build-arm64   6 xen-buildfail REGR. vs. 144861
 build-amd64   6 xen-buildfail REGR. vs. 144861
 build-i386-xsm6 xen-buildfail REGR. vs. 144861
 build-armhf   6 xen-buildfail REGR. vs. 144861
 build-amd64-xsm   6 xen-buildfail REGR. vs. 144861
 build-i3866 xen-buildfail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1