Re: [Xen-devel] [PATCH 11/28] ARM: GICv3: forward pending LPIs to guests

[Jan Beulich]

>>> On 02.03.17 at 21:56,  wrote:
> Ping? I'd like the question to be sorted out before Andre is sending a 
> new version.
> 
> On 02/15/2017 09:25 PM, Stefano Stabellini wrote:
>> On Wed, 15 Feb 2017, Julien Grall wrote:
>>> Hi Stefano,
>>>
>>> On 14/02/17 21:00, Stefano Stabellini wrote:
 On Mon, 30 Jan 2017, Andre Przywara wrote:
> +/*
> + * Handle incoming LPIs, which are a bit special, because they are
> potentially
> + * numerous and also only get injected into guests. Treat them specially
> here,
> + * by just looking up their target vCPU and virtual LPI number and hand
> it
> + * over to the injection function.
> + */
> +void do_LPI(unsigned int lpi)
> +{
> +struct domain *d;
> +union host_lpi *hlpip, hlpi;
> +struct vcpu *vcpu;
> +
> +WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
> +
> +hlpip = gic_get_host_lpi(lpi);
> +if ( !hlpip )
> +return;
> +
> +hlpi.data = read_u64_atomic(>data);
> +
> +/* We may have mapped more host LPIs than the guest actually asked
> for. */
> +if ( !hlpi.virt_lpi )
> +return;
> +
> +d = get_domain_by_id(hlpi.dom_id);
> +if ( !d )
> +return;
> +
> +if ( hlpi.vcpu_id >= d->max_vcpus )
> +{
> +put_domain(d);
> +return;
> +}
> +
> +vcpu = d->vcpu[hlpi.vcpu_id];
> +
> +put_domain(d);
> +
> +vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);

 put_domain should be here
>>>
>>> Why? I don't even understand why we would need to take a reference on the
>>> domain for LPIs. Would not it be enough to use rcu_lock_domain_by_id here?
>>
>> I think that rcu_lock_domain_by_id would also work, but similarly we
>> would need to call rcu_unlock here.
>>
>> To be honest, I don't know exactly in which cases get_domain should be
>> used instead of rcu_lock_domain_by_id.

Aiui get_domain() is needed when you want to retain the reference
across an operation that may involved blocking/scheduling. The RCU
variant should be sufficient whenever you only need to make sure
the domain won't go away for the duration of (a portion of) a
function, since final domain destruction gets carried out from an
RCU callback.

Jan


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

Re: [Xen-devel] [PATCH] xen/arm: fix affected memory range by dcache clean functions

[Edgar E. Iglesias]

On Thu, Mar 02, 2017 at 05:15:26PM -0800, Stefano Stabellini wrote:
> clean_dcache_va_range and clean_and_invalidate_dcache_va_range don't
> calculate the range correctly when "end" is not cacheline aligned. As a
> result, the last cacheline is not skipped. Fix the issue by aligning the
> start address to the cacheline size.
> 
> In addition, make the code simpler and faster in
> invalidate_dcache_va_range, by removing the module operation and using
> bitmasks instead.
> 
> Signed-off-by: Stefano Stabellini 
> Reported-by: edgar.igles...@xilinx.com
> CC: edgar.igles...@xilinx.com

This looks good to me and it works on my side.
In the future, perhaps we could convert invalidate_dcache_va_range
to use a smaller implementation like clean_dcache_va_range().

Anyway:
Reviewed-by: Edgar E. Iglesias 
Tested-by: Edgar E. Iglesias 

And super thanks for helping me resolve this issue!

Cheers,
Edgar


