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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
REGR. vs. 120037
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
120037

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 120001
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 120037
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 120037
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120037
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120037
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 120037
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 120037
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120037
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120037
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120037
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  85688075ccc22c12bd0fca2a2c269199938e104c
baseline version:
 xen  a823a5280f25ad19a751dd9a41044f556471e61a

Last test of basis   120037  2018-02-26 13:16:29 Z4 days
Failing since120076  2018-02-27 20:33:32 Z3 days2 attempts
Testing same since   120120  2018-03-01 10:51:06 Z1 days

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  7a32bedffc5521aabed63a2991db6a805403f76d
baseline version:
 libvirt  1297db741434b9e6f8096c5a5481594cfdedf12a

Last test of basis   120084  2018-02-28 04:21:32 Z3 days
Testing same since   120122  2018-03-01 11:40:29 Z1 days1 attempts


People who touched revisions under test:
  Daniel P. Berrangé 
  Julio Faracco 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  ZhangZijian 

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



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

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

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  7bf61602f295676c8b0ff61e4c584fc2bd57e4cf
baseline version:
 xen  448c03b3cbe14873ee637755a29ea26ee7ca9ef9

Last test of basis   120169  2018-03-02 20:14:46 Z0 days
Testing same since   120177  2018-03-03 00:03:39 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 
  Stewart Hildebrand 

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

To xenbits.xen.org:/home/xen/git/xen.git
   448c03b3cb..7bf61602f2  7bf61602f295676c8b0ff61e4c584fc2bd57e4cf -> smoke

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

Re: [Xen-devel] Setting up a Xen x86 community call

[Tamas K Lengyel]

On Fri, Mar 2, 2018 at 8:39 AM, Lars Kurth  wrote:
> Hi all,
> (sorry for the extensive distribution list - I went through MAINTAINERS and 
> people who may have an interest)
>
> I would like to start organizing a recurring x86 community call to discuss 
> and sync-up on upcoming features for Xen on x86. This call would mirror and 
> follow a similar structure to the ARM call (see 
> http://xen.markmail.org/thread/xqdxvqcjpf2y5ftu for the last one)
>
> I expect that the call will contain
>
> a) Coordination and Planning
> Coordinating who does what, what needs attention, what is blocked, etc.
> I would prepare a list of non-merged patch series of a certain size (e.g. 
> more than 5 patches) and attach to the invite
> If anything is missed, I would expect that these are sent to me before the 
> meeting
>
> b) Design and architecture related discussions: in particular for bigger, 
> more complex items, ...
> Although all of this could be done by email, in reality, we are all human and 
> many people find it easier to collaborate
> and communicate by talking to each other, rather than by email. This is not a 
> must, but an option to highlight issues
>
> c) Demos, Sharing of Experiences, Sometimes discussion of specific 
> issues/bugs/problems/...
> This is something which happens frequently on the ARM call and seems to work 
> very well
>
> I would suggest to start with a 1 hour monthly meeting: possibly every 2nd 
> Tue or Thu each month (depends on timing). I know that people are spread 
> across different timezones (from China to the US), so I would like to gather 
> thoughts before choosing a time. We may have to have alternating time-slots 
> every other month: but this is not ideal for some.
>
> To do this, please
> * Raise your hands on whether you or your org would want to participate

\o/

> * Provide your timezone

MST

> * Provide a UTC time range when you can attend

15:00-23:00

Tamas

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

[Xen-devel] [xen-4.8-testing test] 120116: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 17 guest-start.2   fail blocked in 119771
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119771
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119771
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119771
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119771
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 119771
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 119771
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 119771
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 119771
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  03f947472fde01f438ec057439d8d30456210a1c
baseline version:
 xen  

Re: [Xen-devel] [PATCH] xen/arm: p2m: Prevent deadlock when using memaccess

[Stefano Stabellini]

On Wed, 28 Feb 2018, Julien Grall wrote:
> Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt"
> assumed the read-write lock can be taken recursively. However, this
> assumption is wrong and will lead to deadlock when the lock is
> contended.
> 
> To avoid the nested lock, rework the locking in get_page_from_gva and
> p2m_mem_access_check_and_get_page. The latter will now be called without
> the p2m lock. The new locking in p2m_mem_accces_check_and_get_page will
> not cover the translation of the VA to an IPA.
> 
> This is fine because we can't promise that the stage-1 page-table have
> changed behind our back (they are under guest control). Modification in
> the stage-2 page-table can now happen, but I can't issue any potential
> issue here except with the break-before-make sequence used when updating
> page-table. gva_to_ipa may fail if the sequence is executed at the same
> on another CPU. In that case we would fallback in the software lookup
> path.
> 
> Signed-off-by: Julien Grall 


Hi Julien,

At first glance the patch looks OK, but could you please add more
information on the recursive lock sequence that this patch is trying to
solve? Specifically, how Xen can get into a situation where it tries to
acquire the p2m lock twice recursively? I realize the comment at the
bottom says "access_guest_memory_by_ipa in guest_walk_(sd|ld)" but I
would appreciate more details. Thanks!


> ---
> This patch should be backported to Xen 4.10. There are other
> potential optimization that I am working on. Although, I don't think
> they are backport material.
> ---
>  xen/arch/arm/mem_access.c | 8 ++--
>  xen/arch/arm/p2m.c| 4 ++--
>  xen/include/asm-arm/p2m.h | 4 
>  3 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
> index 0f2cbb81d3..11c2b03b7b 100644
> --- a/xen/arch/arm/mem_access.c
> +++ b/xen/arch/arm/mem_access.c
> @@ -126,7 +126,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag,
>   * is not mapped.
>   */
>  if ( guest_walk_tables(v, gva, , ) < 0 )
> -goto err;
> +return NULL;
>  
>  /*
>   * Check permissions that are assumed by the caller. For instance in
> @@ -139,11 +139,13 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag,
>   * test for execute permissions this check can be left out.
>   */
>  if ( (flag & GV2M_WRITE) && !(perms & GV2M_WRITE) )
> -goto err;
> +return NULL;
>  }
>  
>  gfn = gaddr_to_gfn(ipa);
>  
> +p2m_read_lock(p2m);
> +
>  /*
>   * We do this first as this is faster in the default case when no
>   * permission is set on the page.
> @@ -216,6 +218,8 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag,
>  page = NULL;
>  
>  err:
> +p2m_read_unlock(p2m);
> +
>  return page;
>  }
>  
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 65e8b9c6ea..5de82aafe1 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1449,11 +1449,11 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
> vaddr_t va,
>  }
>  
>  err:
> +p2m_read_unlock(p2m);
> +
>  if ( !page && p2m->mem_access_enabled )
>  page = p2m_mem_access_check_and_get_page(va, flags, v);
>  
> -p2m_read_unlock(p2m);
> -
>  return page;
>  }
>  
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index a0abc84ed8..45ef2cd58b 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -23,10 +23,6 @@ extern void memory_type_changed(struct domain *);
>  struct p2m_domain {
>  /*
>   * Lock that protects updates to the p2m.
> - *
> - * Please note that we use this lock in a nested way by calling
> - * access_guest_memory_by_ipa in guest_walk_(sd|ld). This must be
> - * considered in the future implementation.
>   */
>  rwlock_t lock;
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 3/3] xen/arm: domain_builder: irq sanity check logic fix

[Stefano Stabellini]

On Tue, 27 Feb 2018, julien.gr...@arm.com wrote:
> From: Stewart Hildebrand 
> 
> Since commit "xen/arm: domain_build: Rework the way to allocate the
> event channel interrupt", it is not possible for an irq to be both below 16
> and greater/equal than 32.
> 
> Also fix the reference to linux documentation while we're at it.
> 
> Signed-off-by: Stewart Hildebrand 
> Signed-off-by: Julien Grall 
> [Slightly rework the commit message]

Acked-by: Stefano Stabellini 


