[Xen-devel] [xen-4.4-testing test] 102521: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop   fail REGR. vs. 101268
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101256
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101268
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101268

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun7 xen-buildfail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-5   16 xtf/test-pv32pae-selftestfail   never pass
 test-xtf-amd64-amd64-5   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4   16 xtf/test-pv32pae-selftestfail   never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-xtf-amd64-amd64-3   16 xtf/test-pv32pae-selftestfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-3   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   16 xtf/test-pv32pae-selftestfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-5 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   16 xtf/test-pv32pae-selftestfail   never pass
 test-xtf-amd64-amd64-4 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-3 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-3   49 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-3  51 xtf/test-pv64-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-3   52 xtf/test-pv64-pv-iopl~vmassist fail never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2   49 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-2  51 xtf/test-pv64-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-2   52 xtf/test-pv64-pv-iopl~vmassist fail never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-xtf-amd64-amd64-4   49 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-5   49 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-1   49 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-4  51 xtf/test-pv64-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-4   52 xtf/test-pv64-pv-iopl~vmassist fail never pass
 test-xtf-amd64-amd64-1  51 xtf/test-pv64-pv-iopl~hypercall fail never pass
 test-xtf-amd64-amd64-1   52 xtf/test-pv64-pv-iopl~vmassist fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5  51 

[Xen-devel] [xen-4.6-testing test] 102519: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 101938
 test-xtf-amd64-amd64-3 29 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 101938
 test-xtf-amd64-amd64-3   40 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 101938
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
101938
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 101938

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

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

version targeted for testing:
 xen  514173d3f8623194aa607f71866a240d02d432e8
baseline version:
 xen  fa062b2b9a49fa8f0cb44a3854a121b31f40c10d

Last test of basis   101938  2016-11-04 21:43:52 Z   18 days
Testing same since   102519  2016-11-22 13:42:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Beulich 

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

Re: [Xen-devel] [PATCH 1/2] build system: Include SeaBIOS and TianoCore directory

[Konrad Rzeszutek Wilk]

On Wed, Nov 23, 2016 at 02:39:35AM +, Wei Liu wrote:
> On Sun, Nov 20, 2016 at 10:27:21PM -0500, Konrad Rzeszutek Wilk wrote:
> > The release source did not include those two directories.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> >  tools/misc/mktarball | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/tools/misc/mktarball b/tools/misc/mktarball
> > index 73282b5..7942846 100755
> > --- a/tools/misc/mktarball
> > +++ b/tools/misc/mktarball
> > @@ -35,6 +35,11 @@ git_archive_into 
> > $xen_root/tools/qemu-xen-traditional-dir-remote $tdir/xen-$desc
> >  
> >  git_archive_into $xen_root/extras/mini-os-remote 
> > $tdir/xen-$desc/extras/mini-os
> >  
> > +git_archive_into $xen_root/tools/firmware/seabios-dir-remote 
> > $tdir/xen-$desc/tools/firmware/seabios-dir
> > +
> > +if [ -d $xen_root/tools/firmware/ovmf-dir-remote ]; then
> 
> Is this test really needed? I think subtree-force-update-all will clone
> ovmf anyway.

I think it only does that if CONFIG_OVMF is in your local .config -
which is only the case if you run ./configure --enable-ovmf


> 
> > +git_archive_into $xen_root/tools/firmware/ovmf-dir-remote 
> > $tdir/xen-$desc/tools/firmware/ovmf-dir
> > +fi
> >  GZIP=-9v tar cz -f $xen_root/dist/xen-$desc.tar.gz -C $tdir xen-$desc
> >  
> >  echo "Source tarball in $xen_root/dist/xen-$desc.tar.gz"
> > -- 
> > 2.9.3
> > 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [edk2] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

[Jordan Justen]

On 2016-11-22 18:36:43, Konrad Rzeszutek Wilk wrote:
> From Laszlo:
> " change the catch-all (*) to GCC5, from GCC44
> - remove the (5.*.*) pattern from GCC49
> - add a branch (with multiple patterns if necessary) for gcc-4.3 and
>   earlier to exit with an error message / failure (those compiler
>   versions are unsupported)"

For future reference, I'd suggest this for the formatting of your
commit message body.

v2:
 * Changes suggested by Laszlo:
   - change the catch-all (*) to GCC5, from GCC44
   - remove the (5.*.*) pattern from GCC49
   - generate error for GCC < 4.4

Patch is Reviewed-by: Jordan Justen 

I'll let Laszlo take a look too.

Thanks for the contribution!

-Jordan

> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
> v1: First submission
> v2: Redo it per Laszlo suggestion.
> 
>  OvmfPkg/build.sh | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index eb5eb73..cab7c70 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -83,6 +83,13 @@ case `uname` in
>Linux*)
>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>  case $gcc_version in
> +  4.1.[0-0].*|4.2.*|4.3.*)
> +echo OvmfPkg requires GCC4.4 or later
> +exit 1
> +;;
> +  4.4.*)
> +TARGET_TOOLS=GCC44
> +;;
>4.5.*)
>  TARGET_TOOLS=GCC45
>  ;;
> @@ -95,11 +102,11 @@ case `uname` in
>4.8.*)
>  TARGET_TOOLS=GCC48
>  ;;
> -  4.9.*|4.1[0-9].*|5.*.*)
> +  4.9.*)
>  TARGET_TOOLS=GCC49
>  ;;
>*)
> -TARGET_TOOLS=GCC44
> +TARGET_TOOLS=GCC5
>  ;;
>  esac
>  esac
> -- 
> 2.9.3
> 
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [Xen-devel] [PATCH XSA-followup for-4.8] libelf: fix symtab/strtab loading for 32bit domains

[Wei Liu]

On Tue, Nov 22, 2016 at 05:39:37PM +, Roger Pau Monne wrote:
> Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
> guests, that corrupted the section headers array due to the padding
> introduced by the elf_shdr union.
> 
> The Elf section header array on 32bit should be accessible as an array of
> Elf32_Shdr elements, and the union with Elf64_Shdr done in elf_shdr was
> breaking this due to size differences between Elf32_Shdr and Elf64_Shdr.
> 
> Fix this by copying each section header one by one, and using the proper
> size depending on the bitness of the guest kernel. While there, also fix
> a couple of consistency issues, by making sure we always use the sizes of
> our local versions of the ELF header and the ELF sections headers.
> 
> Reported-by: Brian Marcotte 
> Signed-off-by: Roger Pau Monné 
> Acked-by: Ian Jackson 
> Reviewed-by: Jan Beulich 

This doesn't seem to build for me.

64 bit:

../../xen/common/libelf/libelf-loader.c: In function ‘elf_load_bsdsyms’:
../../xen/common/libelf/libelf-loader.c:304:5: error: ‘ehdr_size’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
 elf_memcpy_safe(elf, ELF_HANDLE_PTRVAL(header_handle),
 ^
../../xen/common/libelf/libelf-loader.c:264:30: note: ‘ehdr_size’ was declared 
here
 unsigned long shdr_size, ehdr_size, header_size;
  ^
../../xen/common/libelf/libelf-loader.c:312:99: error: ‘shdr_size’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
 elf_store_field_bitness(elf, header_handle, e_shentsize, shdr_size);

   ^
../../xen/common/libelf/libelf-loader.c:264:19: note: ‘shdr_size’ was declared 
here
 unsigned long shdr_size, ehdr_size, header_size;
   ^
cc1: all warnings being treated as errors

32 bit:

../../xen/common/libelf/libelf-loader.c:304:20: error: 'ehdr_size' may be used 
uninitialized in this function [-Werror=uninitialized]
../../xen/common/libelf/libelf-loader.c:312:5: error: 'shdr_size' may be used 
uninitialized in this function [-Werror=uninitialized]

This patch is applied on top of 986f790e0184d4bf575462077378e14fa9f85aa9.

Wei.

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

Re: [Xen-devel] [PATCH 1/2] build system: Include SeaBIOS and TianoCore directory

[Wei Liu]

On Sun, Nov 20, 2016 at 10:27:21PM -0500, Konrad Rzeszutek Wilk wrote:
> The release source did not include those two directories.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  tools/misc/mktarball | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tools/misc/mktarball b/tools/misc/mktarball
> index 73282b5..7942846 100755
> --- a/tools/misc/mktarball
> +++ b/tools/misc/mktarball
> @@ -35,6 +35,11 @@ git_archive_into 
> $xen_root/tools/qemu-xen-traditional-dir-remote $tdir/xen-$desc
>  
>  git_archive_into $xen_root/extras/mini-os-remote 
> $tdir/xen-$desc/extras/mini-os
>  
> +git_archive_into $xen_root/tools/firmware/seabios-dir-remote 
> $tdir/xen-$desc/tools/firmware/seabios-dir
> +
> +if [ -d $xen_root/tools/firmware/ovmf-dir-remote ]; then

Is this test really needed? I think subtree-force-update-all will clone
ovmf anyway.

> +git_archive_into $xen_root/tools/firmware/ovmf-dir-remote 
> $tdir/xen-$desc/tools/firmware/ovmf-dir
> +fi
>  GZIP=-9v tar cz -f $xen_root/dist/xen-$desc.tar.gz -C $tdir xen-$desc
>  
>  echo "Source tarball in $xen_root/dist/xen-$desc.tar.gz"
> -- 
> 2.9.3
> 

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

[Xen-devel] [PATCH v2] Compile TianoCore under Fedora Core 25

[Konrad Rzeszutek Wilk]

Hey!

This patch allows me to compile TianoCore under Fedora Core 25.

I've also tested it under some older ancient distros, such as:

Ubuntu 16.04.1 (GCC 5.4.0), uses GCC5
Debian 8.6 (GCC 4.9.2), uses GCC49
Fedora Core 13 (GCC 4.4.4), uses GCC44
RHEL6 (GCC 4.4.7), uses GCC44
RHEL5 (GCC 4.1.2), it does not even get to the message:

$  OvmfPkg/build.sh -a X64 -b RELEASE -n 4
Initializing workspace
/home/konrad/ovmf-dir-remote/BaseTools
Loading previous configuration from 
/home/konrad/ovmf-dir-remote/Conf/BuildEnv.sh
WORKSPACE: /home/konrad/ovmf-dir-remote
EDK_TOOLS_PATH: /home/konrad/ovmf-dir-remote/BaseTools
CONF_PATH: /home/konrad/ovmf-dir-remote/Conf
using prebuilt tools
Running edk2 build for OvmfPkgX64
  File 
"/home/konrad/ovmf-dir-remote/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
 line 703
class PeImageInfo():
  ^
SyntaxError: invalid syntax

Please review the patch at your convience.

Konrad Rzeszutek Wilk (1):
  OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

 OvmfPkg/build.sh | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

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

[Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

[Konrad Rzeszutek Wilk]

From Laszlo:
" change the catch-all (*) to GCC5, from GCC44
- remove the (5.*.*) pattern from GCC49
- add a branch (with multiple patterns if necessary) for gcc-4.3 and
  earlier to exit with an error message / failure (those compiler
  versions are unsupported)"

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Konrad Rzeszutek Wilk 
---
v1: First submission
v2: Redo it per Laszlo suggestion.

 OvmfPkg/build.sh | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
index eb5eb73..cab7c70 100755
--- a/OvmfPkg/build.sh
+++ b/OvmfPkg/build.sh
@@ -83,6 +83,13 @@ case `uname` in
   Linux*)
 gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
 case $gcc_version in
+  4.1.[0-0].*|4.2.*|4.3.*)
+echo OvmfPkg requires GCC4.4 or later
+exit 1
+;;
+  4.4.*)
+TARGET_TOOLS=GCC44
+;;
   4.5.*)
 TARGET_TOOLS=GCC45
 ;;
@@ -95,11 +102,11 @@ case `uname` in
   4.8.*)
 TARGET_TOOLS=GCC48
 ;;
-  4.9.*|4.1[0-9].*|5.*.*)
+  4.9.*)
 TARGET_TOOLS=GCC49
 ;;
   *)
-TARGET_TOOLS=GCC44
+TARGET_TOOLS=GCC5
 ;;
 esac
 esac
-- 
2.9.3


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

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

[Lan Tianyu]

On 2016年11月21日 15:05, Tian, Kevin wrote:
>> If someone add "intel_iommu=on" kernel parameter manually, IOMMU driver
>> > will panic guest because it can't enable DMA remapping function via gcmd
>> > register and "Translation Enable Status" bit in gsts register is never
>> > set by vIOMMU. This shows actual vIOMMU status that there is no l2
>> > translation support and warn user should not enable l2 translation.
> The rationale of section 3.5 is confusing. Do you mean sth. like below?
> 
> - We can first do IRQ remapping, because DMA remapping (l1/l2) and 
> IRQ remapping can be enabled separately according to VT-d spec. Enabling 
> of DMA remapping will be first emulated as a failure, which may lead
> to guest kernel panic if intel_iommu is turned on in the guest. But it's
> not a big problem because major distributions have DMA remapping
> disabled by default while IRQ remapping is enabled.
> 
> - For DMA remapping, likely you'll enable L2 translation first (there is
> no capability bit) with L1 translation disabled (there is a SVM capability 
> bit). 
> 
> If yes, maybe we can break this design into 3 parts too, so both
> design review and implementation side can move forward step by
> step?
> 

Yes, we may implement IRQ remapping first. I will break this design into
3 parts(interrupt remapping, L2 translation and L1 translation). IRQ
remapping will be first one to be sent out for detail discussion.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Boris Ostrovsky]

On 11/22/2016 11:25 AM, Boris Ostrovsky wrote:



On 11/22/2016 11:01 AM, Jan Beulich wrote:

On 22.11.16 at 16:43,  wrote:




On 11/22/2016 10:07 AM, Jan Beulich wrote:

On 22.11.16 at 15:37,  wrote:




On 11/22/2016 08:59 AM, Jan Beulich wrote:

On 22.11.16 at 13:34,  wrote:




On 11/22/2016 05:39 AM, Jan Beulich wrote:

On 22.11.16 at 11:31,  wrote:

On 21.11.16 at 22:00,  wrote:

This domctl is called when a VCPU is hot-(un)plugged to a
guest (via
'xl vcpu-set').

The primary reason for adding this call is because for PVH guests
the hypervisor needs to send an SCI and set GPE registers.
This is
unlike HVM guests that have qemu to perform these tasks.


And the tool stack can't do this?


For the avoidance of further misunderstandings: Of course likely
not completely on its own, but by using a (to be introduced) more
low level hypervisor interface (setting arbitrary GPE bits, with
SCI
raised as needed, or the SCI raising being another hypercall).


So you are suggesting breaking up XEN_DOMCTL_set_avail_vcpus into

XEN_DOMCTL_set_acpi_reg(io_offset, length, val)
XEN_DOMCTL_set_avail_vcpus(avail_vcpus_bitmap)
XEN_DOMCTL_send_virq(virq)

(with perhaps set_avail_vcpus folded into set_acpi_reg) ?


Well, I don't see what set_avail_vcpus would be good for
considering that during v2 review you've said that you need it
just for the GPE modification and SCI sending.



Someone needs to provide the hypervisor with the new number of
available
(i.e. hot-plugged/unplugged) VCPUs, thus the name of the domctl.
GPE/SCI
manipulation are part of that update.

(I didn't say it during v2 review and I should have)


And I've just found that need while looking over patch 8. With
that I'm not sure the splitting would make sense, albeit we may
find it necessary to fiddle with other GPE bits down the road.


Just to make sure we are talking about the same thing:
XEN_DOMCTL_set_acpi_reg is sufficient for both GPE and CPU map (or any
ACPI register should the need arise)


Well, my point is that as long as we continue to need
set_avail_vcpus (which I hear you say we do need), I'm not
sure the splitting would be helpful (minus the "albeit" part
above).



So the downside of having set_avail is that if we ever find this need to
touch ACPI registers we will be left with a useless (or at least
redundant) domctl.

Let me try to have set_acpi_reg and see if it looks good enough. If
people don't like it then I'll go back to set_avail_vcpus.


(apparently I replied to Jan only. Resending to everyone)

I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with 
XEN_DOMCTL_acpi_access and it seems to work OK. The toolstack needs to 
perform two (or more, if >32 VCPUs) hypercalls and the logic on the 
hypervisor side is almost the same as the ioreq handling that this 
series added in patch 8.


However, I now realized that this interface will not be available to PV 
guests (and it will only become available to HVM guests when we move 
hotplug from qemu to hypervisor). And it's x86-specific.


This means that PV guests will not know what the number of available 
VCPUs is and therefore we will not be able to enforce it. OTOH we don't 
know how to do that anyway since PV guests bring up all VCPUs and then 
offline them.


-boris

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

[Xen-devel] [xen-4.5-testing test] 102520: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt  14 guest-saverestorefail REGR. vs. 101275
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101275
 test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail REGR. vs. 
101275
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
101275

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101258
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 101275
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101275
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101275
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101275

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-3   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-3 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-4 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-xtf-amd64-amd64-1  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-5 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-xtf-amd64-amd64-4   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-xtf-amd64-amd64-2  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-5  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds   

[Xen-devel] [xen-4.7-testing test] 102518: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101949
 test-amd64-amd64-libvirt 11 guest-start  fail REGR. vs. 101949
 test-armhf-armhf-xl-xsm   5 xen-install  fail REGR. vs. 101949
 test-armhf-armhf-xl-arndale   6 xen-boot fail REGR. vs. 101949
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 101949
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail REGR. vs. 101949
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-install fail REGR. vs. 101949
 test-armhf-armhf-libvirt15 guest-start/debian.repeat fail REGR. vs. 101949
 test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 101949

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

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

version targeted for testing:
 xen  206fc7084dfaf05c55fd9de650f93a7ef9fe0722
baseline version:
 xen  86f912c86501b9a3c1abf908731e7d86778a594e

Last test of basis   101949  2016-11-05 06:01:53 Z   17 days
Testing same since   102518  2016-11-22 13:41:48 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Beulich 
  Roger Pau Monné 

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

Re: [Xen-devel] [PATCH v3 06/11] acpi: PVH guests need _E02 method

[Konrad Rzeszutek Wilk]

On Mon, Nov 21, 2016 at 04:00:42PM -0500, Boris Ostrovsky wrote:
> This is the method that will get invoked on an SCI.
> 
> Signed-off-by: Boris Ostrovsky 
> Acked-by: Jan Beulich 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  tools/libacpi/mk_dsdt.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
> index 6da24fa..6197692 100644
> --- a/tools/libacpi/mk_dsdt.c
> +++ b/tools/libacpi/mk_dsdt.c
> @@ -282,11 +282,6 @@ int main(int argc, char **argv)
>  
>  pop_block();
>  
> -if (dm_version == QEMU_NONE) {
> -pop_block();
> -return 0;
> -}
> -
>  /* Define GPE control method. */
>  push_block("Scope", "\\_GPE");
>  push_block("Method",
> @@ -295,6 +290,11 @@ int main(int argc, char **argv)
>  stmt("\\_SB.PRSC ()", NULL);
>  pop_block();
>  pop_block();
> +
> +if (dm_version == QEMU_NONE) {
> +pop_block();
> +return 0;
> +}
>  / Processor end /
>  
>  
> -- 
> 2.7.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] Patch "x86/mm/xen: Suppress hugetlbfs in PV guests" (CVE-2016-3961) is missing in 3.4, 3.10 and 3.12 stable tree

[Jiri Slaby]

On 11/21/2016, 04:22 PM, Thomas Deutschmann wrote:
> Hi,
> 
> the following patch is present in the following LTS kernels
> 
>> =linux-3.2.81
>> =linux-3.16.36
>> =linux-3.18.33
>> =linux-4.1.24
>> =linux-4.4.9
> 
> 
> however it is missing from LTS kernels
> 
> - linux-3.4
> - linux-3.10
> - linux-3.12
> 
> 
>> From 103f6112f253017d7062cd74d17f4a514ed4485c Mon Sep 17 00:00:00 2001
>> From: Jan Beulich 
>> Date: Thu, 21 Apr 2016 00:27:04 -0600
>> Subject: x86/mm/xen: Suppress hugetlbfs in PV guests

Applied to 3.12. Thanks!

-- 
js
suse labs



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

Re: [Xen-devel] Can't always start 32 bit domains after 64 bit domains

[Sarah Newman]

On 11/22/2016 10:46 AM, Dario Faggioli wrote:
> On Mon, 2016-11-21 at 13:06 -0800, Sarah Newman wrote:
>> On 11/21/2016 11:37 AM, Sarah Newman wrote:
>>> 
>>> If that's the reason not all the higher memory is being used first: is a 
>>> potential workaround to pin 64 bit domains to the second physical
>>> core on boot, and 32 bit domains to the first physical core on boot, and 
>>> then change the allowed cores with 'xl vcpu-pin' after the domain is
>>> loaded?
>> 
>> Free memory on a test server with no domains: node:memsizememfree
>> distances 0:148480 142983  10,21 1:147456
>> 144645  21,10
>> 
>> Free memory booting 116 256M 64-bit domains, limited to cpus='all,^0- 1' on 
>> boot: node:memsizememfreedistances 0:148480
>> 128416  10,21 1:147456 129669  21,10
>> 
>> Free memory booting 116 256M 64-bit domains, limited to cpus='12-23' on 
>> boot: node:memsizememfreedistances 0:148480 143397
>> 10,21 1:147456 114693  21,10
>> 
>> This looks like a viable workaround. Where should I document it?
>> 
> It's documented in here (although, the text can be improved a bit, I 
> think)... look for 'cpus' and 'cpus_soft' within the page: 
> https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
> 
> A more clear mention to using "all" can perhaps be added to the wiki pages I 
> listed in my other email.
> 

Testing shows that memory allocation is still alternated between the two 
physical nodes, even after setting cpus='all' or removing cpus=... from the
configuration file entirely.

If you're saying not specifying "cpus=..." will keep libxl from interfering 
with the Xens default allocation policy, then Xens default allocation
policy no longer starts from the top of memory for 64 bit PV domains, at least 
for 4.6.3. Maybe it's starting from the top of memory per node.

> However, what I think is totally missing, is any documentation about the fact 
> that, in use cases like yours, domain creation should be done in a
> certain order, for what reasons, which order is that, and the fact that NUMA 
> placement may interfere.
> 
> I'm not sure where and how to properly document all this [adding Lars], but 
> I'd say it probably deserves a dedicated wiki page.
> 
> Thoughts?

A dedicated wiki page would be fine if it is sufficiently linked to. I would 
link to it from
https://wiki.xenproject.org/wiki/Xen_Project_Release_Features, maybe adding a 
footnote for "Host Limits" and/or various parameters listed therein.

--Sarah

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

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Julien Grall]

On 22/11/16 19:06, Stefano Stabellini wrote:

On Mon, 21 Nov 2016, Julien Grall wrote:

On 21/11/2016 21:13, Edgar E. Iglesias wrote:

On Mon, Nov 21, 2016 at 01:01:15PM -0800, Stefano Stabellini wrote:

On Mon, 21 Nov 2016, Edgar E. Iglesias wrote:

On Fri, Nov 18, 2016 at 10:58:42AM -0800, Stefano Stabellini wrote:

On Thu, 17 Nov 2016, Julien Grall wrote:

Hi Stefano,

On 17/11/2016 11:26, Stefano Stabellini wrote:

On Mon, 14 Nov 2016, Julien Grall wrote:

On 11/11/2016 13:55, Stefano Stabellini wrote:

On Fri, 11 Nov 2016, Julien Grall wrote:

On 11/11/2016 02:24, Stefano Stabellini wrote:

On Thu, 10 Nov 2016, Julien Grall wrote:

(CC Stefano and change the title)
On 10/11/16 12:13, casionwoo wrote:

I’m pleased about your reply and you have a lot of
code to
clean-up.

As you mentioned, It’s really huge to digest at once.
Thank you
for
understanding me.

And that’s why i need a small fix up and todo list.

I feel familiar with ARM and c language and there’s no
specific
area
yet.

I think that i can find interesting area with
following up the
codes.

I’m looking forward to being stuck on Xen.

Then it would be easier for me to understand about Xen
on ARM.

Please let me know the TODO and bug-fix lists.


Stefano, before giving a list of code clean-up, do you
have any
small
TODO
on
ARM in mind?


A simple task we talked about recently is to enable the
vuart
(xen/arch/arm/vuart.c) for all guests. At the moment it is
only
emulated
for Dom0, but some guests, in particular BareMetal guests
(https://en.wikipedia.org/wiki/BareMetal), would benefit
from it.

It would be best to introduce an option in libxl to
explicitly
enable/disable the vuart for DomUs. Something like vuart=1
in the VM
config file.


The vuart has not been enabled for DomU because it the UART
region may
clash
with the guest memory layout (which is static).

I don't think this option should be available until we allow
the guest
to
use
the same memory layout as the host (see e820_host parameter
for x86).


Actually there is no reason for the vuart to use the same
address as
the physical uart on the platform, is there?
In fact it doesn't even
have to prentend to be the same uart as the one on the board,
right?
The vuart MMIO address could be completely configurable and
independent
from the one of the physical uart.


There is no reason to use the same information as the physical
UART.

However, the vuart requires quite a few information (e.g base
address,
offset
of different register... see vuart_info structure in
include/xen/serial.h
for
more details) in order to fully work.

IHMO this is a lot of works for the user to configure. I would
much prefer
to
see a PL011 emulated at a specific base address and let the user
select
whether he wants a UART to debug or not.


So you envision the configuration of the MMIO base address to be
done as
part of a new dynamic guest memory map?


For guest using dynamic memory map, I would expect to expose an
uncompleted
emulation of the physical UART (e.g it would only be possible to
write) at the
exact same address as on the host.


Why? Is this a requirement for baremetal guests?

I would have actually opted for always emulating a PL011 even for
guests
using a dynamic memory map (which of course one way or another need to
be able to choose the address of the UART, the memory and the rest).


I guess it's not black and white but trying to reduce the gap towards
being able to run unmodified SW for a given platform as a guest would
be nice.

Some times things are quite relaxed and we can recompile the SW for Xen,
add new drivers etc. Other times perhaps SW has been certified and users
may not be able to change anything.

For apps where the UARTs are only used for console data, vuarts at
configurable locations would be nice IMO.


All right, so I take that same UART as baremetal is easier than always
PL011?


I think so, yes.

To comply with the SBSA, depending on the guest, we'll probably need to
allow for optional emulation of pl011 though...

Having a flexible setup so that vm.cfgs can instantiate vuarts or emulated
pl011 at specific addresses, that sounds good to me.


I am more in favor to have a different approach depending on the memory layout
(static vs dynamic) of the guest.

Exposing the vuart to a guest with static memory layout is overly complex (you
have a bunch information to configure) and it is much easier to require a
guest using pl011 (implementing a small driver for it is very easy). Note that
the emulation could just use the vuart for now. But the user would just have
to say pl011 = true in the vm.cfg.

For the emulated pl011, I would not support user configuration (e.g address)
when using the static memory layout for similar reason as above. Only dynamic
layout could support an extend configuration. Even though, I am not convince
of the usefulness of a pl011 for baremetal app (we are supposed to only
emulate the hardware).


I disagree: I think we can provide a simple way to make it 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 36e9e3e8ea0ce477504b6d2e21603ea94847efae
baseline version:
 ovmf b43dd22981b71dd78dd4cc04d55dc23d81c3bafb

Last test of basis68080  2016-11-22 11:49:41 Z0 days
Testing same since68081  2016-11-22 17:19:25 Z0 days1 attempts


People who touched revisions under test:
  Hao Wu 

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



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

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

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


Push not applicable.


commit 36e9e3e8ea0ce477504b6d2e21603ea94847efae
Author: Hao Wu 
Date:   Mon Nov 21 15:38:11 2016 +0800

SecurityPkg Tcg2Dxe: ASSERT to ensure 'VarData' is not NULL

The logic in functions ReadAndMeasureVariable() and MeasureVariable()
within Tcg2Dxe ensure that 'VarData' will not be NULL before calling
TcgDxeHashLogExtendEvent() at line 1716.

This commit adds ASSERT as warnings for the case that will not happen.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Jiewen Yao 
Reviewed-by: Chao Zhang 

commit a8bcbf9c4d677c392e24893b86944e2cdeb8719e
Author: Hao Wu 
Date:   Mon Nov 21 14:00:44 2016 +0800

SecurityPkg TcgStorageCoreLib: ASSERT to ensure 'ByteSeq' is not NULL

Add ASSERT to make sure 'ByteSeq' is not NULL before comsumed by
CopyMem().

Cc: Eric Dong 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Jiewen Yao 

commit a522ad7c192b5cf3b31d3152eb082236fbda7243
Author: Hao Wu 
Date:   Mon Nov 21 13:44:59 2016 +0800

MdeModulePkg CapsuleApp: ASSERT to ensure 'CapsuleIndex' is not NULL

Function GetVariable2() ensures its third (output) parameter will not be
NULL when the return status is EFI_SUCCESS.

This commit adds ASSERT as warnings for the case that will not happen.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Jiewen Yao 

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

Re: [Xen-devel] [PULL 0/5] xen-20161122-tag

[Stefan Hajnoczi]

On Tue, Nov 22, 2016 at 10:45:58AM -0800, Stefano Stabellini wrote:
> Hi Stefan,
> 
> this pull request contains an XSA ("fix ioreq handling") and xen-usb bug
> fixes and cleanups. Please note that "qdev: add function qdev_set_id()"
> touches generic qdev code: I was the only one to review the patch but it
> is just code movement.
> 
> 
> The following changes since commit a7764f1548ef9946af30a8f96be9cef10761f0c1:
> 
>   Fix FreeBSD (10.x) build after 7dc9ae43 (2016-11-22 10:56:01 +)
> 
> are available in the git repository at:
> 
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161122-tag
> 
> for you to fetch changes up to f1784a222eed213ce3213f431bc2f9c570f20c3e:
> 
>   xen: attach pvusb usb bus to backend qdev (2016-11-22 10:29:41 -0800)
> 
> 
> Xen 2016/11/22
> 
> 
> Jan Beulich (1):
>   xen: fix ioreq handling
> 
> Juergen Gross (4):
>   xen: add an own bus for xen backend devices
>   qdev: add function qdev_set_id()
>   xen: create qdev for each backend device
>   xen: attach pvusb usb bus to backend qdev
> 
>  hw/usb/xen-usb.c | 23 +++
>  hw/xen/xen_backend.c | 66 
> ++--
>  hw/xen/xen_pvdev.c   |  4 ++-
>  include/hw/xen/xen_backend.h |  8 ++
>  include/hw/xen/xen_pvdev.h   |  1 +
>  include/monitor/qdev.h   |  1 +
>  qdev-monitor.c   | 36 +---
>  xen-hvm.c| 16 ++-
>  8 files changed, 121 insertions(+), 34 deletions(-)

Thanks, applied to my staging tree:
https://github.com/stefanha/qemu/commits/staging

Stefan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  986f790e0184d4bf575462077378e14fa9f85aa9
baseline version:
 xen  f6b7fedc896250028cb81dafe9a3f6773aaf1da2

Last test of basis   102516  2016-11-22 13:01:06 Z0 days
Testing same since   102526  2016-11-22 17:05:48 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  Jan Beulich 
  Tamas K Lengyel 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Stefano Stabellini]