> ---
>  xen/include/asm-arm/page.h | 24 +++-
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 86de0b6..4b46e88 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -291,24 +291,20 @@ extern size_t cacheline_bytes;
>  
>  static inline int invalidate_dcache_va_range(const void *p, unsigned long 
> size)
>  {
> -size_t off;
>  const void *end = p + size;
> +size_t cacheline_mask = cacheline_bytes - 1;
>  
>  dsb(sy);   /* So the CPU issues all writes to the range */
>  
> -off = (unsigned long)p % cacheline_bytes;
> -if ( off )
> +if ( (uintptr_t)p & cacheline_mask )
>  {
> -p -= off;
> +p = (void *)((uintptr_t)p & ~cacheline_mask);
>  asm volatile (__clean_and_invalidate_dcache_one(0) : : "r" (p));
>  p += cacheline_bytes;
> -size -= cacheline_bytes - off;
>  }
> -off = (unsigned long)end % cacheline_bytes;
> -if ( off )
> +if ( (uintptr_t)end & cacheline_mask )
>  {
> -end -= off;
> -size -= off;
> +end = (void *)((uintptr_t)end & ~cacheline_mask);
>  asm volatile (__clean_and_invalidate_dcache_one(0) : : "r" (end));
>  }
>  
> @@ -322,9 +318,10 @@ static inline int invalidate_dcache_va_range(const void 
> *p, unsigned long size)
>  
>  static inline int clean_dcache_va_range(const void *p, unsigned long size)
>  {
> -const void *end;
> +const void *end = p + size;
>  dsb(sy);   /* So the CPU issues all writes to the range */
> -for ( end = p + size; p < end; p += cacheline_bytes )
> +p = (void *)((uintptr_t)p & ~(cacheline_bytes - 1));
> +for ( ; p < end; p += cacheline_bytes )
>  asm volatile (__clean_dcache_one(0) : : "r" (p));
>  dsb(sy);   /* So we know the flushes happen before continuing */
>  /* ARM callers assume that dcache_* functions cannot fail. */
> @@ -334,9 +331,10 @@ static inline int clean_dcache_va_range(const void *p, 
> unsigned long size)
>  static inline int clean_and_invalidate_dcache_va_range
>  (const void *p, unsigned long size)
>  {
> -const void *end;
> +const void *end = p + size;
>  dsb(sy); /* So the CPU issues all writes to the range */
> -for ( end = p + size; p < end; p += cacheline_bytes )
> +p = (void *)((uintptr_t)p & ~(cacheline_bytes - 1));
> +for ( ; p < end; p += cacheline_bytes )
>  asm volatile (__clean_and_invalidate_dcache_one(0) : : "r" (p));
>  dsb(sy); /* So we know the flushes happen before continuing */
>  /* ARM callers assume that dcache_* functions cannot fail. */
> -- 
> 1.9.1
> 

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

[Xen-devel] [seabios test] 106381: tolerable FAIL - PUSHED

[osstest service owner]

flight 106381 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106381/

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 seabios  1415d46dc87fd8bf1d6acd97c1ad60e893f62523
baseline version:
 seabios  6bc4164cc8570ed3140d34080e38878adce13593

Last test of basis   106372  2017-03-02 14:44:18 Z0 days
Testing same since   106381  2017-03-02 21:15:29 Z0 days1 attempts


People who touched revisions under test:
  Daniel Verkamp 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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=seabios
+ revision=1415d46dc87fd8bf1d6acd97c1ad60e893f62523
+ . ./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 seabios 
1415d46dc87fd8bf1d6acd97c1ad60e893f62523
+ branch=seabios
+ revision=1415d46dc87fd8bf1d6acd97c1ad60e893f62523
+ . ./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=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' 

[Xen-devel] [qemu-mainline test] 106377: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt  3 host-install(3)broken REGR. vs. 106356
 test-armhf-armhf-xl-vhd   3 host-install(3)broken REGR. vs. 106356

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

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

version targeted for testing:
 qemuuc9fc677a35e6e00cdf00c7d085cbd74e0b90b2e6
baseline version:
 qemuu1e0addb682c3c552fd97480037d4f8ff18e2b87e

Last test of basis   106356  2017-03-02 07:03:28 Z0 days
Testing same since   106377  2017-03-02 18:18:07 Z0 days1 attempts


People who touched revisions under test:
  Alexey Kardashevskiy 
  Christian Borntraeger 
  Cédric Le Goater 
  David Gibson 
  Eduardo Habkost 
  Fam Zheng 
  Gerd Hoffmann 
  Greg Kurz 
  Greg Kurz 
  Igor Mammedov 
  Jiri Denemark 
  Kevin Wolf 
  Laurent Vivier 
  Marc-André Lureau 
  Mark Cave-Ayland 

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf a11928f3310518ab1c6fd34e8d0fdbb72de9602c
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z9 days
Failing since105980  2017-02-22 10:03:53 Z8 days   23 attempts
Testing same since   106378  2017-03-02 18:45:27 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Brijesh Singh 
  Chen A Chen 
  Dandan Bi 
  edk2-devel On Behalf Of rthomaiy <[mailto:edk2-devel-boun...@lists.01.org]>
  Fu Siyuan 
  Hao Wu 
  Hegde Nagaraj P 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leo Duran 
  Paolo Bonzini 
  Qin Long 
  Richard Thomaiyar 
  Ruiyu Ni 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 

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



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

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

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

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


Not pushing.

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

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

[Xen-devel] [linux-linus test] 106375: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linux4977ab6e92e267afe9d8f78438c3db330ca8434c
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  602 days
Failing since 59348  2015-07-10 04:24:05 Z  601 days  307 attempts
Testing same since   106354  2017-03-02 05:52:12 Z0 days2 attempts


8028 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 

[Xen-devel] [PATCH] xen/arm: fix affected memory range by dcache clean functions

[Stefano Stabellini]

clean_dcache_va_range and clean_and_invalidate_dcache_va_range don't
calculate the range correctly when "end" is not cacheline aligned. As a
result, the last cacheline is not skipped. Fix the issue by aligning the
start address to the cacheline size.

In addition, make the code simpler and faster in
invalidate_dcache_va_range, by removing the module operation and using
bitmasks instead.

Signed-off-by: Stefano Stabellini 
Reported-by: edgar.igles...@xilinx.com
CC: edgar.igles...@xilinx.com
---
 xen/include/asm-arm/page.h | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 86de0b6..4b46e88 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -291,24 +291,20 @@ extern size_t cacheline_bytes;
 
 static inline int invalidate_dcache_va_range(const void *p, unsigned long size)
 {
-size_t off;
 const void *end = p + size;
+size_t cacheline_mask = cacheline_bytes - 1;
 
 dsb(sy);   /* So the CPU issues all writes to the range */
 
-off = (unsigned long)p % cacheline_bytes;
-if ( off )
+if ( (uintptr_t)p & cacheline_mask )
 {
-p -= off;
+p = (void *)((uintptr_t)p & ~cacheline_mask);
 asm volatile (__clean_and_invalidate_dcache_one(0) : : "r" (p));
 p += cacheline_bytes;
-size -= cacheline_bytes - off;
 }
-off = (unsigned long)end % cacheline_bytes;
-if ( off )
+if ( (uintptr_t)end & cacheline_mask )
 {
-end -= off;
-size -= off;
+end = (void *)((uintptr_t)end & ~cacheline_mask);
 asm volatile (__clean_and_invalidate_dcache_one(0) : : "r" (end));
 }
 
@@ -322,9 +318,10 @@ static inline int invalidate_dcache_va_range(const void 
*p, unsigned long size)
 
 static inline int clean_dcache_va_range(const void *p, unsigned long size)
 {
-const void *end;
+const void *end = p + size;
 dsb(sy);   /* So the CPU issues all writes to the range */
-for ( end = p + size; p < end; p += cacheline_bytes )
+p = (void *)((uintptr_t)p & ~(cacheline_bytes - 1));
+for ( ; p < end; p += cacheline_bytes )
 asm volatile (__clean_dcache_one(0) : : "r" (p));
 dsb(sy);   /* So we know the flushes happen before continuing */
 /* ARM callers assume that dcache_* functions cannot fail. */
@@ -334,9 +331,10 @@ static inline int clean_dcache_va_range(const void *p, 
unsigned long size)
 static inline int clean_and_invalidate_dcache_va_range
 (const void *p, unsigned long size)
 {
-const void *end;
+const void *end = p + size;
 dsb(sy); /* So the CPU issues all writes to the range */
-for ( end = p + size; p < end; p += cacheline_bytes )
+p = (void *)((uintptr_t)p & ~(cacheline_bytes - 1));
+for ( ; p < end; p += cacheline_bytes )
 asm volatile (__clean_and_invalidate_dcache_one(0) : : "r" (p));
 dsb(sy); /* So we know the flushes happen before continuing */
 /* ARM callers assume that dcache_* functions cannot fail. */
-- 
1.9.1


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

Re: [Xen-devel] xen/arm and swiotlb-xen: possible data corruption

[Stefano Stabellini]

On Thu, 2 Mar 2017, Julien Grall wrote:
> On 02/03/2017 22:39, Stefano Stabellini wrote:
> > On Thu, 2 Mar 2017, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 02/03/17 19:12, Stefano Stabellini wrote:
> > > > On Thu, 2 Mar 2017, Julien Grall wrote:
> > > > > On 02/03/17 08:53, Edgar E. Iglesias wrote:
> > > > > > On Thu, Mar 02, 2017 at 09:38:37AM +0100, Edgar E. Iglesias wrote:
> > > > > > > On Wed, Mar 01, 2017 at 05:05:21PM -0800, Stefano Stabellini
> > > > > > > wrote:
> > > > Julien, from looking at the two diffs, this is simpler and nicer, but if
> > > > you look at xen/include/asm-arm/page.h, my patch made
> > > > clean_dcache_va_range consistent with invalidate_dcache_va_range. For
> > > > consistency, I would prefer to deal with the two functions the same way.
> > > > Although it is not a spec requirement, I also think that it is a good
> > > > idea to issue cache flushes from cacheline aligned addresses, like
> > > > invalidate_dcache_va_range does and Linux does, to make more obvious
> > > > what is going on.
> > > 
> > > invalid_dcache_va_range is split because the cache instruction differs for
> > > the
> > > start and end if unaligned. For them you want to use clean & invalidate
> > > rather
> > > than invalidate.
> > > 
> > > If you look at the implementation of other cache helpers in Linux (see
> > > dcache_by_line_op in arch/arm64/include/asm/assembler.h), they will only
> > > align
> > > start & end.
> > 
> > I don't think so, unless I am reading dcache_by_line_op wrong.
> 
> 343 .macro dcache_by_line_op op, domain, kaddr, size, tmp1, tmp2
> 344 dcache_line_size \tmp1, \tmp2
> 345 add \size, \kaddr, \size
> 346 sub \tmp2, \tmp1, #1
> 347 bic \kaddr, \kaddr, \tmp2
> 348 9998:
> 349 .if (\op == cvau || \op == cvac)
> 350 alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
> 351 dc  \op, \kaddr
> 352 alternative_else
> 353 dc  civac, \kaddr
> 354 alternative_endif
> 355 .else
> 356 dc  \op, \kaddr
> 357 .endif
> 358 add \kaddr, \kaddr, \tmp1
> 359 cmp \kaddr, \size
> 360 b.lo9998b
> 361 dsb \domain
> 362 .endm
> 363
> 
> It has only one cache instruction in the resulting assembly because it has
> .if/.else assembly directives.

Yes, but it does not only align start and end, all cache instructions
are called on aligned addresses, right?

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

Re: [Xen-devel] xen/arm and swiotlb-xen: possible data corruption

[Julien Grall]

On 02/03/2017 23:07, Stefano Stabellini wrote:

On Thu, 2 Mar 2017, Edgar E. Iglesias wrote:

On Thu, Mar 02, 2017 at 02:39:55PM -0800, Stefano Stabellini wrote:

On Thu, 2 Mar 2017, Julien Grall wrote:

Hi Stefano,

On 02/03/17 19:12, Stefano Stabellini wrote:

On Thu, 2 Mar 2017, Julien Grall wrote:

On 02/03/17 08:53, Edgar E. Iglesias wrote:

On Thu, Mar 02, 2017 at 09:38:37AM +0100, Edgar E. Iglesias wrote:

On Wed, Mar 01, 2017 at 05:05:21PM -0800, Stefano Stabellini wrote:

Julien, from looking at the two diffs, this is simpler and nicer, but if
you look at xen/include/asm-arm/page.h, my patch made
clean_dcache_va_range consistent with invalidate_dcache_va_range. For
consistency, I would prefer to deal with the two functions the same way.
Although it is not a spec requirement, I also think that it is a good
idea to issue cache flushes from cacheline aligned addresses, like
invalidate_dcache_va_range does and Linux does, to make more obvious
what is going on.


invalid_dcache_va_range is split because the cache instruction differs for the
start and end if unaligned. For them you want to use clean & invalidate rather
than invalidate.

If you look at the implementation of other cache helpers in Linux (see
dcache_by_line_op in arch/arm64/include/asm/assembler.h), they will only align
start & end.


I don't think so, unless I am reading dcache_by_line_op wrong.



Also, the invalid_dcache_va_range is using modulo which I would rather avoid.
The modulo in this case will not be optimized by the compiler because
cacheline_bytes is not a constant.


That is a good point. What if I replace the modulo op with

  p & (cacheline_bytes - 1)

in invalidate_dcache_va_range, then add the similar code to
clean_dcache_va_range and clean_and_invalidate_dcache_va_range?



Yeah, if there was some kind of generic ALIGN or ROUND_DOWN macro we could do:

--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -325,7 +325,9 @@ static inline int clean_dcache_va_range(const void *p, 
unsigned long size)
 {
 const void *end;
 dsb(sy);   /* So the CPU issues all writes to the range */
-for ( end = p + size; p < end; p += cacheline_bytes )
+
+p = (void *)ALIGN((uintptr_t)p, cacheline_bytes);
+end = (void *)ROUNDUP((uintptr_t)p + size, cacheline_bytes);


Even simpler:

   end = p + size;
   p = (void *)ALIGN((uintptr_t)p, cacheline_bytes);


We don't have any ALIGN macro in Xen and the way we use the term align 
in xen is very similar to ROUNDUP.


However a simple p = (void *)((uintptr_t)p & ~(cacheline_bytes - 1)) 
should work here.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] xen/arm and swiotlb-xen: possible data corruption

[Julien Grall]

On 02/03/2017 22:39, Stefano Stabellini wrote:

On Thu, 2 Mar 2017, Julien Grall wrote:

Hi Stefano,

On 02/03/17 19:12, Stefano Stabellini wrote:

On Thu, 2 Mar 2017, Julien Grall wrote:

On 02/03/17 08:53, Edgar E. Iglesias wrote:

On Thu, Mar 02, 2017 at 09:38:37AM +0100, Edgar E. Iglesias wrote:

On Wed, Mar 01, 2017 at 05:05:21PM -0800, Stefano Stabellini wrote:

Julien, from looking at the two diffs, this is simpler and nicer, but if
you look at xen/include/asm-arm/page.h, my patch made
clean_dcache_va_range consistent with invalidate_dcache_va_range. For
consistency, I would prefer to deal with the two functions the same way.
Although it is not a spec requirement, I also think that it is a good
idea to issue cache flushes from cacheline aligned addresses, like
invalidate_dcache_va_range does and Linux does, to make more obvious
what is going on.


invalid_dcache_va_range is split because the cache instruction differs for the
start and end if unaligned. For them you want to use clean & invalidate rather
than invalidate.

If you look at the implementation of other cache helpers in Linux (see
dcache_by_line_op in arch/arm64/include/asm/assembler.h), they will only align
start & end.


I don't think so, unless I am reading dcache_by_line_op wrong.


343 .macro dcache_by_line_op op, domain, kaddr, size, tmp1, tmp2
344 dcache_line_size \tmp1, \tmp2
345 add \size, \kaddr, \size
346 sub \tmp2, \tmp1, #1
347 bic \kaddr, \kaddr, \tmp2
348 9998:
349 .if (\op == cvau || \op == cvac)
350 alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
351 dc  \op, \kaddr
352 alternative_else
353 dc  civac, \kaddr
354 alternative_endif
355 .else
356 dc  \op, \kaddr
357 .endif
358 add \kaddr, \kaddr, \tmp1
359 cmp \kaddr, \size
360 b.lo9998b
361 dsb \domain
362 .endm
363

It has only one cache instruction in the resulting assembly because it 
has .if/.else assembly directives.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] xen/arm and swiotlb-xen: possible data corruption

[Stefano Stabellini]

On Thu, 2 Mar 2017, Edgar E. Iglesias wrote:
> On Thu, Mar 02, 2017 at 02:39:55PM -0800, Stefano Stabellini wrote:
> > On Thu, 2 Mar 2017, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 02/03/17 19:12, Stefano Stabellini wrote:
> > > > On Thu, 2 Mar 2017, Julien Grall wrote:
> > > > > On 02/03/17 08:53, Edgar E. Iglesias wrote:
> > > > > > On Thu, Mar 02, 2017 at 09:38:37AM +0100, Edgar E. Iglesias wrote:
> > > > > > > On Wed, Mar 01, 2017 at 05:05:21PM -0800, Stefano Stabellini 
> > > > > > > wrote:
> > > > Julien, from looking at the two diffs, this is simpler and nicer, but if
> > > > you look at xen/include/asm-arm/page.h, my patch made
> > > > clean_dcache_va_range consistent with invalidate_dcache_va_range. For
> > > > consistency, I would prefer to deal with the two functions the same way.
> > > > Although it is not a spec requirement, I also think that it is a good
> > > > idea to issue cache flushes from cacheline aligned addresses, like
> > > > invalidate_dcache_va_range does and Linux does, to make more obvious
> > > > what is going on.
> > > 
> > > invalid_dcache_va_range is split because the cache instruction differs 
> > > for the
> > > start and end if unaligned. For them you want to use clean & invalidate 
> > > rather
> > > than invalidate.
> > > 
> > > If you look at the implementation of other cache helpers in Linux (see
> > > dcache_by_line_op in arch/arm64/include/asm/assembler.h), they will only 
> > > align
> > > start & end.
> > 
> > I don't think so, unless I am reading dcache_by_line_op wrong.
> > 
> > 
> > > Also, the invalid_dcache_va_range is using modulo which I would rather 
> > > avoid.
> > > The modulo in this case will not be optimized by the compiler because
> > > cacheline_bytes is not a constant.
> > 
> > That is a good point. What if I replace the modulo op with
> > 
> >   p & (cacheline_bytes - 1)
> > 
> > in invalidate_dcache_va_range, then add the similar code to
> > clean_dcache_va_range and clean_and_invalidate_dcache_va_range?
> 
> 
> Yeah, if there was some kind of generic ALIGN or ROUND_DOWN macro we could do:
> 
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -325,7 +325,9 @@ static inline int clean_dcache_va_range(const void *p, 
> unsigned long size)
>  {
>  const void *end;
>  dsb(sy);   /* So the CPU issues all writes to the range */
> -for ( end = p + size; p < end; p += cacheline_bytes )
> +
> +p = (void *)ALIGN((uintptr_t)p, cacheline_bytes);
> +end = (void *)ROUNDUP((uintptr_t)p + size, cacheline_bytes);

Even simpler:

   end = p + size;
   p = (void *)ALIGN((uintptr_t)p, cacheline_bytes);


> +for ( ; p < end; p += cacheline_bytes )
>  asm volatile (__clean_dcache_one(0) : : "r" (p));
>  dsb(sy);   /* So we know the flushes happen before continuing */
>  /* ARM callers assume that dcache_* functions cannot fail. */
> 
> I think that would achieve the same result as your patch Stefano?

Yes, indeed, that's better.

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

[Xen-devel] [PATCH] xen-netback: fix race condition on XenBus disconnect

[Igor Druzhinin]

In some cases during XenBus disconnect event handling and subsequent
queue resource release there may be some TX handlers active on
other processors. Use RCU in order to synchronize with them.

Signed-off-by: Igor Druzhinin 
---
 drivers/net/xen-netback/interface.c | 13 -
 drivers/net/xen-netback/xenbus.c| 17 +++--
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index a2d32676..32e2cc6 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -164,7 +164,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
 {
struct xenvif *vif = netdev_priv(dev);
struct xenvif_queue *queue = NULL;
-   unsigned int num_queues = vif->num_queues;
+   unsigned int num_queues = rcu_dereference(vif)->num_queues;
u16 index;
struct xenvif_rx_cb *cb;
 
@@ -221,18 +221,21 @@ static struct net_device_stats *xenvif_get_stats(struct 
net_device *dev)
 {
struct xenvif *vif = netdev_priv(dev);
struct xenvif_queue *queue = NULL;
+   unsigned int num_queues;
u64 rx_bytes = 0;
u64 rx_packets = 0;
u64 tx_bytes = 0;
u64 tx_packets = 0;
unsigned int index;
 
-   spin_lock(>lock);
-   if (vif->queues == NULL)
+   rcu_read_lock();
+
+   num_queues = rcu_dereference(vif)->num_queues;
+   if (num_queues < 1)
goto out;
 
/* Aggregate tx and rx stats from each queue */
-   for (index = 0; index < vif->num_queues; ++index) {
+   for (index = 0; index < num_queues; ++index) {
queue = >queues[index];
rx_bytes += queue->stats.rx_bytes;
rx_packets += queue->stats.rx_packets;
@@ -241,7 +244,7 @@ static struct net_device_stats *xenvif_get_stats(struct 
net_device *dev)
}
 
 out:
-   spin_unlock(>lock);
+   rcu_read_unlock();
 
vif->dev->stats.rx_bytes = rx_bytes;
vif->dev->stats.rx_packets = rx_packets;
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index d2d7cd9..76efb01 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -495,26 +495,23 @@ static void backend_disconnect(struct backend_info *be)
struct xenvif *vif = be->vif;
 
if (vif) {
+   unsigned int num_queues = vif->num_queues;
unsigned int queue_index;
-   struct xenvif_queue *queues;
 
xen_unregister_watchers(vif);
 #ifdef CONFIG_DEBUG_FS
xenvif_debugfs_delif(vif);
 #endif /* CONFIG_DEBUG_FS */
xenvif_disconnect_data(vif);
-   for (queue_index = 0;
-queue_index < vif->num_queues;
-++queue_index)
-   xenvif_deinit_queue(>queues[queue_index]);
 
-   spin_lock(>lock);
-   queues = vif->queues;
vif->num_queues = 0;
-   vif->queues = NULL;
-   spin_unlock(>lock);
+   synchronize_net();
 
-   vfree(queues);
+   for (queue_index = 0; queue_index < num_queues; ++queue_index)
+   xenvif_deinit_queue(>queues[queue_index]);
+
+   vfree(vif->queues);
+   vif->queues = NULL;
 
xenvif_disconnect_ctrl(vif);
}
-- 
1.8.3.1


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

Re: [Xen-devel] xen/arm and swiotlb-xen: possible data corruption

[Edgar E. Iglesias]

On Thu, Mar 02, 2017 at 02:39:55PM -0800, Stefano Stabellini wrote:
> On Thu, 2 Mar 2017, Julien Grall wrote:
> > Hi Stefano,
> > 
> > On 02/03/17 19:12, Stefano Stabellini wrote:
> > > On Thu, 2 Mar 2017, Julien Grall wrote:
> > > > On 02/03/17 08:53, Edgar E. Iglesias wrote:
> > > > > On Thu, Mar 02, 2017 at 09:38:37AM +0100, Edgar E. Iglesias wrote:
> > > > > > On Wed, Mar 01, 2017 at 05:05:21PM -0800, Stefano Stabellini wrote:
> > > Julien, from looking at the two diffs, this is simpler and nicer, but if
> > > you look at xen/include/asm-arm/page.h, my patch made
> > > clean_dcache_va_range consistent with invalidate_dcache_va_range. For
> > > consistency, I would prefer to deal with the two functions the same way.
> > > Although it is not a spec requirement, I also think that it is a good
> > > idea to issue cache flushes from cacheline aligned addresses, like
> > > invalidate_dcache_va_range does and Linux does, to make more obvious
> > > what is going on.
> > 
> > invalid_dcache_va_range is split because the cache instruction differs for 
> > the
> > start and end if unaligned. For them you want to use clean & invalidate 
> > rather
> > than invalidate.
> > 
> > If you look at the implementation of other cache helpers in Linux (see
> > dcache_by_line_op in arch/arm64/include/asm/assembler.h), they will only 
> > align
> > start & end.
> 
> I don't think so, unless I am reading dcache_by_line_op wrong.
> 
> 
> > Also, the invalid_dcache_va_range is using modulo which I would rather 
> > avoid.
> > The modulo in this case will not be optimized by the compiler because
> > cacheline_bytes is not a constant.
> 
> That is a good point. What if I replace the modulo op with
> 
>   p & (cacheline_bytes - 1)
> 
> in invalidate_dcache_va_range, then add the similar code to
> clean_dcache_va_range and clean_and_invalidate_dcache_va_range?


Yeah, if there was some kind of generic ALIGN or ROUND_DOWN macro we could do:

--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -325,7 +325,9 @@ static inline int clean_dcache_va_range(const void *p, 
unsigned long size)
 {
 const void *end;
 dsb(sy);   /* So the CPU issues all writes to the range */
-for ( end = p + size; p < end; p += cacheline_bytes )
+
+p = (void *)ALIGN((uintptr_t)p, cacheline_bytes);
+end = (void *)ROUNDUP((uintptr_t)p + size, cacheline_bytes);
+for ( ; p < end; p += cacheline_bytes )
 asm volatile (__clean_dcache_one(0) : : "r" (p));
 dsb(sy);   /* So we know the flushes happen before continuing */
 /* ARM callers assume that dcache_* functions cannot fail. */

I think that would achieve the same result as your patch Stefano?

Cheers,
Edgar


> 
> 
> > BTW, you would also need to fix clean_and_invalidate_dcache_va_range.
> 
> I'll do that, thanks for the reminder.

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

Re: [Xen-devel] [PATCH v2 5/5] xen: use libxendevicemodel when available

[Stefano Stabellini]

On Thu, 2 Mar 2017, Paul Durrant wrote:
> This patch modifies the wrapper functions in xen_common.h to use the
> new xendevicemodel interface if it is available along with compatibility
> code to use the old libxenctrl interface if it is not.
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> 
> v2:
> - Add a compat define for xenforeignmemory_close() since this is now
>   used.
> ---
>  include/hw/xen/xen_common.h | 115 
> +++-
>  xen-common.c|   8 +++
>  2 files changed, 90 insertions(+), 33 deletions(-)
> 
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 31cf25f..48444e5 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -9,6 +9,7 @@
>  #undef XC_WANT_COMPAT_EVTCHN_API
>  #undef XC_WANT_COMPAT_GNTTAB_API
>  #undef XC_WANT_COMPAT_MAP_FOREIGN_API
> +#undef XC_WANT_COMPAT_DEVICEMODEL_API
>  
>  #include 
>  #include 
> @@ -26,48 +27,95 @@ extern xc_interface *xen_xc;
>   * We don't support Xen prior to 4.2.0.
>   */
>  
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490
> +
> +typedef xc_interface xendevicemodel_handle;
> +
> +#define xendevicemodel_open(l, f) xen_xc
> +
> +#define xendevicemodel_map_io_range_to_ioreq_server \
> +xc_hvm_map_io_range_to_ioreq_server
> +#define xendevicemodel_unmap_io_range_from_ioreq_server \
> +xc_hvm_unmap_io_range_from_ioreq_server
> +#define xendevicemodel_map_pcidev_to_ioreq_server \
> +xc_hvm_map_pcidev_to_ioreq_server
> +#define xendevicemodel_unmap_pcidev_from_ioreq_server \
> +xc_hvm_unmap_pcidev_from_ioreq_server
> +#define xendevicemodel_create_ioreq_server \
> +xc_hvm_create_ioreq_server
> +#define xendevicemodel_destroy_ioreq_server \
> +xc_hvm_destroy_ioreq_server
> +#define xendevicemodel_get_ioreq_server_info \
> +xc_hvm_get_ioreq_server_info
> +#define xendevicemodel_set_ioreq_server_state \
> +xc_hvm_set_ioreq_server_state
> +#define xendevicemodel_set_pci_intx_level \
> +xc_hvm_set_pci_intx_level
> +#define xendevicemodel_set_pci_link_route \
> +xc_hvm_set_pci_link_route
> +#define xendevicemodel_set_isa_irq_level \
> +xc_hvm_set_isa_irq_level
> +#define xendevicemodel_inject_msi \
> +xc_hvm_inject_msi
> +#define xendevicemodel_set_mem_type \
> +xc_hvm_set_mem_type
> +#define xendevicemodel_track_dirty_vram \
> +xc_hvm_track_dirty_vram
> +#define xendevicemodel_modified_memory \
> +xc_hvm_modified_memory

It does build correctly now for Xen < 4.9, however it breaks against
xen-unstable:

  ERROR: configure test passed without -Werror but failed with -Werror.
 This is probably a bug in the configure script. The failing command
 will be at the bottom of config.log.
 You can run configure with --disable-werror to bypass this check.

and config.log says:

  config-temp/qemu-conf.c: In function 'main':
  config-temp/qemu-conf.c:32:3: error: implicit declaration of function 
'xc_hvm_set_mem_type' [-Werror=implicit-function-declaration]
  config-temp/qemu-conf.c:32:3: error: nested extern declaration of 
'xc_hvm_set_mem_type' [-Werror=nested-externs]
  config-temp/qemu-conf.c:34:3: error: implicit declaration of function 
'xc_hvm_inject_msi' [-Werror=implicit-function-declaration]
  config-temp/qemu-conf.c:34:3: error: nested extern declaration of 
'xc_hvm_inject_msi' [-Werror=nested-externs]
  config-temp/qemu-conf.c:35:3: error: implicit declaration of function 
'xc_hvm_create_ioreq_server' [-Werror=implicit-function-declaration]
  config-temp/qemu-conf.c:35:3: error: nested extern declaration of 
'xc_hvm_create_ioreq_server' [-Werror=nested-externs]


With -DXC_WANT_COMPAT_DEVICEMODEL_API=1:

  In file included from /local/qemu-upstream/include/hw/xen/xen_backend.h:4:0,
   from hw/block/xen_disk.c:27:
  /local/qemu-upstream/include/hw/xen/xen_common.h: In function 
'xen_set_mem_type':
  /local/qemu-upstream/include/hw/xen/xen_common.h:78:5: error: implicit 
declaration of function 'xc_hvm_set_mem_type' 
[-Werror=implicit-function-declaration]


Only another comment (I guess you didn't see in my previous email):
could you please use static inline functions for compatibility rather
than macros? That way we are going to have some more compile time
checks. Or at least macros with parameters.


> +#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 490 */
> +
> +#include 
> +
> +#endif
> +
> +extern xendevicemodel_handle *xen_dmod;
> +
>  static inline int xen_set_mem_type(domid_t domid, hvmmem_type_t type,
> uint64_t first_pfn, uint32_t nr)
>  {
> -return xc_hvm_set_mem_type(xen_xc, domid, type, first_pfn, nr);
> +return xendevicemodel_set_mem_type(xen_dmod, domid, type, first_pfn,
> +   nr);
>  }
>  
>  static inline int xen_set_pci_intx_level(domid_t domid, 

Re: [Xen-devel] [PATCH net] xen-netback: Use GFP_ATOMIC to allocate hash

[David Miller]

From: Anoob Soman 
Date: Thu, 2 Mar 2017 10:50:20 +

> Allocation of new_hash, inside xenvif_new_hash(), always happen
> in softirq context, so use GFP_ATOMIC instead of GFP_KERNEL for new
> hash allocation.
> 
> Signed-off-by: Anoob Soman 

Applied.

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

Re: [Xen-devel] xen/arm and swiotlb-xen: possible data corruption

[Stefano Stabellini]

On Thu, 2 Mar 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 02/03/17 19:12, Stefano Stabellini wrote:
> > On Thu, 2 Mar 2017, Julien Grall wrote:
> > > On 02/03/17 08:53, Edgar E. Iglesias wrote:
> > > > On Thu, Mar 02, 2017 at 09:38:37AM +0100, Edgar E. Iglesias wrote:
> > > > > On Wed, Mar 01, 2017 at 05:05:21PM -0800, Stefano Stabellini wrote:
> > Julien, from looking at the two diffs, this is simpler and nicer, but if
> > you look at xen/include/asm-arm/page.h, my patch made
> > clean_dcache_va_range consistent with invalidate_dcache_va_range. For
> > consistency, I would prefer to deal with the two functions the same way.
> > Although it is not a spec requirement, I also think that it is a good
> > idea to issue cache flushes from cacheline aligned addresses, like
> > invalidate_dcache_va_range does and Linux does, to make more obvious
> > what is going on.
> 
> invalid_dcache_va_range is split because the cache instruction differs for the
> start and end if unaligned. For them you want to use clean & invalidate rather
> than invalidate.
> 
> If you look at the implementation of other cache helpers in Linux (see
> dcache_by_line_op in arch/arm64/include/asm/assembler.h), they will only align
> start & end.

I don't think so, unless I am reading dcache_by_line_op wrong.


> Also, the invalid_dcache_va_range is using modulo which I would rather avoid.
> The modulo in this case will not be optimized by the compiler because
> cacheline_bytes is not a constant.

That is a good point. What if I replace the modulo op with

  p & (cacheline_bytes - 1)

in invalidate_dcache_va_range, then add the similar code to
clean_dcache_va_range and clean_and_invalidate_dcache_va_range?


> BTW, you would also need to fix clean_and_invalidate_dcache_va_range.

I'll do that, thanks for the reminder.

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

[Xen-devel] [xen-unstable-smoke test] 106380: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 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  7bdb974a82c1631bfc7451b9dd9756858617aef4
baseline version:
 xen  26735f30dffe1091686bbe921aacbea8ba371cc8

Last test of basis   106374  2017-03-02 16:03:24 Z0 days
Testing same since   106380  2017-03-02 20:02:17 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andy Lutomirski 
  Borislav Petkov 
  Jan Beulich 
  keios 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=7bdb974a82c1631bfc7451b9dd9756858617aef4
+ . ./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 
7bdb974a82c1631bfc7451b9dd9756858617aef4
+ branch=xen-unstable-smoke
+ revision=7bdb974a82c1631bfc7451b9dd9756858617aef4
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x7bdb974a82c1631bfc7451b9dd9756858617aef4 = 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
++ : 

[Xen-devel] [linux-linus bisection] complete test-armhf-armhf-xl-cubietruck

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl-cubietruck
testid guest-start

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  4977ab6e92e267afe9d8f78438c3db330ca8434c
  Bug not present: c470abd4fde40ea6a0846a2beab642a578c0b8cd
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/106379/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-armhf-armhf-xl-cubietruck.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-armhf-armhf-xl-cubietruck.guest-start
 --summary-out=tmp/106379.bisection-summary --basis-template=59254 
--blessings=real,real-bisect linux-linus test-armhf-armhf-xl-cubietruck 
guest-start
Searching for failure / basis pass:
 106354 fail [host=cubietruck-metzinger] / 106124 [host=cubietruck-picasso] 
106083 [host=cubietruck-gleizes] 105984 [host=cubietruck-braque] 105960 
[host=cubietruck-braque] 105941 [host=cubietruck-gleizes] 105929 ok.
Failure / basis pass flights: 106354 / 105929
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 4977ab6e92e267afe9d8f78438c3db330ca8434c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57e8fbb2f702001a18bd81e9fe31b26d94247ac9 
2f5af2c962c05b789bdd65b46c74711e903f86d0
Basis pass c470abd4fde40ea6a0846a2beab642a578c0b8cd 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
08c008de9c7d3ac71f71c87cc04a47819ca228dc 
75da1b150e646bb9aaa26c5b2452f0c3e782d302
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#c470abd4fde40ea6a0846a2beab642a578c0b8cd-4977ab6e92e267afe9d8f78438c3db330ca8434c
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen.git#08c008de9c7d3ac71f71c87cc04a47819ca228dc-57e8fbb2f702001a18bd81e9fe31b26d94247ac9
 
git://xenbits.xen.org/xen.git#75da1b150e646bb9aaa26c5b2452f0c3e782d302-2f5af2c962c05b789bdd65b46c74711e903f86d0
From 
git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
   4977ab6..0f221a3  master -> origin/master
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 2006 nodes in revision graph
Searching for test results:
 105893 [host=cubietruck-picasso]
 105897 [host=cubietruck-gleizes]
 105898 []
 105901 pass irrelevant
 105905 [host=cubietruck-braque]
 105922 [host=cubietruck-gleizes]
 105929 pass c470abd4fde40ea6a0846a2beab642a578c0b8cd 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
08c008de9c7d3ac71f71c87cc04a47819ca228dc 
75da1b150e646bb9aaa26c5b2452f0c3e782d302
 105941 [host=cubietruck-gleizes]
 105984 [host=cubietruck-braque]
 105960 [host=cubietruck-braque]
 106083 [host=cubietruck-gleizes]
 106152 []
 106124 [host=cubietruck-picasso]
 106139 fail irrelevant
 106172 fail irrelevant
 106205 pass irrelevant
 106211 fail irrelevant
 106191 pass c470abd4fde40ea6a0846a2beab642a578c0b8cd 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
08c008de9c7d3ac71f71c87cc04a47819ca228dc 
75da1b150e646bb9aaa26c5b2452f0c3e782d302
 106238 pass irrelevant
 106201 fail irrelevant
 106213 pass irrelevant
 106227 pass irrelevant
 106190 fail irrelevant
 106288 fail irrelevant
 106209 fail irrelevant
 106235 blocked irrelevant
 106222 pass irrelevant
 106272 pass c470abd4fde40ea6a0846a2beab642a578c0b8cd 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
08c008de9c7d3ac71f71c87cc04a47819ca228dc 
75da1b150e646bb9aaa26c5b2452f0c3e782d302
 106265 fail irrelevant
 106224 fail irrelevant
 106280 fail irrelevant
 106262 pass irrelevant
 106275 fail irrelevant
 106277 pass irrelevant
 106285 fail irrelevant
 106290 pass irrelevant
 106296 fail irrelevant
 106304 pass irrelevant
 106311 pass c470abd4fde40ea6a0846a2beab642a578c0b8cd 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
08c008de9c7d3ac71f71c87cc04a47819ca228dc 
75da1b150e646bb9aaa26c5b2452f0c3e782d302
 106315 fail irrelevant
 106373 fail 4977ab6e92e267afe9d8f78438c3db330ca8434c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57e8fbb2f702001a18bd81e9fe31b26d94247ac9 
2f5af2c962c05b789bdd65b46c74711e903f86d0
 106330 fail irrelevant
 106363 pass c470abd4fde40ea6a0846a2beab642a578c0b8cd 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57e8fbb2f702001a18bd81e9fe31b26d94247ac9 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 106351

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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:
 xen  f14ce1a13455bfc3fb7b33c185e3e49749d68e28
baseline version:
 xen  1a0ab02e342cfd80decd72606c94479e4b309a3c

Last test of basis   106351  2017-03-02 04:21:56 Z0 days
Testing same since   106371  2017-03-02 14:14:36 Z0 days1 attempts


People who touched revisions under test:
  Marek Marczykowski-Górecki 
  Olaf Hering 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Edgar E. Iglesias]

On Thu, Feb 23, 2017 at 04:47:19PM +, Julien Grall wrote:
> 
> Hi Edgar,
> 
> On 22/02/17 04:03, Edgar E. Iglesias wrote:
> >On Mon, Feb 13, 2017 at 03:35:19PM +, Julien Grall wrote:
> >>On 02/02/17 15:33, Edgar E. Iglesias wrote:
> >>>On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
> On 31/01/2017 19:06, Edgar E. Iglesias wrote:
> >On Tue, Jan 31, 2017 at 05:09:53PM +, Julien Grall wrote:
> >>>I'll see if I can find working examples for PCIe on the ZCU102. Then I'll 
> >>>share
> >>>DTS, Kernel etc.
> >>
> >>I've found a device tree on the github from the ZCU102: zynqmp-zcu102.dts,
> >>it looks like there is no use of PHY for the pcie so far.
> >>
> >>Lets imagine in the future, pcie will use the PHY. If we decide to
> >>initialize the hostbridge in Xen, we would also have to pull the PHY code in
> >>the hypervisor. Leaving aside the problem to pull more code in Xen, this is
> >>not nice because the PHY is used by different components (e.g SATA, USB). So
> >>Xen and DOM0 would have to share the PHY.
> >>
> >>For Xen POV, the best solution would be the bootloader initializing the PHY
> >>because starting Xen. So we can keep all the hostbridge (initialization +
> >>access) in Xen.
> >>
> >>If it is not possible, then I would prefer to see the hostbridge
> >>initialization in DOM0.
> >
> >>>
> >>>I suspect that this setup has previously been done by the initial 
> >>>bootloader
> >>>auto-generated from design configuration tools.
> >>>
> >>>Now, this is moving into Linux.
> >>
> >>Do you know why they decide to move the code in Linux? What would be the
> >>problem to let the bootloader configuring the GT?
> >
> >
> >No, I'm not sure why this approach was not used. The only thing I can think 
> >of
> >is a runtime configuration approach.
> >
> >
> >>
> >>>There's a specific driver that does that but AFAICS, it has not been 
> >>>upstreamed yet.
> >>>You can see it here:
> >>>https://github.com/Xilinx/linux-xlnx/blob/master/drivers/phy/phy-zynqmp.c
> >>>
> >>>DTS nodes that need a PHY can then just refer to it, here's an example 
> >>>from SATA:
> >>> {
> >>>   phy-names = "sata-phy";
> >>>   phys = < PHY_TYPE_SATA 1 3 15000>;
> >>>};
> >>>
> >Yes, I agree that the GT setup in the bootloader is very attractive.
> >I don't think hte setup sequence is complicated, we can perhaps even do it
> >on the commandline in u-boot or xsdb. I'll have to check.
> 
> That might simplify things for Xen. I would be happy to consider any other
> solutions. It might probably be worth to kick a separate thread regarding
> how to support Xilinx hostcontroller in Xen.
> 
> For now, I will explain in the design document the different situation we
> can encounter with an hostbridge and will leave open the design for
> initialization bits.
> 
> 
> [...]
> 
> 
> From a design point of view, it would make more sense to have the MSI
> controller driver in Xen as the hostbridge emulation for guest will also
> live there.
> 
> So if we receive MSI in Xen, we need to figure out a way for DOM0 and 
> guest
> to receive MSI. The same way would be the best, and I guess non-PV if
> possible. I know you are looking to boot unmodified OS in a VM. This would
> mean we need to emulate the MSI controller and potentially xilinx PCI
> controller. How much are you willing to modify the OS?
> >>>
> >>>Today, we have not yet implemented PCIe drivers for our baremetal SDK. So
> >>>things are very open and we could design with pretty much anything in mind.
> >>>
> >>>Yes, we could perhaps include a very small model with most registers 
> >>>dummied.
> >>>Implementing the MSI read FIFO would allow us to:
> >>>
> >>>1. Inject the MSI doorbell SPI into guests. The guest will then see the 
> >>>same
> >>>  IRQ as on real HW.
> >>>
> >>>2. Guest reads host-controller registers (MSI FIFO) to get the signaled 
> >>>MSI.
> >>
> >>The Xilinx PCIe hostbridge is not the only hostbridge having MSI controller
> >>embedded. So I would like to see a generic solution if possible. This would
> >>avoid to increase the code required for emulation in Xen.
> >>
> >>My concern with a FIFO is it will require an upper bound to avoid using to
> >>much memory in Xen. What if the FIFO is full? Will you drop MSI?
> >
> >The FIFO I'm refering to is a FIFO in the MSI controller itself.
> 
> Sorry if it was unclear. I was trying to explain what would be the issue to
> emulate this kind of MSI controller in Xen not using them in Xen.
> 
> >I agree that this wouldn't be generic though
> 
> An idea would be to emulate a GICv2m frame (see appendix E in ARM-DEN-0029
> v3.0) for the guest. The frame is able to handle a certain number of SPIs.
> Each MSI will be presented as a uniq SPI. The association SPI <-> MSI is
> left at the discretion of the driver.
> 
> A guest will discover the number of SPIs by reading the register MSI_TYPER.
> To initialize MSI, the guest will compose the message using the 

[Xen-devel] [seabios test] 106372: tolerable FAIL - PUSHED

[osstest service owner]

flight 106372 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106372/

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 seabios  6bc4164cc8570ed3140d34080e38878adce13593
baseline version:
 seabios  8f598a4641f98cf503653f80c779793d91c95a84

Last test of basis   105970  2017-02-22 00:57:29 Z8 days
Testing same since   106372  2017-03-02 14:44:18 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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=seabios
+ revision=6bc4164cc8570ed3140d34080e38878adce13593
+ . ./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 seabios 
6bc4164cc8570ed3140d34080e38878adce13593
+ branch=seabios
+ revision=6bc4164cc8570ed3140d34080e38878adce13593
+ . ./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=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' 

Re: [Xen-devel] [PATCH 11/28] ARM: GICv3: forward pending LPIs to guests

[Julien Grall]

Hi,

Ping? I'd like the question to be sorted out before Andre is sending a 
new version.


On 02/15/2017 09:25 PM, Stefano Stabellini wrote:

On Wed, 15 Feb 2017, Julien Grall wrote:

Hi Stefano,

On 14/02/17 21:00, Stefano Stabellini wrote:

On Mon, 30 Jan 2017, Andre Przywara wrote:

+/*
+ * Handle incoming LPIs, which are a bit special, because they are
potentially
+ * numerous and also only get injected into guests. Treat them specially
here,
+ * by just looking up their target vCPU and virtual LPI number and hand
it
+ * over to the injection function.
+ */
+void do_LPI(unsigned int lpi)
+{
+struct domain *d;
+union host_lpi *hlpip, hlpi;
+struct vcpu *vcpu;
+
+WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
+
+hlpip = gic_get_host_lpi(lpi);
+if ( !hlpip )
+return;
+
+hlpi.data = read_u64_atomic(>data);
+
+/* We may have mapped more host LPIs than the guest actually asked
for. */
+if ( !hlpi.virt_lpi )
+return;
+
+d = get_domain_by_id(hlpi.dom_id);
+if ( !d )
+return;
+
+if ( hlpi.vcpu_id >= d->max_vcpus )
+{
+put_domain(d);
+return;
+}
+
+vcpu = d->vcpu[hlpi.vcpu_id];
+
+put_domain(d);
+
+vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);


put_domain should be here


Why? I don't even understand why we would need to take a reference on the
domain for LPIs. Would not it be enough to use rcu_lock_domain_by_id here?


I think that rcu_lock_domain_by_id would also work, but similarly we
would need to call rcu_unlock here.

To be honest, I don't know exactly in which cases get_domain should be
used instead of rcu_lock_domain_by_id.

CC'ing the x86 guys that might know the answer.



--
Julien Grall

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

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

[Tamas K Lengyel]

On Thu, Mar 2, 2017 at 10:54 AM, Volodymyr Babchuk
 wrote:
> Hello,
>
> Thank you all for the discussion. I want to summarize it a bit.
>
> Looks like there are no objections about my initial list of
> requirements. There was born another requirement in the discussion.
> Thanks to Stefano for formulation it:
>
> 10. Domains on which the monitor privileged call feature is enabled
>   (which is by default disabled for all domains) should not be able to
>   issue firmware calls via SMCs/HVCs so that such calls reach the
>   firmware directly. Xen should not bounce such calls to the firmware on
>   behalf of the domain. Xen should not alter the state of the domain
>   automatically (ie. incrementing PC). These calls should be exclusively
>   transfered to the monitor subscriber for further processing.
>   Hypercalls, virtual PSCI calls, virtual CPU services calls and virtual
>   ARM architecture service calls remain unaffected.
>
> Tamas, you have agreed with this, right?

Yes, that would work for me.

Tamas

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

[Xen-devel] [PATCH] x86/cpuid: Fix booting on AMD Phenom 6-core platform

[Andrew Cooper]

c/s 5cecf60f4 "x86/cpuid: Handle leaf 0x1 in guest_cpuid()" causes Linux 4.10
to crash during boot.

It turns out to be because of the reported apic_id, which was altered to be
more consistent across guests.  Revert back to the previous behaviour, by
limiting the apic_id adjustment to HVM guests only.  Whomever gets to fixes
topology representation is going to have a lot of fun with non-power-of-2 AMD
boxes.

Reported-by: Sander Eikelenboom 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/cpuid.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 0dd35dc..d6f6b88 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -749,7 +749,8 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 case 0x1:
 /* TODO: Rework topology logic. */
 res->b &= 0x00ffu;
-res->b |= (v->vcpu_id * 2) << 24;
+if ( has_hvm_container_domain(d) )
+res->b |= (v->vcpu_id * 2) << 24;
 
 /* TODO: Rework vPMU control in terms of toolstack choices. */
 if ( vpmu_available(v) &&
-- 
2.1.4


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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Andrew Cooper]

On 02/03/17 19:33, Boris Ostrovsky wrote:
>> I expect it might have something to do with fact that this failure to
>> boot is a 6-core system, rather than a power of two, at which point I
>> doubt the APIC IDs follow a linear trend.
>>
>> (Properly fixing the reported topology is going to be a can of worms. 
>> All this series is trying to do is use just enough duct-tape to get the
>> hypervisor into a state where we can sensibly fix the reported topology.)
>
> I think we are using the same duct-tape roll on the Linux side.

Really? I'm sure I have used several rolls already ;p

> For example,
>
> cc272163ea55 ("x86/xen: Fix APIC id mismatch warning on Intel")
> or
> a6a198bc60e6 ("xen/x86: Update topology map for PV VCPUs")
>
> and there are more.

I seriously hope there is a compatible way to get the hypervisor side
correct without breaking the Linux-side, otherwise we are going to have
some hard decisions to make about which scenarios we can afford to regress.

~Andrew

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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Andrew Cooper]

On 02/03/17 19:28, Sander Eikelenboom wrote:
> On 02/03/17 20:17, Andrew Cooper wrote:
>> On 02/03/17 19:15, Boris Ostrovsky wrote:
>>> On 03/02/2017 01:56 PM, Andrew Cooper wrote:
 On 02/03/17 18:51, Sander Eikelenboom wrote:
> On 02/03/17 19:29, Andrew Cooper wrote:
>> On 02/03/17 18:25, Sander Eikelenboom wrote:
>>> On 02/03/17 18:38, Andrew Cooper wrote:
 On 02/03/17 17:29, Sander Eikelenboom wrote:
> On 02/03/17 15:55, Andrew Cooper wrote:
>> On 02/03/17 14:42, Sander Eikelenboom wrote:
>>> Hi Andrew / Jan,
>>>
>>> While testing current xen-unstable staging i ran into my host 
>>> rebooting in early kernel boot. 
>>> Bisection has turned up:
>>> 5cecf60f439e828f4bc0d2a368ced9a73b130cb7 is the first bad commit
>>> Author: Andrew Cooper 
>>> Date:   Fri Feb 17 17:10:50 2017 +
>>>
>>> x86/cpuid: Handle leaf 0x1 in guest_cpuid()
>>>
>>> Hardware is a AMD phenom x6.
>>> Below is the output of serial console of a failed boot.
>> Hmm.  Sorry for breaking this (although my AMD servers are booting 
>> fine).
> No problem, it is the staging branch of the unstable tree anyway ;-)
>
>> It is unfortunately not entirely obvious what Linux is objecting to, 
>> and
>> must be related to something visible in the emulated view.
>>
>> Does this delta make any difference?
> Yes it does, boots fine with this patch applied, thanks !
 That is bad though. :s

 It means that something in dom0 has an aversion to my attempt to lie
 less about the topology.

 Do you mind checking whether

 res->b = cpuid_ebx(0x1) & 0xff00u;

 causes is to break again?
>>> Used that in the is_hardware_domain() case and it boots fine.
>> Hmm - curious.  I am now even more confused.
>>
>> What about this?
>>
>> res->b = cpuid_ebx(0x1) & 0x00ffu;
>>
>> It will leave the APIC_ID field zeroed rather than feeding v->vcpu_id
>> back into it.
> Also boots fine.
 Right.  For my sanity, what about

 res->b = cpuid_ebx(0x1) & 0x00ffu;
 res->b |= (v->vcpu_id * 2) << 24;
> This doesn't boot.
> --
> Sander

Ok.  So something in dom0 is taking extreme objection to the APIC IDs.

As a stopgap fix, this can be moved back to being HVM only. (And I am
going to have even more $FUN than I was originally planning, fixing the
topology reporting)

~Andrew

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

Re: [Xen-devel] xen/arm and swiotlb-xen: possible data corruption

[Julien Grall]

Hi Stefano,

On 02/03/17 19:12, Stefano Stabellini wrote:

On Thu, 2 Mar 2017, Julien Grall wrote:

On 02/03/17 08:53, Edgar E. Iglesias wrote:

On Thu, Mar 02, 2017 at 09:38:37AM +0100, Edgar E. Iglesias wrote:

On Wed, Mar 01, 2017 at 05:05:21PM -0800, Stefano Stabellini wrote:

Julien, from looking at the two diffs, this is simpler and nicer, but if
you look at xen/include/asm-arm/page.h, my patch made
clean_dcache_va_range consistent with invalidate_dcache_va_range. For
consistency, I would prefer to deal with the two functions the same way.
Although it is not a spec requirement, I also think that it is a good
idea to issue cache flushes from cacheline aligned addresses, like
invalidate_dcache_va_range does and Linux does, to make more obvious
what is going on.


invalid_dcache_va_range is split because the cache instruction differs 
for the start and end if unaligned. For them you want to use clean & 
invalidate rather than invalidate.


If you look at the implementation of other cache helpers in Linux (see 
dcache_by_line_op in arch/arm64/include/asm/assembler.h), they will only 
align start & end.


Also, the invalid_dcache_va_range is using modulo which I would rather 
avoid. The modulo in this case will not be optimized by the compiler 
because cacheline_bytes is not a constant.


So I still prefer to keep this function really simple.

BTW, you would also need to fix clean_and_invalidate_dcache_va_range.

--
Julien Grall

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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Boris Ostrovsky]

> I expect it might have something to do with fact that this failure to
> boot is a 6-core system, rather than a power of two, at which point I
> doubt the APIC IDs follow a linear trend.
>
> (Properly fixing the reported topology is going to be a can of worms. 
> All this series is trying to do is use just enough duct-tape to get the
> hypervisor into a state where we can sensibly fix the reported topology.)


I think we are using the same duct-tape roll on the Linux side. For example,

cc272163ea55 ("x86/xen: Fix APIC id mismatch warning on Intel")
or
a6a198bc60e6 ("xen/x86: Update topology map for PV VCPUs")

and there are more.

-boris




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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Sander Eikelenboom]

On 02/03/17 20:17, Andrew Cooper wrote:
> On 02/03/17 19:15, Boris Ostrovsky wrote:
>> On 03/02/2017 01:56 PM, Andrew Cooper wrote:
>>> On 02/03/17 18:51, Sander Eikelenboom wrote:
 On 02/03/17 19:29, Andrew Cooper wrote:
> On 02/03/17 18:25, Sander Eikelenboom wrote:
>> On 02/03/17 18:38, Andrew Cooper wrote:
>>> On 02/03/17 17:29, Sander Eikelenboom wrote:
 On 02/03/17 15:55, Andrew Cooper wrote:
> On 02/03/17 14:42, Sander Eikelenboom wrote:
>> Hi Andrew / Jan,
>>
>> While testing current xen-unstable staging i ran into my host 
>> rebooting in early kernel boot. 
>> Bisection has turned up:
>> 5cecf60f439e828f4bc0d2a368ced9a73b130cb7 is the first bad commit
>> Author: Andrew Cooper 
>> Date:   Fri Feb 17 17:10:50 2017 +
>>
>> x86/cpuid: Handle leaf 0x1 in guest_cpuid()
>>
>> Hardware is a AMD phenom x6.
>> Below is the output of serial console of a failed boot.
> Hmm.  Sorry for breaking this (although my AMD servers are booting 
> fine).
 No problem, it is the staging branch of the unstable tree anyway ;-)

> It is unfortunately not entirely obvious what Linux is objecting to, 
> and
> must be related to something visible in the emulated view.
>
> Does this delta make any difference?
 Yes it does, boots fine with this patch applied, thanks !
>>> That is bad though. :s
>>>
>>> It means that something in dom0 has an aversion to my attempt to lie
>>> less about the topology.
>>>
>>> Do you mind checking whether
>>>
>>> res->b = cpuid_ebx(0x1) & 0xff00u;
>>>
>>> causes is to break again?
>> Used that in the is_hardware_domain() case and it boots fine.
> Hmm - curious.  I am now even more confused.
>
> What about this?
>
> res->b = cpuid_ebx(0x1) & 0x00ffu;
>
> It will leave the APIC_ID field zeroed rather than feeding v->vcpu_id
> back into it.
 Also boots fine.
>>> Right.  For my sanity, what about
>>>
>>> res->b = cpuid_ebx(0x1) & 0x00ffu;
>>> res->b |= (v->vcpu_id * 2) << 24;

This doesn't boot.
--
Sander

>> FWIW, I booted a 2-node
>>
>>   (XEN) CPU Vendor: AMD, Family 21 (0x15), Model 1 (0x1), Stepping 2
>> (raw 00600f12)
>>
>> with Linux 4.10 and latest staging. (I thought perhaps my nightly missed
>> something because it's a single node)
> 
> I expect it might have something to do with fact that this failure to
> boot is a 6-core system, rather than a power of two, at which point I
> doubt the APIC IDs follow a linear trend.
> 
> (Properly fixing the reported topology is going to be a can of worms. 
> All this series is trying to do is use just enough duct-tape to get the
> hypervisor into a state where we can sensibly fix the reported topology.)
> 
> ~Andrew
> 


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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Andrew Cooper]

On 02/03/17 19:15, Boris Ostrovsky wrote:
> On 03/02/2017 01:56 PM, Andrew Cooper wrote:
>> On 02/03/17 18:51, Sander Eikelenboom wrote:
>>> On 02/03/17 19:29, Andrew Cooper wrote:
 On 02/03/17 18:25, Sander Eikelenboom wrote:
> On 02/03/17 18:38, Andrew Cooper wrote:
>> On 02/03/17 17:29, Sander Eikelenboom wrote:
>>> On 02/03/17 15:55, Andrew Cooper wrote:
 On 02/03/17 14:42, Sander Eikelenboom wrote:
> Hi Andrew / Jan,
>
> While testing current xen-unstable staging i ran into my host 
> rebooting in early kernel boot. 
> Bisection has turned up:
> 5cecf60f439e828f4bc0d2a368ced9a73b130cb7 is the first bad commit
> Author: Andrew Cooper 
> Date:   Fri Feb 17 17:10:50 2017 +
>
> x86/cpuid: Handle leaf 0x1 in guest_cpuid()
>
> Hardware is a AMD phenom x6.
> Below is the output of serial console of a failed boot.
 Hmm.  Sorry for breaking this (although my AMD servers are booting 
 fine).
>>> No problem, it is the staging branch of the unstable tree anyway ;-)
>>>
 It is unfortunately not entirely obvious what Linux is objecting to, 
 and
 must be related to something visible in the emulated view.

 Does this delta make any difference?
>>> Yes it does, boots fine with this patch applied, thanks !
>> That is bad though. :s
>>
>> It means that something in dom0 has an aversion to my attempt to lie
>> less about the topology.
>>
>> Do you mind checking whether
>>
>> res->b = cpuid_ebx(0x1) & 0xff00u;
>>
>> causes is to break again?
> Used that in the is_hardware_domain() case and it boots fine.
 Hmm - curious.  I am now even more confused.

 What about this?

 res->b = cpuid_ebx(0x1) & 0x00ffu;

 It will leave the APIC_ID field zeroed rather than feeding v->vcpu_id
 back into it.
>>> Also boots fine.
>> Right.  For my sanity, what about
>>
>> res->b = cpuid_ebx(0x1) & 0x00ffu;
>> res->b |= (v->vcpu_id * 2) << 24;
> FWIW, I booted a 2-node
>
>   (XEN) CPU Vendor: AMD, Family 21 (0x15), Model 1 (0x1), Stepping 2
> (raw 00600f12)
>
> with Linux 4.10 and latest staging. (I thought perhaps my nightly missed
> something because it's a single node)

I expect it might have something to do with fact that this failure to
boot is a 6-core system, rather than a power of two, at which point I
doubt the APIC IDs follow a linear trend.

(Properly fixing the reported topology is going to be a can of worms. 
All this series is trying to do is use just enough duct-tape to get the
hypervisor into a state where we can sensibly fix the reported topology.)

~Andrew

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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Boris Ostrovsky]

On 03/02/2017 01:56 PM, Andrew Cooper wrote:
> On 02/03/17 18:51, Sander Eikelenboom wrote:
>> On 02/03/17 19:29, Andrew Cooper wrote:
>>> On 02/03/17 18:25, Sander Eikelenboom wrote:
 On 02/03/17 18:38, Andrew Cooper wrote:
> On 02/03/17 17:29, Sander Eikelenboom wrote:
>> On 02/03/17 15:55, Andrew Cooper wrote:
>>> On 02/03/17 14:42, Sander Eikelenboom wrote:
 Hi Andrew / Jan,

 While testing current xen-unstable staging i ran into my host 
 rebooting in early kernel boot. 
 Bisection has turned up:
 5cecf60f439e828f4bc0d2a368ced9a73b130cb7 is the first bad commit
 Author: Andrew Cooper 
 Date:   Fri Feb 17 17:10:50 2017 +

 x86/cpuid: Handle leaf 0x1 in guest_cpuid()

 Hardware is a AMD phenom x6.
 Below is the output of serial console of a failed boot.
>>> Hmm.  Sorry for breaking this (although my AMD servers are booting 
>>> fine).
>> No problem, it is the staging branch of the unstable tree anyway ;-)
>>
>>> It is unfortunately not entirely obvious what Linux is objecting to, and
>>> must be related to something visible in the emulated view.
>>>
>>> Does this delta make any difference?
>> Yes it does, boots fine with this patch applied, thanks !
> That is bad though. :s
>
> It means that something in dom0 has an aversion to my attempt to lie
> less about the topology.
>
> Do you mind checking whether
>
> res->b = cpuid_ebx(0x1) & 0xff00u;
>
> causes is to break again?
 Used that in the is_hardware_domain() case and it boots fine.
>>> Hmm - curious.  I am now even more confused.
>>>
>>> What about this?
>>>
>>> res->b = cpuid_ebx(0x1) & 0x00ffu;
>>>
>>> It will leave the APIC_ID field zeroed rather than feeding v->vcpu_id
>>> back into it.
>> Also boots fine.
> Right.  For my sanity, what about
>
> res->b = cpuid_ebx(0x1) & 0x00ffu;
> res->b |= (v->vcpu_id * 2) << 24;

FWIW, I booted a 2-node

  (XEN) CPU Vendor: AMD, Family 21 (0x15), Model 1 (0x1), Stepping 2
(raw 00600f12)

with Linux 4.10 and latest staging. (I thought perhaps my nightly missed
something because it's a single node)


-boris




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

Re: [Xen-devel] xen/arm and swiotlb-xen: possible data corruption

[Stefano Stabellini]

On Thu, 2 Mar 2017, Julien Grall wrote:
> On 02/03/17 08:53, Edgar E. Iglesias wrote:
> > On Thu, Mar 02, 2017 at 09:38:37AM +0100, Edgar E. Iglesias wrote:
> > > On Wed, Mar 01, 2017 at 05:05:21PM -0800, Stefano Stabellini wrote:
> > > > Hi all,
> > > > 
> > > > Edgar reported a data corruption on network packets in dom0 when the
> > > > swiotlb-xen is in use. He also reported that the following patch "fixes"
> > > > the problem for him:
> > > > 
> > > >  static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t
> > > > handle,
> > > > size_t size, enum dma_data_direction dir)
> > > >  {
> > > > -   dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size,
> > > > dir, DMA_MAP);
> > > > +   printk("%s: addr=%lx size=%zd\n", __func__, handle, size);
> > > > +   dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size +
> > > > 64, dir, DMA_MAP);
> > > > 
> > > > I am thinking that the problem has something to do with cacheline
> > > > alignment on the Xen side
> > > > (xen/common/grant_table.c:__gnttab_cache_flush).
> > > > 
> > > > If op == GNTTAB_CACHE_INVAL, we call invalidate_dcache_va_range; if op
> > > > == GNTTAB_CACHE_CLEAN, we call clean_dcache_va_range instead. The
> > > > parameter, v, could be non-cacheline aligned.
> > > > 
> > > > invalidate_dcache_va_range is capable of handling a not aligned address,
> > > > while clean_dcache_va_range does not.
> > > > 
> > > > Edgar, does the appended patch fix the problem for you?
> > > 
> > > 
> > > Thanks Stefano,
> > > 
> > > This does indeed fix the issue for me.

Thanks for reporting and testing!


> > Hi again,
> > 
> > Looking at the code, the problem here is that we may flush one cache line
> > less than expected.
> > 
> > This smaller patch fixes it for me too:
> > diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> > index c492d6d..fa1b4dd 100644
> > --- a/xen/include/asm-arm/page.h
> > +++ b/xen/include/asm-arm/page.h
> > @@ -325,7 +325,9 @@ static inline int clean_dcache_va_range(const void *p,
> > unsigned long size)
> >  {
> >  const void *end;
> >  dsb(sy);   /* So the CPU issues all writes to the range */
> > -for ( end = p + size; p < end; p += cacheline_bytes )
> > +
> > +end = (void *)ROUNDUP((uintptr_t)p + size, cacheline_bytes);
> > +for ( ; p < end; p += cacheline_bytes )
> >  asm volatile (__clean_dcache_one(0) : : "r" (p));
> >  dsb(sy);   /* So we know the flushes happen before continuing
> > */
> >  /* ARM callers assume that dcache_* functions cannot fail. */
> > 
> > 
> > Anyway, I'm OK with either fix.
> 
> I would prefer your version compare to Stefano's one.

Julien, from looking at the two diffs, this is simpler and nicer, but if
you look at xen/include/asm-arm/page.h, my patch made
clean_dcache_va_range consistent with invalidate_dcache_va_range. For
consistency, I would prefer to deal with the two functions the same way.
Although it is not a spec requirement, I also think that it is a good
idea to issue cache flushes from cacheline aligned addresses, like
invalidate_dcache_va_range does and Linux does, to make more obvious
what is going on.

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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Andrew Cooper]

On 02/03/17 18:51, Sander Eikelenboom wrote:
> On 02/03/17 19:29, Andrew Cooper wrote:
>> On 02/03/17 18:25, Sander Eikelenboom wrote:
>>> On 02/03/17 18:38, Andrew Cooper wrote:
 On 02/03/17 17:29, Sander Eikelenboom wrote:
> On 02/03/17 15:55, Andrew Cooper wrote:
>> On 02/03/17 14:42, Sander Eikelenboom wrote:
>>> Hi Andrew / Jan,
>>>
>>> While testing current xen-unstable staging i ran into my host rebooting 
>>> in early kernel boot. 
>>> Bisection has turned up:
>>> 5cecf60f439e828f4bc0d2a368ced9a73b130cb7 is the first bad commit
>>> Author: Andrew Cooper 
>>> Date:   Fri Feb 17 17:10:50 2017 +
>>>
>>> x86/cpuid: Handle leaf 0x1 in guest_cpuid()
>>>
>>> Hardware is a AMD phenom x6.
>>> Below is the output of serial console of a failed boot.
>> Hmm.  Sorry for breaking this (although my AMD servers are booting fine).
> No problem, it is the staging branch of the unstable tree anyway ;-)
>
>> It is unfortunately not entirely obvious what Linux is objecting to, and
>> must be related to something visible in the emulated view.
>>
>> Does this delta make any difference?
> Yes it does, boots fine with this patch applied, thanks !
 That is bad though. :s

 It means that something in dom0 has an aversion to my attempt to lie
 less about the topology.

 Do you mind checking whether

 res->b = cpuid_ebx(0x1) & 0xff00u;

 causes is to break again?
>>> Used that in the is_hardware_domain() case and it boots fine.
>> Hmm - curious.  I am now even more confused.
>>
>> What about this?
>>
>> res->b = cpuid_ebx(0x1) & 0x00ffu;
>>
>> It will leave the APIC_ID field zeroed rather than feeding v->vcpu_id
>> back into it.
> Also boots fine.

Right.  For my sanity, what about

res->b = cpuid_ebx(0x1) & 0x00ffu;
res->b |= (v->vcpu_id * 2) << 24;

?

~Andrew

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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Sander Eikelenboom]

On 02/03/17 19:29, Andrew Cooper wrote:
> On 02/03/17 18:25, Sander Eikelenboom wrote:
>> On 02/03/17 18:38, Andrew Cooper wrote:
>>> On 02/03/17 17:29, Sander Eikelenboom wrote:
 On 02/03/17 15:55, Andrew Cooper wrote:
> On 02/03/17 14:42, Sander Eikelenboom wrote:
>> Hi Andrew / Jan,
>>
>> While testing current xen-unstable staging i ran into my host rebooting 
>> in early kernel boot. 
>> Bisection has turned up:
>> 5cecf60f439e828f4bc0d2a368ced9a73b130cb7 is the first bad commit
>> Author: Andrew Cooper 
>> Date:   Fri Feb 17 17:10:50 2017 +
>>
>> x86/cpuid: Handle leaf 0x1 in guest_cpuid()
>>
>> Hardware is a AMD phenom x6.
>> Below is the output of serial console of a failed boot.
> Hmm.  Sorry for breaking this (although my AMD servers are booting fine).
 No problem, it is the staging branch of the unstable tree anyway ;-)