> ---
>  xen/arch/arm/domain_build.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index ed1a393bb5..28ee876b92 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -503,9 +503,10 @@ static void set_interrupt_ppi(gic_interrupt_t interrupt, 
> unsigned int irq,
>  {
>  __be32 *cells = interrupt;
>  
> -BUG_ON(irq < 16 && irq >= 32);
> +BUG_ON(irq < 16);
> +BUG_ON(irq >= 32);
>  
> -/* See linux Documentation/devictree/bindings/arm/gic.txt */
> +/* See linux 
> Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
>  dt_set_cell(, 1, 1); /* is a PPI */
>  dt_set_cell(, 1, irq - 16); /* PPIs start at 16 */
>  dt_set_cell(, 1, (cpumask << 8) | level);
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 2/3] xen/arm: domain_build: Rework the way to allocate the event channel interrupt

[Stefano Stabellini]

On Tue, 27 Feb 2018, julien.gr...@arm.com wrote:
> From: Julien Grall 
> 
> At the moment, a placeholder will be created in the device-tree for the
> event channel information. Later in the domain construction, the
> interrupt for the event channel upcall will be allocated the device-tree
> fixed up.
> 
> Looking at the code, the current split is not necessary because all the
> PPIs used by the hardware domain will by the time we create the node in
> the device-tree.
> 
> >From now, mandate that all interrupts are registered before
> acpi_prepare() and dtb_prepare(). This allows us to rework the event
> channel code and remove one placeholder.
> 
> Note, this will also help to fix the BUG(...) condition in set_interrupt_ppi
> which is completely wrong. See in a follow-up patch.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/domain_build.c | 74 
> +
>  1 file changed, 35 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index a5e5c82355..ed1a393bb5 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -576,7 +576,10 @@ static int make_memory_node(const struct domain *d,
>  return res;
>  }
>  
> -static int make_hypervisor_node(const struct kernel_info *kinfo,
> +static void evtchn_allocate(struct domain *d);
> +
> +static int make_hypervisor_node(struct domain *d,
> +const struct kernel_info *kinfo,
>  const struct dt_device_node *parent)
>  {
>  const char compat[] =
> @@ -620,10 +623,18 @@ static int make_hypervisor_node(const struct 
> kernel_info *kinfo,
>  return res;
>  
>  /*
> - * Placeholder for the event channel interrupt.  The values will be
> - * replaced later.
> + * It is safe to allocate the event channel here because all the
> + * PPIs used by the hardware domain have been registered.
> + */
> +evtchn_allocate(d);
> +
> +/*
> + * Interrupt event channel upcall:
> + *  - Active-low level-sensitive
> + *  - All CPUs
> + *  TODO: Handle properly the cpumask;
>   */
> -set_interrupt_ppi(intr, ~0, 0xf, IRQ_TYPE_INVALID);
> +set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf, IRQ_TYPE_LEVEL_LOW);
>  res = fdt_property_interrupts(fdt, , 1);
>  if ( res )
>  return res;
> @@ -1282,7 +1293,11 @@ static int handle_node(struct domain *d, struct 
> kernel_info *kinfo,
>  
>  if ( node == dt_host )
>  {
> -res = make_hypervisor_node(kinfo, node);
> +/*
> + * The hypervisor node should always be created after all nodes
> + * from the host DT have been parsed.
> + */
> +res = make_hypervisor_node(d, kinfo, node);
>  if ( res )
>  return res;
>  
> @@ -1939,6 +1954,12 @@ static int prepare_acpi(struct domain *d, struct 
> kernel_info *kinfo)
>  if ( rc != 0 )
>  return rc;
>  
> +/*
> + * All PPIs have been registered, allocate the event channel
> + * interrupts.
> + */
> +evtchn_allocate(d);
> +
>  return 0;
>  }
>  #else
> @@ -2014,16 +2035,18 @@ static void initrd_load(struct kernel_info *kinfo)
>  panic("Unable to copy the initrd in the hwdom memory");
>  }
>  
> -static void evtchn_fixup(struct domain *d, struct kernel_info *kinfo)
> +/*
> + * Allocate the event channel PPIs and setup the HVM_PARAM_CALLBACK_IRQ.
> + * The allocated IRQ will be found in d->arch.evtchn_irq.
> + *
> + * Note that this should only be called once all PPIs used by the
> + * hardware domain have been registered.
> + */
> +static void evtchn_allocate(struct domain *d)
>  {
> -int res, node;
> +int res;
>  u64 val;
> -gic_interrupt_t intr;
>  
> -/*
> - * The allocation of the event channel IRQ has been deferred until
> - * now. At this time, all PPIs used by DOM0 have been registered.
> - */
>  res = vgic_allocate_ppi(d);
>  if ( res < 0 )
>  panic("Unable to allocate a PPI for the event channel interrupt\n");
> @@ -2041,31 +2064,6 @@ static void evtchn_fixup(struct domain *d, struct 
> kernel_info *kinfo)
>   HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_MASK);
>  val |= d->arch.evtchn_irq;
>  d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ] = val;
> -
> -/*
> - * When booting Dom0 using ACPI, Dom0 can only get the event channel
> - * interrupt via hypercall.
> - */
> -if ( !acpi_disabled )
> -return;
> -
> -/* Fix up "interrupts" in /hypervisor node */
> -node = fdt_path_offset(kinfo->fdt, "/hypervisor");
> -if ( node < 0 )
> -panic("Cannot find the /hypervisor node");
> -
> -/* Interrupt event channel upcall:
> - *  - Active-low level-sensitive
> - *  - All CPUs
> - *
> - *  TODO: 

Re: [Xen-devel] [PATCH 1/3] xen/arm: domain_build: Prepare DTB/ACPI tables after specific mappings

[Stefano Stabellini]

On Tue, 27 Feb 2018, julien.gr...@arm.com wrote:
> From: Julien Grall 
> 
> A follow-up patch will require to have all interrupts routed to the
> hardware registered before calling prepare_dtb/prepare_acpi.
> 
> At the moment, it is not necessary to call platform specific mappings
> (gic and platform) after, so it is fine to move them.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/domain_build.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 941688a2ce..a5e5c82355 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2145,14 +2145,6 @@ int construct_dom0(struct domain *d)
>  allocate_memory(d, );
>  find_gnttab_region(d, );
>  
> -if ( acpi_disabled )
> -rc = prepare_dtb(d, );
> -else
> -rc = prepare_acpi(d, );
> -
> -if ( rc < 0 )
> -return rc;
> -
>  /* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
>  rc = gic_map_hwdom_extra_mappings(d);
>  if ( rc < 0 )
> @@ -2162,6 +2154,14 @@ int construct_dom0(struct domain *d)
>  if ( rc < 0 )
>  return rc;
>  
> +if ( acpi_disabled )
> +rc = prepare_dtb(d, );
> +else
> +rc = prepare_acpi(d, );
> +
> +if ( rc < 0 )
> +return rc;
> +
>  /*
>   * The following loads use the domain's p2m and require current to
>   * be a vcpu of the domain, temporarily switch
> -- 
> 2.11.0
> 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  448c03b3cbe14873ee637755a29ea26ee7ca9ef9
baseline version:
 xen  43c54ac6053bd0ab397d7b77519e875b01a9a105

Last test of basis   120164  2018-03-02 17:01:43 Z0 days
Testing same since   120169  2018-03-02 20:14:46 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Juergen Gross 
  Wei Liu 

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

To xenbits.xen.org:/home/xen/git/xen.git
   43c54ac605..448c03b3cb  448c03b3cbe14873ee637755a29ea26ee7ca9ef9 -> smoke

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

Re: [Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

On 3/2/2018 1:20 PM, Konrad Rzeszutek Wilk wrote:

On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote:

The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.

Would it be better if there was an tag/length as well? And maybe more dynamic
so that if you want to add more structures you can identify them tags?
Like what Multiboot2 has?


That sounds like a decent idea if we expect this structure to continue 
to grow and expand in the future. But I'd be hesitant to make it part of 
this patch series. Mostly because it doesn't add value to the existing 
use case(s) and there's a risk we end up going down a less than ideal 
path trying to design for anticipated (but presently unknown) use cases.


I don't think the currently proposed changes would prevent us from doing 
something like you describe in the future, so I guess I'd prefer to 
leave that discussion for if/when we run into additional use cases that 
require new structures. But if there is overwhelming support for the 
idea, I can work on drafting up a proposal for what that would look like.


Thanks,
-Maran


Signed-off-by: Maran Wilson 
---
  xen/include/public/arch-x86/hvm/start_info.h | 51 +++-
  1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/arch-x86/hvm/start_info.h 
b/xen/include/public/arch-x86/hvm/start_info.h
index 6484159..ae8dac8 100644
--- a/xen/include/public/arch-x86/hvm/start_info.h
+++ b/xen/include/public/arch-x86/hvm/start_info.h
@@ -33,8 +33,9 @@
   *| magic  | Contains the magic value XEN_HVM_START_MAGIC_VALUE
   *|| ("xEn3" with the 0x80 bit of the "E" set).
   *  4 ++
- *| version| Version of this structure. Current version is 0. New
+ *| version| Version of this structure. Current version is 1. New
   *|| versions are guaranteed to be backwards-compatible.
+ *|| For PV guests only 0 allowed, for PVH 0 or 1 allowed.
   *  8 ++
   *| flags  | SIF_xxx flags.
   * 12 ++
@@ -48,6 +49,15 @@
   * 32 ++
   *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
   * 40 ++
+ *| memmap_paddr   | Physical address of the (optional) memory map. Only
+ *|| present in version 1 and newer of the structure.
+ * 48 ++
+ *| memmap_entries | Number of entries in the memory map table. Only
+ *|| present in version 1 and newer of the structure.
+ *|| Zero if there is no memory map being provided.
+ * 52 ++
+ *| reserved   | Version 1 and newer only.
+ * 56 ++
   *
   * The layout of each entry in the module structure is the following:
   *
@@ -62,10 +72,34 @@
   *| reserved   |
   * 32 ++
   *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 ++
+ *| addr   | Base address
+ *  8 ++
+ *| size   | Size of mapping in bytes
+ * 16 ++
+ *| type   | Type of mapping as defined between the hypervisor
+ *|| and guest it's starting. E820_TYPE_xxx, for example.
+ * 20 +|
+ *| reserved   |
+ * 24 ++
+ *
   * The address and sizes are always a 64bit little endian unsigned integer.
   *
   * NB: Xen on x86 will always try to place all the data below the 4GiB
   * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0:
+ *
+ * Version 1:  Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ * padding) to the end of the hvm_start_info struct. These new
+ * fields can be used to pass a memory map to the guest. The
+ * memory map is optional and so guests that understand version 1
+ * of the structure must check that memmap_entries is non-zero
+ * before trying to read the memory map.
   */
  #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
  
@@ -86,6 +120,14 @@ struct hvm_start_info {

  uint64_t cmdline_paddr; /* Physical address of the command line. 
*/
  uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data
*/
  /* structure.
*/
+uint64_t memmap_paddr; /* Physical address of an array of   */
+   /* hvm_memmap_table_entry. Only present in   */
+   /* version 1 and newer of the structure  */
+uint32_t memmap_entries;   /* Number of entries 

Re: [Xen-devel] Setting up a Xen x86 community call

[Brian Woods]

On Fri, Mar 02, 2018 at 04:39:59PM +0100, Lars Kurth wrote:
> Hi all, 
> (sorry for the extensive distribution list - I went through MAINTAINERS and 
> people who may have an interest)
> 
> I would like to start organizing a recurring x86 community call to discuss 
> and sync-up on upcoming features for Xen on x86. This call would mirror and 
> follow a similar structure to the ARM call (see 
> http://xen.markmail.org/thread/xqdxvqcjpf2y5ftu for the last one)
> 
> I expect that the call will contain
> 
> a) Coordination and Planning 
> Coordinating who does what, what needs attention, what is blocked, etc. 
> I would prepare a list of non-merged patch series of a certain size (e.g. 
> more than 5 patches) and attach to the invite
> If anything is missed, I would expect that these are sent to me before the 
> meeting
> 
> b) Design and architecture related discussions: in particular for bigger, 
> more complex items, ... 
> Although all of this could be done by email, in reality, we are all human and 
> many people find it easier to collaborate
> and communicate by talking to each other, rather than by email. This is not a 
> must, but an option to highlight issues
> 
> c) Demos, Sharing of Experiences, Sometimes discussion of specific 
> issues/bugs/problems/...
> This is something which happens frequently on the ARM call and seems to work 
> very well
> 
> I would suggest to start with a 1 hour monthly meeting: possibly every 2nd 
> Tue or Thu each month (depends on timing). I know that people are spread 
> across different timezones (from China to the US), so I would like to gather 
> thoughts before choosing a time. We may have to have alternating time-slots 
> every other month: but this is not ideal for some.
> 
> To do this, please
> * Raise your hands on whether you or your org would want to participate

\o/

> * Provide your timezone

CT

> * Provide a UTC time range when you can attend 

15:00-23:00

> Your sincerely,
> Lars
> 
> 

-- 
Brian Woods

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

Re: [Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

[Konrad Rzeszutek Wilk]

On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> would allow KVM guests to share the same entry point.

Would it be better if there was an tag/length as well? And maybe more dynamic
so that if you want to add more structures you can identify them tags?
Like what Multiboot2 has?

> 
> Signed-off-by: Maran Wilson 
> ---
>  xen/include/public/arch-x86/hvm/start_info.h | 51 
> +++-
>  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/include/public/arch-x86/hvm/start_info.h 
> b/xen/include/public/arch-x86/hvm/start_info.h
> index 6484159..ae8dac8 100644
> --- a/xen/include/public/arch-x86/hvm/start_info.h
> +++ b/xen/include/public/arch-x86/hvm/start_info.h
> @@ -33,8 +33,9 @@
>   *| magic  | Contains the magic value XEN_HVM_START_MAGIC_VALUE
>   *|| ("xEn3" with the 0x80 bit of the "E" set).
>   *  4 ++
> - *| version| Version of this structure. Current version is 0. New
> + *| version| Version of this structure. Current version is 1. New
>   *|| versions are guaranteed to be backwards-compatible.
> + *|| For PV guests only 0 allowed, for PVH 0 or 1 
> allowed.
>   *  8 ++
>   *| flags  | SIF_xxx flags.
>   * 12 ++
> @@ -48,6 +49,15 @@
>   * 32 ++
>   *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
>   * 40 ++
> + *| memmap_paddr   | Physical address of the (optional) memory map. Only
> + *|| present in version 1 and newer of the structure.
> + * 48 ++
> + *| memmap_entries | Number of entries in the memory map table. Only
> + *|| present in version 1 and newer of the structure.
> + *|| Zero if there is no memory map being provided.
> + * 52 ++
> + *| reserved   | Version 1 and newer only.
> + * 56 ++
>   *
>   * The layout of each entry in the module structure is the following:
>   *
> @@ -62,10 +72,34 @@
>   *| reserved   |
>   * 32 ++
>   *
> + * The layout of each entry in the memory map table is as follows:
> + *
> + *  0 ++
> + *| addr   | Base address
> + *  8 ++
> + *| size   | Size of mapping in bytes
> + * 16 ++
> + *| type   | Type of mapping as defined between the hypervisor
> + *|| and guest it's starting. E820_TYPE_xxx, for example.
> + * 20 +|
> + *| reserved   |
> + * 24 ++
> + *
>   * The address and sizes are always a 64bit little endian unsigned integer.
>   *
>   * NB: Xen on x86 will always try to place all the data below the 4GiB
>   * boundary.
> + *
> + * Version numbers of the hvm_start_info structure have evolved like this:
> + *
> + * Version 0:
> + *
> + * Version 1:Added the memmap_paddr/memmap_entries fields (plus 4 
> bytes of
> + *   padding) to the end of the hvm_start_info struct. These new
> + *   fields can be used to pass a memory map to the guest. The
> + *   memory map is optional and so guests that understand version 1
> + *   of the structure must check that memmap_entries is non-zero
> + *   before trying to read the memory map.
>   */
>  #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
>  
> @@ -86,6 +120,14 @@ struct hvm_start_info {
>  uint64_t cmdline_paddr; /* Physical address of the command line. 
> */
>  uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data
> */
>  /* structure.
> */
> +uint64_t memmap_paddr;   /* Physical address of an array of   */
> + /* hvm_memmap_table_entry. Only present in   */
> + /* version 1 and newer of the structure  */
> +uint32_t memmap_entries; /* Number of entries in the memmap table.*/
> + /* Only present in version 1 and newer of*/
> + /* the structure. Value will be zero if  */
> + /* there is no memory map being provided.*/
> +uint32_t reserved;
>  };
>  
>  struct hvm_modlist_entry {
> @@ -95,4 +137,11 @@ struct hvm_modlist_entry {
>  uint64_t reserved;
>  };
>  
> +struct hvm_memmap_table_entry {
> +uint64_t addr;   /* Base address of the memory region */
> +uint64_t size;   /* Size of the memory region in bytes*/
> +uint32_t type;   /* 

[Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.

Signed-off-by: Maran Wilson 
---
 xen/include/public/arch-x86/hvm/start_info.h | 51 +++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/arch-x86/hvm/start_info.h 
b/xen/include/public/arch-x86/hvm/start_info.h
index 6484159..ae8dac8 100644
--- a/xen/include/public/arch-x86/hvm/start_info.h
+++ b/xen/include/public/arch-x86/hvm/start_info.h
@@ -33,8 +33,9 @@
  *| magic  | Contains the magic value XEN_HVM_START_MAGIC_VALUE
  *|| ("xEn3" with the 0x80 bit of the "E" set).
  *  4 ++
- *| version| Version of this structure. Current version is 0. New
+ *| version| Version of this structure. Current version is 1. New
  *|| versions are guaranteed to be backwards-compatible.
+ *|| For PV guests only 0 allowed, for PVH 0 or 1 allowed.
  *  8 ++
  *| flags  | SIF_xxx flags.
  * 12 ++
@@ -48,6 +49,15 @@
  * 32 ++
  *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
  * 40 ++
+ *| memmap_paddr   | Physical address of the (optional) memory map. Only
+ *|| present in version 1 and newer of the structure.
+ * 48 ++
+ *| memmap_entries | Number of entries in the memory map table. Only
+ *|| present in version 1 and newer of the structure.
+ *|| Zero if there is no memory map being provided.
+ * 52 ++
+ *| reserved   | Version 1 and newer only.
+ * 56 ++
  *
  * The layout of each entry in the module structure is the following:
  *
@@ -62,10 +72,34 @@
  *| reserved   |
  * 32 ++
  *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 ++
+ *| addr   | Base address
+ *  8 ++
+ *| size   | Size of mapping in bytes
+ * 16 ++
+ *| type   | Type of mapping as defined between the hypervisor
+ *|| and guest it's starting. E820_TYPE_xxx, for example.
+ * 20 +|
+ *| reserved   |
+ * 24 ++
+ *
  * The address and sizes are always a 64bit little endian unsigned integer.
  *
  * NB: Xen on x86 will always try to place all the data below the 4GiB
  * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0:
+ *
+ * Version 1:  Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ * padding) to the end of the hvm_start_info struct. These new
+ * fields can be used to pass a memory map to the guest. The
+ * memory map is optional and so guests that understand version 1
+ * of the structure must check that memmap_entries is non-zero
+ * before trying to read the memory map.
  */
 #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
 
@@ -86,6 +120,14 @@ struct hvm_start_info {
 uint64_t cmdline_paddr; /* Physical address of the command line. */
 uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
 /* structure.*/
+uint64_t memmap_paddr; /* Physical address of an array of   */
+   /* hvm_memmap_table_entry. Only present in   */
+   /* version 1 and newer of the structure  */
+uint32_t memmap_entries;   /* Number of entries in the memmap table.*/
+   /* Only present in version 1 and newer of*/
+   /* the structure. Value will be zero if  */
+   /* there is no memory map being provided.*/
+uint32_t reserved;
 };
 
 struct hvm_modlist_entry {
@@ -95,4 +137,11 @@ struct hvm_modlist_entry {
 uint64_t reserved;
 };
 
+struct hvm_memmap_table_entry {
+uint64_t addr; /* Base address of the memory region */
+uint64_t size; /* Size of the memory region in bytes*/
+uint32_t type; /* Mapping type  */
+uint32_t reserved;
+};
+
 #endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
-- 
1.8.3.1


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

[Xen-devel] [PATCH 0/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

Here is the patch for updating the canonical definition of the
hvm_start_info struct corresponding to the discussion happening on the
linux-kernel and kvm mailing lists regarding Qemu/KVM use of the PVH
entry point:

   KVM: x86: Allow Qemu/KVM to use PVH entry point
   https://lkml.org/lkml/2018/2/28/1121

Maran Wilson (1):
  x86/PVHv2: Add memory map pointer to hvm_start_info struct

 xen/include/public/arch-x86/hvm/start_info.h | 51 +-
 1 file changed, 50 insertions(+), 1 deletion(-)

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

[Xen-devel] [xen-4.10-testing test] 120111: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub broken
 test-amd64-amd64-xl-qemut-ws16-amd64 broken
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 120065 
REGR. vs. 119859

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-amd64-pvgrub  4 host-install(4) broken pass in 120065
 test-amd64-amd64-xl-qemut-ws16-amd64  4 host-install(4)  broken pass in 120065
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
in 120065 pass in 120111
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 120065 pass 
in 120111
 test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail pass in 
120065

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 

Re: [Xen-devel] [PATCH v2 7/7] x86/build: Use new .nop directive when available

[Andrew Cooper]

On 02/03/18 07:10, Jan Beulich wrote:
 On 01.03.18 at 17:58,  wrote:
>> On 01/03/18 10:54, Jan Beulich wrote:
>> On 01.03.18 at 11:36,  wrote:
 On Thu, Mar 01, 2018 at 12:28:27AM -0700, Jan Beulich wrote:
 Andrew Cooper  02/28/18 7:20 PM >>>
>> On 28/02/18 16:22, Jan Beulich wrote:
>> On 26.02.18 at 12:35,  wrote:
 --- a/xen/include/asm-x86/alternative-asm.h
 +++ b/xen/include/asm-x86/alternative-asm.h
 @@ -1,6 +1,8 @@
  #ifndef _ASM_X86_ALTERNATIVE_ASM_H_
  #define _ASM_X86_ALTERNATIVE_ASM_H_
  
 +#include 
 +
  #ifdef __ASSEMBLY__
  
  /*
 @@ -18,6 +20,14 @@
  .byte \pad_len
  .endm
  
 +.macro mknops nr_bytes
 +#ifdef HAVE_AS_NOP_DIRECTIVE
 +.nop \nr_bytes, ASM_NOP_MAX
>>> And do you really need to specify ASM_NOP_MAX here? What's
>>> wrong with letting the assembler pick what it wants as the longest
>>> NOP?
>> I don't want a toolchain change to cause us to go beyond 11 byte nops,
>> because of the associated decode stall on almost all hardware.  Using
>> ASM_NOP_MAX seemed like the easiest way to keep the end result
>> consistent, irrespective of toolchain support.
> I don't understand - an earlier patch takes care of runtime replacing them
> anyway. What stalls can then result?
 The runtime replacement won't happen when using the .nops directive
 AFAICT, because the original padding section will likely be filled
 with opcodes different than 0x90, and thus the runtime nop
 optimization won't be performed.
>>> Oh, indeed. That puts under question the whole idea of using
>>> .nops in favor of .skip. Andrew, I'm sorry, but with this I prefer
>>> to withdraw my ack.
>>>
 I also agree that using the default (not proving a second argument)
 seems like a better solution. Why would the toolstack switch to
 something that leads to worse performance? That would certainly be
 considered a bug.
>>> Why? They may change it based on data available for newer /
>>> older / whatever hardware. Any build-time choice is going to be
>>> suboptimal somewhere, so I think we absolutely should not
>>> bypass runtime replacing these NOPs, the more that now we
>>> may have quite large sequences of them.
>> The pont of having the toolchain put out optimised nops is to avoid the
>> need for us to patch the site at all.  I.e. calling optimise_nops() on a
>> set of toolchain nops defeats the purpose in the overwhelming common
>> case of running on a system which prefers P6 nops.
>>
>> The problem of working out when to optimise is that, when we come to
>> apply an individual alternative, we don't know if we've already patched
>> this site before.  Even the unoptimised algorithm has a corner case
>> which explodes, if there is a stream of 0x90's on the end of a
>> replacement e.g. in a imm or disp field.
>>
>> Put simply, we cannot determine, by peeking at the patchsite, whether it
>> has been patched or not (other than keeping a full copy of the origin
>> site as a reference).  As soon as we chose to optimise the nops of the
>> origin site, we cannot determine anything at all.
>>
>> Thinking out loud, we could perhaps have a section containing one byte
>> per origin site, which we use to track whether we've already optimised
>> the padding bytes, and whether the contents have been replaced.  This
>> would also add an extra long into struct altentry, but its all cold data
>> after boot.
> What about alternatively simply updating the struct alt_instr
> instances to describe the code _after_ a patch that was applied?
> That'll allow to always know how much padding there is.

There are multiple alt_instr pointing to the same origin sites when
using ALTERNATIVE_2, meaning you keep all the safety problems with the
current setup.

~Andrew

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

[Xen-devel] [PATCH v4 6/7] xen/arm: update the docs about heterogeneous computing

[Stefano Stabellini]

Introduce a new document about big.LITTLE and update the documentation
of hmp-unsafe.

Also update the warning messages to point users to the docs.

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com

---

Changes in v3:
- split warning messages to be under 72 chars

Changes in v2:
- add a separate doc for big.LITTLE
- improve the warning message
---
 docs/misc/arm/big.LITTLE.txt| 46 +
 docs/misc/xen-command-line.markdown |  7 +-
 xen/arch/arm/smpboot.c  | 11 +
 3 files changed, 59 insertions(+), 5 deletions(-)
 create mode 100644 docs/misc/arm/big.LITTLE.txt

diff --git a/docs/misc/arm/big.LITTLE.txt b/docs/misc/arm/big.LITTLE.txt
new file mode 100644
index 000..b6ea1c9
--- /dev/null
+++ b/docs/misc/arm/big.LITTLE.txt
@@ -0,0 +1,46 @@
+big.LITTLE is a form of heterogeneous computing that comes with two
+types of general purpose cpu cores: big cores, more powerful and with a
+higher power consumption rate, and LITTLE cores, less powerful and
+cheaper to run. For example, Cortex A53 and Cortex A57 cpus. Typically,
+big cores are only recommended for burst activity, especially in
+battery powered environments. Please note that Xen doesn't not use any
+board specific power management techniques at the moment, it only uses
+WFI. It is recommended to check the vendor's big.LITTLE and power
+management documentation before using it in a Xen environment.
+
+
+big and LITTLE cores are fully compatible in terms of instruction sets,
+but can differ in many subtle ways. For example, their cacheline sizes
+might differ. For this reason, vcpu migration between big and LITTLE
+cores can lead to data corruptions.
+
+Today, the Xen scheduler does not have support for big.LITTLE,
+therefore, it might unknowingly move any vcpus between big and LITTLE
+cores, potentially leading to breakages. To avoid this kind of issues,
+at boot time Xen disables all cpus that differ from the boot cpu.
+
+
+Expert users can enable all big.LITTLE cores by passing hmp-unsafe=true
+to the Xen command line [1]. Given the lack of big.LITTLE support in the
+scheduler, it is only safe if the cpu affinity of all domains is
+manually specified, so that the scheduler is not allowed to switch a
+vcpu from big to LITTLE or vice versa.
+
+In the case of dom0, dom0_vcpus_pin needs to be added to the Xen command
+line options [1]. For DomUs, the `cpus' option should be added to all VM
+config files [2].
+
+For example, if the first 4 cpus are big and the last 4 are LITTLE, the
+following options run all domain vcpus on either big or LITTLE cores
+(not both):
+
+  cpus = "0-3"
+  cpus = "4-7"
+
+The following option runs one domain vcpu as big and one as LITTLE:
+
+  cpus = ["0-3", "4-7"]
+
+
+[1] docs/misc/xen-command-line.markdown
+[2] docs/man/xl.cfg.pod.5
diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 7b80119..4391b75 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -992,7 +992,12 @@ Control Xens use of the APEI Hardware Error Source Table, 
should one be found.
 
 Say yes at your own risk if you want to enable heterogenous computing
 (such as big.LITTLE). This may result to an unstable and insecure
-platform. When the option is disabled (default), CPUs that are not
+platform, unless you manually specify the cpu affinity of all domains so
+that all vcpus are scheduled on the same class of pcpus (big or LITTLE
+but not both). vcpu migration between big cores and LITTLE cores is not
+supported. See docs/misc/arm/big.LITTLE.txt for more information.
+
+When the hmp-unsafe option is disabled (default), CPUs that are not
 identical to the boot CPU will be parked and not used by Xen.
 
 ### hpetbroadcast
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 122c0b5..04efb33 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -266,7 +266,8 @@ void __init smp_init_cpus(void)
 
 if ( opt_hmp_unsafe )
 warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
-"It has implications on the security and stability of the 
system.\n");
+"It has implications on the security and stability of the 
system,\n"
+"unless the cpu affinity of all domains is specified.\n");
 }
 
 int __init
@@ -308,13 +309,15 @@ void start_secondary(unsigned long boot_phys_offset,
 /*
  * Currently Xen assumes the platform has only one kind of CPUs.
  * This assumption does not hold on big.LITTLE platform and may
- * result to instability and insecure platform. Better to park them
- * for now.
+ * result to instability and insecure platform (unless cpu affinity
+ * is 

[Xen-devel] [PATCH v4 7/7] xen/arm: disable CPUs with different dcache line sizes

[Stefano Stabellini]

Even different cpus in big.LITTLE systems are expected to have the same
dcache line size. Unless the minimum of all dcache line sizes is used
across all cpu cores, cache coherency protocols can go wrong. Instead,
for now, just disable any cpu with a different dcache line size.

This check is not covered by the hmp-unsafe option, because even with
the correct scheduling and vcpu pinning in place, the system breaks if
dcache line sizes differ across cores. We don't believe it is a problem
for most big.LITTLE systems.

This patch moves the implementation of setup_cache to a static inline,
still setting dcache_line_bytes at the beginning of start_xen as
before.

In start_secondary we check that the dcache level 1 line sizes match,
otherwise we disable the cpu.

Suggested-by: Julien Grall 
Signed-off-by: Stefano Stabellini 

---
Changes in v4:
- improve commit message
- use %zu
---
 xen/arch/arm/setup.c   | 14 +-
 xen/arch/arm/smpboot.c |  8 
 xen/include/asm-arm/page.h | 11 +++
 3 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index fced75a..6ccfdab 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -682,18 +682,6 @@ static void __init setup_mm(unsigned long dtb_paddr, 
size_t dtb_size)
 
 size_t __read_mostly dcache_line_bytes;
 
-/* Very early check of the CPU cache properties */
-void __init setup_cache(void)
-{
-uint32_t ctr;
-
-/* Read CTR */
-ctr = READ_SYSREG32(CTR_EL0);
-
-/* Bits 16-19 are the log2 number of words in the cacheline. */
-dcache_line_bytes = (size_t) (4 << ((ctr >> 16) & 0xf));
-}
-
 /* C entry point for boot CPU */
 void __init start_xen(unsigned long boot_phys_offset,
   unsigned long fdt_paddr,
@@ -707,7 +695,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 struct domain *dom0;
 struct xen_arch_domainconfig config;
 
-setup_cache();
+dcache_line_bytes = read_dcache_line_size();
 
 percpu_init_areas();
 set_processor_id(0); /* needed early, for smp_processor_id() */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 04efb33..d15230b 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -323,6 +323,14 @@ void start_secondary(unsigned long boot_phys_offset,
 stop_cpu();
 }
 
+if ( dcache_line_bytes != read_dcache_line_size() )
+{
+printk(XENLOG_ERR "CPU%u dcache line size (%zu) does not match the 
boot CPU (%zu)\n",
+   smp_processor_id(), read_dcache_line_size(),
+   dcache_line_bytes);
+stop_cpu();
+}
+
 mmu_init_secondary_cpu();
 
 gic_init_secondary_cpu();
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index ce18f0c..e539f83 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -138,6 +138,17 @@ extern size_t dcache_line_bytes;
 
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+static inline size_t read_dcache_line_size(void)
+{
+uint32_t ctr;
+
+/* Read CTR */
+ctr = READ_SYSREG32(CTR_EL0);
+
+/* Bits 16-19 are the log2 number of words in the cacheline. */
+return (size_t) (4 << ((ctr >> 16) & 0xf));
+}
+
 /* Functions for flushing medium-sized areas.
  * if 'range' is large enough we might want to use model-specific
  * full-cache flushes. */
-- 
1.9.1


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

[Xen-devel] [PATCH v4 5/7] xen/arm: set VPIDR based on the MIDR value of the underlying pCPU

[Stefano Stabellini]

On big.LITTLE systems not all cores have the same MIDR. Instead of
storing only one VPIDR per domain, initialize it to the value of the
MIDR of the pCPU where the vCPU will run.

This way, assuming that the vCPU has been created with the right pCPU
affinity, the guest will be able to read the right VPIDR value, matching
the one of the physical cpu.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Julien Grall 

---

Changes in v3:
- improve commit message
- do not store vpidr in struct vcpu

Changes in v2:
- remove warning message
- make vpidr per vcpu
---
 xen/arch/arm/domain.c| 8 
 xen/arch/arm/vcpreg.c| 4 ++--
 xen/include/asm-arm/domain.h | 3 ---
 3 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5e76809..545bbf6 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -172,6 +172,8 @@ static void ctxt_switch_from(struct vcpu *p)
 
 static void ctxt_switch_to(struct vcpu *n)
 {
+uint32_t vpidr;
+
 /* When the idle VCPU is running, Xen will always stay in hypervisor
  * mode. Therefore we don't need to restore the context of an idle VCPU.
  */
@@ -180,7 +182,8 @@ static void ctxt_switch_to(struct vcpu *n)
 
 p2m_restore_state(n);
 
-WRITE_SYSREG32(n->domain->arch.vpidr, VPIDR_EL2);
+vpidr = READ_SYSREG32(MIDR_EL1);
+WRITE_SYSREG32(vpidr, VPIDR_EL2);
 WRITE_SYSREG(n->arch.vmpidr, VMPIDR_EL2);
 
 /* VGIC */
@@ -595,9 +598,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
 goto fail;
 
-/* Default the virtual ID to match the physical */
-d->arch.vpidr = boot_cpu_data.midr.bits;
-
 clear_page(d->shared_info);
 share_xen_page_with_guest(
 virt_to_page(d->shared_info), d, XENSHARE_writable);
diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
index e363183..b04d996 100644
--- a/xen/arch/arm/vcpreg.c
+++ b/xen/arch/arm/vcpreg.c
@@ -230,7 +230,6 @@ void do_cp14_32(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 const struct hsr_cp32 cp32 = hsr.cp32;
 int regidx = cp32.reg;
-struct domain *d = current->domain;
 
 if ( !check_conditional_instr(regs, hsr) )
 {
@@ -295,7 +294,8 @@ void do_cp14_32(struct cpu_user_regs *regs, const union hsr 
hsr)
  *  - Variant and Revision bits match MDIR
  */
 val = (1 << 24) | (5 << 16);
-val |= ((d->arch.vpidr >> 20) & 0xf) | (d->arch.vpidr & 0xf);
+val |= ((current_cpu_data.midr.bits >> 20) & 0xf) |
+(current_cpu_data.midr.bits & 0xf);
 set_user_reg(regs, regidx, val);
 
 break;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 4fe189b..0dd8c95 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -63,9 +63,6 @@ struct arch_domain
 RELMEM_done,
 } relmem;
 
-/* Virtual CPUID */
-uint32_t vpidr;
-
 struct {
 uint64_t offset;
 } phys_timer_base;
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v4 01/20] x86emul: extend vbroadcasts{s, d} to AVX2

[Andrew Cooper]

On 28/02/18 12:57, Jan Beulich wrote:
> These gain register forms now.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

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

[Xen-devel] [PATCH v4 2/7] xen/arm: Park CPUs with a MIDR different from the boot CPU.

[Stefano Stabellini]

From: Julien Grall 

From: Julien Grall 

Xen does not properly support big.LITTLE platform. All vCPUs of a guest
will always have the MIDR of the boot CPU (see arch_domain_create).
At best the guest may see unreliable performance (vCPU switching between
big and LITTLE), at worst the guest will become unreliable or insecure.

This is becoming more apparent with branch predictor hardening in Linux
because they target a specific kind of CPUs and may not work on other
CPUs.

For the time being, park any CPUs with a MDIR different from the boot
CPU. This will be revisited in the future once Xen gains understanding
of big.LITTLE.

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00826.html

Signed-off-by: Julien Grall 
Reviewed-by: Oleksandr Tyshchenkko 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
 docs/misc/xen-command-line.markdown | 10 ++
 xen/arch/arm/smpboot.c  | 26 ++
 2 files changed, 36 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index f73990f..7b80119 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -985,6 +985,16 @@ supported only when compiled with XSM on x86.
 
 Control Xens use of the APEI Hardware Error Source Table, should one be found.
 
+### hmp-unsafe (arm)
+> `= `
+
+> Default : `false`
+
+Say yes at your own risk if you want to enable heterogenous computing
+(such as big.LITTLE). This may result to an unstable and insecure
+platform. When the option is disabled (default), CPUs that are not
+identical to the boot CPU will be parked and not used by Xen.
+
 ### hpetbroadcast
 > `= `
 
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 1255185..7ea4e41 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -69,6 +70,13 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
 /* representing HT and core siblings of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
 
+/*
+ * By default non-boot CPUs not identical to the boot CPU will be
+ * parked.
+ */
+static bool __read_mostly opt_hmp_unsafe = false;
+boolean_param("hmp-unsafe", opt_hmp_unsafe);
+
 static void setup_cpu_sibling_map(int cpu)
 {
 if ( !zalloc_cpumask_var(_cpu(cpu_sibling_mask, cpu)) ||
@@ -255,6 +263,9 @@ void __init smp_init_cpus(void)
 else
 acpi_smp_init_cpus();
 
+if ( opt_hmp_unsafe )
+warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
+"It has implications on the security and stability of the 
system.\n");
 }
 
 int __init
@@ -292,6 +303,21 @@ void start_secondary(unsigned long boot_phys_offset,
 
 init_traps();
 
+/*
+ * Currently Xen assumes the platform has only one kind of CPUs.
+ * This assumption does not hold on big.LITTLE platform and may
+ * result to instability and insecure platform. Better to park them
+ * for now.
+ */
+if ( !opt_hmp_unsafe &&
+ current_cpu_data.midr.bits != boot_cpu_data.midr.bits )
+{
+printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR 
(0x%x).\n",
+   smp_processor_id(), current_cpu_data.midr.bits,
+   boot_cpu_data.midr.bits);
+stop_cpu();
+}
+
 mmu_init_secondary_cpu();
 
 gic_init_secondary_cpu();
-- 
1.9.1


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

[Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support

[Stefano Stabellini]

Hi all,

This series changes the initialization of two virtual registers to make
sure they match the value of the underlying physical cpu.

It also disables cpus different from the boot cpu, unless a newly
introduced command line option is specified. In that case, it explains
how to setup the system to avoid corruptions, which involves manually
specifying the cpu affinity of all domains, because the scheduler still
lacks big.LITTLE support.

In the uncommon case of a system where the cacheline sizes are different
across cores, it disables all cores that have a different dcache line size
from the boot cpu. In fact, it is not sufficient to use the dcache line
size of the current cpu, it would be necessary to use the minimum across
all dcache line sizes of all cores.  Given that it is actually uncommon
even in big.LITTLE systems, just disable cpus for now.

The first patch in the series is a fix for the way we read the dcache
line size.

Cheers,

Stefano


Julien Grall (1):
  xen/arm: Park CPUs with a MIDR different from the boot CPU.

Stefano Stabellini (6):
  xen/arm: Read the dcache line size from CTR register
  xen/arm: make processor a per cpu variable
  xen/arm: read ACTLR on the pcpu where the vcpu will run
  xen/arm: set VPIDR based on the MIDR value of the underlying pCPU
  xen/arm: update the docs about heterogeneous computing
  xen/arm: disable CPUs with different dcache line sizes

 docs/misc/arm/big.LITTLE.txt| 46 +
 docs/misc/xen-command-line.markdown | 15 
 xen/arch/arm/arm32/head.S   |  2 +-
 xen/arch/arm/arm64/head.S   |  2 +-
 xen/arch/arm/domain.c   | 15 ++--
 xen/arch/arm/processor.c|  8 +++
 xen/arch/arm/setup.c| 17 ++
 xen/arch/arm/smpboot.c  | 39 +++
 xen/arch/arm/vcpreg.c   |  4 ++--
 xen/include/asm-arm/cpregs.h|  2 ++
 xen/include/asm-arm/domain.h|  3 ---
 xen/include/asm-arm/page.h  | 27 +++---
 12 files changed, 138 insertions(+), 42 deletions(-)
 create mode 100644 docs/misc/arm/big.LITTLE.txt

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

[Xen-devel] [PATCH v4 4/7] xen/arm: read ACTLR on the pcpu where the vcpu will run

[Stefano Stabellini]

On big.LITTLE systems not all cores have the same ACTLR. Instead of
reading ACTLR and setting v->arch.actlr in vcpu_initialise, do it later
on the same pcpu where the vcpu will run.

This way, assuming that the vcpu has been created with the right pcpu
affinity, the guest will be able to read the right ACTLR value, matching
the one of the physical cpu.

Also move processor_vcpu_initialise(v) to continue_new_vcpu as it
can modify v->arch.actlr.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Julien Grall 
---

Changes in v2:
- move processor_vcpu_initialise to continue_new_vcpu
- remove inaccurate sentence from commit message
---
 xen/arch/arm/domain.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a74ff1c..5e76809 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -314,6 +314,9 @@ static void schedule_tail(struct vcpu *prev)
 
 static void continue_new_vcpu(struct vcpu *prev)
 {
+current->arch.actlr = READ_SYSREG32(ACTLR_EL1);
+processor_vcpu_initialise(current);
+
 schedule_tail(prev);
 
 if ( is_idle_vcpu(current) )
@@ -540,12 +543,8 @@ int vcpu_initialise(struct vcpu *v)
 
 v->arch.vmpidr = MPIDR_SMP | vcpuid_to_vaffinity(v->vcpu_id);
 
-v->arch.actlr = READ_SYSREG32(ACTLR_EL1);
-
 v->arch.hcr_el2 = get_default_hcr_flags();
 
-processor_vcpu_initialise(v);
-
 if ( (rc = vcpu_vgic_init(v)) != 0 )
 goto fail;
 
-- 
1.9.1


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

[Xen-devel] [PATCH v4 1/7] xen/arm: Read the dcache line size from CTR register

[Stefano Stabellini]

See the corresponding Linux commit as reference:

  commit f91e2c3bd427239c198351f44814dd39db91afe0
  Author: Catalin Marinas 
  Date:   Tue Dec 7 16:52:04 2010 +0100

  ARM: 6527/1: Use CTR instead of CCSIDR for the D-cache line size on ARMv7

  The current implementation of the dcache_line_size macro reads the L1
  cache size from the CCSIDR register. This, however, is not guaranteed to
  be the smallest cache line in the cache hierarchy. The patch changes to
  the macro to use the more architecturally correct CTR register.

  Reported-by: Kevin Sapp 
  Signed-off-by: Catalin Marinas 
  Signed-off-by: Russell King 

Also rename cacheline_bytes to dcache_line_bytes to clarify that it is
the minimum D-Cache line size.

Suggested-by: Julien Grall 
Signed-off-by: Stefano Stabellini 

---
Changes in v4:
- move patch to the beginning of the series
- rename cacheline_bytes to dcache_line_bytes
- improve commit message
---
 xen/arch/arm/arm32/head.S|  2 +-
 xen/arch/arm/arm64/head.S|  2 +-
 xen/arch/arm/setup.c | 13 ++---
 xen/include/asm-arm/cpregs.h |  2 ++
 xen/include/asm-arm/page.h   | 16 
 5 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 43374e7..2b12908 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -504,7 +504,7 @@ ENTRY(relocate_xen)
 dsb/* So the CPU issues all writes to the range */
 
 mov   r5, r4
-ldr   r6, =cacheline_bytes /* r6 := step */
+ldr   r6, =dcache_line_bytes /* r6 := step */
 ldr   r6, [r6]
 mov   r7, r3
 
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index fa0ef70..38899c7 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -631,7 +631,7 @@ ENTRY(relocate_xen)
 dsb   sy/* So the CPU issues all writes to the range */
 
 mov   x9, x3
-ldr   x10, =cacheline_bytes /* x10 := step */
+ldr   x10, =dcache_line_bytes /* x10 := step */
 ldr   x10, [x10]
 mov   x11, x2
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 032a6a8..fced75a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -680,19 +680,18 @@ static void __init setup_mm(unsigned long dtb_paddr, 
size_t dtb_size)
 }
 #endif
 
-size_t __read_mostly cacheline_bytes;
+size_t __read_mostly dcache_line_bytes;
 
 /* Very early check of the CPU cache properties */
 void __init setup_cache(void)
 {
-uint32_t ccsid;
+uint32_t ctr;
 
-/* Read the cache size ID register for the level-0 data cache */
-WRITE_SYSREG32(0, CSSELR_EL1);
-ccsid = READ_SYSREG32(CCSIDR_EL1);
+/* Read CTR */
+ctr = READ_SYSREG32(CTR_EL0);
 
-/* Low 3 bits are log2(cacheline size in words) - 2. */
-cacheline_bytes = 1U << (4 + (ccsid & 0x7));
+/* Bits 16-19 are the log2 number of words in the cacheline. */
+dcache_line_bytes = (size_t) (4 << ((ctr >> 16) & 0xf));
 }
 
 /* C entry point for boot CPU */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 9e13848..8db65d5 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -106,6 +106,7 @@
 
 /* CP15 CR0: CPUID and Cache Type Registers */
 #define MIDRp15,0,c0,c0,0   /* Main ID Register */
+#define CTR p15,0,c0,c0,1   /* Cache Type Register */
 #define MPIDR   p15,0,c0,c0,5   /* Multiprocessor Affinity Register */
 #define ID_PFR0 p15,0,c0,c1,0   /* Processor Feature Register 0 */
 #define ID_PFR1 p15,0,c0,c1,1   /* Processor Feature Register 1 */
@@ -303,6 +304,7 @@
 #define CPACR_EL1   CPACR
 #define CPTR_EL2HCPTR
 #define CSSELR_EL1  CSSELR
+#define CTR_EL0 CTR
 #define DACR32_EL2  DACR
 #define ESR_EL1 DFSR
 #define ESR_EL2 HSR
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index d948250..ce18f0c 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -134,7 +134,7 @@
 /* Architectural minimum cacheline size is 4 32-bit words. */
 #define MIN_CACHELINE_BYTES 16
 /* Actual cacheline size on the boot CPU. */
-extern size_t cacheline_bytes;
+extern size_t dcache_line_bytes;
 
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
@@ -145,7 +145,7 @@ extern size_t cacheline_bytes;
 static inline int invalidate_dcache_va_range(const void *p, unsigned long size)
 {
 const void *end = p + size;
-size_t cacheline_mask = cacheline_bytes - 1;
+size_t cacheline_mask = dcache_line_bytes - 1;
 
 dsb(sy);   /* So the CPU issues all writes to the range */
 
@@ -153,7 +153,7 @@ static inline int invalidate_dcache_va_range(const void *p, 

[Xen-devel] [PATCH v4 3/7] xen/arm: make processor a per cpu variable

[Stefano Stabellini]

There can be processors of different kinds on a single system. Make
processor a per_cpu variable pointing to the right processor type for
each core.

Suggested-by: Julien Grall 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Julien Grall 
---
Changes in v2:
- add patch
---
 xen/arch/arm/processor.c | 8 
 xen/arch/arm/smpboot.c   | 2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/processor.c b/xen/arch/arm/processor.c
index 8c425ce..ce43850 100644
--- a/xen/arch/arm/processor.c
+++ b/xen/arch/arm/processor.c
@@ -18,7 +18,7 @@
  */
 #include 
 
-static const struct processor *processor = NULL;
+static DEFINE_PER_CPU(struct processor *, processor);
 
 void __init processor_setup(void)
 {
@@ -28,15 +28,15 @@ void __init processor_setup(void)
 if ( !procinfo )
 return;
 
-processor = procinfo->processor;
+this_cpu(processor) = procinfo->processor;
 }
 
 void processor_vcpu_initialise(struct vcpu *v)
 {
-if ( !processor || !processor->vcpu_initialise )
+if ( !this_cpu(processor) || !this_cpu(processor)->vcpu_initialise )
 return;
 
-processor->vcpu_initialise(v);
+this_cpu(processor)->vcpu_initialise(v);
 }
 
 /*
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 7ea4e41..122c0b5 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -300,6 +301,7 @@ void start_secondary(unsigned long boot_phys_offset,
 set_processor_id(cpuid);
 
 identify_cpu(_cpu_data);
+processor_setup();
 
 init_traps();
 
-- 
1.9.1


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

Re: [Xen-devel] [PATCH] xl: remove apic option for PVH guests

[Andrew Cooper]

On 02/03/18 11:09, Wei Liu wrote:
> On Thu, Mar 01, 2018 at 05:01:55PM +, Roger Pau Monné wrote:
>> On Thu, Mar 01, 2018 at 04:01:23PM +, Wei Liu wrote:
>>> On Thu, Mar 01, 2018 at 03:57:18PM +, Andrew Cooper wrote:
 On 01/03/18 12:22, Wei Liu wrote:
> On Wed, Feb 28, 2018 at 10:20:53AM +, Roger Pau Monne wrote:
>> XSA-256 forces the local APIC to always be enabled for PVH guests, so
>> ignore any apic option for PVH guests. Update the documentation
>> accordingly.
> I think how I will approach this is to dictate that PVH always has LAPIC
> in our in-tree document, then use that as the justification for this
> change. That's the consensus from 2 years ago, right?
>
> Or we're just working around the limitation in our code base, and users
> may demand a no-LAPIC PVH guest just because...
 Currently, Xen enforces that HVM guests have an LAPIC.  This is because
 making the non-LAPIC case function correctly/safely devolved into a
 massive rats nest and I stopped trying to fix it after 2 days of trying.

 At the moment, it would be wise to discuss whether the non-LAPIC case is
 actually sensible.  I personally see no value in keeping it.

>>> +1
>>>
 If someone can come up with a convincing usecase for keeping it, then
 ok, but the barrier for this is increasing all the time, especially now
 that hardware acceleration and posted interrupts means that a
 pipeline-virtualised APIC is faster and more efficient than any of our
 event channel mechanisms.
>>> +1
>> I've looked at the in-tree pvh document and it just refers to the local
>> APIC in this sentence:
>>
>> "AP startup can be performed using hypercalls or the local APIC if present."
>>
>> I guess the trailing "if present" could be removed, but it's not
>> colliding with this patch.
>>
>> I'm happy with rebasing this patch and applying the above change, is
>> there any other document that should be changed?
> Can we make it more explicit. Like
>
>   VCPUs for PVH must have local APIC and it can't be disabled.

-1 to this.  When an APIC is available to the guest, there is soft
disable and hard disable as part of the state model.  Saying this will
only confuse the matter.

~Andrew

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  43c54ac6053bd0ab397d7b77519e875b01a9a105
baseline version:
 xen  2d9078954279e943d976ca2154c16b986dd25799

Last test of basis   120151  2018-03-02 13:06:50 Z0 days
Testing same since   120164  2018-03-02 17:01:43 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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

To xenbits.xen.org:/home/xen/git/xen.git
   2d90789542..43c54ac605  43c54ac6053bd0ab397d7b77519e875b01a9a105 -> smoke

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

[Xen-devel] [PATCH] x86/boot: Annotate the multiboot headers with size and type information

[Andrew Cooper]

This causes objdump not to try and disassemble the data.

While altering this area, switch to using .balign, and fill with 0xc2 to help
highlight the embedded padding (rather than having it filled with 0f 1f 40 00
which is a long nop).  Also, shorten the labels by stripping off the _start
suffix.

The end result is now:
  82d08020 <_start>:
  82d08020:   e9 af c1 1c 00  jmpq   82d0803cc1b4 
<__start>
  82d08025:   0f 1f 00nopl   (%rax)

  82d08028 :
  82d08028:   02 b0 ad 1b 03 00 00 00 fb 4f 52 e4 c2 c2 c2 c2 
.OR.

  82d080200018 :
  82d080200018:   d6 50 52 e8 00 00 00 00 88 00 00 00 a2 ae ad 17 
.PR.
  82d080200028:   01 00 00 00 10 00 00 00 04 00 00 00 06 00 00 00 

  82d080200038:   06 00 00 00 08 00 00 00 0a 00 01 00 18 00 00 00 

  82d080200048:   00 00 20 00 ff ff ff ff 00 00 20 00 02 00 00 00 
.. ... .
  82d080200058:   04 00 01 00 0c 00 00 00 02 00 00 00 c2 c2 c2 c2 

  82d080200068:   05 00 01 00 14 00 00 00 00 00 00 00 00 00 00 00 

  82d080200078:   00 00 00 00 c2 c2 c2 c2 07 00 01 00 08 00 00 00 

  82d080200088:   09 00 01 00 0c 00 00 00 5e c0 3c 00 c2 c2 c2 c2 
^.<.
  82d080200098:   00 00 00 00 08 00 00 00 


  82d0802000a0 <__high_start>:
  82d0802000a0:   0f 01 15 5f 8f 25 00lgdt   0x258f5f(%rip)
# 82d080459006 

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

I was considering whether it was worth splitting the multiboot headers out
into a separate file, to declutter the top of head.S
---
 xen/arch/x86/boot/head.S | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 63bc1b3..db19ac6 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -34,7 +34,7 @@
 .endm
 
 .macro mb2ht_init type:req, req:req, args:vararg
-.align MULTIBOOT2_TAG_ALIGN
+.balign MULTIBOOT2_TAG_ALIGN, 0xc2 /* Avoid padding with long nops. */
 .Lmb2ht_init_start\@:
 .short \type
 .short \req
@@ -48,8 +48,8 @@
 ENTRY(start)
 jmp __start
 
-.align 4
-multiboot1_header_start:   /*** MULTIBOOT1 HEADER /
+.balign 4
+multiboot1_header: /*** MULTIBOOT1 HEADER /
 #define MULTIBOOT_HEADER_FLAGS (MULTIBOOT_HEADER_MODS_ALIGNED | \
 MULTIBOOT_HEADER_WANT_MEMORY)
 /* Magic number indicating a Multiboot header. */
@@ -58,22 +58,24 @@ multiboot1_header_start:   /*** MULTIBOOT1 HEADER /
 .long   MULTIBOOT_HEADER_FLAGS
 /* Checksum: must be the negated sum of the first two fields. */
 .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
-multiboot1_header_end:
+
+.size multiboot1_header, . - multiboot1_header
+.type multiboot1_header, @object
 
 /*** MULTIBOOT2 HEADER /
 /* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S 
file. */
-.align  MULTIBOOT2_HEADER_ALIGN
+.balign MULTIBOOT2_HEADER_ALIGN, 0xc2  /* Avoid padding the MB1 header 
with long nops. */
 
-multiboot2_header_start:
+multiboot2_header:
 /* Magic number indicating a Multiboot2 header. */
 .long   MULTIBOOT2_HEADER_MAGIC
 /* Architecture: i386. */
 .long   MULTIBOOT2_ARCHITECTURE_I386
 /* Multiboot2 header length. */
-.long   .Lmultiboot2_header_end - multiboot2_header_start
+.long   .Lmultiboot2_header_end - multiboot2_header
 /* Multiboot2 header checksum. */
 .long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
-(.Lmultiboot2_header_end - multiboot2_header_start))
+(.Lmultiboot2_header_end - multiboot2_header))
 
 /* Multiboot2 information request tag. */
 mb2ht_init MB2_HT(INFORMATION_REQUEST), MB2_HT(REQUIRED), \
@@ -110,6 +112,9 @@ multiboot2_header_start:
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
 .Lmultiboot2_header_end:
 
+.size multiboot2_header, . - multiboot2_header
+.type multiboot2_header, @object
+
 .section .init.rodata, "a", @progbits
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v3 6/6] xen/arm: disable CPUs with different cacheline sizes

[Julien Grall]

On 02/03/2018 18:35, Stefano Stabellini wrote:

On Fri, 2 Mar 2018, Andrew Cooper wrote:

On 02/03/18 18:26, Stefano Stabellini wrote:



Suggested-by: Julien Grall 
Signed-off-by: Stefano Stabellini 

---
Changes in v3:
- new patch

---
Interestingly I couldn't find a better way in C89 to printk a size_t
than casting it to unsigned long.

You can use %zu.

It's C99 only :-(


Sorry for the interjection, but what has C89 got to do with anything?
Xen uses -std=gnu99, as per the root Config.mk file.


I remember our discussions about C standard versions, but I take that
they only affected public headers then (unless I am misremembering).


That's right. Public headers should be C89 compliant. Xen is making good 
use of C99 :).


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: Read the cacheline size from CTR register

[Julien Grall]

On 02/03/2018 18:33, Stefano Stabellini wrote:

On Fri, 2 Mar 2018, Stefano Stabellini wrote:

On Fri, 2 Mar 2018, Julien Grall wrote:

Hi,

On 01/03/18 23:27, Stefano Stabellini wrote:

See the corresponding Linux commit as reference:

commit f91e2c3bd427239c198351f44814dd39db91afe0
Author: Catalin Marinas 
Date:   Tue Dec 7 16:52:04 2010 +0100

ARM: 6527/1: Use CTR instead of CCSIDR for the D-cache line size on
ARMv7

The current implementation of the dcache_line_size macro reads the L1
cache size from the CCSIDR register. This, however, is not guaranteed
to
be the smallest cache line in the cache hierarchy. The patch changes
to
the macro to use the more architecturally correct CTR register.

Reported-by: Kevin Sapp 
Signed-off-by: Catalin Marinas 
Signed-off-by: Russell King 

Suggested-by: Julien Grall 
Signed-off-by: Stefano Stabellini 

---

This patch depends on "unsafe big.LITTLE support".


I still really don't think this should depend on "unsafe big.LITTLE support".
We want to backport this patch but I am still unconvinced that this is the
case of the big.LITTLE one. So can you please reshuffle the patches?


I'll move it earlier. For simplicity, I'll make it the first patch of
"unsafe big.LITTLE support", althought I understand that they are
separate fixes.




Previously, we discussed the possibility of reading the cacheline size
when needed from the register, instead of reading it from a variable,
but going through the code it doesn't seem like a worthwhile
optimization.


Well there are a couple of reasons I wanted this to avoid the a variable:
1) Potentially reading a system register + few instructions is faster
than a memory access
2) The name of the variable leads to confusing. It is named
cacheline_bytes but stores the minimum cacheline size of for the data cache.

1) is arguable and I don't much care whether it is done. However, I really
want to avoid a wrong variable name that could lead to more misuse. So we
should at least rename read_cacheline_size() and cacheline_bytes.


Sure, I can rename. Would min_cacheline_bytes and
read_min_cacheline_bytes() be clearer? Otherwise, please suggest an
alternative naming scheme.


Or min_dcache_line_bytes ?


I would reduce to dcache_line_bytes to avoid lengthy name.
That would go inline with the macro dcache_line_size we currently have 
in arm64.


What matters is the 'd' for data cache. To avoid confusion which 'i' for 
instruction cache that we may need in the future.


Anyway, I am happy with both.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 6/6] xen/arm: disable CPUs with different cacheline sizes

[Stefano Stabellini]

On Fri, 2 Mar 2018, Andrew Cooper wrote:
> On 02/03/18 18:26, Stefano Stabellini wrote:
> >
> >>> Suggested-by: Julien Grall 
> >>> Signed-off-by: Stefano Stabellini 
> >>>
> >>> ---
> >>> Changes in v3:
> >>> - new patch
> >>>
> >>> ---
> >>> Interestingly I couldn't find a better way in C89 to printk a size_t
> >>> than casting it to unsigned long.
> >> You can use %zu.
> > It's C99 only :-(
> 
> Sorry for the interjection, but what has C89 got to do with anything? 
> Xen uses -std=gnu99, as per the root Config.mk file.

I remember our discussions about C standard versions, but I take that
they only affected public headers then (unless I am misremembering).
Good!___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen/arm: Read the cacheline size from CTR register

[Stefano Stabellini]

On Fri, 2 Mar 2018, Stefano Stabellini wrote:
> On Fri, 2 Mar 2018, Julien Grall wrote:
> > Hi,
> > 
> > On 01/03/18 23:27, Stefano Stabellini wrote:
> > > See the corresponding Linux commit as reference:
> > > 
> > >commit f91e2c3bd427239c198351f44814dd39db91afe0
> > >Author: Catalin Marinas 
> > >Date:   Tue Dec 7 16:52:04 2010 +0100
> > > 
> > >ARM: 6527/1: Use CTR instead of CCSIDR for the D-cache line size on
> > > ARMv7
> > > 
> > >The current implementation of the dcache_line_size macro reads the 
> > > L1
> > >cache size from the CCSIDR register. This, however, is not 
> > > guaranteed
> > > to
> > >be the smallest cache line in the cache hierarchy. The patch 
> > > changes
> > > to
> > >the macro to use the more architecturally correct CTR register.
> > > 
> > >Reported-by: Kevin Sapp 
> > >Signed-off-by: Catalin Marinas 
> > >Signed-off-by: Russell King 
> > > 
> > > Suggested-by: Julien Grall 
> > > Signed-off-by: Stefano Stabellini 
> > > 
> > > ---
> > > 
> > > This patch depends on "unsafe big.LITTLE support".
> > 
> > I still really don't think this should depend on "unsafe big.LITTLE 
> > support".
> > We want to backport this patch but I am still unconvinced that this is the
> > case of the big.LITTLE one. So can you please reshuffle the patches?
> 
> I'll move it earlier. For simplicity, I'll make it the first patch of
> "unsafe big.LITTLE support", althought I understand that they are
> separate fixes.
> 
> 
> > > 
> > > Previously, we discussed the possibility of reading the cacheline size
> > > when needed from the register, instead of reading it from a variable,
> > > but going through the code it doesn't seem like a worthwhile
> > > optimization.
> > 
> > Well there are a couple of reasons I wanted this to avoid the a variable:
> > 1) Potentially reading a system register + few instructions is faster
> > than a memory access
> > 2) The name of the variable leads to confusing. It is named
> > cacheline_bytes but stores the minimum cacheline size of for the data cache.
> > 
> > 1) is arguable and I don't much care whether it is done. However, I really
> > want to avoid a wrong variable name that could lead to more misuse. So we
> > should at least rename read_cacheline_size() and cacheline_bytes.
> 
> Sure, I can rename. Would min_cacheline_bytes and
> read_min_cacheline_bytes() be clearer? Otherwise, please suggest an
> alternative naming scheme.

Or min_dcache_line_bytes ?

 
> > 
> > > ---
> > >   xen/include/asm-arm/cpregs.h |  2 ++
> > >   xen/include/asm-arm/page.h   | 11 +--
> > >   2 files changed, 7 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
> > > index 9e13848..8db65d5 100644
> > > --- a/xen/include/asm-arm/cpregs.h
> > > +++ b/xen/include/asm-arm/cpregs.h
> > > @@ -106,6 +106,7 @@
> > > /* CP15 CR0: CPUID and Cache Type Registers */
> > >   #define MIDRp15,0,c0,c0,0   /* Main ID Register */
> > > +#define CTR p15,0,c0,c0,1   /* Cache Type Register */
> > >   #define MPIDR   p15,0,c0,c0,5   /* Multiprocessor Affinity
> > > Register */
> > >   #define ID_PFR0 p15,0,c0,c1,0   /* Processor Feature Register 0 
> > > */
> > >   #define ID_PFR1 p15,0,c0,c1,1   /* Processor Feature Register 1 
> > > */
> > > @@ -303,6 +304,7 @@
> > >   #define CPACR_EL1   CPACR
> > >   #define CPTR_EL2HCPTR
> > >   #define CSSELR_EL1  CSSELR
> > > +#define CTR_EL0 CTR
> > >   #define DACR32_EL2  DACR
> > >   #define ESR_EL1 DFSR
> > >   #define ESR_EL2 HSR
> > > diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> > > index 9fbf232..4c81878 100644
> > > --- a/xen/include/asm-arm/page.h
> > > +++ b/xen/include/asm-arm/page.h
> > > @@ -140,14 +140,13 @@ extern size_t cacheline_bytes;
> > > static inline size_t read_cacheline_size(void)
> > >   {
> > > -uint32_t ccsid;
> > > +uint32_t ctr;
> > >   -/* Read the cache size ID register for the level-0 data cache */
> > > -WRITE_SYSREG32(0, CSSELR_EL1);
> > > -ccsid = READ_SYSREG32(CCSIDR_EL1);
> > > +/* Read CTR */
> > > +ctr = READ_SYSREG32(CTR_EL0);
> > >   -/* Low 3 bits are log2(cacheline size in words) - 2. */
> > > -return (size_t) (1U << (4 + (ccsid & 0x7)));
> > > +/* Bits 16-19 are the log2 number of words in the cacheline. */
> > > +return (size_t) (4 << ((ctr >> 16) & 0xf));
> > >   }
> > > /* Functions for flushing medium-sized areas.
> > > 
> > 
> > -- 
> > Julien Grall
> > 
> 

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

Re: [Xen-devel] [PATCH v3 6/6] xen/arm: disable CPUs with different cacheline sizes

[Andrew Cooper]

On 02/03/18 18:26, Stefano Stabellini wrote:
>
>>> Suggested-by: Julien Grall 
>>> Signed-off-by: Stefano Stabellini 
>>>
>>> ---
>>> Changes in v3:
>>> - new patch
>>>
>>> ---
>>> Interestingly I couldn't find a better way in C89 to printk a size_t
>>> than casting it to unsigned long.
>> You can use %zu.
> It's C99 only :-(

Sorry for the interjection, but what has C89 got to do with anything? 
Xen uses -std=gnu99, as per the root Config.mk file.

~Andrew

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

Re: [Xen-devel] [PATCH] xen/arm: Read the cacheline size from CTR register

[Stefano Stabellini]

Thanks, I'll mention it in the commit message.

On Fri, 2 Mar 2018, Julien Grall wrote:
> Hi,
> 
> I forgot to mention in the title:
> 
> You read the minimum D-Cache line size. The minimum I-Cache line size is read
> from CTR_EL0.IminLine.
> 
> Cheers,
> 
> On 01/03/18 23:27, Stefano Stabellini wrote:
> > See the corresponding Linux commit as reference:
> > 
> >commit f91e2c3bd427239c198351f44814dd39db91afe0
> >Author: Catalin Marinas 
> >Date:   Tue Dec 7 16:52:04 2010 +0100
> > 
> >ARM: 6527/1: Use CTR instead of CCSIDR for the D-cache line size on
> > ARMv7
> > 
> >The current implementation of the dcache_line_size macro reads the L1
> >cache size from the CCSIDR register. This, however, is not guaranteed
> > to
> >be the smallest cache line in the cache hierarchy. The patch changes
> > to
> >the macro to use the more architecturally correct CTR register.
> > 
> >Reported-by: Kevin Sapp 
> >Signed-off-by: Catalin Marinas 
> >Signed-off-by: Russell King 
> > 
> > Suggested-by: Julien Grall 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > 
> > This patch depends on "unsafe big.LITTLE support".
> > 
> > Previously, we discussed the possibility of reading the cacheline size
> > when needed from the register, instead of reading it from a variable,
> > but going through the code it doesn't seem like a worthwhile
> > optimization.
> > ---
> >   xen/include/asm-arm/cpregs.h |  2 ++
> >   xen/include/asm-arm/page.h   | 11 +--
> >   2 files changed, 7 insertions(+), 6 deletions(-)
> > 
> > diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
> > index 9e13848..8db65d5 100644
> > --- a/xen/include/asm-arm/cpregs.h
> > +++ b/xen/include/asm-arm/cpregs.h
> > @@ -106,6 +106,7 @@
> > /* CP15 CR0: CPUID and Cache Type Registers */
> >   #define MIDRp15,0,c0,c0,0   /* Main ID Register */
> > +#define CTR p15,0,c0,c0,1   /* Cache Type Register */
> >   #define MPIDR   p15,0,c0,c0,5   /* Multiprocessor Affinity
> > Register */
> >   #define ID_PFR0 p15,0,c0,c1,0   /* Processor Feature Register 0 */
> >   #define ID_PFR1 p15,0,c0,c1,1   /* Processor Feature Register 1 */
> > @@ -303,6 +304,7 @@
> >   #define CPACR_EL1   CPACR
> >   #define CPTR_EL2HCPTR
> >   #define CSSELR_EL1  CSSELR
> > +#define CTR_EL0 CTR
> >   #define DACR32_EL2  DACR
> >   #define ESR_EL1 DFSR
> >   #define ESR_EL2 HSR
> > diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> > index 9fbf232..4c81878 100644
> > --- a/xen/include/asm-arm/page.h
> > +++ b/xen/include/asm-arm/page.h
> > @@ -140,14 +140,13 @@ extern size_t cacheline_bytes;
> > static inline size_t read_cacheline_size(void)
> >   {
> > -uint32_t ccsid;
> > +uint32_t ctr;
> >   -/* Read the cache size ID register for the level-0 data cache */
> > -WRITE_SYSREG32(0, CSSELR_EL1);
> > -ccsid = READ_SYSREG32(CCSIDR_EL1);
> > +/* Read CTR */
> > +ctr = READ_SYSREG32(CTR_EL0);
> >   -/* Low 3 bits are log2(cacheline size in words) - 2. */
> > -return (size_t) (1U << (4 + (ccsid & 0x7)));
> > +/* Bits 16-19 are the log2 number of words in the cacheline. */
> > +return (size_t) (4 << ((ctr >> 16) & 0xf));
> >   }
> > /* Functions for flushing medium-sized areas.
> > 
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] [PATCH] xen/arm: Read the cacheline size from CTR register

[Stefano Stabellini]

On Fri, 2 Mar 2018, Julien Grall wrote:
> Hi,
> 
> On 01/03/18 23:27, Stefano Stabellini wrote:
> > See the corresponding Linux commit as reference:
> > 
> >commit f91e2c3bd427239c198351f44814dd39db91afe0
> >Author: Catalin Marinas 
> >Date:   Tue Dec 7 16:52:04 2010 +0100
> > 
> >ARM: 6527/1: Use CTR instead of CCSIDR for the D-cache line size on
> > ARMv7
> > 
> >The current implementation of the dcache_line_size macro reads the L1
> >cache size from the CCSIDR register. This, however, is not guaranteed
> > to
> >be the smallest cache line in the cache hierarchy. The patch changes
> > to
> >the macro to use the more architecturally correct CTR register.
> > 
> >Reported-by: Kevin Sapp 
> >Signed-off-by: Catalin Marinas 
> >Signed-off-by: Russell King 
> > 
> > Suggested-by: Julien Grall 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > 
> > This patch depends on "unsafe big.LITTLE support".
> 
> I still really don't think this should depend on "unsafe big.LITTLE support".
> We want to backport this patch but I am still unconvinced that this is the
> case of the big.LITTLE one. So can you please reshuffle the patches?

I'll move it earlier. For simplicity, I'll make it the first patch of
"unsafe big.LITTLE support", althought I understand that they are
separate fixes.


> > 
> > Previously, we discussed the possibility of reading the cacheline size
> > when needed from the register, instead of reading it from a variable,
> > but going through the code it doesn't seem like a worthwhile
> > optimization.
> 
> Well there are a couple of reasons I wanted this to avoid the a variable:
>   1) Potentially reading a system register + few instructions is faster
> than a memory access
>   2) The name of the variable leads to confusing. It is named
> cacheline_bytes but stores the minimum cacheline size of for the data cache.
> 
> 1) is arguable and I don't much care whether it is done. However, I really
> want to avoid a wrong variable name that could lead to more misuse. So we
> should at least rename read_cacheline_size() and cacheline_bytes.

Sure, I can rename. Would min_cacheline_bytes and
read_min_cacheline_bytes() be clearer? Otherwise, please suggest an
alternative naming scheme.


> 
> > ---
> >   xen/include/asm-arm/cpregs.h |  2 ++
> >   xen/include/asm-arm/page.h   | 11 +--
> >   2 files changed, 7 insertions(+), 6 deletions(-)
> > 
> > diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
> > index 9e13848..8db65d5 100644
> > --- a/xen/include/asm-arm/cpregs.h
> > +++ b/xen/include/asm-arm/cpregs.h
> > @@ -106,6 +106,7 @@
> > /* CP15 CR0: CPUID and Cache Type Registers */
> >   #define MIDRp15,0,c0,c0,0   /* Main ID Register */
> > +#define CTR p15,0,c0,c0,1   /* Cache Type Register */
> >   #define MPIDR   p15,0,c0,c0,5   /* Multiprocessor Affinity
> > Register */
> >   #define ID_PFR0 p15,0,c0,c1,0   /* Processor Feature Register 0 */
> >   #define ID_PFR1 p15,0,c0,c1,1   /* Processor Feature Register 1 */
> > @@ -303,6 +304,7 @@
> >   #define CPACR_EL1   CPACR
> >   #define CPTR_EL2HCPTR
> >   #define CSSELR_EL1  CSSELR
> > +#define CTR_EL0 CTR
> >   #define DACR32_EL2  DACR
> >   #define ESR_EL1 DFSR
> >   #define ESR_EL2 HSR
> > diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> > index 9fbf232..4c81878 100644
> > --- a/xen/include/asm-arm/page.h
> > +++ b/xen/include/asm-arm/page.h
> > @@ -140,14 +140,13 @@ extern size_t cacheline_bytes;
> > static inline size_t read_cacheline_size(void)
> >   {
> > -uint32_t ccsid;
> > +uint32_t ctr;
> >   -/* Read the cache size ID register for the level-0 data cache */
> > -WRITE_SYSREG32(0, CSSELR_EL1);
> > -ccsid = READ_SYSREG32(CCSIDR_EL1);
> > +/* Read CTR */
> > +ctr = READ_SYSREG32(CTR_EL0);
> >   -/* Low 3 bits are log2(cacheline size in words) - 2. */
> > -return (size_t) (1U << (4 + (ccsid & 0x7)));
> > +/* Bits 16-19 are the log2 number of words in the cacheline. */
> > +return (size_t) (4 << ((ctr >> 16) & 0xf));
> >   }
> > /* Functions for flushing medium-sized areas.
> > 
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] [PATCH v3 6/6] xen/arm: disable CPUs with different cacheline sizes

[Stefano Stabellini]

On Fri, 2 Mar 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 01/03/18 23:26, Stefano Stabellini wrote:
> > Even different cpus in big.LITTLE systems are expected to have the same
> > cacheline size. Unless the minimum of all cacheline sizes is used across
> > all cpu cores, cache coherency protocols can go wrong. Instead, for
> > now, just disable any cpu with a different cacheline size.
> > 
> > This check is not covered by the hmp-unsafe option, because even with
> > the correct scheduling and vcpu pinning in place, the system breaks if
> > cacheline sizes differ across cores. We don't believe it is a problem
> > for most big.LITTLE systems.
> > 
> > This patch moves the implementation of setup_cache to a static inline,
> > still setting cacheline_bytes at the beginning of start_xen as before.
> > 
> > In start_secondary we check that the cacheline sizes match, otherwise we
> > disable the cpu.
> 
> I am afraid that this commit message is only valid after "xen/arm: Read the
> cacheline from CTR register".

I forgot to update the commit message, I'll fix.


> What you effectively check in that patch is the D-cache level 1 line size is
> equal on every CPU. You could rewrite the commit message to reflect that, but
> then people may wonder why you impose such restriction on Xen? So it would
> really make sense to fix the way to read the D-cacheline size first.

Yes, I understand. I'll reshuffle. For simplicity I'll make that patch
part of this series as first patch, although we both understand that
conceptually they are separate.


> > 
> > Suggested-by: Julien Grall 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > Changes in v3:
> > - new patch
> > 
> > ---
> > Interestingly I couldn't find a better way in C89 to printk a size_t
> > than casting it to unsigned long.
> 
> You can use %zu.

It's C99 only :-(


> > ---
> >   xen/arch/arm/setup.c   | 15 +--
> >   xen/arch/arm/smpboot.c |  8 
> >   xen/include/asm-arm/page.h | 12 
> >   3 files changed, 21 insertions(+), 14 deletions(-)
> > 
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 032a6a8..b5f4c3a 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -682,19 +682,6 @@ static void __init setup_mm(unsigned long dtb_paddr,
> > size_t dtb_size)
> > size_t __read_mostly cacheline_bytes;
> >   -/* Very early check of the CPU cache properties */
> > -void __init setup_cache(void)
> > -{
> > -uint32_t ccsid;
> > -
> > -/* Read the cache size ID register for the level-0 data cache */
> > -WRITE_SYSREG32(0, CSSELR_EL1);
> > -ccsid = READ_SYSREG32(CCSIDR_EL1);
> > -
> > -/* Low 3 bits are log2(cacheline size in words) - 2. */
> > -cacheline_bytes = 1U << (4 + (ccsid & 0x7));
> > -}
> > -
> >   /* C entry point for boot CPU */
> >   void __init start_xen(unsigned long boot_phys_offset,
> > unsigned long fdt_paddr,
> > @@ -708,7 +695,7 @@ void __init start_xen(unsigned long boot_phys_offset,
> >   struct domain *dom0;
> >   struct xen_arch_domainconfig config;
> >   -setup_cache();
> > +cacheline_bytes = read_cacheline_size();
> > percpu_init_areas();
> >   set_processor_id(0); /* needed early, for smp_processor_id() */
> > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> > index 04efb33..153572e 100644
> > --- a/xen/arch/arm/smpboot.c
> > +++ b/xen/arch/arm/smpboot.c
> > @@ -323,6 +323,14 @@ void start_secondary(unsigned long boot_phys_offset,
> >   stop_cpu();
> >   }
> >   +if ( cacheline_bytes != read_cacheline_size() )
> > +{
> > +printk(XENLOG_ERR "CPU%u cacheline size (%lu) does not match the
> > boot CPU (%lu)\n",
> > +   smp_processor_id(), (unsigned long) read_cacheline_size(),
> > +   (unsigned long) cacheline_bytes);
> > +stop_cpu();
> > +}
> > +
> >   mmu_init_secondary_cpu();
> > gic_init_secondary_cpu();
> > diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> > index d948250..9fbf232 100644
> > --- a/xen/include/asm-arm/page.h
> > +++ b/xen/include/asm-arm/page.h
> > @@ -138,6 +138,18 @@ extern size_t cacheline_bytes;
> > #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
> >   +static inline size_t read_cacheline_size(void)
> > +{
> > +uint32_t ccsid;
> > +
> > +/* Read the cache size ID register for the level-0 data cache */
> > +WRITE_SYSREG32(0, CSSELR_EL1);
> > +ccsid = READ_SYSREG32(CCSIDR_EL1);
> > +
> > +/* Low 3 bits are log2(cacheline size in words) - 2. */
> > +return (size_t) (1U << (4 + (ccsid & 0x7)));
> > +}
> > +
> >   /* Functions for flushing medium-sized areas.
> >* if 'range' is large enough we might want to use model-specific
> >* full-cache flushes. */
> > 
> 
> -- 
> Julien Grall
> 

___
Xen-devel mailing list

Re: [Xen-devel] [PATCH v2 2/2] x86/xpti: don't map stack guard pages

[Andrew Cooper]

On 02/03/18 14:35, Jan Beulich wrote:
> Other than for the main mappings, don't even do this in release builds,
> as there are no huge page shattering concerns here.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper , although I think
somewhere (even if its only the commit message) might want to identify
that this is safe to the AMD triple fault issue, because even if someone
enabled XPTI, it only takes effect for PV guests, rather than HVM.  Also,

> ---
> v2: New.
>
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -799,7 +799,8 @@ static int setup_cpu_root_pgt(unsigned i
>  
>  /* Install direct map page table entries for stack, IDT, and TSS. */
>  for ( off = rc = 0; !rc && off < STACK_SIZE; off += PAGE_SIZE )
> -rc = clone_mapping(__va(__pa(stack_base[cpu])) + off, rpt);
> +if ( !memguard_is_stack_guard_page(off) )
> +rc = clone_mapping(__va(__pa(stack_base[cpu])) + off, rpt);
>  
>  if ( !rc )
>  rc = clone_mapping(idt_tables[cpu], rpt);
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5576,6 +5576,14 @@ void memguard_unguard_stack(void *p)
> STACK_SIZE - PRIMARY_STACK_SIZE - IST_MAX * 
> PAGE_SIZE);
>  }
>  
> +bool memguard_is_stack_guard_page(unsigned long addr)
> +{
> +addr &= STACK_SIZE - 1;
> +
> +return addr >= IST_MAX * PAGE_SIZE &&
> +   addr < STACK_SIZE - PRIMARY_STACK_SIZE;
> +}

This probably would be better as a static inline, rather than a call
into a separate translation unit, at which point a clever compiler might
be able to split the loop in two (and may actually have an easier time
doing so if the logic was expressed in terms of get_stack_page()).

~Andrew

> +
>  void arch_dump_shared_mem_info(void)
>  {
>  printk("Shared frames %u -- Saved frames %u\n",
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -519,6 +519,7 @@ void memguard_unguard_range(void *p, uns
>  
>  void memguard_guard_stack(void *p);
>  void memguard_unguard_stack(void *p);
> +bool __attribute_const__ memguard_is_stack_guard_page(unsigned long addr);
>  
>  struct mmio_ro_emulate_ctxt {
>  unsigned long cr2;
>
>
>


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

Re: [Xen-devel] [PATCH v2 1/5] x86/entry: Correct comparisons against boolean variables

[Wei Liu]

On Tue, Feb 27, 2018 at 02:50:32PM +, Andrew Cooper wrote:
> The correct way to check a boolean is `cmpb $0` or `testb $0xff`, whereas a
> lot of our entry code uses `testb $1`.  This will work in principle for values
> which are really C _Bool types, but won't work for other integer types which
> are intended to have boolean properties.
> 
> cmp is the more logical way of thinking about the operation, so adjust all
> outstanding uses of `testb $1` against boolean values.  Changing test to cmp
> changes the logical mnemonic of the following condition from 'zero' to
> 'equal', but the actual encoding remains the same.
> 
> No functional change, as all uses are real C _Bool types, and confirmed by
> diffing the disassembly.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

[Wei Liu]

On Fri, Mar 02, 2018 at 10:23:08AM -0700, Jim Fehlig wrote:
> On 03/02/2018 05:40 AM, Wei Liu wrote:
> > On Fri, Mar 02, 2018 at 12:29:31PM +, Wei Liu wrote:
> > > On Mon, Feb 26, 2018 at 09:53:38AM -0700, Jim Fehlig wrote:
> > > > On 02/26/2018 01:46 AM, Juergen Gross wrote:
> > > > > When creating a pthread in xs_watch() try to get the minimal needed
> > > > > size of the thread from glibc instead of using a constant. This avoids
> > > > > problems when the library is used in programs with large per-thread
> > > > > memory.
> > > > > 
> > > > > Use dlsym() to get the pointer to __pthread_get_minstack() in order to
> > > > > avoid linkage problems and fall back to the current constant size if
> > > > > not found.
> > > > > 
> > > > > Signed-off-by: Juergen Gross 
> > > > > ---
> > > > > V2:
> > > > > - use _GNU_SOURCE (Wei Liu)
> > > > > - call __pthread_get_minstack() with parameter
> > > > > - add -ldl to correct make flags
> > > > > - ensure to not using smaller stack size than today
> > > > > ---
> > > > >tools/xenstore/Makefile |  4 
> > > > >tools/xenstore/xs.c | 21 -
> > > > >2 files changed, 24 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> > > > > index 2b99d2bc1b..0831be0b6f 100644
> > > > > --- a/tools/xenstore/Makefile
> > > > > +++ b/tools/xenstore/Makefile
> > > > > @@ -100,6 +100,10 @@ libxenstore.so.$(MAJOR): 
> > > > > libxenstore.so.$(MAJOR).$(MINOR)
> > > > >   ln -sf $< $@
> > > > >xs.opic: CFLAGS += -DUSE_PTHREAD
> > > > > +ifeq ($(CONFIG_Linux),y)
> > > > > +xs.opic: CFLAGS += -DUSE_DLSYM
> > > > > +libxenstore.so.$(MAJOR).$(MINOR): LDFLAGS += -ldl
> > > > > +endif
> > > > 
> > > > Dropping this patch in one of my automated builds caused a libxenstore 
> > > > link failure
> > > > 
> > > > [   99s] gcc-lsystemd -ldl -pthread -Wl,-soname 
> > > > -Wl,libxenstore.so.3.0
> > > > -shared -o libxenstore.so.3.0.3 xs.opic xs_lib.opic 
> > > > /home/abuild/rpmbuild/BUILD/xen-4.10.0-testing/tools/xenstore/../../tools/libs/toolcore/libxentoolcore.so
> > > > 
> > > > [   99s] 
> > > > /home/abuild/rpmbuild/BUILD/xen-4.10.0-testing/tools/xenstore/../../tools/xenstore/libxenstore.so:
> > > > undefined reference to `dlsym'
> > > > 
> > > > I hacked around it by appending '-ldl' to the end of the subsequent
> > > > libxenstore.so rule.
> > > 
> > > Hmm... Maybe I'm a bit dense today. I know the position of -l matters
> > > but I don't quite understand how placing -pthread before xs.opic works
> > > but -ldl doesn't. xs.c uses both after all.
> > 
> > I'm indeed very dense -- -pthread is a special option that sets the
> > proper flags for linking pthread library for both the preprocessor and
> > linker.
> > 
> > But still, Juergen must have tested the change, so I wonder why it
> > doesn't work in your setup. What is your build environment? Gcc version?
> 
> I dropped the patch in a package build on the openSUSE build service, where
> gcc7 was used. But I don't see the problem when building from sources with
> gcc7. Apparently we have a bug in our package build, so ignore this comment.
> Tested-by still stands though :-).
> 

OK, thanks for the reply.

I will commit this patch soon.

Wei.

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

Re: [Xen-devel] update_runstate_area and Linux KPTI

[Juergen Gross]

On 02/03/18 18:09, Andrew Cooper wrote:
> On 02/03/18 17:05, Juergen Gross wrote:
>> On 02/03/18 17:51, Jan Beulich wrote:
>> On 02.03.18 at 17:25,  wrote:
 On 02/03/18 16:18, Jan Beulich wrote:
 On 02.03.18 at 17:04,  wrote:
>> The proper way to do this is indeed by a nominated (guest) physical
>> address, at which point Xen can make all/any updates at times of its
>> choosing, and the guests pagetable/permissions state at an instantaneous
>> moment don't matter.
>>
>> If you've got time to do this, then please do.  It will be a definite
>> improvement.
> Just to be avoid unnecessary effort in the wrong direction: I don't
> think you can alter the current interface. You'd have to add a new
> one, and we could then deprecate (but never abandon) the current
> one.
 I was only planning to store the guest physical address rather than the 
 virtual address as we do today. Is that considered as an alteration of 
 the current interface?
>>> Yes, it is, as an existing PV kernel could deliberately alter the
>>> mappings underlying the linear address it has handed us.
>> Linux pvops kernel isn't doing this. Mini-OS neither. I guess kernel-xen
>> would be okay with this, too. And I bet BSD is also fine.
>>
>> Seriously: any kernel playing such tricks is asking for problems.
>>
>> We shouldn't support operation modes which make no sense just for the
>> sake of compatibility, IMO.
> 
> I'd love to do this, but we cant.  Older Linux used to have a virtual
> buffer spanning a page boundary.  Changing the behaviour under that will
> cause older setups to explode.

Adding a special per-domain mapping for that purpose would work.


Juergen


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

Re: [Xen-devel] [PATCH v2 1/2] x86/xpti: really hide almost all of Xen image

[Andrew Cooper]

On 02/03/18 17:04, Jan Beulich wrote:
 On 02.03.18 at 17:53,  wrote:
>> On 02/03/18 14:34, Jan Beulich wrote:
>>> Note that the removed BUILD_BUG_ON()s don't get replaced by anything -
>>> there already is a suitable ASSERT() in xen.lds.S.
>> This isn't quite true.  You've changed the mechanism by which the stubs
>> get mapped (from entirely common, to per-pcpu), removing the need for
>> the BUILD_BUG_ON().
>>
>> The ASSERT() in xen.lds.S serves a different purpose, checking that the
>> sum total of stubs don't overlap with the compiled code.  (On this
>> note... do we perform the same check for livepatches?  I can't spot
>> anything.)
> What you say may be true for the one that was in
> setup_cpu_root_pgt(), but surely not the one I'm removing from
> alloc_stub_page(). But I can drop this if you prefer.

I think it might avoid some confusion.

>
>>> What should we do with the TSS? Currently together with it we expose
>>> almost a full page of other per-CPU data. A simple (but slightly
>>> hackish) option would be to use one of the two unused stack slots.
>> In 64bit, the TSS can be mapped read-only, because hardware never has
>> cause to write to it.
>>
>> I believe that Linux now uses a read-only TSS mapping to double as a
>> guard page for the trampoline stack, which is a less hacky way of
>> thinking about it.
>>
>> However, doing that in Xen would mean shattering the directmap
>> superpages in all cases, and we'd inherit the SVM triple fault case into
>> release builds.  A different alternative (and perhaps simpler to
>> backport) might be to have .bss.percpu.page_aligned and use that to hide
>> the surrounding data.
> Well, yes, that's obviously an option, but pretty wasteful. I'd then
> be tempted to at least do some sharing of the page similar to how
> the stubs of several CPUs share a single page.

For backport to older releases?

I think the extra almost 4k per pcpu isn't going to concern people (its
the least of their problems right now), and there is a very tangible
benefit of not leaking the other surrounding data.

>
>> Thinking about it, we've got the same problem with the TSS as the BSP
>> IDT, if the link order happens to cause init_tss to cross a page boundary.
> I don't think so, no - the structure is 128 bytes in size and 128
> byte aligned. When I created the original XPTI light patch I did
> specifically check.

This only happens by chance, because sizeof(struct tss_struct) ==
SMP_CACHE_BYTES

If we intend to rely on this behaviour, we want something like this:

diff --git a/xen/include/asm-x86/processor.h
b/xen/include/asm-x86/processor.h
index 9c70a98..fe647dc 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -385,7 +385,7 @@ static always_inline void __mwait(unsigned long eax,
unsigned long ecx)
 #define IOBMP_BYTES 8192
 #define IOBMP_INVALID_OFFSET    0x8000
 
-struct __packed __cacheline_aligned tss_struct {
+struct __packed tss_struct {
 uint32_t :32;
 uint64_t rsp0, rsp1, rsp2;
 uint64_t :64;
@@ -398,7 +398,7 @@ struct __packed __cacheline_aligned tss_struct {
 uint16_t :16, bitmap;
 /* Pads the TSS to be cacheline-aligned (total size is 0x80). */
 uint8_t __cacheline_filler[24];
-};
+} __aligned(sizeof(struct tss_struct));
 
 #define IST_NONE 0UL
 #define IST_DF   1UL

except that C can't cope with this expression.  I wonder if there is an
alternate way with typedefs.

~Andrew

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

Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

[Jim Fehlig]

On 03/02/2018 05:40 AM, Wei Liu wrote:

On Fri, Mar 02, 2018 at 12:29:31PM +, Wei Liu wrote:

On Mon, Feb 26, 2018 at 09:53:38AM -0700, Jim Fehlig wrote:

On 02/26/2018 01:46 AM, Juergen Gross wrote:

When creating a pthread in xs_watch() try to get the minimal needed
size of the thread from glibc instead of using a constant. This avoids
problems when the library is used in programs with large per-thread
memory.

Use dlsym() to get the pointer to __pthread_get_minstack() in order to
avoid linkage problems and fall back to the current constant size if
not found.

Signed-off-by: Juergen Gross 
---
V2:
- use _GNU_SOURCE (Wei Liu)
- call __pthread_get_minstack() with parameter
- add -ldl to correct make flags
- ensure to not using smaller stack size than today
---
   tools/xenstore/Makefile |  4 
   tools/xenstore/xs.c | 21 -
   2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 2b99d2bc1b..0831be0b6f 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -100,6 +100,10 @@ libxenstore.so.$(MAJOR): libxenstore.so.$(MAJOR).$(MINOR)
ln -sf $< $@
   xs.opic: CFLAGS += -DUSE_PTHREAD
+ifeq ($(CONFIG_Linux),y)
+xs.opic: CFLAGS += -DUSE_DLSYM
+libxenstore.so.$(MAJOR).$(MINOR): LDFLAGS += -ldl
+endif


Dropping this patch in one of my automated builds caused a libxenstore link 
failure

[   99s] gcc-lsystemd -ldl -pthread -Wl,-soname -Wl,libxenstore.so.3.0
-shared -o libxenstore.so.3.0.3 xs.opic xs_lib.opic 
/home/abuild/rpmbuild/BUILD/xen-4.10.0-testing/tools/xenstore/../../tools/libs/toolcore/libxentoolcore.so

[   99s] 
/home/abuild/rpmbuild/BUILD/xen-4.10.0-testing/tools/xenstore/../../tools/xenstore/libxenstore.so:
undefined reference to `dlsym'

I hacked around it by appending '-ldl' to the end of the subsequent
libxenstore.so rule.


Hmm... Maybe I'm a bit dense today. I know the position of -l matters
but I don't quite understand how placing -pthread before xs.opic works
but -ldl doesn't. xs.c uses both after all.


I'm indeed very dense -- -pthread is a special option that sets the
proper flags for linking pthread library for both the preprocessor and
linker.

But still, Juergen must have tested the change, so I wonder why it
doesn't work in your setup. What is your build environment? Gcc version?


I dropped the patch in a package build on the openSUSE build service, where gcc7 
was used. But I don't see the problem when building from sources with gcc7. 
Apparently we have a bug in our package build, so ignore this comment. Tested-by 
still stands though :-).


Regards,
Jim

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

Re: [Xen-devel] Setting up a Xen x86 community call

[George Dunlap]

On 03/02/2018 03:39 PM, Lars Kurth wrote:
> Hi all, 
> (sorry for the extensive distribution list - I went through MAINTAINERS and 
> people who may have an interest)
> 
> I would like to start organizing a recurring x86 community call to discuss 
> and sync-up on upcoming features for Xen on x86. This call would mirror and 
> follow a similar structure to the ARM call (see 
> http://xen.markmail.org/thread/xqdxvqcjpf2y5ftu for the last one)
> 
> I expect that the call will contain
> 
> a) Coordination and Planning 
> Coordinating who does what, what needs attention, what is blocked, etc. 
> I would prepare a list of non-merged patch series of a certain size (e.g. 
> more than 5 patches) and attach to the invite
> If anything is missed, I would expect that these are sent to me before the 
> meeting
> 
> b) Design and architecture related discussions: in particular for bigger, 
> more complex items, ... 
> Although all of this could be done by email, in reality, we are all human and 
> many people find it easier to collaborate
> and communicate by talking to each other, rather than by email. This is not a 
> must, but an option to highlight issues
> 
> c) Demos, Sharing of Experiences, Sometimes discussion of specific 
> issues/bugs/problems/...
> This is something which happens frequently on the ARM call and seems to work 
> very well
> 
> I would suggest to start with a 1 hour monthly meeting: possibly every 2nd 
> Tue or Thu each month (depends on timing). I know that people are spread 
> across different timezones (from China to the US), so I would like to gather 
> thoughts before choosing a time. We may have to have alternating time-slots 
> every other month: but this is not ideal for some.
> 
> To do this, please
> * Raise your hands on whether you or your org would want to participate

o/

> * Provide your timezone

UTC

> * Provide a UTC time range when you can attend 

UTC 0900-1800

 -George

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 2157bc9c8b8be30ada11fe2e64454157d3ae528f
baseline version:
 ovmf f0c69b614cf56df1e7908574111d92864ca3ee9c

Last test of basis   120070  2018-02-27 16:23:11 Z3 days
Testing same since   120113  2018-03-01 02:36:47 Z1 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Bob Feng 
  BobCF 
  Dandan Bi 
  Feng, Bob C 
  Feng, YunhuaX 
  Jian J Wang 
  Kinney, Michael D 
  Michael D Kinney 
  Ruiyu Ni 
  Yonghong Zhu 
  Yunhua Feng 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   f0c69b614c..2157bc9c8b  2157bc9c8b8be30ada11fe2e64454157d3ae528f -> 
xen-tested-master

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

Re: [Xen-devel] Setting up a Xen x86 community call

[Juergen Gross]

On 02/03/18 16:39, Lars Kurth wrote:
> Hi all, 
> (sorry for the extensive distribution list - I went through MAINTAINERS and 
> people who may have an interest)
> 
> I would like to start organizing a recurring x86 community call to discuss 
> and sync-up on upcoming features for Xen on x86. This call would mirror and 
> follow a similar structure to the ARM call (see 
> http://xen.markmail.org/thread/xqdxvqcjpf2y5ftu for the last one)
> 
> I expect that the call will contain
> 
> a) Coordination and Planning 
> Coordinating who does what, what needs attention, what is blocked, etc. 
> I would prepare a list of non-merged patch series of a certain size (e.g. 
> more than 5 patches) and attach to the invite
> If anything is missed, I would expect that these are sent to me before the 
> meeting
> 
> b) Design and architecture related discussions: in particular for bigger, 
> more complex items, ... 
> Although all of this could be done by email, in reality, we are all human and 
> many people find it easier to collaborate
> and communicate by talking to each other, rather than by email. This is not a 
> must, but an option to highlight issues
> 
> c) Demos, Sharing of Experiences, Sometimes discussion of specific 
> issues/bugs/problems/...
> This is something which happens frequently on the ARM call and seems to work 
> very well
> 
> I would suggest to start with a 1 hour monthly meeting: possibly every 2nd 
> Tue or Thu each month (depends on timing). I know that people are spread 
> across different timezones (from China to the US), so I would like to gather 
> thoughts before choosing a time. We may have to have alternating time-slots 
> every other month: but this is not ideal for some.
> 
> To do this, please
> * Raise your hands on whether you or your org would want to participate

Raising hands

> * Provide your timezone

UTC+1

> * Provide a UTC time range when you can attend 

7am to 5pm


Juergen

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

Re: [Xen-devel] Setting up a Xen x86 community call

[Rich Persaud]

On Mar 2, 2018, at 10:39, Lars Kurth  wrote:
> I would suggest to start with a 1 hour monthly meeting: possibly every 2nd 
> Tue or Thu each month (depends on timing). I know that people are spread 
> across different timezones (from China to the US), so I would like to gather 
> thoughts before choosing a time. We may have to have alternating time-slots 
> every other month: but this is not ideal for some.
> 
> To do this, please
> * Raise your hands on whether you or your org would want to participate

I would like to participate.

> * Provide your timezone

US Eastern

> * Provide a UTC time range when you can attend 

I'll work with any time slot, since most attendees are in other timezones.  
Here's a color coded time chart for US central, UK, Europe, China:
https://www.timeanddate.com/worldclock/meetingtime.html?month=3=6=2018=24=136=37=33=0

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

Re: [Xen-devel] update_runstate_area and Linux KPTI

[Andrew Cooper]

On 02/03/18 17:05, Juergen Gross wrote:
> On 02/03/18 17:51, Jan Beulich wrote:
> On 02.03.18 at 17:25,  wrote:
>>> On 02/03/18 16:18, Jan Beulich wrote:
>>> On 02.03.18 at 17:04,  wrote:
> The proper way to do this is indeed by a nominated (guest) physical
> address, at which point Xen can make all/any updates at times of its
> choosing, and the guests pagetable/permissions state at an instantaneous
> moment don't matter.
>
> If you've got time to do this, then please do.  It will be a definite
> improvement.
 Just to be avoid unnecessary effort in the wrong direction: I don't
 think you can alter the current interface. You'd have to add a new
 one, and we could then deprecate (but never abandon) the current
 one.
>>> I was only planning to store the guest physical address rather than the 
>>> virtual address as we do today. Is that considered as an alteration of 
>>> the current interface?
>> Yes, it is, as an existing PV kernel could deliberately alter the
>> mappings underlying the linear address it has handed us.
> Linux pvops kernel isn't doing this. Mini-OS neither. I guess kernel-xen
> would be okay with this, too. And I bet BSD is also fine.
>
> Seriously: any kernel playing such tricks is asking for problems.
>
> We shouldn't support operation modes which make no sense just for the
> sake of compatibility, IMO.

I'd love to do this, but we cant.  Older Linux used to have a virtual
buffer spanning a page boundary.  Changing the behaviour under that will
cause older setups to explode.

~Andrew

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

Re: [Xen-devel] Setting up a Xen x86 community call

[Wei Liu]

On Fri, Mar 02, 2018 at 04:39:59PM +0100, Lars Kurth wrote:
> Hi all, 
> (sorry for the extensive distribution list - I went through MAINTAINERS and 
> people who may have an interest)
> 
> I would like to start organizing a recurring x86 community call to discuss 
> and sync-up on upcoming features for Xen on x86. This call would mirror and 
> follow a similar structure to the ARM call (see 
> http://xen.markmail.org/thread/xqdxvqcjpf2y5ftu for the last one)
> 
> I expect that the call will contain
> 
> a) Coordination and Planning 
> Coordinating who does what, what needs attention, what is blocked, etc. 
> I would prepare a list of non-merged patch series of a certain size (e.g. 
> more than 5 patches) and attach to the invite
> If anything is missed, I would expect that these are sent to me before the 
> meeting
> 
> b) Design and architecture related discussions: in particular for bigger, 
> more complex items, ... 
> Although all of this could be done by email, in reality, we are all human and 
> many people find it easier to collaborate
> and communicate by talking to each other, rather than by email. This is not a 
> must, but an option to highlight issues
> 
> c) Demos, Sharing of Experiences, Sometimes discussion of specific 
> issues/bugs/problems/...
> This is something which happens frequently on the ARM call and seems to work 
> very well
> 
> I would suggest to start with a 1 hour monthly meeting: possibly every 2nd 
> Tue or Thu each month (depends on timing). I know that people are spread 
> across different timezones (from China to the US), so I would like to gather 
> thoughts before choosing a time. We may have to have alternating time-slots 
> every other month: but this is not ideal for some.
> 
> To do this, please
> * Raise your hands on whether you or your org would want to participate