On Mon, 21 Nov 2016, Julien Grall wrote:
> On 21/11/2016 21:13, Edgar E. Iglesias wrote:
> > On Mon, Nov 21, 2016 at 01:01:15PM -0800, Stefano Stabellini wrote:
> > > On Mon, 21 Nov 2016, Edgar E. Iglesias wrote:
> > > > On Fri, Nov 18, 2016 at 10:58:42AM -0800, Stefano Stabellini wrote:
> > > > > On Thu, 17 Nov 2016, Julien Grall wrote:
> > > > > > Hi Stefano,
> > > > > > 
> > > > > > On 17/11/2016 11:26, Stefano Stabellini wrote:
> > > > > > > On Mon, 14 Nov 2016, Julien Grall wrote:
> > > > > > > > On 11/11/2016 13:55, Stefano Stabellini wrote:
> > > > > > > > > On Fri, 11 Nov 2016, Julien Grall wrote:
> > > > > > > > > > On 11/11/2016 02:24, Stefano Stabellini wrote:
> > > > > > > > > > > On Thu, 10 Nov 2016, Julien Grall wrote:
> > > > > > > > > > > > (CC Stefano and change the title)
> > > > > > > > > > > > On 10/11/16 12:13, casionwoo wrote:
> > > > > > > > > > > > > I’m pleased about your reply and you have a lot of
> > > > > > > > > > > > > code to
> > > > > > > > > > > > > clean-up.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > As you mentioned, It’s really huge to digest at once.
> > > > > > > > > > > > > Thank you
> > > > > > > > > > > > > for
> > > > > > > > > > > > > understanding me.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > And that’s why i need a small fix up and todo list.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I feel familiar with ARM and c language and there’s no
> > > > > > > > > > > > > specific
> > > > > > > > > > > > > area
> > > > > > > > > > > > > yet.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I think that i can find interesting area with
> > > > > > > > > > > > > following up the
> > > > > > > > > > > > > codes.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I’m looking forward to being stuck on Xen.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Then it would be easier for me to understand about Xen
> > > > > > > > > > > > > on ARM.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Please let me know the TODO and bug-fix lists.
> > > > > > > > > > > > 
> > > > > > > > > > > > Stefano, before giving a list of code clean-up, do you
> > > > > > > > > > > > have any
> > > > > > > > > > > > small
> > > > > > > > > > > > TODO
> > > > > > > > > > > > on
> > > > > > > > > > > > ARM in mind?
> > > > > > > > > > > 
> > > > > > > > > > > A simple task we talked about recently is to enable the
> > > > > > > > > > > vuart
> > > > > > > > > > > (xen/arch/arm/vuart.c) for all guests. At the moment it is
> > > > > > > > > > > only
> > > > > > > > > > > emulated
> > > > > > > > > > > for Dom0, but some guests, in particular BareMetal guests
> > > > > > > > > > > (https://en.wikipedia.org/wiki/BareMetal), would benefit
> > > > > > > > > > > from it.
> > > > > > > > > > > 
> > > > > > > > > > > It would be best to introduce an option in libxl to
> > > > > > > > > > > explicitly
> > > > > > > > > > > enable/disable the vuart for DomUs. Something like vuart=1
> > > > > > > > > > > in the VM
> > > > > > > > > > > config file.
> > > > > > > > > > 
> > > > > > > > > > The vuart has not been enabled for DomU because it the UART
> > > > > > > > > > region may
> > > > > > > > > > clash
> > > > > > > > > > with the guest memory layout (which is static).
> > > > > > > > > > 
> > > > > > > > > > I don't think this option should be available until we allow
> > > > > > > > > > the guest
> > > > > > > > > > to
> > > > > > > > > > use
> > > > > > > > > > the same memory layout as the host (see e820_host parameter
> > > > > > > > > > for x86).
> > > > > > > > > 
> > > > > > > > > Actually there is no reason for the vuart to use the same
> > > > > > > > > address as
> > > > > > > > > the physical uart on the platform, is there?
> > > > > > > > > In fact it doesn't even
> > > > > > > > > have to prentend to be the same uart as the one on the board,
> > > > > > > > > right?
> > > > > > > > > The vuart MMIO address could be completely configurable and
> > > > > > > > > independent
> > > > > > > > > from the one of the physical uart.
> > > > > > > > 
> > > > > > > > There is no reason to use the same information as the physical
> > > > > > > > UART.
> > > > > > > > 
> > > > > > > > However, the vuart requires quite a few information (e.g base
> > > > > > > > address,
> > > > > > > > offset
> > > > > > > > of different register... see vuart_info structure in
> > > > > > > > include/xen/serial.h
> > > > > > > > for
> > > > > > > > more details) in order to fully work.
> > > > > > > > 
> > > > > > > > IHMO this is a lot of works for the user to configure. I would
> > > > > > > > much prefer
> > > > > > > > to
> > > > > > > > see a PL011 emulated at a specific base address and let the user
> > > > > > > > select
> > > > > > > > whether he wants a UART to debug or not.
> > > > > > > 
> > > > > > > So you envision the configuration of the MMIO base address to be
> > > > > > > done as
> > > > > > > part of a new dynamic guest memory map?
> > > > > > 
> > > > > > For 

Re: [Xen-devel] Can't always start 32 bit domains after 64 bit domains

[Dario Faggioli]

On Mon, 2016-11-21 at 13:06 -0800, Sarah Newman wrote:
> On 11/21/2016 11:37 AM, Sarah Newman wrote:
> > 
> > If that's the reason not all the higher memory is being used first:
> > is a potential workaround to pin 64 bit domains to the second
> > physical core on
> > boot, and 32 bit domains to the first physical core on boot, and
> > then change the allowed cores with 'xl vcpu-pin' after the domain
> > is loaded?
> 
> Free memory on a test server with no domains:
> node:memsizememfreedistances
>    0:148480 142983  10,21
>    1:147456 144645  21,10
> 
> Free memory booting 116 256M 64-bit domains, limited to cpus='all,^0-
> 1' on boot:
> node:memsizememfreedistances
>    0:148480 128416  10,21
>    1:147456 129669  21,10
> 
> Free memory booting 116 256M 64-bit domains, limited to cpus='12-23'
> on boot:
> node:memsizememfreedistances
>    0:148480 143397  10,21
>    1:147456 114693  21,10
> 
> This looks like a viable workaround. Where should I document it?
> 
It's documented in here (although, the text can be improved a bit, I
think)... look for 'cpus' and 'cpus_soft' within the page:
https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html

A more clear mention to using "all" can perhaps be added to the wiki
pages I listed in my other email.

However, what I think is totally missing, is any documentation about
the fact that, in use cases like yours, domain creation should be done
in a certain order, for what reasons, which order is that, and the fact
that NUMA placement may interfere.

I'm not sure where and how to properly document all this [adding Lars],
but I'd say it probably deserves a dedicated wiki page.

Thoughts?

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

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

[Xen-devel] [PULL 2/5] xen: add an own bus for xen backend devices

[Stefano Stabellini]

From: Juergen Gross 

Add a bus for Xen backend devices in order to be able to establish a
dedicated device path for pluggable devices.

Signed-off-by: Juergen Gross 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 hw/xen/xen_backend.c | 19 ---
 include/hw/xen/xen_backend.h |  4 
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 41ba5c5..5ad3caa 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -29,14 +29,14 @@
 #include "hw/sysbus.h"
 #include "sysemu/char.h"
 #include "qemu/log.h"
+#include "qapi/error.h"
 #include "hw/xen/xen_backend.h"
 #include "hw/xen/xen_pvdev.h"
 
 #include 
 
-#define TYPE_XENSYSDEV "xensysdev"
-
 DeviceState *xen_sysdev;
+BusState *xen_sysbus;
 
 /* - */
 
@@ -528,6 +528,8 @@ int xen_be_init(void)
 
 xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV);
 qdev_init_nofail(xen_sysdev);
+xen_sysbus = qbus_create(TYPE_XENSYSBUS, DEVICE(xen_sysdev), "xen-sysbus");
+qbus_set_bus_hotplug_handler(xen_sysbus, _abort);
 
 return 0;
 
@@ -586,6 +588,15 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
 }
 
 