> It is unfortunately not entirely obvious what Linux is objecting to, and
> must be related to something visible in the emulated view.
>
> Does this delta make any difference?
 Yes it does, boots fine with this patch applied, thanks !
>>> That is bad though. :s
>>>
>>> It means that something in dom0 has an aversion to my attempt to lie
>>> less about the topology.
>>>
>>> Do you mind checking whether
>>>
>>> res->b = cpuid_ebx(0x1) & 0xff00u;
>>>
>>> causes is to break again?
>> Used that in the is_hardware_domain() case and it boots fine.
> 
> Hmm - curious.  I am now even more confused.
> 
> What about this?
> 
> res->b = cpuid_ebx(0x1) & 0x00ffu;
> 
> It will leave the APIC_ID field zeroed rather than feeding v->vcpu_id
> back into it.

Also boots fine.

--
Sander
> 
> ~Andrew
> 


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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Andrew Cooper]

On 02/03/17 18:25, Sander Eikelenboom wrote:
> On 02/03/17 18:38, Andrew Cooper wrote:
>> On 02/03/17 17:29, Sander Eikelenboom wrote:
>>> On 02/03/17 15:55, Andrew Cooper wrote:
 On 02/03/17 14:42, Sander Eikelenboom wrote:
> Hi Andrew / Jan,
>
> While testing current xen-unstable staging i ran into my host rebooting 
> in early kernel boot. 
> Bisection has turned up:
> 5cecf60f439e828f4bc0d2a368ced9a73b130cb7 is the first bad commit
> Author: Andrew Cooper 
> Date:   Fri Feb 17 17:10:50 2017 +
>
> x86/cpuid: Handle leaf 0x1 in guest_cpuid()
>
> Hardware is a AMD phenom x6.
> Below is the output of serial console of a failed boot.
 Hmm.  Sorry for breaking this (although my AMD servers are booting fine).
>>> No problem, it is the staging branch of the unstable tree anyway ;-)
>>>
 It is unfortunately not entirely obvious what Linux is objecting to, and
 must be related to something visible in the emulated view.

 Does this delta make any difference?
>>> Yes it does, boots fine with this patch applied, thanks !
>> That is bad though. :s
>>
>> It means that something in dom0 has an aversion to my attempt to lie
>> less about the topology.
>>
>> Do you mind checking whether
>>
>> res->b = cpuid_ebx(0x1) & 0xff00u;
>>
>> causes is to break again?
> Used that in the is_hardware_domain() case and it boots fine.

Hmm - curious.  I am now even more confused.

What about this?

res->b = cpuid_ebx(0x1) & 0x00ffu;

It will leave the APIC_ID field zeroed rather than feeding v->vcpu_id
back into it.

~Andrew

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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Sander Eikelenboom]

On 02/03/17 18:38, Andrew Cooper wrote:
> On 02/03/17 17:29, Sander Eikelenboom wrote:
>> On 02/03/17 15:55, Andrew Cooper wrote:
>>> On 02/03/17 14:42, Sander Eikelenboom wrote:
 Hi Andrew / Jan,

 While testing current xen-unstable staging i ran into my host rebooting in 
 early kernel boot. 
 Bisection has turned up:
 5cecf60f439e828f4bc0d2a368ced9a73b130cb7 is the first bad commit
 Author: Andrew Cooper 
 Date:   Fri Feb 17 17:10:50 2017 +

 x86/cpuid: Handle leaf 0x1 in guest_cpuid()

 Hardware is a AMD phenom x6.
 Below is the output of serial console of a failed boot.
>>> Hmm.  Sorry for breaking this (although my AMD servers are booting fine).
>> No problem, it is the staging branch of the unstable tree anyway ;-)
>>
>>> It is unfortunately not entirely obvious what Linux is objecting to, and
>>> must be related to something visible in the emulated view.
>>>
>>> Does this delta make any difference?
>> Yes it does, boots fine with this patch applied, thanks !
> 
> That is bad though. :s
> 
> It means that something in dom0 has an aversion to my attempt to lie
> less about the topology.
> 
> Do you mind checking whether
> 
> res->b = cpuid_ebx(0x1) & 0xff00u;
> 
> causes is to break again?

Used that in the is_hardware_domain() case and it boots fine.

--
Sander

> That will confirm whether the breakage is to do with Logical Processors
> Per Package (which I suspect is the case), or the APIC ID field (which
> has always been unstable in the past).
> 
> ~Andrew
> 


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

Re: [Xen-devel] [PATCH v2 5/5] golang/xenlight: Add tests host related functionality functions

[Ronald Rojas]

On Thu, Mar 02, 2017 at 05:53:00PM +, George Dunlap wrote:
> On 02/03/17 17:36, Ian Jackson wrote:
> > Ronald Rojas writes ("[PATCH v2 5/5] golang/xenlight: Add tests host 
> > related functionality functions"):
> >> Create tests for the following functions:
> >> - GetVersionInfo
> >> - GetPhysinfo
> >> - GetDominfo
> >> - GetMaxCpus
> >> - GetOnlineCpus
> >> - GetMaxNodes
> >> - GetFreeMemory
> > 
> > I assume this whole series is RFC still ?
> 
> I think the earlier patches looked pretty close to being checked in.  I
> think having a basic chunk of functionality checked in will make it
> easier to actually collaborate on improving things.
> 
> > I don't feel competent to review the golang code.  But I did spot some
> > C to review :-)
> > 
> >> diff --git a/tools/golang/xenlight/test/xeninfo/freememory.c 
> >> b/tools/golang/xenlight/test/xeninfo/freememory.c
> >> new file mode 100644
> >> index 000..04ee90d
> >> --- /dev/null
> >> +++ b/tools/golang/xenlight/test/xeninfo/freememory.c
> >> @@ -0,0 +1,24 @@
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include "print.h"
> >> +
> >> +int main(){
> > 
> > This is an unusual definition of main.  (I think it's still legal, but
> > probably not what you meant.)
> > 

I did this because I'm not expecting any arguments  to be passed into
main. I can change it to the standard definition instead.

> >> +libxl_ctx *context;
> >> +libxl_ctx_alloc(,LIBXL_VERSION, 0, NULL);
> >> +
> >> +uint64_t free_memory;
> >> +int err = libxl_get_free_memory(context, _memory);
> >> +if (err < 0)
> >> +{
> >> +printf("%d\n", err);
> >> +}
> >> +else
> >> +{
> >> +printf("%lu\n", free_memory);
> >> +}
> > 
> > This output is ambiguous.
> > 
> >> +libxl_ctx_free(context);
> >> +
> >> +}
> > 
> > Returns from main without returning a value.  Error code is lost.
> 
> He's not testing whether the call succeeds; he's testing if the call has
> the same result as the golang function.
> 
> But this won't quite work anymore, because as of v2 the golang return
> values are positive constants (to make it easy to use them for indexes).
>  So if there were an identical error, the output would be different even
> if the error number were identical.

You are right. I need to negate the value that I print in the go file.

> 
> That needs to be fixed; but I also agree it would probably be better to
> print something that distinguishes between success and failure.

I think it's always clear whether the function failed or succeeded. The
error code will always be a negative number while free_memory can only
be non-negative because it is an unsigned long. There is no overlap
between those two values.


Ronald

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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 342fdb6eaa5934eacdf59158a99fb047fea797d6
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z8 days
Failing since105980  2017-02-22 10:03:53 Z8 days   22 attempts
Testing same since   106359  2017-03-02 07:31:42 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Brijesh Singh 
  Chen A Chen 
  Dandan Bi 
  edk2-devel On Behalf Of rthomaiy <[mailto:edk2-devel-boun...@lists.01.org]>
  Fu Siyuan 
  Hao Wu 
  Hegde Nagaraj P 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leo Duran 
  Paolo Bonzini 
  Qin Long 
  Richard Thomaiyar 
  Ruiyu Ni 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v2 5/5] golang/xenlight: Add tests host related functionality functions

[George Dunlap]

On 02/03/17 17:55, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH v2 5/5] golang/xenlight: Add tests host 
> related functionality functions"):
>> On 02/03/17 17:36, Ian Jackson wrote:
>>> I assume this whole series is RFC still ?
>>
>> I think the earlier patches looked pretty close to being checked in.  I
>> think having a basic chunk of functionality checked in will make it
>> easier to actually collaborate on improving things.
> 
> There is a lot of hand-crafted code here, whose semantics (eg, lists
> of enum values and fields) which is copied from the libxl idl.
> 
> What this means is that the golang code may stop building, or (worse)
> start to produce broken results, when the idl is updated.

Right.  The purpose of hand-crafting the code was to get a feel for what
a good Go-like output would look like before investing in the IDL.  It
sounds like you're suggesting that having IDL support would be a
prerequisite to getting anything checked in?

I'd definitely say havind IDL support would be a prerequisite for
declaring the bindings "supported".  I don't think the structures for
these functions change so often that it would be a hardship for Ronald
or I to change them whenever they broke; and so I would argue it
shouldn't be a blocker for getting things into the tree if the code
looks good.

But in the end it's your & Wei's call. :-)

 -George

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu1e0addb682c3c552fd97480037d4f8ff18e2b87e
baseline version:
 qemuuc8c0a1a784cdf70ecea50e93213137c6c89337a7

Last test of basis   106266  2017-02-28 15:45:39 Z2 days
Failing since106291  2017-03-01 06:20:41 Z1 days3 attempts
Testing same since   106356  2017-03-02 07:03:28 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Clement Deschamps 
  Cornelia Huck 
  Eric Auger 
  Fam Zheng 
  Farhan Ali 
  Franklin "Snaipe" Mathieu 
  Franklin \"Snaipe\" Mathieu 
  Greg Kurz 
  Igor Mammedov 
  Igor Pavlikevich 
  John Snow 
  Krzysztof Kozlowski 

Re: [Xen-devel] xen/arm and swiotlb-xen: possible data corruption

[Julien Grall]

Hi Edgar,

On 02/03/17 08:53, Edgar E. Iglesias wrote:

On Thu, Mar 02, 2017 at 09:38:37AM +0100, Edgar E. Iglesias wrote:

On Wed, Mar 01, 2017 at 05:05:21PM -0800, Stefano Stabellini wrote:

Hi all,

Edgar reported a data corruption on network packets in dom0 when the
swiotlb-xen is in use. He also reported that the following patch "fixes"
the problem for him:

 static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
 {
-   dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, 
DMA_MAP);
+   printk("%s: addr=%lx size=%zd\n", __func__, handle, size);
+   dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size + 64, 
dir, DMA_MAP);

I am thinking that the problem has something to do with cacheline
alignment on the Xen side
(xen/common/grant_table.c:__gnttab_cache_flush).

If op == GNTTAB_CACHE_INVAL, we call invalidate_dcache_va_range; if op
== GNTTAB_CACHE_CLEAN, we call clean_dcache_va_range instead. The
parameter, v, could be non-cacheline aligned.

invalidate_dcache_va_range is capable of handling a not aligned address,
while clean_dcache_va_range does not.

Edgar, does the appended patch fix the problem for you?



Thanks Stefano,

This does indeed fix the issue for me.



Hi again,

Looking at the code, the problem here is that we may flush one cache line
less than expected.

This smaller patch fixes it for me too:
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index c492d6d..fa1b4dd 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -325,7 +325,9 @@ static inline int clean_dcache_va_range(const void *p, 
unsigned long size)
 {
 const void *end;
 dsb(sy);   /* So the CPU issues all writes to the range */
-for ( end = p + size; p < end; p += cacheline_bytes )
+
+end = (void *)ROUNDUP((uintptr_t)p + size, cacheline_bytes);
+for ( ; p < end; p += cacheline_bytes )
 asm volatile (__clean_dcache_one(0) : : "r" (p));
 dsb(sy);   /* So we know the flushes happen before continuing */
 /* ARM callers assume that dcache_* functions cannot fail. */


Anyway, I'm OK with either fix.


I would prefer your version compare to Stefano's one.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Andrew Cooper]

On 02/03/17 17:29, Sander Eikelenboom wrote:
> On 02/03/17 15:55, Andrew Cooper wrote:
>> On 02/03/17 14:42, Sander Eikelenboom wrote:
>>> Hi Andrew / Jan,
>>>
>>> While testing current xen-unstable staging i ran into my host rebooting in 
>>> early kernel boot. 
>>> Bisection has turned up:
>>> 5cecf60f439e828f4bc0d2a368ced9a73b130cb7 is the first bad commit
>>> Author: Andrew Cooper 
>>> Date:   Fri Feb 17 17:10:50 2017 +
>>>
>>> x86/cpuid: Handle leaf 0x1 in guest_cpuid()
>>>
>>> Hardware is a AMD phenom x6.
>>> Below is the output of serial console of a failed boot.
>> Hmm.  Sorry for breaking this (although my AMD servers are booting fine).
> No problem, it is the staging branch of the unstable tree anyway ;-)
>
>> It is unfortunately not entirely obvious what Linux is objecting to, and
>> must be related to something visible in the emulated view.
>>
>> Does this delta make any difference?
> Yes it does, boots fine with this patch applied, thanks !

That is bad though. :s

It means that something in dom0 has an aversion to my attempt to lie
less about the topology.

Do you mind checking whether

res->b = cpuid_ebx(0x1) & 0xff00u;

causes is to break again?

That will confirm whether the breakage is to do with Logical Processors
Per Package (which I suspect is the case), or the APIC ID field (which
has always been unstable in the past).

~Andrew

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

Re: [Xen-devel] [PATCH v2 5/5] golang/xenlight: Add tests host related functionality functions

[Ian Jackson]

George Dunlap writes ("Re: [PATCH v2 5/5] golang/xenlight: Add tests host 
related functionality functions"):
> On 02/03/17 17:36, Ian Jackson wrote:
> > I assume this whole series is RFC still ?
> 
> I think the earlier patches looked pretty close to being checked in.  I
> think having a basic chunk of functionality checked in will make it
> easier to actually collaborate on improving things.

There is a lot of hand-crafted code here, whose semantics (eg, lists
of enum values and fields) which is copied from the libxl idl.

What this means is that the golang code may stop building, or (worse)
start to produce broken results, when the idl is updated.

Ian.

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

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

[Volodymyr Babchuk]

Hello,

Thank you all for the discussion. I want to summarize it a bit.

Looks like there are no objections about my initial list of
requirements. There was born another requirement in the discussion.
Thanks to Stefano for formulation it:

10. Domains on which the monitor privileged call feature is enabled
  (which is by default disabled for all domains) should not be able to
  issue firmware calls via SMCs/HVCs so that such calls reach the
  firmware directly. Xen should not bounce such calls to the firmware on
  behalf of the domain. Xen should not alter the state of the domain
  automatically (ie. incrementing PC). These calls should be exclusively
  transfered to the monitor subscriber for further processing.
  Hypercalls, virtual PSCI calls, virtual CPU services calls and virtual
  ARM architecture service calls remain unaffected.

Tamas, you have agreed with this, right?

So, looks like the HVC/SMC calls should be handled in the next way:

1.  Virtualized calls (like vPSCI) will be handled by hypervisor
2a. If a VM Monitor is installed for a domain, remaining calls will be
forwarded to the VM Monitor
2b. In another case, call will be forwarded to some other handler. In
absence of handler, SMCs from dom0 will be forwarded to firmware. All
other calls (HVCs or SMCs from domU) will cause Undefined Instruction
(Xilinx usecase).

Case 2b is to be discussed further. I like idea of EL0 handler, but as
I said on community call, I'm still working on the prototype.

Have I missed something?

On 11 February 2017 at 02:14, Volodymyr Babchuk  wrote:
> Hello,
>
> This e-mail is sort of follow-up to the two threads: [1] (my thread
> about TEE interaction) and [2] (Edgar's thread regarding handling SMC
> calls in platform_hvc). I want to discuss more broad topic there.
>
> Obviously, there are growing number of SMC users and current state of
> SMC handling in Xen satisfies nobody. My team wants to handle SMCs in
> secure way, Xilinx wants to forward some calls directly to Secure
> Monitor, while allowing to handle other in userspace, etc.
>
> My proposition is to gather all requirements to SMC (and HVC) handling
> in one place (e.g. in this mail thread). After we' will have clear
> picture of what we want, we will be able to develop some solution,
> that will satisfy us all. At least, I hope so :)
>
> Also I want to remind, that there are ARM document called "SMC Calling
> Convention" [3]. According to it, any aarch64 hypervisor "must
> implement the Standard Secure and Hypervisor Service calls". At this
> moment XEN does not conform to this.
>
> So, lets get started with the requirements:
> 0. There are no much difference between SMC and HVC handling (at least
> according to SMCCC).
> 1. Hypervisor should at least provide own UUID and version while
> called by SMC/HVC
> 2. Hypervisor should forward some calls from dom0 directly to Secure
> Monitor (Xilinx use case)
> 3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM
> architecture service calls, etc.
> 4. Hypervisor should handle TEE calls in a secure way (e.g. no
> untrusted handlers in Dom0 userspace).
> 5. Hypervisor should support multiple TEEs (at least at compilation time).
> 6. Hypervisor should do this as fast as possible (DRM playback use case).
> 7. All domains (including dom0) should be handled in the same way.
> 8. Not all domains will have right to issue certain SMCs.
> 9. Hypervisor will issue own SMCs in some cases.
>
> This is high-level requirements. Feel free to expand this list.
>
> Current SMC handling code does not even handle PSCI calls. Only HVC
> trap handler have branch to handle PSCI calls. SMCs are forwarded to
> VM monitor subsystem. There are even no advance_pc() call, so monitor
> needs to advance PC by itself. Also, dom0 can't have monitor, so there
> are no way to handle SMCs that originate from dom0. So, basically,
> current code does not meet any requirements from above list. This
> means that we can start from scratch and develop any solution.
>
> But at this moment I only want to gather requirements. So feel free to
> point at what I have missed.
>
> [1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg02220.html
> [2] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00635.html
> [3] 
> http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
> --
> WBR Volodymyr Babchuk aka lorc [+380976646013]
> mailto: vlad.babc...@gmail.com



-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

[Xen-devel] [PATCH v2 06/21] x86/xen: split off enlighten_pv.c

[Vitaly Kuznetsov]

Basically, enlighten.c is renamed to enlighten_pv.c and some code moved
out to common enlighten.c.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/Makefile   |4 +-
 arch/x86/xen/enlighten.c| 1626 ++-
 arch/x86/xen/enlighten_pv.c | 1552 +
 3 files changed, 1596 insertions(+), 1586 deletions(-)
 create mode 100644 arch/x86/xen/enlighten_pv.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 1bca75b..5ca8d3eb 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -7,13 +7,13 @@ endif
 
 # Make sure early boot has no stackprotector
 nostackp := $(call cc-option, -fno-stack-protector)
-CFLAGS_enlighten.o := $(nostackp)
+CFLAGS_enlighten_pv.o  := $(nostackp)
 CFLAGS_mmu.o   := $(nostackp)
 
 obj-y  := enlighten.o setup.o multicalls.o mmu.o irq.o \
time.o xen-asm.o xen-asm_$(BITS).o \
grant-table.o suspend.o platform-pci-unplug.o \
-   p2m.o apic.o pmu.o
+   p2m.o apic.o pmu.o enlighten_pv.o
 
 obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0cd99ad..4bd20bb 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1,92 +1,15 @@
-/*
- * Core of Xen paravirt_ops implementation.
- *
- * This file contains the xen_paravirt_ops structure itself, and the
- * implementations for:
- * - privileged instructions
- * - interrupt flags
- * - segment operations
- * - booting and setup
- *
- * Jeremy Fitzhardinge , XenSource Inc, 2007
- */
-
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
 #include 
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
-#include 
-#include 
 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 
-#ifdef CONFIG_ACPI
-#include 
-#include 
-#include 
-#include 
-#include 
-#endif
-
 #include "xen-ops.h"
-#include "mmu.h"
 #include "smp.h"
-#include "multicalls.h"
 #include "pmu.h"
 
 EXPORT_SYMBOL_GPL(hypercall_page);
@@ -133,14 +56,6 @@ EXPORT_SYMBOL_GPL(xen_start_info);
 
 struct shared_info xen_dummy_shared_info;
 
-void *xen_initial_gdt;
-
-RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
-
-static int xen_cpu_up_prepare_pv(unsigned int cpu);
-static int xen_cpu_up_online(unsigned int cpu);
-static int xen_cpu_dead_pv(unsigned int cpu);
-
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -162,18 +77,30 @@ struct shared_info *HYPERVISOR_shared_info = 
_dummy_shared_info;
  */
 int xen_have_vcpu_info_placement = 1;
 
-struct tls_descs {
-   struct desc_struct desc[3];
-};
+static int xen_cpu_up_online(unsigned int cpu)
+{
+   xen_init_lock_cpu(cpu);
+   return 0;
+}
 
-/*
- * Updating the 3 TLS descriptors in the GDT on every task switch is
- * surprisingly expensive so we avoid updating them if they haven't
- * changed.  Since Xen writes different descriptors than the one
- * passed in the update_descriptor hypercall we keep shadow copies to
- * compare against.
- */
-static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
+int xen_cpuhp_setup(int (*cpu_up_prepare_cb)(unsigned int),
+   int (*cpu_dead_cb)(unsigned int))
+{
+   int rc;
+
+   rc = cpuhp_setup_state_nocalls(CPUHP_XEN_PREPARE,
+  "x86/xen/hvm_guest:prepare",
+  cpu_up_prepare_cb, cpu_dead_cb);
+   if (rc >= 0) {
+   rc = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
+  "x86/xen/hvm_guest:online",
+  xen_cpu_up_online, NULL);
+   if (rc < 0)
+   cpuhp_remove_state_nocalls(CPUHP_XEN_PREPARE);
+   }
+
+   return rc >= 0 ? 0 : rc;
+}
 
 static void clamp_max_cpus(void)
 {
@@ -242,1511 +169,42 @@ void xen_vcpu_setup(int cpu)
}
 }
 