I want to participate.

> * Provide your timezone

UTC.

> * Provide a UTC time range when you can attend 

9am to 6pm.

Wei.

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

Re: [Xen-devel] update_runstate_area and Linux KPTI

[Juergen Gross]

On 02/03/18 17:51, Jan Beulich wrote:
 On 02.03.18 at 17:25,  wrote:
>> On 02/03/18 16:18, Jan Beulich wrote:
>> On 02.03.18 at 17:04,  wrote:
 The proper way to do this is indeed by a nominated (guest) physical
 address, at which point Xen can make all/any updates at times of its
 choosing, and the guests pagetable/permissions state at an instantaneous
 moment don't matter.

 If you've got time to do this, then please do.  It will be a definite
 improvement.
>>>
>>> Just to be avoid unnecessary effort in the wrong direction: I don't
>>> think you can alter the current interface. You'd have to add a new
>>> one, and we could then deprecate (but never abandon) the current
>>> one.
>>
>> I was only planning to store the guest physical address rather than the 
>> virtual address as we do today. Is that considered as an alteration of 
>> the current interface?
> 
> Yes, it is, as an existing PV kernel could deliberately alter the
> mappings underlying the linear address it has handed us.

Linux pvops kernel isn't doing this. Mini-OS neither. I guess kernel-xen
would be okay with this, too. And I bet BSD is also fine.