+static const TypeInfo xensysbus_info = {
+.name   = TYPE_XENSYSBUS,
+.parent = TYPE_BUS,
+.interfaces = (InterfaceInfo[]) {
+{ TYPE_HOTPLUG_HANDLER },
+{ }
+}
+};
+
 static int xen_sysdev_init(SysBusDevice *dev)
 {
 return 0;
@@ -602,6 +613,7 @@ static void xen_sysdev_class_init(ObjectClass *klass, void 
*data)
 
 k->init = xen_sysdev_init;
 dc->props = xen_sysdev_properties;
+dc->bus_type = TYPE_XENSYSBUS;
 }
 
 static const TypeInfo xensysdev_info = {
@@ -613,7 +625,8 @@ static const TypeInfo xensysdev_info = {
 
 static void xenbe_register_types(void)
 {
+type_register_static(_info);
 type_register_static(_info);
 }
 
-type_init(xenbe_register_types);
+type_init(xenbe_register_types)
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index cbda40e..38f730e 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -6,12 +6,16 @@
 #include "sysemu/sysemu.h"
 #include "net/net.h"
 
+#define TYPE_XENSYSDEV "xen-sysdev"
+#define TYPE_XENSYSBUS "xen-sysbus"
+
 /* variables */
 extern xc_interface *xen_xc;
 extern xenforeignmemory_handle *xen_fmem;
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
 extern DeviceState *xen_sysdev;
+extern BusState *xen_sysbus;
 
 int xenstore_mkdir(char *path, int p);
 int xenstore_write_be_str(struct XenDevice *xendev, const char *node, const 
char *val);
-- 
1.9.1


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

[Xen-devel] [PULL 5/5] xen: attach pvusb usb bus to backend qdev

[Stefano Stabellini]

From: Juergen Gross 

Attach the usb bus of a new pvusb controller to the qdev associated
with the Xen backend. Any device connected to that controller can now
specify the bus and port directly via its properties.

Signed-off-by: Juergen Gross 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 hw/usb/xen-usb.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 1b3c2fb..8e676e6 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -712,15 +712,10 @@ static void usbback_portid_detach(struct usbback_info 
*usbif, unsigned port)
 
 static void usbback_portid_remove(struct usbback_info *usbif, unsigned port)
 {
-USBPort *p;
-
 if (!usbif->ports[port - 1].dev) {
 return;
 }
 
-p = &(usbif->ports[port - 1].port);
-snprintf(p->path, sizeof(p->path), "%d", 99);
-
 object_unparent(OBJECT(usbif->ports[port - 1].dev));
 usbif->ports[port - 1].dev = NULL;
 usbback_portid_detach(usbif, port);
@@ -733,10 +728,10 @@ static void usbback_portid_add(struct usbback_info 
*usbif, unsigned port,
 {
 unsigned speed;
 char *portname;
-USBPort *p;
 Error *local_err = NULL;
 QDict *qdict;
 QemuOpts *opts;
+char *tmp;
 
 if (usbif->ports[port - 1].dev) {
 return;
@@ -749,11 +744,16 @@ static void usbback_portid_add(struct usbback_info 
*usbif, unsigned port,
 return;
 }
 portname++;
-p = &(usbif->ports[port - 1].port);
-snprintf(p->path, sizeof(p->path), "%s", portname);
 
 qdict = qdict_new();
 qdict_put(qdict, "driver", qstring_from_str("usb-host"));
+tmp = g_strdup_printf("%s.0", usbif->xendev.qdev.id);
+qdict_put(qdict, "bus", qstring_from_str(tmp));
+g_free(tmp);
+tmp = g_strdup_printf("%s-%u", usbif->xendev.qdev.id, port);
+qdict_put(qdict, "id", qstring_from_str(tmp));
+g_free(tmp);
+qdict_put(qdict, "port", qint_from_int(port));
 qdict_put(qdict, "hostbus", qint_from_int(atoi(busid)));
 qdict_put(qdict, "hostport", qstring_from_str(portname));
 opts = qemu_opts_from_qdict(qemu_find_opts("device"), qdict, _err);
@@ -765,7 +765,6 @@ static void usbback_portid_add(struct usbback_info *usbif, 
unsigned port,
 goto err;
 }
 QDECREF(qdict);
-snprintf(p->path, sizeof(p->path), "%d", port);
 speed = usbif->ports[port - 1].dev->speed;
 switch (speed) {
 case USB_SPEED_LOW:
@@ -799,7 +798,6 @@ static void usbback_portid_add(struct usbback_info *usbif, 
unsigned port,
 
 err:
 QDECREF(qdict);
-snprintf(p->path, sizeof(p->path), "%d", 99);
 xen_pv_printf(>xendev, 0, "device %s could not be opened\n", busid);
 }
 
@@ -1012,13 +1010,13 @@ static void usbback_alloc(struct XenDevice *xendev)
 
 usbif = container_of(xendev, struct usbback_info, xendev);
 
-usb_bus_new(>bus, sizeof(usbif->bus), _usb_bus_ops, xen_sysdev);
+usb_bus_new(>bus, sizeof(usbif->bus), _usb_bus_ops,
+DEVICE(>qdev));
 for (i = 0; i < USBBACK_MAXPORTS; i++) {
 p = &(usbif->ports[i].port);
 usb_register_port(>bus, p, usbif, i, _usb_port_ops,
   USB_SPEED_MASK_LOW | USB_SPEED_MASK_FULL |
   USB_SPEED_MASK_HIGH);
-snprintf(p->path, sizeof(p->path), "%d", 99);
 }
 
 QTAILQ_INIT(>req_free_q);
@@ -1066,7 +1064,6 @@ static int usbback_free(struct XenDevice *xendev)
 }
 
 usb_bus_release(>bus);
-object_unparent(OBJECT(>bus));
 
 TR_BUS(xendev, "finished\n");
 
-- 
1.9.1


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

[Xen-devel] [PULL 4/5] xen: create qdev for each backend device

[Stefano Stabellini]

From: Juergen Gross 

Create a qdev plugged to the xen-sysbus for each new backend device.
This device can be used as a parent for all needed devices of that
backend. The id of the new device will be "xen--" with
 being the xen backend type (e.g. "qdisk") and  the xen
backend number of the type under which it is to be found in xenstore.

Signed-off-by: Juergen Gross 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 hw/xen/xen_backend.c | 47 
 hw/xen/xen_pvdev.c   |  4 +++-
 include/hw/xen/xen_backend.h |  4 
 include/hw/xen/xen_pvdev.h   |  1 +
 4 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 5ad3caa..d119004 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -27,11 +27,13 @@
 
 #include "hw/hw.h"
 #include "hw/sysbus.h"
+#include "hw/boards.h"
 #include "sysemu/char.h"
 #include "qemu/log.h"
 #include "qapi/error.h"
 #include "hw/xen/xen_backend.h"
 #include "hw/xen/xen_pvdev.h"
+#include "monitor/qdev.h"
 
 #include 
 
@@ -121,6 +123,12 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 
 /* init new xendev */
 xendev = g_malloc0(ops->size);
+object_initialize(>qdev, ops->size, TYPE_XENBACKEND);
+qdev_set_parent_bus(>qdev, xen_sysbus);
+qdev_set_id(>qdev, g_strdup_printf("xen-%s-%d", type, dev));
+qdev_init_nofail(>qdev);
+object_unref(OBJECT(>qdev));
+
 xendev->type  = type;
 xendev->dom   = dom;
 xendev->dev   = dev;
@@ -541,6 +549,15 @@ err:
 return -1;
 }
 
+static void xen_set_dynamic_sysbus(void)
+{
+Object *machine = qdev_get_machine();
+ObjectClass *oc = object_get_class(machine);
+MachineClass *mc = MACHINE_CLASS(oc);
+
+mc->has_dynamic_sysbus = true;
+}
+
 int xen_be_register(const char *type, struct XenDevOps *ops)
 {
 char path[50];
@@ -562,6 +579,8 @@ int xen_be_register(const char *type, struct XenDevOps *ops)
 
 void xen_be_register_common(void)
 {
+xen_set_dynamic_sysbus();
+
 xen_be_register("console", _console_ops);
 xen_be_register("vkbd", _kbdmouse_ops);
 xen_be_register("qdisk", _blkdev_ops);
@@ -588,9 +607,36 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
 }
 
 
+static Property xendev_properties[] = {
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xendev_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->props = xendev_properties;
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+}
+
+static const TypeInfo xendev_type_info = {
+.name  = TYPE_XENBACKEND,
+.parent= TYPE_XENSYSDEV,
+.class_init= xendev_class_init,
+.instance_size = sizeof(struct XenDevice),
+};
+
+static void xen_sysbus_class_init(ObjectClass *klass, void *data)
+{
+HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
+
+hc->unplug = qdev_simple_device_unplug_cb;
+}
+
 static const TypeInfo xensysbus_info = {
 .name   = TYPE_XENSYSBUS,
 .parent = TYPE_BUS,
+.class_init = xen_sysbus_class_init,
 .interfaces = (InterfaceInfo[]) {
 { TYPE_HOTPLUG_HANDLER },
 { }
@@ -627,6 +673,7 @@ static void xenbe_register_types(void)
 {
 type_register_static(_info);
 type_register_static(_info);
+type_register_static(_type_info);
 }
 
 type_init(xenbe_register_types)
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index 5212bc6..aed783e 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -19,6 +19,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/log.h"
+#include "hw/qdev-core.h"
 #include "hw/xen/xen_backend.h"
 #include "hw/xen/xen_pvdev.h"
 
@@ -307,7 +308,8 @@ void xen_pv_del_xendev(struct XenDevice *xendev)
 }
 
 QTAILQ_REMOVE(, xendev, next);
-g_free(xendev);
+
+qdev_unplug(>qdev, NULL);
 }
 
 void xen_pv_insert_xendev(struct XenDevice *xendev)
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 38f730e..4f4799a 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -8,6 +8,10 @@
 
 #define TYPE_XENSYSDEV "xen-sysdev"
 #define TYPE_XENSYSBUS "xen-sysbus"
+#define TYPE_XENBACKEND "xen-backend"
+
+#define XENBACKEND_DEVICE(obj) \
+OBJECT_CHECK(XenDevice, (obj), TYPE_XENBACKEND)
 
 /* variables */
 extern xc_interface *xen_xc;
diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h
index 083f0a9..d473e9b 100644
--- a/include/hw/xen/xen_pvdev.h
+++ b/include/hw/xen/xen_pvdev.h
@@ -29,6 +29,7 @@ struct XenDevOps {
 };
 
 struct XenDevice {
+DeviceStateqdev;
 const char *type;
 intdom;
 intdev;
-- 
1.9.1


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

[Xen-devel] [PULL 3/5] qdev: add function qdev_set_id()

[Stefano Stabellini]

From: Juergen Gross 

In order to have an easy way to add a new qdev with a specific id
carve out the needed functionality from qdev_device_add() into a new
function qdev_set_id().

Signed-off-by: Juergen Gross 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 include/monitor/qdev.h |  1 +
 qdev-monitor.c | 36 
 2 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/include/monitor/qdev.h b/include/monitor/qdev.h
index 8e504bc..0ff3331 100644
--- a/include/monitor/qdev.h
+++ b/include/monitor/qdev.h
@@ -12,5 +12,6 @@ void qmp_device_add(QDict *qdict, QObject **ret_data, Error 
**errp);
 
 int qdev_device_help(QemuOpts *opts);
 DeviceState *qdev_device_add(QemuOpts *opts, Error **errp);
+void qdev_set_id(DeviceState *dev, const char *id);
 
 #endif
diff --git a/qdev-monitor.c b/qdev-monitor.c
index 4f78ecb..c73410c 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -539,10 +539,28 @@ static BusState *qbus_find(const char *path, Error **errp)
 return bus;
 }
 
+void qdev_set_id(DeviceState *dev, const char *id)
+{
+if (id) {
+dev->id = id;
+}
+
+if (dev->id) {
+object_property_add_child(qdev_get_peripheral(), dev->id,
+  OBJECT(dev), NULL);
+} else {
+static int anon_count;
+gchar *name = g_strdup_printf("device[%d]", anon_count++);
+object_property_add_child(qdev_get_peripheral_anon(), name,
+  OBJECT(dev), NULL);
+g_free(name);
+}
+}
+
 DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
 {
 DeviceClass *dc;
-const char *driver, *path, *id;
+const char *driver, *path;
 DeviceState *dev;
 BusState *bus = NULL;
 Error *err = NULL;
@@ -591,21 +609,7 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
 qdev_set_parent_bus(dev, bus);
 }
 
-id = qemu_opts_id(opts);
-if (id) {
-dev->id = id;
-}
-
-if (dev->id) {
-object_property_add_child(qdev_get_peripheral(), dev->id,
-  OBJECT(dev), NULL);
-} else {
-static int anon_count;
-gchar *name = g_strdup_printf("device[%d]", anon_count++);
-object_property_add_child(qdev_get_peripheral_anon(), name,
-  OBJECT(dev), NULL);
-g_free(name);
-}
+qdev_set_id(dev, qemu_opts_id(opts));
 
 /* set properties */
 if (qemu_opt_foreach(opts, set_property, dev, )) {
-- 
1.9.1


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

[Xen-devel] [PULL 1/5] xen: fix ioreq handling

[Stefano Stabellini]

From: Jan Beulich 

Avoid double fetches and bounds check size to avoid overflowing
internal variables.

This is CVE-2016-9381 / XSA-197.

Reported-by: yanghongke 
Signed-off-by: Jan Beulich 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 xen-hvm.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/xen-hvm.c b/xen-hvm.c
index 150c7e7..99b8ee8 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -810,6 +810,10 @@ static void cpu_ioreq_pio(ioreq_t *req)
 trace_cpu_ioreq_pio(req, req->dir, req->df, req->data_is_ptr, req->addr,
  req->data, req->count, req->size);
 
+if (req->size > sizeof(uint32_t)) {
+hw_error("PIO: bad size (%u)", req->size);
+}
+
 if (req->dir == IOREQ_READ) {
 if (!req->data_is_ptr) {
 req->data = do_inp(req->addr, req->size);
@@ -846,6 +850,10 @@ static void cpu_ioreq_move(ioreq_t *req)
 trace_cpu_ioreq_move(req, req->dir, req->df, req->data_is_ptr, req->addr,
  req->data, req->count, req->size);
 
+if (req->size > sizeof(req->data)) {
+hw_error("MMIO: bad size (%u)", req->size);
+}
+
 if (!req->data_is_ptr) {
 if (req->dir == IOREQ_READ) {
 for (i = 0; i < req->count; i++) {
@@ -1010,11 +1018,13 @@ static int handle_buffered_iopage(XenIOState *state)
 req.df = 1;
 req.type = buf_req->type;
 req.data_is_ptr = 0;
+xen_rmb();
 qw = (req.size == 8);
 if (qw) {
 buf_req = _page->buf_ioreq[(rdptr + 1) %
IOREQ_BUFFER_SLOT_NUM];
 req.data |= ((uint64_t)buf_req->data) << 32;
+xen_rmb();
 }
 
 handle_ioreq(state, );
@@ -1045,7 +1055,11 @@ static void cpu_handle_ioreq(void *opaque)
 
 handle_buffered_iopage(state);
 if (req) {
-handle_ioreq(state, req);
+ioreq_t copy = *req;
+
+xen_rmb();
+handle_ioreq(state, );
+req->data = copy.data;
 
 if (req->state != STATE_IOREQ_INPROCESS) {
 fprintf(stderr, "Badness in I/O request ... not in service?!: "
-- 
1.9.1


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

[Xen-devel] [PULL 0/5] xen-20161122-tag

[Stefano Stabellini]

Hi Stefan,

this pull request contains an XSA ("fix ioreq handling") and xen-usb bug
fixes and cleanups. Please note that "qdev: add function qdev_set_id()"
touches generic qdev code: I was the only one to review the patch but it
is just code movement.


The following changes since commit a7764f1548ef9946af30a8f96be9cef10761f0c1:

  Fix FreeBSD (10.x) build after 7dc9ae43 (2016-11-22 10:56:01 +)

are available in the git repository at:

  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161122-tag

for you to fetch changes up to f1784a222eed213ce3213f431bc2f9c570f20c3e:

  xen: attach pvusb usb bus to backend qdev (2016-11-22 10:29:41 -0800)


Xen 2016/11/22


Jan Beulich (1):
  xen: fix ioreq handling

Juergen Gross (4):
  xen: add an own bus for xen backend devices
  qdev: add function qdev_set_id()
  xen: create qdev for each backend device
  xen: attach pvusb usb bus to backend qdev

 hw/usb/xen-usb.c | 23 +++
 hw/xen/xen_backend.c | 66 ++--
 hw/xen/xen_pvdev.c   |  4 ++-
 include/hw/xen/xen_backend.h |  8 ++
 include/hw/xen/xen_pvdev.h   |  1 +
 include/monitor/qdev.h   |  1 +
 qdev-monitor.c   | 36 +---
 xen-hvm.c| 16 ++-
 8 files changed, 121 insertions(+), 34 deletions(-)

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

Re: [Xen-devel] Can't always start 32 bit domains after 64 bit domains

[Dario Faggioli]

On Mon, 2016-11-21 at 11:37 -0800, Sarah Newman wrote:
> On 11/21/2016 05:21 AM, Andrew Cooper wrote:
> > I suspect that libxl's preference towards NUMA allocation of
> > domains
> > interferes with this, by adding a NUMA constraints to memory
> > allocations
> > for 64bit PV guests.
> 
> I ran xl info -n (which I didn't know about before) and that shows
> the problem much more clearly.
> 
> If that's the reason not all the higher memory is being used first:
> is a potential workaround to pin 64 bit domains to the second
> physical core on
> boot, and 32 bit domains to the first physical core on boot, and then
> change the allowed cores with 'xl vcpu-pin' after the domain is
> loaded?
> 
If you're looking for a way to disable libxl's NUMA-aware domain
placement --which does indeed interfere whit what memory (as in, the
memory of what NUMA node) is going to be used for the domains-- you can
"just" specify this, in all the domains' config files:

cpus="all"

This will leave all the vcpus free to run everywhere, and stop libxl to
pass down to Xen any hint on memory allocation.

Using

cpus="foo"

and/or

cpus_soft="bar"

would allow to tweak things more.

And the same is true for creating cpupools, with specific cpus from
specific NUMA nodes in them, and creating the domain direcly inside
those various pools.

That being said, what values are the best for your use case, I'm not
really sure... But maybe have a look at this.

Some more info:
https://wiki.xen.org/wiki/Xen_on_NUMA_Machines
https://wiki.xen.org/wiki/Xen_4.3_NUMA_Aware_Scheduling
https://wiki.xen.org/wiki/Tuning_Xen_for_Performance#vCPU_Soft_Affinity_for_guests

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

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

Re: [Xen-devel] DomU application crashes while mmap'ing device memory on x86_64

[Oleksandr Andrushchenko]

Hi,

just wanted to bump this as I also have the same issue on real HW now
(x86_64)
Nov 14 10:30:18 DomU kernel: [ 1169.569936]  []
xen_mc_flush+0x19c/0x1b0

Thank you in advnce,
Oleksandr


On Mon, Nov 14, 2016 at 6:07 PM, Oleksandr Andrushchenko  wrote:

> Hi, there!
>
> Sorry for the long read ahead, but it seems I've got stuck...
>
> I am working on a PV driver and facing an mmap issue.
> This actually happens when user-space tries to mmap
> the memory allocated by the driver:
>
> cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
>   GFP_KERNEL | __GFP_NOWARN);
>
> and maping:
>
> vma->vm_flags &= ~VM_PFNMAP;
> vma->vm_pgoff = 0;
>
> ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
>  cma_obj->paddr, vma->vm_end - vma->vm_start);
>
> Return of the dma_mmap_wc is 0, but I see in the DomU kernel logs:
>
> Nov 14 10:30:18 DomU kernel: [ 1169.569909] [ cut here
> ]
> Nov 14 10:30:18 DomU kernel: [ 1169.569911] WARNING: CPU: 1 PID: 5146 at
> /home/kernel/COD/linux/arch/x86/xen/multicalls.c:129
> xen_mc_flush+0x19c/0x1b0
> Nov 14 10:30:18 DomU kernel: [ 1169.569912] Modules linked in:
> xen_drmfront(OE) drm_kms_helper(OE) drm(OE) fb_sys_fops syscopyarea
> sysfillrect sysimgblt crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
> aesni_intel aes_x86_64 lrw glue_helper ablk_helper cryptd intel_rapl_perf
> autofs4 [last unloaded: xen_drmfront]
> Nov 14 10:30:18 DomU kernel: [ 1169.569919] CPU: 1 PID: 5146 Comm:
> lt-modetest Tainted: GW  OE   4.9.0-040900rc3-generic #201610291831
> Nov 14 10:30:18 DomU kernel: [ 1169.569920]  c900406ffb10
> 81416bf2  
> Nov 14 10:30:18 DomU kernel: [ 1169.569923]  c900406ffb50
> 8108361b 0081406ffb30 88003f90b8e0
> Nov 14 10:30:18 DomU kernel: [ 1169.569925]  0001
> 0010  0201
> Nov 14 10:30:18 DomU kernel: [ 1169.569928] Call Trace:
> Nov 14 10:30:18 DomU kernel: [ 1169.569930]  []
> dump_stack+0x63/0x81
> Nov 14 10:30:18 DomU kernel: [ 1169.569932]  []
> __warn+0xcb/0xf0
> Nov 14 10:30:18 DomU kernel: [ 1169.569934]  []
> warn_slowpath_null+0x1d/0x20
> Nov 14 10:30:18 DomU kernel: [ 1169.569936]  []
> xen_mc_flush+0x19c/0x1b0
> Nov 14 10:30:18 DomU kernel: [ 1169.569938]  []
> __xen_mc_entry+0xf6/0x150
> Nov 14 10:30:18 DomU kernel: [ 1169.569940]  []
> xen_extend_mmu_update+0x56/0xd0
> Nov 14 10:30:18 DomU kernel: [ 1169.569942]  []
> xen_set_pte_at+0x177/0x2f0
> Nov 14 10:30:18 DomU kernel: [ 1169.569944]  []
> remap_pfn_range+0x30b/0x430
> Nov 14 10:30:18 DomU kernel: [ 1169.569946]  []
> dma_common_mmap+0x87/0xa0
> Nov 14 10:30:18 DomU kernel: [ 1169.569953]  []
> drm_gem_cma_mmap_obj+0x8f/0xa0 [drm]
> Nov 14 10:30:18 DomU kernel: [ 1169.569960]  []
> drm_gem_cma_mmap+0x25/0x30 [drm]
> Nov 14 10:30:18 DomU kernel: [ 1169.569962]  []
> mmap_region+0x3a5/0x640
> Nov 14 10:30:18 DomU kernel: [ 1169.569964]  []
> do_mmap+0x446/0x530
> Nov 14 10:30:18 DomU kernel: [ 1169.569966]  [] ?
> common_mmap+0x45/0x50
> Nov 14 10:30:18 DomU kernel: [ 1169.569968]  [] ?
> apparmor_mmap_file+0x16/0x20
> Nov 14 10:30:18 DomU kernel: [ 1169.569970]  [] ?
> security_mmap_file+0xdd/0xf0
> Nov 14 10:30:18 DomU kernel: [ 1169.569972]  []
> vm_mmap_pgoff+0xba/0xf0
> Nov 14 10:30:18 DomU kernel: [ 1169.569974]  []
> SyS_mmap_pgoff+0x1c1/0x290
> Nov 14 10:30:18 DomU kernel: [ 1169.569976]  []
> SyS_mmap+0x1b/0x30
> Nov 14 10:30:18 DomU kernel: [ 1169.569978]  []
> entry_SYSCALL_64_fastpath+0x1e/0xad
> Nov 14 10:30:18 DomU kernel: [ 1169.569979] ---[ end trace
> ce1796cb265ebe08 ]---
> Nov 14 10:30:18 DomU kernel: [ 1169.569982] [ cut here
> ]
>
>
> And output of xl dmesg says:
>
> (XEN) memory.c:226:d0v0 Could not allocate order=9 extent: id=31
> memflags=0x40 (488 of 512)
> (d31) mapping kernel into physical memory
> (d31) about to get started...
> (XEN) d31 attempted to change d31v0's CR4 flags 0620 -> 00040660
> (XEN) d31 attempted to change d31v1's CR4 flags 0620 -> 00040660
> (XEN) traps.c:3657: GPF (): 82d0801a1a09 -> 82d08024b970
> (XEN) mm.c:1893:d31v0 Bad L1 flags 90
> (XEN) mm.c:1893:d31v0 Bad L1 flags 90
> (XEN) mm.c:1893:d31v0 Bad L1 flags 90
> (XEN) mm.c:1893:d31v0 Bad L1 flags 90
>
> My setup is a little bit tricky... I am using a Xen setup running
> inside VirtualBox:
>
> 1. xl info:
> host   : Dom0
> release: 4.4.0-45-generic
> version: #66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016
> machine: x86_64
> nr_cpus: 2
> max_cpu_id : 1
> nr_nodes   : 1
> cores_per_socket   : 2
> threads_per_core   : 1
> cpu_mhz: 3408
> hw_caps: 178bfbff:d6d82203:28100800:
> 0121::00842000::0100
> virt_caps  :
> total_memory   : 2047
> free_memory: 11
> sharing_freed_memory   

Re: [Xen-devel] [PATCH] xen/arm: Add support for 16 bit VMIDs

[Stefano Stabellini]

On Tue, 22 Nov 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 19/11/16 04:34, Stefano Stabellini wrote:
> > On Fri, 11 Nov 2016, Bhupinder Thakur wrote:
> > > VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
> > > This allows more than 256 VMs to be supported by Xen.
> > > 
> > > This change adds support for 16-bit VMIDs in Xen based on whether the
> > > architecture supports it.
> > > 
> > > Signed-off-by: Bhupinder Thakur 
> 
> [...]
> 
> > >  xen/arch/arm/p2m.c  | 44
> > > +++--
> > >  xen/include/asm-arm/p2m.h   |  2 +-
> > >  xen/include/asm-arm/processor.h | 17 +++-
> > >  3 files changed, 55 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > index cc5634b..6ed7e5c 100644
> > > --- a/xen/arch/arm/p2m.c
> > > +++ b/xen/arch/arm/p2m.c
> > > @@ -19,6 +19,7 @@ static unsigned int __read_mostly p2m_root_order;
> > >  static unsigned int __read_mostly p2m_root_level;
> > >  #define P2M_ROOT_ORDERp2m_root_order
> > >  #define P2M_ROOT_LEVEL p2m_root_level
> > > +static unsigned int __read_mostly max_vmid;
> > >  #else
> > >  /* First level P2M is alway 2 consecutive pages */
> > >  #define P2M_ROOT_LEVEL 1
> > > @@ -1219,7 +1220,7 @@ static int p2m_alloc_table(struct domain *d)
> > > 
> > >  p2m->root = page;
> > > 
> > > -p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff)
> > > << 48;
> > > +p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid << 48);
> > > 
> > >  /*
> > >   * Make sure that all TLBs corresponding to the new VMID are flushed
> > > @@ -1230,20 +1231,47 @@ static int p2m_alloc_table(struct domain *d)
> > >  return 0;
> > >  }
> > > 
> > > -#define MAX_VMID 256
> > > +#ifdef CONFIG_ARM_64
> > > +#define MAX_VMID  (1UL << 16)
> > > +#else
> > > +#define MAX_VMID (1UL << 8)
> > > +#endif
> > 
> > Given that MAX_VMID on ARM64 can be either 256 or 65536, and given that
> > this patch also introduces max_vmid, I find these #defines confusing. It
> > is not obvious how max_vmid and MAX_VMID differ. I would go for
> > something like the following:
> > 
> > #define MAX_VMID_8  (1UL << 8)
> > #define MAX_VMID_16 (1UL << 16)
> > #ifdef CONFIG_ARM_64
> > #define MAX_VMID_ARCH MAX_VMID_16
> > #else
> > #define MAX_VMID_ARCH MAX_VMID_8
> > #endif
> 
> MAX_VMID is mostly used to define the vmid at compilation time.
> However, with the support of 16 bits VMID, the size is now 8KB. So we would
> increase Xen footprint by 8KB on all AArch64 platform (even non ARMv8.1
> compliant).
> 
> I would much prefer to see this bitmap allocating at runtime. With that we
> could drop the use of MAX_VMID.

You are right

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

Re: [Xen-devel] Low-hanging fruit bugs for starting contributor

[Konrad Rzeszutek Wilk]

On Tue, Nov 22, 2016 at 05:49:35PM +, Andrew Cooper wrote:
> On 22/11/16 17:42, Elazar Leibovich wrote:
> > Indeed nested virtualization, I apologize for the accidental deletion,
> > While we would like to contribute to nested virtualization eventually,
> > if there are other small bugs in other places in the hypervisor, that
> > would be a good warm up as well.
> 
> Perhaps I should publish my plans for making usable nested-virt in Xen.

Yes please do.
> 
> My current estimate of 2 person-years of work to get it into a state
> where upstream Xen could plausibly support nested-virt.

Two years go fast. And with more people it can go even faster..
> 
> ~Andrew
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] Low-hanging fruit bugs for starting contributor

[Andrew Cooper]

On 22/11/16 17:42, Elazar Leibovich wrote:
> Indeed nested virtualization, I apologize for the accidental deletion,
> While we would like to contribute to nested virtualization eventually,
> if there are other small bugs in other places in the hypervisor, that
> would be a good warm up as well.

Perhaps I should publish my plans for making usable nested-virt in Xen.

My current estimate of 2 person-years of work to get it into a state
where upstream Xen could plausibly support nested-virt.

~Andrew

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

Re: [Xen-devel] Big.LITTLE support (WAS Re: Xen ARM community call)

[Dario Faggioli]

On Tue, 2016-11-22 at 14:28 +, Julien Grall wrote:
> On 09/11/16 22:50, Anastassios Nanos wrote:
> > > Example of features that could be discussed:
> > > - Sharing co-processor between guests
> > > - PCI passthrough
> > 
> > Another issue to discuss, at some point, could be big.LITTLE
> > support
> > (based on https://lists.xenproject.org/archives/html/xen-devel/2016
> > -09/msg01802.html).
> 
> Good point. 
>
Good point indeed. If that will be on the agenda, I'd like to be in the
call, if possible.

> Looking at the discussion, many ideas was suggested and I 
> don't remember whether we all agreed on what to do. I would recommend
> to 
> summarize the discussion in a mail so we can come up with an
> agreement.
> 
> Peng, would you be up to do this?
> 
Yep, that would help a lot! :-)
> Regards,
> 
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH] xen/arm: Add support for 16 bit VMIDs

[Julien Grall]

Hello Bhupinder,

On 11/11/16 09:06, Bhupinder Thakur wrote:

VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
This allows more than 256 VMs to be supported by Xen.

This change adds support for 16-bit VMIDs in Xen based on whether the
architecture supports it.

Signed-off-by: Bhupinder Thakur 
---
 xen/arch/arm/p2m.c  | 44 +++--
 xen/include/asm-arm/p2m.h   |  2 +-
 xen/include/asm-arm/processor.h | 17 +++-
 3 files changed, 55 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index cc5634b..6ed7e5c 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -19,6 +19,7 @@ static unsigned int __read_mostly p2m_root_order;
 static unsigned int __read_mostly p2m_root_level;
 #define P2M_ROOT_ORDERp2m_root_order
 #define P2M_ROOT_LEVEL p2m_root_level
+static unsigned int __read_mostly max_vmid;
 #else
 /* First level P2M is alway 2 consecutive pages */
 #define P2M_ROOT_LEVEL 1
@@ -1219,7 +1220,7 @@ static int p2m_alloc_table(struct domain *d)

 p2m->root = page;

-p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff) << 48;
+p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid << 48);

 /*
  * Make sure that all TLBs corresponding to the new VMID are flushed
@@ -1230,20 +1231,47 @@ static int p2m_alloc_table(struct domain *d)
 return 0;
 }

-#define MAX_VMID 256
+#ifdef CONFIG_ARM_64
+#define MAX_VMID  (1UL << 16)
+#else
+#define MAX_VMID (1UL << 8)
+#endif
+
 #define INVALID_VMID 0 /* VMID 0 is reserved */

 static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;

 /*
- * VTTBR_EL2 VMID field is 8 bits. Using a bitmap here limits us to
- * 256 concurrent domains.
+ * VTTBR_EL2 VMID field is 8 or 16 bits. Aarch64 supports 16-bit VMID.
+ * Using a bitmap here limits us to 256 or 65536 (for Aarch64) concurrent
+ * domains.
  */
 static DECLARE_BITMAP(vmid_mask, MAX_VMID);

 void p2m_vmid_allocator_init(void)
 {
+unsigned int cpu;
+
 set_bit(INVALID_VMID, vmid_mask);
+
+max_vmid = MAX_VMID;


max_vmid is only declared for ARM64 and will break compilation for 
ARM32. Please try to build each patch for both architecture before 
sending to the ML.


However, in this case. It would make more sense to keep the maximum vmid 
static for ARM32 as it will never change.


I quite like what has been done for P2M_ROOT_{LEVEL,ORDER} where the 
define is a constant on ARM32 and point to a variable on ARM64.



+
+#ifdef CONFIG_ARM_64
+/*
+ * if any cpu does not support 16-bit VMID then restrict the
+ * max VMIDs which can be allocated to 256
+ */
+for_each_online_cpu ( cpu )
+{
+const struct cpuinfo_arm *info = _data[cpu];
+
+if ( info->mm64.vmid_bits != VMID_16_BITS_SUPPORT )
+{
+max_vmid = (1UL << 8);
+break;
+}
+}
+#endif


I would rework this code to have max_vmid set to 8 bits by default and 
the turn on 16 bits if available on every CPU.



 }

 static int p2m_alloc_vmid(struct domain *d)
@@ -1254,11 +1282,11 @@ static int p2m_alloc_vmid(struct domain *d)

 spin_lock(_alloc_lock);

-nr = find_first_zero_bit(vmid_mask, MAX_VMID);
+nr = find_first_zero_bit(vmid_mask, max_vmid);

 ASSERT(nr != INVALID_VMID);

-if ( nr == MAX_VMID )
+if ( nr == max_vmid )
 {
 rc = -EBUSY;
 printk(XENLOG_ERR "p2m.c: dom%d: VMID pool exhausted\n", d->domain_id);
@@ -1646,6 +1674,10 @@ void __init setup_virt_paging(void)

 val |= VTCR_PS(pa_range);
 val |= VTCR_TG0_4K;
+
+/* set the VS bit only if 16 bit VMID is supported */
+if ( max_vmid == MAX_VMID )


This check is confusing, I would be clearer to use MAX_VMID_16 or else.


+val |= VTCR_VS;
 val |= VTCR_SL0(pa_range_info[pa_range].sl0);
 val |= VTCR_T0SZ(pa_range_info[pa_range].t0sz);

diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index fdb6b47..bfcdbf1 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -30,7 +30,7 @@ struct p2m_domain {
 struct page_info *root;

 /* Current VMID in use */
-uint8_t vmid;
+uint16_t vmid;

 /* Current Translation Table Base Register for the p2m */
 uint64_t vttbr;
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 15bf890..4b6be3d 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -215,6 +215,7 @@

 #define VTCR_PS(x)  ((x)<<16)

+#define VTCR_VS(_AC(0x1,UL)<<19)


Newline here please.


 #endif

 #define VTCR_RES1   (_AC(1,UL)<<31)
@@ -269,6 +270,11 @@
 /* FSR long format */
 #define FSRL_STATUS_DEBUG   (_AC(0x22,UL)<<0)

+#ifdef CONFIG_ARM_64
+#define VMID_8_BITS_SUPPORT 0x0
+#define VMID_16_BITS_SUPPORT0x2
+#endif


I would prefix the 2 define with MM64_ so we know how the values will be 
matched.



+
 #ifndef 

Re: [Xen-devel] [PATCH-for-4.9 v1 1/8] public / x86: Introduce __HYPERCALL_dm_op...

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 22 November 2016 17:25
> To: Paul Durrant 
> Cc: Andrew Cooper ; Wei Liu
> ; xen-de...@lists.xenproject.org; Daniel DeGraaf
> 
> Subject: RE: [PATCH-for-4.9 v1 1/8] public / x86: Introduce
> __HYPERCALL_dm_op...
> 
> >>> On 22.11.16 at 17:32,  wrote:
> >>  -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 22 November 2016 15:57
> >> To: Paul Durrant 
> >> Cc: Andrew Cooper ; Wei Liu
> >> ; xen-de...@lists.xenproject.org; Daniel De Graaf
> >> 
> >> Subject: Re: [PATCH-for-4.9 v1 1/8] public / x86: Introduce
> >> __HYPERCALL_dm_op...
> >>
> >> >>> On 18.11.16 at 18:13,  wrote:
> >> > This patch simply adds the boilerplate for the hypercall and bumps
> >> > __XEN_LATEST_INTERFACE_VERSION__ to 0x040900.
> >>
> >> Why the latter?
> >
> > Do I not need to bump the interface version?
> 
> Not for plain additions.
> 

Oh, I see. The change is in preparation for later patches which remove HVMOP 
definitions for newer versions, but I can defer making the change till the 
first of those if that makes more sense.

  Paul

> Jan


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

Re: [Xen-devel] Low-hanging fruit bugs for starting contributor

[Elazar Leibovich]

Indeed nested virtualization, I apologize for the accidental deletion,
While we would like to contribute to nested virtualization eventually, if
there are other small bugs in other places in the hypervisor, that would be
a good warm up as well.
Thanks,

On Tue, Nov 22, 2016 at 7:38 PM Lars Kurth  wrote:

> Added Konrad,
>
> as he replied to an earlier mail.
>
> On 22 Nov 2016, at 17:00, Elazar Leibovich <
> elazar.leibov...@ravellosystems.com> wrote:
>
> Hi,
>
> At Ravello/Oracle, we would be interested with contributing patches to the
> Xen hypervisor, especially in areas related , and our team have no
> experience with Xen.
>
>
> Something seems to be missing here. Looking at Ravello's website, I
> suppose you mean nested virtualisation. If so, Andrew Cooper (you can get
> the email address from the MAINTAINERS file in xen.git) may have some ideas
> re bugs / small projects, and I would just CC him. I don't know whether any
> of these are simple enough though.
>
> I've read the contributor guideline, and I think that before contributing
> big patches, we should start with contributing small patches, to make sure
> we're fluent with the entire contribution process, e.g., coverity static
> analysis.
>
>
> If you have specific questions, let me know and I will try to answer them.
> I am currently re-working part 2 of the training at
> https://wiki.xenproject.org/wiki/Contributor_Training and should have an
> updated version within a few days. Also, the #xendevel IRC channel (
> https://www.xenproject.org/help/irc.html) is usually quite good for
> developer related questions and short questions.
>
> Regards
> Lars
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Error regarding filesystem in Dom0 in lager board

[George John]

Thank you all,

what Andrii suggested was really the problem. I modified the uart driver in
the kernel, so that it won't disable the port the xen was using(scif0). Now
the linux Dom0 was booted up. But the new problem now occured was that
filesystem getting stuck before login prompt. I assume it was the problem
when the serial getty service tries to use the scif0 port the xen was using.
Can any one suggest me a solution.?. I am attaching the log

Thanks and regards,

George

On Mon, Nov 21, 2016 at 4:45 PM, Andrii Anisov 
wrote:

> John,
>
> I guess you should remove descriptions of clocks and pins of a serial
> port owned by XEN from the DTSI.
> Normally kernel decides that they are not used, so disables them and
> you think your system hangs.
> I'm not really sure why you are reached this far (rootfs mounting), it
> should be "hanged" earlier. But it could be you case.
>
> Sincerely,
> Andrii Anisov.
>
>
> On Sun, Nov 20, 2016 at 5:44 PM, George John 
> wrote:
> > Hi,
> >
> >
> > On Sat, Nov 19, 2016 at 3:06 AM, Julien Grall 
> wrote:
> >>
> >>
> >>
> >> On 16/11/2016 11:23, George John wrote:
> >>>
> >>> Hi,
> >>
> >>
> >> Hello George,
> >>
> >>> I just bumped in to some errors related to filesystem . The following
> is
> >>> the log. I am using xen 4.7.1 along with linux kernel 3.19.8 as Dom0
> >>
> >>
> >> [...]
> >>
> >>> sh_mobile_sdhi sh_mobile_sdhi.0: mmc1 base at 0xee10 clock rate 97
> >>> MHz
> >>> ata1: link resume succeeded after 1 retries
> >>> ata1: SATA link down (SStatus 0 SControl 300)
> >>> sh_mobile_sdhi sh_mobile_sdhi.2: mmc2 base at 0xee14 clock rate 48
> >>> MHz
> >>> asoc-simple-card asoc-simple-card: ak4642-hifi <-> rcar_sound mapping
> ok
> >>> input: gpio-keys as /devices/platform/gpio-keys/input/input0
> >>> �H�EXT4-fs (mmcblk0p1): error count since last fsck: 24
> >>> EXT4-fs (mmcblk0p1): initial error at time 11: mb_free_blocks:1450:
> >>> inode 67523: block 296960
> >>> EXT4-fs (mmcblk0p1): last error at time 10: ext4_free_inode:340
> >>
> >>
> >> It looks like the filesystem is corrupted. Have you tried to verify the
> >> filesystem with fsck?
> >
> >
> > No, I haven't verified the filesystem. But the filesystem is working
> with no
> > problems for native linux. Also Network file system( working with native
> > linux) is not working when linux is running above xen. So I assumed it
> may
> > be the problem with accessibility of hardware by linux when running above
> > the hypervisor.
> >
> >>>
> >>>
> >>> After this the system hangs
> >>
> >>
> >> Do you mean that even Xen is becoming inaccessible?
> >>
> >> You can try to switch to the Xen console by type 3-times "CTRL-a". You
> >> should see a message from Xen telling you it has switched to Xen. If it
> >> works, then only DOM0 is hanging.
> >
> >
> > Yes, I have tried that. Xen is also becoming inaccessible. Nothing works
> > after the system hang.
> >
> >>
> >>
> >> Regards,
> >>
> >> --
> >> Julien Grall
> >
> >
> >
> > Regards,
> > George
> >
> >
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
> >
>


log_22-11-2016
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH XSA-followup for-4.8] libelf: fix symtab/strtab loading for 32bit domains

[Roger Pau Monne]

Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
guests, that corrupted the section headers array due to the padding
introduced by the elf_shdr union.

The Elf section header array on 32bit should be accessible as an array of
Elf32_Shdr elements, and the union with Elf64_Shdr done in elf_shdr was
breaking this due to size differences between Elf32_Shdr and Elf64_Shdr.

Fix this by copying each section header one by one, and using the proper
size depending on the bitness of the guest kernel. While there, also fix
a couple of consistency issues, by making sure we always use the sizes of
our local versions of the ELF header and the ELF sections headers.

Reported-by: Brian Marcotte 
Signed-off-by: Roger Pau Monné 
Acked-by: Ian Jackson 
Reviewed-by: Jan Beulich 
---
Cc: Brian Marcotte 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Should be backported to Xen 4.7 stable branch.
---
Changes since v4:
 - Fix consistency issues: make sure the sizes of our local copy of the ELF
   header and the ELF section headers are always used.

Changes since v3:
 - Move the definition of elf_sym_header into libelf-loader.c.

Changes since v2:
 - Use offsetof to correctly account for the memory used by the elf header.

Changes since v1:
 - No need to calculate shdr_size again, it's already fetched from the
   original elf header.
 - Remove shdr variable.
 - Use offsetof instead of subtracting two sizeofs.
 - Fix elf_parse_bsdsyms so that it takes into account the size of elf_ehdr
   instead of the size of the native elf header.
---
 xen/common/libelf/libelf-loader.c | 67 ---
 1 file changed, 48 insertions(+), 19 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c 
b/xen/common/libelf/libelf-loader.c
index d67e0a7..eb7569d 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -21,10 +21,17 @@
 
 #include "libelf-private.h"
 
+/*  */
+
 /* Number of section header needed in order to fit the SYMTAB and STRTAB. */
 #define ELF_BSDSYM_SECTIONS 3
-
-/*  */
+struct elf_sym_header {
+uint32_t size;
+struct {
+elf_ehdr header;
+elf_shdr section[ELF_BSDSYM_SECTIONS];
+} elf_header;
+} __attribute__((packed));
 
 elf_errorstatus elf_init(struct elf_binary *elf, const char *image_input, 
size_t size)
 {
@@ -172,9 +179,10 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t 
pstart)
 /* Space to store the size of the elf image */
 sz = sizeof(uint32_t);
 
-/* Space for the elf and elf section headers */
-sz += elf_uval(elf, elf->ehdr, e_ehsize) +
-  ELF_BSDSYM_SECTIONS * elf_uval(elf, elf->ehdr, e_shentsize);
+/* Space for the ELF header and section headers */
+sz += offsetof(struct elf_sym_header, elf_header.section) +
+  ELF_BSDSYM_SECTIONS * (elf_64bit(elf) ? sizeof(Elf64_Shdr) :
+  sizeof(Elf32_Shdr));
 sz = elf_round_up(elf, sz);
 
 /*
@@ -251,18 +259,11 @@ static void elf_load_bsdsyms(struct elf_binary *elf)
  * strtab, so we only need three section headers in our fake ELF
  * header (first section header is always the undefined section).
  */
-struct {
-uint32_t size;
-struct {
-elf_ehdr header;
-elf_shdr section[ELF_BSDSYM_SECTIONS];
-} __attribute__((packed)) elf_header;
-} __attribute__((packed)) header;
-
+struct elf_sym_header header;
 ELF_HANDLE_DECL(elf_ehdr) header_handle;
-unsigned long shdr_size;
+unsigned long shdr_size, ehdr_size, header_size;
 ELF_HANDLE_DECL(elf_shdr) section_handle;
-unsigned int link, rc;
+unsigned int link, rc, i;
 elf_ptrval header_base;
 elf_ptrval elf_header_base;
 elf_ptrval symtab_base;
@@ -301,8 +302,15 @@ do {   
 \
 header_handle = ELF_MAKE_HANDLE(elf_ehdr,
 ELF_REALPTR2PTRVAL(_header.header));
 elf_memcpy_safe(elf, ELF_HANDLE_PTRVAL(header_handle),
-ELF_HANDLE_PTRVAL(elf->ehdr),
-elf_uval(elf, elf->ehdr, e_ehsize));
+ELF_HANDLE_PTRVAL(elf->ehdr), ehdr_size);
+
+/*
+ * Set the ELF header size, section header entry size and version
+ * (in case we are dealing with an input ELF header that has extensions).
+ */
+elf_store_field_bitness(elf, 

Re: [Xen-devel] Low-hanging fruit bugs for starting contributor

[Lars Kurth]

Added Konrad, 

as he replied to an earlier mail.

> On 22 Nov 2016, at 17:00, Elazar Leibovich 
>  wrote:
> 
> Hi,
> At Ravello/Oracle, we would be interested with contributing patches to the 
> Xen hypervisor, especially in areas related , and our team have no experience 
> with Xen.

Something seems to be missing here. Looking at Ravello's website, I suppose you 
mean nested virtualisation. If so, Andrew Cooper (you can get the email address 
from the MAINTAINERS file in xen.git) may have some ideas re bugs / small 
projects, and I would just CC him. I don't know whether any of these are simple 
enough though. 

> I've read the contributor guideline, and I think that before contributing big 
> patches, we should start with contributing small patches, to make sure we're 
> fluent with the entire contribution process, e.g., coverity static analysis.

If you have specific questions, let me know and I will try to answer them. I am 
currently re-working part 2 of the training at 
https://wiki.xenproject.org/wiki/Contributor_Training 
 and should have an 
updated version within a few days. Also, the #xendevel IRC channel 
(https://www.xenproject.org/help/irc.html 
) is usually quite good for developer 
related questions and short questions.

Regards
Lars 

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

Re: [Xen-devel] [PATCH-for-4.9 v1 1/8] public / x86: Introduce __HYPERCALL_dm_op...

[Jan Beulich]

>>> On 22.11.16 at 17:32,  wrote:
>>  -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 22 November 2016 15:57
>> To: Paul Durrant 
>> Cc: Andrew Cooper ; Wei Liu
>> ; xen-de...@lists.xenproject.org; Daniel De Graaf
>> 
>> Subject: Re: [PATCH-for-4.9 v1 1/8] public / x86: Introduce
>> __HYPERCALL_dm_op...
>> 
>> >>> On 18.11.16 at 18:13,  wrote:
>> > This patch simply adds the boilerplate for the hypercall and bumps
>> > __XEN_LATEST_INTERFACE_VERSION__ to 0x040900.
>> 
>> Why the latter?
> 
> Do I not need to bump the interface version?

Not for plain additions.

Jan


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

Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

[Eric Blake]

On 11/22/2016 11:00 AM, Olaf Hering wrote:
> On Tue, Nov 22, Eric Blake wrote:
> 
>> if (sec_start + sec_count < sec_count ||
>> sec_start > (INT64_MAX >> BDRV_SECTOR_BITS) - sec_count) {
>> return false;
>> }
> 
> My point was: how does this handle sec_start=0,sec_count=UINT64_MAX or
> sec_start=INT64_MAX,sec_count=INT64_MAX? For me this gets past the if().

Fair enough.  Your test that things didn't overflow means that you can
then safely compare the sum to the limit, so go with:

if (sec_start + sec_count < sec_count ||
sec_start + sec_count > INT64_MAX >> BDRV_SECTOR_BITS) {
return false;
}

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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

Re: [Xen-devel] [PATCH 3/3] x86/HVM: correct error code writing during task switch

[Andrew Cooper]

On 22/11/16 13:56, Jan Beulich wrote:
> Whether to write 32 or just 16 bits depends on the D bit of the target
> CS. The width of the stack pointer to use depends on the B bit of the
> target SS.
>
> Also avoid using the no-fault copying routine.
>
> Finally avoid using yet another struct segment_register variable here.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3033,9 +3033,6 @@ void hvm_task_switch(
>  goto out;
>  }
>  
> -if ( (tss.trace & 1) && !exn_raised )
> -hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
> -
>  tr.attr.fields.type = 0xb; /* busy 32-bit tss */
>  hvm_set_segment_register(v, x86_seg_tr, );
>  
> @@ -3051,17 +3048,32 @@ void hvm_task_switch(
>  
>  if ( errcode >= 0 )
>  {
> -struct segment_register reg;
>  unsigned long linear_addr;
> -regs->esp -= 4;
> -hvm_get_segment_register(current, x86_seg_ss, );
> -/* Todo: do not ignore access faults here. */
> -if ( hvm_virtual_to_linear_addr(x86_seg_ss, , regs->esp,
> -4, hvm_access_write, 32,
> +unsigned int opsz, sp;
> +
> +hvm_get_segment_register(current, x86_seg_cs, );

You already have current latched in v at this point.

Otherwise, Reviewed-by: Andrew Cooper 

> +opsz = segr.attr.fields.db ? 4 : 2;
> +hvm_get_segment_register(current, x86_seg_ss, );
> +if ( segr.attr.fields.db )
> +sp = regs->_esp -= opsz;
> +else
> +sp = *(uint16_t *)>esp -= opsz;
> +if ( hvm_virtual_to_linear_addr(x86_seg_ss, , sp, opsz,
> +hvm_access_write,
> +16 << segr.attr.fields.db,
>  _addr) )
> -hvm_copy_to_guest_virt_nofault(linear_addr, , 4, 0);
> +{
> +rc = hvm_copy_to_guest_virt(linear_addr, , opsz, 0);
> +if ( rc == HVMCOPY_bad_gva_to_gfn )
> +exn_raised = 1;
> +else if ( rc != HVMCOPY_okay )
> +goto out;
> +}
>  }
>  
> +if ( (tss.trace & 1) && !exn_raised )
> +hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
> +
>   out:
>  hvm_unmap_entry(optss_desc);
>  hvm_unmap_entry(nptss_desc);
>
>
>


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

Re: [Xen-devel] Low-hanging fruit bugs for starting contributor

[Elazar Leibovich]

Hi,
At Ravello/Oracle, we would be interested with contributing patches to the
Xen hypervisor, especially in areas related , and our team have no
experience with Xen.
I've read the contributor guideline, and I think that before contributing
big patches, we should start with contributing small patches, to make sure
we're fluent with the entire contribution process, e.g., coverity static
analysis.
As of the setup phase. I created a pbuilder clean environment with the
following script, note the list of build dependencies:

#!/bin/bash -vx
set -e
sudo apt install pbuilder
[ ! -f /var/cache/pbuilder/base.tgz ] && sudo pbuilder --create
--distribution xenial --othermirror 'deb
http://il.archive.ubuntu.com/ubuntu/ xenial main restricted universe
multiverse'
DEPS=/tmp/$USER-$$-dep-install
echo -e '#!/bin/bash -xv\napt-get install -y wget curl ftp autotools-dev
debhelper dpkg-dev lsb-release python-dev bcc gcc-multilib e2fslibs-dev
iasl seabios libaio-dev libfdt-dev libglib2.0-dev liblzma-dev
libncurses5-dev libpixman-1-dev libyajl-dev libssl-dev pkg-config uuid-dev
zlib1g-dev libsystemd-dev texinfo fakeroot' > $DEPS
trap "rm $DEPS" EXIT
chmod +x $DEPS
sudo pbuilder --execute --save-after-exec $DEPS

Then I went on, pbuilder --login, and inside
$ make debball
I ran a  plain Ubuntu Server on KVM with nested virtualization enabled,
then I installed the deb on the ubuntu,
$ update-grub
installed some runtime dependencies
$ apt install libpixman-1-dev libfdt-dev libaio-dev libyajl-dev
and booted with the new Xen entry. Note that you can rename
/etc/grub.d/20_linux_xen to be /etc/grub.d/09_linux_xen before update-grub
and hence have your machine to boot to Xen by default.

Finally I started the xen daemons
$ service xen-watchdog start
$ service xendomains start
$ service xendriverdomain start
$ service xencommons start
Than, I created VMs with the xl create tool.
I'm not sure I have the best setup, and I'll be happy to hear what I did
wrong, or what could be improved.
Thanks!

On Tue, Nov 22, 2016 at 6:19 PM Lars Kurth  wrote:

> Elazar,
>
> we do have a list of links to starter projects at the bottom of
> https://wiki.xenproject.org/wiki/Outreachy/Round12%2B2016GSoC
> , but these
> are probably not quite what you are looking for. We don't maintain a list
> of starter bugs, because much of it depends on what you want to get out of
> it. I am assuming you solved build, set-up, etc. already?
>
> If you could give us a bit of context and what you are trying to
> accomplish, I can CC a community member who can then point you in the right
> direction or alternatively can come up with a small project that can help
> you get up to speed.
>
> Regards
> Lars
>
> On 22 Nov 2016, at 15:49, Elazar Leibovich <
> elazar.leibov...@ravellosystems.com> wrote:
>
> Hi,
> For someone wishing to start contributing to  Xen hypervisor, what would
> you recommend as an easy, educational, bug he could start with?
>
> Thanks,
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

[Olaf Hering]

On Tue, Nov 22, Eric Blake wrote:

> if (sec_start + sec_count < sec_count ||
> sec_start > (INT64_MAX >> BDRV_SECTOR_BITS) - sec_count) {
> return false;
> }

My point was: how does this handle sec_start=0,sec_count=UINT64_MAX or
sec_start=INT64_MAX,sec_count=INT64_MAX? For me this gets past the if().

Olaf


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf b43dd22981b71dd78dd4cc04d55dc23d81c3bafb
baseline version:
 ovmf 01dd077315c6759c94af9af4232f8318db13cf8d

Last test of basis68075  2016-11-21 16:49:08 Z1 days
Testing same since68080  2016-11-22 11:49:41 Z0 days1 attempts


People who touched revisions under test:
  Jeff Fan 
  Laszlo Ersek 

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



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

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

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


Push not applicable.


commit b43dd22981b71dd78dd4cc04d55dc23d81c3bafb
Author: Laszlo Ersek 
Date:   Thu Nov 17 21:13:29 2016 +0100

UefiCpuPkg/PiSmmCpuDxeSmm: dynamic PcdCpuSmmApSyncTimeout, PcdCpuSmmSyncMode

Move the declaration of these PCDs from the

  [PcdsFixedAtBuild, PcdsPatchableInModule]

section of "UefiCpuPkg/UefiCpuPkg.dec" to the

  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]

section. Their types, default values, and token values remain unchanged.

Only UefiCpuPkg/PiSmmCpuDxeSmm consumes these PCDs, specifically on the
call stack of its entry point function, and it turns them into static or
dynamically allocated data in SMRAM:

  PiCpuSmmEntry()[PiSmmCpuDxeSmm.c]
InitializeSmmTimer() [SyncTimer.c]
  PcdCpuSmmApSyncTimeout
  -> mTimeoutTicker
InitializeMpServiceData()[MpService.c]
  InitializeMpSyncData() [MpService.c]
PcdCpuSmmSyncMode
-> mSmmMpSyncData->EffectiveSyncMode

However, there's another call path to fetching "PcdCpuSmmSyncMode", namely

  SmmInitHandler()   [PiSmmCpuDxeSmm.c]
InitializeMpSyncData()   [MpService.c]
  PcdCpuSmmSyncMode
  -> mSmmMpSyncData->EffectiveSyncMode

and this path is exercised during S3 resume (as stated by the comment in
SmmInitHandler() too, "Initialize private data during S3 resume").

While we can call the PCD protocol (via PcdLib) for fetching dynamic PCDs
in the entry point function, we cannot do that at S3 resume. Therefore
pre-fetch PcdCpuSmmSyncMode into a new global variable (which lives in
SMRAM) in InitializeMpServiceData(), just before calling
InitializeMpSyncData(). This way InitializeMpSyncData() can retrieve the
stashed PCD value from SMRAM, regardless of the boot mode.

Cc: Jeff Fan 
Cc: Jordan Justen 
Cc: Michael Kinney 
Cc: Paolo Bonzini 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=230
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jeff Fan 

commit eaae7b33b1cf6b9f21db1636f219c2b6a8d88afd
Author: Jeff Fan 
Date:   Fri Nov 18 10:46:43 2016 +0800

MdeModulePkg/PiSmmCore: Cache CommunicationBuffer info before using it

gSmmCorePrivate->CommunicationBuffer and gSmmCorePrivate->BufferSize locate 
at
runtime memory region. That means they could be modified by non-SMM code 
during
runtime.

We should cache them into SMM local variables before we verify them. After
verification, we should use the cached ones directly instead of the ones in
gSmmCorePrivate.

Cc: Jiewen Yao 
Cc: Feng Tian 
Cc: Michael D Kinney 

Re: [Xen-devel] [PATCH 2/3] x86/HVM: limit writes to outgoing TSS during task switch

[Andrew Cooper]

On 22/11/16 13:55, Jan Beulich wrote:
> The only fields modified are EIP, EFLAGS, GPRs, and segment selectors.
> CR3 in particular is not supposed to be updated.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2952,7 +2952,6 @@ void hvm_task_switch(
>  if ( taskswitch_reason == TSW_iret )
>  eflags &= ~X86_EFLAGS_NT;
>  
> -tss.cr3= v->arch.hvm_vcpu.guest_cr[3];
>  tss.eip= regs->eip;
>  tss.eflags = eflags;
>  tss.eax= regs->eax;
> @@ -2979,8 +2978,10 @@ void hvm_task_switch(
>  hvm_get_segment_register(v, x86_seg_ldtr, );
>  tss.ldt = segr.sel;
>  
> -rc = hvm_copy_to_guest_virt(
> -prev_tr.base, , sizeof(tss), PFEC_page_present);
> +rc = hvm_copy_to_guest_virt(prev_tr.base + offsetof(typeof(tss), eip),
> +,
> +(void *) - (void *),

How about offsetof(typeof(tss), trace) - offsetof(typeof(tss), eip)?

It avoids some casts and void pointer arithmetic.

Either way, Reviewed-by: Andrew Cooper 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  f6b7fedc896250028cb81dafe9a3f6773aaf1da2
baseline version:
 xen  f678e2c78110e73431217306bbd33c736802d700

Last test of basis   102490  2016-11-21 18:01:03 Z0 days
Testing same since   102516  2016-11-22 13:01:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Beulich 
  Roger Pau Monné 

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



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

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

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

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


Pushing revision :

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail REGR. vs. 101909
 test-amd64-amd64-libvirt 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-pair 20 guest-start/debian  fail REGR. vs. 101909
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 101909
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail REGR. vs. 101909
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt  11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt-xsm  11 guest-start  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 101909
 test-armhf-armhf-libvirt 11 guest-start  fail REGR. vs. 101909

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl  14 guest-stop fail pass in 102492

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101909
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101909

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

version targeted for testing:
 qemuuc36ed06e9159fa484b711dfdd27ec64d7ac3d17a
baseline version:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f

Last test of basis   101909  2016-11-03 23:21:40 Z   18 days
Failing since101943  2016-11-04 22:40:48 Z   17 days   40 attempts
Testing same since   102492  2016-11-21 19:22:23 Z0 days2 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Williamson 
  Alexey Kardashevskiy 
  Ankit Kumar 
  ann.zhuangyany...@huawei.com
  Ashijeet Acharya 
  Balbir singh 
  Bharata B Rao 
  Brian Candler 
  Christian Borntraeger 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel Oram 
  Daniel P. Berrange 
  David Gibson 
  Doug Evans 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Farhan Ali 
  Gautham R. Shenoy 
  Gerd Hoffmann 
  Gonglei 
  Greg Kurz 
  Halil Pasic 
  Igor Mammedov 
  Jason Wang 
  Jeff Cody 
  John Snow 
  Jose Ricardo Ziviani 
  Juan Quintela 
  Julian Brown 

Re: [Xen-devel] [PATCH v3 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

[Boris Ostrovsky]

On 11/22/2016 11:05 AM, Jan Beulich wrote:

On 22.11.16 at 16:30,  wrote:

On 11/22/2016 10:01 AM, Jan Beulich wrote:



+const static uint8_t pm1a_mask[4] = {ACPI_BITMASK_GLOBAL_LOCK_STATUS,

0,

+ ACPI_BITMASK_GLOBAL_LOCK_ENABLE,

0};

+const static uint8_t gpe0_mask[4] = {1U << XEN_GPE0_CPUHP_BIT, 0,
+ 1U << XEN_GPE0_CPUHP_BIT, 0};


Hmm, funny, in someone else's patch I've recently seen the same.
Can we please stick to the more standard "storage type first"
ordering of declaration elements. After all const modifies the type,
and hence better stays together with it.

And then I'd like to have an explanation (in the commit message)
about the choice of the values for pm1a_mask.


Sure (Lock status/enable is required)


And nothing else is? And there's no other implementation
required for the lock bit?


The other part is the global lock itself, which is part of the FACS that 
we allocate in build.c


-boris

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

Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

[Eric Blake]

On 11/22/2016 10:12 AM, Olaf Hering wrote:
> On Fri, Nov 18, Eric Blake wrote:
> 
>> if (sec_start > (INT64_MAX >> BDRV_SECTOR_BITS) - sec_count)
> 
> I have looked at this for a while now and cant spot how this would cover
> all cases. Are you saying there should be just a single overflow check,
> yours? My change has two: one to check for wrap around and to check
> against the upper limit. My check happens to work with 0/UINT64_MAX or
> INT64_MAX/INT64_MAX as input, yours appearently not.
> Obviously I'm missing something essential.

I never suggested eliminating the wraparound check, only simplifying the
overflow check.  You could combine the wraparound and overflow into one:

if (sec_start + sec_count < sec_count ||
sec_start > (INT64_MAX >> BDRV_SECTOR_BITS) - sec_count) {
return false;
}

Remember, sec_start and sec_count were both typed as unsigned 64-bit
values, so everything in the above computation is well-defined
arithmetic, and you catch all cases of trying to add two numbers into
something that doesn't fit in 64 bits, as well as all cases of the
addition fitting in 64 bits but going beyond the maximum possible sector
number (since it is not possible to have a sector number whose
corresponding offset would exceed 63 bits).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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

Re: [Xen-devel] [PATCH-for-4.9 v1 1/8] public / x86: Introduce __HYPERCALL_dm_op...

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 22 November 2016 15:57
> To: Paul Durrant 
> Cc: Andrew Cooper ; Wei Liu
> ; xen-de...@lists.xenproject.org; Daniel De Graaf
> 
> Subject: Re: [PATCH-for-4.9 v1 1/8] public / x86: Introduce
> __HYPERCALL_dm_op...
> 
> >>> On 18.11.16 at 18:13,  wrote:
> > This patch simply adds the boilerplate for the hypercall and bumps
> > __XEN_LATEST_INTERFACE_VERSION__ to 0x040900.
> 
> Why the latter?

Do I not need to bump the interface version?

> 
> > +static int
> dm_op_get_buf(XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs,
> > + unsigned int nr_bufs, unsigned int idx,
> > + struct xen_dm_op_buf *buf)
> > +{
> > +if ( idx >= nr_bufs )
> > +return -EFAULT;
> 
> There's no fault here. ENOENT, EIO, ENXIO, ...?
> 

True, ENOENT I think.

> > +return copy_from_guest_offset(buf, bufs, idx, 1);
> > +}
> > +
> > +static int
> >
> dm_op_copy_buf_from_guest(XEN_GUEST_HANDLE_PARAM(xen_dm_op_
> buf_t) bufs,
> > + unsigned int nr_bufs, void *dst,
> > + unsigned int idx, size_t dst_size)
> > +{
> > +struct xen_dm_op_buf buf;
> > +size_t size;
> > +int rc;
> > +
> > +memset(dst, 0, dst_size);
> > +
> > +rc = dm_op_get_buf(bufs, nr_bufs, idx, );
> > +if ( rc )
> > +return -EFAULT;
> > +
> > +size = min(dst_size, buf.size);
> 
> Hmm, the file is x86-specific, so this may indeed build. But formally
> the two expressions are of different types, which min() doesn't like.
> 

Ok.

> > +static int
> dm_op_copy_buf_to_guest(XEN_GUEST_HANDLE_PARAM(xen_dm_op_bu
> f_t) bufs,
> > +   unsigned int nr_bufs, unsigned int idx,
> > +   void *src, size_t src_size)
> > +{
> > +struct xen_dm_op_buf buf;
> > +size_t size;
> > +int rc;
> > +
> > +rc = dm_op_get_buf(bufs, nr_bufs, idx, );
> > +if ( rc )
> > +return -EFAULT;
> > +
> > +size = min(buf.size, src_size);
> > +
> > +rc = copy_to_guest(buf.h, src, size);
> > +if ( rc )
> > +return -EFAULT;
> > +
> > +return 0;
> > +}
> 
> For copying from guest doing all-or-nothing is probably sufficient,
> but is that really the case also for copying data back?
> 

It is ok for now. It can always be changed later if we want to optimise.

> > +long do_dm_op(domid_t domid,
> > +  unsigned int nr_bufs,
> > +  XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs)
> > +{
> > +struct domain *d;
> > +struct xen_dm_op op;
> > +bool restart;
> > +long rc;
> > +
> > +rc = rcu_lock_remote_domain_by_id(domid, );
> > +if ( rc )
> > +return rc;
> > +
> > +restart = false;
> > +
> > +if ( !has_hvm_container_domain(d) )
> > +goto out;
> > +
> > +rc = xsm_dm_op(XSM_DM_PRIV, d);
> > +if ( rc )
> > +goto out;
> > +
> > +rc = dm_op_copy_buf_from_guest(bufs, nr_bufs, , 0, sizeof(op));
> > +if ( rc )
> > +goto out;
> > +
> > +switch ( op.op )
> > +{
> > +default:
> > +rc = -EOPNOTSUPP;
> > +break;
> > +}
> > +
> > +if ( rc == -ERESTART )
> > +restart = true;
> > +
> > +if ( !restart && rc )
> 
> Is the "restart" variable really necessary?
> 
> > +goto out;
> > +
> > +rc = dm_op_copy_buf_to_guest(bufs, nr_bufs, 0, , sizeof(op));
> > +
> > +out:
> 
> A goto over a single statement is certainly too much goto-ery for
> my taste. In any event - labels indented by at least one space
> please.
> 

Ok, I'll get rid of the goto despite it making the code look more cumbersome to 
me.

> > +#ifndef __XEN_PUBLIC_HVM_DM_OP_H__
> > +#define __XEN_PUBLIC_HVM_DM_OP_H__
> > +
> > +#if defined(__XEN__) || defined(__XEN_TOOLS__)
> > +
> > +#include "../xen.h"
> > +
> > +#define DMOP_invalid 0
> 
> XEN_DMOP_invalid
> 

Yes, indeed.

> > +struct xen_dm_op {
> > +uint32_t op;
> > +};
> > +
> > +struct xen_dm_op_buf {
> > +XEN_GUEST_HANDLE(void) h;
> > +uint64_t size;
> > +};
> > +typedef struct xen_dm_op_buf xen_dm_op_buf_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_dm_op_buf_t);
> > +
> > +/* ` enum neg_errnoval
> > + * ` HYPERVISOR_dm_op(domid_t domid,
> > + * `  xen_dm_op_buf_t *bufs,
> 
> I'd prefer you to use the bufs[] notation here, to emphasize the
> array nature.
> 

Ok.

> > + * `  unsigned int nr_bufs)
> > + * `
> > + *
> > + * @domid is the domain the hypercall operates on.
> > + * @bufs points to an array of buffers where @bufs[0] contains a struct
> > + * dm_op, describing the specific device model operation and its
> parameters.
> 
> xen_dm_op
> 

Yep.

> > + * @bufs[1..] may be referenced in the parameters for the purposes of
> > + * passing extra information 

Re: [Xen-devel] [PATCH 1/3] x86/HVM: limit writes to incoming TSS during task switch

[Andrew Cooper]

On 22/11/16 13:55, Jan Beulich wrote:
> The only field modified (and even that conditionally) is the back link.
> Write only that field, and only when it actually has been written to.
>
> Take the opportunity and also ditch the pointless initializer from the
> "tss" local variable.

It would help to point out that tss is unconditionally filled completely
from guest memory.

> Signed-off-by: Jan Beulich 

As for the mechanical adjustments here, Reviewed-by: Andrew Cooper


However, is the position of the backlink write actually correct?  I'd
have thought that all access to the old tss happen before switching cr3.

I can't find a useful description of the order of events in a task
switch in either manual.

~Andrew

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

Re: [Xen-devel] [PATCH] xen/arm: Add support for 16 bit VMIDs

[Julien Grall]

Hi Stefano,

On 19/11/16 04:34, Stefano Stabellini wrote:

On Fri, 11 Nov 2016, Bhupinder Thakur wrote:

VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
This allows more than 256 VMs to be supported by Xen.

This change adds support for 16-bit VMIDs in Xen based on whether the
architecture supports it.

Signed-off-by: Bhupinder Thakur 


[...]


 xen/arch/arm/p2m.c  | 44 +++--
 xen/include/asm-arm/p2m.h   |  2 +-
 xen/include/asm-arm/processor.h | 17 +++-
 3 files changed, 55 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index cc5634b..6ed7e5c 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -19,6 +19,7 @@ static unsigned int __read_mostly p2m_root_order;
 static unsigned int __read_mostly p2m_root_level;
 #define P2M_ROOT_ORDERp2m_root_order
 #define P2M_ROOT_LEVEL p2m_root_level
+static unsigned int __read_mostly max_vmid;
 #else
 /* First level P2M is alway 2 consecutive pages */
 #define P2M_ROOT_LEVEL 1
@@ -1219,7 +1220,7 @@ static int p2m_alloc_table(struct domain *d)

 p2m->root = page;

-p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff) << 48;
+p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid << 48);

 /*
  * Make sure that all TLBs corresponding to the new VMID are flushed
@@ -1230,20 +1231,47 @@ static int p2m_alloc_table(struct domain *d)
 return 0;
 }

-#define MAX_VMID 256
+#ifdef CONFIG_ARM_64
+#define MAX_VMID  (1UL << 16)
+#else
+#define MAX_VMID (1UL << 8)
+#endif


Given that MAX_VMID on ARM64 can be either 256 or 65536, and given that
this patch also introduces max_vmid, I find these #defines confusing. It
is not obvious how max_vmid and MAX_VMID differ. I would go for
something like the following:

#define MAX_VMID_8  (1UL << 8)
#define MAX_VMID_16 (1UL << 16)
#ifdef CONFIG_ARM_64
#define MAX_VMID_ARCH MAX_VMID_16
#else
#define MAX_VMID_ARCH MAX_VMID_8
#endif


MAX_VMID is mostly used to define the vmid at compilation time.
However, with the support of 16 bits VMID, the size is now 8KB. So we 
would increase Xen footprint by 8KB on all AArch64 platform (even non 
ARMv8.1 compliant).


I would much prefer to see this bitmap allocating at runtime. With that 
we could drop the use of MAX_VMID.


Regards,

--
Julien Grall

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

Re: [Xen-devel] Ping: [PATCH] x86/memshr: properly check grant references

[Tamas K Lengyel]

On Tue, Nov 22, 2016 at 3:12 AM, Jan Beulich  wrote:

> >>> On 14.11.16 at 11:34,  wrote:
> > They need to be range checked against the current table limit in any
> > event.
> >
> > Reported-by: Huawei PSIRT 
> >
> > Move the code to where it belongs, eliminating a number of duplicate
> > definitions. Add locking. Produce proper error codes, and consume them
> > instead of making one up. Check grant type. Convert parameter types at
> > once.
> >
> > Signed-off-by: Jan Beulich 
>
> Tamas? (The minor fix needed to address Andrew's reply doesn't seem
> to warrant sending out a v2.)


> > ---
> > Note that likely there's more work needed subsequently: The grant isn't
> > being marked in use for the duration of the use of the GFN. But I'll
> > leave that to someone actually knowing how to properly to test this.
>
>
Hi Jan,
unfortunately I don't have a good way to test this either as I never used
memsharing with grefs before. The above comment about the grant not being
marked for in-use makes me wonder whether this is a regression from this
patch or whether that just was never the case. Either way, I can see this
being an issue only if memory is being removed by hot-plugging, which AFAIK
is not a supported scenario anyway. The rest of the patch is fairly
mechanical, so:

Acked-by: Tamas K Lengyel 


> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @@ -753,75 +753,25 @@ int mem_sharing_debug_gfn(struct domain
> >  return num_refs;
> >  }
> >
> > -#define SHGNT_PER_PAGE_V1 (PAGE_SIZE / sizeof(grant_entry_v1_t))
> > -#define shared_entry_v1(t, e) \
> > -((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1])
> > -#define SHGNT_PER_PAGE_V2 (PAGE_SIZE / sizeof(grant_entry_v2_t))
> > -#define shared_entry_v2(t, e) \
> > -((t)->shared_v2[(e)/SHGNT_PER_PAGE_V2][(e)%SHGNT_PER_PAGE_V2])
> > -#define STGNT_PER_PAGE (PAGE_SIZE / sizeof(grant_status_t))
> > -#define status_entry(t, e) \
> > -((t)->status[(e)/STGNT_PER_PAGE][(e)%STGNT_PER_PAGE])
> > -
> > -static grant_entry_header_t *
> > -shared_entry_header(struct grant_table *t, grant_ref_t ref)
> > -{
> > -ASSERT (t->gt_version != 0);
> > -if ( t->gt_version == 1 )
> > -return (grant_entry_header_t*)_entry_v1(t, ref);
> > -else
> > -return _entry_v2(t, ref).hdr;
> > -}
> > -
> > -static int mem_sharing_gref_to_gfn(struct domain *d,
> > -   grant_ref_t ref,
> > -   unsigned long *gfn)
> > -{
> > -if ( d->grant_table->gt_version < 1 )
> > -return -1;
> > -
> > -if ( d->grant_table->gt_version == 1 )
> > -{
> > -grant_entry_v1_t *sha1;
> > -sha1 = _entry_v1(d->grant_table, ref);
> > -*gfn = sha1->frame;
> > -}
> > -else
> > -{
> > -grant_entry_v2_t *sha2;
> > -sha2 = _entry_v2(d->grant_table, ref);
> > -*gfn = sha2->full_page.frame;
> > -}
> > -
> > -return 0;
> > -}
> > -
> > -
> >  int mem_sharing_debug_gref(struct domain *d, grant_ref_t ref)
> >  {
> > -grant_entry_header_t *shah;
> > +int rc;
> >  uint16_t status;
> > -unsigned long gfn;
> > +gfn_t gfn;
> >
> > -if ( d->grant_table->gt_version < 1 )
> > +rc = mem_sharing_gref_to_gfn(d->grant_table, ref, , );
> > +if ( rc )
> >  {
> > -MEM_SHARING_DEBUG(
> > -"Asked to debug [dom=%d,gref=%d], but not yet
> inited.\n",
> > -d->domain_id, ref);
> > -return -EINVAL;
> > -}
> > -(void)mem_sharing_gref_to_gfn(d, ref, );
> > -shah = shared_entry_header(d->grant_table, ref);
> > -if ( d->grant_table->gt_version == 1 )
> > -status = shah->flags;
> > -else
> > -status = status_entry(d->grant_table, ref);
> > +MEM_SHARING_DEBUG("Asked to debug [dom=%d,gref=%u]: error
> %d.\n",
> > +  d->domain_id, ref, rc);
> > +return rc;
> > +}
> >
> >  MEM_SHARING_DEBUG(
> >  "==> Grant [dom=%d,ref=%d], status=%x. ",
> >  d->domain_id, ref, status);
> >
> > -return mem_sharing_debug_gfn(d, gfn);
> > +return mem_sharing_debug_gfn(d, gfn_x(gfn));
> >  }
> >
> >  int mem_sharing_nominate_page(struct domain *d,
> > @@ -1422,23 +1372,24 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_P
> >  case XENMEM_sharing_op_nominate_gref:
> >  {
> >  grant_ref_t gref = mso.u.nominate.u.grant_ref;
> > -unsigned long gfn;
> > +gfn_t gfn;
> >  shr_handle_t handle;
> >
> >  rc = -EINVAL;
> >  if ( !mem_sharing_enabled(d) )
> >  goto out;
> > -if ( mem_sharing_gref_to_gfn(d, gref, ) < 0 )
> > +rc = mem_sharing_gref_to_gfn(d->grant_table, gref, ,
> NULL);
> > +if ( rc < 0 )
> >  goto out;
> >
> 

Re: [Xen-devel] Ping: [PATCH] x86/memshr: properly check grant references

[Wei Liu]

On Tue, Nov 22, 2016 at 09:17:43AM -0700, Jan Beulich wrote:
> >>> On 22.11.16 at 17:13,  wrote:
> > On Tue, Nov 22, 2016 at 3:12 AM, Jan Beulich  wrote:
> > 
> >> >>> On 14.11.16 at 11:34,  wrote:
> >> > They need to be range checked against the current table limit in any
> >> > event.
> >> >
> >> > Reported-by: Huawei PSIRT 
> >> >
> >> > Move the code to where it belongs, eliminating a number of duplicate
> >> > definitions. Add locking. Produce proper error codes, and consume them
> >> > instead of making one up. Check grant type. Convert parameter types at
> >> > once.
> >> >
> >> > Signed-off-by: Jan Beulich 
> >>
> >> Tamas? (The minor fix needed to address Andrew's reply doesn't seem
> >> to warrant sending out a v2.)
> > 
> > 
> >> > ---
> >> > Note that likely there's more work needed subsequently: The grant isn't
> >> > being marked in use for the duration of the use of the GFN. But I'll
> >> > leave that to someone actually knowing how to properly to test this.
> >>
> >>
> > Hi Jan,
> > unfortunately I don't have a good way to test this either as I never used
> > memsharing with grefs before. The above comment about the grant not being
> > marked for in-use makes me wonder whether this is a regression from this
> > patch or whether that just was never the case.
> 
> This was never the case. I wouldn't dare to submit a patch
> knowingly breaking something.
> 
> > Either way, I can see this
> > being an issue only if memory is being removed by hot-plugging, which AFAIK
> > is not a supported scenario anyway. The rest of the patch is fairly
> > mechanical, so:
> > 
> > Acked-by: Tamas K Lengyel 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [RFC PATCH 0/7] Implement Xen PV-IOMMU interface

[Martin Cerveny]

Hello.

Any update on this ?

Thanks, Martin Cerveny

On Wed, 10 Feb 2016, Malcolm Crossley wrote:


This RFC series implements the PV-IOMMU interface according to the PV-IOMMU
design draft D.

The PV-IOMMU interface is currently restricted to being used by the hardware
domain only as non hardware domain callers have not been fully tested yet.

Significant effort was put into implementing a m2b tracking structure without
increasing the size of struct page but no union was found that could be safely
used in all cases when a page is allocated to an HVM domain. Comments and
feedback on the m2b design are most welcome.

The hardware domain specific IOMMU pre map mechanism was implemented in order
to keep performance parity with current out of tree mechanisms to obtain BFNs
for foreign guest owned memory. The pre map mechanism is not a weakening of
the current security model of Xen and is only allowed when the hardware domain
is allowed relaxed IOMMU mappings.


Malcolm Crossley (7):
 common/pv-iommu: Add stub hypercall for PV-IOMMU
 iommu: add iommu_lookup_page to lookup guest gfn for a particular
   IOMMU mapping
 VT-d: Add iommu_lookup_page support
 common/pv-iommu: Add query, map and unmap ops
 x86/m2b: Add a tracking structure for mfn to bfn mappings per page
 common/pv-iommu: Add foreign ops to PV-IOMMU interface
 common/pv-iommu: Allow hardware_domain to pre IOMMU map foreign
   memory

xen/arch/x86/domain.c   |  12 +-
xen/arch/x86/mm/Makefile|   1 +
xen/arch/x86/mm/m2b.c   | 211 
xen/arch/x86/x86_64/compat/entry.S  |   2 +
xen/arch/x86/x86_64/entry.S |   2 +
xen/common/Makefile |   1 +
xen/common/memory.c |  11 +
xen/common/pv_iommu.c   | 633 
xen/drivers/passthrough/iommu.c |  21 ++
xen/drivers/passthrough/vtd/iommu.c |  31 ++
xen/drivers/passthrough/vtd/iommu.h |   1 +
xen/include/asm-x86/domain.h|   1 +
xen/include/asm-x86/m2b.h   |  65 
xen/include/asm-x86/mm.h|  12 +-
xen/include/public/hvm/ioreq.h  |   1 +
xen/include/public/pv-iommu.h   |  93 ++
xen/include/public/xen.h|   1 +
xen/include/xen/iommu.h |   2 +
xen/include/xen/sched.h |   4 +
xen/include/xsm/dummy.h |   6 +
xen/include/xsm/xsm.h   |   6 +
xen/xsm/dummy.c |   1 +
22 files changed, 1116 insertions(+), 2 deletions(-)
create mode 100644 xen/arch/x86/mm/m2b.c
create mode 100644 xen/common/pv_iommu.c
create mode 100644 xen/include/asm-x86/m2b.h
create mode 100644 xen/include/public/pv-iommu.h

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



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

Re: [Xen-devel] Low-hanging fruit bugs for starting contributor

[Lars Kurth]

Elazar,

we do have a list of links to starter projects at the bottom of 
https://wiki.xenproject.org/wiki/Outreachy/Round12%2B2016GSoC 
, but these are 
probably not quite what you are looking for. We don't maintain a list of 
starter bugs, because much of it depends on what you want to get out of it. I 
am assuming you solved build, set-up, etc. already?

If you could give us a bit of context and what you are trying to accomplish, I 
can CC a community member who can then point you in the right direction or 
alternatively can come up with a small project that can help you get up to 
speed.

Regards
Lars


> On 22 Nov 2016, at 15:49, Elazar Leibovich 
>  wrote:
> 
> Hi,
> For someone wishing to start contributing to  Xen hypervisor, what would you 
> recommend as an easy, educational, bug he could start with?
> 
> Thanks,
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] Low-hanging fruit bugs for starting contributor

[Konrad Rzeszutek Wilk]

On Tue, Nov 22, 2016 at 03:49:01PM +, Elazar Leibovich wrote:
> Hi,
> For someone wishing to start contributing to  Xen hypervisor, what would
> you recommend as an easy, educational, bug he could start with?

Port 'hptool' functionality to bring down physical CPUs up and down
to libxl.


> 
> Thanks,

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


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

Re: [Xen-devel] Ping: [PATCH] x86/memshr: properly check grant references

[Jan Beulich]

>>> On 22.11.16 at 17:13,  wrote:
> On Tue, Nov 22, 2016 at 3:12 AM, Jan Beulich  wrote:
> 
>> >>> On 14.11.16 at 11:34,  wrote:
>> > They need to be range checked against the current table limit in any
>> > event.
>> >
>> > Reported-by: Huawei PSIRT 
>> >
>> > Move the code to where it belongs, eliminating a number of duplicate
>> > definitions. Add locking. Produce proper error codes, and consume them
>> > instead of making one up. Check grant type. Convert parameter types at
>> > once.
>> >
>> > Signed-off-by: Jan Beulich 
>>
>> Tamas? (The minor fix needed to address Andrew's reply doesn't seem
>> to warrant sending out a v2.)
> 
> 
>> > ---
>> > Note that likely there's more work needed subsequently: The grant isn't
>> > being marked in use for the duration of the use of the GFN. But I'll
>> > leave that to someone actually knowing how to properly to test this.
>>
>>
> Hi Jan,
> unfortunately I don't have a good way to test this either as I never used
> memsharing with grefs before. The above comment about the grant not being
> marked for in-use makes me wonder whether this is a regression from this
> patch or whether that just was never the case.

This was never the case. I wouldn't dare to submit a patch
knowingly breaking something.

> Either way, I can see this
> being an issue only if memory is being removed by hot-plugging, which AFAIK
> is not a supported scenario anyway. The rest of the patch is fairly
> mechanical, so:
> 
> Acked-by: Tamas K Lengyel 

Thanks.

Jan


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

Re: [Xen-devel] [PATCH v3 02/11] acpi: Define ACPI IO registers for PVH guests

[Jan Beulich]

>>> On 22.11.16 at 16:52,  wrote:

> 
> On 11/22/2016 10:13 AM, Jan Beulich wrote:
> On 22.11.16 at 15:53,  wrote:
>>
>>>
>>> On 11/22/2016 09:07 AM, Jan Beulich wrote:
>>> On 22.11.16 at 13:28,  wrote:

>
> On 11/22/2016 05:37 AM, Jan Beulich wrote:
> On 21.11.16 at 22:00,  wrote:
>>> @@ -119,11 +122,33 @@ typedef struct buffered_iopage buffered_iopage_t;
>>>
>>>  /* Compatibility definitions for the default location (version 0). */
>>>  #define ACPI_PM1A_EVT_BLK_ADDRESSACPI_PM1A_EVT_BLK_ADDRESS_V0
>>> +#define ACPI_PM1A_EVT_BLK_LEN0x04
>>> +#define ACPI_PM1A_EVT_BLK_BIT_OFFSET 0x00
>>>  #define ACPI_PM1A_CNT_BLK_ADDRESSACPI_PM1A_CNT_BLK_ADDRESS_V0
>>> +#define ACPI_PM1A_CNT_BLK_LEN0x02
>>> +#define ACPI_PM1A_CNT_BLK_BIT_OFFSET 0x00
>>>  #define ACPI_PM_TMR_BLK_ADDRESS  ACPI_PM_TMR_BLK_ADDRESS_V0
>>> +#define ACPI_PM_TMR_BLK_LEN  0x04
>>> +#define ACPI_PM_TMR_BLK_BIT_OFFSET   0x00
>>>  #define ACPI_GPE0_BLK_ADDRESSACPI_GPE0_BLK_ADDRESS_V0
>>>  #define ACPI_GPE0_BLK_LENACPI_GPE0_BLK_LEN_V0
>>>
>>> +#if __XEN_INTERFACE_VERSION__ >= 0x00040800
>>> +#if defined(__XEN__) || defined(__XEN_TOOLS__)
>>> +
>>> +/* Location of online VCPU bitmap. */
>>> +#define XEN_ACPI_CPU_MAP 0xaf00
>>> +#define XEN_ACPI_CPU_MAP_LEN ((HVM_MAX_VCPUS + 7) / 8)
>>> +
>>> +#if XEN_ACPI_CPU_MAP + XEN_ACPI_CPU_MAP_LEN >= ACPI_GPE0_BLK_ADDRESS_V1
>>> +#error "XEN_ACPI_CPU_MAP is too big"
>>> +#endif
>>> +
>>> +/* GPE0 bit set during CPU hotplug */
>>> +#define XEN_GPE0_CPUHP_BIT   2
>>> +
>>> +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
>>> +#endif /* __XEN_INTERFACE_VERSION__ >= 0x00040800 */
>>>
>>>  #endif /* _IOREQ_H_ */
>>
>> I'm afraid there's been some misunderstanding here during the v2
>> discussion: New hypervisor/tools only definitions don't need an
>> additional interface version guard. It's instead the pre-existing
>> ones which should be removed from the namespace by adding
>> such a guard.
>
> We want to keep all of them now. Shouldn't then the interface check be
> added after we move to Andrew's suggestion of dynamic IO ranges?

 No, we want them gone from the public interface for new
 consumers. The only valid consumer has always been the tool
 stack, just that this hadn't been properly done in the header.
 Hence the need to add __XEN__ / __XEN_TOOLS__ around new
 additions, and additionally interface version guards around
 existing ones.
>>>
>>> pmtimer.c uses some of those macros so how will wrapping interface
>>> version check around existing definitions continue to work when
>>> interface version is updated, unless dynamic IO ranges are also added by
>>> that time?
>>
>> The question makes me suspect you still don't understand how things
>> should look like. I'll try to sketch this out in a simplified manner:
>>
>> #if defined(__XEN__) || defined(__XEN_TOOLS__) || interface-version < 4.9
>> existing #define-s
>> #endif
>>
>> #if defined(__XEN__) || defined(__XEN_TOOLS__)
>> new #define-s
>> #endif
> 
> OK, now I understand what you want.
> 
> Unfortunately, I still don't understand why, until IO range reservation 
> is implemented. Sorry for being obtuse.

The "why" is the same as for everything else we want to hide from
the general public, but make available to tools: Be able to modify
it without going through versioning hoops.

Jan


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

Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

[Olaf Hering]

On Fri, Nov 18, Eric Blake wrote:

> if (sec_start > (INT64_MAX >> BDRV_SECTOR_BITS) - sec_count)

I have looked at this for a while now and cant spot how this would cover
all cases. Are you saying there should be just a single overflow check,
yours? My change has two: one to check for wrap around and to check
against the upper limit. My check happens to work with 0/UINT64_MAX or
INT64_MAX/INT64_MAX as input, yours appearently not.
Obviously I'm missing something essential.

Olaf


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

Re: [Xen-devel] [PATCH v3 09/11] events/x86: Define SCI virtual interrupt

[Jan Beulich]

>>> On 22.11.16 at 16:57,  wrote:
> On 11/22/2016 10:25 AM, Jan Beulich wrote:
> On 21.11.16 at 22:00,  wrote:
>>> PVH guests do not have IOAPIC which typically generates an SCI. For
>>> those guests SCI will be provided as a virtual interrupt.
>>>
>>> We also move VIRQ_MCA definition out of xen-mca.h to
>>> keep all x86-specific VIRQ_ARCH_* in one place.
>>
>> While I appreciate the idea, you can't: xen-mca.h doesn't include
>> xen.h, and hence parties consuming xen-mca.h alone may then see
>> their build broken.
> 
> Right.
> 
> Any reason we can't include "xen.h" here?

I'm personally of the opinion that we shouldn't force unnecessary
header dependencies onto every consumer. But maybe everone
else disagrees ...

Jan


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

Re: [Xen-devel] [PATCH v3 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

[Jan Beulich]

>>> On 22.11.16 at 16:30,  wrote:
> On 11/22/2016 10:01 AM, Jan Beulich wrote:
>>
>>> +const static uint8_t pm1a_mask[4] = {ACPI_BITMASK_GLOBAL_LOCK_STATUS, 
> 0,
>>> + ACPI_BITMASK_GLOBAL_LOCK_ENABLE, 
> 0};
>>> +const static uint8_t gpe0_mask[4] = {1U << XEN_GPE0_CPUHP_BIT, 0,
>>> + 1U << XEN_GPE0_CPUHP_BIT, 0};
>>
>> Hmm, funny, in someone else's patch I've recently seen the same.
>> Can we please stick to the more standard "storage type first"
>> ordering of declaration elements. After all const modifies the type,
>> and hence better stays together with it.
>>
>> And then I'd like to have an explanation (in the commit message)
>> about the choice of the values for pm1a_mask.
> 
> Sure (Lock status/enable is required)

And nothing else is? And there's no other implementation
required for the lock bit?

>> Plus you using
>> uint8_t here is at least odd, considering that this is about registers
>> consisting of two 16-bit halves. I'm not even certain the spec
>> permits these to be accessed with other than the specified
>> granularity.
> 
> 
> GPE registers can be 1-byte long. And, in fact, that's how ACPICA 
> accesses it.
> 
> PM1 is indeed 2-byte long. I can make a check in the switch statement 
> but I think I should leave the IOREQ_WRITE handling (at the bottom of 
> this message) as it is for simplicity.
> 
> 
>> Or wait - the literal 4-s here look bad too. Perhaps the two should
>> be combined into a variable of type
>> typeof(currd->arch.hvm_domain.acpi_io), so values and masks
>> really match up. Which would still seem to make it desirable for the
>> parts to be of type uint16_t, if permitted by the spec.
> 
> But I then assign these masks to uint8_t mask. Wouldn't it be better to 
> explicitly keep those as byte-size values? Especially given how they are 
> used in IOREQ_WRITE case (below).

Well, maybe, namely considering that the GPE and PM1a parts
would otherwise end up different, further complicating the code.

Jan


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

Re: [Xen-devel] [PATCH v3 02/11] acpi: Define ACPI IO registers for PVH guests

[Boris Ostrovsky]

On 11/22/2016 10:13 AM, Jan Beulich wrote:

On 22.11.16 at 15:53,  wrote:




On 11/22/2016 09:07 AM, Jan Beulich wrote:

On 22.11.16 at 13:28,  wrote:




On 11/22/2016 05:37 AM, Jan Beulich wrote:

On 21.11.16 at 22:00,  wrote:

@@ -119,11 +122,33 @@ typedef struct buffered_iopage buffered_iopage_t;

 /* Compatibility definitions for the default location (version 0). */
 #define ACPI_PM1A_EVT_BLK_ADDRESSACPI_PM1A_EVT_BLK_ADDRESS_V0
+#define ACPI_PM1A_EVT_BLK_LEN0x04
+#define ACPI_PM1A_EVT_BLK_BIT_OFFSET 0x00
 #define ACPI_PM1A_CNT_BLK_ADDRESSACPI_PM1A_CNT_BLK_ADDRESS_V0
+#define ACPI_PM1A_CNT_BLK_LEN0x02
+#define ACPI_PM1A_CNT_BLK_BIT_OFFSET 0x00
 #define ACPI_PM_TMR_BLK_ADDRESS  ACPI_PM_TMR_BLK_ADDRESS_V0
+#define ACPI_PM_TMR_BLK_LEN  0x04
+#define ACPI_PM_TMR_BLK_BIT_OFFSET   0x00
 #define ACPI_GPE0_BLK_ADDRESSACPI_GPE0_BLK_ADDRESS_V0
 #define ACPI_GPE0_BLK_LENACPI_GPE0_BLK_LEN_V0

+#if __XEN_INTERFACE_VERSION__ >= 0x00040800
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+/* Location of online VCPU bitmap. */
+#define XEN_ACPI_CPU_MAP 0xaf00
+#define XEN_ACPI_CPU_MAP_LEN ((HVM_MAX_VCPUS + 7) / 8)
+
+#if XEN_ACPI_CPU_MAP + XEN_ACPI_CPU_MAP_LEN >= ACPI_GPE0_BLK_ADDRESS_V1
+#error "XEN_ACPI_CPU_MAP is too big"
+#endif
+
+/* GPE0 bit set during CPU hotplug */
+#define XEN_GPE0_CPUHP_BIT   2
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+#endif /* __XEN_INTERFACE_VERSION__ >= 0x00040800 */

 #endif /* _IOREQ_H_ */


I'm afraid there's been some misunderstanding here during the v2
discussion: New hypervisor/tools only definitions don't need an
additional interface version guard. It's instead the pre-existing
ones which should be removed from the namespace by adding
such a guard.


We want to keep all of them now. Shouldn't then the interface check be
added after we move to Andrew's suggestion of dynamic IO ranges?


No, we want them gone from the public interface for new
consumers. The only valid consumer has always been the tool
stack, just that this hadn't been properly done in the header.
Hence the need to add __XEN__ / __XEN_TOOLS__ around new
additions, and additionally interface version guards around
existing ones.


pmtimer.c uses some of those macros so how will wrapping interface
version check around existing definitions continue to work when
interface version is updated, unless dynamic IO ranges are also added by
that time?


The question makes me suspect you still don't understand how things
should look like. I'll try to sketch this out in a simplified manner:

#if defined(__XEN__) || defined(__XEN_TOOLS__) || interface-version < 4.9
existing #define-s
#endif

#if defined(__XEN__) || defined(__XEN_TOOLS__)
new #define-s
#endif


OK, now I understand what you want.

Unfortunately, I still don't understand why, until IO range reservation 
is implemented. Sorry for being obtuse.






And of course _everything_ being added here anew needs to be
XEN_ prefixed and guarded.



The ones that I didn't add the prefix to are the standard ACPI names. If
I did this would look like

#define ACPI_PM_TMR_BLK_ADDRESS  ACPI_PM_TMR_BLK_ADDRESS_V0
+#define XEN_ACPI_PM_TMR_BLK_LEN  0x04
+#define XEN_ACPI_PM_TMR_BLK_BIT_OFFSET   0x00


There's nothing standard here. Implementations are fine to specify
a larger length iirc, at least for ACPI v2 and newer. If these values
were all fixed, there wouldn't have been a need to specify them in
FADT in the first place.


I meant that, unlike XEN_ACPI_CPU_MAP that I added, these blocks are
ACPI-standard, not macros' values.

Are you asking to rename just the newly introduced definitions
(lengths/offsets) or existing address macros as well? Doing the latter
will also require changes to at least pmtimer.c


Just the new ones - for backwards compatibility we can't rename
the existing ones. But then, considering they go inside XEN/tools
#ifdef-s, perhaps we don't even need to XEN_-prefix them. I hadn't
considered this aspect before, sorry.


Then I'd rather keep the names the way they are in this series.

-boris

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

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Jan Beulich]

>>> On 22.11.16 at 16:43,  wrote:

> 
> On 11/22/2016 10:07 AM, Jan Beulich wrote:
> On 22.11.16 at 15:37,  wrote:
>>
>>>
>>> On 11/22/2016 08:59 AM, Jan Beulich wrote:
>>> On 22.11.16 at 13:34,  wrote:

>
> On 11/22/2016 05:39 AM, Jan Beulich wrote:
> On 22.11.16 at 11:31,  wrote:
>> On 21.11.16 at 22:00,  wrote:
 This domctl is called when a VCPU is hot-(un)plugged to a guest (via
 'xl vcpu-set').

 The primary reason for adding this call is because for PVH guests
 the hypervisor needs to send an SCI and set GPE registers. This is
 unlike HVM guests that have qemu to perform these tasks.
>>>
>>> And the tool stack can't do this?
>>
>> For the avoidance of further misunderstandings: Of course likely
>> not completely on its own, but by using a (to be introduced) more
>> low level hypervisor interface (setting arbitrary GPE bits, with SCI
>> raised as needed, or the SCI raising being another hypercall).
>
> So you are suggesting breaking up XEN_DOMCTL_set_avail_vcpus into
>
> XEN_DOMCTL_set_acpi_reg(io_offset, length, val)
> XEN_DOMCTL_set_avail_vcpus(avail_vcpus_bitmap)
> XEN_DOMCTL_send_virq(virq)
>
> (with perhaps set_avail_vcpus folded into set_acpi_reg) ?

 Well, I don't see what set_avail_vcpus would be good for
 considering that during v2 review you've said that you need it
 just for the GPE modification and SCI sending.
>>>
>>>
>>> Someone needs to provide the hypervisor with the new number of available
>>> (i.e. hot-plugged/unplugged) VCPUs, thus the name of the domctl. GPE/SCI
>>> manipulation are part of that update.
>>>
>>> (I didn't say it during v2 review and I should have)
>>
>> And I've just found that need while looking over patch 8. With
>> that I'm not sure the splitting would make sense, albeit we may
>> find it necessary to fiddle with other GPE bits down the road.
> 
> Just to make sure we are talking about the same thing: 
> XEN_DOMCTL_set_acpi_reg is sufficient for both GPE and CPU map (or any 
> ACPI register should the need arise)

Well, my point is that as long as we continue to need
set_avail_vcpus (which I hear you say we do need), I'm not
sure the splitting would be helpful (minus the "albeit" part
above).

Jan


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

Re: [Xen-devel] [PATCH-for-4.9 v1 1/8] public / x86: Introduce __HYPERCALL_dm_op...

[Jan Beulich]

>>> On 18.11.16 at 18:13,  wrote:
> This patch simply adds the boilerplate for the hypercall and bumps
> __XEN_LATEST_INTERFACE_VERSION__ to 0x040900.

Why the latter?

> +static int dm_op_get_buf(XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs,
> + unsigned int nr_bufs, unsigned int idx,
> + struct xen_dm_op_buf *buf)
> +{
> +if ( idx >= nr_bufs )
> +return -EFAULT;

There's no fault here. ENOENT, EIO, ENXIO, ...?

> +return copy_from_guest_offset(buf, bufs, idx, 1);
> +}
> +
> +static int 
> dm_op_copy_buf_from_guest(XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs,
> + unsigned int nr_bufs, void *dst,
> + unsigned int idx, size_t dst_size)
> +{
> +struct xen_dm_op_buf buf;
> +size_t size;
> +int rc;
> +
> +memset(dst, 0, dst_size);
> +
> +rc = dm_op_get_buf(bufs, nr_bufs, idx, );
> +if ( rc )
> +return -EFAULT;
> +
> +size = min(dst_size, buf.size);

Hmm, the file is x86-specific, so this may indeed build. But formally
the two expressions are of different types, which min() doesn't like.

> +static int dm_op_copy_buf_to_guest(XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) 
> bufs,
> +   unsigned int nr_bufs, unsigned int idx,
> +   void *src, size_t src_size)
> +{
> +struct xen_dm_op_buf buf;
> +size_t size;
> +int rc;
> +
> +rc = dm_op_get_buf(bufs, nr_bufs, idx, );
> +if ( rc )
> +return -EFAULT;
> +
> +size = min(buf.size, src_size);
> +
> +rc = copy_to_guest(buf.h, src, size);
> +if ( rc )
> +return -EFAULT;
> +
> +return 0;
> +}

For copying from guest doing all-or-nothing is probably sufficient,
but is that really the case also for copying data back?

> +long do_dm_op(domid_t domid,
> +  unsigned int nr_bufs,
> +  XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs)
> +{
> +struct domain *d;
> +struct xen_dm_op op;
> +bool restart;
> +long rc;
> +
> +rc = rcu_lock_remote_domain_by_id(domid, );
> +if ( rc )
> +return rc;
> +
> +restart = false;
> +
> +if ( !has_hvm_container_domain(d) )
> +goto out;
> +
> +rc = xsm_dm_op(XSM_DM_PRIV, d);
> +if ( rc )
> +goto out;
> +
> +rc = dm_op_copy_buf_from_guest(bufs, nr_bufs, , 0, sizeof(op));
> +if ( rc )
> +goto out;
> +
> +switch ( op.op )
> +{
> +default:
> +rc = -EOPNOTSUPP;
> +break;
> +}
> +
> +if ( rc == -ERESTART )
> +restart = true;
> +
> +if ( !restart && rc )

Is the "restart" variable really necessary?

> +goto out;
> +
> +rc = dm_op_copy_buf_to_guest(bufs, nr_bufs, 0, , sizeof(op));
> +
> +out:

A goto over a single statement is certainly too much goto-ery for
my taste. In any event - labels indented by at least one space
please.

> +#ifndef __XEN_PUBLIC_HVM_DM_OP_H__
> +#define __XEN_PUBLIC_HVM_DM_OP_H__
> +
> +#if defined(__XEN__) || defined(__XEN_TOOLS__)
> +
> +#include "../xen.h"
> +
> +#define DMOP_invalid 0

XEN_DMOP_invalid

> +struct xen_dm_op {
> +uint32_t op;
> +};
> +
> +struct xen_dm_op_buf {
> +XEN_GUEST_HANDLE(void) h;
> +uint64_t size;
> +};
> +typedef struct xen_dm_op_buf xen_dm_op_buf_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_dm_op_buf_t);
> +
> +/* ` enum neg_errnoval
> + * ` HYPERVISOR_dm_op(domid_t domid,
> + * `  xen_dm_op_buf_t *bufs,

I'd prefer you to use the bufs[] notation here, to emphasize the
array nature.

> + * `  unsigned int nr_bufs)
> + * `
> + *
> + * @domid is the domain the hypercall operates on.
> + * @bufs points to an array of buffers where @bufs[0] contains a struct
> + * dm_op, describing the specific device model operation and its parameters.

xen_dm_op

> + * @bufs[1..] may be referenced in the parameters for the purposes of
> + * passing extra information to or from the domain.
> + * @nr_bufs is the number of buffers in the @bufs array.
> + */
> +
> +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */

Please omit the two defined() (but retain what's inside the
parentheses).


> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -727,6 +727,12 @@ static XSM_INLINE int xsm_pmu_op (XSM_DEFAULT_ARG struct 
> domain *d, unsigned int
>  }
>  }
>  
> +static XSM_INLINE int xsm_dm_op (XSM_DEFAULT_ARG struct domain *d)

Stray blank (many of the XSM routines have this wrong, and this
really should be cleaned up eventually).

Jan

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

Re: [Xen-devel] [PATCH v3 09/11] events/x86: Define SCI virtual interrupt

[Boris Ostrovsky]

On 11/22/2016 10:25 AM, Jan Beulich wrote:

On 21.11.16 at 22:00,  wrote:

PVH guests do not have IOAPIC which typically generates an SCI. For
those guests SCI will be provided as a virtual interrupt.

We also move VIRQ_MCA definition out of xen-mca.h to
keep all x86-specific VIRQ_ARCH_* in one place.


While I appreciate the idea, you can't: xen-mca.h doesn't include
xen.h, and hence parties consuming xen-mca.h alone may then see
their build broken.


Right.

Any reason we can't include "xen.h" here?

-boris

Considering that duplicate identical #define-s are

fine, I think there's no way around ...


--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -91,8 +91,6 @@

 #ifndef __ASSEMBLY__

-#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */


.. keeping this, while perhaps still ...


--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -295,6 +295,9 @@ struct xen_arch_domainconfig {
 };
 #endif

+#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
+#define VIRQ_SCI VIRQ_ARCH_1 /* G. (PVH) ACPI interrupt */


... adding both here.

Jan



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

[Xen-devel] Low-hanging fruit bugs for starting contributor

[Elazar Leibovich]

Hi,
For someone wishing to start contributing to  Xen hypervisor, what would
you recommend as an easy, educational, bug he could start with?

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

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Boris Ostrovsky]

On 11/22/2016 10:07 AM, Jan Beulich wrote:

On 22.11.16 at 15:37,  wrote:




On 11/22/2016 08:59 AM, Jan Beulich wrote:

On 22.11.16 at 13:34,  wrote:




On 11/22/2016 05:39 AM, Jan Beulich wrote:

On 22.11.16 at 11:31,  wrote:

On 21.11.16 at 22:00,  wrote:

This domctl is called when a VCPU is hot-(un)plugged to a guest (via
'xl vcpu-set').

The primary reason for adding this call is because for PVH guests
the hypervisor needs to send an SCI and set GPE registers. This is
unlike HVM guests that have qemu to perform these tasks.


And the tool stack can't do this?


For the avoidance of further misunderstandings: Of course likely
not completely on its own, but by using a (to be introduced) more
low level hypervisor interface (setting arbitrary GPE bits, with SCI
raised as needed, or the SCI raising being another hypercall).


So you are suggesting breaking up XEN_DOMCTL_set_avail_vcpus into

XEN_DOMCTL_set_acpi_reg(io_offset, length, val)
XEN_DOMCTL_set_avail_vcpus(avail_vcpus_bitmap)
XEN_DOMCTL_send_virq(virq)

(with perhaps set_avail_vcpus folded into set_acpi_reg) ?


Well, I don't see what set_avail_vcpus would be good for
considering that during v2 review you've said that you need it
just for the GPE modification and SCI sending.



Someone needs to provide the hypervisor with the new number of available
(i.e. hot-plugged/unplugged) VCPUs, thus the name of the domctl. GPE/SCI
manipulation are part of that update.

(I didn't say it during v2 review and I should have)


And I've just found that need while looking over patch 8. With
that I'm not sure the splitting would make sense, albeit we may
find it necessary to fiddle with other GPE bits down the road.


Just to make sure we are talking about the same thing: 
XEN_DOMCTL_set_acpi_reg is sufficient for both GPE and CPU map (or any 
ACPI register should the need arise)


-boris

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

Re: [Xen-devel] [PATCH v3 10/11] pvh: Send an SCI on VCPU hotplug event

[Jan Beulich]

>>> On 21.11.16 at 22:00,  wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -509,6 +509,22 @@ void vcpu_destroy(struct vcpu *v)
>  xfree(v->arch.pv_vcpu.trap_ctxt);
>  }
>  
> +int arch_update_avail_vcpus(struct domain *d)

I don't see a way for failure here, so perhaps the function could
return void for now?

> +{
> +/*
> + * For PVH guests we need to send an SCI and set enable/status
> + * bits in GPE block.
> + */
> +if ( is_hvm_domain(d) && !has_acpi_ff(d) )
> +{
> +d->arch.hvm_domain.acpi_io.gpe[2] =
> +d->arch.hvm_domain.acpi_io.gpe[0] = 1 << XEN_GPE0_CPUHP_BIT;

Literal array indexes. I think you want them to be calculated from
XEN_GPE0_CPUHP_BIT (which btw than also applies to the static
mask variable in the other patch).

> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -23,6 +23,14 @@
>  void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq);
>  
>  /*
> + * send_guest_global_virq: Notify guest via a global VIRQ.
> + *  @d:domain to which virtual IRQ should be sent. First
> + * online VCPU will be selected.
> + *  @virq: Virtual IRQ number (VIRQ_*)
> + */
> +void send_guest_global_virq(struct domain *d, uint32_t virq);

Please take the opportunity and switch away for the pointless
use of a fixed width type here - unsigned int will be just fine.

Jan


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

Re: [Xen-devel] [PATCH v3 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

[Boris Ostrovsky]

On 11/22/2016 10:01 AM, Jan Beulich wrote:




+const static uint8_t pm1a_mask[4] = {ACPI_BITMASK_GLOBAL_LOCK_STATUS, 0,
+ ACPI_BITMASK_GLOBAL_LOCK_ENABLE, 0};
+const static uint8_t gpe0_mask[4] = {1U << XEN_GPE0_CPUHP_BIT, 0,
+ 1U << XEN_GPE0_CPUHP_BIT, 0};


Hmm, funny, in someone else's patch I've recently seen the same.
Can we please stick to the more standard "storage type first"
ordering of declaration elements. After all const modifies the type,
and hence better stays together with it.

And then I'd like to have an explanation (in the commit message)
about the choice of the values for pm1a_mask.


Sure (Lock status/enable is required)



Plus you using
uint8_t here is at least odd, considering that this is about registers
consisting of two 16-bit halves. I'm not even certain the spec
permits these to be accessed with other than the specified
granularity.



GPE registers can be 1-byte long. And, in fact, that's how ACPICA 
accesses it.


PM1 is indeed 2-byte long. I can make a check in the switch statement 
but I think I should leave the IOREQ_WRITE handling (at the bottom of 
this message) as it is for simplicity.





Or wait - the literal 4-s here look bad too. Perhaps the two should
be combined into a variable of type
typeof(currd->arch.hvm_domain.acpi_io), so values and masks
really match up. Which would still seem to make it desirable for the
parts to be of type uint16_t, if permitted by the spec.


But I then assign these masks to uint8_t mask. Wouldn't it be better to 
explicitly keep those as byte-size values? Especially given how they are 
used in IOREQ_WRITE case (below).




+else
+{
+unsigned int idx = port & 3;
+unsigned int i;
+uint8_t *ptr;


const


+if ( is_cpu_map )
+/*
+ * CPU map is only read by DSDT's PRSC method and should never
+ * be written by a guest.
+ */
+return X86EMUL_UNHANDLEABLE;
+
+ptr = (uint8_t *)val;
+for ( i = 0; i < bytes; i++, idx++ )
+{
+if ( idx < 2 ) /* status, write 1 to clear. */
+reg[idx] &= ~(mask[i] & ptr[i]);
+else   /* enable */
+reg[idx] |= (mask[i] & ptr[i]);


Don't you mean mask[idx] in both cases?


Oh, right, of course.

-boris

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

Re: [Xen-devel] [PATCH v3 09/11] events/x86: Define SCI virtual interrupt

[Jan Beulich]

>>> On 21.11.16 at 22:00,  wrote:
> PVH guests do not have IOAPIC which typically generates an SCI. For
> those guests SCI will be provided as a virtual interrupt.
> 
> We also move VIRQ_MCA definition out of xen-mca.h to
> keep all x86-specific VIRQ_ARCH_* in one place.

While I appreciate the idea, you can't: xen-mca.h doesn't include
xen.h, and hence parties consuming xen-mca.h alone may then see
their build broken. Considering that duplicate identical #define-s are
fine, I think there's no way around ...

> --- a/xen/include/public/arch-x86/xen-mca.h
> +++ b/xen/include/public/arch-x86/xen-mca.h
> @@ -91,8 +91,6 @@
>  
>  #ifndef __ASSEMBLY__
>  
> -#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */

.. keeping this, while perhaps still ...

> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -295,6 +295,9 @@ struct xen_arch_domainconfig {
>  };
>  #endif
>  
> +#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
> +#define VIRQ_SCI VIRQ_ARCH_1 /* G. (PVH) ACPI interrupt */

... adding both here.

Jan


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

Re: [Xen-devel] [PATCH v3 02/11] acpi: Define ACPI IO registers for PVH guests

[Jan Beulich]

>>> On 22.11.16 at 15:53,  wrote:

> 
> On 11/22/2016 09:07 AM, Jan Beulich wrote:
> On 22.11.16 at 13:28,  wrote:
>>
>>>
>>> On 11/22/2016 05:37 AM, Jan Beulich wrote:
>>> On 21.11.16 at 22:00,  wrote:
> @@ -119,11 +122,33 @@ typedef struct buffered_iopage buffered_iopage_t;
>
>  /* Compatibility definitions for the default location (version 0). */
>  #define ACPI_PM1A_EVT_BLK_ADDRESSACPI_PM1A_EVT_BLK_ADDRESS_V0
> +#define ACPI_PM1A_EVT_BLK_LEN0x04
> +#define ACPI_PM1A_EVT_BLK_BIT_OFFSET 0x00
>  #define ACPI_PM1A_CNT_BLK_ADDRESSACPI_PM1A_CNT_BLK_ADDRESS_V0
> +#define ACPI_PM1A_CNT_BLK_LEN0x02
> +#define ACPI_PM1A_CNT_BLK_BIT_OFFSET 0x00
>  #define ACPI_PM_TMR_BLK_ADDRESS  ACPI_PM_TMR_BLK_ADDRESS_V0
> +#define ACPI_PM_TMR_BLK_LEN  0x04
> +#define ACPI_PM_TMR_BLK_BIT_OFFSET   0x00
>  #define ACPI_GPE0_BLK_ADDRESSACPI_GPE0_BLK_ADDRESS_V0
>  #define ACPI_GPE0_BLK_LENACPI_GPE0_BLK_LEN_V0
>
> +#if __XEN_INTERFACE_VERSION__ >= 0x00040800
> +#if defined(__XEN__) || defined(__XEN_TOOLS__)
> +
> +/* Location of online VCPU bitmap. */
> +#define XEN_ACPI_CPU_MAP 0xaf00
> +#define XEN_ACPI_CPU_MAP_LEN ((HVM_MAX_VCPUS + 7) / 8)
> +
> +#if XEN_ACPI_CPU_MAP + XEN_ACPI_CPU_MAP_LEN >= ACPI_GPE0_BLK_ADDRESS_V1
> +#error "XEN_ACPI_CPU_MAP is too big"
> +#endif
> +
> +/* GPE0 bit set during CPU hotplug */
> +#define XEN_GPE0_CPUHP_BIT   2
> +
> +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
> +#endif /* __XEN_INTERFACE_VERSION__ >= 0x00040800 */
>
>  #endif /* _IOREQ_H_ */

 I'm afraid there's been some misunderstanding here during the v2
 discussion: New hypervisor/tools only definitions don't need an
 additional interface version guard. It's instead the pre-existing
 ones which should be removed from the namespace by adding
 such a guard.
>>>
>>> We want to keep all of them now. Shouldn't then the interface check be
>>> added after we move to Andrew's suggestion of dynamic IO ranges?
>>
>> No, we want them gone from the public interface for new
>> consumers. The only valid consumer has always been the tool
>> stack, just that this hadn't been properly done in the header.
>> Hence the need to add __XEN__ / __XEN_TOOLS__ around new
>> additions, and additionally interface version guards around
>> existing ones.
> 
> pmtimer.c uses some of those macros so how will wrapping interface 
> version check around existing definitions continue to work when 
> interface version is updated, unless dynamic IO ranges are also added by 
> that time?

The question makes me suspect you still don't understand how things
should look like. I'll try to sketch this out in a simplified manner:

#if defined(__XEN__) || defined(__XEN_TOOLS__) || interface-version < 4.9
existing #define-s
#endif

#if defined(__XEN__) || defined(__XEN_TOOLS__)
new #define-s
#endif

 And of course _everything_ being added here anew needs to be
 XEN_ prefixed and guarded.
>>>
>>>
>>> The ones that I didn't add the prefix to are the standard ACPI names. If
>>> I did this would look like
>>>
>>> #define ACPI_PM_TMR_BLK_ADDRESS  ACPI_PM_TMR_BLK_ADDRESS_V0
>>> +#define XEN_ACPI_PM_TMR_BLK_LEN  0x04
>>> +#define XEN_ACPI_PM_TMR_BLK_BIT_OFFSET   0x00
>>
>> There's nothing standard here. Implementations are fine to specify
>> a larger length iirc, at least for ACPI v2 and newer. If these values
>> were all fixed, there wouldn't have been a need to specify them in
>> FADT in the first place.
> 
> I meant that, unlike XEN_ACPI_CPU_MAP that I added, these blocks are 
> ACPI-standard, not macros' values.
> 
> Are you asking to rename just the newly introduced definitions 
> (lengths/offsets) or existing address macros as well? Doing the latter 
> will also require changes to at least pmtimer.c

Just the new ones - for backwards compatibility we can't rename
the existing ones. But then, considering they go inside XEN/tools
#ifdef-s, perhaps we don't even need to XEN_-prefix them. I hadn't
considered this aspect before, sorry.

Jan

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

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Jan Beulich]

>>> On 22.11.16 at 15:37,  wrote:

> 
> On 11/22/2016 08:59 AM, Jan Beulich wrote:
> On 22.11.16 at 13:34,  wrote:
>>
>>>
>>> On 11/22/2016 05:39 AM, Jan Beulich wrote:
>>> On 22.11.16 at 11:31,  wrote:
 On 21.11.16 at 22:00,  wrote:
>> This domctl is called when a VCPU is hot-(un)plugged to a guest (via
>> 'xl vcpu-set').
>>
>> The primary reason for adding this call is because for PVH guests
>> the hypervisor needs to send an SCI and set GPE registers. This is
>> unlike HVM guests that have qemu to perform these tasks.
>
> And the tool stack can't do this?

 For the avoidance of further misunderstandings: Of course likely
 not completely on its own, but by using a (to be introduced) more
 low level hypervisor interface (setting arbitrary GPE bits, with SCI
 raised as needed, or the SCI raising being another hypercall).
>>>
>>> So you are suggesting breaking up XEN_DOMCTL_set_avail_vcpus into
>>>
>>> XEN_DOMCTL_set_acpi_reg(io_offset, length, val)
>>> XEN_DOMCTL_set_avail_vcpus(avail_vcpus_bitmap)
>>> XEN_DOMCTL_send_virq(virq)
>>>
>>> (with perhaps set_avail_vcpus folded into set_acpi_reg) ?
>>
>> Well, I don't see what set_avail_vcpus would be good for
>> considering that during v2 review you've said that you need it
>> just for the GPE modification and SCI sending.
> 
> 
> Someone needs to provide the hypervisor with the new number of available 
> (i.e. hot-plugged/unplugged) VCPUs, thus the name of the domctl. GPE/SCI 
> manipulation are part of that update.
> 
> (I didn't say it during v2 review and I should have)

And I've just found that need while looking over patch 8. With
that I'm not sure the splitting would make sense, albeit we may
find it necessary to fiddle with other GPE bits down the road.

Jan


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

[Xen-devel] [PATCH v2 1/4] Support for building in a Xen binary

[Andre Przywara]

From: Christoffer Dall 

Add support for building a Xen binary which includes a Dom0 image and
the Dom0 command-line.

If the user specifies --with-xen=, where Xen is an appropriate
AArch64 Xen binary, the build system will generate a xen-system.axf
instead of a linux-system.axf.

Original patch from Ian Campbell, but I modified most of it so all bugs
are probably mine.
[Andre: adapt to newest boot-wrapper branch, increase load address,
fixup Xen image file test]

Cc: Ian Campbell 
Signed-off-by: Christoffer Dall 
Signed-off-by: Andre Przywara 
---
 .gitignore|  1 +
 Makefile.am   | 10 +++---
 boot_common.c |  4 ++--
 configure.ac  | 17 +
 model.lds.S   | 14 ++
 5 files changed, 41 insertions(+), 5 deletions(-)

diff --git a/.gitignore b/.gitignore
index 8653852..80770c0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,6 +14,7 @@ configure
 dtc
 fdt.dtb
 Image
+Xen
 install-sh
 Makefile
 Makefile.in
diff --git a/Makefile.am b/Makefile.am
index 692d2cc..f8b9ec9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -85,7 +85,6 @@ TEXT_LIMIT:= 0x8008
 endif
 
 LD_SCRIPT  := model.lds.S
-IMAGE  := linux-system.axf
 
 FS_OFFSET  := 0x1000
 FILESYSTEM_START:= $(shell echo $$(($(PHYS_OFFSET) + $(FS_OFFSET
@@ -94,6 +93,11 @@ FILESYSTEM_END   := $(shell echo $$(($(FILESYSTEM_START) 
+ $(FILESYSTEM_SIZE
 
 FDT_OFFSET := 0x0800
 
+if XEN
+XEN:= -DXEN=$(XEN_IMAGE)
+XEN_OFFSET := 0x0820
+endif
+
 if INITRD
 INITRD_FLAGS   := -DUSE_INITRD
 CHOSEN_NODE:= chosen { \
@@ -121,7 +125,7 @@ all: $(IMAGE)
 
 CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
 
-$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM)
+$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) 
$(XEN_IMAGE)
$(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
 
 %.o: %.S Makefile
@@ -131,7 +135,7 @@ $(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) 
$(FILESYSTEM)
$(CC) $(CPPFLAGS) $(CFLAGS) $(DEFINES) -c -o $@ $<
 
 model.lds: $(LD_SCRIPT) Makefile
-   $(CPP) $(CPPFLAGS) -ansi -DPHYS_OFFSET=$(PHYS_OFFSET) 
-DMBOX_OFFSET=$(MBOX_OFFSET) -DKERNEL_OFFSET=$(KERNEL_OFFSET) 
-DFDT_OFFSET=$(FDT_OFFSET) -DFS_OFFSET=$(FS_OFFSET) -DKERNEL=$(KERNEL_IMAGE) 
-DFILESYSTEM=$(FILESYSTEM) -DTEXT_LIMIT=$(TEXT_LIMIT) -P -C -o $@ $<
+   $(CPP) $(CPPFLAGS) -ansi -DPHYS_OFFSET=$(PHYS_OFFSET) 
-DMBOX_OFFSET=$(MBOX_OFFSET) -DKERNEL_OFFSET=$(KERNEL_OFFSET) 
-DFDT_OFFSET=$(FDT_OFFSET) -DFS_OFFSET=$(FS_OFFSET) $(XEN) 
-DXEN_OFFSET=$(XEN_OFFSET) -DKERNEL=$(KERNEL_IMAGE) -DFILESYSTEM=$(FILESYSTEM) 
-DTEXT_LIMIT=$(TEXT_LIMIT) -P -C -o $@ $<
 
 fdt.dtb: $(KERNEL_DTB) Makefile gen-cpu-nodes.sh
( $(DTC) -O dts -I dtb $(KERNEL_DTB) ; echo "/ { $(CHOSEN_NODE) 
$(PSCI_NODE) $(CPUS_NODE) };" ) | $(DTC) -O dtb -o $@ -
diff --git a/boot_common.c b/boot_common.c
index 4947fe3..e7b8e1d 100644
--- a/boot_common.c
+++ b/boot_common.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 
-extern unsigned long kernel;
+extern unsigned long entrypoint;
 extern unsigned long dtb;
 
 void init_platform(void);
@@ -67,7 +67,7 @@ void __noreturn first_spin(unsigned int cpu, unsigned long 
*mbox,
if (cpu == 0) {
init_platform();
 
-   *mbox = (unsigned long)
+   *mbox = (unsigned long)
sevl();
spin(mbox, invalid, 1);
} else {
diff --git a/configure.ac b/configure.ac
index ab8f5b3..f7e24c7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -40,6 +40,18 @@ AC_ARG_WITH([dtb],
AS_HELP_STRING([--with-dtb], [Specify a particular DTB to use]),
[KERN_DTB="$withval"])
 
+AC_ARG_WITH([xen],
+   AS_HELP_STRING([--with-xen], [Compile for Xen, and Specify a particular 
Xen to use]),
+   X_IMAGE=$withval)
+
+AS_IF([test "x$X_IMAGE" == "x"], [],
+  [AS_IF([test ! -f "$X_IMAGE"],
+[AC_MSG_ERROR([Could not find Xen hypervisor binary: $X_IMAGE])]
+  )]
+)
+AC_SUBST([XEN_IMAGE], [$X_IMAGE])
+AM_CONDITIONAL([XEN], [test "x$X_IMAGE" != "x"])
+
 # Ensure that the user has provided us with a sane kernel dir.
 m4_define([CHECKFILES], [KERN_DIR,
KERN_DTB,
@@ -50,6 +62,10 @@ m4_foreach([checkfile], [CHECKFILES],
 
 AC_SUBST([KERNEL_IMAGE], [$KERN_IMAGE])
 AC_SUBST([KERNEL_DTB], [$KERN_DTB])
+AS_IF([test "x$X_IMAGE" != "x"],
+  [AC_SUBST([IMAGE], ["xen-system.axf"])],
+  [AC_SUBST([IMAGE], ["linux-system.axf"])]
+)
 
 # Allow a user to pass --enable-psci
 AC_ARG_ENABLE([psci],
@@ -119,4 +135,5 @@ echo "  CPU IDs:   ${CPU_IDS}"
 echo "  Use GICv3? ${USE_GICV3}"
 echo "  Boot-wrapper execution state:  AArch${BOOTWRAPPER_ES}"
 echo "  Kernel execution state:AArch${KERNEL_ES}"
+echo "  Xen image  

[Xen-devel] [PATCH v2 2/4] Xen: Support adding DT nodes

[Andre Przywara]

From: Christoffer Dall 

Support adding xen,xen-bootargs node via --with-xen-bootargs to the
configure script and automatically add the Dom0 node to the DT as well.

Signed-off-by: Christoffer Dall 
Signed-off-by: Andre Przywara 
---
 Makefile.am  | 23 +++
 configure.ac |  9 +
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index f8b9ec9..db97f9c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -96,21 +96,28 @@ FDT_OFFSET  := 0x0800
 if XEN
 XEN:= -DXEN=$(XEN_IMAGE)
 XEN_OFFSET := 0x0820
+KERNEL_SIZE:= $(shell stat -Lc %s $(KERNEL_IMAGE) 2>/dev/null || echo 0)
+DOM0_OFFSET:= $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET
+XEN_BOOTARGS   := xen,xen-bootargs = \"$(XEN_CMDLINE)\";   \
+  \#address-cells = <2>;   \
+  \#size-cells = <2>;  \
+  module@1 {   \
+   compatible = \"xen,linux-zimage\", 
\"xen,multiboot-module\"; \
+   reg = <0x0 $(DOM0_OFFSET) 0x0 $(KERNEL_SIZE)>;  \
+  };
 endif
 
 if INITRD
 INITRD_FLAGS   := -DUSE_INITRD
+INITRD_CHOSEN   := linux,initrd-start = <$(FILESYSTEM_START)>; \
+  linux,initrd-end = <$(FILESYSTEM_END)>;
+endif
+
 CHOSEN_NODE:= chosen { \
bootargs = \"$(CMDLINE)\";  \
-   linux,initrd-start = <$(FILESYSTEM_START)>; \
-   linux,initrd-end = <$(FILESYSTEM_END)>; \
-  };
-else
-INITRD_FLAGS   :=
-CHOSEN_NODE:= chosen { \
-   bootargs = \"$(CMDLINE)\";  \
+   $(INITRD_CHOSEN)\
+   $(XEN_BOOTARGS) \
   };
-endif
 
 CPPFLAGS   += $(INITRD_FLAGS)
 CFLAGS += -Iinclude/ -I$(ARCH_SRC)/include/
diff --git a/configure.ac b/configure.ac
index f7e24c7..aff4aad 100644
--- a/configure.ac
+++ b/configure.ac
@@ -98,6 +98,12 @@ AC_ARG_WITH([cmdline],
[C_CMDLINE=$withval])
 AC_SUBST([CMDLINE], [$C_CMDLINE])
 
+X_CMDLINE="console=dtuart dtuart=serial0 no-bootscrub"
+AC_ARG_WITH([xen-cmdline],
+   AS_HELP_STRING([--with-xen-cmdline], [set Xen command line]),
+   [X_CMDLINE=$withval])
+AC_SUBST([XEN_CMDLINE], [$X_CMDLINE])
+
 # Allow a user to pass --enable-gicv3
 AC_ARG_ENABLE([gicv3],
AS_HELP_STRING([--enable-gicv3], [enable GICv3 instead of GICv2]),
@@ -136,4 +142,7 @@ echo "  Use GICv3? ${USE_GICV3}"
 echo "  Boot-wrapper execution state:  AArch${BOOTWRAPPER_ES}"
 echo "  Kernel execution state:AArch${KERNEL_ES}"
 echo "  Xen image  ${XEN_IMAGE:-NONE}"
+if test "x${XEN_IMAGE}" != "x"; then
+echo "  Xen command line:  ${XEN_CMDLINE}"
+fi
 echo ""
-- 
2.9.0


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

[Xen-devel] [PATCH v2 4/4] Explicitly clean linux-system.axf and xen-system.axf

[Andre Przywara]

From: Christoffer Dall 

When doing a make clean, only the output image currently configured to
build is being removed.  However, one would expect all build artifacts
to be removed when doing a 'make clean' and when switching between Xen
and Linux builds, it is easy to accidentally run an older build than
intended.  Simply hardcode the axf image file names.

Signed-off-by: Christoffer Dall 
Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index db97f9c..506a1d9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -130,7 +130,7 @@ OFILES  += $(addprefix $(ARCH_SRC),boot.o 
stack.o $(BOOTMETHOD) utils.o)
 
 all: $(IMAGE)
 
-CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
+CLEANFILES = $(IMAGE) linux-system.axf xen-system.axf $(OFILES) model.lds 
fdt.dtb
 
 $(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) 
$(XEN_IMAGE)
$(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
-- 
2.9.0


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

[Xen-devel] [PATCH v2 0/4] boot-wrapper: arm64: Xen support

[Andre Przywara]

These patches allow to include a Xen hypervisor binary into a boot-wrapper
ELF file, so that a Foundation Platform or a Fast Model can boot a Xen
system (including a Dom0 kernel).
The original patches have been around for a while, so this series is
merely an update to apply on the latest boot-wrapper HEAD. Also I fixed
minor things here and there (like increasing Xen's load address to
accomodate for Dom0 kernels bigger than 16 MB) and addressed Julien's
review comments.

For testing this just add: "--with-xen=/path/to/src/xen/xen" to the
./configure command line and feed the resulting xen-system.axf file to
the model.

Cheers,
Andre.

Changelog v1 .. v2:
- use "xen-cmdline" instead of bootargs as parameter and variable name
- move hunk in patch 1/4 to make patch 2/4 smaller
- replace AC_FILE_CHECK macro usage to fix cross compilation

Christoffer Dall (3):
  Support for building in a Xen binary
  Xen: Support adding DT nodes
  Explicitly clean linux-system.axf and xen-system.axf

Ian Campbell (1):
  Xen: Select correct dom0 console

 .gitignore|  1 +
 Makefile.am   | 35 +++
 boot_common.c |  4 ++--
 configure.ac  | 29 -
 model.lds.S   | 14 ++
 5 files changed, 68 insertions(+), 15 deletions(-)

-- 
2.9.0


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

[Xen-devel] [PATCH v2 3/4] Xen: Select correct dom0 console

[Andre Przywara]

From: Ian Campbell 

If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
the usual ttyAMA0 otherwise.

Signed-off-by: Ian Campbell 
Signed-off-by: Christoffer Dall 
Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 configure.ac | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index aff4aad..c959ab8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -92,7 +92,8 @@ AC_ARG_WITH([initrd],
 AC_SUBST([FILESYSTEM], [$USE_INITRD])
 AM_CONDITIONAL([INITRD], [test "x$USE_INITRD" != "x"])
 
-C_CMDLINE="console=ttyAMA0 earlyprintk=pl011,0x1c09"
+AS_IF([test "x$X_IMAGE" = "x"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
+C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c09"
 AC_ARG_WITH([cmdline],
AS_HELP_STRING([--with-cmdline], [set a command line for the kernel]),
[C_CMDLINE=$withval])
-- 
2.9.0


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

Re: [Xen-devel] [PATCH v3 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

[Jan Beulich]

>>> On 21.11.16 at 22:00,  wrote:
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -16,6 +16,7 @@
>   * this program; If not, see .
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 

Please take the opportunity and remove the pointless xen/config.h
inclusion at once.

> @@ -1383,7 +1384,91 @@ static int hvm_access_cf8(
>  static int acpi_ioaccess(
>  int dir, unsigned int port, unsigned int bytes, uint32_t *val)
>  {
> -return X86EMUL_UNHANDLEABLE;
> +uint8_t *reg = NULL;
> +const uint8_t *mask = NULL;
> +bool is_cpu_map = false;
> +struct domain *currd = current->domain;

const?

> +const static uint8_t pm1a_mask[4] = {ACPI_BITMASK_GLOBAL_LOCK_STATUS, 0,
> + ACPI_BITMASK_GLOBAL_LOCK_ENABLE, 0};
> +const static uint8_t gpe0_mask[4] = {1U << XEN_GPE0_CPUHP_BIT, 0,
> + 1U << XEN_GPE0_CPUHP_BIT, 0};

Hmm, funny, in someone else's patch I've recently seen the same.
Can we please stick to the more standard "storage type first"
ordering of declaration elements. After all const modifies the type,
and hence better stays together with it.

And then I'd like to have an explanation (in the commit message)
about the choice of the values for pm1a_mask. Plus you using
uint8_t here is at least odd, considering that this is about registers
consisting of two 16-bit halves. I'm not even certain the spec
permits these to be accessed with other than the specified
granularity.

Or wait - the literal 4-s here look bad too. Perhaps the two should
be combined into a variable of type
typeof(currd->arch.hvm_domain.acpi_io), so values and masks
really match up. Which would still seem to make it desirable for the
parts to be of type uint16_t, if permitted by the spec.

> +BUILD_BUG_ON((ACPI_PM1A_EVT_BLK_LEN != 4) ||
> + (ACPI_GPE0_BLK_LEN_V1 != 4));

Please split these into two, so that one of them triggering uniquely
identifies the offender. There's no code being generated for them,
so it doesn't matter how many there are. Perhaps it might even be
worth moving each into its respective case block below.

> +ASSERT(!has_acpi_ff(currd));
> +
> +switch ( port )
> +{
> +case ACPI_PM1A_EVT_BLK_ADDRESS_V1 ...
> + ACPI_PM1A_EVT_BLK_ADDRESS_V1 + ACPI_PM1A_EVT_BLK_LEN - 1:
> +reg = currd->arch.hvm_domain.acpi_io.pm1a;
> +mask = pm1a_mask;
> +break;
> +
> +case ACPI_GPE0_BLK_ADDRESS_V1 ...
> + ACPI_GPE0_BLK_ADDRESS_V1 + ACPI_GPE0_BLK_LEN_V1 - 1:
> +reg = currd->arch.hvm_domain.acpi_io.gpe;
> +mask = gpe0_mask;
> +break;
> +
> +case XEN_ACPI_CPU_MAP ...
> + XEN_ACPI_CPU_MAP + XEN_ACPI_CPU_MAP_LEN - 1:
> +is_cpu_map = true;

In order to make more obvious in the code below that reg and mask
can't be NULL, wouldn't it make sense to ditch this variable and
instead use checks of reg against NULL in the code further down?

> +break;
> +
> +default:
> +return X86EMUL_UNHANDLEABLE;
> +}
> +
> +if ( bytes == 0 )
> +return X86EMUL_OKAY;

Did you find a check like this in any other I/O port handler? It doesn't
seem to make sense to me.

> +if ( dir == IOREQ_READ )
> +{
> +if ( is_cpu_map )
> +{
> +unsigned int first_byte = port - XEN_ACPI_CPU_MAP;
> +
> +/*
> + * Clear bits that we are about to read to in case we
> + * copy fewer than @bytes.
> + */
> +*val &= (~((1ULL << (bytes * 8)) - 1)) & 0x;

*val being of type uint32_t I understand neither the ULL suffix nor
the and-ing. How about

if ( bytes < 4 )
*val &= ~0U << (bytes * 8);

?

> +if ( ((currd->max_vcpus + 7) / 8) > first_byte )
> +{
> +memcpy(val, (uint8_t *)currd->avail_vcpus + first_byte,
> +   min(bytes, ((currd->max_vcpus + 7) / 8) - 
> first_byte));
> +}

Stray braces.

> +}
> +else
> +memcpy(val, [port & 3], bytes);
> +}
> +else
> +{
> +unsigned int idx = port & 3;
> +unsigned int i;
> +uint8_t *ptr;

const

> +if ( is_cpu_map )
> +/*
> + * CPU map is only read by DSDT's PRSC method and should never
> + * be written by a guest.
> + */
> +return X86EMUL_UNHANDLEABLE;
> +
> +ptr = (uint8_t *)val;
> +for ( i = 0; i < bytes; i++, idx++ )
> +{
> +if ( idx < 2 ) /* status, write 1 to clear. */
> +reg[idx] &= ~(mask[i] & ptr[i]);
> +else   /* enable */
> +reg[idx] |= (mask[i] & ptr[i]);

Don't you mean mask[idx] in both cases?

Jan

___
Xen-devel mailing list

Re: [Xen-devel] [PATCH v3 02/11] acpi: Define ACPI IO registers for PVH guests

[Boris Ostrovsky]

On 11/22/2016 09:07 AM, Jan Beulich wrote:

On 22.11.16 at 13:28,  wrote:




On 11/22/2016 05:37 AM, Jan Beulich wrote:

On 21.11.16 at 22:00,  wrote:

@@ -119,11 +122,33 @@ typedef struct buffered_iopage buffered_iopage_t;

 /* Compatibility definitions for the default location (version 0). */
 #define ACPI_PM1A_EVT_BLK_ADDRESSACPI_PM1A_EVT_BLK_ADDRESS_V0
+#define ACPI_PM1A_EVT_BLK_LEN0x04
+#define ACPI_PM1A_EVT_BLK_BIT_OFFSET 0x00
 #define ACPI_PM1A_CNT_BLK_ADDRESSACPI_PM1A_CNT_BLK_ADDRESS_V0
+#define ACPI_PM1A_CNT_BLK_LEN0x02
+#define ACPI_PM1A_CNT_BLK_BIT_OFFSET 0x00
 #define ACPI_PM_TMR_BLK_ADDRESS  ACPI_PM_TMR_BLK_ADDRESS_V0
+#define ACPI_PM_TMR_BLK_LEN  0x04
+#define ACPI_PM_TMR_BLK_BIT_OFFSET   0x00
 #define ACPI_GPE0_BLK_ADDRESSACPI_GPE0_BLK_ADDRESS_V0
 #define ACPI_GPE0_BLK_LENACPI_GPE0_BLK_LEN_V0

+#if __XEN_INTERFACE_VERSION__ >= 0x00040800
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+/* Location of online VCPU bitmap. */
+#define XEN_ACPI_CPU_MAP 0xaf00
+#define XEN_ACPI_CPU_MAP_LEN ((HVM_MAX_VCPUS + 7) / 8)
+
+#if XEN_ACPI_CPU_MAP + XEN_ACPI_CPU_MAP_LEN >= ACPI_GPE0_BLK_ADDRESS_V1
+#error "XEN_ACPI_CPU_MAP is too big"
+#endif
+
+/* GPE0 bit set during CPU hotplug */
+#define XEN_GPE0_CPUHP_BIT   2
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+#endif /* __XEN_INTERFACE_VERSION__ >= 0x00040800 */

 #endif /* _IOREQ_H_ */


I'm afraid there's been some misunderstanding here during the v2
discussion: New hypervisor/tools only definitions don't need an
additional interface version guard. It's instead the pre-existing
ones which should be removed from the namespace by adding
such a guard.


We want to keep all of them now. Shouldn't then the interface check be
added after we move to Andrew's suggestion of dynamic IO ranges?


No, we want them gone from the public interface for new
consumers. The only valid consumer has always been the tool
stack, just that this hadn't been properly done in the header.
Hence the need to add __XEN__ / __XEN_TOOLS__ around new
additions, and additionally interface version guards around
existing ones.



pmtimer.c uses some of those macros so how will wrapping interface 
version check around existing definitions continue to work when 
interface version is updated, unless dynamic IO ranges are also added by 
that time?




And of course _everything_ being added here anew needs to be
XEN_ prefixed and guarded.



The ones that I didn't add the prefix to are the standard ACPI names. If
I did this would look like

#define ACPI_PM_TMR_BLK_ADDRESS  ACPI_PM_TMR_BLK_ADDRESS_V0
+#define XEN_ACPI_PM_TMR_BLK_LEN  0x04
+#define XEN_ACPI_PM_TMR_BLK_BIT_OFFSET   0x00


There's nothing standard here. Implementations are fine to specify
a larger length iirc, at least for ACPI v2 and newer. If these values
were all fixed, there wouldn't have been a need to specify them in
FADT in the first place.


I meant that, unlike XEN_ACPI_CPU_MAP that I added, these blocks are 
ACPI-standard, not macros' values.


Are you asking to rename just the newly introduced definitions 
(lengths/offsets) or existing address macros as well? Doing the latter 
will also require changes to at least pmtimer.c


-boris




And as for being guarded, don't you think it mill make things difficult
to read. E.g.:

#define ACPI_PM_TMR_BLK_ADDRESS  ACPI_PM_TMR_BLK_ADDRESS_V0
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+#define XEN_ACPI_PM_TMR_BLK_LEN  0x04
+#define XEN_ACPI_PM_TMR_BLK_BIT_OFFSET   0x00
+#endif

Repeated 3 times.


Then don't repeat it three times and put the lengths and bit offsets
after all the addresses.

Jan



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

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Boris Ostrovsky]

On 11/22/2016 08:59 AM, Jan Beulich wrote:

On 22.11.16 at 13:34,  wrote:




On 11/22/2016 05:39 AM, Jan Beulich wrote:

On 22.11.16 at 11:31,  wrote:

On 21.11.16 at 22:00,  wrote:

This domctl is called when a VCPU is hot-(un)plugged to a guest (via
'xl vcpu-set').

The primary reason for adding this call is because for PVH guests
the hypervisor needs to send an SCI and set GPE registers. This is
unlike HVM guests that have qemu to perform these tasks.


And the tool stack can't do this?


For the avoidance of further misunderstandings: Of course likely
not completely on its own, but by using a (to be introduced) more
low level hypervisor interface (setting arbitrary GPE bits, with SCI
raised as needed, or the SCI raising being another hypercall).


So you are suggesting breaking up XEN_DOMCTL_set_avail_vcpus into

XEN_DOMCTL_set_acpi_reg(io_offset, length, val)
XEN_DOMCTL_set_avail_vcpus(avail_vcpus_bitmap)
XEN_DOMCTL_send_virq(virq)

(with perhaps set_avail_vcpus folded into set_acpi_reg) ?


Well, I don't see what set_avail_vcpus would be good for
considering that during v2 review you've said that you need it
just for the GPE modification and SCI sending.



Someone needs to provide the hypervisor with the new number of available 
(i.e. hot-plugged/unplugged) VCPUs, thus the name of the domctl. GPE/SCI 
manipulation are part of that update.


(I didn't say it during v2 review and I should have)




And whether to split the other two, or simply send SCI whenever
GPE bits have been modified depends on the specific requirements
the ACPI spec puts on us. Or maybe it could always be folded,
with (if necessary) SCI sending being controlled by a flag.


True. The spec says that all ACPI events generate an SCI.

-boris

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

[Xen-devel] Big.LITTLE support (WAS Re: Xen ARM community call)

[Julien Grall]

Hello Anastassios,

On 09/11/16 22:50, Anastassios Nanos wrote:

Hi Julien, all,


I would like to start organizing a recurring community call to discuss and
sync-up on upcoming features for Xen ARM.


great idea, I'd like to join too (GMT).


Example of features that could be discussed:
- Sharing co-processor between guests
- PCI passthrough


Another issue to discuss, at some point, could be big.LITTLE support
(based on 
https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01802.html).


Good point. Looking at the discussion, many ideas was suggested and I 
don't remember whether we all agreed on what to do. I would recommend to 
summarize the discussion in a mail so we can come up with an agreement.


Peng, would you be up to do this?

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/2] x86emul: in_longmode() should not ignore ->read_msr() errors

[Andrew Cooper]

On 22/11/16 14:20, Jan Beulich wrote:
> Suggested-by: George Dunlap 
> Signed-off-by: Jan Beulich 

Possibly worth nothing in the commit message that the current
implementation of this hook when present never fails with MSR_EFER?

Reviewed-by: Andrew Cooper 

>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1296,10 +1296,10 @@ in_longmode(
>  {
>  uint64_t efer;
>  
> -if (ops->read_msr == NULL)
> +if ( !ops->read_msr ||
> + unlikely(ops->read_msr(MSR_EFER, , ctxt) != X86EMUL_OKAY) )
>  return -1;
>  
> -ops->read_msr(MSR_EFER, , ctxt);
>  return !!(efer & EFER_LMA);
>  }
>  
>
>
>


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

[Xen-devel] [PATCH 2/2] x86emul: in_longmode() should not ignore ->read_msr() errors

[Jan Beulich]

Suggested-by: George Dunlap 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1296,10 +1296,10 @@ in_longmode(
 {
 uint64_t efer;
 
-if (ops->read_msr == NULL)
+if ( !ops->read_msr ||
+ unlikely(ops->read_msr(MSR_EFER, , ctxt) != X86EMUL_OKAY) )
 return -1;
 
-ops->read_msr(MSR_EFER, , ctxt);
 return !!(efer & EFER_LMA);
 }
 



x86emul: in_longmode() should not ignore ->read_msr() errors

Suggested-by: George Dunlap 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1296,10 +1296,10 @@ in_longmode(
 {
 uint64_t efer;
 
-if (ops->read_msr == NULL)
+if ( !ops->read_msr ||
+ unlikely(ops->read_msr(MSR_EFER, , ctxt) != X86EMUL_OKAY) )
 return -1;
 
-ops->read_msr(MSR_EFER, , ctxt);
 return !!(efer & EFER_LMA);
 }
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] x86emul: simplify DstBitBase handling code

[Andrew Cooper]

On 22/11/16 14:20, Jan Beulich wrote:
> ..., at once making it more obvious that even in the negative bit
> offset case the resulting bit offset to be used by the inlined
> instructions will always be constrained to the operand size of the
> original instruction.
>
> Also add a test case which would have failed without the XSA-195 fix.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] Xen ARM community call

[Julien Grall]

Hello Dirk,

On 09/11/16 07:32, Dirk Behme wrote:

On 08.11.2016 13:19, Julien Grall wrote:

Hi all,

I would like to start organizing a recurring community call to discuss
and sync-up on upcoming features for Xen ARM.

Example of features that could be discussed:
- Sharing co-processor between guests
- PCI passthrough



Would it be an option to talk about

"Don't disable clocks owned by Xen in the Linux kernel"
https://bugs.xenproject.org/xen/bug/45

too?

Some month ago we've had a discussion with the kernel people about that
issue. But I think there has been no solution, yet.


The discussion on the thread [1] was quite long and looking at it, I am 
not sure where it is stuck. May I ask you to summarize it in the mail 
with the different suggestions?


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH 1/2] x86emul: simplify DstBitBase handling code

[Jan Beulich]

..., at once making it more obvious that even in the negative bit
offset case the resulting bit offset to be used by the inlined
instructions will always be constrained to the operand size of the
original instruction.

Also add a test case which would have failed without the XSA-195 fix.

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -431,6 +431,22 @@ int main(int argc, char **argv)
 goto fail;
 printf("okay\n");
 
+#ifdef __x86_64__
+printf("%-40s", "Testing btcq %r8,(%r11)...");
+instr[0] = 0x4d; instr[1] = 0x0f; instr[2] = 0xbb; instr[3] = 0x03;
+regs.eflags = 0x200;
+regs.rip= (unsigned long)[0];
+regs.r8 = (-1L << 40) + 1;
+regs.r11= (unsigned long)(res + (1L << 35));
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ (*res != 0x2233445C) ||
+ (regs.eflags != 0x201) ||
+ (regs.rip != (unsigned long)[4]) )
+goto fail;
+printf("okay\n");
+#endif
+
 res[0] = 0x12345678;
 res[1] = 0x87654321;
 
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2560,18 +2560,11 @@ x86_emulate(
 else if ( op_bytes == 4 )
 src.val = (int32_t)src.val;
 if ( (long)src.val < 0 )
-{
-unsigned long byte_offset =
+ea.mem.off -=
 op_bytes + (((-src.val - 1) >> 3) & ~(op_bytes - 1L));
-
-ea.mem.off -= byte_offset;
-src.val = (byte_offset << 3) + src.val;
-}
 else
-{
 ea.mem.off += (src.val >> 3) & ~(op_bytes - 1L);
-src.val &= (op_bytes << 3) - 1;
-}
+src.val &= (op_bytes << 3) - 1;
 }
 /* Becomes a normal DstMem operation from here on. */
 d = (d & ~DstMask) | DstMem;



x86emul: simplify DstBitBase handling code

..., at once making it more obvious that even in the negative bit
offset case the resulting bit offset to be used by the inlined
instructions will always be constrained to the operand size of the
original instruction.

Also add a test case which would have failed without the XSA-195 fix.

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -431,6 +431,22 @@ int main(int argc, char **argv)
 goto fail;
 printf("okay\n");
 
+#ifdef __x86_64__
+printf("%-40s", "Testing btcq %r8,(%r11)...");
+instr[0] = 0x4d; instr[1] = 0x0f; instr[2] = 0xbb; instr[3] = 0x03;
+regs.eflags = 0x200;
+regs.rip= (unsigned long)[0];
+regs.r8 = (-1L << 40) + 1;
+regs.r11= (unsigned long)(res + (1L << 35));
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ (*res != 0x2233445C) ||
+ (regs.eflags != 0x201) ||
+ (regs.rip != (unsigned long)[4]) )
+goto fail;
+printf("okay\n");
+#endif
+
 res[0] = 0x12345678;
 res[1] = 0x87654321;
 
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2560,18 +2560,11 @@ x86_emulate(
 else if ( op_bytes == 4 )
 src.val = (int32_t)src.val;
 if ( (long)src.val < 0 )
-{
-unsigned long byte_offset =
+ea.mem.off -=
 op_bytes + (((-src.val - 1) >> 3) & ~(op_bytes - 1L));
-
-ea.mem.off -= byte_offset;
-src.val = (byte_offset << 3) + src.val;
-}
 else
-{
 ea.mem.off += (src.val >> 3) & ~(op_bytes - 1L);
-src.val &= (op_bytes << 3) - 1;
-}
+src.val &= (op_bytes << 3) - 1;
 }
 /* Becomes a normal DstMem operation from here on. */
 d = (d & ~DstMask) | DstMem;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

[Paul Durrant]

> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 21 November 2016 21:01
> To: xen-devel@lists.xen.org
> Cc: jbeul...@suse.com; Andrew Cooper ;
> Wei Liu ; Ian Jackson ; Roger
> Pau Monne ; Boris Ostrovsky
> ; Paul Durrant 
> Subject: [PATCH v3 08/11] pvh/acpi: Handle ACPI accesses for PVH guests
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Paul Durrant 

> ---
> CC: Paul Durrant 
> ---
> Changes in v3:
> * Introduce a mask for pm1a and gpe0 that lists bits that a
>   guest can operate on.
> * Lots of small changes.
> 
>  xen/arch/x86/hvm/ioreq.c | 87
> +++-
>  xen/include/asm-x86/hvm/domain.h |  6 +++
>  2 files changed, 92 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index 51bb399..4ab0d0a 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -16,6 +16,7 @@
>   * this program; If not, see .
>   */
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1383,7 +1384,91 @@ static int hvm_access_cf8(
>  static int acpi_ioaccess(
>  int dir, unsigned int port, unsigned int bytes, uint32_t *val)
>  {
> -return X86EMUL_UNHANDLEABLE;
> +uint8_t *reg = NULL;
> +const uint8_t *mask = NULL;
> +bool is_cpu_map = false;
> +struct domain *currd = current->domain;
> +const static uint8_t pm1a_mask[4] =
> {ACPI_BITMASK_GLOBAL_LOCK_STATUS, 0,
> + ACPI_BITMASK_GLOBAL_LOCK_ENABLE, 0};
> +const static uint8_t gpe0_mask[4] = {1U << XEN_GPE0_CPUHP_BIT, 0,
> + 1U << XEN_GPE0_CPUHP_BIT, 0};
> +
> +BUILD_BUG_ON((ACPI_PM1A_EVT_BLK_LEN != 4) ||
> + (ACPI_GPE0_BLK_LEN_V1 != 4));
> +
> +ASSERT(!has_acpi_ff(currd));
> +
> +switch ( port )
> +{
> +case ACPI_PM1A_EVT_BLK_ADDRESS_V1 ...
> + ACPI_PM1A_EVT_BLK_ADDRESS_V1 + ACPI_PM1A_EVT_BLK_LEN - 1:
> +reg = currd->arch.hvm_domain.acpi_io.pm1a;
> +mask = pm1a_mask;
> +break;
> +
> +case ACPI_GPE0_BLK_ADDRESS_V1 ...
> + ACPI_GPE0_BLK_ADDRESS_V1 + ACPI_GPE0_BLK_LEN_V1 - 1:
> +reg = currd->arch.hvm_domain.acpi_io.gpe;
> +mask = gpe0_mask;
> +break;
> +
> +case XEN_ACPI_CPU_MAP ...
> + XEN_ACPI_CPU_MAP + XEN_ACPI_CPU_MAP_LEN - 1:
> +is_cpu_map = true;
> +break;
> +
> +default:
> +return X86EMUL_UNHANDLEABLE;
> +}
> +
> +if ( bytes == 0 )
> +return X86EMUL_OKAY;
> +
> +if ( dir == IOREQ_READ )
> +{
> +if ( is_cpu_map )
> +{
> +unsigned int first_byte = port - XEN_ACPI_CPU_MAP;
> +
> +/*
> + * Clear bits that we are about to read to in case we
> + * copy fewer than @bytes.
> + */
> +*val &= (~((1ULL << (bytes * 8)) - 1)) & 0x;
> +
> +if ( ((currd->max_vcpus + 7) / 8) > first_byte )
> +{
> +memcpy(val, (uint8_t *)currd->avail_vcpus + first_byte,
> +   min(bytes, ((currd->max_vcpus + 7) / 8) - 
> first_byte));
> +}
> +}
> +else
> +memcpy(val, [port & 3], bytes);
> +}
> +else
> +{
> +unsigned int idx = port & 3;
> +unsigned int i;
> +uint8_t *ptr;
> +
> +if ( is_cpu_map )
> +/*
> + * CPU map is only read by DSDT's PRSC method and should never
> + * be written by a guest.
> + */
> +return X86EMUL_UNHANDLEABLE;
> +
> +ptr = (uint8_t *)val;
> +for ( i = 0; i < bytes; i++, idx++ )
> +{
> +if ( idx < 2 ) /* status, write 1 to clear. */
> +reg[idx] &= ~(mask[i] & ptr[i]);
> +else   /* enable */
> +reg[idx] |= (mask[i] & ptr[i]);
> +}
> +}
> +
> +return X86EMUL_OKAY;
>  }
> 
>  void hvm_ioreq_init(struct domain *d)
> diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-
> x86/hvm/domain.h
> index f34d784..f492a2b 100644
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -87,6 +87,12 @@ struct hvm_domain {
>  } ioreq_server;
>  struct hvm_ioreq_server *default_ioreq_server;
> 
> +/* PVH guests */
> +struct {
> +uint8_t pm1a[ACPI_PM1A_EVT_BLK_LEN];
> +uint8_t gpe[ACPI_GPE0_BLK_LEN_V1];
> +} acpi_io;
> +
>  /* Cached CF8 for guest PCI config cycles */
>  uint32_tpci_cf8;
> 
> --
> 2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] [PATCH 0/2] x86emul: recent XSA follow-up

[Jan Beulich]

These aren't outright bug fixes, so aren't strictly candidates for 4.8,
but I think they're still worthwhile to consider.

1: simplify DstBitBase handling code
2: in_longmode() should not ignore ->read_msr() errors

Signed-off-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v3 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses

[Jan Beulich]

>>> On 22.11.16 at 13:38,  wrote:

> 
> On 11/22/2016 06:34 AM, Jan Beulich wrote:
> On 21.11.16 at 22:00,  wrote:
>>> PVH guests will have ACPI accesses emulated by the hypervisor
>>> as opposed to QEMU (as is the case for HVM guests)
>>>
>>> Support for IOREQ server emulation of CPU hotplug is indicated
>>> by XEN_X86_EMU_IOREQ_CPUHP flag.
>>>
>>> Logic for the handler will be provided by a later patch.
>>>
>>> Signed-off-by: Boris Ostrovsky 
>>> ---
>>> CC: Paul Durrant 
>>> ---
>>> Changes in v3:
>>> * acpi_ioaccess() returns X86EMUL_UNHANDLEABLE
>>> * Renamed XEN_X86_EMU_IOREQ_CPUHP to XEN_X86_EMU_ACPI_FF (together
>>>   with corresponding has_*())
>>
>> Except in the description above.
>>
>> Also, while I'm fine with the flag rename, has_acpi_ff() looks wrong
>> (or at least misleading) to me: Both HVM and PVHv2 have fixed
>> function hardware emulated, they only differ in who the emulator
>> is. Reduced hardware, if we would emulate such down the road,
>> otoh might then indeed come without. So how about one of
>> has_xen_acpi_ff() or has_dm_acpi_ff()?
> 
> I think the latter is better. But then to keep flag names in sync with 
> has_*() macros, how about XEN_X86_EMU_DM_ACPI_FF?

Not sure - the flag name, as said, seemed fine to me before, and I
don't overly care about the two names fully matching up. Maybe
others here have an opinion?

Jan


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

Re: [Xen-devel] [PATCH v3 02/11] acpi: Define ACPI IO registers for PVH guests

[Jan Beulich]

>>> On 22.11.16 at 13:28,  wrote:

> 
> On 11/22/2016 05:37 AM, Jan Beulich wrote:
> On 21.11.16 at 22:00,  wrote:
>>> @@ -119,11 +122,33 @@ typedef struct buffered_iopage buffered_iopage_t;
>>>
>>>  /* Compatibility definitions for the default location (version 0). */
>>>  #define ACPI_PM1A_EVT_BLK_ADDRESSACPI_PM1A_EVT_BLK_ADDRESS_V0
>>> +#define ACPI_PM1A_EVT_BLK_LEN0x04
>>> +#define ACPI_PM1A_EVT_BLK_BIT_OFFSET 0x00
>>>  #define ACPI_PM1A_CNT_BLK_ADDRESSACPI_PM1A_CNT_BLK_ADDRESS_V0
>>> +#define ACPI_PM1A_CNT_BLK_LEN0x02
>>> +#define ACPI_PM1A_CNT_BLK_BIT_OFFSET 0x00
>>>  #define ACPI_PM_TMR_BLK_ADDRESS  ACPI_PM_TMR_BLK_ADDRESS_V0
>>> +#define ACPI_PM_TMR_BLK_LEN  0x04
>>> +#define ACPI_PM_TMR_BLK_BIT_OFFSET   0x00
>>>  #define ACPI_GPE0_BLK_ADDRESSACPI_GPE0_BLK_ADDRESS_V0
>>>  #define ACPI_GPE0_BLK_LENACPI_GPE0_BLK_LEN_V0
>>>
>>> +#if __XEN_INTERFACE_VERSION__ >= 0x00040800
>>> +#if defined(__XEN__) || defined(__XEN_TOOLS__)
>>> +
>>> +/* Location of online VCPU bitmap. */
>>> +#define XEN_ACPI_CPU_MAP 0xaf00
>>> +#define XEN_ACPI_CPU_MAP_LEN ((HVM_MAX_VCPUS + 7) / 8)
>>> +
>>> +#if XEN_ACPI_CPU_MAP + XEN_ACPI_CPU_MAP_LEN >= ACPI_GPE0_BLK_ADDRESS_V1
>>> +#error "XEN_ACPI_CPU_MAP is too big"
>>> +#endif
>>> +
>>> +/* GPE0 bit set during CPU hotplug */
>>> +#define XEN_GPE0_CPUHP_BIT   2
>>> +
>>> +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
>>> +#endif /* __XEN_INTERFACE_VERSION__ >= 0x00040800 */
>>>
>>>  #endif /* _IOREQ_H_ */
>>
>> I'm afraid there's been some misunderstanding here during the v2
>> discussion: New hypervisor/tools only definitions don't need an
>> additional interface version guard. It's instead the pre-existing
>> ones which should be removed from the namespace by adding
>> such a guard.
> 
> We want to keep all of them now. Shouldn't then the interface check be 
> added after we move to Andrew's suggestion of dynamic IO ranges?

No, we want them gone from the public interface for new
consumers. The only valid consumer has always been the tool
stack, just that this hadn't been properly done in the header.
Hence the need to add __XEN__ / __XEN_TOOLS__ around new
additions, and additionally interface version guards around
existing ones.

>> And of course _everything_ being added here anew needs to be
>> XEN_ prefixed and guarded.
> 
> 
> The ones that I didn't add the prefix to are the standard ACPI names. If 
> I did this would look like
> 
> #define ACPI_PM_TMR_BLK_ADDRESS  ACPI_PM_TMR_BLK_ADDRESS_V0
> +#define XEN_ACPI_PM_TMR_BLK_LEN  0x04
> +#define XEN_ACPI_PM_TMR_BLK_BIT_OFFSET   0x00

There's nothing standard here. Implementations are fine to specify
a larger length iirc, at least for ACPI v2 and newer. If these values
were all fixed, there wouldn't have been a need to specify them in
FADT in the first place.

> And as for being guarded, don't you think it mill make things difficult 
> to read. E.g.:
> 
> #define ACPI_PM_TMR_BLK_ADDRESS  ACPI_PM_TMR_BLK_ADDRESS_V0
> +#if defined(__XEN__) || defined(__XEN_TOOLS__)
> +#define XEN_ACPI_PM_TMR_BLK_LEN  0x04
> +#define XEN_ACPI_PM_TMR_BLK_BIT_OFFSET   0x00
> +#endif
> 
> Repeated 3 times.

Then don't repeat it three times and put the lengths and bit offsets
after all the addresses.

Jan


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

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Jan Beulich]

>>> On 22.11.16 at 13:34,  wrote:

> 
> On 11/22/2016 05:39 AM, Jan Beulich wrote:
> On 22.11.16 at 11:31,  wrote:
>> On 21.11.16 at 22:00,  wrote:
 This domctl is called when a VCPU is hot-(un)plugged to a guest (via
 'xl vcpu-set').

 The primary reason for adding this call is because for PVH guests
 the hypervisor needs to send an SCI and set GPE registers. This is
 unlike HVM guests that have qemu to perform these tasks.
>>>
>>> And the tool stack can't do this?
>>
>> For the avoidance of further misunderstandings: Of course likely
>> not completely on its own, but by using a (to be introduced) more
>> low level hypervisor interface (setting arbitrary GPE bits, with SCI
>> raised as needed, or the SCI raising being another hypercall).
> 
> So you are suggesting breaking up XEN_DOMCTL_set_avail_vcpus into
> 
> XEN_DOMCTL_set_acpi_reg(io_offset, length, val)
> XEN_DOMCTL_set_avail_vcpus(avail_vcpus_bitmap)
> XEN_DOMCTL_send_virq(virq)
> 
> (with perhaps set_avail_vcpus folded into set_acpi_reg) ?

Well, I don't see what set_avail_vcpus would be good for
considering that during v2 review you've said that you need it
just for the GPE modification and SCI sending.

And whether to split the other two, or simply send SCI whenever
GPE bits have been modified depends on the specific requirements
the ACPI spec puts on us. Or maybe it could always be folded,
with (if necessary) SCI sending being controlled by a flag.

Jan


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

[Xen-devel] [PATCH 3/3] x86/HVM: correct error code writing during task switch

[Jan Beulich]

Whether to write 32 or just 16 bits depends on the D bit of the target
CS. The width of the stack pointer to use depends on the B bit of the
target SS.

Also avoid using the no-fault copying routine.

Finally avoid using yet another struct segment_register variable here.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3033,9 +3033,6 @@ void hvm_task_switch(
 goto out;
 }
 
-if ( (tss.trace & 1) && !exn_raised )
-hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
-
 tr.attr.fields.type = 0xb; /* busy 32-bit tss */
 hvm_set_segment_register(v, x86_seg_tr, );
 
@@ -3051,17 +3048,32 @@ void hvm_task_switch(
 
 if ( errcode >= 0 )
 {
-struct segment_register reg;
 unsigned long linear_addr;
-regs->esp -= 4;
-hvm_get_segment_register(current, x86_seg_ss, );
-/* Todo: do not ignore access faults here. */
-if ( hvm_virtual_to_linear_addr(x86_seg_ss, , regs->esp,
-4, hvm_access_write, 32,
+unsigned int opsz, sp;
+
+hvm_get_segment_register(current, x86_seg_cs, );
+opsz = segr.attr.fields.db ? 4 : 2;
+hvm_get_segment_register(current, x86_seg_ss, );
+if ( segr.attr.fields.db )
+sp = regs->_esp -= opsz;
+else
+sp = *(uint16_t *)>esp -= opsz;
+if ( hvm_virtual_to_linear_addr(x86_seg_ss, , sp, opsz,
+hvm_access_write,
+16 << segr.attr.fields.db,
 _addr) )
-hvm_copy_to_guest_virt_nofault(linear_addr, , 4, 0);
+{
+rc = hvm_copy_to_guest_virt(linear_addr, , opsz, 0);
+if ( rc == HVMCOPY_bad_gva_to_gfn )
+exn_raised = 1;
+else if ( rc != HVMCOPY_okay )
+goto out;
+}
 }
 
+if ( (tss.trace & 1) && !exn_raised )
+hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
+
  out:
 hvm_unmap_entry(optss_desc);
 hvm_unmap_entry(nptss_desc);



x86/HVM: correct error code writing during task switch

Whether to write 32 or just 16 bits depends on the D bit of the target
CS. The width of the stack pointer to use depends on the B bit of the
target SS.

Also avoid using the no-fault copying routine.

Finally avoid using yet another struct segment_register variable here.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3033,9 +3033,6 @@ void hvm_task_switch(
 goto out;
 }
 
-if ( (tss.trace & 1) && !exn_raised )
-hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
-
 tr.attr.fields.type = 0xb; /* busy 32-bit tss */
 hvm_set_segment_register(v, x86_seg_tr, );
 
@@ -3051,17 +3048,32 @@ void hvm_task_switch(
 
 if ( errcode >= 0 )
 {
-struct segment_register reg;
 unsigned long linear_addr;
-regs->esp -= 4;
-hvm_get_segment_register(current, x86_seg_ss, );
-/* Todo: do not ignore access faults here. */
-if ( hvm_virtual_to_linear_addr(x86_seg_ss, , regs->esp,
-4, hvm_access_write, 32,
+unsigned int opsz, sp;
+
+hvm_get_segment_register(current, x86_seg_cs, );
+opsz = segr.attr.fields.db ? 4 : 2;
+hvm_get_segment_register(current, x86_seg_ss, );
+if ( segr.attr.fields.db )
+sp = regs->_esp -= opsz;
+else
+sp = *(uint16_t *)>esp -= opsz;
+if ( hvm_virtual_to_linear_addr(x86_seg_ss, , sp, opsz,
+hvm_access_write,
+16 << segr.attr.fields.db,
 _addr) )
-hvm_copy_to_guest_virt_nofault(linear_addr, , 4, 0);
+{
+rc = hvm_copy_to_guest_virt(linear_addr, , opsz, 0);
+if ( rc == HVMCOPY_bad_gva_to_gfn )
+exn_raised = 1;
+else if ( rc != HVMCOPY_okay )
+goto out;
+}
 }
 
+if ( (tss.trace & 1) && !exn_raised )
+hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
+
  out:
 hvm_unmap_entry(optss_desc);
 hvm_unmap_entry(nptss_desc);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/3] x86/HVM: limit writes to outgoing TSS during task switch

[Jan Beulich]

The only fields modified are EIP, EFLAGS, GPRs, and segment selectors.
CR3 in particular is not supposed to be updated.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2952,7 +2952,6 @@ void hvm_task_switch(
 if ( taskswitch_reason == TSW_iret )
 eflags &= ~X86_EFLAGS_NT;
 
-tss.cr3= v->arch.hvm_vcpu.guest_cr[3];
 tss.eip= regs->eip;
 tss.eflags = eflags;
 tss.eax= regs->eax;
@@ -2979,8 +2978,10 @@ void hvm_task_switch(
 hvm_get_segment_register(v, x86_seg_ldtr, );
 tss.ldt = segr.sel;
 
-rc = hvm_copy_to_guest_virt(
-prev_tr.base, , sizeof(tss), PFEC_page_present);
+rc = hvm_copy_to_guest_virt(prev_tr.base + offsetof(typeof(tss), eip),
+,
+(void *) - (void *),
+PFEC_page_present);
 if ( rc != HVMCOPY_okay )
 goto out;
 



x86/HVM: limit writes to outgoing TSS during task switch

The only fields modified are EIP, EFLAGS, GPRs, and segment selectors.
CR3 in particular is not supposed to be updated.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2952,7 +2952,6 @@ void hvm_task_switch(
 if ( taskswitch_reason == TSW_iret )
 eflags &= ~X86_EFLAGS_NT;
 
-tss.cr3= v->arch.hvm_vcpu.guest_cr[3];
 tss.eip= regs->eip;
 tss.eflags = eflags;
 tss.eax= regs->eax;
@@ -2979,8 +2978,10 @@ void hvm_task_switch(
 hvm_get_segment_register(v, x86_seg_ldtr, );
 tss.ldt = segr.sel;
 
-rc = hvm_copy_to_guest_virt(
-prev_tr.base, , sizeof(tss), PFEC_page_present);
+rc = hvm_copy_to_guest_virt(prev_tr.base + offsetof(typeof(tss), eip),
+,
+(void *) - (void *),
+PFEC_page_present);
 if ( rc != HVMCOPY_okay )
 goto out;
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [COVERITY ACCESS] for Embedded/Automotive team

[Artem Mygaiev]

On 22.11.16 15:42, Andrew Cooper wrote:
> On 22/11/16 11:55, Lars Kurth wrote:
>> On 22/11/2016 11:51, "Julien Grall"  wrote:
>>
>>> Hi Lars,
>>>
>>> On 19/11/16 16:53, Lars Kurth wrote:
 On 18/11/2016 20:55, "Julien Grall"  wrote:
> Coverity has been proven useful on x86 to catch some bugs. A such
> things
> would be nice for ARM too. Is there anything we can do to get coverity
> testing ARM? (CC Lars).
 Coverity does static code analysis. It analyses our entire tree,
 although
 I don't know whether we updated it to point it to new repos such as the
 mini-os one.
>>> I thought coverity was hooking into the build system by replacing the
>>> compiler, right?
>>>
>>> If so, how does coverity analyze xen/arch/arm?
>> I guess that is a question for someone else who is more familiar with the
>> set-up. But there shouldn't be any technical reason which prevents
>> Coverity scan from running on any CPU specific code.
> There is no technical problem with using Coverity for ARM.  Coverity, as
> a product, is capable of doing this.
>
> The problem is that Coverity Scan only offers us one stream for the Xen
> Project, and we cannot mix architectures within a single stream.  (Not
> that we physically can't, but that the change tracking of defects would
> be meaningless).
>
> The only way we could scan for ARM is if we could be given multiple
> different streams (one per arch) to use, and Coverity have already said
> no to this request.  This is a politics problem, not a technical problem.

Andrew, I understand, thanks.

Would it be still possible to get Scan model files for us? We would like
to update them for use with ARM. BTW, we could set up ARM build Coverity
Scan with GitHub/Travis only limited by amount of runs per week
(depending on number LOC number).

BR, Artem


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

[Xen-devel] [PATCH 1/3] x86/HVM: limit writes to incoming TSS during task switch

[Jan Beulich]

The only field modified (and even that conditionally) is the back link.
Write only that field, and only when it actually has been written to.

Take the opportunity and also ditch the pointless initializer from the
"tss" local variable.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2890,7 +2890,7 @@ void hvm_task_switch(
 u32 cr3, eip, eflags, eax, ecx, edx, ebx, esp, ebp, esi, edi;
 u16 es, _3, cs, _4, ss, _5, ds, _6, fs, _7, gs, _8, ldt, _9;
 u16 trace, iomap;
-} tss = { 0 };
+} tss;
 
 hvm_get_segment_register(v, x86_seg_gdtr, );
 hvm_get_segment_register(v, x86_seg_tr, _tr);
@@ -3010,12 +3010,6 @@ void hvm_task_switch(
 regs->esi= tss.esi;
 regs->edi= tss.edi;
 
-if ( (taskswitch_reason == TSW_call_or_int) )
-{
-regs->eflags |= X86_EFLAGS_NT;
-tss.back_link = prev_tr.sel;
-}
-
 exn_raised = 0;
 if ( hvm_load_segment_selector(x86_seg_es, tss.es, tss.eflags) ||
  hvm_load_segment_selector(x86_seg_cs, tss.cs, tss.eflags) ||
@@ -3025,12 +3019,18 @@ void hvm_task_switch(
  hvm_load_segment_selector(x86_seg_gs, tss.gs, tss.eflags) )
 exn_raised = 1;
 
-rc = hvm_copy_to_guest_virt(
-tr.base, , sizeof(tss), PFEC_page_present);
-if ( rc == HVMCOPY_bad_gva_to_gfn )
-exn_raised = 1;
-else if ( rc != HVMCOPY_okay )
-goto out;
+if ( taskswitch_reason == TSW_call_or_int )
+{
+regs->eflags |= X86_EFLAGS_NT;
+tss.back_link = prev_tr.sel;
+
+rc = hvm_copy_to_guest_virt(tr.base + offsetof(typeof(tss), back_link),
+_link, sizeof(tss.back_link), 0);
+if ( rc == HVMCOPY_bad_gva_to_gfn )
+exn_raised = 1;
+else if ( rc != HVMCOPY_okay )
+goto out;
+}
 
 if ( (tss.trace & 1) && !exn_raised )
 hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);



x86/HVM: limit writes to incoming TSS during task switch

The only field modified (and even that conditionally) is the back link.
Write only that field, and only when it actually has been written to.

Take the opportunity and also ditch the pointless initializer from the
"tss" local variable.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2890,7 +2890,7 @@ void hvm_task_switch(
 u32 cr3, eip, eflags, eax, ecx, edx, ebx, esp, ebp, esi, edi;
 u16 es, _3, cs, _4, ss, _5, ds, _6, fs, _7, gs, _8, ldt, _9;
 u16 trace, iomap;
-} tss = { 0 };
+} tss;
 
 hvm_get_segment_register(v, x86_seg_gdtr, );
 hvm_get_segment_register(v, x86_seg_tr, _tr);
@@ -3010,12 +3010,6 @@ void hvm_task_switch(
 regs->esi= tss.esi;
 regs->edi= tss.edi;
 
-if ( (taskswitch_reason == TSW_call_or_int) )
-{
-regs->eflags |= X86_EFLAGS_NT;
-tss.back_link = prev_tr.sel;
-}
-
 exn_raised = 0;
 if ( hvm_load_segment_selector(x86_seg_es, tss.es, tss.eflags) ||
  hvm_load_segment_selector(x86_seg_cs, tss.cs, tss.eflags) ||
@@ -3025,12 +3019,18 @@ void hvm_task_switch(
  hvm_load_segment_selector(x86_seg_gs, tss.gs, tss.eflags) )
 exn_raised = 1;
 
-rc = hvm_copy_to_guest_virt(
-tr.base, , sizeof(tss), PFEC_page_present);
-if ( rc == HVMCOPY_bad_gva_to_gfn )
-exn_raised = 1;
-else if ( rc != HVMCOPY_okay )
-goto out;
+if ( taskswitch_reason == TSW_call_or_int )
+{
+regs->eflags |= X86_EFLAGS_NT;
+tss.back_link = prev_tr.sel;
+
+rc = hvm_copy_to_guest_virt(tr.base + offsetof(typeof(tss), back_link),
+_link, sizeof(tss.back_link), 0);
+if ( rc == HVMCOPY_bad_gva_to_gfn )
+exn_raised = 1;
+else if ( rc != HVMCOPY_okay )
+goto out;
+}
 
 if ( (tss.trace & 1) && !exn_raised )
 hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 0/3] x86/HVM: XSA-192 follow-ups

[Jan Beulich]

1: limit writes to incoming TSS during task switch
2: limit writes to outgoing TSS during task switch
3: correct error code writing during task switch

Signed-off-by: Jan Beulich 


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

Re: [Xen-devel] Xen ARM community call

[Julien Grall]

Hello all,

Below an agenda for the call tomorrow:

* Round-table and introductions
* Features for the next release
* Stable tree maintenance
* Areas of concern

Regards,

On 18/11/16 16:07, Julien Grall wrote:

Hello all,

Based on the timezone given by each of you, the best time seems to be:

Wednesday 23rd November at 4pm UTC.

I will post an agenda beginning of next week.

Use either of the following to join the call:
Call+44 1223 406065 (Local dial in)
and enter the access code below followed by # key.
Participant code: 4915191

Mobile Auto Dial:
VoIP: voip://+441223406065;4915191#
iOS devices: +44 1223 406065,4915191 and press #
Other devices: +44 1223 406065x4915191#

Additional Calling Information:

UK +44 1142828002
US CA +1 4085761502
US TX +1 5123141073
JP +81 453455355
DE +49 8945604050
NO +47 73187518
SE +46 46313131
FR +33 497235101
TW +886 35657119
HU +36 13275600
IE +353 91337900

Toll Free

UK 0800 1412084
US +1 8668801148
CN +86 4006782367
IN 0008009868365
IN +918049282778
TW 08000 22065
HU 0680981587
IE 1800800022
KF +972732558877

Regards,

On 08/11/2016 06:19, Julien Grall wrote:

Hi all,

I would like to start organizing a recurring community call to discuss
and sync-up on upcoming features for Xen ARM.

Example of features that could be discussed:
- Sharing co-processor between guests
- PCI passthrough

I would suggest to start with a 1 hour meeting on the Wednesday 23rd
November. I know that people are spread across different timezones, so I
would like to gather thought before choosing a time.

Your sincerely,





--
Julien Grall

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

Re: [Xen-devel] [COVERITY ACCESS] for Embedded/Automotive team

[Andrew Cooper]

On 22/11/16 11:55, Lars Kurth wrote:
>
> On 22/11/2016 11:51, "Julien Grall"  wrote:
>
>> Hi Lars,
>>
>> On 19/11/16 16:53, Lars Kurth wrote:
>>> On 18/11/2016 20:55, "Julien Grall"  wrote:
 Coverity has been proven useful on x86 to catch some bugs. A such
 things
 would be nice for ARM too. Is there anything we can do to get coverity
 testing ARM? (CC Lars).
>>> Coverity does static code analysis. It analyses our entire tree,
>>> although
>>> I don't know whether we updated it to point it to new repos such as the
>>> mini-os one.
>> I thought coverity was hooking into the build system by replacing the
>> compiler, right?
>>
>> If so, how does coverity analyze xen/arch/arm?
> I guess that is a question for someone else who is more familiar with the
> set-up. But there shouldn't be any technical reason which prevents
> Coverity scan from running on any CPU specific code.

There is no technical problem with using Coverity for ARM.  Coverity, as
a product, is capable of doing this.

The problem is that Coverity Scan only offers us one stream for the Xen
Project, and we cannot mix architectures within a single stream.  (Not
that we physically can't, but that the change tracking of defects would
be meaningless).

The only way we could scan for ARM is if we could be given multiple
different streams (one per arch) to use, and Coverity have already said
no to this request.  This is a politics problem, not a technical problem.

~Andrew

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