-/*
- * On restore, set the vcpu placement up again.
- * If it fails, then we're in a bad state, since
- * we can't back out from using it...
- */
-void xen_vcpu_restore(void)
+void xen_reboot(int reason)
 {
+   struct sched_shutdown r = { .reason = reason };
int cpu;
 
-   for_each_possible_cpu(cpu) {
-   bool other_cpu = (cpu != 

[Xen-devel] [PATCH v2 17/21] x86/xen: create stubs for HVM-only builds in page.h

[Vitaly Kuznetsov]

__pfn_to_mfn() is only used from PV code (mmu_pv.c, p2m.c) and from
page.h where all functions calling it check for
xen_feature(XENFEAT_auto_translated_physmap) first so we can replace
it with any stub to make build happy.

set_foreign_p2m_mapping()/clear_foreign_p2m_mapping() are used from
grant-table.c but only if !xen_feature(XENFEAT_auto_translated_physmap).

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/include/asm/xen/page.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 33cbd3d..0bf4bb34 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -51,12 +51,30 @@ extern bool __set_phys_to_machine(unsigned long pfn, 
unsigned long mfn);
 extern unsigned long __init set_phys_range_identity(unsigned long pfn_s,
unsigned long pfn_e);
 
+#ifdef CONFIG_XEN_PV
 extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
   struct gnttab_map_grant_ref *kmap_ops,
   struct page **pages, unsigned int count);
 extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 struct gnttab_unmap_grant_ref *kunmap_ops,
 struct page **pages, unsigned int count);
+#else
+static inline int
+set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
+   struct gnttab_map_grant_ref *kmap_ops,
+   struct page **pages, unsigned int count)
+{
+   return 0;
+}
+
+static inline int
+clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
+ struct gnttab_unmap_grant_ref *kunmap_ops,
+ struct page **pages, unsigned int count)
+{
+   return 0;
+}
+#endif
 
 /*
  * Helper functions to write or read unsigned long values to/from
@@ -72,6 +90,7 @@ static inline int xen_safe_read_ulong(unsigned long *addr, 
unsigned long *val)
return __get_user(*val, (unsigned long __user *)addr);
 }
 
+#ifdef CONFIG_XEN_PV
 /*
  * When to use pfn_to_mfn(), __pfn_to_mfn() or get_phys_to_machine():
  * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. No indicator
@@ -98,6 +117,12 @@ static inline unsigned long __pfn_to_mfn(unsigned long pfn)
 
return mfn;
 }
+#else
+static inline unsigned long __pfn_to_mfn(unsigned long pfn)
+{
+   return pfn;
+}
+#endif
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
 {
-- 
2.9.3


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

[Xen-devel] [PATCH v2 20/21] x86/xen: enable PVHVM-only builds

[Vitaly Kuznetsov]

Now everything is in place and we can move PV-only code under
CONFIG_XEN_PV. CONFIG_XEN_PV_SMP is created to support the change.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/Kconfig  | 4 
 arch/x86/xen/Makefile | 9 +
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 04284d9..aa8256b 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -21,6 +21,10 @@ config XEN_PV
help
  Support running as a Xen PV guest.
 
+config XEN_PV_SMP
+   def_bool y
+   depends on XEN_PV && SMP
+
 config XEN_DOM0
bool "Xen PV Dom0 support"
default y
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index f610651..fffb0a1 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -12,16 +12,17 @@ CFLAGS_mmu_pv.o := $(nostackp)
 
 obj-y  := enlighten.o multicalls.o mmu.o irq.o \
time.o xen-asm.o xen-asm_$(BITS).o \
-   grant-table.o suspend.o platform-pci-unplug.o \
-   p2m.o enlighten_pv.o mmu_pv.o
+   grant-table.o suspend.o platform-pci-unplug.o
 
 obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o 
suspend_hvm.o
-obj-$(CONFIG_XEN_PV)   += setup.o apic.o pmu.o suspend_pv.o
+obj-$(CONFIG_XEN_PV)   += setup.o apic.o pmu.o suspend_pv.o \
+   p2m.o enlighten_pv.o mmu_pv.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
-obj-$(CONFIG_SMP)  += smp.o smp_pv.o
+obj-$(CONFIG_SMP)  += smp.o
+obj-$(CONFIG_XEN_PV_SMP)   += smp_pv.o
 obj-$(CONFIG_XEN_PVHVM_SMP)+= smp_hvm.o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS) += debugfs.o
-- 
2.9.3


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

[Xen-devel] [PATCH v2 18/21] xen/balloon: decorate PV-only parts with #ifdef CONFIG_XEN_PV

[Vitaly Kuznetsov]

Balloon driver uses several PV-only concepts (xen_start_info,
xen_extra_mem,..) and it seems the simpliest solution to make HVM-only
build happy is to decorate these parts with #ifdefs.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/xen/balloon.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index db107fa..b11ca75 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -708,6 +708,7 @@ void free_xenballooned_pages(int nr_pages, struct page 
**pages)
 }
 EXPORT_SYMBOL(free_xenballooned_pages);
 
+#ifdef CONFIG_XEN_PV
 static void __init balloon_add_region(unsigned long start_pfn,
  unsigned long pages)
 {
@@ -731,19 +732,22 @@ static void __init balloon_add_region(unsigned long 
start_pfn,
 
balloon_stats.total_pages += extra_pfn_end - start_pfn;
 }
+#endif
 
 static int __init balloon_init(void)
 {
-   int i;
-
if (!xen_domain())
return -ENODEV;
 
pr_info("Initialising balloon driver\n");
 
+#ifdef CONFIG_XEN_PV
balloon_stats.current_pages = xen_pv_domain()
? min(xen_start_info->nr_pages - xen_released_pages, max_pfn)
: get_num_physpages();
+#else
+   balloon_stats.current_pages = get_num_physpages();
+#endif
balloon_stats.target_pages  = balloon_stats.current_pages;
balloon_stats.balloon_low   = 0;
balloon_stats.balloon_high  = 0;
@@ -760,14 +764,20 @@ static int __init balloon_init(void)
register_sysctl_table(xen_root);
 #endif
 
-   /*
-* Initialize the balloon with pages from the extra memory
-* regions (see arch/x86/xen/setup.c).
-*/
-   for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++)
-   if (xen_extra_mem[i].n_pfns)
-   balloon_add_region(xen_extra_mem[i].start_pfn,
-  xen_extra_mem[i].n_pfns);
+#ifdef CONFIG_XEN_PV
+   {
+   int i;
+
+   /*
+* Initialize the balloon with pages from the extra memory
+* regions (see arch/x86/xen/setup.c).
+*/
+   for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++)
+   if (xen_extra_mem[i].n_pfns)
+   balloon_add_region(xen_extra_mem[i].start_pfn,
+  xen_extra_mem[i].n_pfns);
+   }
+#endif
 
return 0;
 }
-- 
2.9.3


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

[Xen-devel] [PATCH v2 21/21] x86/xen: rename some PV-only functions in smp_pv.c

[Vitaly Kuznetsov]

After code split between PV and HVM some functions in xen_smp_ops have
xen_pv_ prefix and some only xen_ which makes them look like they're
common for both PV and HVM while they're not. Rename all the rest to
have xen_pv_ prefix.

Signed-off-by: Vitaly Kuznetsov 
---
- This patch is rather a matter of taste and it makes code archeology
 slightly harder, we may consider dropping it from the series.
---
 arch/x86/xen/smp_pv.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index e20718a..0110429 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -220,7 +220,7 @@ static void __init xen_pv_smp_prepare_boot_cpu(void)
xen_init_spinlocks();
 }
 
-static void __init xen_smp_prepare_cpus(unsigned int max_cpus)
+static void __init xen_pv_smp_prepare_cpus(unsigned int max_cpus)
 {
unsigned cpu;
unsigned int i;
@@ -336,7 +336,7 @@ cpu_initialize_context(unsigned int cpu, struct task_struct 
*idle)
return 0;
 }
 
-static int xen_cpu_up(unsigned int cpu, struct task_struct *idle)
+static int xen_pv_cpu_up(unsigned int cpu, struct task_struct *idle)
 {
int rc;
 
@@ -370,12 +370,12 @@ static int xen_cpu_up(unsigned int cpu, struct 
task_struct *idle)
return 0;
 }
 
-static void xen_smp_cpus_done(unsigned int max_cpus)
+static void xen_pv_smp_cpus_done(unsigned int max_cpus)
 {
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-static int xen_cpu_disable(void)
+static int xen_pv_cpu_disable(void)
 {
unsigned int cpu = smp_processor_id();
if (cpu == 0)
@@ -403,7 +403,7 @@ static void xen_pv_cpu_die(unsigned int cpu)
}
 }
 
-static void xen_play_dead(void) /* used only with HOTPLUG_CPU */
+static void xen_pv_play_dead(void) /* used only with HOTPLUG_CPU */
 {
play_dead_common();
HYPERVISOR_vcpu_op(VCPUOP_down, xen_vcpu_nr(smp_processor_id()), NULL);
@@ -420,7 +420,7 @@ static void xen_play_dead(void) /* used only with 
HOTPLUG_CPU */
 }
 
 #else /* !CONFIG_HOTPLUG_CPU */
-static int xen_cpu_disable(void)
+static int xen_pv_cpu_disable(void)
 {
return -ENOSYS;
 }
@@ -430,7 +430,7 @@ static void xen_pv_cpu_die(unsigned int cpu)
BUG();
 }
 
-static void xen_play_dead(void)
+static void xen_pv_play_dead(void)
 {
BUG();
 }
@@ -450,7 +450,7 @@ static void stop_self(void *v)
BUG();
 }
 
-static void xen_stop_other_cpus(int wait)
+static void xen_pv_stop_other_cpus(int wait)
 {
smp_call_function(stop_self, NULL, wait);
 }
@@ -477,15 +477,15 @@ static irqreturn_t xen_irq_work_interrupt(int irq, void 
*dev_id)
 
 static const struct smp_ops xen_smp_ops __initconst = {
.smp_prepare_boot_cpu = xen_pv_smp_prepare_boot_cpu,
-   .smp_prepare_cpus = xen_smp_prepare_cpus,
-   .smp_cpus_done = xen_smp_cpus_done,
+   .smp_prepare_cpus = xen_pv_smp_prepare_cpus,
+   .smp_cpus_done = xen_pv_smp_cpus_done,
 
-   .cpu_up = xen_cpu_up,
+   .cpu_up = xen_pv_cpu_up,
.cpu_die = xen_pv_cpu_die,
-   .cpu_disable = xen_cpu_disable,
-   .play_dead = xen_play_dead,
+   .cpu_disable = xen_pv_cpu_disable,
+   .play_dead = xen_pv_play_dead,
 
-   .stop_other_cpus = xen_stop_other_cpus,
+   .stop_other_cpus = xen_pv_stop_other_cpus,
.smp_send_reschedule = xen_smp_send_reschedule,
 
.send_call_func_ipi = xen_smp_send_call_function_ipi,
-- 
2.9.3


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

[Xen-devel] [PATCH v2 14/21] x86/xen: split suspend.c for PV and PVHVM guests

[Vitaly Kuznetsov]

Slit the code in suspend.c into suspend_pv.c and suspend_hvm.c.

Reviewed-by: Juergen Gross 
Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/Makefile  |  3 ++-
 arch/x86/xen/suspend.c | 54 --
 arch/x86/xen/suspend_hvm.c | 22 +++
 arch/x86/xen/suspend_pv.c  | 44 +
 arch/x86/xen/xen-ops.h | 13 +++
 5 files changed, 81 insertions(+), 55 deletions(-)
 create mode 100644 arch/x86/xen/suspend_hvm.c
 create mode 100644 arch/x86/xen/suspend_pv.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 8da1ca9..cf8d6c5 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -15,7 +15,8 @@ obj-y := enlighten.o setup.o multicalls.o mmu.o irq.o 
\
grant-table.o suspend.o platform-pci-unplug.o \
p2m.o apic.o pmu.o enlighten_pv.o mmu_pv.o
 
-obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o
+obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o 
suspend_hvm.o
+obj-$(CONFIG_XEN_PV)   += suspend_pv.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 7f664c4..d6b1680 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -14,60 +14,6 @@
 #include "mmu.h"
 #include "pmu.h"
 
-static void xen_pv_pre_suspend(void)
-{
-   xen_mm_pin_all();
-
-   xen_start_info->store_mfn = mfn_to_pfn(xen_start_info->store_mfn);
-   xen_start_info->console.domU.mfn =
-   mfn_to_pfn(xen_start_info->console.domU.mfn);
-
-   BUG_ON(!irqs_disabled());
-
-   HYPERVISOR_shared_info = _dummy_shared_info;
-   if (HYPERVISOR_update_va_mapping(fix_to_virt(FIX_PARAVIRT_BOOTMAP),
-__pte_ma(0), 0))
-   BUG();
-}
-
-static void xen_hvm_post_suspend(int suspend_cancelled)
-{
-#ifdef CONFIG_XEN_PVHVM
-   int cpu;
-   if (!suspend_cancelled)
-   xen_hvm_init_shared_info();
-   xen_callback_vector();
-   xen_unplug_emulated_devices();
-   if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
-   for_each_online_cpu(cpu) {
-   xen_setup_runstate_info(cpu);
-   }
-   }
-#endif
-}
-
-static void xen_pv_post_suspend(int suspend_cancelled)
-{
-   xen_build_mfn_list_list();
-
-   xen_setup_shared_info();
-
-   if (suspend_cancelled) {
-   xen_start_info->store_mfn =
-   pfn_to_mfn(xen_start_info->store_mfn);
-   xen_start_info->console.domU.mfn =
-   pfn_to_mfn(xen_start_info->console.domU.mfn);
-   } else {
-#ifdef CONFIG_SMP
-   BUG_ON(xen_cpu_initialized_map == NULL);
-   cpumask_copy(xen_cpu_initialized_map, cpu_online_mask);
-#endif
-   xen_vcpu_restore();
-   }
-
-   xen_mm_unpin_all();
-}
-
 void xen_arch_pre_suspend(void)
 {
if (xen_pv_domain())
diff --git a/arch/x86/xen/suspend_hvm.c b/arch/x86/xen/suspend_hvm.c
new file mode 100644
index 000..01afcad
--- /dev/null
+++ b/arch/x86/xen/suspend_hvm.c
@@ -0,0 +1,22 @@
+#include 
+
+#include 
+#include 
+#include 
+
+#include "xen-ops.h"
+
+void xen_hvm_post_suspend(int suspend_cancelled)
+{
+   int cpu;
+
+   if (!suspend_cancelled)
+   xen_hvm_init_shared_info();
+   xen_callback_vector();
+   xen_unplug_emulated_devices();
+   if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
+   for_each_online_cpu(cpu) {
+   xen_setup_runstate_info(cpu);
+   }
+   }
+}
diff --git a/arch/x86/xen/suspend_pv.c b/arch/x86/xen/suspend_pv.c
new file mode 100644
index 000..496decca
--- /dev/null
+++ b/arch/x86/xen/suspend_pv.c
@@ -0,0 +1,44 @@
+#include 
+
+#include 
+#include 
+
+#include "xen-ops.h"
+
+void xen_pv_pre_suspend(void)
+{
+   xen_mm_pin_all();
+
+   xen_start_info->store_mfn = mfn_to_pfn(xen_start_info->store_mfn);
+   xen_start_info->console.domU.mfn =
+   mfn_to_pfn(xen_start_info->console.domU.mfn);
+
+   BUG_ON(!irqs_disabled());
+
+   HYPERVISOR_shared_info = _dummy_shared_info;
+   if (HYPERVISOR_update_va_mapping(fix_to_virt(FIX_PARAVIRT_BOOTMAP),
+__pte_ma(0), 0))
+   BUG();
+}
+
+void xen_pv_post_suspend(int suspend_cancelled)
+{
+   xen_build_mfn_list_list();
+
+   xen_setup_shared_info();
+
+   if (suspend_cancelled) {
+   xen_start_info->store_mfn =
+   pfn_to_mfn(xen_start_info->store_mfn);
+   xen_start_info->console.domU.mfn =
+   pfn_to_mfn(xen_start_info->console.domU.mfn);
+   } else {
+#ifdef CONFIG_SMP
+   BUG_ON(xen_cpu_initialized_map == NULL);
+

[Xen-devel] [PATCH v2 11/21] x86/xen: split off smp_pv.c

[Vitaly Kuznetsov]

Basically, smp.c is renamed to smp_pv.c and some code moved out to common
smp.c. struct xen_common_irq delcaration ended up in smp.h.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/Makefile |   2 +-
 arch/x86/xen/smp.c| 487 +---
 arch/x86/xen/smp.h|   5 +
 arch/x86/xen/smp_pv.c | 499 ++
 4 files changed, 508 insertions(+), 485 deletions(-)
 create mode 100644 arch/x86/xen/smp_pv.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index bc7df8c..ebf3522 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_XEN_PVH) += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
-obj-$(CONFIG_SMP)  += smp.o
+obj-$(CONFIG_SMP)  += smp.o smp_pv.o
 obj-$(CONFIG_XEN_PVHVM_SMP)+= smp_hvm.o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS) += debugfs.o
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index c692336..82ac611 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -1,62 +1,21 @@
-/*
- * Xen SMP support
- *
- * This file implements the Xen versions of smp_ops.  SMP under Xen is
- * very straightforward.  Bringing a CPU up is simply a matter of
- * loading its initial context and setting it running.
- *
- * IPIs are handled through the Xen event mechanism.
- *
- * Because virtual CPUs can be scheduled onto any real CPU, there's no
- * useful topology information for the kernel to make use of.  As a
- * result, all CPUs are treated as if they're single-core and
- * single-threaded.
- */
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-
-#include 
-#include 
+#include 
+#include 
+#include 
 
-#include 
-#include 
 #include 
 
 #include 
 #include "xen-ops.h"
-#include "mmu.h"
 #include "smp.h"
-#include "pmu.h"
-
-cpumask_var_t xen_cpu_initialized_map;
 
-struct xen_common_irq {
-   int irq;
-   char *name;
-};
 static DEFINE_PER_CPU(struct xen_common_irq, xen_resched_irq) = { .irq = -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_callfunc_irq) = { .irq = -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_callfuncsingle_irq) = { .irq 
= -1 };
-static DEFINE_PER_CPU(struct xen_common_irq, xen_irq_work) = { .irq = -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_debug_irq) = { .irq = -1 };
-static DEFINE_PER_CPU(struct xen_common_irq, xen_pmu_irq) = { .irq = -1 };
 
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
 static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
-static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
 
 /*
  * Reschedule call back.
@@ -69,42 +28,6 @@ static irqreturn_t xen_reschedule_interrupt(int irq, void 
*dev_id)
return IRQ_HANDLED;
 }
 
-static void cpu_bringup(void)
-{
-   int cpu;
-
-   cpu_init();
-   touch_softlockup_watchdog();
-   preempt_disable();
-
-   /* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
-   if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
-   xen_enable_sysenter();
-   xen_enable_syscall();
-   }
-   cpu = smp_processor_id();
-   smp_store_cpu_info(cpu);
-   cpu_data(cpu).x86_max_cores = 1;
-   set_cpu_sibling_map(cpu);
-
-   xen_setup_cpu_clockevents();
-
-   notify_cpu_starting(cpu);
-
-   set_cpu_online(cpu, true);
-
-   cpu_set_state_online(cpu);  /* Implies full memory barrier. */
-
-   /* We can take interrupts now: we're officially "up". */
-   local_irq_enable();
-}
-
-asmlinkage __visible void cpu_bringup_and_idle(void)
-{
-   cpu_bringup();
-   cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
-}
-
 void xen_smp_intr_free(unsigned int cpu)
 {
if (per_cpu(xen_resched_irq, cpu).irq >= 0) {
@@ -134,23 +57,6 @@ void xen_smp_intr_free(unsigned int cpu)
}
 }
 
-void xen_smp_intr_free_pv(unsigned int cpu)
-{
-   if (per_cpu(xen_irq_work, cpu).irq >= 0) {
-   unbind_from_irqhandler(per_cpu(xen_irq_work, cpu).irq, NULL);
-   per_cpu(xen_irq_work, cpu).irq = -1;
-   kfree(per_cpu(xen_irq_work, cpu).name);
-   per_cpu(xen_irq_work, cpu).name = NULL;
-   }
-
-   if (per_cpu(xen_pmu_irq, cpu).irq >= 0) {
-   unbind_from_irqhandler(per_cpu(xen_pmu_irq, cpu).irq, NULL);
-   per_cpu(xen_pmu_irq, cpu).irq = -1;
-   kfree(per_cpu(xen_pmu_irq, cpu).name);
-   per_cpu(xen_pmu_irq, cpu).name = NULL;
-   }
-}
-
 int xen_smp_intr_init(unsigned int cpu)
 {
int rc;
@@ -208,360 +114,6 @@ int xen_smp_intr_init(unsigned int cpu)
return rc;
 }
 
-int xen_smp_intr_init_pv(unsigned int cpu)
-{
-   int rc;
-   char *callfunc_name, *pmu_name;
-
-   callfunc_name = 

[Xen-devel] [PATCH v2 12/21] x86/xen: split off mmu_hvm.c

[Vitaly Kuznetsov]

Move PVHVM related code to mmu_hvm.c.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/Makefile  |  2 +-
 arch/x86/xen/mmu.c | 74 --
 arch/x86/xen/mmu_hvm.c | 79 ++
 3 files changed, 80 insertions(+), 75 deletions(-)
 create mode 100644 arch/x86/xen/mmu_hvm.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index ebf3522..6a95a8b 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -15,7 +15,7 @@ obj-y := enlighten.o setup.o multicalls.o mmu.o irq.o 
\
grant-table.o suspend.o platform-pci-unplug.o \
p2m.o apic.o pmu.o enlighten_pv.o
 
-obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o
+obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index f6740b5..4dfcb06 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2689,80 +2689,6 @@ void xen_destroy_contiguous_region(phys_addr_t pstart, 
unsigned int order)
 }
 EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
 
-#ifdef CONFIG_XEN_PVHVM
-#ifdef CONFIG_PROC_VMCORE
-/*
- * This function is used in two contexts:
- * - the kdump kernel has to check whether a pfn of the crashed kernel
- *   was a ballooned page. vmcore is using this function to decide
- *   whether to access a pfn of the crashed kernel.
- * - the kexec kernel has to check whether a pfn was ballooned by the
- *   previous kernel. If the pfn is ballooned, handle it properly.
- * Returns 0 if the pfn is not backed by a RAM page, the caller may
- * handle the pfn special in this case.
- */
-static int xen_oldmem_pfn_is_ram(unsigned long pfn)
-{
-   struct xen_hvm_get_mem_type a = {
-   .domid = DOMID_SELF,
-   .pfn = pfn,
-   };
-   int ram;
-
-   if (HYPERVISOR_hvm_op(HVMOP_get_mem_type, ))
-   return -ENXIO;
-
-   switch (a.mem_type) {
-   case HVMMEM_mmio_dm:
-   ram = 0;
-   break;
-   case HVMMEM_ram_rw:
-   case HVMMEM_ram_ro:
-   default:
-   ram = 1;
-   break;
-   }
-
-   return ram;
-}
-#endif
-
-static void xen_hvm_exit_mmap(struct mm_struct *mm)
-{
-   struct xen_hvm_pagetable_dying a;
-   int rc;
-
-   a.domid = DOMID_SELF;
-   a.gpa = __pa(mm->pgd);
-   rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, );
-   WARN_ON_ONCE(rc < 0);
-}
-
-static int is_pagetable_dying_supported(void)
-{
-   struct xen_hvm_pagetable_dying a;
-   int rc = 0;
-
-   a.domid = DOMID_SELF;
-   a.gpa = 0x00;
-   rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, );
-   if (rc < 0) {
-   printk(KERN_DEBUG "HVMOP_pagetable_dying not supported\n");
-   return 0;
-   }
-   return 1;
-}
-
-void __init xen_hvm_init_mmu_ops(void)
-{
-   if (is_pagetable_dying_supported())
-   pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap;
-#ifdef CONFIG_PROC_VMCORE
-   register_oldmem_pfn_is_ram(_oldmem_pfn_is_ram);
-#endif
-}
-#endif
-
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c
new file mode 100644
index 000..1c57f1c
--- /dev/null
+++ b/arch/x86/xen/mmu_hvm.c
@@ -0,0 +1,79 @@
+#include 
+#include 
+
+#include 
+#include 
+
+#include "mmu.h"
+
+#ifdef CONFIG_PROC_VMCORE
+/*
+ * This function is used in two contexts:
+ * - the kdump kernel has to check whether a pfn of the crashed kernel
+ *   was a ballooned page. vmcore is using this function to decide
+ *   whether to access a pfn of the crashed kernel.
+ * - the kexec kernel has to check whether a pfn was ballooned by the
+ *   previous kernel. If the pfn is ballooned, handle it properly.
+ * Returns 0 if the pfn is not backed by a RAM page, the caller may
+ * handle the pfn special in this case.
+ */
+static int xen_oldmem_pfn_is_ram(unsigned long pfn)
+{
+   struct xen_hvm_get_mem_type a = {
+   .domid = DOMID_SELF,
+   .pfn = pfn,
+   };
+   int ram;
+
+   if (HYPERVISOR_hvm_op(HVMOP_get_mem_type, ))
+   return -ENXIO;
+
+   switch (a.mem_type) {
+   case HVMMEM_mmio_dm:
+   ram = 0;
+   break;
+   case HVMMEM_ram_rw:
+   case HVMMEM_ram_ro:
+   default:
+   ram = 1;
+   break;
+   }
+
+   return ram;
+}
+#endif
+
+static void xen_hvm_exit_mmap(struct mm_struct *mm)
+{
+   struct xen_hvm_pagetable_dying a;
+   int rc;
+
+   a.domid = DOMID_SELF;
+   a.gpa = __pa(mm->pgd);
+   rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, );
+   WARN_ON_ONCE(rc < 0);
+}
+
+static int is_pagetable_dying_supported(void)
+{
+   

[Xen-devel] [PATCH v2 16/21] x86/xen: define startup_xen for XEN PV only

[Vitaly Kuznetsov]

startup_xen references PV-only code, decorate it with #ifdef CONFIG_XEN_PV
to make PV-free builds possible.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/xen-head.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 37794e4..72a8e6a 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -16,6 +16,7 @@
 #include 
 #include 
 
+#ifdef CONFIG_XEN_PV
__INIT
 ENTRY(startup_xen)
cld
@@ -34,6 +35,7 @@ ENTRY(startup_xen)
jmp xen_start_kernel
 
__FINIT
+#endif
 
 .pushsection .text
.balign PAGE_SIZE
@@ -58,7 +60,9 @@ ENTRY(hypercall_page)
/* Map the p2m table to a 512GB-aligned user address. */
ELFNOTE(Xen, XEN_ELFNOTE_INIT_P2M,   .quad PGDIR_SIZE)
 #endif
+#ifdef CONFIG_XEN_PV
ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,  _ASM_PTR startup_xen)
+#endif
ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,
.ascii "!writable_page_tables|pae_pgdir_above_4gb")
-- 
2.9.3


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

[Xen-devel] [PATCH v2 19/21] xen: create xen_create/destroy_contiguous_region() stubs for PVHVM only builds

[Vitaly Kuznetsov]

xen_create_contiguous_region()/xen_create_contiguous_region() are PV-only,
they both contain xen_feature(XENFEAT_auto_translated_physmap) check and
bail in the very beginning.

Signed-off-by: Vitaly Kuznetsov 
---
 include/xen/xen-ops.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index b5486e6..f939114 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -34,11 +34,25 @@ u64 xen_steal_clock(int cpu);
 int xen_setup_shutdown_event(void);
 
 extern unsigned long *xen_contiguous_bitmap;
+
+#ifdef CONFIG_XEN_PV
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
unsigned int address_bits,
dma_addr_t *dma_handle);
 
 void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order);
+#else
+static inline int xen_create_contiguous_region(phys_addr_t pstart,
+  unsigned int order,
+  unsigned int address_bits,
+  dma_addr_t *dma_handle)
+{
+   return 0;
+}
+
+static inline void xen_destroy_contiguous_region(phys_addr_t pstart,
+unsigned int order) { }
+#endif
 
 struct vm_area_struct;
 
-- 
2.9.3


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

[Xen-devel] [PATCH v2 04/21] x86/xen: split off enlighten_pvh.c

[Vitaly Kuznetsov]

Create enlighten_pvh.c by splitting off PVH related code from enlighten.c,
put it under CONFIG_XEN_PVH.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/Makefile|   2 +
 arch/x86/xen/enlighten.c | 110 -
 arch/x86/xen/enlighten_pvh.c | 114 +++
 3 files changed, 116 insertions(+), 110 deletions(-)
 create mode 100644 arch/x86/xen/enlighten_pvh.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index cb0164a..348128b 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -15,6 +15,8 @@ obj-y := enlighten.o setup.o multicalls.o mmu.o irq.o 
\
grant-table.o suspend.o platform-pci-unplug.o \
p2m.o apic.o pmu.o
 
+obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
+
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
 obj-$(CONFIG_SMP)  += smp.o
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index de77be9..d66debd 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -179,20 +179,6 @@ struct tls_descs {
  */
 static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
 
-#ifdef CONFIG_XEN_PVH
-/*
- * PVH variables.
- *
- * xen_pvh and pvh_bootparams need to live in data segment since they
- * are used after startup_{32|64}, which clear .bss, are invoked.
- */
-bool xen_pvh __attribute__((section(".data"))) = 0;
-struct boot_params pvh_bootparams __attribute__((section(".data")));
-
-struct hvm_start_info pvh_start_info;
-unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
-#endif
-
 static void clamp_max_cpus(void)
 {
 #ifdef CONFIG_SMP
@@ -1674,102 +1660,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
 #endif
 }
 
-#ifdef CONFIG_XEN_PVH
-
-static void xen_pvh_arch_setup(void)
-{
-#ifdef CONFIG_ACPI
-   /* Make sure we don't fall back to (default) ACPI_IRQ_MODEL_PIC. */
-   if (nr_ioapics == 0)
-   acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
-#endif
-}
-
-static void __init init_pvh_bootparams(void)
-{
-   struct xen_memory_map memmap;
-   unsigned int i;
-   int rc;
-
-   memset(_bootparams, 0, sizeof(pvh_bootparams));
-
-   memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_map);
-   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_map);
-   rc = HYPERVISOR_memory_op(XENMEM_memory_map, );
-   if (rc) {
-   xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
-   BUG();
-   }
-
-   if (memmap.nr_entries < E820MAX - 1) {
-   pvh_bootparams.e820_map[memmap.nr_entries].addr =
-   ISA_START_ADDRESS;
-   pvh_bootparams.e820_map[memmap.nr_entries].size =
-   ISA_END_ADDRESS - ISA_START_ADDRESS;
-   pvh_bootparams.e820_map[memmap.nr_entries].type =
-   E820_RESERVED;
-   memmap.nr_entries++;
-   } else
-   xen_raw_printk("Warning: Can fit ISA range into e820\n");
-
-   sanitize_e820_map(pvh_bootparams.e820_map,
- ARRAY_SIZE(pvh_bootparams.e820_map),
- _entries);
-
-   pvh_bootparams.e820_entries = memmap.nr_entries;
-   for (i = 0; i < pvh_bootparams.e820_entries; i++)
-   e820_add_region(pvh_bootparams.e820_map[i].addr,
-   pvh_bootparams.e820_map[i].size,
-   pvh_bootparams.e820_map[i].type);
-
-   pvh_bootparams.hdr.cmd_line_ptr =
-   pvh_start_info.cmdline_paddr;
-
-   /* The first module is always ramdisk. */
-   if (pvh_start_info.nr_modules) {
-   struct hvm_modlist_entry *modaddr =
-   __va(pvh_start_info.modlist_paddr);
-   pvh_bootparams.hdr.ramdisk_image = modaddr->paddr;
-   pvh_bootparams.hdr.ramdisk_size = modaddr->size;
-   }
-
-   /*
-* See Documentation/x86/boot.txt.
-*
-* Version 2.12 supports Xen entry point but we will use default x86/PC
-* environment (i.e. hardware_subarch 0).
-*/
-   pvh_bootparams.hdr.version = 0x212;
-   pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
-}
-
-/*
- * This routine (and those that it might call) should not use
- * anything that lives in .bss since that segment will be cleared later.
- */
-void __init xen_prepare_pvh(void)
-{
-   u32 msr;
-   u64 pfn;
-
-   if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
-   xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
-   pvh_start_info.magic);
-   BUG();
-   }
-
-   xen_pvh = 1;
-
-   msr = cpuid_ebx(xen_cpuid_base() + 2);
-   pfn = __pa(hypercall_page);
-   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
-
-   init_pvh_bootparams();
-
-   x86_init.oem.arch_setup = 