Seriously: any kernel playing such tricks is asking for problems.

We shouldn't support operation modes which make no sense just for the
sake of compatibility, IMO.


Juergen

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

Re: [Xen-devel] [PATCH v2 1/2] x86/xpti: really hide almost all of Xen image

[Jan Beulich]

>>> On 02.03.18 at 17:53,  wrote:
> On 02/03/18 14:34, Jan Beulich wrote:
>> Note that the removed BUILD_BUG_ON()s don't get replaced by anything -
>> there already is a suitable ASSERT() in xen.lds.S.
> 
> This isn't quite true.  You've changed the mechanism by which the stubs
> get mapped (from entirely common, to per-pcpu), removing the need for
> the BUILD_BUG_ON().
> 
> The ASSERT() in xen.lds.S serves a different purpose, checking that the
> sum total of stubs don't overlap with the compiled code.  (On this
> note... do we perform the same check for livepatches?  I can't spot
> anything.)

What you say may be true for the one that was in
setup_cpu_root_pgt(), but surely not the one I'm removing from
alloc_stub_page(). But I can drop this if you prefer.

>> What should we do with the TSS? Currently together with it we expose
>> almost a full page of other per-CPU data. A simple (but slightly
>> hackish) option would be to use one of the two unused stack slots.
> 
> In 64bit, the TSS can be mapped read-only, because hardware never has
> cause to write to it.
> 
> I believe that Linux now uses a read-only TSS mapping to double as a
> guard page for the trampoline stack, which is a less hacky way of
> thinking about it.
> 
> However, doing that in Xen would mean shattering the directmap
> superpages in all cases, and we'd inherit the SVM triple fault case into
> release builds.  A different alternative (and perhaps simpler to
> backport) might be to have .bss.percpu.page_aligned and use that to hide
> the surrounding data.