[Xen-devel] [PATCH v2 15/21] x86/xen: put setup.c, pmu.c and apic.c under CONFIG_XEN_PV

[Vitaly Kuznetsov]

xen_pmu_init/finish() functions are used in suspend.c and
enlighten.c, add stubs for now.

Reviewed-by: Juergen Gross 
Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/Kconfig  | 2 +-
 arch/x86/xen/Makefile | 6 +++---
 arch/x86/xen/pmu.h| 5 +
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index dae8dc6..04284d9 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -6,7 +6,6 @@ config XEN
bool "Xen guest support"
depends on PARAVIRT
select PARAVIRT_CLOCK
-   select XEN_HAVE_VPMU
depends on X86_64 || (X86_32 && X86_PAE)
depends on X86_LOCAL_APIC && X86_TSC
help
@@ -18,6 +17,7 @@ config XEN_PV
bool "Xen PV guest support"
default y
depends on XEN
+   select XEN_HAVE_VPMU
help
  Support running as a Xen PV guest.
 
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index cf8d6c5..f610651 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -10,13 +10,13 @@ nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_enlighten_pv.o  := $(nostackp)
 CFLAGS_mmu_pv.o:= $(nostackp)
 
-obj-y  := enlighten.o setup.o multicalls.o mmu.o irq.o \
+obj-y  := enlighten.o multicalls.o mmu.o irq.o \
time.o xen-asm.o xen-asm_$(BITS).o \
grant-table.o suspend.o platform-pci-unplug.o \
-   p2m.o apic.o pmu.o enlighten_pv.o mmu_pv.o
+   p2m.o enlighten_pv.o mmu_pv.o
 
 obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o 
suspend_hvm.o
-obj-$(CONFIG_XEN_PV)   += suspend_pv.o
+obj-$(CONFIG_XEN_PV)   += setup.o apic.o pmu.o suspend_pv.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
diff --git a/arch/x86/xen/pmu.h b/arch/x86/xen/pmu.h
index af5f0ad..4be5355 100644
--- a/arch/x86/xen/pmu.h
+++ b/arch/x86/xen/pmu.h
@@ -4,8 +4,13 @@
 #include 
 
 irqreturn_t xen_pmu_irq_handler(int irq, void *dev_id);
+#ifdef CONFIG_XEN_HAVE_VPMU
 void xen_pmu_init(int cpu);
 void xen_pmu_finish(int cpu);
+#else
+static inline void xen_pmu_init(int cpu) {}
+static inline void xen_pmu_finish(int cpu) {}
+#endif
 bool is_xen_pmu(int cpu);
 bool pmu_msr_read(unsigned int msr, uint64_t *val, int *err);
 bool pmu_msr_write(unsigned int msr, uint32_t low, uint32_t high, int *err);
-- 
2.9.3


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

[Xen-devel] [PATCH v2 07/21] x86/xen: split xen_smp_intr_init()/xen_smp_intr_free()

[Vitaly Kuznetsov]

xen_smp_intr_init() and xen_smp_intr_free() have PV-specific code and as
a praparatory change to splitting smp.c we need to split these fucntions.
Create xen_smp_intr_init_pv()/xen_smp_intr_free_pv().

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/enlighten_pv.c |  9 +
 arch/x86/xen/smp.c  | 29 ++---
 arch/x86/xen/smp.h  |  8 
 3 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index b9ff23c..acfd896 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1478,12 +1478,21 @@ static int xen_cpu_up_prepare_pv(unsigned int cpu)
 cpu, rc);
return rc;
}
+
+   rc = xen_smp_intr_init_pv(cpu);
+   if (rc) {
+   WARN(1, "xen_smp_intr_init_pv() for CPU %d failed: %d\n",
+cpu, rc);
+   return rc;
+   }
+
return 0;
 }
 
 static int xen_cpu_dead_pv(unsigned int cpu)
 {
xen_smp_intr_free(cpu);
+   xen_smp_intr_free_pv(cpu);
 
xen_teardown_timer(cpu);
 
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 0dee6f5..ff6aaff 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -132,9 +132,10 @@ void xen_smp_intr_free(unsigned int cpu)
kfree(per_cpu(xen_callfuncsingle_irq, cpu).name);
per_cpu(xen_callfuncsingle_irq, cpu).name = NULL;
}
-   if (xen_hvm_domain())
-   return;
+}
 
+void xen_smp_intr_free_pv(unsigned int cpu)
+{
if (per_cpu(xen_irq_work, cpu).irq >= 0) {
unbind_from_irqhandler(per_cpu(xen_irq_work, cpu).irq, NULL);
per_cpu(xen_irq_work, cpu).irq = -1;
@@ -148,11 +149,12 @@ void xen_smp_intr_free(unsigned int cpu)
kfree(per_cpu(xen_pmu_irq, cpu).name);
per_cpu(xen_pmu_irq, cpu).name = NULL;
}
-};
+}
+
 int xen_smp_intr_init(unsigned int cpu)
 {
int rc;
-   char *resched_name, *callfunc_name, *debug_name, *pmu_name;
+   char *resched_name, *callfunc_name, *debug_name;
 
resched_name = kasprintf(GFP_KERNEL, "resched%d", cpu);
rc = bind_ipi_to_irqhandler(XEN_RESCHEDULE_VECTOR,
@@ -199,12 +201,17 @@ int xen_smp_intr_init(unsigned int cpu)
per_cpu(xen_callfuncsingle_irq, cpu).irq = rc;
per_cpu(xen_callfuncsingle_irq, cpu).name = callfunc_name;
 
-   /*
-* The IRQ worker on PVHVM goes through the native path and uses the
-* IPI mechanism.
-*/
-   if (xen_hvm_domain())
-   return 0;
+   return 0;
+
+ fail:
+   xen_smp_intr_free(cpu);
+   return rc;
+}
+
+int xen_smp_intr_init_pv(unsigned int cpu)
+{
+   int rc;
+   char *callfunc_name, *pmu_name;
 
callfunc_name = kasprintf(GFP_KERNEL, "irqwork%d", cpu);
rc = bind_ipi_to_irqhandler(XEN_IRQ_WORK_VECTOR,
@@ -233,7 +240,7 @@ int xen_smp_intr_init(unsigned int cpu)
return 0;
 
  fail:
-   xen_smp_intr_free(cpu);
+   xen_smp_intr_free_pv(cpu);
return rc;
 }
 
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
index 9beef33..a059adb 100644
--- a/arch/x86/xen/smp.h
+++ b/arch/x86/xen/smp.h
@@ -11,6 +11,8 @@ extern void xen_send_IPI_self(int vector);
 
 extern int xen_smp_intr_init(unsigned int cpu);
 extern void xen_smp_intr_free(unsigned int cpu);
+extern int xen_smp_intr_init_pv(unsigned int cpu);
+extern void xen_smp_intr_free_pv(unsigned int cpu);
 
 #else /* CONFIG_SMP */
 
@@ -19,6 +21,12 @@ static inline int xen_smp_intr_init(unsigned int cpu)
return 0;
 }
 static inline void xen_smp_intr_free(unsigned int cpu) {}
+
+static inline int xen_smp_intr_init_pv(unsigned int cpu)
+{
+   return 0;
+}
+static inline void xen_smp_intr_free_pv(unsigned int cpu) {}
 #endif /* CONFIG_SMP */
 
 #endif
-- 
2.9.3


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

[Xen-devel] [PATCH v2 09/21] x86/xen: split xen_cpu_die()

[Vitaly Kuznetsov]

Split xen_cpu_die() into xen_pv_cpu_die() and xen_hvm_cpu_die() to support
further splitting of smp.c.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/smp.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 6c8a3a5..6c4b415 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -513,10 +513,10 @@ static int xen_cpu_disable(void)
return 0;
 }
 
-static void xen_cpu_die(unsigned int cpu)
+static void xen_pv_cpu_die(unsigned int cpu)
 {
-   while (xen_pv_domain() && HYPERVISOR_vcpu_op(VCPUOP_is_up,
-xen_vcpu_nr(cpu), NULL)) {
+   while (HYPERVISOR_vcpu_op(VCPUOP_is_up,
+ xen_vcpu_nr(cpu), NULL)) {
__set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(HZ/10);
}
@@ -529,6 +529,15 @@ static void xen_cpu_die(unsigned int cpu)
}
 }
 
+static void xen_hvm_cpu_die(unsigned int cpu)
+{
+   if (common_cpu_die(cpu) == 0) {
+   xen_smp_intr_free(cpu);
+   xen_uninit_lock_cpu(cpu);
+   xen_teardown_timer(cpu);
+   }
+}
+
 static void xen_play_dead(void) /* used only with HOTPLUG_CPU */
 {
play_dead_common();
@@ -551,7 +560,12 @@ static int xen_cpu_disable(void)
return -ENOSYS;
 }
 
-static void xen_cpu_die(unsigned int cpu)
+static void xen_pv_cpu_die(unsigned int cpu)
+{
+   BUG();
+}
+
+static void xen_hvm_cpu_die(unsigned int cpu)
 {
BUG();
 }
@@ -732,7 +746,7 @@ static const struct smp_ops xen_smp_ops __initconst = {
.smp_cpus_done = xen_smp_cpus_done,
 
.cpu_up = xen_cpu_up,
-   .cpu_die = xen_cpu_die,
+   .cpu_die = xen_pv_cpu_die,
.cpu_disable = xen_cpu_disable,
.play_dead = xen_play_dead,
 
@@ -761,7 +775,7 @@ void __init xen_hvm_smp_init(void)
 {
smp_ops.smp_prepare_cpus = xen_hvm_smp_prepare_cpus;
smp_ops.smp_send_reschedule = xen_smp_send_reschedule;
-   smp_ops.cpu_die = xen_cpu_die;
+   smp_ops.cpu_die = xen_hvm_cpu_die;
smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi;
smp_ops.send_call_func_single_ipi = 
xen_smp_send_call_function_single_ipi;
smp_ops.smp_prepare_boot_cpu = xen_hvm_smp_prepare_boot_cpu;
-- 
2.9.3


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

[Xen-devel] [PATCH v2 02/21] x86/xen: globalize have_vcpu_info_placement

[Vitaly Kuznetsov]

have_vcpu_info_placement applies to both PV and HVM and as we're going
to split the code we need to make it global.

Rename to xen_have_vcpu_info_placement.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/enlighten.c | 12 ++--
 arch/x86/xen/xen-ops.h   |  2 ++
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4c1a582..de77be9 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -164,7 +164,7 @@ struct shared_info *HYPERVISOR_shared_info = 
_dummy_shared_info;
  *
  * 0: not available, 1: available
  */
-static int have_vcpu_info_placement = 1;
+int xen_have_vcpu_info_placement = 1;
 
 struct tls_descs {
struct desc_struct desc[3];
@@ -228,7 +228,7 @@ void xen_vcpu_setup(int cpu)
per_cpu(xen_vcpu, cpu) =
_shared_info->vcpu_info[xen_vcpu_nr(cpu)];
 
-   if (!have_vcpu_info_placement) {
+   if (!xen_have_vcpu_info_placement) {
if (cpu >= MAX_VIRT_CPUS)
clamp_max_cpus();
return;
@@ -251,7 +251,7 @@ void xen_vcpu_setup(int cpu)
 
if (err) {
printk(KERN_DEBUG "register_vcpu_info failed: err=%d\n", err);
-   have_vcpu_info_placement = 0;
+   xen_have_vcpu_info_placement = 0;
clamp_max_cpus();
} else {
/* This cpu is using the registered vcpu info, even if
@@ -280,7 +280,7 @@ void xen_vcpu_restore(void)
 
xen_setup_runstate_info(cpu);
 
-   if (have_vcpu_info_placement)
+   if (xen_have_vcpu_info_placement)
xen_vcpu_setup(cpu);
 
if (other_cpu && is_up &&
@@ -1159,7 +1159,7 @@ void xen_setup_vcpu_info_placement(void)
 * xen_vcpu_setup managed to place the vcpu_info within the
 * percpu area for all cpus, so make use of it.
 */
-   if (have_vcpu_info_placement) {
+   if (xen_have_vcpu_info_placement) {
pv_irq_ops.save_fl = __PV_IS_CALLEE_SAVE(xen_save_fl_direct);
pv_irq_ops.restore_fl = 
__PV_IS_CALLEE_SAVE(xen_restore_fl_direct);
pv_irq_ops.irq_disable = 
__PV_IS_CALLEE_SAVE(xen_irq_disable_direct);
@@ -1178,7 +1178,7 @@ static unsigned xen_patch(u8 type, u16 clobbers, void 
*insnbuf,
 
 #define SITE(op, x)\
case PARAVIRT_PATCH(op.x):  \
-   if (have_vcpu_info_placement) { \
+   if (xen_have_vcpu_info_placement) { \
start = (char *)xen_##x##_direct;   \
end = xen_##x##_direct_end; \
reloc = xen_##x##_direct_reloc; \
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index f6a41c4..2b162f6 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -76,6 +76,8 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id);
 
 bool xen_vcpu_stolen(int vcpu);
 
+extern int xen_have_vcpu_info_placement;
+
 void xen_vcpu_setup(int cpu);
 void xen_setup_vcpu_info_placement(void);
 
-- 
2.9.3


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

[Xen-devel] [PATCH v2 05/21] x86/xen: split off enlighten_hvm.c

[Vitaly Kuznetsov]

Move PVHVM related code to enlighten_hvm.c. Three functions:
xen_cpuhp_setup(), xen_reboot(), xen_emergency_restart() are shared, drop
static qualifier from them. These functions will go to common code once
it is split from enlighten.c.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/Makefile|   1 +
 arch/x86/xen/enlighten.c | 209 +-
 arch/x86/xen/enlighten_hvm.c | 210 +++
 arch/x86/xen/xen-ops.h   |   6 ++
 4 files changed, 221 insertions(+), 205 deletions(-)
 create mode 100644 arch/x86/xen/enlighten_hvm.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 348128b..1bca75b 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -15,6 +15,7 @@ obj-y := enlighten.o setup.o multicalls.o mmu.o irq.o 
\
grant-table.o suspend.o platform-pci-unplug.o \
p2m.o apic.o pmu.o
 
+obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d66debd..0cd99ad 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,10 +45,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -140,10 +138,8 @@ void *xen_initial_gdt;
 RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 
 static int xen_cpu_up_prepare_pv(unsigned int cpu);
-static int xen_cpu_up_prepare_hvm(unsigned int cpu);
 static int xen_cpu_up_online(unsigned int cpu);
 static int xen_cpu_dead_pv(unsigned int cpu);
-static int xen_cpu_dead_hvm(unsigned int cpu);
 
 /*
  * Point at some empty memory to start with. We map the real shared_info
@@ -1282,7 +1278,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
.end_context_switch = xen_end_context_switch,
 };
 
-static void xen_reboot(int reason)
+void xen_reboot(int reason)
 {
struct sched_shutdown r = { .reason = reason };
int cpu;
@@ -1299,7 +1295,7 @@ static void xen_restart(char *msg)
xen_reboot(SHUTDOWN_reboot);
 }
 
-static void xen_emergency_restart(void)
+void xen_emergency_restart(void)
 {
xen_reboot(SHUTDOWN_reboot);
 }
@@ -1435,8 +1431,8 @@ static void __init xen_dom0_set_legacy_features(void)
x86_platform.legacy.rtc = 1;
 }
 
-static int xen_cpuhp_setup(int (*cpu_up_prepare_cb)(unsigned int),
-  int (*cpu_dead_cb)(unsigned int))
+int xen_cpuhp_setup(int (*cpu_up_prepare_cb)(unsigned int),
+   int (*cpu_dead_cb)(unsigned int))
 {
int rc;
 
@@ -1660,79 +1656,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
 #endif
 }
 
-void __ref xen_hvm_init_shared_info(void)
-{
-   int cpu;
-   struct xen_add_to_physmap xatp;
-   static struct shared_info *shared_info_page = 0;
-
-   if (!shared_info_page)
-   shared_info_page = (struct shared_info *)
-   extend_brk(PAGE_SIZE, PAGE_SIZE);
-   xatp.domid = DOMID_SELF;
-   xatp.idx = 0;
-   xatp.space = XENMAPSPACE_shared_info;
-   xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
-   if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, ))
-   BUG();
-
-   HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
-
-   /* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
-* page, we use it in the event channel upcall and in some pvclock
-* related functions. We don't need the vcpu_info placement
-* optimizations because we don't use any pv_mmu or pv_irq op on
-* HVM.
-* When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
-* online but xen_hvm_init_shared_info is run at resume time too and
-* in that case multiple vcpus might be online. */
-   for_each_online_cpu(cpu) {
-   /* Leave it to be NULL. */
-   if (xen_vcpu_nr(cpu) >= MAX_VIRT_CPUS)
-   continue;
-   per_cpu(xen_vcpu, cpu) =
-   _shared_info->vcpu_info[xen_vcpu_nr(cpu)];
-   }
-}
-
-#ifdef CONFIG_XEN_PVHVM
-static void __init init_hvm_pv_info(void)
-{
-   int major, minor;
-   uint32_t eax, ebx, ecx, edx, base;
-
-   base = xen_cpuid_base();
-   eax = cpuid_eax(base + 1);
-
-   major = eax >> 16;
-   minor = eax & 0x;
-   printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
-
-   xen_domain_type = XEN_HVM_DOMAIN;
-
-   /* PVH set up hypercall page in xen_prepare_pvh(). */
-   if (xen_pvh_domain())
-   pv_info.name = "Xen PVH";
-   else {
-   u64 pfn;
-   uint32_t msr;
-
-   pv_info.name = "Xen HVM";
-   msr = cpuid_ebx(base + 2);
-   pfn = __pa(hypercall_page);
-   wrmsr_safe(msr, 

[Xen-devel] [PATCH v2 03/21] x86/xen: add CONFIG_XEN_PV to Kconfig

[Vitaly Kuznetsov]

All code to supprot Xen PV will get under this new option. For the
beginning, check for it in the common code.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/kernel/cpu/hypervisor.c |  4 +++-
 arch/x86/kernel/process_64.c |  2 +-
 arch/x86/xen/Kconfig | 23 ++-
 3 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index a77f18d..ce6fcc3 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -28,8 +28,10 @@
 
 static const __initconst struct hypervisor_x86 * const hypervisors[] =
 {
-#ifdef CONFIG_XEN
+#ifdef CONFIG_XEN_PV
_hyper_xen_pv,
+#endif
+#ifdef CONFIG_XEN_PVHVM
_hyper_xen_hvm,
 #endif
_hyper_vmware,
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index a61e141..5e8d129 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -438,7 +438,7 @@ __switch_to(struct task_struct *prev_p, struct task_struct 
*next_p)
 task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV))
__switch_to_xtra(prev_p, next_p, tss);
 
-#ifdef CONFIG_XEN
+#ifdef CONFIG_XEN_PV
/*
 * On Xen PV, IOPL bits in pt_regs->flags have no effect, and
 * current_pt_regs()->flags may not match the current task's
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 76b6dbd..c387560 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -6,7 +6,6 @@ config XEN
bool "Xen guest support"
depends on PARAVIRT
select PARAVIRT_CLOCK
-   select XEN_HAVE_PVMMU
select XEN_HAVE_VPMU
depends on X86_64 || (X86_32 && X86_PAE)
depends on X86_LOCAL_APIC && X86_TSC
@@ -15,18 +14,32 @@ config XEN
  kernel to boot in a paravirtualized environment under the
  Xen hypervisor.
 
+config XEN_PV
+   bool "Xen PV guest support"
+   default y
+   depends on XEN
+   help
+ Support running as a Xen PV guest.
+
 config XEN_DOM0
-   def_bool y
-   depends on XEN && PCI_XEN && SWIOTLB_XEN
+   bool "Xen PV Dom0 support"
+   default y
+   depends on XEN_PV && PCI_XEN && SWIOTLB_XEN
depends on X86_IO_APIC && ACPI && PCI
+   select XEN_HAVE_PVMMU
+   help
+ Support running as a Xen PV Dom0 guest.
 
 config XEN_PVHVM
-   def_bool y
+   bool "Xen PVHVM guest support"
+   default y
depends on XEN && PCI && X86_LOCAL_APIC
+   help
+ Support running as a Xen PVHVM guest.
 
 config XEN_512GB
bool "Limit Xen pv-domain memory to 512GB"
-   depends on XEN && X86_64
+   depends on XEN_PV && X86_64
default y
help
  Limit paravirtualized user domains to 512GB of RAM.
-- 
2.9.3


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

[Xen-devel] [PATCH v2 08/21] x86/xen: split xen_smp_prepare_boot_cpu()

[Vitaly Kuznetsov]

Split xen_smp_prepare_boot_cpu() into xen_pv_smp_prepare_boot_cpu() and
xen_hvm_smp_prepare_boot_cpu() to support further splitting of smp.c.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/smp.c | 49 ++---
 1 file changed, 30 insertions(+), 19 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index ff6aaff..6c8a3a5 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -296,35 +296,46 @@ static void __init xen_filter_cpu_maps(void)
 
 }
 
-static void __init xen_smp_prepare_boot_cpu(void)
+static void __init xen_pv_smp_prepare_boot_cpu(void)
 {
BUG_ON(smp_processor_id() != 0);
native_smp_prepare_boot_cpu();
 
-   if (xen_pv_domain()) {
-   if (!xen_feature(XENFEAT_writable_page_tables))
-   /* We've switched to the "real" per-cpu gdt, so make
-* sure the old memory can be recycled. */
-   make_lowmem_page_readwrite(xen_initial_gdt);
+   if (!xen_feature(XENFEAT_writable_page_tables))
+   /* We've switched to the "real" per-cpu gdt, so make
+* sure the old memory can be recycled. */
+   make_lowmem_page_readwrite(xen_initial_gdt);
 
 #ifdef CONFIG_X86_32
-   /*
-* Xen starts us with XEN_FLAT_RING1_DS, but linux code
-* expects __USER_DS
-*/
-   loadsegment(ds, __USER_DS);
-   loadsegment(es, __USER_DS);
+   /*
+* Xen starts us with XEN_FLAT_RING1_DS, but linux code
+* expects __USER_DS
+*/
+   loadsegment(ds, __USER_DS);
+   loadsegment(es, __USER_DS);
 #endif
 
-   xen_filter_cpu_maps();
-   xen_setup_vcpu_info_placement();
-   }
+   xen_filter_cpu_maps();
+   xen_setup_vcpu_info_placement();
+
+   /*
+* The alternative logic (which patches the unlock/lock) runs before
+* the smp bootup up code is activated. Hence we need to set this up
+* the core kernel is being patched. Otherwise we will have only
+* modules patched but not core code.
+*/
+   xen_init_spinlocks();
+}
+
+static void __init xen_hvm_smp_prepare_boot_cpu(void)
+{
+   BUG_ON(smp_processor_id() != 0);
+   native_smp_prepare_boot_cpu();
 
/*
 * Setup vcpu_info for boot CPU.
 */
-   if (xen_hvm_domain())
-   xen_vcpu_setup(0);
+   xen_vcpu_setup(0);
 
/*
 * The alternative logic (which patches the unlock/lock) runs before
@@ -716,7 +727,7 @@ static irqreturn_t xen_irq_work_interrupt(int irq, void 
*dev_id)
 }
 
 static const struct smp_ops xen_smp_ops __initconst = {
-   .smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu,
+   .smp_prepare_boot_cpu = xen_pv_smp_prepare_boot_cpu,
.smp_prepare_cpus = xen_smp_prepare_cpus,
.smp_cpus_done = xen_smp_cpus_done,
 
@@ -753,5 +764,5 @@ void __init xen_hvm_smp_init(void)
smp_ops.cpu_die = xen_cpu_die;
smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi;
smp_ops.send_call_func_single_ipi = 
xen_smp_send_call_function_single_ipi;
-   smp_ops.smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu;
+   smp_ops.smp_prepare_boot_cpu = xen_hvm_smp_prepare_boot_cpu;
 }
-- 
2.9.3


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

[Xen-devel] [PATCH v2 10/21] x86/xen: split off smp_hvm.c

[Vitaly Kuznetsov]

Move PVHVM related code to smp_hvm.c. Drop 'static' qualifier from
xen_smp_send_reschedule(), xen_smp_send_call_function_ipi(),
xen_smp_send_call_function_single_ipi(), these functions will be moved to
common smp code when smp_pv.c is split.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/Kconfig   |  4 
 arch/x86/xen/Makefile  |  1 +
 arch/x86/xen/smp.c | 57 +++--
 arch/x86/xen/smp.h |  3 +++
 arch/x86/xen/smp_hvm.c | 58 ++
 5 files changed, 69 insertions(+), 54 deletions(-)
 create mode 100644 arch/x86/xen/smp_hvm.c

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index c387560..dae8dc6 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -37,6 +37,10 @@ config XEN_PVHVM
help
  Support running as a Xen PVHVM guest.
 
+config XEN_PVHVM_SMP
+   def_bool y
+   depends on XEN_PVHVM && SMP
+
 config XEN_512GB
bool "Limit Xen pv-domain memory to 512GB"
depends on XEN_PV && X86_64
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 5ca8d3eb..bc7df8c 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_XEN_PVH) += enlighten_pvh.o
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
 obj-$(CONFIG_SMP)  += smp.o
+obj-$(CONFIG_XEN_PVHVM_SMP)+= smp_hvm.o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS) += debugfs.o
 obj-$(CONFIG_XEN_DOM0) += vga.o
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 6c4b415..c692336 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -327,25 +327,6 @@ static void __init xen_pv_smp_prepare_boot_cpu(void)
xen_init_spinlocks();
 }
 
-static void __init xen_hvm_smp_prepare_boot_cpu(void)
-{
-   BUG_ON(smp_processor_id() != 0);
-   native_smp_prepare_boot_cpu();
-
-   /*
-* Setup vcpu_info for boot CPU.
-*/
-   xen_vcpu_setup(0);
-
-   /*
-* The alternative logic (which patches the unlock/lock) runs before
-* the smp bootup up code is activated. Hence we need to set this up
-* the core kernel is being patched. Otherwise we will have only
-* modules patched but not core code.
-*/
-   xen_init_spinlocks();
-}
-
 static void __init xen_smp_prepare_cpus(unsigned int max_cpus)
 {
unsigned cpu;
@@ -529,15 +510,6 @@ static void xen_pv_cpu_die(unsigned int cpu)
}
 }
 
-static void xen_hvm_cpu_die(unsigned int cpu)
-{
-   if (common_cpu_die(cpu) == 0) {
-   xen_smp_intr_free(cpu);
-   xen_uninit_lock_cpu(cpu);
-   xen_teardown_timer(cpu);
-   }
-}
-
 static void xen_play_dead(void) /* used only with HOTPLUG_CPU */
 {
play_dead_common();
@@ -565,11 +537,6 @@ static void xen_pv_cpu_die(unsigned int cpu)
BUG();
 }
 
-static void xen_hvm_cpu_die(unsigned int cpu)
-{
-   BUG();
-}
-
 static void xen_play_dead(void)
 {
BUG();
@@ -595,7 +562,7 @@ static void xen_stop_other_cpus(int wait)
smp_call_function(stop_self, NULL, wait);
 }
 
-static void xen_smp_send_reschedule(int cpu)
+void xen_smp_send_reschedule(int cpu)
 {
xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }
@@ -609,7 +576,7 @@ static void __xen_send_IPI_mask(const struct cpumask *mask,
xen_send_IPI_one(cpu, vector);
 }
 
-static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
+void xen_smp_send_call_function_ipi(const struct cpumask *mask)
 {
int cpu;
 
@@ -624,7 +591,7 @@ static void xen_smp_send_call_function_ipi(const struct 
cpumask *mask)
}
 }
 
-static void xen_smp_send_call_function_single_ipi(int cpu)
+void xen_smp_send_call_function_single_ipi(int cpu)
 {
__xen_send_IPI_mask(cpumask_of(cpu),
  XEN_CALL_FUNCTION_SINGLE_VECTOR);
@@ -762,21 +729,3 @@ void __init xen_smp_init(void)
smp_ops = xen_smp_ops;
xen_fill_possible_map();
 }
-
-static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus)
-{
-   native_smp_prepare_cpus(max_cpus);
-   WARN_ON(xen_smp_intr_init(0));
-
-   xen_init_lock_cpu(0);
-}
-
-void __init xen_hvm_smp_init(void)
-{
-   smp_ops.smp_prepare_cpus = xen_hvm_smp_prepare_cpus;
-   smp_ops.smp_send_reschedule = xen_smp_send_reschedule;
-   smp_ops.cpu_die = xen_hvm_cpu_die;
-   smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi;
-   smp_ops.send_call_func_single_ipi = 
xen_smp_send_call_function_single_ipi;
-   smp_ops.smp_prepare_boot_cpu = xen_hvm_smp_prepare_boot_cpu;
-}
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
index a059adb..bf36e79 100644
--- a/arch/x86/xen/smp.h
+++ b/arch/x86/xen/smp.h
@@ -14,6 +14,9 @@ extern void xen_smp_intr_free(unsigned int cpu);
 extern int xen_smp_intr_init_pv(unsigned int cpu);
 extern void xen_smp_intr_free_pv(unsigned int cpu);
 

[Xen-devel] [PATCH v2 01/21] x86/xen: separate PV and HVM hypervisors

[Vitaly Kuznetsov]

As a preparation to splitting the code we need to untangle it:

x86_hyper_xen -> x86_hyper_xen_hvm and x86_hyper_xen_pv
xen_platform() -> xen_platform_hvm() and xen_platform_pv()
xen_cpu_up_prepare() -> xen_cpu_up_prepare_pv() and xen_cpu_up_prepare_hvm()
xen_cpu_dead() -> xen_cpu_dead_pv() and xen_cpu_dead_pv_hvm()

Add two parameters to xen_cpuhp_setup() to pass proper cpu_up_prepare and
cpu_dead hooks. xen_set_cpu_features() is now PV-only so the redundant
xen_pv_domain() check can be dropped.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/include/asm/hypervisor.h |   3 +-
 arch/x86/kernel/cpu/hypervisor.c  |   3 +-
 arch/x86/xen/enlighten.c  | 113 +-
 3 files changed, 78 insertions(+), 41 deletions(-)

diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h
index 67942b6..6f7545c6 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -53,7 +53,8 @@ extern const struct hypervisor_x86 *x86_hyper;
 /* Recognized hypervisors */
 extern const struct hypervisor_x86 x86_hyper_vmware;
 extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
-extern const struct hypervisor_x86 x86_hyper_xen;
+extern const struct hypervisor_x86 x86_hyper_xen_pv;
+extern const struct hypervisor_x86 x86_hyper_xen_hvm;
 extern const struct hypervisor_x86 x86_hyper_kvm;
 
 extern void init_hypervisor(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 35691a6..a77f18d 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -29,7 +29,8 @@
 static const __initconst struct hypervisor_x86 * const hypervisors[] =
 {
 #ifdef CONFIG_XEN
-   _hyper_xen,
+   _hyper_xen_pv,
+   _hyper_xen_hvm,
 #endif
_hyper_vmware,
_hyper_ms_hyperv,
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index ec1d5c4..4c1a582 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -139,9 +139,11 @@ void *xen_initial_gdt;
 
 RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 
-static int xen_cpu_up_prepare(unsigned int cpu);
+static int xen_cpu_up_prepare_pv(unsigned int cpu);
+static int xen_cpu_up_prepare_hvm(unsigned int cpu);
 static int xen_cpu_up_online(unsigned int cpu);
-static int xen_cpu_dead(unsigned int cpu);
+static int xen_cpu_dead_pv(unsigned int cpu);
+static int xen_cpu_dead_hvm(unsigned int cpu);
 
 /*
  * Point at some empty memory to start with. We map the real shared_info
@@ -1447,13 +1449,14 @@ static void __init xen_dom0_set_legacy_features(void)
x86_platform.legacy.rtc = 1;
 }
 
-static int xen_cpuhp_setup(void)
+static int xen_cpuhp_setup(int (*cpu_up_prepare_cb)(unsigned int),
+  int (*cpu_dead_cb)(unsigned int))
 {
int rc;
 
rc = cpuhp_setup_state_nocalls(CPUHP_XEN_PREPARE,
   "x86/xen/hvm_guest:prepare",
-  xen_cpu_up_prepare, xen_cpu_dead);
+  cpu_up_prepare_cb, cpu_dead_cb);
if (rc >= 0) {
rc = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
   "x86/xen/hvm_guest:online",
@@ -1559,7 +1562,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
   possible map and a non-dummy shared_info. */
per_cpu(xen_vcpu, 0) = _shared_info->vcpu_info[0];
 
-   WARN_ON(xen_cpuhp_setup());
+   WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_pv, xen_cpu_dead_pv));
 
local_irq_disable();
early_boot_irqs_disabled = true;
@@ -1840,28 +1843,41 @@ static void __init init_hvm_pv_info(void)
 }
 #endif
 
-static int xen_cpu_up_prepare(unsigned int cpu)
+static int xen_cpu_up_prepare_pv(unsigned int cpu)
 {
int rc;
 
-   if (xen_hvm_domain()) {
-   /*
-* This can happen if CPU was offlined earlier and
-* offlining timed out in common_cpu_die().
-*/
-   if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
-   xen_smp_intr_free(cpu);
-   xen_uninit_lock_cpu(cpu);
-   }
+   xen_setup_timer(cpu);
 
-   if (cpu_acpi_id(cpu) != U32_MAX)
-   per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
-   else
-   per_cpu(xen_vcpu_id, cpu) = cpu;
-   xen_vcpu_setup(cpu);
+   rc = xen_smp_intr_init(cpu);
+   if (rc) {
+   WARN(1, "xen_smp_intr_init() for CPU %d failed: %d\n",
+cpu, rc);
+   return rc;
+   }
+   return 0;
+}
+
+static int xen_cpu_up_prepare_hvm(unsigned int cpu)
+{
+   int rc;
+
+   /*
+* This can happen if CPU was offlined earlier and
+* offlining timed out in common_cpu_die().
+*/
+   if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
+  

[Xen-devel] [PATCH v2 00/21] x86/xen: untangle PV and PVHVM guest support code

[Vitaly Kuznetsov]

Changes since v1:
- Patches 1,2 and 3 were split and reordered to avoid adding temporary
  #ifdefs [Juergen Gross]
- Juergen's R-b added to what is now patches 14 and 15 (patches 4 and 5
  in v1). Due to re-ordering there are some tiny diffrences but I opted
  for keeping the tag.

Some patches are known to produce checkpatch.pl WARNINGS and a couple of
ERRORs, I fixed a few (mostly in _hvm* code I split) and I refrained from
fixing the rest to make it easier to review. I think that we may leave PV
code as it is as sooner or later it will go away.

Original description:

I have a long-standing idea to separate PV and PVHVM code in kernel and 
introduce Kconfig options to make it possible to enable the required
parts only breaking the current 'all or nothing' approach.

Motivation:
- Xen related x86 code in kernel is rather big and it is unclear which
  parts of it are required for PV, for HVM or for both. With PVH coming
  into picture is becomes even more tangled. It makes it hard to
  understand/audit the code.

- In some case we may want to avoid bloating kernel by supporting Xen
  guests we don't need. In particular, 90% of the code in arch/x86/xen/ is
  required to support PV guests and one may require PVHVM support only.

- PV guests are supposed to go away one day and such code separation would
  help us to get ready.

This series adds XEN_PV Kconfig option and makes it possible to build PV-only
and PVHVM-only kernels. It also makes it possible to disable Dom0 support.

Some patches are rather big but this is mostly just moving code around, no
functional changes intended. I smoke tested it with PV-only and PVHVM-only
builds, booted and did save/restore test. I also tried the newly introduced
PVHv2 guest, it even worked!

Vitaly Kuznetsov (21):
  x86/xen: separate PV and HVM hypervisors
  x86/xen: globalize have_vcpu_info_placement
  x86/xen: add CONFIG_XEN_PV to Kconfig
  x86/xen: split off enlighten_pvh.c
  x86/xen: split off enlighten_hvm.c
  x86/xen: split off enlighten_pv.c
  x86/xen: split xen_smp_intr_init()/xen_smp_intr_free()
  x86/xen: split xen_smp_prepare_boot_cpu()
  x86/xen: split xen_cpu_die()
  x86/xen: split off smp_hvm.c
  x86/xen: split off smp_pv.c
  x86/xen: split off mmu_hvm.c
  x86/xen: split off mmu_pv.c
  x86/xen: split suspend.c for PV and PVHVM guests
  x86/xen: put setup.c, pmu.c and apic.c under CONFIG_XEN_PV
  x86/xen: define startup_xen for XEN PV only
  x86/xen: create stubs for HVM-only builds in page.h
  xen/balloon: decorate PV-only parts with #ifdef CONFIG_XEN_PV
  xen: create xen_create/destroy_contiguous_region() stubs for PVHVM
only builds
  x86/xen: enable PVHVM-only builds
  x86/xen: rename some PV-only functions in smp_pv.c

 arch/x86/include/asm/hypervisor.h |3 +-
 arch/x86/include/asm/xen/page.h   |   25 +
 arch/x86/kernel/cpu/hypervisor.c  |7 +-
 arch/x86/kernel/process_64.c  |2 +-
 arch/x86/xen/Kconfig  |   33 +-
 arch/x86/xen/Makefile |   16 +-
 arch/x86/xen/enlighten.c  | 1904 +
 arch/x86/xen/enlighten_hvm.c  |  210 +++
 arch/x86/xen/enlighten_pv.c   | 1561 +
 arch/x86/xen/enlighten_pvh.c  |  114 ++
 arch/x86/xen/mmu.c| 2776 +
 arch/x86/xen/mmu_hvm.c|   79 ++
 arch/x86/xen/mmu_pv.c | 2635 +++
 arch/x86/xen/pmu.h|5 +
 arch/x86/xen/smp.c|  516 +--
 arch/x86/xen/smp.h|   16 +
 arch/x86/xen/smp_hvm.c|   58 +
 arch/x86/xen/smp_pv.c |  499 +++
 arch/x86/xen/suspend.c|   54 -
 arch/x86/xen/suspend_hvm.c|   22 +
 arch/x86/xen/suspend_pv.c |   44 +
 arch/x86/xen/xen-head.S   |4 +
 arch/x86/xen/xen-ops.h|   21 +
 drivers/xen/balloon.c |   30 +-
 include/xen/xen-ops.h |   14 +
 25 files changed, 5461 insertions(+), 5187 deletions(-)
 create mode 100644 arch/x86/xen/enlighten_hvm.c
 create mode 100644 arch/x86/xen/enlighten_pv.c
 create mode 100644 arch/x86/xen/enlighten_pvh.c
 create mode 100644 arch/x86/xen/mmu_hvm.c
 create mode 100644 arch/x86/xen/mmu_pv.c
 create mode 100644 arch/x86/xen/smp_hvm.c
 create mode 100644 arch/x86/xen/smp_pv.c
 create mode 100644 arch/x86/xen/suspend_hvm.c
 create mode 100644 arch/x86/xen/suspend_pv.c

-- 
2.9.3


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

Re: [Xen-devel] [PATCH v2 5/5] golang/xenlight: Add tests host related functionality functions

[George Dunlap]

On 02/03/17 17:36, Ian Jackson wrote:
> Ronald Rojas writes ("[PATCH v2 5/5] golang/xenlight: Add tests host related 
> functionality functions"):
>> Create tests for the following functions:
>> - GetVersionInfo
>> - GetPhysinfo
>> - GetDominfo
>> - GetMaxCpus
>> - GetOnlineCpus
>> - GetMaxNodes
>> - GetFreeMemory
> 
> I assume this whole series is RFC still ?

I think the earlier patches looked pretty close to being checked in.  I
think having a basic chunk of functionality checked in will make it
easier to actually collaborate on improving things.

> I don't feel competent to review the golang code.  But I did spot some
> C to review :-)
> 
>> diff --git a/tools/golang/xenlight/test/xeninfo/freememory.c 
>> b/tools/golang/xenlight/test/xeninfo/freememory.c
>> new file mode 100644
>> index 000..04ee90d
>> --- /dev/null
>> +++ b/tools/golang/xenlight/test/xeninfo/freememory.c
>> @@ -0,0 +1,24 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include "print.h"
>> +
>> +int main(){
> 
> This is an unusual definition of main.  (I think it's still legal, but
> probably not what you meant.)
> 
>> +libxl_ctx *context;
>> +libxl_ctx_alloc(,LIBXL_VERSION, 0, NULL);
>> +
>> +uint64_t free_memory;
>> +int err = libxl_get_free_memory(context, _memory);
>> +if (err < 0)
>> +{
>> +printf("%d\n", err);
>> +}
>> +else
>> +{
>> +printf("%lu\n", free_memory);
>> +}
> 
> This output is ambiguous.
> 
>> +libxl_ctx_free(context);
>> +
>> +}
> 
> Returns from main without returning a value.  Error code is lost.

He's not testing whether the call succeeds; he's testing if the call has
the same result as the golang function.

But this won't quite work anymore, because as of v2 the golang return
values are positive constants (to make it easy to use them for indexes).
 So if there were an identical error, the output would be different even
if the error number were identical.

That needs to be fixed; but I also agree it would probably be better to
print something that distinguishes between success and failure.

 -George

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

[Xen-devel] [xen-unstable-smoke test] 106374: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 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  26735f30dffe1091686bbe921aacbea8ba371cc8
baseline version:
 xen  9a0e3e618b590eb6093a8a170453a95fb32840b8

Last test of basis   106368  2017-03-02 13:01:11 Z0 days
Testing same since   106374  2017-03-02 16:03:24 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=26735f30dffe1091686bbe921aacbea8ba371cc8
+ . ./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 
26735f30dffe1091686bbe921aacbea8ba371cc8
+ branch=xen-unstable-smoke
+ revision=26735f30dffe1091686bbe921aacbea8ba371cc8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x26735f30dffe1091686bbe921aacbea8ba371cc8 = 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
++ : 

Re: [Xen-devel] [PATCH v2 5/5] golang/xenlight: Add tests host related functionality functions

[Ian Jackson]

Ronald Rojas writes ("[PATCH v2 5/5] golang/xenlight: Add tests host related 
functionality functions"):
> Create tests for the following functions:
> - GetVersionInfo
> - GetPhysinfo
> - GetDominfo
> - GetMaxCpus
> - GetOnlineCpus
> - GetMaxNodes
> - GetFreeMemory

I assume this whole series is RFC still ?

I don't feel competent to review the golang code.  But I did spot some
C to review :-)

> diff --git a/tools/golang/xenlight/test/xeninfo/freememory.c 
> b/tools/golang/xenlight/test/xeninfo/freememory.c
> new file mode 100644
> index 000..04ee90d
> --- /dev/null
> +++ b/tools/golang/xenlight/test/xeninfo/freememory.c
> @@ -0,0 +1,24 @@
> +#include 
> +#include 
> +#include 
> +#include "print.h"
> +
> +int main(){

This is an unusual definition of main.  (I think it's still legal, but
probably not what you meant.)

> +libxl_ctx *context;
> +libxl_ctx_alloc(,LIBXL_VERSION, 0, NULL);
> +
> +uint64_t free_memory;
> +int err = libxl_get_free_memory(context, _memory);
> +if (err < 0)
> +{
> +printf("%d\n", err);
> +}
> +else
> +{
> +printf("%lu\n", free_memory);
> +}

This output is ambiguous.

> +libxl_ctx_free(context);
> +
> +}

Returns from main without returning a value.  Error code is lost.

Thanks,
Ian.

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

Re: [Xen-devel] [RFC PATCH v1 21/21] ARM: NUMA: Enable CONFIG_ACPI_NUMA config

[Julien Grall]

Hello Vijay,

On 09/02/17 15:57, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K 

Enable CONFIG_ACPI_NUMA to enable ACPI NUMA

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index fbc4f23..4b74eef 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -43,6 +43,10 @@ config ACPI
  Advanced Configuration and Power Interface (ACPI) support for Xen is
  an alternative to device tree on ARM64.

+config ACPI_NUMA
+   def_bool y
+   depends on ACPI


This also depends on NUMA


+


The define CONFIG_ACPI_NUMA in asm-x86/config.h should be turned into a 
Kconfig in drivers/acpi and make it selectable when NUMA && ACPI is 
available.



 config HAS_GICV3
bool




Regards,

--
Julien Grall

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

Re: [Xen-devel] Xen-unstable: Bisected Host boot failure on AMD Phenom

[Sander Eikelenboom]

On 02/03/17 15:55, Andrew Cooper wrote:
> On 02/03/17 14:42, Sander Eikelenboom wrote:
>> Hi Andrew / Jan,
>>
>> While testing current xen-unstable staging i ran into my host rebooting in 
>> early kernel boot. 
>> Bisection has turned up:
>> 5cecf60f439e828f4bc0d2a368ced9a73b130cb7 is the first bad commit
>> Author: Andrew Cooper 
>> Date:   Fri Feb 17 17:10:50 2017 +
>>
>> x86/cpuid: Handle leaf 0x1 in guest_cpuid()
>>
>> Hardware is a AMD phenom x6.
>> Below is the output of serial console of a failed boot.
> 
> Hmm.  Sorry for breaking this (although my AMD servers are booting fine).

No problem, it is the staging branch of the unstable tree anyway ;-)

> It is unfortunately not entirely obvious what Linux is objecting to, and
> must be related to something visible in the emulated view.
> 
> Does this delta make any difference?

Yes it does, boots fine with this patch applied, thanks !

--
Sander

> 
> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
> index 0dd35dc..c8fabe9 100644
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -747,9 +747,14 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>  const struct cpu_user_regs *regs;
>  
>  case 0x1:
> -/* TODO: Rework topology logic. */
> -res->b &= 0x00ffu;
> -res->b |= (v->vcpu_id * 2) << 24;
> +if ( is_hardware_domain(d) )
> +res->b = cpuid_ebx(0x1);
> +else
> +{
> +/* TODO: Rework topology logic. */
> +res->b &= 0x00ffu;
> +res->b |= (v->vcpu_id * 2) << 24;
> +}
>  
>  /* TODO: Rework vPMU control in terms of toolstack choices. */
>  if ( vpmu_available(v) &&
> 


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

Re: [Xen-devel] [RFC PATCH v1 20/21] ARM: NUMA: Enable CONFIG_NUMA config

[Julien Grall]

Hello Vijay,

On 09/02/17 15:57, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K 

Enable CONFIG_NUMA to enable DT NUMA

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 2e023d1..fbc4f23 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -23,6 +23,7 @@ config ARM
select HAS_PASSTHROUGH
select HAS_PDX
select VIDEO
+   select NUMA


I would have expected a patch to move config NUMA from 
drivers/acpi/Kconfig to config/Kconfig.


Regards,


--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v1 19/21] ARM: NUMA: Initialize ACPI NUMA

[Julien Grall]

Hello Vijay,

On 09/02/17 15:57, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K 

Call ACPI NUMA initialization under CONFIG_ACPI_NUMA.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/numa.c | 12 +++-
 xen/common/numa.c   |  6 ++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 50c3dea..1d6e16c 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -204,7 +204,17 @@ int __init numa_init(void)
 for ( i = 0; i < MAX_NUMNODES * 2; i++ )
 _node_distance[i] = 0;

-ret = dt_numa_init();
+#ifdef CONFIG_ACPI_NUMA
+if ( !acpi_disabled )
+{
+acpi_map_uid_to_mpidr();
+ret = acpi_numa_init();
+if ( ret || srat_disabled() )
+goto no_numa;
+}
+else
+#endif


We should really have only on call to ACPI in the generic code. Please 
move all of this in a function.



+ret = dt_numa_init();

 if ( !ret )
 ret = numa_initmem_init();
diff --git a/xen/common/numa.c b/xen/common/numa.c
index 2f5266a..4c67d38 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 static int numa_setup(char *s);
@@ -282,6 +283,11 @@ static __init int numa_setup(char *opt)
 numa_off = 1;
 if ( !strncmp(opt,"on",2) )
 numa_off = 0;
+if ( !strncmp(opt,"noacpi",6) )
+{
+numa_off = 0;
+acpi_numa = -1;
+}

 return arch_numa_setup(opt);
 }



--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v1 18/21] ARM: NUMA: update node_distance with ACPI support

[Julien Grall]

Hello Vijay,

On 09/02/17 15:57, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K 

Update node_distance() function to handle
ACPI SLIT table information.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/numa.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 5c49347..50c3dea 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -35,6 +36,7 @@ extern struct node nodes[MAX_NUMNODES] __initdata;
 extern int num_node_memblks;
 extern struct node node_memblk_range[NR_NODE_MEMBLKS];
 extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
+extern struct acpi_table_slit *__read_mostly acpi_slit;

 void __init numa_set_cpu_node(int cpu, unsigned long hwid)
 {
@@ -50,9 +52,24 @@ void __init numa_set_cpu_node(int cpu, unsigned long hwid)

 u8 __node_distance(nodeid_t a, nodeid_t b)
 {
-if ( !node_distance )
+unsigned index;
+u8 slit_val;
+
+if ( !node_distance && !acpi_slit )
 return a == b ? 10 : 20;

+if ( acpi_slit )
+{
+index = acpi_slit->locality_count * node_to_pxm(a);
+slit_val = acpi_slit->entry[index + node_to_pxm(b)];
+
+/* ACPI defines 0xff as an unreachable node and 0-9 are undefined */
+if ( (slit_val == 0xff) || (slit_val <= 9) )
+return NUMA_NO_DISTANCE;
+else
+return slit_val;
+}
+


arm/numa.c is the generic code and should not contain any ACPI specific 
code.


But as I said, the way to get the distance on ACPI is the same on x86 
and ARM.


So I would introduce __node_distance callback that will be setup at 
boot-time to either point to the ACPI version or DT version.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v1 16/21] ARM: NUMA: Extract proximity from SRAT table

[Julien Grall]

(+ Jan as ACPI maintainer)

Hello Vijay,

On 09/02/17 15:57, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K 

Register SRAT entry handler for type
ACPI_SRAT_TYPE_GICC_AFFINITY to parse SRAT table
and extract proximity for all CPU IDs.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/acpi_numa.c  | 55 +++
 xen/drivers/acpi/numa.c   | 37 +++
 xen/drivers/acpi/osl.c|  2 ++
 xen/include/acpi/actbl1.h | 17 ++-
 xen/include/xen/acpi.h| 39 +
 5 files changed, 149 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/acpi_numa.c b/xen/arch/arm/acpi_numa.c
index 3ee87f2..f659275 100644
--- a/xen/arch/arm/acpi_numa.c
+++ b/xen/arch/arm/acpi_numa.c
@@ -105,6 +105,61 @@ static int __init acpi_parse_madt_handler(struct 
acpi_subtable_header *header,
 return 0;
 }

+/* Callback for Proximity Domain -> ACPI processor UID mapping */
+void __init acpi_numa_gicc_affinity_init(const struct acpi_srat_gicc_affinity 
*pa)
+{
+int pxm, node;
+u64 mpidr = 0;


mpidr does not need to be set to 0.


+static u32 cpus_in_srat;
+
+if ( srat_disabled() )
+return;
+
+if ( pa->header.length < sizeof(struct acpi_srat_gicc_affinity) )
+{
+printk(XENLOG_WARNING "SRAT: Invalid SRAT header length: %d\n",
+   pa->header.length);
+bad_srat();
+return;
+}
+
+if ( !(pa->flags & ACPI_SRAT_GICC_ENABLED) )
+return;
+
+if ( cpus_in_srat >= NR_CPUS )
+{
+printk(XENLOG_WARNING


This should be XENLOG_ERROR.


+   "SRAT: cpu_to_node_map[%d] is too small to fit all cpus\n",
+   NR_CPUS);
+return;
+}
+
+pxm = pa->proximity_domain;
+node = setup_node(pxm);
+if ( node == NUMA_NO_NODE || node >= MAX_NUMNODES )


Looking at the implementation of setup_node, node will either be equal 
to NUMA_NO_NODE or valid. It is not possible to have node >= MAX_NUMNODES.



+{
+printk(XENLOG_WARNING "SRAT: Too many proximity domains %d\n", pxm);


setup_node is already printing an error if we have too many proximity 
domains. So no need to duplicate twice.



+bad_srat();
+return;
+}
+
+mpidr = acpi_get_cpu_mpidr(pa->acpi_processor_uid);
+if ( mpidr == MPIDR_INVALID )
+{
+printk(XENLOG_WARNING


s/XENLOG_WARNING/XENLOG_ERROR/


+   "SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
+   pxm, pa->acpi_processor_uid);
+bad_srat();
+return;
+}
+
+node_set(node, numa_nodes_parsed);
+cpus_in_srat++;
+acpi_numa = 1;
+printk(XENLOG_INFO "SRAT: PXM %d -> MPIDR 0x%lx -> Node %d\n",
+   pxm, mpidr, node);
+}
+
 void __init acpi_map_uid_to_mpidr(void)
 {
 int i;
diff --git a/xen/drivers/acpi/numa.c b/xen/drivers/acpi/numa.c
index 50bf9f8..ce22e88 100644
--- a/xen/drivers/acpi/numa.c
+++ b/xen/drivers/acpi/numa.c
@@ -25,9 +25,11 @@
 #include 
 #include 
 #include 
+#include 


Why do you need to inlucde xen/mm.h and ...


 #include 
 #include 
 #include 
+#include 


asm/mm.h?



 #define ACPI_NUMA  0x8000
 #define _COMPONENT ACPI_NUMA
@@ -105,6 +107,21 @@ void __init acpi_table_print_srat_entry(struct 
acpi_subtable_header * header)
}
 #endif /* ACPI_DEBUG_OUTPUT */
break;
+   case ACPI_SRAT_TYPE_GICC_AFFINITY:
+#ifdef ACPI_DEBUG_OUTPUT
+   {
+   struct acpi_srat_gicc_affinity *p =
+   (struct acpi_srat_gicc_affinity *)header;
+   ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ "SRAT Processor (acpi id[0x%04x]) in"
+ " proximity domain %d %s\n",
+ p->acpi_processor_uid,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_GICC_ENABLED) ?
+ "enabled" : "disabled");
+   }
+#endif /* ACPI_DEBUG_OUTPUT */
+   break;
default:
printk(KERN_WARNING PREFIX
   "Found unsupported SRAT entry (type = %#x)\n",
@@ -185,6 +202,24 @@ int __init acpi_parse_srat(struct acpi_table_header *table)
return 0;
 }

+static int __init
+acpi_parse_gicc_affinity(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+   const struct acpi_srat_gicc_affinity *processor_affinity
+   = (struct acpi_srat_gicc_affinity *)header;
+
+   if (!processor_affinity)
+   return -EINVAL;
+
+   acpi_table_print_srat_entry(header);
+
+   /* let architecture-dependent part to do it */
+   

Re: [Xen-devel] qdisks and stubdomains

[Gémes Géza]

2017-03-02 16:29 keltezéssel, Simon Weald írta:

Hello

I don't know whether this classifies as a bug or missing functionality,
but I'm looking to attach Ceph RBD volumes directly to a guest (as
opposed to mapping them on the host and then passing the block device to
the guest). The rationale for this is that the kernel RBD client's
functionality lags behind that of librbd, meaning the kernel cannot map
RBD volumes created with the newer features.

For a little bit of background, these are PVHVM guests, I'm running
4.7.1 and 4.8.0 on Jessie, and the Ceph cluster is 10.2.5 (latest Jewel
release).

When running the guest outside of a stubdomain, block-attach exits
successfully:

xl block-attach domU format=raw, vdev=xvdb, access=rw,
backendtype=qdisk, target=rbd:cinder/test:id=xenhosts

root@xen:~# xl block-list domU
Vdev  BE  handle state evt-ch ring-ref BE-path
768   0   6  4 12 8/local/domain/0/backend/vbd/6/768
5632  0   6  6 -1 -1   /local/domain/0/backend/qdisk/6/5632
832   0   6  3 22 897  /local/domain/0/backend/qdisk/6/832

root@mshx-rd-6:~# xenstore-ls /local/domain/0/backend/qdisk/6/832 -f
/local/domain/0/backend/qdisk/6/832/frontend =
"/local/domain/6/device/vbd/832"
/local/domain/0/backend/qdisk/6/832/params =
"aio:rbd:cinder/test:id=xenhosts"
/local/domain/0/backend/qdisk/6/832/frontend-id = "6"
/local/domain/0/backend/qdisk/6/832/online = "1"
/local/domain/0/backend/qdisk/6/832/removable = "0"
/local/domain/0/backend/qdisk/6/832/bootable = "1"
/local/domain/0/backend/qdisk/6/832/state = "2"
/local/domain/0/backend/qdisk/6/832/dev = "hdb"
/local/domain/0/backend/qdisk/6/832/type = "qdisk"
/local/domain/0/backend/qdisk/6/832/mode = "w"
/local/domain/0/backend/qdisk/6/832/device-type = "disk"
/local/domain/0/backend/qdisk/6/832/discard-enable = "1"
/local/domain/0/backend/qdisk/6/832/feature-flush-cache = "1"
/local/domain/0/backend/qdisk/6/832/feature-persistent = "1"
/local/domain/0/backend/qdisk/6/832/info = "0"
/local/domain/0/backend/qdisk/6/832/feature-discard = "1"
/local/domain/0/backend/qdisk/6/832/hotplug-status = "connected"

This all looks good at this point, however the device doesn't actually
appear available to the guest (no device nodes, nothing in dmesg). This
however is academic, as the ultimate goal is to attach the volumes to
stubdomained guests (without relying on the problematic kernel client
and block scripts). When I try a block-attach to the stubdomained guest,
I get the following:

libxl: error: libxl_dm.c:2423:libxl__dm_check_start: device model
required but not running
libxl: error: libxl.c:2012:device_addrm_aocomplete: unable to add device
libxl_device_disk_add failed.

Is this even possible?

Thanks in advance!

Simon



Hi Simon,

If you are using the minios based stubdom, then the qemu in the stubdom 
is qemu-traditional, which is an old fork of the upstream qemu, which 
clearly lacks support for ceph. Unfortunately there is no support for 
qemu-xen yet in the stubdom implementations in the xen tree.


Cheers,

Geza


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

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

[Igor Mammedov]

On Thu, 2 Mar 2017 15:28:16 +0100
Michal Hocko  wrote:

> On Thu 02-03-17 14:53:48, Igor Mammedov wrote:
> [...]
> > When trying to support memory unplug on guest side in RHEL7,
> > experience shows otherwise. Simplistic udev rule which onlines
> > added block doesn't work in case one wants to online it as movable.
> > 
> > Hotplugged blocks in current kernel should be onlined in reverse
> > order to online blocks as movable depending on adjacent blocks zone.  
> 
> Could you be more specific please? Setting online_movable from the udev
> rule should just work regardless of the ordering or the state of other
> memblocks. If that doesn't work I would call it a bug.
It's rather an implementation constrain than a bug
for details and workaround patch see
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1314306#c7
patch attached there is limited by another memory hotplug
issue, which is NORMAL/MOVABLE zone balance, if kernel runs
on configuration where the most of memory is hot-removable
kernel might experience lack of memory in zone NORMAL.

> 
> > Which means simple udev rule isn't usable since it gets event from
> > the first to the last hotplugged block order. So now we would have
> > to write a daemon that would
> >  - watch for all blocks in hotplugged memory appear (how would it know)
> >  - online them in right order (order might also be different depending
> >on kernel version)
> >-- it becomes even more complicated in NUMA case when there are
> >   multiple zones and kernel would have to provide user-space
> >   with information about zone maps
> > 
> > In short current experience shows that userspace approach
> >  - doesn't solve issues that Vitaly has been fixing (i.e. onlining
> >fast and/or under memory pressure) when udev (or something else
> >might be killed)  
> 
> yeah and that is why the patch does the onlining from the kernel.
onlining in this patch is limited to hyperv and patch breaks
auto-online on x86 kvm/vmware/baremetal as they reuse the same
hotplug path.

> > > Can you imagine any situation when somebody actually might want to have
> > > this knob enabled? From what I understand it doesn't seem to be the
> > > case.  
> > For x86:
> >  * this config option is enabled by default in recent Fedora,  
> 
> How do you want to support usecases which really want to online memory
> as movable? Do you expect those users to disable the option because
> unless I am missing something the in kernel auto onlining only supporst
> regular onlining.
current auto onlining config option does what it's been designed for,
i.e. it onlines hotplugged memory.
It's possible for non average Fedora user to override default
(commit 86dd995d6) if she/he needs non default behavior
(i.e. user knows how to online manually and/or can write
a daemon that would handle all of nuances of kernel in use).

For the rest when Fedora is used in cloud and user increases memory
via management interface of whatever cloud she/he uses, it just works.

So it's choice of distribution to pick its own default that makes
majority of user-base happy and this patch removes it without taking
that in consideration.

How to online memory is different issue not related to this patch,
current default onlining as ZONE_NORMAL works well for scaling
up VMs.

Memory unplug is rather new and it doesn't work reliably so far,
moving onlining to user-space won't really help. Further work
is need to be done so that it would work reliably.

Now about the question of onlining removable memory as movable,
x86 kernel is able to get info, if hotadded memory is removable,
from ACPI subsystem and online it as movable one without any
intervention from user-space where it's hard to do so,
as patch[1] shows.
Problem is still researched and when we figure out how to fix
hot-remove issues we might enable auto-onlining by default for x86.

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

Re: [Xen-devel] [RFC PATCH v1 15/21] ARM: NUMA: Extract MPIDR from MADT table

[Julien Grall]

On 02/03/17 16:41, Vijay Kilari wrote:

On Thu, Mar 2, 2017 at 9:58 PM, Julien Grall  wrote:

Hello Vijay,

On 09/02/17 15:57, vijay.kil...@gmail.com wrote:


From: Vijaya Kumar K 

Parse MADT table and extract MPIDR for all
CPU IDs in MADT ACPI_MADT_TYPE_GENERIC_INTERRUPT entries
and store in cpu_uid_to_hwid[].

This mapping is used by SRAT table parsing to
extract MPIDR of the CPU ID.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/Makefile  |   1 +
 xen/arch/arm/acpi_numa.c   | 122
+
 xen/arch/arm/numa.c|   1 +



This new file should go in xen/arch/arm/acpi/


shouldn't be in xen/arch/arm/numa/?


If you introduce a numa directory then move in it. Otherwise acpi/.



+static int __init acpi_parse_madt_handler(struct acpi_subtable_header
*header,
+  const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *p =
+   container_of(header, struct acpi_madt_generic_interrupt,
header);
+
+if ( BAD_MADT_ENTRY(p, end) )
+{
+/* Though MADT is invalid, we disable NUMA by calling bad_srat()
*/
+bad_srat();
+return -EINVAL;
+}
+
+acpi_table_print_madt_entry(header);
+acpi_map_cpu_to_mpidr(p);
+
+return 0;
+}



Why do you need to parse the MADT again? Can't this be done in the parsing
made in acpi/boot.c?