Well, yes, that's obviously an option, but pretty wasteful. I'd then
be tempted to at least do some sharing of the page similar to how
the stubs of several CPUs share a single page.

> Thinking about it, we've got the same problem with the TSS as the BSP
> IDT, if the link order happens to cause init_tss to cross a page boundary.

I don't think so, no - the structure is 128 bytes in size and 128
byte aligned. When I created the original XPTI light patch I did
specifically check.

Jan


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

Re: [Xen-devel] [PATCH v2] x86: invpcid support

[Wei Liu]

On Fri, Mar 02, 2018 at 09:47:45AM -0700, Jan Beulich wrote:
> >>> On 02.03.18 at 17:23,  wrote:
> > +static inline void invpcid(unsigned int pcid, unsigned long addr,
> > +   unsigned int type)
> > +{
> > +struct {
> > +uint64_t pcid:12;
> > +uint64_t reserved:52;
> > +uint64_t addr;
> > +} desc = { .pcid = pcid, .addr = addr };
> > +
> > +asm volatile (
> > +#ifdef HAVE_AS_INVPCID
> > +  "invpcid %[desc], %q[type]"
> > +  : /* No output */
> > +  : [desc] "m" (desc), [type] "r" (type)
> > +#else
> > +  INVPCID_OPCODE MODRM_ECX_01
> > +  : /* No output */
> > +  : "a" (type), "c" ()
> > +#endif
> > +  : "memory" );
> 
> I can see why you need the memory clobber in the #else case
> (albeit even there it could be avoided by also properly specifying
> the input), but what is this good for in the #if case?

It is the same as why writing to CR3 requires a memory clobber. It is
flushing TLB.

Wei.

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

Re: [Xen-devel] [PATCH v2] x86: invpcid support

[Andrew Cooper]

On 02/03/18 16:47, Jan Beulich wrote:
 On 02.03.18 at 17:23,  wrote:
>> +static inline void invpcid(unsigned int pcid, unsigned long addr,
>> +   unsigned int type)
>> +{
>> +struct {
>> +uint64_t pcid:12;
>> +uint64_t reserved:52;
>> +uint64_t addr;
>> +} desc = { .pcid = pcid, .addr = addr };
>> +
>> +asm volatile (
>> +#ifdef HAVE_AS_INVPCID
>> +  "invpcid %[desc], %q[type]"
>> +  : /* No output */
>> +  : [desc] "m" (desc), [type] "r" (type)
>> +#else
>> +  INVPCID_OPCODE MODRM_ECX_01
>> +  : /* No output */
>> +  : "a" (type), "c" ()
>> +#endif
>> +  : "memory" );
> I can see why you need the memory clobber in the #else case
> (albeit even there it could be avoided by also properly specifying
> the input), but what is this good for in the #if case?

This is a tlb flush operation.  I don't think anything good will come
from having other operations reordered around it.

~Andrew

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

Re: [Xen-devel] Setting up a Xen x86 community call

[Andrew Cooper]

On 02/03/18 15:39, Lars Kurth wrote:
> Hi all, 
> (sorry for the extensive distribution list - I went through MAINTAINERS and 
> people who may have an interest)
>
> I would like to start organizing a recurring x86 community call to discuss 
> and sync-up on upcoming features for Xen on x86. This call would mirror and 
> follow a similar structure to the ARM call (see 
> http://xen.markmail.org/thread/xqdxvqcjpf2y5ftu for the last one)
>
> I expect that the call will contain
>
> a) Coordination and Planning 
> Coordinating who does what, what needs attention, what is blocked, etc. 
> I would prepare a list of non-merged patch series of a certain size (e.g. 
> more than 5 patches) and attach to the invite
> If anything is missed, I would expect that these are sent to me before the 
> meeting
>
> b) Design and architecture related discussions: in particular for bigger, 
> more complex items, ... 
> Although all of this could be done by email, in reality, we are all human and 
> many people find it easier to collaborate
> and communicate by talking to each other, rather than by email. This is not a 
> must, but an option to highlight issues
>
> c) Demos, Sharing of Experiences, Sometimes discussion of specific 
> issues/bugs/problems/...
> This is something which happens frequently on the ARM call and seems to work 
> very well
>
> I would suggest to start with a 1 hour monthly meeting: possibly every 2nd 
> Tue or Thu each month (depends on timing). I know that people are spread 
> across different timezones (from China to the US), so I would like to gather 
> thoughts before choosing a time. We may have to have alternating time-slots 
> every other month: but this is not ideal for some.
>
> To do this, please
> * Raise your hands on whether you or your org would want to participate

/me waves

> * Provide your timezone

UTC

> * Provide a UTC time range when you can attend 

10am - 5pm ideally.

~Andrew

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

Re: [Xen-devel] [PATCH] x86: rename HAVE_GAS_* to HAVE_AS_*

[Roger Pau Monné]

On Fri, Mar 02, 2018 at 04:46:25PM +, Wei Liu wrote:
> Xen also uses clang's assembler when it is possible. Change the macro
> names to not be GAS specific.
> 
> Patch produced with:
> 
> $ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \
> do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done

grep -Rl HAVE_GAS_ xen/ | xargs sed...

Seems simpler :) (but I have not tried it).

> 
> Signed-off-by: Wei Liu 

Thanks!

Reviewed-by: Roger Pau Monné 

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

Re: [Xen-devel] update_runstate_area and Linux KPTI

[Juergen Gross]

On 02/03/18 17:25, Julien Grall wrote:
> 
> 
> On 02/03/18 16:18, Jan Beulich wrote:
> On 02.03.18 at 17:04,  wrote:
>>> The proper way to do this is indeed by a nominated (guest) physical
>>> address, at which point Xen can make all/any updates at times of its
>>> choosing, and the guests pagetable/permissions state at an instantaneous
>>> moment don't matter.
>>>
>>> If you've got time to do this, then please do.  It will be a definite
>>> improvement.
>>
>> Just to be avoid unnecessary effort in the wrong direction: I don't
>> think you can alter the current interface. You'd have to add a new
>> one, and we could then deprecate (but never abandon) the current
>> one.
> 
> I was only planning to store the guest physical address rather than the
> virtual address as we do today. Is that considered as an alteration of
> the current interface?

I don't think so. It should be perfectly fine to assume the mapping of
the registered virtual address isn't changed by the guest.

> In other words, the current version (e.g store virtual address) is just
> broken and going to be worst with KPTI kernel. I can't see how this
> could ever work properly on OS with different set of page-tables.

map_vcpu_info() seems to be a nice example how this should be done.
This should make update_runstate_area() simpler and faster.


Juergen

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

Re: [Xen-devel] Setting up a Xen x86 community call

[Paul Durrant]

> -Original Message-
> From: Lars Kurth [mailto:lars.kurth@gmail.com]
> Sent: 02 March 2018 15:40
> To: xen-devel 
> Cc: committ...@xenproject.org; Jan Beulich ; Andrew
> Cooper ; Susie Li ; John Ji
> ; Hurwitz, Sherry ; Brian
> Woods ; Babu Moger ;
> Chao Peng ; daniel.ki...@oracle.com;
> joao.m.mart...@oracle.com; boris.ostrov...@oracle.com; Rich Persaud
> ; Kevin Tian ; Razvan Cojocaru
> ; ta...@tklengyel.com; Paul Durrant
> ; Roger Pau Monné 
> Subject: Setting up a Xen x86 community call
> 
> Hi all,
> (sorry for the extensive distribution list - I went through MAINTAINERS and
> people who may have an interest)
> 
> I would like to start organizing a recurring x86 community call to discuss and
> sync-up on upcoming features for Xen on x86. This call would mirror and
> follow a similar structure to the ARM call (see
> http://xen.markmail.org/thread/xqdxvqcjpf2y5ftu for the last one)
> 
> I expect that the call will contain
> 
> a) Coordination and Planning
> Coordinating who does what, what needs attention, what is blocked, etc.
> I would prepare a list of non-merged patch series of a certain size (e.g. more
> than 5 patches) and attach to the invite
> If anything is missed, I would expect that these are sent to me before the
> meeting
> 
> b) Design and architecture related discussions: in particular for bigger, more
> complex items, ...
> Although all of this could be done by email, in reality, we are all human and
> many people find it easier to collaborate
> and communicate by talking to each other, rather than by email. This is not a
> must, but an option to highlight issues
> 
> c) Demos, Sharing of Experiences, Sometimes discussion of specific
> issues/bugs/problems/...
> This is something which happens frequently on the ARM call and seems to
> work very well
> 
> I would suggest to start with a 1 hour monthly meeting: possibly every 2nd
> Tue or Thu each month (depends on timing). I know that people are spread
> across different timezones (from China to the US), so I would like to gather
> thoughts before choosing a time. We may have to have alternating time-slots
> every other month: but this is not ideal for some.
> 
> To do this, please
> * Raise your hands on whether you or your org would want to participate

I would like to participate.

> * Provide your timezone

GMT

> * Provide a UTC time range when you can attend
> 

10am - 5pm

Cheers,

  Pail

> Your sincerely,
> Lars
> 


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

[Xen-devel] osstest planned outage consultation

[Ian Jackson]

Several of the VMs in the Massachusetts Xen Project Test Lab, which
runs our community osstest instance, need to be upgraded.  And we want
to sort out some oddities with the way the storage is configured.

This will involve a long outage, maybe 3 days or so.

We should schedule this when it is convenient for everyone.  Right now
is not convenient because we have the BTI patches which are stuck in
various staging-NN branches and which need to be fixed and pushed to
stable-NN and released.

Also people may be away at various times.

If you have opinions about this please reply to this mail, to me and
to Lars.

Ian.

(For our reference, this relates to tickets 104771 102951)

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

Re: [Xen-devel] [PATCH] x86: rename HAVE_GAS_* to HAVE_AS_*

[Andrew Cooper]

On 02/03/18 16:46, Wei Liu wrote:
> Xen also uses clang's assembler when it is possible. Change the macro
> names to not be GAS specific.
>
> Patch produced with:
>
> $ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \
> do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done

andrewcoop@andrewcoop:/local/xen.git/xen$ git help refactor
`git refactor' is aliased to `!sh -c 'git grep -l "$1" -- $GIT_PREFIX |
xargs sed "s|$1|$2|g" -i' -'

One of my most useful git aliases :)

>
> Signed-off-by: Wei Liu 

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 1/2] x86/xpti: really hide almost all of Xen image

[Andrew Cooper]

On 02/03/18 14:34, Jan Beulich wrote:
> Commit 422588e885 ("x86/xpti: Hide almost all of .text and all
> .data/.rodata/.bss mappings") carefully limited the Xen image cloning to
> just entry code, but then overwrote the just allocated and populated L3
> entry with the normal one again covering both Xen image and stubs.

Some version of this patch definitely worked correctly, but it is clear
that this version doesn't.  Sorry :(

>
> Drop the respective code in favor of an explicit clone_mapping()
> invocation. This in turn now requires setup_cpu_root_pgt() to run after
> stub setup in all cases. Additionally, with (almost) no unintended
> mappings left, the BSP's IDT now also needs to be page aligned.
>
> Note that the removed BUILD_BUG_ON()s don't get replaced by anything -
> there already is a suitable ASSERT() in xen.lds.S.

This isn't quite true.  You've changed the mechanism by which the stubs
get mapped (from entirely common, to per-pcpu), removing the need for
the BUILD_BUG_ON().

The ASSERT() in xen.lds.S serves a different purpose, checking that the
sum total of stubs don't overlap with the compiled code.  (On this
note... do we perform the same check for livepatches?  I can't spot
anything.)

>
> The moving ahead of cleanup_cpu_root_pgt() is not strictly necessary
> for functionality, but things are more logical this way, and we retain
> cleanup being done in the inverse order of setup.
>
> Signed-off-by: Jan Beulich 
> ---
> v2: Add missing cleanup of the stub mapping.
> ---
> What should we do with the TSS? Currently together with it we expose
> almost a full page of other per-CPU data. A simple (but slightly
> hackish) option would be to use one of the two unused stack slots.

In 64bit, the TSS can be mapped read-only, because hardware never has
cause to write to it.

I believe that Linux now uses a read-only TSS mapping to double as a
guard page for the trampoline stack, which is a less hacky way of
thinking about it.

However, doing that in Xen would mean shattering the directmap
superpages in all cases, and we'd inherit the SVM triple fault case into
release builds.  A different alternative (and perhaps simpler to
backport) might be to have .bss.percpu.page_aligned and use that to hide
the surrounding data.

Thinking about it, we've got the same problem with the TSS as the BSP
IDT, if the link order happens to cause init_tss to cross a page boundary.

~Andrew

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

Re: [Xen-devel] [PATCH] x86: rename HAVE_GAS_* to HAVE_AS_*

[Jan Beulich]

>>> On 02.03.18 at 17:46,  wrote:
> Xen also uses clang's assembler when it is possible. Change the macro
> names to not be GAS specific.
> 
> Patch produced with:
> 
> $ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \
> do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] update_runstate_area and Linux KPTI

[Jan Beulich]

>>> On 02.03.18 at 17:25,  wrote:
> On 02/03/18 16:18, Jan Beulich wrote:
> On 02.03.18 at 17:04,  wrote:
>>> The proper way to do this is indeed by a nominated (guest) physical
>>> address, at which point Xen can make all/any updates at times of its
>>> choosing, and the guests pagetable/permissions state at an instantaneous
>>> moment don't matter.
>>>
>>> If you've got time to do this, then please do.  It will be a definite
>>> improvement.
>> 
>> Just to be avoid unnecessary effort in the wrong direction: I don't
>> think you can alter the current interface. You'd have to add a new
>> one, and we could then deprecate (but never abandon) the current
>> one.
> 
> I was only planning to store the guest physical address rather than the 
> virtual address as we do today. Is that considered as an alteration of 
> the current interface?

Yes, it is, as an existing PV kernel could deliberately alter the
mappings underlying the linear address it has handed us.

Jan


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

Re: [Xen-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

[Oleksandr Andrushchenko]

Any chance ALSA community may also review the below?

BTW, the driver, with the changes proposed, is at [1]

Thank you,

Oleksandr

On 02/05/2018 10:24 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Hi, all!

Foreword


This change is aimed to add support for explicit back and front
synchronization during playback and capture in response to comments
raised during upstream attempt of the para-virtualized sound frontend
driver for Xen [1], [2] and gather opinions from the relevant communities
(ALSA, Xen) on the change.

The relevant backend is implemented as a user-space application [3]
and uses accompanying helper library [4].

Both frontend driver and backend were tested on real HW running Xen hypervisor
(Renesas R-Car ARM based H3/M3 boards, x86) to make sure the proposed
solution does work.

Rationale
=

During the first attempt to upstream the Linux front driver [5] number
of comments and concerns were raised, one of the biggest flaws in the
design were questioned by both Clemens Ladisch [6] and
Takashi Sakamoto [7]: the absence of synchronization between frontend
and backend during capture/playback. Two options were discussed:

“In design of ALSA PCM core, drivers are expected to synchronize to
actual hardwares for semi-realtime data transmission. The
synchronization is done by two points:
1) Interrupts to respond events from actual hardwares.
2) Positions of actual data transmission in any serial sound interfaces
 of actual hardwares.
“

and finally a change to the existing protocol was suggested:

“In 'include/xen/interface/io/sndif.h', there's no functionalities I
described the above:
1. notifications from DomU to Dom0 about the size of period for
 interrupts from actual hardwares. Or no way from Dom0 to DomU about
 the configured size of the period.
2. notifications of the interrupts from actual hardwares to DomU.”

This is implemented as a change to the sndif protocol and allows removing
period emulation:
1. Introduced a new event channel from back to front
2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS,
to be used for sending snd_pcm_period_elapsed at frontend (in Linux
implementation). Sent in bytes, not frames to make the protocol
generic and consistent)
3. New request for playback/capture control (XENSND_OP_TRIGGER) with
start/pause/stop/resume sub-ops
4. Playback/capture buffer size is set on the backend side via
XENSND_FIELD_BUFFER_SIZE XenStore entry

Waiting for your valuable comments,

Thank you,
Oleksandr

[1] https://github.com/andr2000/linux/commits/snd_upstream_v1
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h
[3] https://github.com/xen-troops/snd_be
[4] https://github.com/xen-troops/libxenbe
[5] https://lkml.org/lkml/2017/8/7/363
[6] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html
[7] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html


Oleksandr Andrushchenko (2):
   sndif: introduce protocol version
   sndif: add explicit back and front synchronization

  xen/include/public/io/sndif.h | 173 +-
  1 file changed, 170 insertions(+), 3 deletions(-)

[1] 
https://github.com/andr2000/linux/commits/tiwai_sound_for_next_pv_snd_upstream_v1


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

Re: [Xen-devel] [PATCH v2 2/2] x86/xpti: don't map stack guard pages

[Jan Beulich]

>>> On 02.03.18 at 17:41,  wrote:
> On 02/03/18 17:10, Jan Beulich wrote:
> On 02.03.18 at 16:43,  wrote:
>>> On 02/03/18 15:35, Jan Beulich wrote:
 --- a/xen/arch/x86/mm.c
 +++ b/xen/arch/x86/mm.c
 @@ -5576,6 +5576,14 @@ void memguard_unguard_stack(void *p)
 STACK_SIZE - PRIMARY_STACK_SIZE - IST_MAX * 
 PAGE_SIZE);
  }
  
 +bool memguard_is_stack_guard_page(unsigned long addr)
 +{
 +addr &= STACK_SIZE - 1;
 +
 +return addr >= IST_MAX * PAGE_SIZE &&
 +   addr < STACK_SIZE - PRIMARY_STACK_SIZE;
 +}
 +
>>>
>>> What about making use of memguard_is_stack_guard_page() in
>>> memguard_[un]guard_stack() ?
>> 
>> I was considering this as a follow-up step.
>> 
>>> This would at once ensure the other unused
>>> pages won't be accessed accidentally somewhere.
>> 
>> I don't understand this part, though.
> 
> Today memguard_guard_stack() touches only one of the unused pages, not
> all of them.

That was earlier today, but not anymore at the time I sent this
patch.

Jan


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

Re: [Xen-devel] [PATCH v2] x86: invpcid support

[Jan Beulich]