I will check. But I see that this is done quite late in smp_init().


Then rework the code.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v1 15/21] ARM: NUMA: Extract MPIDR from MADT table

[Vijay Kilari]

On Thu, Mar 2, 2017 at 9:58 PM, Julien Grall  wrote:
> Hello Vijay,
>
> On 09/02/17 15:57, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K 
>>
>> Parse MADT table and extract MPIDR for all
>> CPU IDs in MADT ACPI_MADT_TYPE_GENERIC_INTERRUPT entries
>> and store in cpu_uid_to_hwid[].
>>
>> This mapping is used by SRAT table parsing to
>> extract MPIDR of the CPU ID.
>>
>> Signed-off-by: Vijaya Kumar 
>> ---
>>  xen/arch/arm/Makefile  |   1 +
>>  xen/arch/arm/acpi_numa.c   | 122
>> +
>>  xen/arch/arm/numa.c|   1 +
>
>
> This new file should go in xen/arch/arm/acpi/

shouldn't be in xen/arch/arm/numa/?
>
>
>>  xen/include/asm-arm/acpi.h |   2 +
>>  4 files changed, 126 insertions(+)
>>
>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>> index 7694485..8c5e67b 100644
>> --- a/xen/arch/arm/Makefile
>> +++ b/xen/arch/arm/Makefile
>> @@ -51,6 +51,7 @@ obj-y += vpsci.o
>>  obj-y += vuart.o
>>  obj-$(CONFIG_NUMA) += numa.o
>>  obj-$(CONFIG_NUMA) += dt_numa.o
>> +obj-$(CONFIG_ACPI_NUMA) += acpi_numa.o
>>
>>  #obj-bin-y += o
>>
>> diff --git a/xen/arch/arm/acpi_numa.c b/xen/arch/arm/acpi_numa.c
>> new file mode 100644
>> index 000..3ee87f2
>> --- /dev/null
>> +++ b/xen/arch/arm/acpi_numa.c
>> @@ -0,0 +1,122 @@
>> +/*
>> + * ACPI based NUMA setup
>> + *
>> + * Copyright (C) 2016 - Cavium Inc.
>> + * Vijaya Kumar K 
>> + *
>> + * Reads the ACPI MADT and SRAT table to setup NUMA information.
>> + *
>> + * Contains Excerpts from x86 implementation
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>
>
> Xen is GPLv2, please update the license accordingly.
>
>
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +extern nodemask_t numa_nodes_parsed;
>> +struct uid_to_mpidr {
>> +u32 uid;
>> +u64 mpidr;
>> +};
>> +
>> +/* Holds mapping of CPU id to MPIDR read from MADT */
>> +static struct uid_to_mpidr cpu_uid_to_hwid[NR_CPUS] __read_mostly;
>> +
>> +static __init void bad_srat(void)
>> +{
>> +int i;
>> +
>> +printk(KERN_ERR "SRAT: SRAT not used.\n");
>> +acpi_numa = -1;
>> +for (i = 0; i < ARRAY_SIZE(pxm2node); i++)
>> +pxm2node[i].node = NUMA_NO_NODE;
>> +}
>> +
>> +static u64 acpi_get_cpu_mpidr(int uid)
>> +{
>> +int i;
>> +
>> +if ( uid < ARRAY_SIZE(cpu_uid_to_hwid) && cpu_uid_to_hwid[uid].uid ==
>> uid &&
>> + cpu_uid_to_hwid[uid].mpidr != MPIDR_INVALID )
>> +return cpu_uid_to_hwid[uid].mpidr;
>
>
> Please don't make a special case. This makes more complicate to read the
> code.
>
> We should just loop to find the entry matching the UID.
>
>> +
>> +for ( i = 0; i < NR_CPUS; i++ )
>
>
> You can limit the loop by keeping an the number of element in the array.
OK.
>
>
>> +{
>> +if ( cpu_uid_to_hwid[i].uid == uid )
>> +return cpu_uid_to_hwid[i].mpidr;
>> +}
>> +
>> +return MPIDR_INVALID;
>> +}
>> +
>> +static void __init
>> +acpi_map_cpu_to_mpidr(struct acpi_madt_generic_interrupt *processor)
>> +{
>> +static int cpus = 0;
>> +
>> +u64 mpidr = processor->arm_mpidr & MPIDR_HWID_MASK;
>> +
>> +if ( mpidr == MPIDR_INVALID )
>> +{
>> +printk("Skip MADT cpu entry with invalid MPIDR\n");
>> +bad_srat();
>> +return;
>> +}
>> +
>> +cpu_uid_to_hwid[cpus].mpidr = mpidr;
>> +cpu_uid_to_hwid[cpus].uid = processor->uid;
>> +
>> +cpus++;
>> +}
>> +
>> +static int __init acpi_parse_madt_handler(struct acpi_subtable_header
>> *header,
>> +  const unsigned long end)
>> +{
>> +struct acpi_madt_generic_interrupt *p =
>> +   container_of(header, struct acpi_madt_generic_interrupt,
>> header);
>> +
>> +if ( BAD_MADT_ENTRY(p, end) )
>> +{
>> +/* Though MADT is invalid, we disable NUMA by calling bad_srat()
>> */
>> +bad_srat();
>> +return -EINVAL;
>> +}
>> +
>> +acpi_table_print_madt_entry(header);
>> +acpi_map_cpu_to_mpidr(p);
>> +
>> +return 0;
>> +}
>
>
> Why do you need to parse the MADT again? Can't this be done in the parsing
> made in acpi/boot.c?
I will check. But I see that this is done quite late in smp_init().

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

Re: [Xen-devel] [PATCH 7/7] x86/pagewalk: Re-implement the pagetable walker

[Tim Deegan]

At 14:03 + on 27 Feb (1488204198), Andrew Cooper wrote:
> The existing pagetable walker has complicated return semantics, which squeeze
> multiple pieces of information into single integer.  This would be fine if the
> information didn't overlap, but it does.
> 
> Specifically, _PAGE_INVALID_BITS for 3-level guests alias _PAGE_PAGED and
> _PAGE_SHARED.  A guest which constructs a PTE with bits 52 or 53 set (the
> start of the upper software-available range) will create a virtual address
> which, when walked by Xen, tricks Xen into believing the frame is paged or
> shared.  This behaviour was introduced by XSA-173 (c/s 8b17648).
> 
> It is also complicated to turn rc back into a normal pagefault error code.
> Instead, change the calling semantics to return a boolean indicating success,
> and have the function accumulate a real pagefault error code as it goes
> (including synthetic error codes, which do not alias hardware ones).  This
> requires an equivalent adjustment to map_domain_gfn().
> 
> Issues fixed:
>  * 2-level PSE36 superpages now return the correct translation.
>  * 2-level L2 superpages without CR0.PSE now return the correct translation.
>  * SMEP now inhibits a user instruction fetch even if NX isn't active.
>  * Supervisor writes without CR0.WP now set the leaf dirty bit.
>  * L4e._PAGE_GLOBAL is strictly reserved on AMD.
>  * 3-level l3 entries have all reserved bits checked.
>  * 3-level entries can no longer alias Xen's idea of paged or shared.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Tim Deegan 

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

Re: [Xen-devel] [RFC PATCH v1 13/21] ACPI: Refactor acpi SRAT and SLIT table handling code

[Julien Grall]

On 02/03/17 16:31, Vijay Kilari wrote:

On Thu, Mar 2, 2017 at 9:00 PM, Julien Grall  wrote:

Missing emacs magic here.

You mean this at the end of the file?


Yes.



/*
 * Local variables:
 * mode: C
 * c-file-style: "BSD"
 * c-basic-offset: 4
 * indent-tabs-mode: nil
 * End:
 */



--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v1 13/21] ACPI: Refactor acpi SRAT and SLIT table handling code

[Vijay Kilari]

On Thu, Mar 2, 2017 at 9:00 PM, Julien Grall  wrote:
> Hello Vijay,
>
> On 09/02/17 15:57, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K 
>>
>> Move SRAT handling code which is common across
>> architecture is moved to new file xen/commom/srat.c
>> from xen/arch/x86/srat.c file. New header file srat.h is
>> introduced.
>>
>> Signed-off-by: Vijaya Kumar 
>> ---
>>  xen/arch/x86/domain_build.c |   1 +
>>  xen/arch/x86/numa.c |   1 +
>>  xen/arch/x86/physdev.c  |   1 +
>>  xen/arch/x86/setup.c|   1 +
>>  xen/arch/x86/smpboot.c  |   1 +
>>  xen/arch/x86/srat.c | 129 +--
>>  xen/arch/x86/x86_64/mm.c|   1 +
>>  xen/common/Makefile |   1 +
>>  xen/common/srat.c   | 150
>> 
>
>
> This new file should be created in xen/drivers/acpi/
OK
>
>>  xen/drivers/passthrough/vtd/iommu.c |   1 +
>>  xen/include/asm-x86/numa.h  |   2 -
>>  xen/include/xen/numa.h  |   1 -
>>  xen/include/xen/srat.h  |  13 
>
>
> This new file should be created in xen/include/acpi/
OK
>
> [...]
>
>> diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
>> index 58dee09..af12e26 100644
>> --- a/xen/arch/x86/srat.c
>> +++ b/xen/arch/x86/srat.c
>> @@ -18,91 +18,20 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> -static struct acpi_table_slit *__read_mostly acpi_slit;
>> +extern struct acpi_table_slit *__read_mostly acpi_slit;
>
>
> This should be defined in the header. However, I don't like the idea of
> exposing acpi_slit.
>
> Looking at the usage it is only to parse the distance that can be common.

node_distance() of x86 and arm is quite different as arm has DT mechanism.
I will check if possible to make ACPI node_distance part common between
x86 and arm.

>
> [...]
>
>>  /* Callback for Proximity Domain -> x2APIC mapping */
>>  void __init
>>  acpi_numa_x2apic_affinity_init(const struct acpi_srat_x2apic_cpu_affinity
>> *pa)
>> @@ -456,18 +343,6 @@ int __init acpi_scan_nodes(u64 start, u64 end)
>> return 0;
>>  }
>
>
> The code of acpi_numa_memory_affinity_init looks pretty generic. Why didn't
> you move it in the common code?

Agreed.
>
> [...]
>
>> diff --git a/xen/common/Makefile b/xen/common/Makefile
>> index c1bd2ff..a668094 100644
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -64,6 +64,7 @@ obj-bin-y += warning.init.o
>>  obj-$(CONFIG_XENOPROF) += xenoprof.o
>>  obj-y += xmalloc_tlsf.o
>>  obj-y += numa.o
>> +obj-y += srat.o
>
>
> This should be only compiled when CONFIG_ACPI is enabled.
OK
>
>
>>
>>  obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo
>> unlz4 earlycpio,$(n).init.o)
>>
>> diff --git a/xen/common/srat.c b/xen/common/srat.c
>> new file mode 100644
>> index 000..cf50c78
>> --- /dev/null
>> +++ b/xen/common/srat.c
>> @@ -0,0 +1,150 @@
>> +/*
>> + * ACPI 3.0 based NUMA setup
>> + * Copyright 2004 Andi Kleen, SuSE Labs.
>> + *
>> + * Reads the ACPI SRAT table to figure out what memory belongs to which
>> CPUs.
>> + *
>> + * Called from acpi_numa_init while reading the SRAT and SLIT tables.
>> + * Assumes all memory regions belonging to a single proximity domain
>> + * are in one chunk. Holes between them will be included in the node.
>> + *
>> + * Adapted for Xen: Ryan Harper 
>> + *
>> + * Moved this generic code from xen/arch/x86/srat.c for other arch usage
>> + * by Vijaya Kumar K 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct acpi_table_slit *__read_mostly acpi_slit;
>
>
> This should really be static.
>
>> +extern struct node nodes[MAX_NUMNODES] __initdata;
>> +
>> +struct pxm2node __read_mostly pxm2node[MAX_NUMNODES] =
>> +{ [0 ... MAX_NUMNODES - 1] = {.node = NUMA_NO_NODE} };
>
>
> So this is not only exposed because of bad_srat(). The code should be
> reworked to avoid that.

I will check.
>
>> +
>> +static inline bool_t node_found(unsigned idx, unsigned pxm)
>> +{
>> +return ((pxm2node[idx].pxm == pxm) &&
>> +(pxm2node[idx].node != NUMA_NO_NODE));
>> +}
>> +
>> +nodeid_t pxm_to_node(unsigned pxm)
>> +{
>> +unsigned i;
>> +
>> +if ( (pxm < ARRAY_SIZE(pxm2node)) && node_found(pxm, pxm) )
>> +return pxm2node[pxm].node;
>> +
>> +for ( i = 0; i < ARRAY_SIZE(pxm2node); i++ )
>> +if ( node_found(i, pxm) )
>> +return pxm2node[i].node;
>> +
>> +return NUMA_NO_NODE;
>> +}
>> +
>> +nodeid_t setup_node(unsigned pxm)
>
>
> This name is too generic. The name of the function should make clear it is
> an ACPI only function.
>
OK
> [...]
>
>> +unsigned node_to_pxm(nodeid_t n)
>> +{
>> +unsigned i;
>> +
>> +if ( (n < 

Re: [Xen-devel] [RFC PATCH v1 15/21] ARM: NUMA: Extract MPIDR from MADT table

[Julien Grall]

Hello Vijay,

On 09/02/17 15:57, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K 

Parse MADT table and extract MPIDR for all
CPU IDs in MADT ACPI_MADT_TYPE_GENERIC_INTERRUPT entries
and store in cpu_uid_to_hwid[].

This mapping is used by SRAT table parsing to
extract MPIDR of the CPU ID.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/Makefile  |   1 +
 xen/arch/arm/acpi_numa.c   | 122 +
 xen/arch/arm/numa.c|   1 +


This new file should go in xen/arch/arm/acpi/


 xen/include/asm-arm/acpi.h |   2 +
 4 files changed, 126 insertions(+)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7694485..8c5e67b 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -51,6 +51,7 @@ obj-y += vpsci.o
 obj-y += vuart.o
 obj-$(CONFIG_NUMA) += numa.o
 obj-$(CONFIG_NUMA) += dt_numa.o
+obj-$(CONFIG_ACPI_NUMA) += acpi_numa.o

 #obj-bin-y += o

diff --git a/xen/arch/arm/acpi_numa.c b/xen/arch/arm/acpi_numa.c
new file mode 100644
index 000..3ee87f2
--- /dev/null
+++ b/xen/arch/arm/acpi_numa.c
@@ -0,0 +1,122 @@
+/*
+ * ACPI based NUMA setup
+ *
+ * Copyright (C) 2016 - Cavium Inc.
+ * Vijaya Kumar K 
+ *
+ * Reads the ACPI MADT and SRAT table to setup NUMA information.
+ *
+ * Contains Excerpts from x86 implementation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.


Xen is GPLv2, please update the license accordingly.


+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+extern nodemask_t numa_nodes_parsed;
+struct uid_to_mpidr {
+u32 uid;
+u64 mpidr;
+};
+
+/* Holds mapping of CPU id to MPIDR read from MADT */
+static struct uid_to_mpidr cpu_uid_to_hwid[NR_CPUS] __read_mostly;
+
+static __init void bad_srat(void)
+{
+int i;
+
+printk(KERN_ERR "SRAT: SRAT not used.\n");
+acpi_numa = -1;
+for (i = 0; i < ARRAY_SIZE(pxm2node); i++)
+pxm2node[i].node = NUMA_NO_NODE;
+}
+
+static u64 acpi_get_cpu_mpidr(int uid)
+{
+int i;
+
+if ( uid < ARRAY_SIZE(cpu_uid_to_hwid) && cpu_uid_to_hwid[uid].uid == uid 
&&
+ cpu_uid_to_hwid[uid].mpidr != MPIDR_INVALID )
+return cpu_uid_to_hwid[uid].mpidr;


Please don't make a special case. This makes more complicate to read the 
code.


We should just loop to find the entry matching the UID.


+
+for ( i = 0; i < NR_CPUS; i++ )


You can limit the loop by keeping an the number of element in the array.


+{
+if ( cpu_uid_to_hwid[i].uid == uid )
+return cpu_uid_to_hwid[i].mpidr;
+}
+
+return MPIDR_INVALID;
+}
+
+static void __init
+acpi_map_cpu_to_mpidr(struct acpi_madt_generic_interrupt *processor)
+{
+static int cpus = 0;
+
+u64 mpidr = processor->arm_mpidr & MPIDR_HWID_MASK;
+
+if ( mpidr == MPIDR_INVALID )
+{
+printk("Skip MADT cpu entry with invalid MPIDR\n");
+bad_srat();
+return;
+}
+
+cpu_uid_to_hwid[cpus].mpidr = mpidr;
+cpu_uid_to_hwid[cpus].uid = processor->uid;
+
+cpus++;
+}
+
+static int __init acpi_parse_madt_handler(struct acpi_subtable_header *header,
+  const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *p =
+   container_of(header, struct acpi_madt_generic_interrupt, 
header);
+
+if ( BAD_MADT_ENTRY(p, end) )
+{
+/* Though MADT is invalid, we disable NUMA by calling bad_srat() */
+bad_srat();
+return -EINVAL;
+}
+
+acpi_table_print_madt_entry(header);
+acpi_map_cpu_to_mpidr(p);
+
+return 0;
+}


Why do you need to parse the MADT again? Can't this be done in the 
parsing made in acpi/boot.c?



+
+void __init acpi_map_uid_to_mpidr(void)
+{
+int i;


unsigned int.


+
+for ( i  = 0; i < NR_CPUS; i++ )
+{
+cpu_uid_to_hwid[i].mpidr = MPIDR_INVALID;
+cpu_uid_to_hwid[i].uid = -1;
+}
+
+acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+acpi_parse_madt_handler, 0);
+}
+
+void __init acpi_numa_arch_fixup(void) {}


Missing emacs magic.


diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 31dc552..5c49347 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 


Why this include? This patch should compile without it.


 #include 
 #include 
 #include 
diff --git a/xen/include/asm-arm/acpi.h 

Re: [Xen-devel] [RFC PATCH v1 11/21] ARM: NUMA: Add fallback on NUMA failure

[Vijay Kilari]

On Thu, Mar 2, 2017 at 9:39 PM, Julien Grall  wrote:
> Hello Vijay,
>
> On 09/02/17 15:57, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K 
>>
>> On NUMA initialization failure, reset all the
>> NUMA structures to emulate as single node.
>>
>> Signed-off-by: Vijaya Kumar 
>> ---
>>  xen/arch/arm/numa.c | 50
>> --
>>  1 file changed, 48 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
>> index aa34c82..31dc552 100644
>> --- a/xen/arch/arm/numa.c
>> +++ b/xen/arch/arm/numa.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -127,6 +128,29 @@ static int __init numa_scan_mem_nodes(void)
>>  return 0;
>>  }
>>
>> +static void __init numa_dummy_init(unsigned long start_pfn,
>> +   unsigned long end_pfn)
>
>
> This code is very similar to numa_initmem_init on x86. This is a call to
> make the code more generic.

Yes, I have noticed it and taken care in next revision
>
>
>> +{
>> +int i;
>> +
>> +nodes_clear(numa_nodes_parsed);
>> +memnode_shift = BITS_PER_LONG - 1;
>> +memnodemap = _memnodemap;
>> +nodes_clear(node_online_map);
>> +node_set_online(0);
>> +
>> +for ( i = 0; i < NR_CPUS; i++ )
>> +numa_set_node(i, 0);
>> +
>> +node_distance = NULL;
>> +for ( i = 0; i < MAX_NUMNODES * 2; i++ )
>> +_node_distance[i] = 0;
>> +
>> +cpumask_copy(_to_cpumask[0], cpumask_of(0));
>> +setup_node_bootmem(0, (u64)start_pfn << PAGE_SHIFT,
>> +   (u64)end_pfn << PAGE_SHIFT);
>> +}
>> +
>>  static int __init numa_initmem_init(void)
>>  {
>>  if ( !numa_mem_init() )
>> @@ -151,7 +175,9 @@ void __init init_cpu_to_node(void)
>>
>>  int __init numa_init(void)
>
>
> I would make numa_initmem_init from x86 generic and have an arch specific
> function called from there.
>
>>  {
>> -int i, ret = 0;
>> +int i, bank, ret = 0;
>> +paddr_t ram_start = ~0;
>> +paddr_t ram_end = 0;
>>
>>  if ( numa_off )
>>  goto no_numa;
>> @@ -164,8 +190,28 @@ int __init numa_init(void)
>>  if ( !ret )
>>  ret = numa_initmem_init();
>>
>> +if ( !ret )
>> +return 0;
>> +
>>  no_numa:
>> -return ret;
>> +for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ )
>> +{
>> +paddr_t bank_start = bootinfo.mem.bank[bank].start;
>> +paddr_t bank_end = bank_start + bootinfo.mem.bank[bank].size;
>> +
>> +ram_start = min(ram_start, bank_start);
>> +ram_end = max(ram_end, bank_end);
>> +}
>
>
> I am sure this could be done in setup.c rather than here.

Yes, I have noticed it and taken care in next revision.
numa_init() is called from setup_mm() with ram_start and ram_end as params

>
>> +
>> +printk(XENLOG_INFO "%s\n",
>> +   numa_off ? "NUMA turned off" : "No NUMA configuration found");
>> +
>> +printk(XENLOG_INFO "Faking a node at %016"PRIx64"-%016"PRIx64"\n",
>> +   (u64)ram_start, (u64)ram_end);
>> +
>> +numa_dummy_init(PFN_UP(ram_start),PFN_DOWN(ram_end));
>> +
>> +return 0;
>>  }
>>
>>  int __init arch_numa_setup(char *opt)
>>
>
> Regards,
>
> --
> Julien Grall

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

Re: [Xen-devel] [RFC PATCH v1 10/21] ARM: NUMA: Add memory NUMA support

[Vijay Kilari]

On Thu, Mar 2, 2017 at 9:35 PM, Julien Grall  wrote:
> Hello Vijay,
>
>
> On 09/02/17 15:57, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K 
>>
>> For all banks in bootinfo.mem, update nodes[] with
>> corresponding nodeid and register these nodes by
>> calling setup_node_bootmem().
>> compute memnode_shift and initialize memnodemap[] to fetch
>> nodeid for a given physical address.
>>
>> Signed-off-by: Vijaya Kumar K 
>> ---
>>  xen/arch/arm/numa.c| 90
>> ++
>>  xen/common/numa.c  | 14 
>>  xen/include/xen/numa.h |  1 +
>>  3 files changed, 105 insertions(+)
>>
>> diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
>> index d4dbad4..aa34c82 100644
>> --- a/xen/arch/arm/numa.c
>> +++ b/xen/arch/arm/numa.c
>> @@ -24,10 +24,15 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  int _node_distance[MAX_NUMNODES * 2];
>>  int *node_distance;
>>  extern nodemask_t numa_nodes_parsed;
>> +extern struct node nodes[MAX_NUMNODES] __initdata;
>> +extern int num_node_memblks;
>> +extern struct node node_memblk_range[NR_NODE_MEMBLKS];
>> +extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
>>
>>  void __init numa_set_cpu_node(int cpu, unsigned long hwid)
>>  {
>> @@ -51,6 +56,88 @@ u8 __node_distance(nodeid_t a, nodeid_t b)
>>
>>  EXPORT_SYMBOL(__node_distance);
>>
>> +static int __init numa_mem_init(void)
>
>
> The function return only 2 different value either 0 or -EINVAL. It should be
> better to use a boolean.
>
>> +{
>> +nodemask_t memory_nodes_parsed;
>> +int bank, nodeid;
>> +struct node *nd;
>> +paddr_t start, size, end;
>> +
>> +nodes_clear(memory_nodes_parsed);
>> +for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ )
>> +{
>> +start = bootinfo.mem.bank[bank].start;
>> +size = bootinfo.mem.bank[bank].size;
>> +end = start + size;
>> +
>> +nodeid = get_numa_node(start, end);
>> +if ( nodeid == -EINVAL || nodeid > MAX_NUMNODES )
>
>
> If found, how the nodeid could be invalid? IHMO, this is a parsing bug.
>
>> +{
>> +printk(XENLOG_WARNING
>> +   "NUMA: node for mem bank start 0x%lx - 0x%lx not
>> found\n",
>> +   start, end);
>> +
>> +return -EINVAL;
>> +}
>> +
>> +nd = [nodeid];
>> +if ( !node_test_and_set(nodeid, memory_nodes_parsed) )
>> +{
>> +nd->start = start;
>> +nd->end = end;
>> +}
>> +else
>> +{
>> +if ( start < nd->start )
>> +nd->start = start;
>> +if ( nd->end < end )
>> +nd->end = end;
>> +}
>> +}
>
>
> This function is quite confusing. What is the purpose? Why do you go through
> bootinfo.mem and not node_memblk_range?

node_memblk_range[] contains memory bank to node info read from DT memory node.
We go through bootinfo.mem and populate nodes[] with actual memory
range indexed by
nodeid.

I think this is similar to nodes_cover_memory in arch/x86/srat.c

>
>> +
>> +return 0;
>> +}
>> +
>> +/* Use the information discovered above to actually set up the nodes. */
>> +static int __init numa_scan_mem_nodes(void)
>
>
> This function looks very similar to acpi_scan_nodes on x86. This is call to
> move more code in common.
>
Yes, I have already fixed it in next revision.

>
>> +{
>> +int i;
>> +
>> +memnode_shift = compute_hash_shift(node_memblk_range,
>> num_node_memblks,
>> +   memblk_nodeid);
>> +if ( memnode_shift < 0 )
>> +{
>> +printk(XENLOG_WARNING "No NUMA hash found.\n");
>> +memnode_shift = 0;
>> +}
>> +
>> +for_each_node_mask(i, numa_nodes_parsed)
>> +{
>> +u64 size = node_memblk_range[i].end - node_memblk_range[i].start;
>> +
>> +if ( size == 0 )
>> +printk(XENLOG_WARNING "NUMA: Node %u has no memory. \n", i);
>> +
>> +printk(XENLOG_INFO
>> +   "NUMA: NODE[%d]: Start 0x%lx End 0x%lx\n",
>> +   i, nodes[i].start, nodes[i].end);
>> +setup_node_bootmem(i, nodes[i].start, nodes[i].end);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int __init numa_initmem_init(void)
>> +{
>> +if ( !numa_mem_init() )
>> +{
>> +if ( !numa_scan_mem_nodes() )
>> +return 0;
>> +}
>
>
> This could be simplified with
>
> if ( !numa_mem_init() && !num_scan_mem_nodes )
>return 0;
>
> However looking at the usage, this function seems rather pointless.

OK. I have changed this in next revision.

>
>> +
>> +return -EINVAL;
>> +}
>> +
>>  /*
>>   * Setup early cpu_to_node.
>>   */
>> @@ -74,6 +161,9 @@ int __init numa_init(void)
>>
>>  ret = dt_numa_init();
>>
>> +if ( !ret )
>> +ret = numa_initmem_init();
>> +
>>  no_numa:
>>  return ret;
>>  }
>> diff --git 

Re: [Xen-devel] [PATCH 2/7] x86/shadow: Try to correctly identify implicit supervisor accesses

[Tim Deegan]

At 14:03 + on 27 Feb (1488204193), Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper 

Reviewed-by: Tim Deegan 

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

[Xen-devel] [linux-linus test] 106354: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linux4977ab6e92e267afe9d8f78438c3db330ca8434c
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  602 days
Failing since 59348  2015-07-10 04:24:05 Z  601 days  306 attempts
Testing same since   106354  2017-03-02 05:52:12 Z0 days1 attempts


8028 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 

Re: [Xen-devel] [PATCH 6/7] x86/pagewalk: Consistently use guest_walk_*() helpers for translation

[Tim Deegan]

At 14:03 + on 27 Feb (1488204197), Andrew Cooper wrote:
> hap_p2m_ga_to_gfn() and sh_page_fault() currently use guest_l1e_get_gfn() to
> obtain the translation of a pagewalk.  This is conceptually wrong (the
> semantics of gw.l1e is an internal detail), and will actually be wrong when
> PSE36 superpage support is fixed.  Switch them to using guest_walk_to_gfn().
> 
> Take the opportunity to const-correct the walk_t parameter of the
> guest_walk_to_*() helpers, and implement guest_walk_to_gpa() in terms of
> guest_walk_to_gfn() to avoid duplicating the actual translation calculation.
> 
> While editing guest_walk_to_gpa(), fix a latent bug by causing it to return
> INVALID_PADDR rather than 0 for a failed translation, as 0 is also a valid
> successful result.  The sole caller, sh_page_fault(), has already confirmed
> that the translation is valid, so this doesn't cause a behavioural change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Tim Deegan 

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

Re: [Xen-devel] [PATCH 3/7] x86/pagewalk: Helpers for reserved bit handling

[Tim Deegan]

At 14:03 + on 27 Feb (1488204194), Andrew Cooper wrote:
> Some bits are unconditionally reserved in pagetable entries, or reserved
> because of alignment restrictions.  Other bits are reserved because of control
> register configuration.
> 
> Introduce helpers which take an individual vcpu and guest pagetable entry, and
> calculates whether any reserved bits are set.
> 
> While here, add a couple of newlines to aid readability, drop some trailing
> whitespace and bool/const correct the existing helpers to allow the new
> helpers to take const vcpu pointers.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Tim Deegan 

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

Re: [Xen-devel] [PATCH 1/7] x86/hvm: Correctly identify implicit supervisor accesses

[Tim Deegan]

At 14:03 + on 27 Feb (1488204192), Andrew Cooper wrote:
> All actions which refer to the active ldt/gdt/idt or task register
> (e.g. loading a new segment selector) are known as implicit supervisor
> accesses, even when the access originates from user code.
> 
> The distinction is necessary in the pagewalk when SMAP is enabled.  Refer to
> Intel SDM Vol 3 "Access Rights" for the exact details.
> 
> Introduce a new pagewalk input, and make use of the new system segment
> references in hvmemul_{read,write}().  While modifying those areas, move the
> calculation of the appropriate pagewalk input before its first use.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Tim Deegan 

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

Re: [Xen-devel] [RFC PATCH v1 11/21] ARM: NUMA: Add fallback on NUMA failure

[Julien Grall]

Hello Vijay,

On 09/02/17 15:57, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K 

On NUMA initialization failure, reset all the
NUMA structures to emulate as single node.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/numa.c | 50 --
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index aa34c82..31dc552 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -127,6 +128,29 @@ static int __init numa_scan_mem_nodes(void)
 return 0;
 }

+static void __init numa_dummy_init(unsigned long start_pfn,
+   unsigned long end_pfn)


This code is very similar to numa_initmem_init on x86. This is a call to 
make the code more generic.



+{
+int i;
+
+nodes_clear(numa_nodes_parsed);
+memnode_shift = BITS_PER_LONG - 1;
+memnodemap = _memnodemap;
+nodes_clear(node_online_map);
+node_set_online(0);
+
+for ( i = 0; i < NR_CPUS; i++ )
+numa_set_node(i, 0);
+
+node_distance = NULL;
+for ( i = 0; i < MAX_NUMNODES * 2; i++ )
+_node_distance[i] = 0;
+
+cpumask_copy(_to_cpumask[0], cpumask_of(0));
+setup_node_bootmem(0, (u64)start_pfn << PAGE_SHIFT,
+   (u64)end_pfn << PAGE_SHIFT);
+}
+
 static int __init numa_initmem_init(void)
 {
 if ( !numa_mem_init() )
@@ -151,7 +175,9 @@ void __init init_cpu_to_node(void)

 int __init numa_init(void)


I would make numa_initmem_init from x86 generic and have an arch 
specific function called from there.



 {
-int i, ret = 0;
+int i, bank, ret = 0;
+paddr_t ram_start = ~0;
+paddr_t ram_end = 0;

 if ( numa_off )
 goto no_numa;
@@ -164,8 +190,28 @@ int __init numa_init(void)
 if ( !ret )
 ret = numa_initmem_init();

+if ( !ret )
+return 0;
+
 no_numa:
-return ret;
+for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ )
+{
+paddr_t bank_start = bootinfo.mem.bank[bank].start;
+paddr_t bank_end = bank_start + bootinfo.mem.bank[bank].size;
+
+ram_start = min(ram_start, bank_start);
+ram_end = max(ram_end, bank_end);
+}


I am sure this could be done in setup.c rather than here.


+
+printk(XENLOG_INFO "%s\n",
+   numa_off ? "NUMA turned off" : "No NUMA configuration found");
+
+printk(XENLOG_INFO "Faking a node at %016"PRIx64"-%016"PRIx64"\n",
+   (u64)ram_start, (u64)ram_end);
+
+numa_dummy_init(PFN_UP(ram_start),PFN_DOWN(ram_end));
+
+return 0;
 }

 int __init arch_numa_setup(char *opt)