>>> On 02.03.18 at 17:23,  wrote:
> +static inline void invpcid(unsigned int pcid, unsigned long addr,
> +   unsigned int type)
> +{
> +struct {
> +uint64_t pcid:12;
> +uint64_t reserved:52;
> +uint64_t addr;
> +} desc = { .pcid = pcid, .addr = addr };
> +
> +asm volatile (
> +#ifdef HAVE_AS_INVPCID
> +  "invpcid %[desc], %q[type]"
> +  : /* No output */
> +  : [desc] "m" (desc), [type] "r" (type)
> +#else
> +  INVPCID_OPCODE MODRM_ECX_01
> +  : /* No output */
> +  : "a" (type), "c" ()
> +#endif
> +  : "memory" );

I can see why you need the memory clobber in the #else case
(albeit even there it could be avoided by also properly specifying
the input), but what is this good for in the #if case?

Jan


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

[Xen-devel] [PATCH] x86: rename HAVE_GAS_* to HAVE_AS_*

[Wei Liu]

Xen also uses clang's assembler when it is possible. Change the macro
names to not be GAS specific.

Patch produced with:

$ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \
do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/Rules.mk  | 14 +++---
 xen/arch/x86/x86_emulate/x86_emulate.c |  6 +++---
 xen/include/asm-x86/asm_defns.h|  4 ++--
 xen/include/asm-x86/hvm/vmx/vmx.h  | 26 +-
 xen/include/asm-x86/msr.h  |  8 
 5 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index acec5ce92a..a29ab22d36 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -14,14 +14,14 @@ CFLAGS += -msoft-float
 
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 $(call cc-option-add,CFLAGS,CC,-Wnested-externs)
-$(call as-option-add,CFLAGS,CC,"vmcall",-DHAVE_GAS_VMX)
-$(call as-option-add,CFLAGS,CC,"crc32 %eax$$(comma)%eax",-DHAVE_GAS_SSE4_2)
-$(call as-option-add,CFLAGS,CC,"invept (%rax)$$(comma)%rax",-DHAVE_GAS_EPT)
-$(call as-option-add,CFLAGS,CC,"rdrand %eax",-DHAVE_GAS_RDRAND)
-$(call as-option-add,CFLAGS,CC,"rdfsbase %rax",-DHAVE_GAS_FSGSBASE)
-$(call as-option-add,CFLAGS,CC,"rdseed %eax",-DHAVE_GAS_RDSEED)
+$(call as-option-add,CFLAGS,CC,"vmcall",-DHAVE_AS_VMX)
+$(call as-option-add,CFLAGS,CC,"crc32 %eax$$(comma)%eax",-DHAVE_AS_SSE4_2)
+$(call as-option-add,CFLAGS,CC,"invept (%rax)$$(comma)%rax",-DHAVE_AS_EPT)
+$(call as-option-add,CFLAGS,CC,"rdrand %eax",-DHAVE_AS_RDRAND)
+$(call as-option-add,CFLAGS,CC,"rdfsbase %rax",-DHAVE_AS_FSGSBASE)
+$(call as-option-add,CFLAGS,CC,"rdseed %eax",-DHAVE_AS_RDSEED)
 $(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
- -U__OBJECT_LABEL__ -DHAVE_GAS_QUOTED_SYM \
+ -U__OBJECT_LABEL__ -DHAVE_AS_QUOTED_SYM \
  '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$$@')
 $(call as-option-add,CFLAGS,CC,"invpcid (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
 
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index f02ce2cab4..02c79914dd 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6688,7 +6688,7 @@ x86_emulate(
 goto unrecognized_insn;
 
 case 6: /* rdrand */
-#ifdef HAVE_GAS_RDRAND
+#ifdef HAVE_AS_RDRAND
 generate_exception_if(rep_prefix(), EXC_UD);
 host_and_vcpu_must_have(rdrand);
 dst = ea;
@@ -6731,7 +6731,7 @@ x86_emulate(
 dst.bytes = 4;
 break;
 }
-#ifdef HAVE_GAS_RDSEED
+#ifdef HAVE_AS_RDSEED
 generate_exception_if(rep_prefix(), EXC_UD);
 host_and_vcpu_must_have(rdseed);
 dst = ea;
@@ -7311,7 +7311,7 @@ x86_emulate(
 ASSERT_UNREACHABLE();
 }
 break;
-#ifdef HAVE_GAS_SSE4_2
+#ifdef HAVE_AS_SSE4_2
 case X86EMUL_OPC_F2(0x0f38, 0xf0): /* crc32 r/m8, r{32,64} */
 case X86EMUL_OPC_F2(0x0f38, 0xf1): /* crc32 r/m{16,32,64}, r{32,64} */
 host_and_vcpu_must_have(sse4_2);
diff --git a/xen/include/asm-x86/asm_defns.h b/xen/include/asm-x86/asm_defns.h
index ebd2c88a1f..24a269c546 100644
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -71,7 +71,7 @@ void ret_from_intr(void);
 
 #ifdef __ASSEMBLY__
 
-#ifdef HAVE_GAS_QUOTED_SYM
+#ifdef HAVE_AS_QUOTED_SYM
 #define SUBSECTION_LBL(tag)\
 .ifndef .L.tag;\
 .equ .L.tag, 1;\
@@ -152,7 +152,7 @@ void ret_from_intr(void);
 
 #else
 
-#ifdef HAVE_GAS_QUOTED_SYM
+#ifdef HAVE_AS_QUOTED_SYM
 #define SUBSECTION_LBL(tag)  \
 ".ifndef .L." #tag "\n\t"\
 ".equ .L." #tag ", 1\n\t"\
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index af1f82d244..af6fe7c9a4 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -311,7 +311,7 @@ extern uint8_t posted_intr_vector;
 #define INVVPID_ALL_CONTEXT 2
 #define INVVPID_SINGLE_CONTEXT_RETAINING_GLOBAL 3
 
-#ifdef HAVE_GAS_VMX
+#ifdef HAVE_AS_VMX
 # define GAS_VMX_OP(yes, no) yes
 #else
 # define GAS_VMX_OP(yes, no) no
@@ -320,7 +320,7 @@ extern uint8_t posted_intr_vector;
 static always_inline void __vmptrld(u64 addr)
 {
 asm volatile (
-#ifdef HAVE_GAS_VMX
+#ifdef HAVE_AS_VMX
"vmptrld %0\n"
 #else
VMPTRLD_OPCODE MODRM_EAX_06
@@ -330,7 +330,7 @@ static always_inline void __vmptrld(u64 addr)
_ASM_BUGFRAME_TEXT(0)

Re: [Xen-devel] [PATCH v2 3/5] x86/pv: Introduce pv_create_exception_frame()

[Jan Beulich]

>>> On 27.02.18 at 15:50,  wrote:
> v2:
>  * Use domain_crash() rather than domain_crash_sync().  All callers
>immediately continue to {compat_}test_all_events
>  * Count the number of frame[] entries correctly
>  * Consistently use 64bit operations when adjusting the root frame
>  * Introduce a compat_addr_ok() check for the 32bit side.  The ASM version
>didn't have protection attempting to write into the compat p2m, other than
>hitting a #PF while trying.

I'm not sure I see the value of the extra check - we've got to handle
#PF anyway. But I also won't insist on dropping it again.

> +void pv_create_exception_frame(void)
> +{
> +struct vcpu *curr = current;
> +struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
> +struct cpu_user_regs *regs = guest_cpu_user_regs();
> +const bool user_mode_frame = !guest_kernel_mode(curr, regs);
> +uint8_t *evt_mask = _info(curr, evtchn_upcall_mask);
> +unsigned int flags, bytes, missing;
> +
> +ASSERT_NOT_IN_ATOMIC();
> +
> +if ( unlikely(null_trap_bounce(curr, tb)) )
> +{
> +gprintk(XENLOG_ERR, "Fatal: Attempting to inject null trap 
> bounce\n");
> +domain_crash(curr->domain);
> +return;
> +}
> +
> +/* Fold the upcall mask and architectural IOPL into the guests rflags. */
> +flags  = regs->rflags & ~(X86_EFLAGS_IF | X86_EFLAGS_IOPL);

regs->eflags would be more consistent with the type of flags.

> +flags |= ((*evt_mask ? 0 : X86_EFLAGS_IF) |
> +  (VM_ASSIST(curr->domain, architectural_iopl)
> +   ? curr->arch.pv_vcpu.iopl : 0));
> +
> +if ( is_pv_32bit_vcpu(curr) )
> +{
> +/* { [ERRCODE,] EIP, CS/MASK , EFLAGS, [ESP, SS] } */
> +unsigned int frame[6], *ptr = frame, ksp =
> +(user_mode_frame ? curr->arch.pv_vcpu.kernel_sp : regs->esp);
> +
> +if ( tb->flags & TBF_EXCEPTION_ERRCODE )
> +*ptr++ = tb->error_code;
> +
> +*ptr++ = regs->eip;
> +*ptr++ = regs->cs | ((unsigned int)*evt_mask << 16);
> +*ptr++ = flags;
> +
> +if ( user_mode_frame )
> +{
> +*ptr++ = regs->esp;
> +*ptr++ = regs->ss;
> +}
> +
> +/* Copy the constructed frame to the guest kernel stack. */
> +bytes = _p(ptr) - _p(frame);
> +ksp -= bytes;
> +
> +if ( unlikely(!__compat_access_ok(curr->domain, ksp, bytes)) )
> +{
> +gprintk(XENLOG_ERR, "Fatal: Bad guest kernel stack %p\n", 
> _p(ksp));

While I understand that you don't want to deal with non-flat SS here
(yet), I think it would be prudent to log %ss nevertheless.

> +domain_crash(curr->domain);
> +return;
> +}
> +
> +if ( unlikely((missing = __copy_to_user(_p(ksp), frame, bytes)) != 
> 0) )
> +{
> +gprintk(XENLOG_ERR, "Fatal: Fault while writing exception 
> frame\n");
> +show_page_walk(ksp + missing);

"missing" is the right name, but the use is wrong - ITYM
"ksp + bytes - missing" (same on the 64-bit path then).

If you agree with (and have carried out) the suggested changes
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v2 2/2] x86/xpti: don't map stack guard pages

[Juergen Gross]

On 02/03/18 17:10, Jan Beulich wrote:
 On 02.03.18 at 16:43,  wrote:
>> On 02/03/18 15:35, Jan Beulich wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -5576,6 +5576,14 @@ void memguard_unguard_stack(void *p)
>>> STACK_SIZE - PRIMARY_STACK_SIZE - IST_MAX * 
>>> PAGE_SIZE);
>>>  }
>>>  
>>> +bool memguard_is_stack_guard_page(unsigned long addr)
>>> +{
>>> +addr &= STACK_SIZE - 1;
>>> +
>>> +return addr >= IST_MAX * PAGE_SIZE &&
>>> +   addr < STACK_SIZE - PRIMARY_STACK_SIZE;
>>> +}
>>> +
>>
>> What about making use of memguard_is_stack_guard_page() in
>> memguard_[un]guard_stack() ?
> 
> I was considering this as a follow-up step.
> 
>> This would at once ensure the other unused
>> pages won't be accessed accidentally somewhere.
> 
> I don't understand this part, though.

Today memguard_guard_stack() touches only one of the unused pages, not
all of them.


Juergen

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

Re: [Xen-devel] [RFC PATCH 31/49] ARM: new VGIC: Add PENDING registers handlers

[Andre Przywara]

Hi,

On 19/02/18 15:43, Julien Grall wrote:
> 
> 
> On 19/02/18 15:32, Andre Przywara wrote:
>> Hi,
> 
> Hi Andre,
> 
>> On 16/02/18 17:16, Julien Grall wrote:
>>> On 09/02/18 14:39, Andre Przywara wrote:
 +
 +    /* Loop over all IRQs affected by this read */
 +    for ( i = 0; i < len * 8; i++ )
 +    {
 +    struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid
 + i);
 +
 +    if ( irq_is_pending(irq) )
 +    value |= (1U << i);
>>>
>>> Don't you need to propagate the value to the hardware for virtual
>>> interrupt mapped to physical interrupt?
>>
>> Do you mean in the write functions below? (This is the read function, I
>> don't see how this would apply here.)
> 
> Hmmm yes. Sorry I misplaced the comment.
> 
>>
>> In case you meant the write_[cs]pending() functions:
>> I don't think this makes too much sense. Why would you want to trigger
>> an hardware IRQ? All you want it is to deliver it to the guest, which is
>> what those functions below do. So what do I miss here?
> 
> Imagine you clear the pending bit on an hardware mapped interrupt. If
> you never clear the active bit on the physical one, you will never
> receive that interrupt again.
> 
> For setting pending bit, I am not entirely sure. But it looks like KVM
> is doing it (see latest master). So I am wondering why Xen is diverging
> here.

The simple reason is that "latest master" was something different when I
imported the VGIC, obviously. So this was a later addition. I now ported
this new patch over, though due to the locking order of the desc lock
this isn't so pretty (but still not too bad). But actually this function
should be extremely rare, up to the point that I currently cannot test
this easily.

Cheers,
Andre.

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

Re: [Xen-devel] Setting up a Xen x86 community call

[Roger Pau Monné]

On Fri, Mar 02, 2018 at 04:39:59PM +0100, Lars Kurth wrote:
> Hi all, 
> (sorry for the extensive distribution list - I went through MAINTAINERS and 
> people who may have an interest)
> 
> I would like to start organizing a recurring x86 community call to discuss 
> and sync-up on upcoming features for Xen on x86. This call would mirror and 
> follow a similar structure to the ARM call (see 
> http://xen.markmail.org/thread/xqdxvqcjpf2y5ftu for the last one)
> 
> I expect that the call will contain
> 
> a) Coordination and Planning 
> Coordinating who does what, what needs attention, what is blocked, etc. 
> I would prepare a list of non-merged patch series of a certain size (e.g. 
> more than 5 patches) and attach to the invite
> If anything is missed, I would expect that these are sent to me before the 
> meeting
> 
> b) Design and architecture related discussions: in particular for bigger, 
> more complex items, ... 
> Although all of this could be done by email, in reality, we are all human and 
> many people find it easier to collaborate
> and communicate by talking to each other, rather than by email. This is not a 
> must, but an option to highlight issues
> 
> c) Demos, Sharing of Experiences, Sometimes discussion of specific 
> issues/bugs/problems/...
> This is something which happens frequently on the ARM call and seems to work 
> very well
> 
> I would suggest to start with a 1 hour monthly meeting: possibly every 2nd 
> Tue or Thu each month (depends on timing). I know that people are spread 
> across different timezones (from China to the US), so I would like to gather 
> thoughts before choosing a time. We may have to have alternating time-slots 
> every other month: but this is not ideal for some.

Thanks, I think this has worked well for the ARM community, so we
should give it a try on x86.

> To do this, please
> * Raise your hands on whether you or your org would want to participate

I would like to participate.

> * Provide your timezone

UTC

> * Provide a UTC time range when you can attend 

8:00am - 6:00pm WFM

Roger.

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

Re: [Xen-devel] [PATCH v2] x86: invpcid support

[Andrew Cooper]

On 02/03/18 16:23, Wei Liu wrote:
> Provide the functions needed for different modes. Add cpu_has_invpcid.
>
> Signed-off-by: Wei Liu 
> Reviewed-by: Juergen Gross 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 1/5] x86/entry: Correct comparisons against boolean variables

[Jan Beulich]

>>> On 27.02.18 at 15:50,  wrote:
> The correct way to check a boolean is `cmpb $0` or `testb $0xff`, whereas a
> lot of our entry code uses `testb $1`.  This will work in principle for values
> which are really C _Bool types, but won't work for other integer types which
> are intended to have boolean properties.
> 
> cmp is the more logical way of thinking about the operation, so adjust all
> outstanding uses of `testb $1` against boolean values.  Changing test to cmp
> changes the logical mnemonic of the following condition from 'zero' to
> 'equal', but the actual encoding remains the same.
> 
> No functional change, as all uses are real C _Bool types, and confirmed by
> diffing the disassembly.
> 
> Signed-off-by: Andrew Cooper 

Thanks, one less item on the list of things I keep forgetting to
actually do.

Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] PVH backports to 4.9 and 4.8

[Roger Pau Monné]

On Fri, Mar 02, 2018 at 08:23:50AM -0700, Jan Beulich wrote:
> >>> On 02.03.18 at 15:36,  wrote:
> > On Fri, Mar 02, 2018 at 07:31:43AM -0700, Jan Beulich wrote:
> >> >>> On 02.03.18 at 15:22,  wrote:
> >> > I'd be in favor of merging the 4.8.3pre-shim-comet and
> >> > 4.10.0-shim-comet branches into staging-4.8 and staging-4.10
> >> > respectively (assuming that's suitable).  Are there any other fixes to
> >> > PVH / PVshim hosting that we'd need to backport as well?
> >> 
> >> That depends on how well those branches have been maintained
> >> wrt fixes posted / applied during the last couple of weeks.
> >> 
> > 
> > I can cherry-pick relevant fixes to 4.10-comet and then merge 4.10-comet
> > with 4.10 staging.
> 
> Fine with me.
> 
> > If that's agreed we can discuss on what criteria do patches get picked
> > for backporting.
> 
> Until we've shipped a stable version from those branches (to be honest
> I'm not sure about doing this for 4.8 when we don#t mean to do it for
> 4.9),

We avoided 4.9 at the time due to the pressure of getting something
out fast, I'm not sure if it would be very complicated to pick the
'type=pvh' 4.8 backports and apply them 4.9, I'm fairly sure the code
base is not that different (and at most this is going to involve
dropping patches from the 4.8 branch).

Roger.

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

Re: [Xen-devel] update_runstate_area and Linux KPTI

[Julien Grall]

On 02/03/18 16:18, Jan Beulich wrote:

On 02.03.18 at 17:04,  wrote:

The proper way to do this is indeed by a nominated (guest) physical
address, at which point Xen can make all/any updates at times of its
choosing, and the guests pagetable/permissions state at an instantaneous
moment don't matter.

If you've got time to do this, then please do.  It will be a definite
improvement.


Just to be avoid unnecessary effort in the wrong direction: I don't
think you can alter the current interface. You'd have to add a new
one, and we could then deprecate (but never abandon) the current
one.


I was only planning to store the guest physical address rather than the 
virtual address as we do today. Is that considered as an alteration of 
the current interface?


In other words, the current version (e.g store virtual address) is just 
broken and going to be worst with KPTI kernel. I can't see how this 
could ever work properly on OS with different set of page-tables.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] update_runstate_area and Linux KPTI

[Andrew Cooper]

On 02/03/18 16:18, Jan Beulich wrote:
 On 02.03.18 at 17:04,  wrote:
>> The proper way to do this is indeed by a nominated (guest) physical
>> address, at which point Xen can make all/any updates at times of its
>> choosing, and the guests pagetable/permissions state at an instantaneous
>> moment don't matter.
>>
>> If you've got time to do this, then please do.  It will be a definite
>> improvement.
> Just to be avoid unnecessary effort in the wrong direction: I don't
> think you can alter the current interface. You'd have to add a new
> one, and we could then deprecate (but never abandon) the current
> one.

No - we sadly can't remove the current interface (at least for a long
while), but we can immediately deprecate it when a better alternative is
available.

OTOH, I think it would be a very good idea to have a Kconfig option so
we can selectively excise legacy interfaces.  I expect this will be of
particular interest to embedded/bespoke configurations.

~Andrew

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

[Xen-devel] [PATCH v2] x86: invpcid support

[Wei Liu]

Provide the functions needed for different modes. Add cpu_has_invpcid.

Signed-off-by: Wei Liu 
Reviewed-by: Juergen Gross 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Juergen Gross 
---
 xen/arch/x86/Rules.mk|  1 +
 xen/include/asm-x86/cpufeature.h |  1 +
 xen/include/asm-x86/invpcid.h| 70 
 3 files changed, 72 insertions(+)
 create mode 100644 xen/include/asm-x86/invpcid.h

diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 9897deaab9..acec5ce92a 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -23,6 +23,7 @@ $(call as-option-add,CFLAGS,CC,"rdseed 
%eax",-DHAVE_GAS_RDSEED)
 $(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
  -U__OBJECT_LABEL__ -DHAVE_GAS_QUOTED_SYM \
  '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$$@')
+$(call as-option-add,CFLAGS,CC,"invpcid (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
 
 CFLAGS += -mno-red-zone -fpic -fno-asynchronous-unwind-tables
 
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 55b696ed07..db8072279d 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -93,6 +93,7 @@
 #define cpu_has_avx2boot_cpu_has(X86_FEATURE_AVX2)
 #define cpu_has_smepboot_cpu_has(X86_FEATURE_SMEP)
 #define cpu_has_bmi2boot_cpu_has(X86_FEATURE_BMI2)
+#define cpu_has_invpcid boot_cpu_has(X86_FEATURE_INVPCID)
 #define cpu_has_rtm boot_cpu_has(X86_FEATURE_RTM)
 #define cpu_has_fpu_sel (!boot_cpu_has(X86_FEATURE_NO_FPU_SEL))
 #define cpu_has_mpx boot_cpu_has(X86_FEATURE_MPX)
diff --git a/xen/include/asm-x86/invpcid.h b/xen/include/asm-x86/invpcid.h
new file mode 100644
index 00..b46624a865
--- /dev/null
+++ b/xen/include/asm-x86/invpcid.h
@@ -0,0 +1,70 @@
+#ifndef _ASM_X86_INVPCID_H_
+#define _ASM_X86_INVPCID_H_
+
+#include 
+
+#define INVPCID_TYPE_INDIV_ADDR  0
+#define INVPCID_TYPE_SINGLE_CTXT 1
+#define INVPCID_TYPE_ALL_INCL_GLOBAL 2
+#define INVPCID_TYPE_ALL_NON_GLOBAL  3
+
+#define INVPCID_OPCODE ".byte 0x66, 0x0f, 0x38, 0x82\n"
+#define MODRM_ECX_01   ".byte 0x01\n"
+
+static inline void invpcid(unsigned int pcid, unsigned long addr,
+   unsigned int type)
+{
+struct {
+uint64_t pcid:12;
+uint64_t reserved:52;
+uint64_t addr;
+} desc = { .pcid = pcid, .addr = addr };
+
+asm volatile (
+#ifdef HAVE_AS_INVPCID
+  "invpcid %[desc], %q[type]"
+  : /* No output */
+  : [desc] "m" (desc), [type] "r" (type)
+#else
+  INVPCID_OPCODE MODRM_ECX_01
+  : /* No output */
+  : "a" (type), "c" ()
+#endif
+  : "memory" );
+}
+
+/* Flush all mappings for a given PCID and addr, not including globals */
+static inline void invpcid_flush_one(unsigned int pcid, unsigned long addr)
+{
+invpcid(pcid, addr, INVPCID_TYPE_INDIV_ADDR);
+}
+
+/* Flush all mappings for a given PCID, not including globals */
+static inline void invpcid_flush_single_context(unsigned int pcid)
+{
+invpcid(pcid, 0, INVPCID_TYPE_SINGLE_CTXT);
+}
+
+/* Flush all mappings, including globals, for all PCIDs */
+static inline void invpcid_flush_all(void)
+{
+invpcid(0, 0, INVPCID_TYPE_ALL_INCL_GLOBAL);
+}
+
+/* Flush all mappings for all PCIDs, excluding globals */
+static inline void invpcid_flush_all_nonglobals(void)
+{
+invpcid(0, 0, INVPCID_TYPE_ALL_NON_GLOBAL);
+}
+
+#endif /* _ASM_X86_INVPCID_H_ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.11.0


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

[Xen-devel] [PATCH v2] vvmx: fixes after CR4 trapping optimizations

[Roger Pau Monne]

Commit 406817 doesn't update nested VMX code in order to take into
account L1 CR4 host mask when nested guest (L2) writes to CR4, and
thus the mask written to CR4_GUEST_HOST_MASK is likely not as
restrictive as it should be.

Also the VVMCS GUEST_CR4 value should be updated to match the
underlying value when syncing the VVMCS state.

Fixes: 406817 ("vmx/hap: optimize CR4 trapping")
Signed-off-by: Roger Pau Monné 
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Sergey Dyasli 
---
I've manually tested and AFAICT this fixes the osstest failure
detected in 120076 ("test-amd64-amd64-qemuu-nested-intel").
---
Changes since v1:
 - Use guest_cr[4] in order to update the nested VMCS GUEST_CR4.
---
 xen/arch/x86/hvm/vmx/vmx.c  | 4 
 xen/arch/x86/hvm/vmx/vvmx.c | 7 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 5cee364b0c..18d8ce2303 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1617,6 +1617,10 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned 
int cr,
 v->arch.hvm_vmx.cr4_host_mask |=
 ~v->domain->arch.monitor.write_ctrlreg_mask[VM_EVENT_X86_CR4];
 
+if ( nestedhvm_vcpu_in_guestmode(v) )
+/* Add the nested host mask to get the more restrictive one. */
+v->arch.hvm_vmx.cr4_host_mask |= get_vvmcs(v,
+   
CR4_GUEST_HOST_MASK);
 }
 __vmwrite(CR4_GUEST_HOST_MASK, v->arch.hvm_vmx.cr4_host_mask);
 
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 8176736e8f..dcd3b28f86 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1101,7 +1101,8 @@ static void load_shadow_guest_state(struct vcpu *v)
  (get_vvmcs(v, CR4_READ_SHADOW) & cr_gh_mask);
 __vmwrite(CR4_READ_SHADOW, cr_read_shadow);
 /* Add the nested host mask to the one set by vmx_update_guest_cr. */
-__vmwrite(CR4_GUEST_HOST_MASK, cr_gh_mask | v->arch.hvm_vmx.cr4_host_mask);
+v->arch.hvm_vmx.cr4_host_mask |= cr_gh_mask;
+__vmwrite(CR4_GUEST_HOST_MASK, v->arch.hvm_vmx.cr4_host_mask);
 
 /* TODO: CR3 target control */
 }
@@ -1232,6 +1233,10 @@ static void sync_vvmcs_guest_state(struct vcpu *v, 
struct cpu_user_regs *regs)
 /* CR3 sync if exec doesn't want cr3 load exiting: i.e. nested EPT */
 if ( !(__n2_exec_control(v) & CPU_BASED_CR3_LOAD_EXITING) )
 shadow_to_vvmcs(v, GUEST_CR3);
+
+if ( v->arch.hvm_vmx.cr4_host_mask != ~0UL )
+/* Only need to update nested GUEST_CR4 if not all bits are trapped. */
+set_vvmcs(v, GUEST_CR4, v->arch.hvm_vcpu.guest_cr[4]);
 }
 
 static void sync_vvmcs_ro(struct vcpu *v)
-- 
2.16.1


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

Re: [Xen-devel] update_runstate_area and Linux KPTI

[Jan Beulich]

>>> On 02.03.18 at 17:04,  wrote:
> The proper way to do this is indeed by a nominated (guest) physical
> address, at which point Xen can make all/any updates at times of its
> choosing, and the guests pagetable/permissions state at an instantaneous
> moment don't matter.
> 
> If you've got time to do this, then please do.  It will be a definite
> improvement.

Just to be avoid unnecessary effort in the wrong direction: I don't
think you can alter the current interface. You'd have to add a new
one, and we could then deprecate (but never abandon) the current
one.

Jan


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

Re: [Xen-devel] [PATCH] Please Welcome Julien, our new Committer

[Julien Grall]

Hi Stefano,

On 01/03/18 19:17, Stefano Stabellini wrote:

In recognition of his expertise and commitment to Xen Project, please
join me in welcoming Julien among the Committers and REST Maintainers.

Signed-off-by: Stefano Stabellini 


Thank you for the nomination! FWIW:

Acked-by: Julien Grall 

Cheers,



diff --git a/MAINTAINERS b/MAINTAINERS
index e4070ff..a5b3e95 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -503,6 +503,7 @@ M:  Andrew Cooper 
  M:George Dunlap 
  M:Ian Jackson 
  M:Jan Beulich 
+M: Julien Grall 
  M:Konrad Rzeszutek Wilk 
  M:Stefano Stabellini 
  M:Tim Deegan 

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



--
Julien Grall

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

Re: [Xen-devel] [PATCH] vvmx: fixes after CR4 trapping optimizations

[Roger Pau Monné]

On Fri, Mar 02, 2018 at 02:29:54PM +, Sergey Dyasli wrote:
> On Thu, 2018-03-01 at 16:19 +, Roger Pau Monne wrote:
> > Commit 406817 doesn't update nested VMX code in order to take into
> > account L1 CR4 host mask when nested guest (L2) writes to CR4, and
> > thus the mask written to CR4_GUEST_HOST_MASK is likely not as
> > restrictive as it should be.
> > 
> > Also the VVMCS GUEST_CR4 value should be updated to match the
> > underlying value when syncing the VVMCS state.
> > 
> > Fixes: 406817 ("vmx/hap: optimize CR4 trapping")
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Jun Nakajima 
> > Cc: Kevin Tian 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > ---
> > I've manually tested and AFAICT this fixes the osstest failure
> > detected in 120076 ("test-amd64-amd64-qemuu-nested-intel").
> > ---
> >  xen/arch/x86/hvm/vmx/vmx.c  |  4 
> >  xen/arch/x86/hvm/vmx/vvmx.c | 13 -
> >  2 files changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> > index 5cee364b0c..18d8ce2303 100644
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -1617,6 +1617,10 @@ static void vmx_update_guest_cr(struct vcpu *v, 
> > unsigned int cr,
> >  v->arch.hvm_vmx.cr4_host_mask |=
> >  
> > ~v->domain->arch.monitor.write_ctrlreg_mask[VM_EVENT_X86_CR4];
> >  
> > +if ( nestedhvm_vcpu_in_guestmode(v) )
> > +/* Add the nested host mask to get the more restrictive 
> > one. */
> > +v->arch.hvm_vmx.cr4_host_mask |= get_vvmcs(v,
> > +   
> > CR4_GUEST_HOST_MASK);
> >  }
> >  __vmwrite(CR4_GUEST_HOST_MASK, v->arch.hvm_vmx.cr4_host_mask);
> >  
> > diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> > index 8176736e8f..2baf707eec 100644
> > --- a/xen/arch/x86/hvm/vmx/vvmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> > @@ -1101,7 +1101,8 @@ static void load_shadow_guest_state(struct vcpu *v)
> >   (get_vvmcs(v, CR4_READ_SHADOW) & cr_gh_mask);
> >  __vmwrite(CR4_READ_SHADOW, cr_read_shadow);
> >  /* Add the nested host mask to the one set by vmx_update_guest_cr. */
> > -__vmwrite(CR4_GUEST_HOST_MASK, cr_gh_mask | 
> > v->arch.hvm_vmx.cr4_host_mask);
> > +v->arch.hvm_vmx.cr4_host_mask |= cr_gh_mask;
> > +__vmwrite(CR4_GUEST_HOST_MASK, v->arch.hvm_vmx.cr4_host_mask);
> >  
> >  /* TODO: CR3 target control */
> >  }
> > @@ -1232,6 +1233,16 @@ static void sync_vvmcs_guest_state(struct vcpu *v, 
> > struct cpu_user_regs *regs)
> >  /* CR3 sync if exec doesn't want cr3 load exiting: i.e. nested EPT */
> >  if ( !(__n2_exec_control(v) & CPU_BASED_CR3_LOAD_EXITING) )
> >  shadow_to_vvmcs(v, GUEST_CR3);
> > +
> > +if ( v->arch.hvm_vmx.cr4_host_mask != ~0UL )
> > +{
> > +   /* Only need to update nested GUEST_CR4 if not all bits are 
> > trapped. */
> > +unsigned long nested_cr4_mask = get_vvmcs(v, CR4_GUEST_HOST_MASK);
> > +
> > +set_vvmcs(v, GUEST_CR4,
> > +  (get_vvmcs(v, GUEST_CR4) & nested_cr4_mask) |
> > +  (v->arch.hvm_vcpu.guest_cr[4] & ~nested_cr4_mask));
> 
> Why reading the old GUEST_CR4 is needed here? Can the new value be set
> directly from guest_cr[4]?

Yes, I think so. The nested GUEST_CR4 value is the value the L1
hypervisor thinks is written to the hardware CR4 (while the L2 guest
is running) and guest_cr[4] contains the value of the CR4 register as
seen by the L1 hypervisor.

There's no way CR4 L1 tapped bits can leak into guest_cr[4] because
cr4_host_mask is always equally or more restrictive than the nested
CR4_GUEST_HOST_MASK. Let me send a new version.

Thanks, Roger.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  2d9078954279e943d976ca2154c16b986dd25799
baseline version:
 xen  59afdb8a81d66454d8bc0489e82de031613227bf

Last test of basis   120134  2018-03-01 21:01:49 Z0 days
Testing same since   120151  2018-03-02 13:06:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Jim Fehlig 
  Marek Marczykowski-Górecki 
  Olaf Hering 
  Paul Semel 
  Wei Liu 

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

To xenbits.xen.org:/home/xen/git/xen.git
   59afdb8a81..2d90789542  2d9078954279e943d976ca2154c16b986dd25799 -> smoke

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

Re: [Xen-devel] [PATCH v4 14/16] xen/grant: Switch common/grant_table.c to use typesafe MFN

[Jan Beulich]

>>> On 02.03.18 at 16:59,  wrote:
> On 02/03/18 15:54, Jan Beulich wrote:
> On 21.02.18 at 15:02,  wrote:
>>> @@ -872,7 +879,7 @@ map_grant_ref(
>>>   struct grant_table *lgt, *rgt;
>>>   struct vcpu   *led;
>>>   grant_handle_t handle;
>>> -unsigned long  frame = 0;
>>> +mfn_t frame = _mfn(0);
>> 
>> If the initializer is needed at all, I think it should again become
>> INVALID_MFN. Same in a few other places.
> 
> I didn't switch to INVALID_MFN because I wasn't sure if some place in 
> the code where relying on 0. If you think it is fine, then I am more 
> thank happy to switch to INVALID_MFN.

Well, as said - it looks as if the initializer isn't needed at all, in
which case it's value really is a don't care.

Jan


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

Re: [Xen-devel] [PATCH v2 2/2] x86/xpti: don't map stack guard pages

[Jan Beulich]

>>> On 02.03.18 at 16:43,  wrote:
> On 02/03/18 15:35, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -5576,6 +5576,14 @@ void memguard_unguard_stack(void *p)
>> STACK_SIZE - PRIMARY_STACK_SIZE - IST_MAX * 
>> PAGE_SIZE);
>>  }
>>  
>> +bool memguard_is_stack_guard_page(unsigned long addr)
>> +{
>> +addr &= STACK_SIZE - 1;
>> +
>> +return addr >= IST_MAX * PAGE_SIZE &&
>> +   addr < STACK_SIZE - PRIMARY_STACK_SIZE;
>> +}
>> +
> 
> What about making use of memguard_is_stack_guard_page() in
> memguard_[un]guard_stack() ?

I was considering this as a follow-up step.

> This would at once ensure the other unused
> pages won't be accessed accidentally somewhere.

I don't understand this part, though.

Jan


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

Re: [Xen-devel] [PATCH v4 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

[Jan Beulich]

>>> On 21.02.18 at 15:02,  wrote:
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -43,16 +43,6 @@
>  #include "emulate.h"
>  #include "mm.h"
>  
> -/* Override macros from asm/page.h to make them work with mfn_t */
> -#undef mfn_to_page
> -#define mfn_to_page(mfn) __mfn_to_page(mfn_x(mfn))
> -#undef page_to_mfn
> -#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
> -
> -/***
> - * I/O emulation support
> - */

Why does this comment go away?

> @@ -478,10 +478,10 @@ extern paddr_t mem_hotplug;
>  #define SHARED_M2P(_e)   ((_e) == SHARED_M2P_ENTRY)
>  
>  #define compat_machine_to_phys_mapping ((unsigned int 
> *)RDWR_COMPAT_MPT_VIRT_START)
> -#define _set_gpfn_from_mfn(mfn, pfn) ({\
> -struct domain *d = page_get_owner(__mfn_to_page(mfn)); \
> -unsigned long entry = (d && (d == dom_cow)) ?  \
> -SHARED_M2P_ENTRY : (pfn);  \
> +#define _set_gpfn_from_mfn(mfn, pfn) ({ \
> +struct domain *d = page_get_owner(mfn_to_page(_mfn(mfn)));\
> +unsigned long entry = (d && (d == dom_cow)) ?   \
> +SHARED_M2P_ENTRY : (pfn);   \

Please don't break the alignment of the backslashes here. It also looks
like three of the four lines could be left alone altogether.

> @@ -157,10 +157,10 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa, 
> unsigned int flags)
>  #define l4e_from_intpte(intpte)((l4_pgentry_t) { (intpte_t)(intpte) })
>  
>  /* Construct a pte from a page pointer and access flags. */
> -#define l1e_from_page(page, flags) l1e_from_pfn(__page_to_mfn(page), (flags))
> -#define l2e_from_page(page, flags) l2e_from_pfn(__page_to_mfn(page), (flags))
> -#define l3e_from_page(page, flags) l3e_from_pfn(__page_to_mfn(page), (flags))
> -#define l4e_from_page(page, flags) l4e_from_pfn(__page_to_mfn(page), (flags))
> +#define l1e_from_page(page, flags) l1e_from_mfn(page_to_mfn(page), (flags))
> +#define l2e_from_page(page, flags) l2e_from_mfn(page_to_mfn(page), (flags))
> +#define l3e_from_page(page, flags) l3e_from_mfn(page_to_mfn(page), (flags))
> +#define l4e_from_page(page, flags) l4e_from_mfn(page_to_mfn(page), (flags))

Would again have been nice if you got rid of the extra parentheses
here at the same time.

> @@ -240,12 +240,12 @@ void copy_page_sse2(void *, const void *);
>  #define __mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
>  
>  /* Convert between machine frame numbers and page-info structures. */
> -#define __mfn_to_page(mfn)  (frame_table + pfn_to_pdx(mfn))
> -#define __page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table))
> +#define mfn_to_page(mfn)(frame_table + mfn_to_pdx(mfn))
> +#define page_to_mfn(pg) pdx_to_mfn((unsigned long)((pg) - frame_table))
>  
>  /* Convert between machine addresses and page-info structures. */
> -#define __maddr_to_page(ma) __mfn_to_page((ma) >> PAGE_SHIFT)
> -#define __page_to_maddr(pg) ((paddr_t)__page_to_mfn(pg) << PAGE_SHIFT)
> +#define __maddr_to_page(ma) mfn_to_page(maddr_to_mfn(ma))
> +#define __page_to_maddr(pg) (mfn_to_maddr(page_to_mfn(pg)))

Same here.

With at least the first two items taken care of, relevant x86 pieces
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] update_runstate_area and Linux KPTI

[Andrew Cooper]

On 02/03/18 15:57, Julien Grall wrote:
> Hi,
>
> While I was looking at some unrelated problem with Xen ARM P2M code, I
> noticed that the function update_runstate_area is using guest virtual
> address to update the vCPU runstate. That function will be called when
> context switch to a vCPU. However, that vCPU may run in userspace
> context. When KPTI (kernel page table isolation) is used,
>
> In the best case, that address is not mapped into the page-table
> currently used. Xen will not be able to update the region.
>
> In the worst case, that address is mapped to a different region and
> Xen will corrupt some bits of the memory.
>
> The code looks fundamentally wrong on Arm, I am entirely not sure
> about x86.
>
> It look like to me that Xen should always use the guest physical
> address and therefore translate the virtual address to a physical one
> in VCPUOP_register_runstate_memory_area. So only the physical address
> will be used in update_runstate_area making the function much safer.
>
> Any opinion on this approach?

All the Xen interfaces like this built upon linear (virtual) addresses
are fundamentally wrong, but that horse has bolted.

On the x86 side, we've got a gross hack where we try and ignore
pagefaults, leaving a note to come back and try again later.  It gets
even more complicated with SMAP (PAN on ARM, iirc).

The proper way to do this is indeed by a nominated (guest) physical
address, at which point Xen can make all/any updates at times of its
choosing, and the guests pagetable/permissions state at an instantaneous
moment don't matter.

If you've got time to do this, then please do.  It will be a definite
improvement.

~Andrew

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

Re: [Xen-devel] [PATCH v4 14/16] xen/grant: Switch common/grant_table.c to use typesafe MFN

[Julien Grall]

Hi Jan,

On 02/03/18 15:54, Jan Beulich wrote:

On 21.02.18 at 15:02,  wrote:

@@ -872,7 +879,7 @@ map_grant_ref(
  struct grant_table *lgt, *rgt;
  struct vcpu   *led;
  grant_handle_t handle;
-unsigned long  frame = 0;
+mfn_t frame = _mfn(0);


If the initializer is needed at all, I think it should again become
INVALID_MFN. Same in a few other places.


I didn't switch to INVALID_MFN because I wasn't sure if some place in 
the code where relying on 0. If you think it is fine, then I am more 
thank happy to switch to INVALID_MFN.





--- a/xen/include/asm-x86/grant_table.h
+++ b/xen/include/asm-x86/grant_table.h
@@ -76,7 +76,7 @@ static inline unsigned int gnttab_dom0_max(void)
  #define gnttab_status_gmfn(d, t, i) \
  (mfn_to_gmfn(d, gnttab_status_mfn(t, i)))
  
-#define gnttab_mark_dirty(d, f) paging_mark_dirty((d), _mfn(f))

+#define gnttab_mark_dirty(d, f) paging_mark_dirty((d), f)


Please take the opportunity and also drop the stray parentheses
around d.


Sure.



With these taken care of and with Wei's R-b
Acked-by: Jan Beulich 


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 11/16] xen/mm: Switch page_alloc.c to typesafe MFN

[Julien Grall]

On 02/03/18 15:18, Jan Beulich wrote:

On 21.02.18 at 15:02,  wrote:

@@ -1735,14 +1743,14 @@ static void init_heap_pages(
  
  if ( unlikely(!avail[nid]) )

  {
-unsigned long s = page_to_mfn(pg + i);
-unsigned long e = page_to_mfn(pg + nr_pages - 1) + 1;
+unsigned long s = mfn_x(page_to_mfn(pg + i));
+unsigned long e = mfn_x(mfn_add(page_to_mfn(pg + nr_pages - 1), 
1));
  bool_t use_tail = (nid == phys_to_nid(pfn_to_paddr(e - 1))) &&
!(s & ((1UL << MAX_ORDER) - 1)) &&
(find_first_set_bit(e) <= 
find_first_set_bit(s));
  unsigned long n;
  
-n = init_node_heap(nid, page_to_mfn(pg+i), nr_pages - i,

+n = init_node_heap(nid, mfn_x(page_to_mfn(pg+i)), nr_pages - i,


You've got Wei's R-b, so I won't insist, but it would have been nice
if you added the missing blanks around the + here.

Also I think the patch doesn't go quite far enough to make the title
actually true. Care to make it say "... some of page_alloc.c ..."?


I will do for both. Thank you for the review.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 15/16] xen/x86: Switch mfn_to_page in x86_64/mm.c to use typesafe MFN

[Jan Beulich]

>>> On 21.02.18 at 15:02,  wrote:
> @@ -160,7 +162,8 @@ static int m2p_mapped(unsigned long spfn)
>  
>  static int share_hotadd_m2p_table(struct mem_hotadd_info *info)
>  {
> -unsigned long i, n, v, m2p_start_mfn = 0;
> +unsigned long i, n, v;
> +mfn_t m2p_start_mfn = _mfn(0);

INVALID_MFN again please.

With that
Acked-by: Jan Beulich 

Jan


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

[Xen-devel] update_runstate_area and Linux KPTI

[Julien Grall]

Hi,

While I was looking at some unrelated problem with Xen ARM P2M code, I 
noticed that the function update_runstate_area is using guest virtual 
address to update the vCPU runstate. That function will be called when 
context switch to a vCPU. However, that vCPU may run in userspace 
context. When KPTI (kernel page table isolation) is used,


In the best case, that address is not mapped into the page-table 
currently used. Xen will not be able to update the region.


In the worst case, that address is mapped to a different region and Xen 
will corrupt some bits of the memory.


The code looks fundamentally wrong on Arm, I am entirely not sure about x86.

It look like to me that Xen should always use the guest physical address 
and therefore translate the virtual address to a physical one in 
VCPUOP_register_runstate_memory_area. So only the physical address will 
be used in update_runstate_area making the function much safer.


Any opinion on this approach?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 14/16] xen/grant: Switch common/grant_table.c to use typesafe MFN

[Jan Beulich]

>>> On 21.02.18 at 15:02,  wrote:
> @@ -872,7 +879,7 @@ map_grant_ref(
>  struct grant_table *lgt, *rgt;
>  struct vcpu   *led;
>  grant_handle_t handle;
> -unsigned long  frame = 0;
> +mfn_t frame = _mfn(0);

If the initializer is needed at all, I think it should again become
INVALID_MFN. Same in a few other places.

> --- a/xen/include/asm-x86/grant_table.h
> +++ b/xen/include/asm-x86/grant_table.h
> @@ -76,7 +76,7 @@ static inline unsigned int gnttab_dom0_max(void)
>  #define gnttab_status_gmfn(d, t, i) \
>  (mfn_to_gmfn(d, gnttab_status_mfn(t, i)))
>  
> -#define gnttab_mark_dirty(d, f) paging_mark_dirty((d), _mfn(f))
> +#define gnttab_mark_dirty(d, f) paging_mark_dirty((d), f)

Please take the opportunity and also drop the stray parentheses
around d.

With these taken care of and with Wei's R-b
Acked-by: Jan Beulich 

Jan


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

[Xen-devel] Setting up a Xen x86 community call

[Lars Kurth]

Hi all, 
(sorry for the extensive distribution list - I went through MAINTAINERS and 
people who may have an interest)

I would like to start organizing a recurring x86 community call to discuss and 
sync-up on upcoming features for Xen on x86. This call would mirror and follow 
a similar structure to the ARM call (see 
http://xen.markmail.org/thread/xqdxvqcjpf2y5ftu for the last one)

I expect that the call will contain

a) Coordination and Planning 
Coordinating who does what, what needs attention, what is blocked, etc. 
I would prepare a list of non-merged patch series of a certain size (e.g. more 
than 5 patches) and attach to the invite
If anything is missed, I would expect that these are sent to me before the 
meeting

b) Design and architecture related discussions: in particular for bigger, more 
complex items, ... 
Although all of this could be done by email, in reality, we are all human and 
many people find it easier to collaborate
and communicate by talking to each other, rather than by email. This is not a 
must, but an option to highlight issues

c) Demos, Sharing of Experiences, Sometimes discussion of specific 
issues/bugs/problems/...
This is something which happens frequently on the ARM call and seems to work 
very well

I would suggest to start with a 1 hour monthly meeting: possibly every 2nd Tue 
or Thu each month (depends on timing). I know that people are spread across 
different timezones (from China to the US), so I would like to gather thoughts 
before choosing a time. We may have to have alternating time-slots every other 
month: but this is not ideal for some.

To do this, please
* Raise your hands on whether you or your org would want to participate
* Provide your timezone
* Provide a UTC time range when you can attend 

Your sincerely,
Lars



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

Re: [Xen-devel] [PATCH v4 13/16] xen/grant: Switch {create, replace}_grant_p2m_mapping to typesafe MFN

[Jan Beulich]

>>> On 21.02.18 at 15:02,  wrote:
> The current prototype is slightly confusing because it takes a guest
> physical address and a machine physical frame (not address!). Switching to
> MFN will improve safety and reduce the chance to mistakenly invert the
> 2 parameters.
> 
> Signed-off-by: Julien grall 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v4 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

[Jan Beulich]

>>> On 21.02.18 at 15:02,  wrote:
> @@ -95,11 +101,18 @@ static unsigned int max_order(const struct domain *d)
>  return min(order, MAX_ORDER + 0U);
>  }
>  
> +/* Helper to copy a typesafe MFN to guest */
> +#define copy_mfn_to_guest(hnd, off, mfn)\
> +({  \
> +xen_pfn_t mfn_ = mfn_x(mfn);\
> +__copy_to_guest_offset(hnd, off, _, 1); \
> +})

Hmm, not really nice, but what do you do. 

>  static void increase_reservation(struct memop_args *a)
>  {
>  struct page_info *page;
>  unsigned long i;
> -xen_pfn_t mfn;
> +mfn_t mfn;

Please move this declaration ...

> @@ -133,7 +146,7 @@ static void increase_reservation(struct memop_args *a)
>   !guest_handle_is_null(a->extent_list) )
>  {
>  mfn = page_to_mfn(page);

... here, making the assignment its initializer. Or even avoid the
local variable altogether, as the macro has already got one. Same
elsewhere (whichever of the two variants fits), albeit maybe in the
other cases the scope can't be shrunk much.

Jan


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

[Xen-devel] Role base in Xen.

[Jason Long]

Hello.How can I configure Xen and limit users for create VMs and set quota for 
them? For example, users can't create a VM that have more than 1GB RAM.
Thank you.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] PVH backports to 4.9 and 4.8

[Jan Beulich]

>>> On 02.03.18 at 15:36,  wrote:
> On Fri, Mar 02, 2018 at 07:31:43AM -0700, Jan Beulich wrote:
>> >>> On 02.03.18 at 15:22,  wrote:
>> > I'd be in favor of merging the 4.8.3pre-shim-comet and
>> > 4.10.0-shim-comet branches into staging-4.8 and staging-4.10
>> > respectively (assuming that's suitable).  Are there any other fixes to
>> > PVH / PVshim hosting that we'd need to backport as well?
>> 
>> That depends on how well those branches have been maintained
>> wrt fixes posted / applied during the last couple of weeks.
>> 
> 
> I can cherry-pick relevant fixes to 4.10-comet and then merge 4.10-comet
> with 4.10 staging.

Fine with me.

> If that's agreed we can discuss on what criteria do patches get picked
> for backporting.

Until we've shipped a stable version from those branches (to be honest
I'm not sure about doing this for 4.8 when we don#t mean to do it for
4.9), I think this can be a little relaxed. Later the criteria should match
that of other changes going into stable.

Jan


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

Re: [Xen-devel] [PATCH] x86: invpcid support

[Wei Liu]

On Fri, Mar 02, 2018 at 02:47:13PM +, Wei Liu wrote:
> Provide the functions needed for different modes. And cpu_has_invpcid.
> 
> Signed-off-by: Wei Liu 
> ---
> This is useful for Juergen's XPTI improvement series.
> 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Juergen Gross 
> ---
>  xen/arch/x86/Rules.mk|  1 +
>  xen/include/asm-x86/cpufeature.h |  1 +
>  xen/include/asm-x86/invpcid.h| 75 
> 
>  3 files changed, 77 insertions(+)
>  create mode 100644 xen/include/asm-x86/invpcid.h
> 
> diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
> index 9897deaab9..c941059f42 100644
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -23,6 +23,7 @@ $(call as-option-add,CFLAGS,CC,"rdseed 
> %eax",-DHAVE_GAS_RDSEED)
>  $(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
>   -U__OBJECT_LABEL__ -DHAVE_GAS_QUOTED_SYM \
>   '-D__OBJECT_LABEL__=$(subst 
> $(BASEDIR)/,,$(CURDIR))/$$@')
> +$(call as-insn-check,CFLAGS,CC,"invpcid 
> (%rax)$$(comma)%rax",-DHAVE_GAS_INVPCID)

Ah, and this also needs to be replaced with as-option-add.

Wei.

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

[Xen-devel] [xen-4.9-testing test] 120105: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
12
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
12

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 12
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 119954
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 12
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 12
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 12
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 12
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 12
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 12
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  dc3efc2d2bcfe1613cd9c26c31a5180da26c7c68
baseline version:
 xen  

Re: [Xen-devel] [PATCH v4 11/16] xen/mm: Switch page_alloc.c to typesafe MFN

[Jan Beulich]

>>> On 21.02.18 at 15:02,  wrote:
> @@ -1735,14 +1743,14 @@ static void init_heap_pages(
>  
>  if ( unlikely(!avail[nid]) )
>  {
> -unsigned long s = page_to_mfn(pg + i);
> -unsigned long e = page_to_mfn(pg + nr_pages - 1) + 1;
> +unsigned long s = mfn_x(page_to_mfn(pg + i));
> +unsigned long e = mfn_x(mfn_add(page_to_mfn(pg + nr_pages - 1), 
> 1));
>  bool_t use_tail = (nid == phys_to_nid(pfn_to_paddr(e - 1))) &&
>!(s & ((1UL << MAX_ORDER) - 1)) &&
>(find_first_set_bit(e) <= 
> find_first_set_bit(s));
>  unsigned long n;
>  
> -n = init_node_heap(nid, page_to_mfn(pg+i), nr_pages - i,
> +n = init_node_heap(nid, mfn_x(page_to_mfn(pg+i)), nr_pages - i,

You've got Wei's R-b, so I won't insist, but it would have been nice
if you added the missing blanks around the + here.

Also I think the patch doesn't go quite far enough to make the title
actually true. Care to make it say "... some of page_alloc.c ..."?

Jan


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

Re: [Xen-devel] [PATCH 1/2] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling

[Juergen Gross]

On 02/03/18 15:58, Simon Gaiser wrote:
> Juergen Gross:
>> On 20/02/18 05:56, Simon Gaiser wrote:
>>> Juergen Gross:
 On 07/02/18 23:22, Simon Gaiser wrote:
> Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
> concurrent xenstore accesses") made a subtle change to the semantic of
> xenbus_dev_request_and_reply() and xenbus_transaction_end().
>
> Before on an error response to XS_TRANSACTION_END
> xenbus_dev_request_and_reply() would not decrement the active
> transaction counter. But xenbus_transaction_end() has always counted the
> transaction as finished regardless of the response.

 Which is correct now. Xenstore will free all transaction related
 data regardless of the response. A once failed transaction can't
 be repaired, it has to be repeated completely.
>>>
>>> So if xenstore frees the transaction why should we keep it in the list
>>> with pending transaction in xenbus_dev_frontend? That's exactly what
>>> this patch fixes by always removing it from the list, not only on a
>>> successful response (See below for the EINVAL case).
>>
>> Aah, sorry, I seem to have misread my own coding. :-(
>>
>> Yes, you are right. Sorry for not seeing it before.
>>
>>>
>>> [...]
> But xenbus_dev_frontend tries to end a transaction on closing of the
> device if the XS_TRANSACTION_END failed before. Trying to close the
> transaction twice corrupts the reference count. So fix this by also
> considering a transaction closed if we have sent XS_TRANSACTION_END once
> regardless of the return code.

 A transaction in the list of transactions should not considered to be
 finished. Either it is not on the list or it is still pending.
>>>
>>> With "considering a transaction closed" I mean "take the code path which
>>> removes the transaction from the list with pending transactions".
>>>
>>> From the follow-up mail:
>> The new behavior is that xenbus_dev_request_and_reply() and
>> xenbus_transaction_end() will always count the transaction as finished
>> regardless the response code (handled in xs_request_exit()).
>
> ENOENT should not decrement the transaction counter, while all
> other responses to XS_TRANSACTION_END should still do so.

 Sorry, I stand corrected: the ENOENT case should never happen, as this
 case is tested in xenbus_write_transaction(). It doesn't hurt to test
 for ENOENT, though.

 What should be handled is EINVAL: this would happen if a user specified
 a string different from "T" and "F".
>>>
>>> Ok, I will handle those cases in xs_request_exit(). Although I don't
>>> like that this depends on the internals of xenstore (At least to me it's
>>> not obvious why it should only return ENOENT or EINVAL in this case).
>>>
>>> In the xenbus_write_transaction() case checking the string before
>>> sending the transaction (like the transaction itself is verified) would
>>> avoid this problem.
>>
>> Right. I'd prefer this solution.
>>
>> Remains the only problem you tried to tackle with your second patch: a
>> kernel driver going crazy and ending transactions it never started (or
>> ending them multiple times). The EINVAL case can't happen here, but
>> ENOENT can. Either ENOENT has to be handled in xs_request_exit() or you
>> need to keep track of the transactions like in the user interface and
>> refuse ending an unknown transaction. Or you trust the kernel users.
>> Trying to fix the usage counter seems to be the wrong approach IMO.
> 
> The point of the second patch was to detect such bugs. This would have
> saved quite some time to find this bug. I added the "fix" of the counter
> I just because it was trivial after having the if there.
> 
> Adding tracking seems to be a quite complex solution for a _potential_
> problem.

I agree.

> So I would go with checking ENOENT in xs_request_exit(). Should this be
> WARN_ON_ONCE()? Since this normally should not happen I would say yes.

Yes, having a WARN_ON_ONCE here will help.

> Should I keep the reference counter sanity check? And if yes, with the
> "fix" to the counter?

I'd drop it. This really should not happen and blowing up kernel size
with checks of impossible situations isn't the way to go.

In case you really want to do something here you can add something like
ASSERT(xs_state_users) before decrementing the counter.


Juergen

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

Re: [Xen-devel] [PATCH v4 06/16] xen/x86: Remove unused override of page_to_mfn/mfn_to_page

[Jan Beulich]

>>> On 02.03.18 at 15:44,  wrote:
> On 02/03/18 14:42, Jan Beulich wrote:
> On 21.02.18 at 15:02,  wrote:
>>> A few files override page_to_mfn/mfn_to_page but actually never use
>>> those macros. So drop them.
>>>
>>> Signed-off-by: Julien Grall 
>> 
>> It doesn't look like there are any risky uses of the removed
>> symbols in the headers, so
>> Acked-by: Jan Beulich 
>> assuming this has been build-tested in relevant configurations.
> 
> All patches have been build-tested one by one.

I've taken that for given. I did say "in relevant configurations"
because things like BIGMEM=y or SHADOW_PAGING=n may
cause issues despite a "normal" build having gone fine.

Jan


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