Regards,

--
Julien Grall

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

[Xen-devel] [PATCH v2 4/5] golang/xenlight: Implement libxl_domain_info and libxl_domain_unpause

[Ronald Rojas]

Add calls for the following host-related functionality:
- libxl_domain_info
- libxl_domain_unpause

Include Golang version for the libxl_domain_info as
DomainInfo.

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 
---
Changes since last version
- Created type and enumeration of DomainType and ShutdownReason

- Created String() method for DomainType and ShutdownReason

- Refactored creating DomainInfo from c type into seperate
toGo() function

- Applied libxl_domain_info_init/dispose()

- whitespace fixes

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com

---
---
 tools/golang/xenlight/xenlight.go | 132 ++
 1 file changed, 132 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 63cc805..18dedcb 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -34,6 +34,7 @@ import "C"
 import (
"fmt"
"unsafe"
+   "time"
 )
 
 /*
@@ -102,6 +103,12 @@ var errors = [...]string{
  * Types: Builtins
  */
 
+type Domid uint32
+
+type MemKB uint64
+
+type Uuid C.libxl_uuid
+
 type Context struct {
ctx *C.libxl_ctx
 }
@@ -203,6 +210,95 @@ func (cinfo *C.libxl_version_info) toGo() (info 
*VersionInfo) {
return
 }
 
+type ShutdownReason int32
+
+const(
+   ShutdownReasonUnknown = ShutdownReason(C.LIBXL_SHUTDOWN_REASON_UNKNOWN)
+   ShutdownReasonPoweroff = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_POWEROFF)
+   ShutdownReasonReboot = ShutdownReason(C.LIBXL_SHUTDOWN_REASON_REBOOT)
+   ShutdownReasonSuspend = ShutdownReason(C.LIBXL_SHUTDOWN_REASON_SUSPEND)
+   ShutdownReasonCrash = ShutdownReason(C.LIBXL_SHUTDOWN_REASON_CRASH)
+   ShutdownReasonWatchdog = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_WATCHDOG)
+   ShutdownReasonSoftReset = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_SOFT_RESET)
+
+)
+
+func (sr ShutdownReason) String()(str string){
+   cstr := C.libxl_shutdown_reason_to_string(C.libxl_shutdown_reason(sr))
+   str = C.GoString(cstr)
+
+   return
+}
+
+type DomainType int32
+
+const(
+   DomainTypeInvalid = DomainType(C.LIBXL_DOMAIN_TYPE_INVALID)
+   DomainTypeHvm = DomainType(C.LIBXL_DOMAIN_TYPE_HVM)
+   DomainTypePv = DomainType(C.LIBXL_DOMAIN_TYPE_PV)
+)
+
+func (dt DomainType) String()(str string){
+   cstr := C.libxl_domain_type_to_string(C.libxl_domain_type(dt))
+   str = C.GoString(cstr)
+
+   return
+}
+
+type Dominfo struct {
+   Uuid   Uuid
+   Domid  Domid
+   Ssidref uint32
+   SsidLabel string
+   Runningbool
+   Blockedbool
+   Paused bool
+   Shutdown   bool
+   Dying  bool
+   NeverStop bool
+
+   ShutdownReason   int32
+   OutstandingMemkb MemKB
+   CurrentMemkb MemKB
+   SharedMemkb  MemKB
+   PagedMemkb   MemKB
+   MaxMemkb MemKB
+   CpuTime  time.Duration
+   VcpuMaxId   uint32
+   VcpuOnline   uint32
+   Cpupool   uint32
+   DomainType   int32
+
+}
+
+func (cdi *C.libxl_dominfo) toGo()(di *Dominfo){
+
+   di = {}
+   di.Uuid = Uuid(cdi.uuid)
+   di.Domid = Domid(cdi.domid)
+   di.Ssidref = uint32(cdi.ssidref)
+   di.SsidLabel = C.GoString(cdi.ssid_label)
+   di.Running = bool(cdi.running)
+   di.Blocked = bool(cdi.blocked)
+   di.Paused = bool(cdi.paused)
+   di.Shutdown = bool(cdi.shutdown)
+   di.Dying = bool(cdi.dying)
+   di.NeverStop= bool(cdi.never_stop)
+   di.ShutdownReason= int32(cdi.shutdown_reason)
+   di.OutstandingMemkb= MemKB(cdi.outstanding_memkb)
+   di.CurrentMemkb = MemKB(cdi.current_memkb)
+   di.SharedMemkb = MemKB(cdi.shared_memkb)
+   di.PagedMemkb = MemKB(cdi.paged_memkb)
+   di.MaxMemkb= MemKB(cdi.max_memkb)
+   di.CpuTime= time.Duration(cdi.cpu_time)
+   di.VcpuMaxId = uint32(cdi.vcpu_max_id)
+   di.VcpuOnline = uint32(cdi.vcpu_online)
+   di.Cpupool = uint32(cdi.cpupool)
+   di.DomainType = int32(cdi.domain_type)
+
+   return
+}
+
 /*
  * Context
  */
@@ -356,3 +452,39 @@ func (Ctx *Context) GetVersionInfo() (info *VersionInfo, 
err error) {
 
return
 }
+
+func (Ctx *Context) DomainInfo(Id Domid) (di *Dominfo, err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var cdi C.libxl_dominfo
+   C.libxl_dominfo_init()
+
+   ret := C.libxl_domain_info(Ctx.ctx, unsafe.Pointer(), 
C.uint32_t(Id))
+
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   di = cdi.toGo()
+   C.libxl_dominfo_dispose()
+
+   return
+}
+
+func (Ctx *Context) DomainUnpause(Id Domid) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   ret := 

[Xen-devel] [PATCH v2 2/5] golang/xenlight: Add error constants and standard handling

[Ronald Rojas]

Create error type Errorxl for throwing proper xenlight
errors.

Update Ctx functions to throw Errorxl errors.

Signed-off-by: Ronald Rojas 
---
Changes since last patch:

- Whitespace fixes

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/xenlight.go | 81 +--
 1 file changed, 77 insertions(+), 4 deletions(-)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 0a0cea2..cbd3527 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -29,17 +29,79 @@ import "C"
  *
  * To get back to static linking:
  * #cgo LDFLAGS: -lxenlight -lyajl_s -lxengnttab -lxenstore -lxenguest 
-lxentoollog -lxenevtchn -lxenctrl -lblktapctl -lxenforeignmemory -lxencall -lz 
-luuid -lutil
-*/
+ */
 
 import (
"fmt"
"unsafe"
 )
 
+/*
+ * Errors
+ */
+
+type Error int
+
+const (
+   ErrorNonspecific  = Error(-C.ERROR_NONSPECIFIC)
+   ErrorVersion  = Error(-C.ERROR_VERSION)
+   ErrorFail = Error(-C.ERROR_FAIL)
+   ErrorNi   = Error(-C.ERROR_NI)
+   ErrorNomem= Error(-C.ERROR_NOMEM)
+   ErrorInval= Error(-C.ERROR_INVAL)
+   ErrorBadfail  = Error(-C.ERROR_BADFAIL)
+   ErrorGuestTimedout= Error(-C.ERROR_GUEST_TIMEDOUT)
+   ErrorTimedout = Error(-C.ERROR_TIMEDOUT)
+   ErrorNoparavirt   = Error(-C.ERROR_NOPARAVIRT)
+   ErrorNotReady = Error(-C.ERROR_NOT_READY)
+   ErrorOseventRegFail   = Error(-C.ERROR_OSEVENT_REG_FAIL)
+   ErrorBufferfull   = Error(-C.ERROR_BUFFERFULL)
+   ErrorUnknownChild = Error(-C.ERROR_UNKNOWN_CHILD)
+   ErrorLockFail = Error(-C.ERROR_LOCK_FAIL)
+   ErrorJsonConfigEmpty  = Error(-C.ERROR_JSON_CONFIG_EMPTY)
+   ErrorDeviceExists = Error(-C.ERROR_DEVICE_EXISTS)
+   ErrorCheckpointDevopsDoesNotMatch = 
Error(-C.ERROR_CHECKPOINT_DEVOPS_DOES_NOT_MATCH)
+   ErrorCheckpointDeviceNotSupported = 
Error(-C.ERROR_CHECKPOINT_DEVICE_NOT_SUPPORTED)
+   ErrorVnumaConfigInvalid   = Error(-C.ERROR_VNUMA_CONFIG_INVALID)
+   ErrorDomainNotfound   = Error(-C.ERROR_DOMAIN_NOTFOUND)
+   ErrorAborted  = Error(-C.ERROR_ABORTED)
+   ErrorNotfound = Error(-C.ERROR_NOTFOUND)
+   ErrorDomainDestroyed  = Error(-C.ERROR_DOMAIN_DESTROYED)
+   ErrorFeatureRemoved   = Error(-C.ERROR_FEATURE_REMOVED)
+)
+
+var errors = [...]string{
+   ErrorNonspecific:  "Non-specific error",
+   ErrorVersion:  "Wrong version",
+   ErrorFail: "Failed",
+   ErrorNi:   "Not Implemented",
+   ErrorNomem:"No memory",
+   ErrorInval:"Invalid argument",
+   ErrorBadfail:  "Bad Fail",
+   ErrorGuestTimedout:"Guest timed out",
+   ErrorTimedout: "Timed out",
+   ErrorNoparavirt:   "No Paravirtualization",
+   ErrorNotReady: "Not ready",
+   ErrorOseventRegFail:   "OS event registration failed",
+   ErrorBufferfull:   "Buffer full",
+   ErrorUnknownChild: "Unknown child",
+   ErrorLockFail: "Lock failed",
+   ErrorJsonConfigEmpty:  "JSON config empty",
+   ErrorDeviceExists: "Device exists",
+   ErrorCheckpointDevopsDoesNotMatch: "Checkpoint devops does not match",
+   ErrorCheckpointDeviceNotSupported: "Checkpoint device not supported",
+   ErrorVnumaConfigInvalid:   "VNUMA config invalid",
+   ErrorDomainNotfound:   "Domain not found",
+   ErrorAborted:  "Aborted",
+   ErrorNotfound: "Not found",
+   ErrorDomainDestroyed:  "Domain destroyed",
+   ErrorFeatureRemoved:   "Feature removed",
+}
 
 /*
  * Types: Builtins
  */
+
 type Context struct {
ctx *C.libxl_ctx
 }
@@ -49,6 +111,17 @@ type Context struct {
  */
 var Ctx Context
 
+func (e Error) Error() string {
+   if 0 < int(e) && int(e) < len(errors) {
+   s := errors[e]
+   if s != "" {
+   return s
+   }
+   }
+   return fmt.Sprintf("libxl error: %d", -e)
+
+}
+
 func (Ctx *Context) IsOpen() bool {
return Ctx.ctx != nil
 }
@@ -58,11 +131,11 @@ func (Ctx *Context) Open() (err error) {
return
}
 
-   

[Xen-devel] [PATCH v2 1/5] golang/xenlight: Create stub package

[Ronald Rojas]

Create a basic Makefile to build and install libxenlight Golang
bindings. Also add a stub package which only opens libxl context.

Include a global xenlight.Ctx variable which can be used as the
default context by the entire program if desired.

For now, return simple errors. Proper error handling will be
added in next patch.

Signed-off-by: Ronald Rojas 
Signed-off-by: George Dunlap 
---

Changes:
- Changed GPL Lisense to LGPL Lisense

- Initialized xentoollog_logger for storing error messages

- Moved manual-enable config option to tools/Rules.mk, use
  CONFIG_GOLANG in tools/Makefile

- Added XEN_GOPATH, pointing to tools/golang

- Modified tools/golang/xenlight makefile to construct necessary $GOPATH

- Added tools/golang/Makefile, so we don't need special rules in tools
  to make tools/golang/xenlight; and so we have a single place to remove the
  $GOPATH build side-effects ($GOPATH/src and $GOPATH/pkg)

- Build of tools/golang/xenlight sets $GOPATH and does a 'go install'

- Use tree-provided CFLAGS_libxenlight and LDLIBS_libxenlight, rather
  than hard-coding our own

- Made a PKGSOURCES variable to track dependencies of all target files
  which need to be part of the output package (i.e., what's put in
  $GOPATH/src).  At the moment this is one file, but it will probably
  be more once we start using the IDL.

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/Makefile|  1 +
 tools/Rules.mk|  6 +++
 tools/golang/Makefile | 27 +
 tools/golang/xenlight/Makefile| 49 ++
 tools/golang/xenlight/xenlight.go | 85 +++
 5 files changed, 168 insertions(+)
 create mode 100644 tools/golang/Makefile
 create mode 100644 tools/golang/xenlight/Makefile
 create mode 100644 tools/golang/xenlight/xenlight.go

diff --git a/tools/Makefile b/tools/Makefile
index 77e0723..df1fda1 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -31,6 +31,7 @@ endif
 
 SUBDIRS-y += xenpmd
 SUBDIRS-y += libxl
+SUBDIRS-$(CONFIG_GOLANG) += golang
 SUBDIRS-y += helpers
 SUBDIRS-$(CONFIG_X86) += xenpaging
 SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
diff --git a/tools/Rules.mk b/tools/Rules.mk
index b35999b..24e5220 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -30,6 +30,12 @@ XENSTORE_XENSTORED ?= y
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Uncomment to compile with Go
+CONFIG_GOLANG ?= y
+ifeq ($(CONFIG_GOLANG),y)
+XEN_GOPATH= $(XEN_ROOT)/tools/golang
+endif
+
 ifeq ($(debug_symbols),y)
 CFLAGS += -g3
 endif
diff --git a/tools/golang/Makefile b/tools/golang/Makefile
new file mode 100644
index 000..47a9235
--- /dev/null
+++ b/tools/golang/Makefile
@@ -0,0 +1,27 @@
+XEN_ROOT=$(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+# In order to link against a package in Go, the package must live in a
+# directory tree in the way that Go expects.  To make this possible,
+# there must be a directory such that we can set GOPATH=${dir}, and
+# the package will be under $GOPATH/src/${full-package-path}.
+
+# So we set XEN_GOPATH to $XEN_ROOT/tools/golang.  The xenlight
+# "package build" directory ($PWD/xenlight) will create the "package
+# source" directory in the proper place.  Go programs can use this
+# package by setting GOPATH=$(XEN_GOPATH).
+
+SUBDIRS-y = xenlight
+
+.PHONY: build all
+all build: subdirs-all
+
+.PHONY: install
+install: subdirs-install
+
+.PHONY: clean
+clean: subdirs-clean
+   $(RM) -r src pkg
+
+.PHONY: distclean
+distclean: clean
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
new file mode 100644
index 000..5d578f3
--- /dev/null
+++ b/tools/golang/xenlight/Makefile
@@ -0,0 +1,49 @@
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+# Standing boldly against convention, we insist on installing the
+# package source under $(prefix)/share/gocode
+GOCODE_DIR ?= $(prefix)/share/gocode/
+GOXL_PKG_DIR = /src/xenproject.org/xenlight/
+GOXL_INSTALL_DIR = $(GOCODE_DIR)$(GOXL_PKG_DIR)
+
+# PKGSOURCES: Files which comprise the distributed source package
+PKGSOURCES = xenlight.go
+
+GO ?= go
+
+.PHONY: all
+all: build
+
+.PHONY: package
+package: $(XEN_GOPATH)$(GOXL_PKG_DIR)$(PKGSOURCES)
+
+$(XEN_GOPATH)/src/xenproject.org/xenlight/$(PKGSOURCES): $(PKGSOURCES)
+   $(INSTALL_DIR) $(XEN_GOPATH)$(GOXL_PKG_DIR)
+   $(INSTALL_DATA) $(PKGSOURCES) $(XEN_GOPATH)$(GOXL_PKG_DIR)
+
+# Go will do its own dependency checking, and not actuall go through
+# with the build if none of the input files have changed.
+#
+# NB that because the users of this library need to be able to
+# recompile the library from source, it needs to include '-lxenlight'
+# in the LDFLAGS; and thus we need to add -L$(XEN_XENLIGHT) here
+# so that it can find the actual library.
+.PHONY: build
+build: package
+   CGO_CFLAGS="$(CFLAGS_libxenlight)" 

Re: [Xen-devel] [RFC PATCH v1 10/21] ARM: NUMA: Add memory NUMA support

[Julien Grall]

Hello Vijay,

On 09/02/17 15:57, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K 

For all banks in bootinfo.mem, update nodes[] with
corresponding nodeid and register these nodes by
calling setup_node_bootmem().
compute memnode_shift and initialize memnodemap[] to fetch
nodeid for a given physical address.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/numa.c| 90 ++
 xen/common/numa.c  | 14 
 xen/include/xen/numa.h |  1 +
 3 files changed, 105 insertions(+)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index d4dbad4..aa34c82 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -24,10 +24,15 @@
 #include 
 #include 
 #include 
+#include 

 int _node_distance[MAX_NUMNODES * 2];
 int *node_distance;
 extern nodemask_t numa_nodes_parsed;
+extern struct node nodes[MAX_NUMNODES] __initdata;
+extern int num_node_memblks;
+extern struct node node_memblk_range[NR_NODE_MEMBLKS];
+extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];

 void __init numa_set_cpu_node(int cpu, unsigned long hwid)
 {
@@ -51,6 +56,88 @@ u8 __node_distance(nodeid_t a, nodeid_t b)

 EXPORT_SYMBOL(__node_distance);

+static int __init numa_mem_init(void)


The function return only 2 different value either 0 or -EINVAL. It 
should be better to use a boolean.



+{
+nodemask_t memory_nodes_parsed;
+int bank, nodeid;
+struct node *nd;
+paddr_t start, size, end;
+
+nodes_clear(memory_nodes_parsed);
+for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ )
+{
+start = bootinfo.mem.bank[bank].start;
+size = bootinfo.mem.bank[bank].size;
+end = start + size;
+
+nodeid = get_numa_node(start, end);
+if ( nodeid == -EINVAL || nodeid > MAX_NUMNODES )


If found, how the nodeid could be invalid? IHMO, this is a parsing bug.


+{
+printk(XENLOG_WARNING
+   "NUMA: node for mem bank start 0x%lx - 0x%lx not found\n",
+   start, end);
+
+return -EINVAL;
+}
+
+nd = [nodeid];
+if ( !node_test_and_set(nodeid, memory_nodes_parsed) )
+{
+nd->start = start;
+nd->end = end;
+}
+else
+{
+if ( start < nd->start )
+nd->start = start;
+if ( nd->end < end )
+nd->end = end;
+}
+}


This function is quite confusing. What is the purpose? Why do you go 
through bootinfo.mem and not node_memblk_range?



+
+return 0;
+}
+
+/* Use the information discovered above to actually set up the nodes. */
+static int __init numa_scan_mem_nodes(void)


This function looks very similar to acpi_scan_nodes on x86. This is call 
to move more code in common.



+{
+int i;
+
+memnode_shift = compute_hash_shift(node_memblk_range, num_node_memblks,
+   memblk_nodeid);
+if ( memnode_shift < 0 )
+{
+printk(XENLOG_WARNING "No NUMA hash found.\n");
+memnode_shift = 0;
+}
+
+for_each_node_mask(i, numa_nodes_parsed)
+{
+u64 size = node_memblk_range[i].end - node_memblk_range[i].start;
+
+if ( size == 0 )
+printk(XENLOG_WARNING "NUMA: Node %u has no memory. \n", i);
+
+printk(XENLOG_INFO
+   "NUMA: NODE[%d]: Start 0x%lx End 0x%lx\n",
+   i, nodes[i].start, nodes[i].end);
+setup_node_bootmem(i, nodes[i].start, nodes[i].end);
+}
+
+return 0;
+}
+
+static int __init numa_initmem_init(void)
+{
+if ( !numa_mem_init() )
+{
+if ( !numa_scan_mem_nodes() )
+return 0;
+}


This could be simplified with

if ( !numa_mem_init() && !num_scan_mem_nodes )
   return 0;

However looking at the usage, this function seems rather pointless.


+
+return -EINVAL;
+}
+
 /*
  * Setup early cpu_to_node.
  */
@@ -74,6 +161,9 @@ int __init numa_init(void)

 ret = dt_numa_init();

+if ( !ret )
+ret = numa_initmem_init();
+
 no_numa:
 return ret;
 }
diff --git a/xen/common/numa.c b/xen/common/numa.c
index 62c76af..2f5266a 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -63,6 +63,20 @@ void __init numa_add_memblk(nodeid_t nodeid, u64 start, u64 
size)
 num_node_memblks++;
 }

+int __init get_numa_node(u64 start, u64 end)


I think this function will be confusing for the caller. Why using 
num_node_memblks and not the node itself?



+{
+int i;


Please unsigned int


+
+for ( i = 0; i < num_node_memblks; i++ )
+{
+if ( start >= node_memblk_range[i].start &&
+ end <= node_memblk_range[i].end )
+return memblk_nodeid[i];
+}
+
+return -EINVAL;
+}
+
 int valid_numa_range(u64 start, u64 end, nodeid_t node)
 {
 #ifdef CONFIG_NUMA
diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h
index 9392a89..4f04ab4 100644
--- a/xen/include/xen/numa.h
+++ 

Re: [Xen-devel] [PATCH 1/2] x86/hvm: Don't raise #GP behind the emulators back for CR accesses

[Boris Ostrovsky]

On 03/02/2017 09:59 AM, Andrew Cooper wrote:
> hvm_set_cr{0,4}() are reachable from the emulator, but use
> hvm_inject_hw_exception() directly.
>
> Alter the API to make the callers of hvm_set_cr{0,3,4}() responsible for
> raising #GP, and apply this change to all existing callers.
>
> Signed-off-by: Andrew Cooper 

Reviewed-by:  Boris Ostrovsky 


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

Re: [Xen-devel] [PATCH 1/2] x86/hvm: Don't raise #GP behind the emulators back for CR accesses

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 02 March 2017 15:00
> To: Xen-devel 
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Jun
> Nakajima ; Kevin Tian ;
> Boris Ostrovsky ; Suravee Suthikulpanit
> 
> Subject: [PATCH 1/2] x86/hvm: Don't raise #GP behind the emulators back
> for CR accesses
> 
> hvm_set_cr{0,4}() are reachable from the emulator, but use
> hvm_inject_hw_exception() directly.
> 
> Alter the API to make the callers of hvm_set_cr{0,3,4}() responsible for
> raising #GP, and apply this change to all existing callers.
> 
> Signed-off-by: Andrew Cooper 

emulate code...

Reviewed-by: Paul Durrant 

> ---
> CC: Jan Beulich 
> CC: Paul Durrant 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 
> 
> Issues identified which I am purposefully not fixing in this patch:
> 
> (I will try to get around to them, but probably not in the 4.9 timeframe, at
> this point.)
> 
>  * hvm_set_cr3() doesn't handle bad 32bit PAE PDPTRs properly, as it doesn't
>actually have a path which raises #GP.
>  * There is a lot of redundancy in our HVM CR setting routines, but not
> enough
>to trivially dedup at this point.
>  * Both nested VT-x and SVM are liable raise #GP with L1, rather than failing
>the virtual vmentry/vmexit.  This is not a change in behaviour, but is far
>more obvious now.
>  * The hvm_do_resume() path for vm_event processing has the same bug as
> the
>MSR side, where exceptions are raised after %rip has moved forwards.  This
>is also not a change in behaviour.
> ---
>  xen/arch/x86/hvm/emulate.c| 24 
>  xen/arch/x86/hvm/hvm.c| 59 ++--
> ---
>  xen/arch/x86/hvm/svm/nestedsvm.c  | 14 ++
>  xen/arch/x86/hvm/vmx/vmx.c|  7 -
>  xen/arch/x86/hvm/vmx/vvmx.c   | 29 +++
>  xen/include/asm-x86/hvm/support.h |  6 +++-
>  6 files changed, 101 insertions(+), 38 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index 93782d0..1c66010 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1520,23 +1520,37 @@ static int hvmemul_write_cr(
>  unsigned long val,
>  struct x86_emulate_ctxt *ctxt)
>  {
> +int rc;
> +
>  HVMTRACE_LONG_2D(CR_WRITE, reg, TRC_PAR_LONG(val));
>  switch ( reg )
>  {
>  case 0:
> -return hvm_set_cr0(val, 1);
> +rc = hvm_set_cr0(val, 1);
> +break;
> +
>  case 2:
>  current->arch.hvm_vcpu.guest_cr[2] = val;
> -return X86EMUL_OKAY;
> +rc = X86EMUL_OKAY;
> +break;
> +
>  case 3:
> -return hvm_set_cr3(val, 1);
> +rc = hvm_set_cr3(val, 1);
> +break;
> +
>  case 4:
> -return hvm_set_cr4(val, 1);
> +rc = hvm_set_cr4(val, 1);
> +break;
> +
>  default:
> +rc = X86EMUL_UNHANDLEABLE;
>  break;
>  }
> 
> -return X86EMUL_UNHANDLEABLE;
> +if ( rc == X86EMUL_EXCEPTION )
> +x86_emul_hw_exception(TRAP_gp_fault, 0, ctxt);
> +
> +return rc;
>  }
> 
>  static int hvmemul_read_msr(
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 7432c70..ccfae4f 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -527,19 +527,25 @@ void hvm_do_resume(struct vcpu *v)
> 
>  if ( w->do_write.cr0 )
>  {
> -hvm_set_cr0(w->cr0, 0);
> +if ( hvm_set_cr0(w->cr0, 0) == X86EMUL_EXCEPTION )
> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
> +
>  w->do_write.cr0 = 0;
>  }
> 
>  if ( w->do_write.cr4 )
>  {
> -hvm_set_cr4(w->cr4, 0);
> +if ( hvm_set_cr4(w->cr4, 0) == X86EMUL_EXCEPTION )
> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
> +
>  w->do_write.cr4 = 0;
>  }
> 
>  if ( w->do_write.cr3 )
>  {
> -hvm_set_cr3(w->cr3, 0);
> +if ( hvm_set_cr3(w->cr3, 0) == X86EMUL_EXCEPTION )
> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
> +
>  w->do_write.cr3 = 0;
>  }
>  }
> @@ -2068,6 +2074,7 @@ int hvm_mov_to_cr(unsigned int cr, unsigned int
> gpr)
>  {
>  struct vcpu *curr = current;
>  unsigned long val, *reg;
> +int rc;
> 
>  if ( (reg = decode_register(gpr, guest_cpu_user_regs(), 0)) == NULL )
>  {
> @@ -2082,16 +2089,20 @@ int hvm_mov_to_cr(unsigned int cr, unsigned int
> gpr)
>  switch ( cr )

Re: [Xen-devel] [PATCH] x86/microcode: Replace sync_core() with cpuid_eax()

[Jan Beulich]

>>> On 02.03.17 at 16:39,  wrote:
> From: Andy Lutomirski 
> 
> The Intel microcode driver is using sync_core() to mean "do CPUID
> with EAX=1".
> 
> Signed-off-by: Andy Lutomirski 
> Acked-by: Borislav Petkov 
> [Linux commit 484d0e5c7943644cc46e7308a8f9d83be598f2b9]
> [Ported to Xen]
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



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

[Xen-devel] [PATCH] x86/microcode: Replace sync_core() with cpuid_eax()

[Andrew Cooper]

From: Andy Lutomirski 

The Intel microcode driver is using sync_core() to mean "do CPUID
with EAX=1".

Signed-off-by: Andy Lutomirski 
Acked-by: Borislav Petkov 
[Linux commit 484d0e5c7943644cc46e7308a8f9d83be598f2b9]
[Ported to Xen]
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/microcode_intel.c | 9 +
 xen/arch/x86/traps.c   | 3 ++-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index 62c2932..ba3971a 100644
--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -115,8 +115,9 @@ static int collect_cpu_info(unsigned int cpu_num, struct 
cpu_signature *csig)
 }
 
 wrmsrl(MSR_IA32_UCODE_REV, 0x0ULL);
-/* see notes above for revision 1.07.  Apparent chip bug */
-sync_core();
+/* As documented in the SDM: Do a CPUID 1 here */
+cpuid_eax(1);
+
 /* get the current revision from MSR 0x8B */
 rdmsrl(MSR_IA32_UCODE_REV, msr_content);
 csig->rev = (uint32_t)(msr_content >> 32);
@@ -297,8 +298,8 @@ static int apply_microcode(unsigned int cpu)
 wrmsrl(MSR_IA32_UCODE_WRITE, (unsigned long)uci->mc.mc_intel->bits);
 wrmsrl(MSR_IA32_UCODE_REV, 0x0ULL);
 
-/* see notes above for revision 1.07.  Apparent chip bug */
-sync_core();
+/* As documented in the SDM: Do a CPUID 1 here */
+cpuid_eax(1);
 
 /* get the current revision from MSR 0x8B */
 rdmsrl(MSR_IA32_UCODE_REV, msr_content);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 8ba7ed0..13a609b 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2572,7 +2572,8 @@ static int priv_op_read_msr(unsigned int reg, uint64_t 
*val,
 {
 if ( wrmsr_safe(MSR_IA32_UCODE_REV, 0) )
 break;
-sync_core();
+/* As documented in the SDM: Do a CPUID 1 here */
+cpuid_eax(1);
 }
 goto normal;
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] xen/common: low performance of lib/sort.c

[Jan Beulich]

>>> On 02.03.17 at 16:27,  wrote:
> From: keios 
> 
> It is a non-standard heap-sort algorithm implementation because the index
> of child node is wrong .  The sort function still outputs right result, but
> the performance is O( n * ( log(n) + 1 ) ) , about 10% ~ 20% worse than
> standard algorithm.
> 
> Signed-off-by: keios 
> [Linux commit: d3717bdf8f08a0e1039158c8bab2c24d20f492b6]
> 
> Ported to Xen.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH] x86/SVM: correct boot time cpu_data[] handling

[Andrew Cooper]

On 02/03/17 15:33, Jan Beulich wrote:
 On 02.03.17 at 16:06,  wrote:
>> On 02/03/17 13:08, Jan Beulich wrote:
>>> start_svm() already runs after cpu_data[] was set up, so it shouldn't
>>> modify it anymore (at least not directly). Constify the involved
>>> pointers.
>>>
>>> Furthermore LMSLE feature detection was broken by 566ddbe833 ("x86:
>>> Fail CPU bringup cleanly if it cannot initialise HVM"), as Andrew
>>> Cooper has pointed out: c couldn't possibly equal _cpu_data
>>> anymore.
>>>
>>> Signed-off-by: Jan Beulich 
>> I was hoping to avoid fixing LMSLE this until I had enough CPUID
>> infrastructure in place to make it migration safe.
>>
>> OTOH, I can't really object to the patch either.
>>
>> Would you mind if we #if 0'd the LMSLE bit for now, to avoid introducing
>> a window where it definitely isn't migration safe?
> I can do this, albeit a little reluctantly. I'd prefer "if ( 0 && ...)"
> though, to keep the code getting seen by the parser.

Fine by me.  (Along with a TODO, which I will eventually get around to
taking back out).

~Andrew

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