[Xen-devel] [xen-4.9-testing test] 118524: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 118487 
pass in 118524
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
118487

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail in 118487 like 118222
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 118167
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118167
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 118167
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118222
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118222
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118222
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118222
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 118222
 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-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-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-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-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-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-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-win10-i386 10 windows-installfail 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-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  a2567d6b54b7b187ecc0165021b6dd07dafaf06a
baseline version:
 xen  dc7d46580d9c633a59be1c3776f79c01dd0cb98b

Last test of basis   118222  2018-01-19 06:53:40 Z   15 days
Testing same since   118314  2018-01-24 21:44:17 Z9 days8 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano 

[Xen-devel] [linux-4.9 test] 118520: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 
118483 pass in 118520
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
118483

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail in 118483 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118291
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118291
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118291
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118291
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118291
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   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-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-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-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-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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  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-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-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-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-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-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux6c6f924f9c6294944ee6efb1bbd8cdb853582e50
baseline version:
 linux79584a4221253611a4d033087f373b046350df9f

Last test of basis   118291  2018-01-23 19:17:05 Z   10 days
Testing same since   118483  2018-01-31 12:20:21 Z2 days2 attempts


People who touched 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118474
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118474
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118474
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118474
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118474
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118474
 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-amd64-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-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-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-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-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-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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-i386-xl-qemuu-ws16-amd64 17 guest-stop  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:
 qemuub05631954d6dfe93340d516660397e2c1a2a5dd6
baseline version:
 qemuu6521130b0a7f699fdb82446d57df5627bfa7ed3c

Last test of basis   118474  2018-01-31 09:52:44 Z2 days
Testing same since   118515  2018-02-01 15:20:07 Z1 days1 attempts


People who touched revisions under test:
  Helge Deller 
  Peter Maydell 
  Richard Henderson 

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   

[Xen-devel] [PATCH] pvcalls-back: do not return error on inet_accept EAGAIN

[Stefano Stabellini]

When the client sends a regular blocking accept request, the backend is
expected to return only when the accept is completed, simulating a
blocking behavior, or return an error.

Specifically, on EAGAIN from inet_accept, the backend shouldn't return
"EAGAIN" to the client. Instead, it should simply continue the wait.
Otherwise, the client will send another accept request, which will cause
another EAGAIN to be sent back, which is a waste of resources and not
conforming to the expected behavior. Change the behavior by turning the
"goto error" into a return.

Signed-off-by: Stefano Stabellini 

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index c7822d8..156e5ae 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -548,7 +548,7 @@ static void __pvcalls_back_accept(struct work_struct *work)
ret = inet_accept(mappass->sock, sock, O_NONBLOCK, true);
if (ret == -EAGAIN) {
sock_release(sock);
-   goto out_error;
+   return;
}
 
map = pvcalls_new_active_socket(fedata,

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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  99d9d7a33b781bc9a91416f1e04c8e50e40fa4ef
baseline version:
 xen  dd855aa430f2da9b677c145f0c625a82aaa97110

Last test of basis   118544  2018-02-02 20:01:58 Z0 days
Testing same since   118547  2018-02-02 23:01:14 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

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
   dd855aa430..99d9d7a33b  99d9d7a33b781bc9a91416f1e04c8e50e40fa4ef -> smoke

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

Re: [Xen-devel] [PATCH] xen: hypercall: fix out-of-bounds memcpy

[Boris Ostrovsky]

On 02/02/2018 10:32 AM, Arnd Bergmann wrote:
> The legacy hypercall handlers were originally added with
> a comment explaining that "copying the argument structures in
> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
> variable is sufficiently safe" and only made sure to not write
> past the end of the argument structure, the checks in linux/string.h
> disagree with that, when link-time optimizations are used:
>
> In function 'memcpy',
> inlined from 'pirq_query_unmask' at drivers/xen/fallback.c:53:2,
> inlined from '__startup_pirq' at drivers/xen/events/events_base.c:529:2,
> inlined from 'restore_pirqs' at drivers/xen/events/events_base.c:1439:3,
> inlined from 'xen_irq_resume' at drivers/xen/events/events_base.c:1581:2:
> include/linux/string.h:350:3: error: call to '__read_overflow2' declared with 
> attribute error: detected read beyond size of object passed as 2nd parameter
>__read_overflow2();
>^
> make[3]: *** [ccLujFNx.ltrans15.ltrans.o] Error 1
> make[3]: Target 'all' not remade because of errors.
> lto-wrapper: fatal error: make returned 2 exit status
> compilation terminated.
> ld: error: lto-wrapper failed
>
> This changes the functions so that each argument is accessed with
> exactly the correct length based on the command code.
>
> Fixes: cf47a83fb06e ("xen/hypercall: fix hypercall fallback code for very old 
> hypervisors")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/xen/fallback.c | 94 
> --
>  1 file changed, 53 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
> index b04fb64c5a91..eded8dd821ad 100644
> --- a/drivers/xen/fallback.c
> +++ b/drivers/xen/fallback.c
> @@ -7,75 +7,87 @@
>  
>  int xen_event_channel_op_compat(int cmd, void *arg)
>  {
> - struct evtchn_op op;
> + struct evtchn_op op = { .cmd = cmd, };
> + size_t len;
>   int rc;
>  
> - op.cmd = cmd;
> - memcpy(, arg, sizeof(op.u));
> - rc = _hypercall1(int, event_channel_op_compat, );
> -
>   switch (cmd) {
> + case EVTCHNOP_bind_interdomain:
> + len = sizeof(struct evtchn_bind_interdomain);
> + break;
> + case EVTCHNOP_bind_virq:
> + len = sizeof(struct evtchn_bind_virq);
> + break;
> + case EVTCHNOP_bind_pirq:
> + len = sizeof(struct evtchn_bind_pirq);
> + break;
>   case EVTCHNOP_close:
> + len = sizeof(struct evtchn_close);
> + break;
>   case EVTCHNOP_send:
> + len = sizeof(struct evtchn_send);
> + break;
> + case EVTCHNOP_alloc_unbound:
> + len = sizeof(struct evtchn_alloc_unbound);
> + break;
> + case EVTCHNOP_bind_ipi:
> + len = sizeof(struct evtchn_bind_ipi);
> + break;
> + case EVTCHNOP_status:
> + len = sizeof(struct evtchn_status);
> + break;
>   case EVTCHNOP_bind_vcpu:
> + len = sizeof(struct evtchn_bind_vcpu);
> + break;
>   case EVTCHNOP_unmask:
> - /* no output */
> + len = sizeof(struct evtchn_unmask);
>   break;
> -
> -#define COPY_BACK(eop) \
> - case EVTCHNOP_##eop: \
> - memcpy(arg, , sizeof(op.u.eop)); \
> - break
> -
> - COPY_BACK(bind_interdomain);
> - COPY_BACK(bind_virq);
> - COPY_BACK(bind_pirq);
> - COPY_BACK(status);
> - COPY_BACK(alloc_unbound);
> - COPY_BACK(bind_ipi);
> -#undef COPY_BACK
> -
>   default:
> - WARN_ON(rc != -ENOSYS);
> - break;
> + return -ENOSYS;
>   }
>  
> + memcpy(, arg, len);
> + rc = _hypercall1(int, event_channel_op_compat, );
> + memcpy(arg, , len);


We don't copy back for all commands, only those that are COPY_BACK.



> +
>   return rc;
>  }
>  EXPORT_SYMBOL_GPL(xen_event_channel_op_compat);
>  
>  int xen_physdev_op_compat(int cmd, void *arg)
>  {
> - struct physdev_op op;
> + struct physdev_op op = { .cmd = cmd, };
> + size_t len;
>   int rc;
>  
> - op.cmd = cmd;
> - memcpy(, arg, sizeof(op.u));
> - rc = _hypercall1(int, physdev_op_compat, );
> -
>   switch (cmd) {
>   case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
> + len = 0;
> + break;
> + case PHYSDEVOP_irq_status_query:
> + len = sizeof(struct physdev_irq_status_query);
> + break;
>   case PHYSDEVOP_set_iopl:
> + len = sizeof(struct physdev_set_iopl);
> + break;
>   case PHYSDEVOP_set_iobitmap:
> + len = sizeof(struct physdev_set_iobitmap);
> + break;
> + case PHYSDEVOP_apic_read:
>   case PHYSDEVOP_apic_write:
> - /* no output */
> + len = sizeof(struct physdev_apic);
>   break;
> -
> -#define COPY_BACK(pop, fld) \
> - case PHYSDEVOP_##pop: \
> 

Re: [Xen-devel] [PATCH v3 0/4] xen/arm: Inject an exception to the guest rather than crashing it

[Julien Grall]

On 02/02/2018 22:48, Stefano Stabellini wrote:

Committed, thanks


I know you acked/reviewed all the patches, but it would have been nice 
to wait/give more feedback regarding Andre's valid point on patch #4.


Cheers,


On Fri, 2 Feb 2018, Julien Grall wrote:

Hi all,

This small series replaces all call to domain_crash_synchronous by injecting
an exception to the guest.

This will result to a nicer trace from the guest (no need to manually walk
the stack) and give a chance to the guest to give a bit more information on
what it was doing.

Cheers,

Julien Grall (4):
   xen/arm: traps: Merge try_handle_mmio() and handle_mmio()
   xen/arm: io: Distinguish unhandled IO from aborted one
   xen/arm: Don't crash domain on bad MMIO emulation
   xen/arm: Don't crash the domain on invalid HVC immediate

  xen/arch/arm/io.c  | 65 -
  xen/arch/arm/traps.c   | 72 +++---
  xen/arch/arm/vgic-v2.c |  2 --
  xen/arch/arm/vgic-v3-its.c |  3 --
  xen/arch/arm/vgic-v3.c |  8 --
  xen/arch/arm/vpl011.c  |  2 --
  xen/include/asm-arm/mmio.h | 11 ++-
  7 files changed, 84 insertions(+), 79 deletions(-)

--
2.11.0



--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 0/4] xen/arm: Inject an exception to the guest rather than crashing it

[Stefano Stabellini]

Committed, thanks

On Fri, 2 Feb 2018, Julien Grall wrote:
> Hi all,
> 
> This small series replaces all call to domain_crash_synchronous by injecting
> an exception to the guest.
> 
> This will result to a nicer trace from the guest (no need to manually walk
> the stack) and give a chance to the guest to give a bit more information on
> what it was doing.
> 
> Cheers,
> 
> Julien Grall (4):
>   xen/arm: traps: Merge try_handle_mmio() and handle_mmio()
>   xen/arm: io: Distinguish unhandled IO from aborted one
>   xen/arm: Don't crash domain on bad MMIO emulation
>   xen/arm: Don't crash the domain on invalid HVC immediate
> 
>  xen/arch/arm/io.c  | 65 -
>  xen/arch/arm/traps.c   | 72 
> +++---
>  xen/arch/arm/vgic-v2.c |  2 --
>  xen/arch/arm/vgic-v3-its.c |  3 --
>  xen/arch/arm/vgic-v3.c |  8 --
>  xen/arch/arm/vpl011.c  |  2 --
>  xen/include/asm-arm/mmio.h | 11 ++-
>  7 files changed, 84 insertions(+), 79 deletions(-)
> 
> -- 
> 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] 118544: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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  dd855aa430f2da9b677c145f0c625a82aaa97110
baseline version:
 xen  682760603048cc7b86782a5d3dce23a3a78ab93a

Last test of basis   118542  2018-02-02 17:01:23 Z0 days
Testing same since   118544  2018-02-02 20:01:58 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Marc Zyngier 

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
   6827606030..dd855aa430  dd855aa430f2da9b677c145f0c625a82aaa97110 -> smoke

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

[Xen-devel] [seabios test] 118532: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-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:
 seabios  14d91c353e19b7085fdbb7b2dcc43f3355665670
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   90 days
Failing since115733  2017-11-10 17:19:59 Z   84 days  101 attempts
Testing same since   118140  2018-01-17 05:09:48 Z   16 days   22 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Paul Menzel 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel 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


Not pushing.


commit 14d91c353e19b7085fdbb7b2dcc43f3355665670
Author: Marcel Apfelbaum 
Date:   Thu Jan 11 22:15:12 2018 +0200

pci: fix 'io hints' capability for RedHat PCI bridges

Commit ec6cb17f (pci: enable RedHat PCI bridges to reserve additional
 resources on PCI init)
added a new vendor specific PCI capability for RedHat PCI bridges
allowing them to reserve additional buses and/or IO/MEM space.

When adding the IO hints PCI capability to the pcie-root-port
without specifying a value for bus reservation, the subordinate bus
computation is wrong and the guest kernel gets messed up.

Fix it by returning to prev code if the value for bus
reservation is not set.

Removed also a wrong debug print "PCI: invalid QEMU resource reserve
cap offset" which appears if the 'IO hints' capability is not present.

Acked-by: Michael S. Tsirkin 

Re: [Xen-devel] [PATCH v4 0/7] xen/arm32: Branch predictor hardening (XSA-254 variant 2)

[Stefano Stabellini]

Committed, thanks

On Fri, 2 Feb 2018, Julien Grall wrote:
> Hi all,
> 
> This series provides a skeleton for mitigating branch predictor hardening for
> arm32 on exception entry.
> 
> It also implements mitigation for Cortex-A12, A15 and A17. SoC vendors with
> affected CPUs are strongly encouraged to update.
> 
> For more information about the impact of this issue and the software 
> mitigations
> for Arm processors, please see http://www.arm.com/security-update.
> 
> Cheers,
> 
> Julien Grall (7):
>   xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros
>   xen/arm32: Add missing MIDR values for Cortex-A17 and A12
>   xen/arm32: entry: Add missing trap_reset entry
>   xen/arm32: Add skeleton to harden branch predictor aliasing attacks
>   xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
>   xen/arm32: Invalidate icache on guest exist for Cortex-A15
>   xen/arm32: entry: Document the purpose of r11 in the traps handler
> 
>  xen/arch/arm/Kconfig|   3 +
>  xen/arch/arm/arm32/entry.S  | 147 
> +---
>  xen/arch/arm/arm32/traps.c  |   5 ++
>  xen/arch/arm/cpuerrata.c|  62 +
>  xen/include/asm-arm/processor.h |   4 ++
>  5 files changed, 196 insertions(+), 25 deletions(-)
> 
> -- 
> 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] 118542: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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  682760603048cc7b86782a5d3dce23a3a78ab93a
baseline version:
 xen  252c5d7892fe76f4587ba43646d4d0c56ff81288

Last test of basis   118537  2018-02-02 11:02:23 Z0 days
Testing same since   118539  2018-02-02 14:01:47 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 

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
   252c5d7892..6827606030  682760603048cc7b86782a5d3dce23a3a78ab93a -> smoke

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

Re: [Xen-devel] [PATCH v2] x86/xen: init %gs very early to avoid page faults with stack protector

[Chris Patterson]

On Fri, Feb 2, 2018 at 12:56 AM, Juergen Gross  wrote:
> On 02/02/18 01:36, Chris Patterson wrote:
>> Works great, tested it and it fixes booting Linux v4.15 kernel for me :)
>
> Can I add your "Tested-by:" to the patch when committing it?
>
>

Sure thing, have a great day.

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

[Xen-devel] [PATCH v2] xenbus: track caller request id

[Joao Martins]

Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses") optimized xenbus concurrent accesses but in doing so
broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in
charge of xenbus message exchange with the correct header and body. Now,
after the mentioned commit the replies received by application will no
longer have the header req_id echoed back as it was on request (see
specification below for reference), because that particular field is being
overwritten by kernel.

struct xsd_sockmsg
{
  uint32_t type;  /* XS_??? */
  uint32_t req_id;/* Request identifier, echoed in daemon's response.  */
  uint32_t tx_id; /* Transaction id (0 if not related to a transaction). */
  uint32_t len;   /* Length of data following this. */

  /* Generally followed by nul-terminated string(s). */
};

Before there was only one request at a time so req_id could simply be
forwarded back and forth. To allow simultaneous requests we need a
different req_id for each message thus kernel keeps a monotonic increasing
counter for this field and is written on every request irrespective of
userspace value.

Forwarding again the req_id on userspace requests is not a solution because
we would open the possibility of userspace-generated req_id colliding with
kernel ones. So this patch instead takes another route which is to
artificially keep user req_id while keeping the xenbus logic as is. We do
that by saving the original req_id before xs_send(), use the private kernel
counter as req_id and then once reply comes and was validated, we restore
back the original req_id.

Cc:  # 4.11
Fixes: fd8aa9095a ("xen: optimize xenbus driver for multiple concurrent 
xenstore accesses")
Reported-by: Bhavesh Davda 
Signed-off-by: Joao Martins 
---
Here's a link to a unit test (https://pastebin.com/2q51j2sR) where req_id of
reply and response are being asserted each request. Without this patch
the assert will fail (e.g. try it with `./xswire_reqid_test name`). But
on <= v4.10 or >= v4.11 with the fix above, it will print domain name 10
times.

Changes since v1:
 * Adjust commit message
 (Comments from Juergen on IRC)
 * Unilateraly save/restore req_id and remove xs_request_is_user()
 * Initialize req_id for kernel callers
---
 drivers/xen/xenbus/xenbus.h   | 1 +
 drivers/xen/xenbus/xenbus_comms.c | 1 +
 drivers/xen/xenbus/xenbus_xs.c| 3 +++
 3 files changed, 5 insertions(+)

diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
index 149c5e7efc89..092981171df1 100644
--- a/drivers/xen/xenbus/xenbus.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -76,6 +76,7 @@ struct xb_req_data {
struct list_head list;
wait_queue_head_t wq;
struct xsd_sockmsg msg;
+   uint32_t caller_req_id;
enum xsd_sockmsg_type type;
char *body;
const struct kvec *vec;
diff --git a/drivers/xen/xenbus/xenbus_comms.c 
b/drivers/xen/xenbus/xenbus_comms.c
index 5b081a01779d..d239fc3c5e3d 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -309,6 +309,7 @@ static int process_msg(void)
goto out;
 
if (req->state == xb_req_state_wait_reply) {
+   req->msg.req_id = req->caller_req_id;
req->msg.type = state.msg.type;
req->msg.len = state.msg.len;
req->body = state.body;
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 3e59590c7254..3f3b29398ab8 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -227,6 +227,8 @@ static void xs_send(struct xb_req_data *req, struct 
xsd_sockmsg *msg)
req->state = xb_req_state_queued;
init_waitqueue_head(>wq);
 
+   /* Save the caller req_id and restore it later in the reply */
+   req->caller_req_id = req->msg.req_id;
req->msg.req_id = xs_request_enter(req);
 
mutex_lock(_write_mutex);
@@ -310,6 +312,7 @@ static void *xs_talkv(struct xenbus_transaction t,
req->num_vecs = num_vecs;
req->cb = xs_wake_up;
 
+   msg.req_id = 0;
msg.tx_id = t.id;
msg.type = type;
msg.len = 0;
-- 
2.11.0


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

[Xen-devel] [PATCH 4.14 124/156] x86/xen: Support early interrupts in xen pv guests

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Juergen Gross 


[ Upstream commit 42b3a4cb5609de757f5445fcad18945ba9239a07 ]

Add early interrupt handlers activated by idt_setup_early_handler() to
the handlers supported by Xen pv guests. This will allow for early
WARN() calls not crashing the guest.

Suggested-by: Andy Lutomirski 
Signed-off-by: Juergen Gross 
Signed-off-by: Thomas Gleixner 
Cc: xen-devel@lists.xenproject.org
Cc: boris.ostrov...@oracle.com
Link: https://lkml.kernel.org/r/20171124084221.30172-1-jgr...@suse.com
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/x86/include/asm/segment.h |   12 
 arch/x86/mm/extable.c  |4 +++-
 arch/x86/xen/enlighten_pv.c|   37 -
 arch/x86/xen/xen-asm_64.S  |   14 ++
 4 files changed, 53 insertions(+), 14 deletions(-)

--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -236,11 +236,23 @@
  */
 #define EARLY_IDT_HANDLER_SIZE 9
 
+/*
+ * xen_early_idt_handler_array is for Xen pv guests: for each entry in
+ * early_idt_handler_array it contains a prequel in the form of
+ * pop %rcx; pop %r11; jmp early_idt_handler_array[i]; summing up to
+ * max 8 bytes.
+ */
+#define XEN_EARLY_IDT_HANDLER_SIZE 8
+
 #ifndef __ASSEMBLY__
 
 extern const char 
early_idt_handler_array[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_SIZE];
 extern void early_ignore_irq(void);
 
+#if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
+extern const char 
xen_early_idt_handler_array[NUM_EXCEPTION_VECTORS][XEN_EARLY_IDT_HANDLER_SIZE];
+#endif
+
 /*
  * Load a segment. Fall back on loading the zero segment if something goes
  * wrong.  This variant assumes that loading zero fully clears the segment.
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -212,8 +213,9 @@ void __init early_fixup_exception(struct
 * Old CPUs leave the high bits of CS on the stack
 * undefined.  I'm not sure which CPUs do this, but at least
 * the 486 DX works this way.
+* Xen pv domains are not using the default __KERNEL_CS.
 */
-   if (regs->cs != __KERNEL_CS)
+   if (!xen_pv_domain() && regs->cs != __KERNEL_CS)
goto fail;
 
/*
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -622,7 +622,7 @@ static struct trap_array_entry trap_arra
{ simd_coprocessor_error,  xen_simd_coprocessor_error,  false },
 };
 
-static bool get_trap_addr(void **addr, unsigned int ist)
+static bool __ref get_trap_addr(void **addr, unsigned int ist)
 {
unsigned int nr;
bool ist_okay = false;
@@ -644,6 +644,14 @@ static bool get_trap_addr(void **addr, u
}
}
 
+   if (nr == ARRAY_SIZE(trap_array) &&
+   *addr >= (void *)early_idt_handler_array[0] &&
+   *addr < (void *)early_idt_handler_array[NUM_EXCEPTION_VECTORS]) {
+   nr = (*addr - (void *)early_idt_handler_array[0]) /
+EARLY_IDT_HANDLER_SIZE;
+   *addr = (void *)xen_early_idt_handler_array[nr];
+   }
+
if (WARN_ON(ist != 0 && !ist_okay))
return false;
 
@@ -1261,6 +1269,21 @@ asmlinkage __visible void __init xen_sta
xen_setup_gdt(0);
 
xen_init_irq_ops();
+
+   /* Let's presume PV guests always boot on vCPU with id 0. */
+   per_cpu(xen_vcpu_id, 0) = 0;
+
+   /*
+* Setup xen_vcpu early because idt_setup_early_handler needs it for
+* local_irq_disable(), irqs_disabled().
+*
+* Don't do the full vcpu_info placement stuff until we have
+* the cpu_possible_mask and a non-dummy shared_info.
+*/
+   xen_vcpu_info_reset(0);
+
+   idt_setup_early_handler();
+
xen_init_capabilities();
 
 #ifdef CONFIG_X86_LOCAL_APIC
@@ -1294,18 +1317,6 @@ asmlinkage __visible void __init xen_sta
 */
acpi_numa = -1;
 #endif
-   /* Let's presume PV guests always boot on vCPU with id 0. */
-   per_cpu(xen_vcpu_id, 0) = 0;
-
-   /*
-* Setup xen_vcpu early because start_kernel needs it for
-* local_irq_disable(), irqs_disabled().
-*
-* Don't do the full vcpu_info placement stuff until we have
-* the cpu_possible_mask and a non-dummy shared_info.
-*/
-   xen_vcpu_info_reset(0);
-
WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_pv, xen_cpu_dead_pv));
 
local_irq_disable();
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -15,6 +15,7 @@
 
 #include 
 
+#include 
 #include 
 
 .macro xen_pv_trap name
@@ -54,6 +55,19 @@ xen_pv_trap entry_INT80_compat
 #endif
 xen_pv_trap hypervisor_callback
 
+   

Re: [Xen-devel] [PATCH v3 12/25] x86emul: abstract out XCRn accesses

[Jan Beulich]

>>> On 02.02.18 at 14:29,  wrote:
> On 07/12/17 14:07, Jan Beulich wrote:
>> --- a/tools/tests/x86_emulator/x86-emulate.c
>> +++ b/tools/tests/x86_emulator/x86-emulate.c
>> @@ -120,6 +120,19 @@ int emul_test_read_cr(
>>  return X86EMUL_UNHANDLEABLE;
>>  }
>>  
>> +int emul_test_read_xcr(
>> +unsigned int reg,
>> +uint64_t *val,
>> +struct x86_emulate_ctxt *ctxt)
>> +{
>> +uint32_t lo, hi;
>> +
>> +asm ( "xgetbv" : "=a" (lo), "=d" (hi) : "c" (reg) );
>> +*val = lo | ((uint64_t)hi << 32);
> 
> This will want a reg filter, or AFL will find that trying to read reg 2
> will explode.

How would AFL manage to do that? It doesn't fuzz the function
alone, and there's no call path leading here that would pass an
invalid value. It is the main emulator that should never call this
with a wrong value, or if it does, we should be happy for it to
be flagged by AFL rather than going silent (via some error path).

Plus - if I wanted to add proper checking here, I'd have to re-do
exactly what the emulator code around the call site does.

>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -1825,6 +1825,49 @@ static int hvmemul_write_cr(
>>  return rc;
>>  }
>>  
>> +static int hvmemul_read_xcr(
>> +unsigned int reg,
>> +uint64_t *val,
>> +struct x86_emulate_ctxt *ctxt)
>> +{
>> +uint32_t lo, hi;
>> +
>> +switch ( reg )
>> +{
>> +case 0:
>> +*val = current->arch.xcr0;
>> +return X86EMUL_OKAY;
>> +
>> +case 1:
>> +if ( !cpu_has_xgetbv1 )
>> +return X86EMUL_UNHANDLEABLE;
>> +break;
>> +
>> +default:
>> +return X86EMUL_UNHANDLEABLE;
>> +}
>> +
>> +asm ( ".byte 0x0f,0x01,0xd0" /* xgetbv */
>> +  : "=a" (lo), "=d" (hi) : "c" (reg) );
> 
> Please can we have a static inline?

Sure.

>  It needs to be volatile, because
> the result depends on unspecified other operations, which for xgetbv1
> includes any instruction which alters xsave state.

Well, yes, strictly speaking it should be volatile. Will add.

> Furthermore, does this actually return the correct result?  I'd prefer
> if we didn't have to read from hardware here, but I can't see an
> alternative.

In what way do you see it possibly producing the wrong value?

> From the guests point of view, we should at least have the guests xcr0
> in context, but we have xcr0_accum loaded, meaning that the guest is
> liable to see returned set bits which are higher than its idea of xcr0.

Nor would it make much sense to cache a dozen or more XCRs,
once there'll be that many.

>> +static int hvmemul_write_xcr(
>> +unsigned int reg,
>> +uint64_t val,
>> +struct x86_emulate_ctxt *ctxt)
>> +{
>> +HVMTRACE_LONG_2D(XCR_WRITE, reg, TRC_PAR_LONG(val));
>> +if ( likely(handle_xsetbv(reg, val) == 0) )
>> +return X86EMUL_OKAY;
>> +
>> +x86_emul_hw_exception(TRAP_gp_fault, 0, ctxt);
>> +return X86EMUL_EXCEPTION;
> 
> This exception is inconsistent with unhandleable above.  FTR, I'd expect
> all of them to be exception rather than unhandleable.

I can switch to that, sure.

>> @@ -5161,18 +5182,33 @@ x86_emulate(
>>  _regs.eflags |= X86_EFLAGS_AC;
>>  break;
>>  
>> -#ifdef __XEN__
>> -case 0xd1: /* xsetbv */
>> +case 0xd0: /* xgetbv */
>>  generate_exception_if(vex.pfx, EXC_UD);
>> -if ( !ops->read_cr || ops->read_cr(4, , ctxt) != 
>> X86EMUL_OKAY )
>> +if ( !ops->read_cr || !ops->read_xcr ||
>> + ops->read_cr(4, , ctxt) != X86EMUL_OKAY )
>>  cr4 = 0;
>>  generate_exception_if(!(cr4 & X86_CR4_OSXSAVE), EXC_UD);
>> -generate_exception_if(!mode_ring0() ||
>> -  handle_xsetbv(_regs.ecx,
>> -_regs.eax | (_regs.rdx << 
>> 32)),
>> +generate_exception_if(_regs.ecx > (vcpu_has_xgetbv1() ? 1 : 0),
>>EXC_GP, 0);
> 
> I don't think this filtering is correct.  We don't filter on the xsetbv
> side, or for the plain cr/dr index.  It should be up to the hook to
> decide whether a specific index is appropriate.

Any filtering that can be done here should be done here - this
is the central place to enforce architectural dependencies. I'd
rather add a similar check to xsetbv; in fact I'm not sure why I
didn't.

>> --- a/xen/include/asm-x86/x86-defns.h
>> +++ b/xen/include/asm-x86/x86-defns.h
>> @@ -66,4 +66,28 @@
>>  #define X86_CR4_SMAP   0x0020 /* enable SMAP */
>>  #define X86_CR4_PKE0x0040 /* enable PKE */
>>  
>> +/*
>> + * XSTATE component flags in XCR0
>> + */
>> +#define _XSTATE_FP0
>> +#define XSTATE_FP (1ULL << _XSTATE_FP)
>> +#define _XSTATE_SSE   1
>> +#define XSTATE_SSE(1ULL << _XSTATE_SSE)
>> +#define _XSTATE_YMM   2
>> +#define 

[Xen-devel] [PATCH] x86/pv: Rename pv/ro-page-fault.c to pv/emul-ro-page-fault.c

[Andrew Cooper]

To match all our other emulation handling.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/pv/Makefile  | 2 +-
 xen/arch/x86/pv/{ro-page-fault.c => emul-ro-page-fault.c} | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename xen/arch/x86/pv/{ro-page-fault.c => emul-ro-page-fault.c} (99%)

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index 65bca04..bc777e9 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -5,12 +5,12 @@ obj-y += emulate.o
 obj-y += emul-gate-op.o
 obj-y += emul-inv-op.o
 obj-y += emul-priv-op.o
+obj-y += emul-ro-page-fault.o
 obj-y += grant_table.o
 obj-y += hypercall.o
 obj-y += iret.o
 obj-y += misc-hypercalls.o
 obj-y += mm.o
-obj-y += ro-page-fault.o
 obj-$(CONFIG_PV_SHIM) += shim.o
 obj-y += traps.o
 
diff --git a/xen/arch/x86/pv/ro-page-fault.c 
b/xen/arch/x86/pv/emul-ro-page-fault.c
similarity index 99%
rename from xen/arch/x86/pv/ro-page-fault.c
rename to xen/arch/x86/pv/emul-ro-page-fault.c
index 7e0e7e8..aad5332 100644
--- a/xen/arch/x86/pv/ro-page-fault.c
+++ b/xen/arch/x86/pv/emul-ro-page-fault.c
@@ -1,5 +1,5 @@
 /**
- * arch/x86/pv/ro-page-fault.c
+ * arch/x86/pv/emul-ro-page-fault.c
  *
  * Read-only page fault emulation for PV guests
  *
-- 
2.1.4


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

[Xen-devel] [PATCH] x86/emul: Misc non-functional improvements

[Andrew Cooper]

 * Drop trailing whitespace
 * Use ARRAY_SIZE() rather than opencoding it

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 13 ++---
 xen/arch/x86/x86_emulate/x86_emulate.h | 12 ++--
 2 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index cc333a0..90c3a70 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1,21 +1,21 @@
 /**
  * x86_emulate.c
- * 
+ *
  * Generic x86 (32-bit and 64-bit) instruction decoder and emulator.
- * 
+ *
  * Copyright (c) 2005-2007 Keir Fraser
  * Copyright (c) 2005-2007 XenSource Inc.
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; If not, see .
  */
@@ -2636,8 +2636,7 @@ x86_decode(
 goto done;
 }
 }
-else if ( ext < ext_8f08 +
-sizeof(xop_table) / sizeof(*xop_table) )
+else if ( ext < ext_8f08 + ARRAY_SIZE(xop_table) )
 {
 b = insn_fetch_type(uint8_t);
 opcode |= MASK_INSR(0x8f08 + ext - ext_8f08,
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h 
b/xen/arch/x86/x86_emulate/x86_emulate.h
index ab5ef41..99a6189 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -1,21 +1,21 @@
 /**
  * x86_emulate.h
- * 
+ *
  * Generic x86 (32-bit and 64-bit) instruction decoder and emulator.
- * 
+ *
  * Copyright (c) 2005-2007 Keir Fraser
  * Copyright (c) 2005-2007 XenSource Inc.
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; If not, see .
  */
@@ -180,7 +180,7 @@ struct x86_emulate_state;
 /*
  * These operations represent the instruction emulator's interface to memory,
  * I/O ports, privileged state... pretty much everything other than GPRs.
- * 
+ *
  * NOTES:
  *  1. If the access fails (cannot emulate, or a standard access faults) then
  * it is up to the memop to propagate the fault to the guest VM via
-- 
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 24/25] x86/shadow: fully move unmap-dest into common code

[Andrew Cooper]

On 07/12/17 14:18, Jan Beulich wrote:
> @@ -1778,6 +1781,42 @@ void *sh_emulate_map_dest(struct vcpu *v
>  return map;
>  }
>  
> +/**/
> +/* Optimization: If we see two emulated writes of zeros to the same
> + * page-table without another kind of page fault in between, we guess
> + * that this is a batch of changes (for process destruction) and
> + * unshadow the page so we don't take a pagefault on every entry.  This
> + * should also make finding writeable mappings of pagetables much
> + * easier. */
> +
> +/* Look to see if this is the second emulated write in a row to this
> + * page, and unshadow if it is */

Do you mind adjusting the comment style as part of the movement?

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 v3 23/25] x86/HVM: make use of new read-modify-write emulator hook

[Andrew Cooper]

On 07/12/17 14:17, Jan Beulich wrote:
> ..., at least as far as currently possible, i.e. when a mapping can be
> obtained.
>
> Signed-off-by: Jan Beulich 
> ---
> v3: New.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1187,6 +1187,61 @@ static int hvmemul_write(
>  return X86EMUL_OKAY;
>  }
>  
> +static int hvmemul_rmw(
> +enum x86_segment seg,
> +unsigned long offset,
> +unsigned int bytes,
> +uint32_t *eflags,
> +struct x86_emulate_state *state,
> +struct x86_emulate_ctxt *ctxt)
> +{
> +struct hvm_emulate_ctxt *hvmemul_ctxt =
> +container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
> +unsigned long addr, reps = 1;
> +uint32_t pfec = PFEC_page_present | PFEC_write_access;

Drop present, and...

> +struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
> +int rc;
> +void *mapping;
> +
> +rc = hvmemul_virtual_to_linear(
> +seg, offset, bytes, , hvm_access_write, hvmemul_ctxt, );
> +if ( rc != X86EMUL_OKAY || !bytes )
> +return rc;
> +
> +if ( is_x86_system_segment(seg) )
> +pfec |= PFEC_implicit;
> +else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 )
> +pfec |= PFEC_user_mode;
> +
> +mapping = hvmemul_map_linear_addr(addr, bytes, pfec, hvmemul_ctxt);
> +if ( IS_ERR(mapping) )
> +return ~PTR_ERR(mapping);
> +
> +if ( mapping )
> +{
> +rc = x86_emul_rmw(mapping, bytes, eflags, state, ctxt);
> +hvmemul_unmap_linear_addr(mapping, addr, bytes, hvmemul_ctxt);
> +}
> +else
> +{
> +unsigned long data = 0;
> +bool_t known_gpfn = vio->mmio_access.write_access &&
> +vio->mmio_gla == (addr & PAGE_MASK);

... bool here.

Otherwise, Reviewed-by: Andrew Cooper 

> +
> +if ( bytes > sizeof(data) )
> +return X86EMUL_UNHANDLEABLE;
> +rc = hvmemul_linear_mmio_read(addr, bytes, , pfec, hvmemul_ctxt,
> +  known_gpfn);
> +if ( rc == X86EMUL_OKAY )
> +rc = x86_emul_rmw(, bytes, eflags, state, ctxt);
> +if ( rc == X86EMUL_OKAY )
> +rc = hvmemul_linear_mmio_write(addr, bytes, , pfec,
> +   hvmemul_ctxt, known_gpfn);
> +}
> +
> +return rc;
> +}
> +
>  static int hvmemul_write_discard(
>  enum x86_segment seg,
>  unsigned long offset,
> @@ -2157,6 +2212,7 @@ static const struct x86_emulate_ops hvm_
>  .read  = hvmemul_read,
>  .insn_fetch= hvmemul_insn_fetch,
>  .write = hvmemul_write,
> +.rmw   = hvmemul_rmw,
>  .cmpxchg   = hvmemul_cmpxchg,
>  .validate  = hvmemul_validate,
>  .rep_ins   = hvmemul_rep_ins,
>
>
>


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

Re: [Xen-devel] [PATCH v3 22/25] x86/HVM: do actual CMPXCHG in hvmemul_cmpxchg()

[Andrew Cooper]

On 07/12/17 14:16, Jan Beulich wrote:
> ..., at least as far as currently possible, i.e. when a mapping can be
> obtained.
>
> Signed-off-by: Jan Beulich 
> ---
> v3: New.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1296,8 +1296,83 @@ static int hvmemul_cmpxchg(
>  bool lock,
>  struct x86_emulate_ctxt *ctxt)
>  {
> -/* Fix this in case the guest is really relying on r-m-w atomicity. */
> -return hvmemul_write(seg, offset, p_new, bytes, ctxt);
> +struct hvm_emulate_ctxt *hvmemul_ctxt =
> +container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
> +struct vcpu *curr = current;
> +unsigned long addr, reps = 1;
> +uint32_t pfec = PFEC_page_present | PFEC_write_access;

I'm fairly certain from my pagetable work that passing PFEC_page_present
here is bogus, and I do have (eventual) plans to make the pagewalk
reject such values.

> +struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
> +int rc;
> +void *mapping = NULL;
> +
> +rc = hvmemul_virtual_to_linear(
> +seg, offset, bytes, , hvm_access_write, hvmemul_ctxt, );
> +if ( rc != X86EMUL_OKAY )
> +return rc;
> +
> +if ( is_x86_system_segment(seg) )
> +pfec |= PFEC_implicit;
> +else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 )
> +pfec |= PFEC_user_mode;
> +
> +mapping = hvmemul_map_linear_addr(addr, bytes, pfec, hvmemul_ctxt);
> +if ( IS_ERR(mapping) )
> +return ~PTR_ERR(mapping);
> +
> +if ( !mapping )
> +{
> +/* Fix this in case the guest is really relying on r-m-w atomicity. 
> */
> +return hvmemul_linear_mmio_write(addr, bytes, p_new, pfec,
> + hvmemul_ctxt,
> + vio->mmio_access.write_access &&
> + vio->mmio_gla == (addr & 
> PAGE_MASK));
> +}
> +
> +switch ( bytes )
> +{
> +case 1: case 2: case 4: case 8:
> +{
> +unsigned long old = 0, new = 0, cur;
> +
> +memcpy(, p_old, bytes);
> +memcpy(, p_new, bytes);
> +if ( lock )
> +cur = __cmpxchg(mapping, old, new, bytes);
> +else
> +cur = cmpxchg_local_(mapping, old, new, bytes);
> +if ( cur != old )
> +{
> +memcpy(p_old, , bytes);
> +rc = X86EMUL_CMPXCHG_FAILED;
> +}
> +break;
> +}
> +
> +case 16:
> +if ( cpu_has_cx16 )
> +{
> +__uint128_t *old = p_old, cur;
> +
> +if ( lock )
> +cur = __cmpxchg16b(mapping, old, p_new);
> +else
> +cur = cmpxchg16b_local_(mapping, old, p_new);
> +if ( cur != *old )
> +{
> +*old = cur;
> +rc = X86EMUL_CMPXCHG_FAILED;
> +}
> +break;
> +}
> +/* fall through */
> +default:

ASSERT_UNREACHABLE() ?

> +rc = X86EMUL_UNHANDLEABLE;
> +break;
> +}
> +
> +hvmemul_unmap_linear_addr(mapping, addr, bytes, hvmemul_ctxt);
> +
> +return rc;
>  }
>  
>  static int hvmemul_validate(
> --- a/xen/include/asm-x86/system.h
> +++ b/xen/include/asm-x86/system.h
> @@ -110,6 +110,38 @@ static always_inline unsigned long __cmp
>  return old;
>  }
>  
> +static always_inline unsigned long cmpxchg_local_(

unlocked_cmpxchg() ?

~Andrew

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

Re: [Xen-devel] [PATCH] xen: hypercall: fix out-of-bounds memcpy

[Dan Carpenter]

On Fri, Feb 02, 2018 at 05:11:02PM +0100, Arnd Bergmann wrote:
> On Fri, Feb 2, 2018 at 4:53 PM, Dan Carpenter  
> wrote:
> > On Fri, Feb 02, 2018 at 04:32:31PM +0100, Arnd Bergmann wrote:
> >>   switch (cmd) {
> >> + case EVTCHNOP_bind_interdomain:
> >> + len = sizeof(struct evtchn_bind_interdomain);
> >> + break;
> >
> > This was in the original code, but I'm slightly surpprised that we're
> > using a switch statement here instead of a table.  I would have thought
> > this is a fast path but I don't know xen at all.
> 
> I thought about using a table, but figured the switch statement
> had a lower risk of getting something slightly wrong during the
> conversion.
> 
> I would expect gcc to turn this into a table lookup, since all the
> constants are consecutive, but it should not really matter since
> this is only the fallback path for ancient Xen releases. When Xen
> guest support was first merged in 2007, it was already
> deprecated.
> 

Ah.  Ok.  That makes sense.

regards,
dan carpenter


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

Re: [Xen-devel] [PATCH v3 13/25] x86emul: adjust_bnd() should check XCR0

[Andrew Cooper]

On 02/02/18 16:19, Jan Beulich wrote:
 On 02.02.18 at 14:30,  wrote:
>> On 07/12/17 14:08, Jan Beulich wrote:
>>> Experimentally MPX instructions have been confirmed to behave as NOPs
>>> unless both related XCR0 bits are set to 1. By implication branches
>>> then also don't clear BNDn.
>>>
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -2143,12 +2143,16 @@ static bool umip_active(struct x86_emula
>>>  static void adjust_bnd(struct x86_emulate_ctxt *ctxt,
>>> const struct x86_emulate_ops *ops, enum vex_pfx pfx)
>>>  {
>>> -uint64_t bndcfg;
>>> +uint64_t xcr0, bndcfg;
>>>  int rc;
>>>  
>>>  if ( pfx == vex_f2 || !cpu_has_mpx || !vcpu_has_mpx() )
>>>  return;
>>>  
>>> +if ( !ops->read_xcr || ops->read_xcr(0, , ctxt) != X86EMUL_OKAY ||
>>> + !(xcr0 & XSTATE_BNDREGS) || !(xcr0 & XSTATE_BNDCSR) )
>> !(xcr0 & (XSTATE_BNDREGS | XSTATE_BNDCSR)) ?
> No, I mean "if either bit is clear", not "if both bits are clear". I think
> we had discussed before that both bits need to be 1 in order for
> bounds checking to actually work.
>
>> Otherwise, Reviewed-by: Andrew Cooper 
> Please clarify this in light of the above.

Architecturally, they can't be different, which is why the above logic
looks suspicious.

Given that the actual isn't wrong, I won't object, but it does look
wrong to compare them individually.

~Andrew

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

Re: [Xen-devel] [PATCH v1 2/4] hvm/svm: Enable Breakpoint events

[Alexandru Stefan ISAILA]

On Vi, 2018-02-02 at 15:58 +, Andrew Cooper wrote:
> On 02/02/18 09:37, Alexandru Isaila wrote:
> >
> > This commit enables the breakpoint events for svm.
> >
> > Signed-off-by: Alexandru Isaila 
> > ---
> >  xen/arch/x86/hvm/svm/svm.c| 52
> > ---
> >  xen/include/asm-x86/monitor.h |  3 ++-
> >  2 files changed, 46 insertions(+), 9 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/svm/svm.c
> > b/xen/arch/x86/hvm/svm/svm.c
> > index dcbd550..14a5f60 100644
> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> > @@ -59,6 +59,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  void svm_asm_do_resume(void);
> > @@ -1079,7 +1080,8 @@ static void svm_ctxt_switch_to(struct vcpu
> > *v)
> >  static void noreturn svm_do_resume(struct vcpu *v)
> >  {
> >  struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> > -bool_t debug_state = v->domain->debugger_attached;
> > +bool_t debug_state = v->domain->debugger_attached
> > +|| v->domain-
> > >arch.monitor.software_breakpoint_enabled;
> As a minor note, please clean up bool_t => bool as you end up making
> changes.
Will do, must of passed it.
>
> >
> >  bool_t vcpu_guestmode = 0;
> >  struct vlapic *vlapic = vcpu_vlapic(v);
> >
> > @@ -2407,6 +2409,23 @@ static bool svm_get_pending_event(struct
> > vcpu *v, struct x86_event *info)
> >  return true;
> >  }
> >
> > +static void svm_propagate_intr(struct vcpu *v, unsigned long
> > insn_len)
> > +{
> > +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> > +struct x86_event event = {
> > +.vector = vmcb->eventinj.fields.type,
> > +.type = vmcb->eventinj.fields.type,
> > +.error_code = vmcb->exitinfo1,
> > +};
> > +
> > +if ( event.type >= X86_EVENTTYPE_SW_INTERRUPT )
> > +event.insn_len = insn_len;
> > +else
> > +event.insn_len = 0;
> IIRC, you need to always set insn_len.  The length handling is vastly
> complicated (depends on event type and hardware availability, and in
> some cases needs emulating anyway), but the lower injection levels
> should DTRT.
>
> If they don't, can you provide a concrete example which doesn't work
> and
> we can see about what to do.
I've copied the functionality form vmx but I can remove the if
statement and always add the inst_len to the event.

Alex


This email was scanned by Bitdefender
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 16/25] x86emul: support SWAPGS

[Jan Beulich]

>>> On 02.02.18 at 14:41,  wrote:
> On 07/12/17 14:11, Jan Beulich wrote:
>> Signed-off-by: Jan Beulich 
>> ---
>> v3: New.
>>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -5047,6 +5047,24 @@ x86_emulate(
>>  goto done;
>>  break;
>>  
>> +case 0xf8: /* swapgs */
>> +generate_exception_if(!mode_64bit(), EXC_UD);
>> +generate_exception_if(!mode_ring0(), EXC_GP, 0);
>> +fail_if(!ops->read_segment || !ops->read_msr ||
>> +!ops->write_segment || !ops->write_msr);
>> +if ( (rc = ops->read_segment(x86_seg_gs, ,
>> + ctxt)) != X86EMUL_OKAY ||
>> + (rc = ops->read_msr(MSR_SHADOW_GS_BASE, _val,
>> + ctxt)) != X86EMUL_OKAY ||
>> + (rc = ops->write_msr(MSR_SHADOW_GS_BASE, sreg.base,
>> +  ctxt)) != X86EMUL_OKAY )
> 
> We need to unwind this write in the case of write_segment failing, or
> when the instruction restarts, state will be corrupt.

We don't do similar restoring anywhere else iirc, so I'm not sure I
want to start doing so here. Multi-element updates really need to
be converted to go through a staging layer, where the checks
are done right away, but the commit happens only at the end.
One of the reasons I decided against doing what you suggest
(indeed I had considered that) is that this other write may then
be failing, too. Let me know.

Jan

>> +goto done;
>> +sreg.base = msr_val;
>> +if ( (rc = ops->write_segment(x86_seg_gs, ,
>> +  ctxt)) != X86EMUL_OKAY )
>> +goto done;
>> +break;
>> +
>>  case 0xf9: /* rdtscp */
>>  fail_if(ops->read_msr == NULL);
>>  if ( (rc = ops->read_msr(MSR_TSC_AUX,
>>
>>
>>




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

[Xen-devel] [xen-unstable-smoke test] 118539: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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  682760603048cc7b86782a5d3dce23a3a78ab93a
baseline version:
 xen  252c5d7892fe76f4587ba43646d4d0c56ff81288

Last test of basis   118537  2018-02-02 11:02:23 Z0 days
Testing same since   118539  2018-02-02 14:01:47 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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


Not pushing.


commit 682760603048cc7b86782a5d3dce23a3a78ab93a
Author: Andrew Cooper 
Date:   Thu Feb 1 19:51:23 2018 +

x86/emul: Add structure names to opcode tables

No functional change, but it makes the diff context line more helpful when
reviewing patches which alter the opcode tables.  e.g. Consider:

  --- a/xen/arch/x86/x86_emulate/x86_emulate.c
  +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
  @@ -370,7 +370,7 @@ static const struct {
   [0x0c ... 0x0f] = { .simd_size = simd_packed_fp },
   [0x10] = { .simd_size = simd_packed_int },
   [0x13] = { .simd_size = simd_other, .two_op = 1 },
  -[0x14 ... 0x15] = { .simd_size = simd_packed_fp },
  +[0x14 ... 0x16] = { .simd_size = simd_packed_fp },
   [0x17] = { .simd_size = simd_packed_int, .two_op = 1 },
   [0x18 ... 0x19] = { .simd_size = simd_scalar_fp, .two_op = 1 },
   [0x1a] = { .simd_size = simd_128, .two_op = 1 },

which is entirely ambiguous between 0f38 and 0f3a, and the same diff with 
this
change in place:

  --- a/xen/arch/x86/x86_emulate/x86_emulate.c
  +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
  @@ -370,7 +370,7 @@ static const struct ext0f38_table {
   [0x0c ... 0x0f] = { .simd_size = simd_packed_fp },
   [0x10] = { .simd_size = simd_packed_int },
   [0x13] = { .simd_size = simd_other, .two_op = 1 },
  -[0x14 ... 0x15] = { .simd_size = simd_packed_fp },
  +[0x14 ... 0x16] = { .simd_size = simd_packed_fp },
   [0x17] = { .simd_size = simd_packed_int, .two_op = 1 },
   [0x18 ... 0x19] = { .simd_size = simd_scalar_fp, .two_op = 1 },
   [0x1a] = { .simd_size = simd_128, .two_op = 1 },

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
(qemu changes not included)

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

Re: [Xen-devel] [PATCH v3 21/25] x86emul: add read-modify-write hook

[Andrew Cooper]

On 07/12/17 14:16, Jan Beulich wrote:
> In order to correctly emulate read-modify-write insns, especially
> LOCKed ones, we should not issue reads and writes separately. Use a
> new hook to combine both, and don't uniformly read the memory
> destination anymore. Instead, DstMem opcodes without Mov now need to
> have done so in their respective case blocks.
>
> Also strip bogus _ prefixes from macro parameters when this only affects
> lines which are being changed anyway.
>
> In the test harness, besides some re-ordering to facilitate running a
> few tests twice (one without and a second time with the .rmw hook in
> place), tighten a few EFLAGS checks and add a test for NOT with memory
> operand (in particular to verify EFLAGS don't get altered there).
>
> For now make use of the hook optional for callers; eventually we may
> want to consider making this mandatory.
>
> Signed-off-by: Jan Beulich 
> ---
> v3: New.
> ---
> TBD: Do we want to also support non-lockable RMW insns in the new hook
>  and helper (SHL & friends, SHLD, SHRD)?

What would this achieve?  I suppose it would avoid a double pagewalk.

>
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -3356,35 +3388,83 @@ x86_emulate(
>  unsigned int i, n;
>  unsigned long dummy;
>  
> -case 0x00 ... 0x05: add: /* add */
> -emulate_2op_SrcV("add", src, dst, _regs.eflags);
> +case 0x00: case 0x01: add: /* add reg,mem */
> +if ( ops->rmw && dst.type == OP_MEM )
> +state->rmw = rmw_add;
> +else
> +{
> +case 0x02 ... 0x05: /* add */

I think it would help to identify reg,reg specifically in these comments.

> +emulate_2op_SrcV("add", src, dst, _regs.eflags);
> +}
>  break;
>  
> -case 0x08 ... 0x0d: or:  /* or */
> -emulate_2op_SrcV("or", src, dst, _regs.eflags);
> +case 0x08: case 0x09: or: /* or reg,mem */
> +if ( ops->rmw && dst.type == OP_MEM )
> +state->rmw = rmw_or;
> +else
> +{
> +case 0x0a ... 0x0d: /* or */
> +emulate_2op_SrcV("or", src, dst, _regs.eflags);
> +}
>  break;
>  
> -case 0x10 ... 0x15: adc: /* adc */
> -emulate_2op_SrcV("adc", src, dst, _regs.eflags);
> +case 0x10: case 0x11: adc: /* adc reg,mem */
> +if ( ops->rmw && dst.type == OP_MEM )
> +state->rmw = rmw_adc;
> +else
> +{
> +case 0x12 ... 0x15: /* adc */
> +emulate_2op_SrcV("adc", src, dst, _regs.eflags);
> +}
>  break;
>  
> -case 0x18 ... 0x1d: sbb: /* sbb */
> -emulate_2op_SrcV("sbb", src, dst, _regs.eflags);
> +case 0x18: case 0x19: sbb: /* sbb reg,mem */
> +if ( ops->rmw && dst.type == OP_MEM )
> +state->rmw = rmw_sbb;
> +else
> +{
> +case 0x1a ... 0x1d: /* sbb */
> +emulate_2op_SrcV("sbb", src, dst, _regs.eflags);
> +}
>  break;
>  
> -case 0x20 ... 0x25: and: /* and */
> -emulate_2op_SrcV("and", src, dst, _regs.eflags);
> +case 0x20: case 0x21: and: /* and reg,mem */
> +if ( ops->rmw && dst.type == OP_MEM )
> +state->rmw = rmw_and;
> +else
> +{
> +case 0x22 ... 0x25: /* and */
> +emulate_2op_SrcV("and", src, dst, _regs.eflags);
> +}
>  break;
>  
> -case 0x28 ... 0x2d: sub: /* sub */
> -emulate_2op_SrcV("sub", src, dst, _regs.eflags);
> +case 0x28: case 0x29: sub: /* sub reg,mem */
> +if ( ops->rmw && dst.type == OP_MEM )
> +state->rmw = rmw_sub;
> +else
> +{
> +case 0x2a ... 0x2d: /* sub */
> +emulate_2op_SrcV("sub", src, dst, _regs.eflags);
> +}
>  break;
>  
> -case 0x30 ... 0x35: xor: /* xor */
> -emulate_2op_SrcV("xor", src, dst, _regs.eflags);
> +case 0x30: case 0x31: xor: /* xor reg,mem */
> +if ( ops->rmw && dst.type == OP_MEM )
> +state->rmw = rmw_xor;
> +else
> +{
> +case 0x32 ... 0x35: /* xor */
> +emulate_2op_SrcV("xor", src, dst, _regs.eflags);
> +}
>  break;
>  
> -case 0x38 ... 0x3d: cmp: /* cmp */
> +case 0x38: case 0x39: cmp: /* cmp reg,mem */
> +if ( ops->rmw && dst.type == OP_MEM &&
> + (rc = read_ulong(dst.mem.seg, dst.mem.off, ,
> +  dst.bytes, ctxt, ops)) != X86EMUL_OKAY )

Why does rmw matter here? cmp doesn't write to its operands.

> +goto done;
> +/* fall through */
> +case 0x3a ... 0x3d: /* cmp */
>  generate_exception_if(lock_prefix, EXC_UD);
>  emulate_2op_SrcV("cmp", src, dst, _regs.eflags);
>  dst.type = OP_NONE;
> @@ -3700,6 +3780,13 @@ x86_emulate(
>  break;
>  
>  case 0x86 ... 0x87: xchg: /* xchg */
> +/* The lock prefix is implied for this insn. */
> +  

Re: [Xen-devel] [PATCH v3 13/25] x86emul: adjust_bnd() should check XCR0

[Jan Beulich]

>>> On 02.02.18 at 14:30,  wrote:
> On 07/12/17 14:08, Jan Beulich wrote:
>> Experimentally MPX instructions have been confirmed to behave as NOPs
>> unless both related XCR0 bits are set to 1. By implication branches
>> then also don't clear BNDn.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -2143,12 +2143,16 @@ static bool umip_active(struct x86_emula
>>  static void adjust_bnd(struct x86_emulate_ctxt *ctxt,
>> const struct x86_emulate_ops *ops, enum vex_pfx pfx)
>>  {
>> -uint64_t bndcfg;
>> +uint64_t xcr0, bndcfg;
>>  int rc;
>>  
>>  if ( pfx == vex_f2 || !cpu_has_mpx || !vcpu_has_mpx() )
>>  return;
>>  
>> +if ( !ops->read_xcr || ops->read_xcr(0, , ctxt) != X86EMUL_OKAY ||
>> + !(xcr0 & XSTATE_BNDREGS) || !(xcr0 & XSTATE_BNDCSR) )
> 
> !(xcr0 & (XSTATE_BNDREGS | XSTATE_BNDCSR)) ?

No, I mean "if either bit is clear", not "if both bits are clear". I think
we had discussed before that both bits need to be 1 in order for
bounds checking to actually work.

> Otherwise, Reviewed-by: Andrew Cooper 

Please clarify this in light of the above.

Jan


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

Re: [Xen-devel] [PATCH v3 10/25] x86emul: support 3DNow! insns

[Andrew Cooper]

On 02/02/18 15:22, Jan Beulich wrote:
 On 02.02.18 at 14:02,  wrote:
>> On 07/12/17 14:05, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -355,6 +355,36 @@ static const struct {
>>>  [0xff] = { ModRM }
>>>  };
>>>  
>>> +static const uint16_t _3dnow_table[16] = {
>> Comment explaining how these mappings work?  It looks like nibble
>> splits, but I still can't work out how to crossreference with the opcode
>> tables.
> Will do. Array index is high opcode nibble, bit index is low opcode
> nibble.
>
>>> +[0x0] = (1 << 0xd) /* pi2fd */,
>>> +[0x1] = (1 << 0xd) /* pf2id */,
>>> +[0x9] = (1 << 0x0) /* pfcmpge */ |
>>> +(1 << 0x4) /* pfmin */ |
>>> +(1 << 0x6) /* pfrcp */ |
>>> +(1 << 0x7) /* pfrsqrt */ |
>>> +(1 << 0xa) /* pfsub */ |
>>> +(1 << 0xe) /* pfadd */,
>>> +[0xa] = (1 << 0x0) /* pfcmpge */ |
>>> +(1 << 0x4) /* pfmax */ |
>>> +(1 << 0x6) /* pfrcpit1 */ |
>>> +(1 << 0x7) /* pfrsqit1 */ |
>>> +(1 << 0xa) /* pfsubr */ |
>>> +(1 << 0xe) /* pfacc */,
>>> +[0xb] = (1 << 0x0) /* pfcmpeq */ |
>>> +(1 << 0x4) /* pfmul */ |
>>> +(1 << 0x6) /* pfrcpit2 */ |
>>> +(1 << 0x7) /* pmulhrw */ |
>>> +(1 << 0xf) /* pavgusb */,
>>> +};
>>> +
>>> +static const uint16_t _3dnow_ext_table[16] = {
>>> +[0x1] = (1 << 0xd) /* pi2fw */,
>>> +[0x1] = (1 << 0xc) /* pf2iw */,
>> You presumably want an | in here instead?
> No, the first of the two lines is wrong and needs to be
>
> [0x0] = (1 << 0xc) /* pi2fw */,
>
> (wrong post-copy-and-paste editing).
>
>>> @@ -5505,6 +5537,26 @@ x86_emulate(
>>>  case X86EMUL_OPC(0x0f, 0x19) ... X86EMUL_OPC(0x0f, 0x1f): /* nop */
>>>  break;
>> 0f 0d prefetches?  They are 3DNow instructions, but available on later
>> processors.
> And it is for that latter reason (I assume) that we have these
> already.

Ah.  I see now that they are just out of context above this hunk.

Sorry for the noise.

~Andrew

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

Re: [Xen-devel] [PATCH] xen: hypercall: fix out-of-bounds memcpy

[Arnd Bergmann]

On Fri, Feb 2, 2018 at 4:53 PM, Dan Carpenter  wrote:
> On Fri, Feb 02, 2018 at 04:32:31PM +0100, Arnd Bergmann wrote:

>> --- a/drivers/xen/fallback.c
>> +++ b/drivers/xen/fallback.c
>> @@ -7,75 +7,87 @@
>>
>>  int xen_event_channel_op_compat(int cmd, void *arg)
>>  {
>> - struct evtchn_op op;
>> + struct evtchn_op op = { .cmd = cmd, };
>> + size_t len;
>>   int rc;
>>
>> - op.cmd = cmd;
>> - memcpy(, arg, sizeof(op.u));
>> - rc = _hypercall1(int, event_channel_op_compat, );
>> -
>>   switch (cmd) {
>> + case EVTCHNOP_bind_interdomain:
>> + len = sizeof(struct evtchn_bind_interdomain);
>> + break;
>
> This was in the original code, but I'm slightly surpprised that we're
> using a switch statement here instead of a table.  I would have thought
> this is a fast path but I don't know xen at all.

I thought about using a table, but figured the switch statement
had a lower risk of getting something slightly wrong during the
conversion.

I would expect gcc to turn this into a table lookup, since all the
constants are consecutive, but it should not really matter since
this is only the fallback path for ancient Xen releases. When Xen
guest support was first merged in 2007, it was already
deprecated.

  Arnd

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

Re: [Xen-devel] [PATCH v3 08/25] x86emul: add tables for XOP 08 and 09 extension spaces

[Andrew Cooper]

On 02/02/18 15:15, Jan Beulich wrote:
 On 02.02.18 at 12:43,  wrote:
>> On 07/12/17 14:04, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -458,6 +458,20 @@ static const opcode_desc_t xop_table[] =
>>>  DstReg|SrcImm|ModRM,
>>>  };
>>>  
>>> +static const struct {
>>> +uint8_t simd_size:5;
>>> +uint8_t two_op:1;
>>> +uint8_t four_op:1;
>>> +} ext8f08_table[256] = {
>>> +};
>>> +
>>> +static const struct {
>>> +uint8_t simd_size:5;
>>> +uint8_t two_op:1;
>>> +} ext8f09_table[256] = {
>>> +[0x01 ... 0x02] = { .two_op = 1 },
>>> +};
>>> +
>> What about 8f0a ?  We've got emulation for bextr already, and might want
>> to consider #GRP4 seeing as we expose LWP to guests.
> I'd prefer to convert that to a table at the time we need it.
>
>>> @@ -2726,7 +2740,7 @@ x86_decode(
>>>  }
>>>  break;
>>>  
>>> -case vex_0f38:
>>> +case ext_0f38:
>>>  d = ext0f38_table[b].to_mem ? DstMem | SrcReg
>>>  : DstReg | SrcMem;
>>>  if ( ext0f38_table[b].two_op )
>>> @@ -2736,7 +2750,14 @@ x86_decode(
>>>  state->simd_size = ext0f38_table[b].simd_size;
>>>  break;
>>>  
>>> -case vex_0f3a:
>>> +case ext_8f09:
>>> +if ( ext8f09_table[b].two_op )
>>> +d |= TwoOp;
>>> +state->simd_size = ext8f09_table[b].simd_size;
>>> +break;
>>> +
>>> +case ext_0f3a:
>>> +case ext_8f08:
>>>  /*
>>>   * Cannot update d here yet, as the immediate operand still
>>>   * needs fetching.
>>> @@ -2928,6 +2949,15 @@ x86_decode(
>>>  break;
>>>  
>>>  case ext_8f08:
>>> +d = DstReg | SrcMem;
>>> +if ( ext8f08_table[b].two_op )
>>> +d |= TwoOp;
>>> +else if ( ext8f08_table[b].four_op && !mode_64bit() )
>>> +imm1 &= 0x7f;
>>> +state->desc = d;
>>> +state->simd_size = ext8f08_table[b].simd_size;
>>> +break;
>> I presume that these don't actually impact our currently implemented XOP
>> instructions?
> No - as the description says, the patch converts the existing ones,
> it doesn't break them (and the test harness continuing to work
> confirms this).

Ok, in which case Reviewed-by: Andrew Cooper
, conditional on the tables gaining names
(which you said you've already done IIRC).

~Andrew

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

Re: [Xen-devel] [PATCH v1 2/4] hvm/svm: Enable Breakpoint events

[Andrew Cooper]

On 02/02/18 09:37, Alexandru Isaila wrote:
> This commit enables the breakpoint events for svm.
>
> Signed-off-by: Alexandru Isaila 
> ---
>  xen/arch/x86/hvm/svm/svm.c| 52 
> ---
>  xen/include/asm-x86/monitor.h |  3 ++-
>  2 files changed, 46 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index dcbd550..14a5f60 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -59,6 +59,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  void svm_asm_do_resume(void);
> @@ -1079,7 +1080,8 @@ static void svm_ctxt_switch_to(struct vcpu *v)
>  static void noreturn svm_do_resume(struct vcpu *v)
>  {
>  struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> -bool_t debug_state = v->domain->debugger_attached;
> +bool_t debug_state = v->domain->debugger_attached
> +|| v->domain->arch.monitor.software_breakpoint_enabled;

As a minor note, please clean up bool_t => bool as you end up making
changes.

>  bool_t vcpu_guestmode = 0;
>  struct vlapic *vlapic = vcpu_vlapic(v);
>  
> @@ -2407,6 +2409,23 @@ static bool svm_get_pending_event(struct vcpu *v, 
> struct x86_event *info)
>  return true;
>  }
>  
> +static void svm_propagate_intr(struct vcpu *v, unsigned long insn_len)
> +{
> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> +struct x86_event event = {
> +.vector = vmcb->eventinj.fields.type,
> +.type = vmcb->eventinj.fields.type,
> +.error_code = vmcb->exitinfo1,
> +};
> +
> +if ( event.type >= X86_EVENTTYPE_SW_INTERRUPT )
> +event.insn_len = insn_len;
> +else
> +event.insn_len = 0;

IIRC, you need to always set insn_len.  The length handling is vastly
complicated (depends on event type and hardware availability, and in
some cases needs emulating anyway), but the lower injection levels
should DTRT.

If they don't, can you provide a concrete example which doesn't work and
we can see about what to do.

> +
> +hvm_inject_event();
> +}
> +
>  static struct hvm_function_table __initdata svm_function_table = {
>  .name = "SVM",
>  .cpu_up_prepare   = svm_cpu_up_prepare,
> @@ -2619,14 +2638,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>  break;
>  
>  case VMEXIT_EXCEPTION_BP:
> -if ( !v->domain->debugger_attached )
> -goto unexpected_exit_type;
> -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. 
> */
> -if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
> +inst_len = __get_instruction_length(v, INSTR_INT3);
> +
> +if ( inst_len == 0 )
>  break;
> -__update_guest_eip(regs, inst_len);
> -current->arch.gdbsx_vcpu_event = TRAP_int3;
> -domain_pause_for_debugger();
> +
> +if ( !v->domain->debugger_attached )
> +{
> + /* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. 
> */
> +int rc;
> +
> +rc = hvm_monitor_debug(regs->rip,
> +   HVM_MONITOR_SOFTWARE_BREAKPOINT,
> +   X86_EVENTTYPE_SW_EXCEPTION,
> +   inst_len);
> +if ( rc < 0 )
> +goto unexpected_exit_type;
> +if ( !rc )
> +svm_propagate_intr(v, inst_len);
> +}
> +else
> +{
> +__update_guest_eip(regs, inst_len);
> +current->arch.gdbsx_vcpu_event = TRAP_int3;
> +domain_pause_for_debugger();
> +}
>  break;
>  
>  case VMEXIT_EXCEPTION_NM:
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index 3706b7a..68a210a 100644
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -94,7 +94,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
> domain *d)
>  }
>  else if ( cpu_has_svm )
>  {
> -capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
> +capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT);

Please introduce an extra pair of brackets around the whole thing, so
automatic indentation in most editors DTRT.

~Andrew

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

Re: [Xen-devel] [PATCH] xen: hypercall: fix out-of-bounds memcpy

[Dan Carpenter]

On Fri, Feb 02, 2018 at 04:32:31PM +0100, Arnd Bergmann wrote:
> The legacy hypercall handlers were originally added with
> a comment explaining that "copying the argument structures in
> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
> variable is sufficiently safe" and only made sure to not write
> past the end of the argument structure, the checks in linux/string.h
> disagree with that, when link-time optimizations are used:
> 
> In function 'memcpy',
> inlined from 'pirq_query_unmask' at drivers/xen/fallback.c:53:2,
> inlined from '__startup_pirq' at drivers/xen/events/events_base.c:529:2,
> inlined from 'restore_pirqs' at drivers/xen/events/events_base.c:1439:3,
> inlined from 'xen_irq_resume' at drivers/xen/events/events_base.c:1581:2:
> include/linux/string.h:350:3: error: call to '__read_overflow2' declared with 
> attribute error: detected read beyond size of object passed as 2nd parameter
>__read_overflow2();
>^
> make[3]: *** [ccLujFNx.ltrans15.ltrans.o] Error 1
> make[3]: Target 'all' not remade because of errors.
> lto-wrapper: fatal error: make returned 2 exit status
> compilation terminated.
> ld: error: lto-wrapper failed
> 

It was a more naive era.  :P

> This changes the functions so that each argument is accessed with
> exactly the correct length based on the command code.
> 
> Fixes: cf47a83fb06e ("xen/hypercall: fix hypercall fallback code for very old 
> hypervisors")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/xen/fallback.c | 94 
> --
>  1 file changed, 53 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
> index b04fb64c5a91..eded8dd821ad 100644
> --- a/drivers/xen/fallback.c
> +++ b/drivers/xen/fallback.c
> @@ -7,75 +7,87 @@
>  
>  int xen_event_channel_op_compat(int cmd, void *arg)
>  {
> - struct evtchn_op op;
> + struct evtchn_op op = { .cmd = cmd, };
> + size_t len;
>   int rc;
>  
> - op.cmd = cmd;
> - memcpy(, arg, sizeof(op.u));
> - rc = _hypercall1(int, event_channel_op_compat, );
> -
>   switch (cmd) {
> + case EVTCHNOP_bind_interdomain:
> + len = sizeof(struct evtchn_bind_interdomain);
> + break;

This was in the original code, but I'm slightly surpprised that we're
using a switch statement here instead of a table.  I would have thought
this is a fast path but I don't know xen at all.

regards,
dan carpenter


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

Re: [Xen-devel] [PATCH v1 2/4] hvm/svm: Enable Breakpoint events

[Tamas K Lengyel]

On Fri, Feb 2, 2018 at 2:37 AM, Alexandru Isaila
 wrote:
> This commit enables the breakpoint events for svm.
>
> Signed-off-by: Alexandru Isaila 
> ---
>  xen/arch/x86/hvm/svm/svm.c| 52 
> ---
>  xen/include/asm-x86/monitor.h |  3 ++-
>  2 files changed, 46 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index dcbd550..14a5f60 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -59,6 +59,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  void svm_asm_do_resume(void);
> @@ -1079,7 +1080,8 @@ static void svm_ctxt_switch_to(struct vcpu *v)
>  static void noreturn svm_do_resume(struct vcpu *v)
>  {
>  struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> -bool_t debug_state = v->domain->debugger_attached;
> +bool_t debug_state = v->domain->debugger_attached
> +|| v->domain->arch.monitor.software_breakpoint_enabled;
>  bool_t vcpu_guestmode = 0;
>  struct vlapic *vlapic = vcpu_vlapic(v);
>
> @@ -2407,6 +2409,23 @@ static bool svm_get_pending_event(struct vcpu *v, 
> struct x86_event *info)
>  return true;
>  }
>
> +static void svm_propagate_intr(struct vcpu *v, unsigned long insn_len)
> +{
> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> +struct x86_event event = {
> +.vector = vmcb->eventinj.fields.type,
> +.type = vmcb->eventinj.fields.type,
> +.error_code = vmcb->exitinfo1,
> +};
> +
> +if ( event.type >= X86_EVENTTYPE_SW_INTERRUPT )
> +event.insn_len = insn_len;seems
> +else
> +event.insn_len = 0;
> +
> +hvm_inject_event();
> +}
> +
>  static struct hvm_function_table __initdata svm_function_table = {
>  .name = "SVM",
>  .cpu_up_prepare   = svm_cpu_up_prepare,
> @@ -2619,14 +2638,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>  break;
>
>  case VMEXIT_EXCEPTION_BP:
> -if ( !v->domain->debugger_attached )
> -goto unexpected_exit_type;
> -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. 
> */
> -if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
> +inst_len = __get_instruction_length(v, INSTR_INT3);
> +
> +if ( inst_len == 0 )
>  break;
> -__update_guest_eip(regs, inst_len);
> -current->arch.gdbsx_vcpu_event = TRAP_int3;
> -domain_pause_for_debugger();
> +
> +if ( !v->domain->debugger_attached )

I think this would be easier to follow if you switched it around.

> +{
> + /* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. 
> */
> +int rc;
> +
> +rc = hvm_monitor_debug(regs->rip,
> +   HVM_MONITOR_SOFTWARE_BREAKPOINT,
> +   X86_EVENTTYPE_SW_EXCEPTION,
> +   inst_len);
> +if ( rc < 0 )
> +goto unexpected_exit_type;
> +if ( !rc )
> +svm_propagate_intr(v, inst_len);
> +}
> +else
> +{
> +__update_guest_eip(regs, inst_len);
> +current->arch.gdbsx_vcpu_event = TRAP_int3;
> +domain_pause_for_debugger();
> +}
>  break;
>
>  case VMEXIT_EXCEPTION_NM:
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index 3706b7a..68a210a 100644
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -94,7 +94,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
> domain *d)
>  }
>  else if ( cpu_has_svm )
>  {
> -capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
> +capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT);

Since breakpoints are also supported for both svm and vmx, you can
just set it once, no need for the extra if block.

Tamas

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

Re: [Xen-devel] [PATCH RFC v2 11/12] x86: modify interrupt handlers to support stack switching

[Juergen Gross]

On 31/01/18 11:36, Jan Beulich wrote:
 On 30.01.18 at 18:19,  wrote:
>> On 30/01/18 17:07, Jan Beulich wrote:
>> On 22.01.18 at 13:32,  wrote:
 --- a/xen/arch/x86/x86_64/asm-offsets.c
 +++ b/xen/arch/x86/x86_64/asm-offsets.c
 @@ -137,6 +137,10 @@ void __dummy__(void)
  OFFSET(CPUINFO_processor_id, struct cpu_info, processor_id);
  OFFSET(CPUINFO_current_vcpu, struct cpu_info, current_vcpu);
  OFFSET(CPUINFO_cr4, struct cpu_info, cr4);
 +OFFSET(CPUINFO_stack_bottom_cpu, struct cpu_info, stack_bottom_cpu);
 +OFFSET(CPUINFO_flags, struct cpu_info, flags);
 +DEFINE(ASM_ON_VCPUSTACK, ON_VCPUSTACK);
 +DEFINE(ASM_VCPUSTACK_ACTIVE, VCPUSTACK_ACTIVE);
>>>
>>> Seeing their uses in asm_defns.h it's not really clear to me why
>>> you can't use the C constants there, the more that those uses
>>> are inside C macros (which perhaps would better be assembler
>>> ones). The latter doesn't even appear to be used in assembly
>>> code.
>>
>> I tried using the C constants but this led to rather nasty include
>> dependencies.
> 
> Hmm, I can imagine this to be the case, but I'd like to have more
> detail for justification. current.h itself doesn't have that many
> dependencies, and if half-way reasonable disentangling our
> headers may be the better choice.

Some #ifndef __ASSEMBLY__ made it work.

I think I had the defines in another header in the beginning and just
didn't switch back after moving them to current.h.

> 
>> ASM_VCPUSTACK_ACTIVE will be used when %cr3 switching is being added.
> 
> Please introduce it when needed.
> 
 --- a/xen/common/wait.c
 +++ b/xen/common/wait.c
 @@ -122,10 +122,10 @@ void wake_up_all(struct waitqueue_head *wq)
  
  static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
  {
 -struct cpu_info *cpu_info = get_cpu_info();
 +struct cpu_user_regs *user_regs = guest_cpu_user_regs();
  struct vcpu *curr = current;
  unsigned long dummy;
 -u32 entry_vector = cpu_info->guest_cpu_user_regs.entry_vector;
 +u32 entry_vector = user_regs->entry_vector;
  
  ASSERT(wqv->esp == 0);
  
 @@ -160,7 +160,7 @@ static void __prepare_to_wait(struct waitqueue_vcpu 
 *wqv)
  "pop %%r11; pop %%r10; pop %%r9;  pop %%r8;"
  "pop %%rbp; pop %%rdx; pop %%rbx; pop %%rax"
  : "=" (wqv->esp), "=" (dummy), "=" (dummy)
 -: "i" (PAGE_SIZE), "0" (0), "1" (cpu_info), "2" (wqv->stack)
 +: "i" (PAGE_SIZE), "0" (0), "1" (user_regs), "2" (wqv->stack)
  : "memory" );
  
  if ( unlikely(wqv->esp == 0) )
 @@ -169,7 +169,7 @@ static void __prepare_to_wait(struct waitqueue_vcpu 
 *wqv)
  domain_crash_synchronous();
  }
  
 -cpu_info->guest_cpu_user_regs.entry_vector = entry_vector;
 +user_regs->entry_vector = entry_vector;
  }
>>>
>>> I don't see how this change is related to the purpose of this patch,
>>> or why the change is needed. All you do is utilize that
>>> guest_cpu_user_regs is the first field of struct cpu_info afaics.
>>
>> guest_cpu_user_regs() might point to either stack, while get_cpu_info()
>> will always reference the Xen stack and never the per-vcpu one.
> 
> Then the description should say so for justification.

Okay, added.


Juergen

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

Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Volodymyr Babchuk]

Hi

On 02.02.18 16:31, Julien Grall wrote:

Hi,

On 02/02/18 14:23, Volodymyr Babchuk wrote:

On 02.02.18 13:41, Julien Grall wrote:

At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).

This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI functions.

Therefore move PSCI dispatching in two new functions do_vpsci_0_1_call
and do_vpsci_0_2_call. The former will handle PSCI 0.1 call while the 
latter

0.2 or later call.

At the same time, a new header vpsci.h was created to contain all
definitions for virtual PSCI and avoid confusion with the host PSCI.

Signed-off-by: Julien Grall 


I'm okay with this generally, you can have my r-b:
`Reviewed-by: Volodymyr Babchuk `


I would not have gave a reviewed-by with the comments you gave below ;).



Point taken :)


+/*
+ * PSCI 0.2 or later calls. It will return false if the function ID is
+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+    /*
+ * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when
+ * adding/removing a function
+ */
Should we also update revision of SSSC interface as well? SMCCC 
requires this.


Meh, you can't rely on the SSSC revision most of the time as the version 
for PSCI is done through PSCI_get_version. I can add a comment if you want.


Yes, I agree with you. But section 5.4 of SMCCC 1.0 applies to SSSC as 
well. So you can write something like "ARM SMCCC requires that SSSC 
revision and function call count should be updated every time you add or 
remove a function"


[...]

--
Volodymyr Babchuk

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

Re: [Xen-devel] [PATCH v1 1/4] asm-x86/monitor: Enable svm monitor events

[Tamas K Lengyel]

On Fri, Feb 2, 2018 at 2:37 AM, Alexandru Isaila
 wrote:
> This commit separates the svm caps from the vmx caps.
>
> Signed-off-by: Alexandru Isaila 
> ---
>  xen/include/asm-x86/monitor.h | 33 -
>  1 file changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index a0444d1..3706b7a 100644
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -74,21 +74,28 @@ static inline uint32_t 
> arch_monitor_get_capabilities(struct domain *d)
>   * At the moment only Intel HVM domains are supported. However, event
>   * delivery could be extended to AMD and PV domains.

I guess adjusting this comment here would now be also appropriate.

>   */
> -if ( !is_hvm_domain(d) || !cpu_has_vmx )
> +if ( !is_hvm_domain(d) )
>  return capabilities;
>
> -capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
> -
> -/* Since we know this is on VMX, we can just call the hvm func */
> -if ( hvm_is_singlestep_supported() )
> -capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
> +if( cpu_has_vmx )
> +{
> +capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
> +
> +/* Since we know this is on VMX, we can just call the hvm func */
> +if ( hvm_is_singlestep_supported() )
> +capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
> +}
> +else if ( cpu_has_svm )
> +{
> +capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);

If this is now supported on both svm and vmx, so you could just set it
outside the if blocks. We know we are dealing with an hvm domain at
this point.

Tamas

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

Re: [Xen-devel] [PATCH V3] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Tamas K Lengyel]

On Fri, Feb 2, 2018 at 1:14 AM, Razvan Cojocaru
 wrote:
> The emulation layers of Xen lack PCID support, and as we only offer
> PCID to HAP guests, all writes to CR3 are handled by hardware,
> except when introspection is involved. Consequently, trying to set
> CR3 when the noflush bit is set in hvm_set_cr3() leads to domain
> crashes. The workaround is to clear the noflush bit in
> hvm_set_cr3(). CR3 values in hvm_monitor_cr() are also sanitized.
> Additionally, a bool parameter now propagates to
> {svm,vmx}_update_guest_cr(), so that no flushes occur when
> the bit was set.
>
> Signed-off-by: Razvan Cojocaru 
> Reported-by: Bitweasil 
> Suggested-by: Andrew Cooper 

Acked-by: Tamas K Lengyel 

>
> ---
> Changes since V2:
>  - Fixed the write_ctrlreg.index check (the proper comparison
>is with VM_EVENT_X86_CR3, not 3). Noticed by Tamas.
> ---
>  xen/arch/x86/hvm/domain.c |  6 +++---
>  xen/arch/x86/hvm/hvm.c| 25 -
>  xen/arch/x86/hvm/monitor.c|  3 +++
>  xen/arch/x86/hvm/svm/nestedsvm.c  |  4 ++--
>  xen/arch/x86/hvm/svm/svm.c| 22 ++
>  xen/arch/x86/hvm/svm/vmcb.c   |  4 ++--
>  xen/arch/x86/hvm/vmx/vmcs.c   |  4 ++--
>  xen/arch/x86/hvm/vmx/vmx.c| 16 +---
>  xen/arch/x86/mm.c |  2 +-
>  xen/arch/x86/mm/hap/hap.c |  6 +++---
>  xen/arch/x86/mm/shadow/common.c   |  2 +-
>  xen/arch/x86/mm/shadow/multi.c|  6 +++---
>  xen/arch/x86/mm/shadow/none.c |  2 +-
>  xen/arch/x86/monitor.c|  2 +-
>  xen/include/asm-x86/hvm/hvm.h | 10 +++---
>  xen/include/asm-x86/hvm/svm/svm.h |  2 +-
>  xen/include/asm-x86/paging.h  |  7 ---
>  17 files changed, 73 insertions(+), 50 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c
> index 6047464..9be085e 100644
> --- a/xen/arch/x86/hvm/domain.c
> +++ b/xen/arch/x86/hvm/domain.c
> @@ -287,9 +287,9 @@ int arch_set_info_hvm_guest(struct vcpu *v, const 
> vcpu_hvm_context_t *ctx)
>  return -EINVAL;
>  }
>
> -hvm_update_guest_cr(v, 0);
> -hvm_update_guest_cr(v, 3);
> -hvm_update_guest_cr(v, 4);
> +hvm_update_guest_cr(v, 0, false);
> +hvm_update_guest_cr(v, 3, false);
> +hvm_update_guest_cr(v, 4, false);
>  hvm_update_guest_efer(v);
>
>  if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) )
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 18d721d..10c62fb 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2171,7 +2171,7 @@ static void hvm_update_cr(struct vcpu *v, unsigned int 
> cr, unsigned long value)
>  {
>  v->arch.hvm_vcpu.guest_cr[cr] = value;
>  nestedhvm_set_cr(v, cr, value);
> -hvm_update_guest_cr(v, cr);
> +hvm_update_guest_cr(v, cr, false);
>  }
>
>  int hvm_set_cr0(unsigned long value, bool_t may_defer)
> @@ -2297,6 +2297,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>  struct vcpu *v = current;
>  struct page_info *page;
>  unsigned long old = v->arch.hvm_vcpu.guest_cr[3];
> +bool noflush = false;
>
>  if ( may_defer && unlikely(v->domain->arch.monitor.write_ctrlreg_enabled 
> &
> monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3)) )
> @@ -2313,6 +2314,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>  }
>  }
>
> +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */
> +{
> +noflush = !!(value & X86_CR3_NOFLUSH);
> +value &= X86_CR3_NOFLUSH_DISABLE_MASK;
> +}
> +
>  if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
>   (value != v->arch.hvm_vcpu.guest_cr[3]) )
>  {
> @@ -2330,7 +2337,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>  }
>
>  v->arch.hvm_vcpu.guest_cr[3] = value;
> -paging_update_cr3(v);
> +paging_update_cr3(v, noflush);
>  return X86EMUL_OKAY;
>
>   bad_cr3:
> @@ -3059,7 +3066,7 @@ void hvm_task_switch(
>  hvm_set_segment_register(v, x86_seg_tr, );
>
>  v->arch.hvm_vcpu.guest_cr[0] |= X86_CR0_TS;
> -hvm_update_guest_cr(v, 0);
> +hvm_update_guest_cr(v, 0, false);
>
>  if ( (taskswitch_reason == TSW_iret ||
>taskswitch_reason == TSW_jmp) && otd_writable )
> @@ -3895,16 +3902,16 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t 
> cs, uint16_t ip)
>  memset(>arch.debugreg, 0, sizeof(v->arch.debugreg));
>
>  v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_ET;
> -hvm_update_guest_cr(v, 0);
> +hvm_update_guest_cr(v, 0, false);
>
>  v->arch.hvm_vcpu.guest_cr[2] = 0;
> -hvm_update_guest_cr(v, 2);
> +hvm_update_guest_cr(v, 2, false);
>
>  v->arch.hvm_vcpu.guest_cr[3] = 0;
> -hvm_update_guest_cr(v, 3);
> +hvm_update_guest_cr(v, 3, false);
>
>  v->arch.hvm_vcpu.guest_cr[4] = 0;
> -

[Xen-devel] [PATCH] xen: hypercall: fix out-of-bounds memcpy

[Arnd Bergmann]

The legacy hypercall handlers were originally added with
a comment explaining that "copying the argument structures in
HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
variable is sufficiently safe" and only made sure to not write
past the end of the argument structure, the checks in linux/string.h
disagree with that, when link-time optimizations are used:

In function 'memcpy',
inlined from 'pirq_query_unmask' at drivers/xen/fallback.c:53:2,
inlined from '__startup_pirq' at drivers/xen/events/events_base.c:529:2,
inlined from 'restore_pirqs' at drivers/xen/events/events_base.c:1439:3,
inlined from 'xen_irq_resume' at drivers/xen/events/events_base.c:1581:2:
include/linux/string.h:350:3: error: call to '__read_overflow2' declared with 
attribute error: detected read beyond size of object passed as 2nd parameter
   __read_overflow2();
   ^
make[3]: *** [ccLujFNx.ltrans15.ltrans.o] Error 1
make[3]: Target 'all' not remade because of errors.
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
ld: error: lto-wrapper failed

This changes the functions so that each argument is accessed with
exactly the correct length based on the command code.

Fixes: cf47a83fb06e ("xen/hypercall: fix hypercall fallback code for very old 
hypervisors")
Signed-off-by: Arnd Bergmann 
---
 drivers/xen/fallback.c | 94 --
 1 file changed, 53 insertions(+), 41 deletions(-)

diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
index b04fb64c5a91..eded8dd821ad 100644
--- a/drivers/xen/fallback.c
+++ b/drivers/xen/fallback.c
@@ -7,75 +7,87 @@
 
 int xen_event_channel_op_compat(int cmd, void *arg)
 {
-   struct evtchn_op op;
+   struct evtchn_op op = { .cmd = cmd, };
+   size_t len;
int rc;
 
-   op.cmd = cmd;
-   memcpy(, arg, sizeof(op.u));
-   rc = _hypercall1(int, event_channel_op_compat, );
-
switch (cmd) {
+   case EVTCHNOP_bind_interdomain:
+   len = sizeof(struct evtchn_bind_interdomain);
+   break;
+   case EVTCHNOP_bind_virq:
+   len = sizeof(struct evtchn_bind_virq);
+   break;
+   case EVTCHNOP_bind_pirq:
+   len = sizeof(struct evtchn_bind_pirq);
+   break;
case EVTCHNOP_close:
+   len = sizeof(struct evtchn_close);
+   break;
case EVTCHNOP_send:
+   len = sizeof(struct evtchn_send);
+   break;
+   case EVTCHNOP_alloc_unbound:
+   len = sizeof(struct evtchn_alloc_unbound);
+   break;
+   case EVTCHNOP_bind_ipi:
+   len = sizeof(struct evtchn_bind_ipi);
+   break;
+   case EVTCHNOP_status:
+   len = sizeof(struct evtchn_status);
+   break;
case EVTCHNOP_bind_vcpu:
+   len = sizeof(struct evtchn_bind_vcpu);
+   break;
case EVTCHNOP_unmask:
-   /* no output */
+   len = sizeof(struct evtchn_unmask);
break;
-
-#define COPY_BACK(eop) \
-   case EVTCHNOP_##eop: \
-   memcpy(arg, , sizeof(op.u.eop)); \
-   break
-
-   COPY_BACK(bind_interdomain);
-   COPY_BACK(bind_virq);
-   COPY_BACK(bind_pirq);
-   COPY_BACK(status);
-   COPY_BACK(alloc_unbound);
-   COPY_BACK(bind_ipi);
-#undef COPY_BACK
-
default:
-   WARN_ON(rc != -ENOSYS);
-   break;
+   return -ENOSYS;
}
 
+   memcpy(, arg, len);
+   rc = _hypercall1(int, event_channel_op_compat, );
+   memcpy(arg, , len);
+
return rc;
 }
 EXPORT_SYMBOL_GPL(xen_event_channel_op_compat);
 
 int xen_physdev_op_compat(int cmd, void *arg)
 {
-   struct physdev_op op;
+   struct physdev_op op = { .cmd = cmd, };
+   size_t len;
int rc;
 
-   op.cmd = cmd;
-   memcpy(, arg, sizeof(op.u));
-   rc = _hypercall1(int, physdev_op_compat, );
-
switch (cmd) {
case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
+   len = 0;
+   break;
+   case PHYSDEVOP_irq_status_query:
+   len = sizeof(struct physdev_irq_status_query);
+   break;
case PHYSDEVOP_set_iopl:
+   len = sizeof(struct physdev_set_iopl);
+   break;
case PHYSDEVOP_set_iobitmap:
+   len = sizeof(struct physdev_set_iobitmap);
+   break;
+   case PHYSDEVOP_apic_read:
case PHYSDEVOP_apic_write:
-   /* no output */
+   len = sizeof(struct physdev_apic);
break;
-
-#define COPY_BACK(pop, fld) \
-   case PHYSDEVOP_##pop: \
-   memcpy(arg, , sizeof(op.u.fld)); \
-   break
-
-   COPY_BACK(irq_status_query, irq_status_query);
-   COPY_BACK(apic_read, apic_op);
-   COPY_BACK(ASSIGN_VECTOR, irq_op);
-#undef COPY_BACK
-
-

Re: [Xen-devel] [PATCH v3 10/25] x86emul: support 3DNow! insns

[Jan Beulich]

>>> On 02.02.18 at 14:02,  wrote:
> On 07/12/17 14:05, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -355,6 +355,36 @@ static const struct {
>>  [0xff] = { ModRM }
>>  };
>>  
>> +static const uint16_t _3dnow_table[16] = {
> 
> Comment explaining how these mappings work?  It looks like nibble
> splits, but I still can't work out how to crossreference with the opcode
> tables.

Will do. Array index is high opcode nibble, bit index is low opcode
nibble.

>> +[0x0] = (1 << 0xd) /* pi2fd */,
>> +[0x1] = (1 << 0xd) /* pf2id */,
>> +[0x9] = (1 << 0x0) /* pfcmpge */ |
>> +(1 << 0x4) /* pfmin */ |
>> +(1 << 0x6) /* pfrcp */ |
>> +(1 << 0x7) /* pfrsqrt */ |
>> +(1 << 0xa) /* pfsub */ |
>> +(1 << 0xe) /* pfadd */,
>> +[0xa] = (1 << 0x0) /* pfcmpge */ |
>> +(1 << 0x4) /* pfmax */ |
>> +(1 << 0x6) /* pfrcpit1 */ |
>> +(1 << 0x7) /* pfrsqit1 */ |
>> +(1 << 0xa) /* pfsubr */ |
>> +(1 << 0xe) /* pfacc */,
>> +[0xb] = (1 << 0x0) /* pfcmpeq */ |
>> +(1 << 0x4) /* pfmul */ |
>> +(1 << 0x6) /* pfrcpit2 */ |
>> +(1 << 0x7) /* pmulhrw */ |
>> +(1 << 0xf) /* pavgusb */,
>> +};
>> +
>> +static const uint16_t _3dnow_ext_table[16] = {
>> +[0x1] = (1 << 0xd) /* pi2fw */,
>> +[0x1] = (1 << 0xc) /* pf2iw */,
> 
> You presumably want an | in here instead?

No, the first of the two lines is wrong and needs to be

[0x0] = (1 << 0xc) /* pi2fw */,

(wrong post-copy-and-paste editing).

>> @@ -5505,6 +5537,26 @@ x86_emulate(
>>  case X86EMUL_OPC(0x0f, 0x19) ... X86EMUL_OPC(0x0f, 0x1f): /* nop */
>>  break;
> 
> 0f 0d prefetches?  They are 3DNow instructions, but available on later
> processors.

And it is for that latter reason (I assume) that we have these
already.

Jan


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

Re: [Xen-devel] [PATCH v3 09/25] x86emul: support XOP insns

[Jan Beulich]

>>> On 02.02.18 at 13:03,  wrote:
> On 07/12/17 14:04, Jan Beulich wrote:
>> @@ -8027,6 +8060,13 @@ x86_emulate(
>>  generate_exception_if(vex.w, EXC_UD);
>>  goto simd_0f_imm8_avx;
>>  
>> +case X86EMUL_OPC_VEX_66(0x0f3a, 0x48): /* vpermil2ps 
>> $imm,{x,y}mm/mem,{x,y}mm,{x,y}mm,{x,y}mm */
>> +   /* vpermil2ps 
>> $imm,{x,y}mm,{x,y}mm/mem,{x,y}mm,{x,y}mm */
>> +case X86EMUL_OPC_VEX_66(0x0f3a, 0x49): /* vpermil2pd 
>> $imm,{x,y}mm/mem,{x,y}mm,{x,y}mm,{x,y}mm */
>> +   /* vpermil2pd 
>> $imm,{x,y}mm,{x,y}mm/mem,{x,y}mm,{x,y}mm */
>> +host_and_vcpu_must_have(xop);
>> +goto simd_0f_imm8_ymm;
> 
> Is this correct?  VEX.W selects which operand may be the memory operand,
> and I don't see anything in the decode which copes, or anything in the
> stub which adjusts .W.

That's the nice thing here - by re-using the original instruction in
the stub (with only GPR numbers adjusted if necessary) we simply
don't care which of the operands it the memory one, as long as
the access width does not differ (and it doesn't).

Jan


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

Re: [Xen-devel] [PATCH v3 08/25] x86emul: add tables for XOP 08 and 09 extension spaces

[Jan Beulich]

>>> On 02.02.18 at 12:43,  wrote:
> On 07/12/17 14:04, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -458,6 +458,20 @@ static const opcode_desc_t xop_table[] =
>>  DstReg|SrcImm|ModRM,
>>  };
>>  
>> +static const struct {
>> +uint8_t simd_size:5;
>> +uint8_t two_op:1;
>> +uint8_t four_op:1;
>> +} ext8f08_table[256] = {
>> +};
>> +
>> +static const struct {
>> +uint8_t simd_size:5;
>> +uint8_t two_op:1;
>> +} ext8f09_table[256] = {
>> +[0x01 ... 0x02] = { .two_op = 1 },
>> +};
>> +
> 
> What about 8f0a ?  We've got emulation for bextr already, and might want
> to consider #GRP4 seeing as we expose LWP to guests.

I'd prefer to convert that to a table at the time we need it.

>> @@ -2726,7 +2740,7 @@ x86_decode(
>>  }
>>  break;
>>  
>> -case vex_0f38:
>> +case ext_0f38:
>>  d = ext0f38_table[b].to_mem ? DstMem | SrcReg
>>  : DstReg | SrcMem;
>>  if ( ext0f38_table[b].two_op )
>> @@ -2736,7 +2750,14 @@ x86_decode(
>>  state->simd_size = ext0f38_table[b].simd_size;
>>  break;
>>  
>> -case vex_0f3a:
>> +case ext_8f09:
>> +if ( ext8f09_table[b].two_op )
>> +d |= TwoOp;
>> +state->simd_size = ext8f09_table[b].simd_size;
>> +break;
>> +
>> +case ext_0f3a:
>> +case ext_8f08:
>>  /*
>>   * Cannot update d here yet, as the immediate operand still
>>   * needs fetching.
>> @@ -2928,6 +2949,15 @@ x86_decode(
>>  break;
>>  
>>  case ext_8f08:
>> +d = DstReg | SrcMem;
>> +if ( ext8f08_table[b].two_op )
>> +d |= TwoOp;
>> +else if ( ext8f08_table[b].four_op && !mode_64bit() )
>> +imm1 &= 0x7f;
>> +state->desc = d;
>> +state->simd_size = ext8f08_table[b].simd_size;
>> +break;
> 
> I presume that these don't actually impact our currently implemented XOP
> instructions?

No - as the description says, the patch converts the existing ones,
it doesn't break them (and the test harness continuing to work
confirms this).

Jan


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

Re: [Xen-devel] [PATCH v3 1/4] xen/arm: traps: Merge try_handle_mmio() and handle_mmio()

[Andre Przywara]

Hi,

On 02/02/18 14:47, Julien Grall wrote:
> 
> 
> On 02/02/18 14:34, Andre Przywara wrote:
>> Hi,
> 
> Hi,
> 
>> On 02/02/18 10:14, Julien Grall wrote:
>>> At the moment, try_handle_mmio() will do check on the HSR and bail out
>>> if one check fail. This means that another method will be tried to
>>> handle the fault even for bad access on emulated region. While this
>>> should not be an issue, this is not future proof.
>>>
>>> Move the checks of try_handle_mmio() in handle_mmio() after we
>>> identified
>>> the fault to target an emulated MMIO. While this does not fix the
>>> potential
>>> fall-through, a follow-up patch will do by distinguish the potential
>>> error.
>>>
>>> Note that the handle_mmio() was renamed to try_handle_mmio() and the
>>> prototype adapted.
>>
>> Why is that? I think the prefix "try_" only makes sense if you have a
>> non-try version as well. To some degree most functions "try" something,
>> when they check for and return errors.
>> I think the return type makes it clear what the semantics are.
>> So personally I would prefer just "handle_mmio" as the function name.
> Because we have another function called try_map_mmio() just below, so I
> wanted to keep similar.
> 
> Also, I think "try_" makes sense here because if you don't succeed, you
> will fallback to another method. Most of the times, this is not the case
> of other functions.

Yeah, fair enough. Fine for me, then.

Cheers,
Andre.

>> But this only a nit, definitely not worth a respin on its own.
>>
>>> While merging the 2 functions, remove the check whether the fault is
>>> stage-2 abort on stage-1 translation walk because the instruction
>>> syndrome will always be invalid (see B3-1433 in DDI 0406C.c and
>>> D10-2460 in DDI 0487C.a).
>>
>> Yes, that looks correct to me.
>>
>>> Signed-off-by: Julien Grall 
>>
>> Reviewed-by: Andre Przywara 
> 
> Thanks!
> 
> Cheers,
> 

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

Re: [Xen-devel] [PATCH v3 4/4] xen/arm: Don't crash the domain on invalid HVC immediate

[Julien Grall]

On 02/02/18 14:37, Andre Przywara wrote:

Hi,


Hi,


On 02/02/18 10:14, Julien Grall wrote:

domain_crash_synchronous() should only be used when something went wrong
in Xen. It is better to inject to the guest as it will be in a better
position to provide helpful information (stack trace...).

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

---

 We potentially want to return -1 instead. This would make Xen more
 future-proof if we decide to implement the other HVC immediate.

 Changes in v2:
 - Add Stefano's reviewed-by
---
  xen/arch/arm/traps.c | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1e85f99ec1..1cba7e584d 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1471,14 +1471,17 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
  #endif
  
  static void do_trap_hypercall(struct cpu_user_regs *regs, register_t *nr,

-  unsigned long iss)
+  const union hsr hsr)
  {
  arm_hypercall_fn_t call = NULL;
  
  BUILD_BUG_ON(NR_hypercalls < ARRAY_SIZE(arm_hypercall_table) );
  
-if ( iss != XEN_HYPERCALL_TAG )

-domain_crash_synchronous();
+if ( hsr.iss != XEN_HYPERCALL_TAG )
+{
+gprintk(XENLOG_WARNING, "Invalid HVC imm 0x%x\n", hsr.iss);
+return inject_undef_exception(regs, hsr);


Why is this UNDEF?
UNDEF is the exception used when either HVC is disabled or if it's
called from EL0.
I couldn't find anything that talks about how non-implemented immediates
should be handled, I guess they would just be ignored?
Do you have any sources that recommend UNDEF?


Per the SMCCC, all nonzero immediate for HVC are designated for use by 
the hypervisors. So I take as we can implement the way we want.


We have few solutions here:
	1) Ignore. This means that a guest may wrongly call an HVC and will 
never notice it until implemented. This would lead to some trouble with 
introduce new ABI.
	2) Return a value. We could return -1 (or -ENOSYS). But that would need 
to be defined.

3) Undefined. The guest should not be allow to touch it, so it makes 
sense.

1# is not a solution because catching them wrong usage on old Xen would 
be a nightmare.


2# might be doable, thought I am not sure we want to commit on a return 
value now. But old Xen would see crash the domain.


So I choose #3 which still crash the domain but by injecting an undefined.

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 20/25] x86emul: correctly handle CMPXCHG* comparison failures

[Andrew Cooper]

On 07/12/17 14:15, Jan Beulich wrote:
> If the ->cmpxchg() hook finds a mismatch, we should deal with this the
> same way as when the "manual" comparison reports a mismatch.
>
> This involves reverting bfce0e62c3 ("x86/emul: Drop
> X86EMUL_CMPXCHG_FAILED"), albeit with X86EMUL_CMPXCHG_FAILED now
> becoming a value distinct from X86EMUL_RETRY.
>
> In order to not leave mixed code also fully switch affected functions
> from paddr_t to intpte_t.
>
> Signed-off-by: Jan Beulich 
> ---
> v3: New.
> ---
> The code could be further simplified if we could rely on all
> ->cmpxchg() hooks always using CMPXCHG, but for now we need to cope
> with them using plain writes (and hence accept the double reads if
> CMPXCHG is actually being used).
> Note that the patch doesn't address the incorrectness of there not
> being a memory write even in the comparison-failed case.
>
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -302,8 +302,12 @@ hvm_emulate_cmpxchg(enum x86_segment seg
>  memcpy(, p_old, bytes);
>  memcpy(, p_new, bytes);
>  
> -return v->arch.paging.mode->shadow.x86_emulate_cmpxchg(
> -   v, addr, old, new, bytes, sh_ctxt);
> +rc = v->arch.paging.mode->shadow.x86_emulate_cmpxchg(
> + v, addr, , new, bytes, sh_ctxt);
> +
> +memcpy(p_old, , bytes);

This is redundant with ...

> +
> +return rc;
>  }
>  
>  static const struct x86_emulate_ops hvm_shadow_emulator_ops = {
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -4741,11 +4741,11 @@ sh_x86_emulate_write(struct vcpu *v, uns
>  
>  static int
>  sh_x86_emulate_cmpxchg(struct vcpu *v, unsigned long vaddr,
> -unsigned long old, unsigned long new,
> -unsigned int bytes, struct sh_emulate_ctxt *sh_ctxt)
> +   unsigned long *p_old, unsigned long new,
> +   unsigned int bytes, struct sh_emulate_ctxt *sh_ctxt)
>  {
>  void *addr;
> -unsigned long prev;
> +unsigned long prev, old = *p_old;
>  int rv = X86EMUL_OKAY;
>  
>  /* Unaligned writes are only acceptable on HVM */
> @@ -4769,7 +4769,10 @@ sh_x86_emulate_cmpxchg(struct vcpu *v, u
>  }
>  
>  if ( prev != old )
> -rv = X86EMUL_RETRY;
> +{
> +*p_old = prev;

... this, is it not?

> +rv = X86EMUL_CMPXCHG_FAILED;
> +}
>  
>  SHADOW_DEBUG(EMULATE, "va %#lx was %#lx expected %#lx"
>" wanted %#lx now %#lx bytes %u\n",
> --- a/xen/arch/x86/pv/ro-page-fault.c
> +++ b/xen/arch/x86/pv/ro-page-fault.c
> @@ -65,14 +65,16 @@ static int ptwr_emulated_read(enum x86_s
>  return X86EMUL_OKAY;
>  }
>  
> -static int ptwr_emulated_update(unsigned long addr, paddr_t old, paddr_t val,
> -unsigned int bytes, unsigned int do_cmpxchg,
> +static int ptwr_emulated_update(unsigned long addr, intpte_t *p_old,
> +intpte_t val, unsigned int bytes,
>  struct x86_emulate_ctxt *ctxt)
>  {
>  unsigned long mfn;
>  unsigned long unaligned_addr = addr;
>  struct page_info *page;
>  l1_pgentry_t pte, ol1e, nl1e, *pl1e;
> +intpte_t old = p_old ? *p_old : 0;
> +unsigned int offset = 0;

I really think this conversion to intpte needs splitting out into a
separate patch.  You're making multiple changes in this function which
aren't at commit message at all, including introducing the distinction
I've just noted of *p_old being NULL meaning a write rather than cmpxchg.

On that note specifically, it would be clearer to have "const bool
do_cmpxchg = *p_old; /* cmpxchg, or write? */".  If you don't want to do
it, then there needs to be a comment with the function explaining the
semantics of p_old.

~Andrew


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

Re: [Xen-devel] [PATCH v3 2/4] xen/arm: io: Distinguish unhandled IO from aborted one

[Julien Grall]

On 02/02/18 14:34, Andre Przywara wrote:

Hi,


Hi,


On 02/02/18 10:14, Julien Grall wrote:

Currently, Xen is considering that an IO could either be handled or
unhandled. When unhandled, the stage-2 abort function will try another
way to resolve the abort.

However, the MMIO emulation may return unhandled when the address
belongs to an emulated range but was not correct. In that case, Xen
should avoid to try another way and directly inject a guest data abort.

Introduce a tri-state return to distinguish the following state:
 * IO_ABORT: The IO was handled but resulted in an abort
 * IO_HANDLED: The IO was handled
 * IO_UNHANDLED: The IO was unhandled


I like that very much!



For now, it is considered that an IO belonging to an emulated range
could either be handled or inject an abort. This could be revisit in the
future if overlapped region exist (or we want to try another way to
resolve the abort).

Signed-off-by: Julien Grall 

---
 Changes in v2:
 - Always return IO_ABORT when the check failed because we know
 it was targeted emulated IO.
 - Fix typoes
---
  xen/arch/arm/io.c  | 32 ++--
  xen/arch/arm/traps.c   | 18 +++---
  xen/include/asm-arm/mmio.h | 13 ++---
  3 files changed, 43 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index c3e9239ffe..1f4cb8f37d 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -26,8 +26,9 @@
  
  #include "decode.h"
  
-static int handle_read(const struct mmio_handler *handler, struct vcpu *v,

-   mmio_info_t *info)
+static enum io_state handle_read(const struct mmio_handler *handler,
+ struct vcpu *v,
+ mmio_info_t *info)
  {
  const struct hsr_dabt dabt = info->dabt;
  struct cpu_user_regs *regs = guest_cpu_user_regs();
@@ -40,7 +41,7 @@ static int handle_read(const struct mmio_handler *handler, 
struct vcpu *v,
  uint8_t size = (1 << dabt.size) * 8;
  
  if ( !handler->ops->read(v, info, , handler->priv) )

-return 0;
+return IO_ABORT;
  
  /*

   * Sign extend if required.
@@ -60,17 +61,20 @@ static int handle_read(const struct mmio_handler *handler, 
struct vcpu *v,
  
  set_user_reg(regs, dabt.reg, r);
  
-return 1;

+return IO_HANDLED;
  }
  
-static int handle_write(const struct mmio_handler *handler, struct vcpu *v,

-mmio_info_t *info)
+static enum io_state handle_write(const struct mmio_handler *handler,
+  struct vcpu *v,
+  mmio_info_t *info)
  {
  const struct hsr_dabt dabt = info->dabt;
  struct cpu_user_regs *regs = guest_cpu_user_regs();
+int ret;
  
-return handler->ops->write(v, info, get_user_reg(regs, dabt.reg),

-   handler->priv);
+ret = handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
+  handler->priv);
+return ( ret ) ? IO_HANDLED : IO_ABORT;


Why the brackets?


I was not feeling lazy that day ;). I will drop them.



Otherwise:

Reviewed-by: Andre Przywara 


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 1/4] xen/arm: traps: Merge try_handle_mmio() and handle_mmio()

[Julien Grall]

On 02/02/18 14:34, Andre Przywara wrote:

Hi,


Hi,


On 02/02/18 10:14, Julien Grall wrote:

At the moment, try_handle_mmio() will do check on the HSR and bail out
if one check fail. This means that another method will be tried to
handle the fault even for bad access on emulated region. While this
should not be an issue, this is not future proof.

Move the checks of try_handle_mmio() in handle_mmio() after we identified
the fault to target an emulated MMIO. While this does not fix the potential
fall-through, a follow-up patch will do by distinguish the potential error.

Note that the handle_mmio() was renamed to try_handle_mmio() and the
prototype adapted.


Why is that? I think the prefix "try_" only makes sense if you have a
non-try version as well. To some degree most functions "try" something,
when they check for and return errors.
I think the return type makes it clear what the semantics are.
So personally I would prefer just "handle_mmio" as the function name.
Because we have another function called try_map_mmio() just below, so I 
wanted to keep similar.


Also, I think "try_" makes sense here because if you don't succeed, you 
will fallback to another method. Most of the times, this is not the case 
of other functions.




But this only a nit, definitely not worth a respin on its own.


While merging the 2 functions, remove the check whether the fault is
stage-2 abort on stage-1 translation walk because the instruction
syndrome will always be invalid (see B3-1433 in DDI 0406C.c and
D10-2460 in DDI 0487C.a).


Yes, that looks correct to me.


Signed-off-by: Julien Grall 


Reviewed-by: Andre Przywara 


Thanks!

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 4/4] xen/arm: Don't crash the domain on invalid HVC immediate

[Andre Przywara]

Hi,

On 02/02/18 10:14, Julien Grall wrote:
> domain_crash_synchronous() should only be used when something went wrong
> in Xen. It is better to inject to the guest as it will be in a better
> position to provide helpful information (stack trace...).
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Stefano Stabellini 
> 
> ---
> 
> We potentially want to return -1 instead. This would make Xen more
> future-proof if we decide to implement the other HVC immediate.
> 
> Changes in v2:
> - Add Stefano's reviewed-by
> ---
>  xen/arch/arm/traps.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 1e85f99ec1..1cba7e584d 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1471,14 +1471,17 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
> unsigned int code)
>  #endif
>  
>  static void do_trap_hypercall(struct cpu_user_regs *regs, register_t *nr,
> -  unsigned long iss)
> +  const union hsr hsr)
>  {
>  arm_hypercall_fn_t call = NULL;
>  
>  BUILD_BUG_ON(NR_hypercalls < ARRAY_SIZE(arm_hypercall_table) );
>  
> -if ( iss != XEN_HYPERCALL_TAG )
> -domain_crash_synchronous();
> +if ( hsr.iss != XEN_HYPERCALL_TAG )
> +{
> +gprintk(XENLOG_WARNING, "Invalid HVC imm 0x%x\n", hsr.iss);
> +return inject_undef_exception(regs, hsr);

Why is this UNDEF?
UNDEF is the exception used when either HVC is disabled or if it's
called from EL0.
I couldn't find anything that talks about how non-implemented immediates
should be handled, I guess they would just be ignored?
Do you have any sources that recommend UNDEF?

The rest looks fine.

Cheers,
Andre.

> +}
>  
>  if ( *nr >= ARRAY_SIZE(arm_hypercall_table) )
>  {
> @@ -2109,7 +2112,7 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
>  if ( hsr.iss == 0 )
>  return do_trap_hvc_smccc(regs);
>  nr = regs->r12;
> -do_trap_hypercall(regs, , hsr.iss);
> +do_trap_hypercall(regs, , hsr);
>  regs->r12 = (uint32_t)nr;
>  break;
>  }
> @@ -2123,7 +2126,7 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
>  #endif
>  if ( hsr.iss == 0 )
>  return do_trap_hvc_smccc(regs);
> -do_trap_hypercall(regs, >x16, hsr.iss);
> +do_trap_hypercall(regs, >x16, hsr);
>  break;
>  case HSR_EC_SMC64:
>  /*
> 

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

Re: [Xen-devel] [PATCH v3 3/4] xen/arm: Don't crash domain on bad MMIO emulation

[Andre Przywara]

Hi,

On 02/02/18 10:14, Julien Grall wrote:
> Now the MMIO emulation is able to distinguish unhandled IO from aborted
> one, there are no need to crash the domain when the region is access
> with a bad width.
> 
> Instead let Xen inject a data abort to the guest and decide what to do.

Very nice!

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

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
> Changes in v2
> - Add Stefano's reviewed-by
> ---
>  xen/arch/arm/vgic-v2.c | 2 --
>  xen/arch/arm/vgic-v3-its.c | 3 ---
>  xen/arch/arm/vgic-v3.c | 8 
>  xen/arch/arm/vpl011.c  | 2 --
>  4 files changed, 15 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
> index 2bdb25261a..646d1f3d12 100644
> --- a/xen/arch/arm/vgic-v2.c
> +++ b/xen/arch/arm/vgic-v2.c
> @@ -348,7 +348,6 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  bad_width:
>  printk(XENLOG_G_ERR "%pv: vGICD: bad read width %d r%d offset %#08x\n",
> v, dabt.size, dabt.reg, gicd_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  read_as_zero_32:
> @@ -613,7 +612,6 @@ bad_width:
>  printk(XENLOG_G_ERR
> "%pv: vGICD: bad write width %d r%d=%"PRIregister" offset 
> %#08x\n",
> v, dabt.size, dabt.reg, r, gicd_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  write_ignore_32:
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index d8fa44258d..32061c6b03 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -1136,7 +1136,6 @@ read_reserved:
>  bad_width:
>  printk(XENLOG_G_ERR "vGITS: bad read width %d r%d offset %#04lx\n",
> info->dabt.size, info->dabt.reg, (unsigned long)info->gpa & 
> 0x);
> -domain_crash_synchronous();
>  
>  return 0;
>  }
> @@ -1446,8 +1445,6 @@ bad_width:
>  printk(XENLOG_G_ERR "vGITS: bad write width %d r%d offset %#08lx\n",
> info->dabt.size, info->dabt.reg, (unsigned long)info->gpa & 
> 0x);
>  
> -domain_crash_synchronous();
> -
>  return 0;
>  }
>  
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index af16dfd005..2ad8a6be62 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -328,7 +328,6 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  bad_width:
>  printk(XENLOG_G_ERR "%pv vGICR: bad read width %d r%d offset %#08x\n",
> v, dabt.size, dabt.reg, gicr_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  read_as_zero_64:
> @@ -648,7 +647,6 @@ bad_width:
>  printk(XENLOG_G_ERR
>"%pv: vGICR: bad write width %d r%d=%"PRIregister" offset %#08x\n",
>v, dabt.size, dabt.reg, r, gicr_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  write_ignore_64:
> @@ -760,7 +758,6 @@ static int __vgic_v3_distr_common_mmio_read(const char 
> *name, struct vcpu *v,
>  bad_width:
>  printk(XENLOG_G_ERR "%pv: %s: bad read width %d r%d offset %#08x\n",
> v, name, dabt.size, dabt.reg, reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  read_as_zero:
> @@ -876,7 +873,6 @@ bad_width:
>  printk(XENLOG_G_ERR
> "%pv: %s: bad write width %d r%d=%"PRIregister" offset %#08x\n",
> v, name, dabt.size, dabt.reg, r, reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  write_ignore_32:
> @@ -937,7 +933,6 @@ static int vgic_v3_rdistr_sgi_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  bad_width:
>  printk(XENLOG_G_ERR "%pv: vGICR: SGI: bad read width %d r%d offset 
> %#08x\n",
> v, dabt.size, dabt.reg, gicr_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  read_as_zero_32:
> @@ -1017,7 +1012,6 @@ bad_width:
>  printk(XENLOG_G_ERR
> "%pv: vGICR: SGI: bad write width %d r%d=%"PRIregister" offset 
> %#08x\n",
> v, dabt.size, dabt.reg, r, gicr_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  write_ignore_32:
> @@ -1268,7 +1262,6 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  bad_width:
>  printk(XENLOG_G_ERR "%pv: vGICD: bad read width %d r%d offset %#08x\n",
> v, dabt.size, dabt.reg, gicd_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  read_as_zero_32:
> @@ -1456,7 +1449,6 @@ bad_width:
>  printk(XENLOG_G_ERR
> "%pv: vGICD: bad write width %d r%d=%"PRIregister" offset 
> %#08x\n",
> v, dabt.size, dabt.reg, r, gicd_reg);
> -domain_crash_synchronous();
>  return 0;
>  
>  write_ignore_32:
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 725b2e03ad..7788c2fc32 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -296,7 +296,6 @@ static int vpl011_mmio_read(struct vcpu *v,
>  bad_width:
>  

Re: [Xen-devel] [PATCH v3 2/4] xen/arm: io: Distinguish unhandled IO from aborted one

[Andre Przywara]

Hi,

On 02/02/18 10:14, Julien Grall wrote:
> Currently, Xen is considering that an IO could either be handled or
> unhandled. When unhandled, the stage-2 abort function will try another
> way to resolve the abort.
> 
> However, the MMIO emulation may return unhandled when the address
> belongs to an emulated range but was not correct. In that case, Xen
> should avoid to try another way and directly inject a guest data abort.
> 
> Introduce a tri-state return to distinguish the following state:
> * IO_ABORT: The IO was handled but resulted in an abort
> * IO_HANDLED: The IO was handled
> * IO_UNHANDLED: The IO was unhandled

I like that very much!

> 
> For now, it is considered that an IO belonging to an emulated range
> could either be handled or inject an abort. This could be revisit in the
> future if overlapped region exist (or we want to try another way to
> resolve the abort).
> 
> Signed-off-by: Julien Grall 
> 
> ---
> Changes in v2:
> - Always return IO_ABORT when the check failed because we know
> it was targeted emulated IO.
> - Fix typoes
> ---
>  xen/arch/arm/io.c  | 32 ++--
>  xen/arch/arm/traps.c   | 18 +++---
>  xen/include/asm-arm/mmio.h | 13 ++---
>  3 files changed, 43 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> index c3e9239ffe..1f4cb8f37d 100644
> --- a/xen/arch/arm/io.c
> +++ b/xen/arch/arm/io.c
> @@ -26,8 +26,9 @@
>  
>  #include "decode.h"
>  
> -static int handle_read(const struct mmio_handler *handler, struct vcpu *v,
> -   mmio_info_t *info)
> +static enum io_state handle_read(const struct mmio_handler *handler,
> + struct vcpu *v,
> + mmio_info_t *info)
>  {
>  const struct hsr_dabt dabt = info->dabt;
>  struct cpu_user_regs *regs = guest_cpu_user_regs();
> @@ -40,7 +41,7 @@ static int handle_read(const struct mmio_handler *handler, 
> struct vcpu *v,
>  uint8_t size = (1 << dabt.size) * 8;
>  
>  if ( !handler->ops->read(v, info, , handler->priv) )
> -return 0;
> +return IO_ABORT;
>  
>  /*
>   * Sign extend if required.
> @@ -60,17 +61,20 @@ static int handle_read(const struct mmio_handler 
> *handler, struct vcpu *v,
>  
>  set_user_reg(regs, dabt.reg, r);
>  
> -return 1;
> +return IO_HANDLED;
>  }
>  
> -static int handle_write(const struct mmio_handler *handler, struct vcpu *v,
> -mmio_info_t *info)
> +static enum io_state handle_write(const struct mmio_handler *handler,
> +  struct vcpu *v,
> +  mmio_info_t *info)
>  {
>  const struct hsr_dabt dabt = info->dabt;
>  struct cpu_user_regs *regs = guest_cpu_user_regs();
> +int ret;
>  
> -return handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
> -   handler->priv);
> +ret = handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
> +  handler->priv);
> +return ( ret ) ? IO_HANDLED : IO_ABORT;

Why the brackets?

Otherwise:

Reviewed-by: Andre Przywara 

Cheers,
Andre.

>  }
>  
>  /* This function assumes that mmio regions are not overlapped */
> @@ -103,9 +107,9 @@ static const struct mmio_handler 
> *find_mmio_handler(struct domain *d,
>  return handler;
>  }
>  
> -int try_handle_mmio(struct cpu_user_regs *regs,
> -const union hsr hsr,
> -paddr_t gpa)
> +enum io_state try_handle_mmio(struct cpu_user_regs *regs,
> +  const union hsr hsr,
> +  paddr_t gpa)
>  {
>  struct vcpu *v = current;
>  const struct mmio_handler *handler = NULL;
> @@ -119,11 +123,11 @@ int try_handle_mmio(struct cpu_user_regs *regs,
>  
>  handler = find_mmio_handler(v->domain, info.gpa);
>  if ( !handler )
> -return 0;
> +return IO_UNHANDLED;
>  
>  /* All the instructions used on emulated MMIO region should be valid */
>  if ( !dabt.valid )
> -return 0;
> +return IO_ABORT;
>  
>  /*
>   * Erratum 766422: Thumb store translation fault to Hypervisor may
> @@ -138,7 +142,7 @@ int try_handle_mmio(struct cpu_user_regs *regs,
>  if ( rc )
>  {
>  gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
> -return 0;
> +return IO_ABORT;
>  }
>  }
>  
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 2f8d790bb3..1e85f99ec1 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1964,10 +1964,21 @@ static void do_trap_stage2_abort_guest(struct 
> cpu_user_regs *regs,
>   *
>   * Note that emulated region cannot be executed
>   */
> -if ( is_data && try_handle_mmio(regs, hsr, 

Re: [Xen-devel] [PATCH v3 1/4] xen/arm: traps: Merge try_handle_mmio() and handle_mmio()

[Andre Przywara]

Hi,

On 02/02/18 10:14, Julien Grall wrote:
> At the moment, try_handle_mmio() will do check on the HSR and bail out
> if one check fail. This means that another method will be tried to
> handle the fault even for bad access on emulated region. While this
> should not be an issue, this is not future proof.
> 
> Move the checks of try_handle_mmio() in handle_mmio() after we identified
> the fault to target an emulated MMIO. While this does not fix the potential
> fall-through, a follow-up patch will do by distinguish the potential error.
> 
> Note that the handle_mmio() was renamed to try_handle_mmio() and the
> prototype adapted.

Why is that? I think the prefix "try_" only makes sense if you have a
non-try version as well. To some degree most functions "try" something,
when they check for and return errors.
I think the return type makes it clear what the semantics are.
So personally I would prefer just "handle_mmio" as the function name.

But this only a nit, definitely not worth a respin on its own.

> While merging the 2 functions, remove the check whether the fault is
> stage-2 abort on stage-1 translation walk because the instruction
> syndrome will always be invalid (see B3-1433 in DDI 0406C.c and
> D10-2460 in DDI 0487C.a).

Yes, that looks correct to me.

> Signed-off-by: Julien Grall 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
> Changes in v2:
> - Patch added
> ---
>  xen/arch/arm/io.c  | 43 ++-
>  xen/arch/arm/traps.c   | 41 -
>  xen/include/asm-arm/mmio.h |  4 +++-
>  3 files changed, 41 insertions(+), 47 deletions(-)
> 
> diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> index c748d8f5bf..c3e9239ffe 100644
> --- a/xen/arch/arm/io.c
> +++ b/xen/arch/arm/io.c
> @@ -20,9 +20,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> +#include "decode.h"
> +
>  static int handle_read(const struct mmio_handler *handler, struct vcpu *v,
> mmio_info_t *info)
>  {
> @@ -100,19 +103,49 @@ static const struct mmio_handler 
> *find_mmio_handler(struct domain *d,
>  return handler;
>  }
>  
> -int handle_mmio(mmio_info_t *info)
> +int try_handle_mmio(struct cpu_user_regs *regs,
> +const union hsr hsr,
> +paddr_t gpa)
>  {
>  struct vcpu *v = current;
>  const struct mmio_handler *handler = NULL;
> +const struct hsr_dabt dabt = hsr.dabt;
> +mmio_info_t info = {
> +.gpa = gpa,
> +.dabt = dabt
> +};
> +
> +ASSERT(hsr.ec == HSR_EC_DATA_ABORT_LOWER_EL);
>  
> -handler = find_mmio_handler(v->domain, info->gpa);
> +handler = find_mmio_handler(v->domain, info.gpa);
>  if ( !handler )
>  return 0;
>  
> -if ( info->dabt.write )
> -return handle_write(handler, v, info);
> +/* All the instructions used on emulated MMIO region should be valid */
> +if ( !dabt.valid )
> +return 0;
> +
> +/*
> + * Erratum 766422: Thumb store translation fault to Hypervisor may
> + * not have correct HSR Rt value.
> + */
> +if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
> + dabt.write )
> +{
> +int rc;
> +
> +rc = decode_instruction(regs, );
> +if ( rc )
> +{
> +gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
> +return 0;
> +}
> +}
> +
> +if ( info.dabt.write )
> +return handle_write(handler, v, );
>  else
> -return handle_read(handler, v, info);
> +return handle_read(handler, v, );
>  }
>  
>  void register_mmio_handler(struct domain *d,
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index c8534d6cff..2f8d790bb3 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -51,8 +51,6 @@
>  #include 
>  #include 
>  
> -#include "decode.h"
> -
>  /* The base of the stack must always be double-word aligned, which means
>   * that both the kernel half of struct cpu_user_regs (which is pushed in
>   * entry.S) and struct cpu_info (which lives at the bottom of a Xen
> @@ -1864,45 +1862,6 @@ static inline bool hpfar_is_valid(bool s1ptw, uint8_t 
> fsc)
>  return s1ptw || (fsc == FSC_FLT_TRANS && !check_workaround_834220());
>  }
>  
> -static bool try_handle_mmio(struct cpu_user_regs *regs,
> -const union hsr hsr,
> -paddr_t gpa)
> -{
> -const struct hsr_dabt dabt = hsr.dabt;
> -mmio_info_t info = {
> -.gpa = gpa,
> -.dabt = dabt
> -};
> -int rc;
> -
> -ASSERT(hsr.ec == HSR_EC_DATA_ABORT_LOWER_EL);
> -
> -/* stage-1 page table should never live in an emulated MMIO region */
> -if ( dabt.s1ptw )
> -return false;
> -
> -/* All the instructions used on emulated MMIO region should be valid */
> -if ( 

Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Julien Grall]

Hi,

On 02/02/18 14:23, Volodymyr Babchuk wrote:

On 02.02.18 13:41, Julien Grall wrote:

At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).

This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI functions.

Therefore move PSCI dispatching in two new functions do_vpsci_0_1_call
and do_vpsci_0_2_call. The former will handle PSCI 0.1 call while the 
latter

0.2 or later call.

At the same time, a new header vpsci.h was created to contain all
definitions for virtual PSCI and avoid confusion with the host PSCI.

Signed-off-by: Julien Grall 


I'm okay with this generally, you can have my r-b:
`Reviewed-by: Volodymyr Babchuk `


I would not have gave a reviewed-by with the comments you gave below ;).


+/*
+ * PSCI 0.2 or later calls. It will return false if the function ID is
+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+    /*
+ * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when
+ * adding/removing a function
+ */
Should we also update revision of SSSC interface as well? SMCCC requires 
this.


Meh, you can't rely on the SSSC revision most of the time as the version 
for PSCI is done through PSCI_get_version. I can add a comment if you want.


[...]


diff --git a/xen/include/asm-arm/vpsci.h b/xen/include/asm-arm/vpsci.h
new file mode 100644
index 00..d6a890f6a2
--- /dev/null
+++ b/xen/include/asm-arm/vpsci.h
@@ -0,0 +1,13 @@

I'm not sure, should you add license information?


I think so.




+#ifndef __ASM_VPSCI_H__
+#define __ASM_VPSCI_H__
+
+#include 
+
+/* Number of function implemented by virtual PSCI (only 0.2 or later) */
+#define VPSCI_NR_FUNCS  11
+
+/* Functions handle PSCI calls from the guests */
+bool do_vpsci_0_1_call(struct cpu_user_regs *regs, uint32_t fid);
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid);
+
+#endif /* __ASM_VPSCI_H__ */



And the same about Emacs tags.


Good catch. I will send a new version with the comments addressed.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Volodymyr Babchuk]

On 02.02.18 13:41, Julien Grall wrote:

At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).

This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI functions.

Therefore move PSCI dispatching in two new functions do_vpsci_0_1_call
and do_vpsci_0_2_call. The former will handle PSCI 0.1 call while the latter
0.2 or later call.

At the same time, a new header vpsci.h was created to contain all
definitions for virtual PSCI and avoid confusion with the host PSCI.

Signed-off-by: Julien Grall 


I'm okay with this generally, you can have my r-b:
`Reviewed-by: Volodymyr Babchuk `

But there are couple of minor questions below.


---
 Changes in v2:
 - Add a 'v' in the function names to help distinguish virtual vs
 physical PSCI
 - Introduce vpsci.h and VSCPI_NR_FUNCS
---
  xen/arch/arm/vpsci.c| 147 +++-
  xen/arch/arm/vsmc.c |  99 ++---
  xen/include/asm-arm/psci.h  |  19 --
  xen/include/asm-arm/vpsci.h |  13 
  4 files changed, 152 insertions(+), 126 deletions(-)
  create mode 100644 xen/include/asm-arm/vpsci.h

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 979d32ed6d..884f0fa710 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -16,7 +16,7 @@
  
  #include 

  #include 
-#include 
+#include 
  #include 
  
  #include 

@@ -91,12 +91,12 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
  return PSCI_SUCCESS;
  }
  
-int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)

+static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
  {
  return do_common_cpu_on(vcpuid, entry_point, 0 , PSCI_VERSION(0, 1));
  }
  
-int32_t do_psci_cpu_off(uint32_t power_state)

+static int32_t do_psci_cpu_off(uint32_t power_state)
  {
  struct vcpu *v = current;
  if ( !test_and_set_bit(_VPF_down, >pause_flags) )
@@ -104,13 +104,14 @@ int32_t do_psci_cpu_off(uint32_t power_state)
  return PSCI_SUCCESS;
  }
  
-uint32_t do_psci_0_2_version(void)

+static uint32_t do_psci_0_2_version(void)
  {
  return PSCI_VERSION(0, 2);
  }
  
-register_t do_psci_0_2_cpu_suspend(uint32_t power_state, register_t entry_point,

-register_t context_id)
+static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
+  register_t entry_point,
+  register_t context_id)
  {
  struct vcpu *v = current;
  
@@ -123,13 +124,14 @@ register_t do_psci_0_2_cpu_suspend(uint32_t power_state, register_t entry_point,

  return PSCI_SUCCESS;
  }
  
-int32_t do_psci_0_2_cpu_off(void)

+static int32_t do_psci_0_2_cpu_off(void)
  {
  return do_psci_cpu_off(0);
  }
  
-int32_t do_psci_0_2_cpu_on(register_t target_cpu, register_t entry_point,

-   register_t context_id)
+static int32_t do_psci_0_2_cpu_on(register_t target_cpu,
+  register_t entry_point,
+  register_t context_id)
  {
  return do_common_cpu_on(target_cpu, entry_point, context_id,
  PSCI_VERSION(0, 2));
@@ -144,8 +146,8 @@ static const unsigned long target_affinity_mask[] = {
  #endif
  };
  
-int32_t do_psci_0_2_affinity_info(register_t target_affinity,

-  uint32_t lowest_affinity_level)
+static int32_t do_psci_0_2_affinity_info(register_t target_affinity,
+ uint32_t lowest_affinity_level)
  {
  struct domain *d = current->domain;
  struct vcpu *v;
@@ -172,23 +174,140 @@ int32_t do_psci_0_2_affinity_info(register_t 
target_affinity,
  return PSCI_0_2_AFFINITY_LEVEL_OFF;
  }
  
-uint32_t do_psci_0_2_migrate_info_type(void)

+static uint32_t do_psci_0_2_migrate_info_type(void)
  {
  return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
  }
  
-void do_psci_0_2_system_off( void )

+static void do_psci_0_2_system_off( void )
  {
  struct domain *d = current->domain;
  domain_shutdown(d,SHUTDOWN_poweroff);
  }
  
-void do_psci_0_2_system_reset(void)

+static void do_psci_0_2_system_reset(void)
  {
  struct domain *d = current->domain;
  domain_shutdown(d,SHUTDOWN_reboot);
  }
  
+#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)

+#define PSCI_ARG(reg, n) get_user_reg(reg, n)
+
+#ifdef CONFIG_ARM_64
+#define PSCI_ARG32(reg, n) (uint32_t)(get_user_reg(reg, n))
+#else
+#define PSCI_ARG32(reg, n) PSCI_ARG(reg, n)
+#endif
+
+/*
+ * PSCI 0.1 calls. It will return false if the function ID is not
+ * handled.
+ */
+bool do_vpsci_0_1_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+switch ( (uint32_t)get_user_reg(regs, 0) )
+{

[Xen-devel] [PATCH v4 3/7] xen/arm32: entry: Add missing trap_reset entry

[Julien Grall]

At the moment, the reset vector is defined as .word 0 (e.g andeq r0, r0,
r0).

This is rather unintuitive and will result to execute the trap
undefined. Instead introduce trap helpers for reset and will generate an
error message in the unlikely case that reset will be called.

This is part of XSA-254.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Replace .word 0 by trap_reset
---
 xen/arch/arm/arm32/entry.S | 3 ++-
 xen/arch/arm/arm32/traps.c | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index c6490d2847..64876c1184 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -137,7 +137,7 @@ trap_##trap:
\
 
 .align 5
 GLOBAL(hyp_traps_vector)
-.word 0 /* 0x00 - Reset */
+b trap_reset/* 0x00 - Reset */
 b trap_undefined_instruction/* 0x04 - Undefined Instruction */
 b trap_hypervisor_call  /* 0x08 - Hypervisor Call */
 b trap_prefetch_abort   /* 0x0c - Prefetch Abort */
@@ -146,6 +146,7 @@ GLOBAL(hyp_traps_vector)
 b trap_irq  /* 0x18 - IRQ */
 b trap_fiq  /* 0x1c - FIQ */
 
+DEFINE_TRAP_ENTRY(reset)
 DEFINE_TRAP_ENTRY(undefined_instruction)
 DEFINE_TRAP_ENTRY(hypervisor_call)
 DEFINE_TRAP_ENTRY(prefetch_abort)
diff --git a/xen/arch/arm/arm32/traps.c b/xen/arch/arm/arm32/traps.c
index 705255883e..4f27543dec 100644
--- a/xen/arch/arm/arm32/traps.c
+++ b/xen/arch/arm/arm32/traps.c
@@ -23,6 +23,11 @@
 
 #include 
 
+void do_trap_reset(struct cpu_user_regs *regs)
+{
+do_unexpected_trap("Reset", regs);
+}
+
 void do_trap_undefined_instruction(struct cpu_user_regs *regs)
 {
 uint32_t pc = regs->pc;
-- 
2.11.0


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

[Xen-devel] [PATCH v4 0/7] xen/arm32: Branch predictor hardening (XSA-254 variant 2)

[Julien Grall]

Hi all,

This series provides a skeleton for mitigating branch predictor hardening for
arm32 on exception entry.

It also implements mitigation for Cortex-A12, A15 and A17. SoC vendors with
affected CPUs are strongly encouraged to update.

For more information about the impact of this issue and the software mitigations
for Arm processors, please see http://www.arm.com/security-update.

Cheers,

Julien Grall (7):
  xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros
  xen/arm32: Add missing MIDR values for Cortex-A17 and A12
  xen/arm32: entry: Add missing trap_reset entry
  xen/arm32: Add skeleton to harden branch predictor aliasing attacks
  xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
  xen/arm32: Invalidate icache on guest exist for Cortex-A15
  xen/arm32: entry: Document the purpose of r11 in the traps handler

 xen/arch/arm/Kconfig|   3 +
 xen/arch/arm/arm32/entry.S  | 147 +---
 xen/arch/arm/arm32/traps.c  |   5 ++
 xen/arch/arm/cpuerrata.c|  62 +
 xen/include/asm-arm/processor.h |   4 ++
 5 files changed, 196 insertions(+), 25 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH v4 6/7] xen/arm32: Invalidate icache on guest exist for Cortex-A15

[Julien Grall]

In order to avoid aliasing attacks against the branch predictor on
Cortex A-15, let's invalidate the BTB on guest exit, which can only be
done by invalidating the icache (with ACTLR[0] being set).

We use the same hack as for A12/A17 to perform the vector decoding.

This is based on Linux patch from the kpti branch in [1].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git

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

Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/arm32/entry.S | 21 +
 xen/arch/arm/cpuerrata.c   | 13 +
 2 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index 1ebbe4b065..2f8b7cb7b8 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -163,6 +163,26 @@ GLOBAL(hyp_traps_vector)
 #ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
 
 .align 5
+GLOBAL(hyp_traps_vector_ic_inv)
+/*
+ * We encode the exception entry in the bottom 3 bits of
+ * SP, and we have to guarantee to be 8 bytes aligned.
+ */
+add sp, sp, #1  /* Reset7 */
+add sp, sp, #1  /* Undef6 */
+add sp, sp, #1  /* Hypervisor call  5 */
+add sp, sp, #1  /* Prefetch abort   4 */
+add sp, sp, #1  /* Data abort   3 */
+add sp, sp, #1  /* Hypervisor   2 */
+add sp, sp, #1  /* IRQ  1 */
+nop /* FIQ  0 */
+
+mcr p15, 0, r0, c7, c5, 0   /* ICIALLU */
+isb
+
+b decode_vectors
+
+.align 5
 GLOBAL(hyp_traps_vector_bp_inv)
 /*
  * We encode the exception entry in the bottom 3 bits of
@@ -180,6 +200,7 @@ GLOBAL(hyp_traps_vector_bp_inv)
 mcrp15, 0, r0, c7, c5, 6   /* BPIALL */
 isb
 
+decode_vectors:
 .macro vect_br val, targ
 eor sp, sp, #\val
 tst sp, #7
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index c79e6d65d3..9c7458ef06 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -180,6 +180,7 @@ static int enable_psci_bp_hardening(void *data)
 DEFINE_PER_CPU_READ_MOSTLY(const char *, bp_harden_vecs);
 
 extern char hyp_traps_vector_bp_inv[];
+extern char hyp_traps_vector_ic_inv[];
 
 static void __maybe_unused
 install_bp_hardening_vecs(const struct arm_cpu_capabilities *entry,
@@ -205,6 +206,13 @@ static int enable_bp_inv_hardening(void *data)
 return 0;
 }
 
+static int enable_ic_inv_hardening(void *data)
+{
+install_bp_hardening_vecs(data, hyp_traps_vector_ic_inv,
+  "execute ICIALLU");
+return 0;
+}
+
 #endif
 
 #define MIDR_RANGE(model, min, max) \
@@ -302,6 +310,11 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 MIDR_ALL_VERSIONS(MIDR_CORTEX_A17),
 .enable = enable_bp_inv_hardening,
 },
+{
+.capability = ARM_HARDEN_BRANCH_PREDICTOR,
+MIDR_ALL_VERSIONS(MIDR_CORTEX_A15),
+.enable = enable_ic_inv_hardening,
+},
 #endif
 {},
 };
-- 
2.11.0


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

[Xen-devel] [PATCH v4 2/7] xen/arm32: Add missing MIDR values for Cortex-A17 and A12

[Julien Grall]

Cortex-A17 and A12 MIDR will be used in a follow-up patch for hardening
the branch predictor.

This is part of XSA-254.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/include/asm-arm/processor.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 466da5da86..c0f79d0093 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -44,6 +44,8 @@
 
 #define ARM_CPU_IMP_ARM 0x41
 
+#define ARM_CPU_PART_CORTEX_A12 0xC0D
+#define ARM_CPU_PART_CORTEX_A17 0xC0E
 #define ARM_CPU_PART_CORTEX_A15 0xC0F
 #define ARM_CPU_PART_CORTEX_A53 0xD03
 #define ARM_CPU_PART_CORTEX_A57 0xD07
@@ -51,6 +53,8 @@
 #define ARM_CPU_PART_CORTEX_A73 0xD09
 #define ARM_CPU_PART_CORTEX_A75 0xD0A
 
+#define MIDR_CORTEX_A12 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A12)
+#define MIDR_CORTEX_A17 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A17)
 #define MIDR_CORTEX_A15 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A15)
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
-- 
2.11.0


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

[Xen-devel] [PATCH v4 5/7] xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12

[Julien Grall]

In order to avoid aliasing attackes agains the branch predictor, let's
invalidate the BTB on guest exist. This is made complicated by the fact
that we cannot take a branch invalidating the BTB.

This is based on the fourth version posted by Marc Zyngier on Linux-arm
mailing list (see [1]).

This is part of XSA-254.

[1] https://www.spinics.net/lists/arm-kernel/msg632062.html

Signed-off-by: Marc Zyngier 
Signed-off-by: Julien Grall 

---
Changes in v3:
- Drop Stefano's reviewed-by
- Use the latest version of the Linux patch. This will improve
code readability.

Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/arm32/entry.S | 38 ++
 xen/arch/arm/cpuerrata.c   | 19 +++
 2 files changed, 57 insertions(+)

diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index 828e52c25c..1ebbe4b065 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -160,6 +160,44 @@ GLOBAL(hyp_traps_vector)
 b trap_irq  /* 0x18 - IRQ */
 b trap_fiq  /* 0x1c - FIQ */
 
+#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
+
+.align 5
+GLOBAL(hyp_traps_vector_bp_inv)
+/*
+ * We encode the exception entry in the bottom 3 bits of
+ * SP, and we have to guarantee to be 8 bytes aligned.
+ */
+add sp, sp, #1  /* Reset7 */
+add sp, sp, #1  /* Undef6 */
+add sp, sp, #1  /* Hypervisor Call  5 */
+add sp, sp, #1  /* Prefetch abort   4 */
+add sp, sp, #1  /* Data abort   3 */
+add sp, sp, #1  /* Hypervisor   2 */
+add sp, sp, #1  /* IRQ  1 */
+nop /* FIQ  0 */
+
+mcrp15, 0, r0, c7, c5, 6   /* BPIALL */
+isb
+
+.macro vect_br val, targ
+eor sp, sp, #\val
+tst sp, #7
+eorne   sp, sp, #\val
+beq \targ
+.endm
+
+vect_br 0, trap_fiq
+vect_br 1, trap_irq
+vect_br 2, trap_guest_sync
+vect_br 3, trap_data_abort
+vect_br 4, trap_prefetch_abort
+vect_br 5, trap_hypervisor_call
+vect_br 6, trap_undefined_instruction
+vect_br 7, trap_reset
+
+#endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
+
 DEFINE_TRAP_ENTRY(reset)
 DEFINE_TRAP_ENTRY(undefined_instruction)
 DEFINE_TRAP_ENTRY(hypervisor_call)
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 0a138fa735..c79e6d65d3 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -198,6 +198,13 @@ install_bp_hardening_vecs(const struct 
arm_cpu_capabilities *entry,
 this_cpu(bp_harden_vecs) = hyp_vecs;
 }
 
+static int enable_bp_inv_hardening(void *data)
+{
+install_bp_hardening_vecs(data, hyp_traps_vector_bp_inv,
+  "execute BPIALL");
+return 0;
+}
+
 #endif
 
 #define MIDR_RANGE(model, min, max) \
@@ -284,6 +291,18 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 .enable = enable_psci_bp_hardening,
 },
 #endif
+#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
+{
+.capability = ARM_HARDEN_BRANCH_PREDICTOR,
+MIDR_ALL_VERSIONS(MIDR_CORTEX_A12),
+.enable = enable_bp_inv_hardening,
+},
+{
+.capability = ARM_HARDEN_BRANCH_PREDICTOR,
+MIDR_ALL_VERSIONS(MIDR_CORTEX_A17),
+.enable = enable_bp_inv_hardening,
+},
+#endif
 {},
 };
 
-- 
2.11.0


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

[Xen-devel] [PATCH v4 4/7] xen/arm32: Add skeleton to harden branch predictor aliasing attacks

[Julien Grall]

Aliasing attacked against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
information from one context to another.

This patch adds initiatial skeleton code behind a new Kconfig option
to enable implementation-specific mitigations against these attacks
for CPUs that are affected.

Most of mitigations will have to be applied when entering to the
hypervisor from the guest context.

Because the attack is against branch predictor, it is not possible to
safely use branch instruction before the mitigation is applied.
Therefore this has to be done in the vector entry before jump to the
helper handling a given exception.

However, on arm32, each vector contain a single instruction. This means
that the hardened vector tables may rely on the state of registers that
does not hold when in the hypervisor (e.g SP is 8 bytes aligned).
Therefore hypervisor code running with guest vectors table should be
minimized and always have IRQs and SErrors masked to reduce the risk to
use them.

This patch provides an infrastructure to switch vector tables before
entering to the guest and when leaving it.

Note that alternative could have been used, but older Xen (4.8 or
earlier) doesn't have support. So avoid using alternative to ease
backporting.

This is part of XSA-254.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Clarify the commit message
---
 xen/arch/arm/Kconfig   |  3 +++
 xen/arch/arm/arm32/entry.S | 41 -
 xen/arch/arm/cpuerrata.c   | 30 ++
 3 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 06fd85cc77..2782ee6589 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -191,6 +191,9 @@ config HARDEN_BRANCH_PREDICTOR
 config ARM64_HARDEN_BRANCH_PREDICTOR
 def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
 
+config ARM32_HARDEN_BRANCH_PREDICTOR
+def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
+
 source "common/Kconfig"
 
 source "drivers/Kconfig"
diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index 64876c1184..828e52c25c 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -34,6 +34,20 @@
 blne save_guest_regs
 
 save_guest_regs:
+#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
+/*
+ * Restore vectors table to the default as it may have been
+ * changed when returning to the guest (see
+ * return_to_hypervisor). We need to do that early (e.g before
+ * any interrupts are unmasked) because hardened vectors requires
+ * SP to be 8 bytes aligned. This does not hold when running in
+ * the hypervisor.
+ */
+ldr r1, =hyp_traps_vector
+mcr p15, 4, r1, c12, c0, 0
+isb
+#endif
+
 ldr r11, =0x  /* Clobber SP which is only valid for hypervisor 
frames. */
 str r11, [sp, #UREGS_sp]
 SAVE_ONE_BANKED(SP_usr)
@@ -179,12 +193,37 @@ return_to_guest:
 RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
 /* Fall thru */
 return_to_hypervisor:
-cpsid i
+cpsid ai
 ldr lr, [sp, #UREGS_lr]
 ldr r11, [sp, #UREGS_pc]
 msr ELR_hyp, r11
 ldr r11, [sp, #UREGS_cpsr]
 msr SPSR_hyp, r11
+#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
+/*
+ * Hardening branch predictor may require to setup a different
+ * vector tables before returning to the guests. Those vectors
+ * may rely on the state of registers that does not hold when
+ * running in the hypervisor (e.g SP is 8 bytes aligned). So setup
+ * HVBAR very late.
+ *
+ * Default vectors table will be restored on exit (see
+ * save_guest_regs).
+ */
+mov r9, #0  /* vector tables = NULL */
+/*
+ * Load vector tables pointer from the per-cpu bp_harden_vecs
+ * when returning to the guest only.
+ */
+and r11, #PSR_MODE_MASK
+cmp r11, #PSR_MODE_HYP
+ldrne r11, =per_cpu__bp_harden_vecs
+mrcne p15, 4, r10, c13, c0, 2   /* r10 = per-cpu offset (HTPIDR) */
+addne r11, r11, r10 /* r11 = offset of the vector tables */
+ldrne r9, [r11] /* r9  = vector tables */
+cmp r9, #0  /* Only update HVBAR when the vector */
+mcrne p15, 4, r9, c12, c0, 0/* tables is not NULL. */
+#endif
 pop {r0-r12}
 add sp, #(UREGS_SP_usr - UREGS_sp); /* SP, LR, SPSR, PC */
 clrex
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index f1ea7f3c5b..0a138fa735 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -170,6 +170,36 @@ static int enable_psci_bp_hardening(void *data)
 
 #endif /* CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR */
 
+/* 

[Xen-devel] [PATCH v4 7/7] xen/arm32: entry: Document the purpose of r11 in the traps handler

[Julien Grall]

It took me a bit of time to understand why __DEFINE_TRAP_ENTRY is
storing the original stack pointer in r11. It is working in pair with
return_traps_entry where sp will be restored from r11.

This is fine because per the AAPCS r11 must be preserved by the
subroutine. So in return_from_trap, r11 will still contain the original
stack pointer.

Add some documentation in the code to point the 2 sides to each other.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/arm32/entry.S | 8 
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index 2f8b7cb7b8..f6908e3f16 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -136,6 +136,10 @@ trap_##trap:   
 \
 cpsie iflags;   \
 adr lr, return_from_trap;   \
 mov r0, sp; \
+/*  \
+ * Save the stack pointer in r11. It will be restored after the \
+ * trap has been handled (see return_from_trap).\
+ */ \
 mov r11, sp;\
 bic sp, #7; /* Align the stack pointer (noop on guest trap) */  \
 b do_trap_##trap
@@ -229,6 +233,10 @@ DEFINE_TRAP_ENTRY_NOIRQ(fiq)
 DEFINE_TRAP_ENTRY_NOABORT(data_abort)
 
 return_from_trap:
+/*
+ * Restore the stack pointer from r11. It was saved on exception
+ * entry (see __DEFINE_TRAP_ENTRY).
+ */
 mov sp, r11
 ENTRY(return_to_new_vcpu32)
 ldr r11, [sp, #UREGS_cpsr]
-- 
2.11.0


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

Re: [Xen-devel] Compatible string for psci node: v1.0?

[Mirela Simonovic]

Hi Julien,

Thanks, it looks like the issue was with the way I verified this - cat on
/sys/firmware/devicetree/base/psci/compatible from dom0's console returns
only the first compatible string set by Xen no matter what.
I have verified by debugging that linux finds the right compatible string
in psci_dt_init().

Thanks,
Mirela

On Thu, Feb 1, 2018 at 8:12 PM, Julien Grall  wrote:

> On 01/02/18 19:00, Mirela Simonovic wrote:
>
>> Hi,
>>
>
> Hi Mirela,
>
>
>>
>> I'm working on switching to PSCI v1.0 in Xen (needed to support suspend
>> > to RAM).
>>
>
> I am about to send a series to add support for PSCI 1.1 (I need it for the
> spectre mitigation). I can send you a temporary branch if you want to see
> whether I missed anything.
>
>
>> In addition to updates in PSCI implementation, we assumed that compatible
>> property in psci device tree node should be extended with "arm,psci-1.0"
>> (not a must since this doesn't affect Dom0's functionality today, but I
>> would add it if possible).
>>
>> Could you please let me know how to add "arm,psci-1.0" to compatible
>> property?
>>
>> I assumed that in domain_build.c in make_psci_node() function I need to
>> add "arm,psci-1.0""\0" at the beginning of 'compat' string (although I
>> don't understand the "\0"). That doesn't seem to work. Only "arm,psci-1.0"
>> ends up in compatible property and we need strings for older versions as
>> well.
>> I also noticed that even "arm,psci" doesn't appear to be added into the
>> compatible property (without any code modifications from my side). I
>> checked what is generated by debugging and by 'cat' on
>> /sys/firmware/devicetree/base/psci/compatible from Dom0's console.
>>
>
> From the DT specification, each compatible string should be separated by
> '\0'. Doing a hexdump -C in the hardware domain I can see that both
> arm,psci and arm,psci-0.2 are present on latest Xen. So I am not sure why
> it would not be present on your side.
>
> BTW, if you use printk, only the first compatible will be printed (printk
> stop at the '\0').
>
> 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 19/25] x86emul: tell cmpxchg hook whether LOCK is in effect

[Andrew Cooper]

On 07/12/17 14:14, Jan Beulich wrote:
> This is necessary for the hook to correctly perform the operation.
>
> Signed-off-by: Jan Beulich 

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 v3 18/25] x86emul: add missing suffixes in test harness

[Andrew Cooper]

On 07/12/17 14:12, Jan Beulich wrote:
> I'm in the process of putting together a gas change issuing at least
> warnings when the intended size of a memory operation can't be deduced
> from another (register) operand. Add missing suffixes to silence such
> future diagnostics.
>
> Signed-off-by: Jan Beulich 

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 v3 17/25] x86emul: emulate {MONITOR, MWAIT}{, X} as no-op

[Andrew Cooper]

On 07/12/17 14:11, Jan Beulich wrote:
> As mentioned in Linux commit 87c00572ba ("kvm: x86: emulate monitor and
> mwait instructions as nop"), older OS X versions (for example) may make
> use of the insns without checking CPUID flags (presumably implying
> availability from family/model).

-1 to this.

IIRC, monitor and mwait are disabled entirely due to VMCS/VMCB
configuration, and convert to #UD internally.  The emulator shouldn't be
able to let software work around that.

If and when we decide to support this functionality for guests (which
probably won't be until after EPT SPP gets in), then the feature should
use CPUID as per normal.

There is a large list of other things which prevent OS X from booting
under Xen.  If someone decides to step up and get OS X support working
then we could reconsider whether we quirk this, but until then,
unilaterally quirking it is a net negative.

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: vsmc: Don't implement function ID that doesn't exist

[Volodymyr Babchuk]

On 02.02.18 13:41, Julien Grall wrote:

The current implementation of SMCCC relies on the fact only function
number (bits [15:0]) is enough to identify what to implement.

However, PSCI call are only available in the range 0x8400-0x841F
and 0xC400-0xC41F. Furthermore, not all SMC32 functions have
equivalent in the SMC64. This is the case of:
 * PSCI_VERSION
 * CPU_OFF
 * MIGRATE_INFO_TYPE
 * SYSTEM_OFF
 * SYSTEM_RESET

Similarly call count, call uid, revision can only be query using smc32/hvc32
fast calls (See 6.2 in ARM DEN 0028B).

Xen should only implement identifier existing in the specification in
order to avoid potential clash with later revision. Therefore rework the
vsmc code to use the whole function identifier rather than only the
function number.

At the same time, the new macros for call count, call uid, revision are
renamed to better suit the spec.

Lastly, update SSSC_SMCCC_FUNCTION_COUNT to match the correct number of
funtions. Note that version is not updated because the number has always
been wrong, and nobody could properly use it.

Signed-off-by: Julien Grall 


`Reviewed-by: Volodymyr Babchuk `

---
 This should be backported to Xen 4.10 as we should not implement
 functions identifier that does not exist toprevent clash with a
 later revision.

 Changes in v2:
 - Rename the call count, call uid, revision macros
 - Update SSSC_SMCCC_FUNCTION_COUNT
---
  xen/arch/arm/vsmc.c | 39 ++-
  xen/include/asm-arm/smccc.h | 20 +---
  2 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 997f2e0ebc..3d8cbcc808 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -28,7 +28,7 @@
  #define XEN_SMCCC_FUNCTION_COUNT 3
  
  /* Number of functions currently supported by Standard Service Service Calls. */

-#define SSSC_SMCCC_FUNCTION_COUNT 11
+#define SSSC_SMCCC_FUNCTION_COUNT 14
  
  static bool fill_uid(struct cpu_user_regs *regs, xen_uuid_t uuid)

  {
@@ -84,13 +84,15 @@ static bool fill_function_call_count(struct cpu_user_regs 
*regs, uint32_t cnt)
  /* SMCCC interface for hypervisor. Tell about itself. */
  static bool handle_hypervisor(struct cpu_user_regs *regs)
  {
-switch ( smccc_get_fn(get_user_reg(regs, 0)) )
+uint32_t fid = (uint32_t)get_user_reg(regs, 0);
+
+switch ( fid )
  {
-case ARM_SMCCC_FUNC_CALL_COUNT:
+case ARM_SMCCC_CALL_COUNT_FID(HYPERVISOR):
  return fill_function_call_count(regs, XEN_SMCCC_FUNCTION_COUNT);
-case ARM_SMCCC_FUNC_CALL_UID:
+case ARM_SMCCC_CALL_UID_FID(HYPERVISOR):
  return fill_uid(regs, XEN_SMCCC_UID);
-case ARM_SMCCC_FUNC_CALL_REVISION:
+case ARM_SMCCC_REVISION_FID(HYPERVISOR):
  return fill_revision(regs, XEN_SMCCC_MAJOR_REVISION,
   XEN_SMCCC_MINOR_REVISION);
  default:
@@ -140,36 +142,37 @@ static bool handle_sssc(struct cpu_user_regs *regs)
  {
  uint32_t fid = (uint32_t)get_user_reg(regs, 0);
  
-switch ( smccc_get_fn(fid) )

+switch ( fid )
  {
-case PSCI_0_2_FN_PSCI_VERSION:
+case PSCI_0_2_FN32(PSCI_VERSION):
  perfc_incr(vpsci_version);
  PSCI_SET_RESULT(regs, do_psci_0_2_version());
  return true;
  
-case PSCI_0_2_FN_CPU_OFF:

+case PSCI_0_2_FN32(CPU_OFF):
  perfc_incr(vpsci_cpu_off);
  PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
  return true;
  
-case PSCI_0_2_FN_MIGRATE_INFO_TYPE:

+case PSCI_0_2_FN32(MIGRATE_INFO_TYPE):
  perfc_incr(vpsci_migrate_info_type);
  PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
  return true;
  
-case PSCI_0_2_FN_SYSTEM_OFF:

+case PSCI_0_2_FN32(SYSTEM_OFF):
  perfc_incr(vpsci_system_off);
  do_psci_0_2_system_off();
  PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
  return true;
  
-case PSCI_0_2_FN_SYSTEM_RESET:

+case PSCI_0_2_FN32(SYSTEM_RESET):
  perfc_incr(vpsci_system_reset);
  do_psci_0_2_system_reset();
  PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
  return true;
  
-case PSCI_0_2_FN_CPU_ON:

+case PSCI_0_2_FN32(CPU_ON):
+case PSCI_0_2_FN64(CPU_ON):
  {
  register_t vcpuid = PSCI_ARG(regs, 1);
  register_t epoint = PSCI_ARG(regs, 2);
@@ -180,7 +183,8 @@ static bool handle_sssc(struct cpu_user_regs *regs)
  return true;
  }
  
-case PSCI_0_2_FN_CPU_SUSPEND:

+case PSCI_0_2_FN32(CPU_SUSPEND):
+case PSCI_0_2_FN64(CPU_SUSPEND):
  {
  uint32_t pstate = PSCI_ARG32(regs, 1);
  register_t epoint = PSCI_ARG(regs, 2);
@@ -191,7 +195,8 @@ static bool handle_sssc(struct cpu_user_regs *regs)
  return true;
  }
  
-case PSCI_0_2_FN_AFFINITY_INFO:

+case PSCI_0_2_FN32(AFFINITY_INFO):
+

Re: [Xen-devel] [PATCH v2 1/3] xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU

[Volodymyr Babchuk]

Hi Julien,

On 02.02.18 13:41, Julien Grall wrote:

The PSCI call MIGRATE and MIGRATE_INFO_UP_CPU are optional and
implemented as just returning PSCI_NOT_SUPPORTED (aka UNKNOWN_FUNCTION
for SMCCC).

The new SMCCC framework is able to deal with unimplemented function and
return the proper error code. So remove the implementations for both
function.

Signed-off-by: Julien Grall 


`Reviewed-by: Volodymyr Babchuk `

---
 Changes in v2:
 - Remove define in psci.h
 - Update SSSC_SMCCC_FUNCTION_COUNT
---
  xen/arch/arm/vpsci.c | 10 --
  xen/arch/arm/vsmc.c  | 16 +---
  xen/include/asm-arm/perfc_defn.h |  2 --
  xen/include/asm-arm/psci.h   |  4 
  4 files changed, 1 insertion(+), 31 deletions(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index cd724904ef..979d32ed6d 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -172,21 +172,11 @@ int32_t do_psci_0_2_affinity_info(register_t 
target_affinity,
  return PSCI_0_2_AFFINITY_LEVEL_OFF;
  }
  
-int32_t do_psci_0_2_migrate(uint32_t target_cpu)

-{
-return PSCI_NOT_SUPPORTED;
-}
-
  uint32_t do_psci_0_2_migrate_info_type(void)
  {
  return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
  }
  
-register_t do_psci_0_2_migrate_info_up_cpu(void)

-{
-return PSCI_NOT_SUPPORTED;
-}
-
  void do_psci_0_2_system_off( void )
  {
  struct domain *d = current->domain;
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index c9064de37a..997f2e0ebc 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -28,7 +28,7 @@
  #define XEN_SMCCC_FUNCTION_COUNT 3
  
  /* Number of functions currently supported by Standard Service Service Calls. */

-#define SSSC_SMCCC_FUNCTION_COUNT 13
+#define SSSC_SMCCC_FUNCTION_COUNT 11
  
  static bool fill_uid(struct cpu_user_regs *regs, xen_uuid_t uuid)

  {
@@ -157,11 +157,6 @@ static bool handle_sssc(struct cpu_user_regs *regs)
  PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
  return true;
  
-case PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:

-perfc_incr(vpsci_migrate_info_up_cpu);
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
-return true;
-
  case PSCI_0_2_FN_SYSTEM_OFF:
  perfc_incr(vpsci_system_off);
  do_psci_0_2_system_off();
@@ -206,15 +201,6 @@ static bool handle_sssc(struct cpu_user_regs *regs)
  return true;
  }
  
-case PSCI_0_2_FN_MIGRATE:

-{
-uint32_t tcpu = PSCI_ARG32(regs, 1);
-
-perfc_incr(vpsci_cpu_migrate);
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate(tcpu));
-return true;
-}
-
  case ARM_SMCCC_FUNC_CALL_COUNT:
  return fill_function_call_count(regs, SSSC_SMCCC_FUNCTION_COUNT);
  
diff --git a/xen/include/asm-arm/perfc_defn.h b/xen/include/asm-arm/perfc_defn.h

index 5f957ee6ec..a7acb7d21c 100644
--- a/xen/include/asm-arm/perfc_defn.h
+++ b/xen/include/asm-arm/perfc_defn.h
@@ -27,12 +27,10 @@ PERFCOUNTER(vpsci_cpu_on,  "vpsci: cpu_on")
  PERFCOUNTER(vpsci_cpu_off, "vpsci: cpu_off")
  PERFCOUNTER(vpsci_version, "vpsci: version")
  PERFCOUNTER(vpsci_migrate_info_type,   "vpsci: migrate_info_type")
-PERFCOUNTER(vpsci_migrate_info_up_cpu, "vpsci: migrate_info_up_cpu")
  PERFCOUNTER(vpsci_system_off,  "vpsci: system_off")
  PERFCOUNTER(vpsci_system_reset,"vpsci: system_reset")
  PERFCOUNTER(vpsci_cpu_suspend, "vpsci: cpu_suspend")
  PERFCOUNTER(vpsci_cpu_affinity_info,   "vpsci: cpu_affinity_info")
-PERFCOUNTER(vpsci_cpu_migrate, "vpsci: cpu_migrate")
  
  PERFCOUNTER(vgicd_reads,"vgicd: read")

  PERFCOUNTER(vgicd_writes,   "vgicd: write")
diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
index 635ea5dae4..32c1f81f21 100644
--- a/xen/include/asm-arm/psci.h
+++ b/xen/include/asm-arm/psci.h
@@ -37,9 +37,7 @@ int32_t do_psci_0_2_cpu_on(register_t target_cpu, register_t 
entry_point,
 register_t context_id);
  int32_t do_psci_0_2_affinity_info(register_t target_affinity,
uint32_t lowest_affinity_level);
-int32_t do_psci_0_2_migrate(uint32_t target_cpu);
  uint32_t do_psci_0_2_migrate_info_type(void);
-register_t do_psci_0_2_migrate_info_up_cpu(void);
  void do_psci_0_2_system_off(void);
  void do_psci_0_2_system_reset(void);
  
@@ -57,9 +55,7 @@ void do_psci_0_2_system_reset(void);

  #define PSCI_0_2_FN_CPU_OFF 2
  #define PSCI_0_2_FN_CPU_ON  3
  #define PSCI_0_2_FN_AFFINITY_INFO   4
-#define PSCI_0_2_FN_MIGRATE 5
  #define PSCI_0_2_FN_MIGRATE_INFO_TYPE   6
-#define PSCI_0_2_FN_MIGRATE_INFO_UP_CPU 7
  #define PSCI_0_2_FN_SYSTEM_OFF  8
  #define PSCI_0_2_FN_SYSTEM_RESET9
  



--
Volodymyr Babchuk

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

Re: [Xen-devel] [PATCH v3 16/25] x86emul: support SWAPGS

[Andrew Cooper]

On 07/12/17 14:11, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 
> ---
> v3: New.
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -5047,6 +5047,24 @@ x86_emulate(
>  goto done;
>  break;
>  
> +case 0xf8: /* swapgs */
> +generate_exception_if(!mode_64bit(), EXC_UD);
> +generate_exception_if(!mode_ring0(), EXC_GP, 0);
> +fail_if(!ops->read_segment || !ops->read_msr ||
> +!ops->write_segment || !ops->write_msr);
> +if ( (rc = ops->read_segment(x86_seg_gs, ,
> + ctxt)) != X86EMUL_OKAY ||
> + (rc = ops->read_msr(MSR_SHADOW_GS_BASE, _val,
> + ctxt)) != X86EMUL_OKAY ||
> + (rc = ops->write_msr(MSR_SHADOW_GS_BASE, sreg.base,
> +  ctxt)) != X86EMUL_OKAY )

We need to unwind this write in the case of write_segment failing, or
when the instruction restarts, state will be corrupt.

~Andrew

> +goto done;
> +sreg.base = msr_val;
> +if ( (rc = ops->write_segment(x86_seg_gs, ,
> +  ctxt)) != X86EMUL_OKAY )
> +goto done;
> +break;
> +
>  case 0xf9: /* rdtscp */
>  fail_if(ops->read_msr == NULL);
>  if ( (rc = ops->read_msr(MSR_TSC_AUX,
>
>
>


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

Re: [Xen-devel] [PATCH v3 14/25] x86emul: make all FPU emulation use the stub

[Andrew Cooper]

On 07/12/17 14:09, Jan Beulich wrote:
> While this means quite some reduction of (source) code, the main
> purpose is to no longer have exceptions raised from other than stubs.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper  for the reduction
alone, but with a recommendation.

> @@ -4266,37 +4262,13 @@ x86_emulate(
>  emulate_fpu_insn_stub(0xd8, modrm);
>  break;
>  default:
> +fpu_memsrc32:
>  ASSERT(ea.type == OP_MEM);
>  if ( (rc = ops->read(ea.mem.seg, ea.mem.off, ,
>   4, ctxt)) != X86EMUL_OKAY )
>  goto done;
> -switch ( modrm_reg & 7 )
> -{
> -case 0: /* fadd */
> -emulate_fpu_insn_memsrc("fadds", src.val);
> -break;
> -case 1: /* fmul */
> -emulate_fpu_insn_memsrc("fmuls", src.val);
> -break;
> -case 2: /* fcom */
> -emulate_fpu_insn_memsrc("fcoms", src.val);
> -break;
> -case 3: /* fcomp */
> -emulate_fpu_insn_memsrc("fcomps", src.val);
> -break;
> -case 4: /* fsub */
> -emulate_fpu_insn_memsrc("fsubs", src.val);
> -break;
> -case 5: /* fsubr */
> -emulate_fpu_insn_memsrc("fsubrs", src.val);
> -break;
> -case 6: /* fdiv */
> -emulate_fpu_insn_memsrc("fdivs", src.val);
> -break;
> -case 7: /* fdivr */
> -emulate_fpu_insn_memsrc("fdivrs", src.val);
> -break;
> -}
> +emulate_fpu_insn_memsrc(b, modrm_reg, src.val);

The modrm_reg & 7 should be visible here to make it obvious that the rex
prefix if any is dropped.  It is probably best to duplicate up the &7
because the one inside the macro is for encoding safety, and the
compiler can trivially combine the two.

~Andrew

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

Re: [Xen-devel] [PATCH v3 13/25] x86emul: adjust_bnd() should check XCR0

[Andrew Cooper]

On 07/12/17 14:08, Jan Beulich wrote:
> Experimentally MPX instructions have been confirmed to behave as NOPs
> unless both related XCR0 bits are set to 1. By implication branches
> then also don't clear BNDn.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -2143,12 +2143,16 @@ static bool umip_active(struct x86_emula
>  static void adjust_bnd(struct x86_emulate_ctxt *ctxt,
> const struct x86_emulate_ops *ops, enum vex_pfx pfx)
>  {
> -uint64_t bndcfg;
> +uint64_t xcr0, bndcfg;
>  int rc;
>  
>  if ( pfx == vex_f2 || !cpu_has_mpx || !vcpu_has_mpx() )
>  return;
>  
> +if ( !ops->read_xcr || ops->read_xcr(0, , ctxt) != X86EMUL_OKAY ||
> + !(xcr0 & XSTATE_BNDREGS) || !(xcr0 & XSTATE_BNDCSR) )

!(xcr0 & (XSTATE_BNDREGS | XSTATE_BNDCSR)) ?

Otherwise, Reviewed-by: Andrew Cooper 

> +return;
> +
>  if ( !mode_ring0() )
>  bndcfg = read_bndcfgu();
>  else if ( !ops->read_msr ||
>
>
>


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

Re: [Xen-devel] [PATCH v3 12/25] x86emul: abstract out XCRn accesses

[Andrew Cooper]

On 07/12/17 14:07, Jan Beulich wrote:
> --- a/tools/tests/x86_emulator/x86-emulate.c
> +++ b/tools/tests/x86_emulator/x86-emulate.c
> @@ -120,6 +120,19 @@ int emul_test_read_cr(
>  return X86EMUL_UNHANDLEABLE;
>  }
>  
> +int emul_test_read_xcr(
> +unsigned int reg,
> +uint64_t *val,
> +struct x86_emulate_ctxt *ctxt)
> +{
> +uint32_t lo, hi;
> +
> +asm ( "xgetbv" : "=a" (lo), "=d" (hi) : "c" (reg) );
> +*val = lo | ((uint64_t)hi << 32);

This will want a reg filter, or AFL will find that trying to read reg 2
will explode.

> +
> +return X86EMUL_OKAY;
> +}
> +
>  int emul_test_get_fpu(
>  void (*exception_callback)(void *, struct cpu_user_regs *),
>  void *exception_callback_arg,
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1825,6 +1825,49 @@ static int hvmemul_write_cr(
>  return rc;
>  }
>  
> +static int hvmemul_read_xcr(
> +unsigned int reg,
> +uint64_t *val,
> +struct x86_emulate_ctxt *ctxt)
> +{
> +uint32_t lo, hi;
> +
> +switch ( reg )
> +{
> +case 0:
> +*val = current->arch.xcr0;
> +return X86EMUL_OKAY;
> +
> +case 1:
> +if ( !cpu_has_xgetbv1 )
> +return X86EMUL_UNHANDLEABLE;
> +break;
> +
> +default:
> +return X86EMUL_UNHANDLEABLE;
> +}
> +
> +asm ( ".byte 0x0f,0x01,0xd0" /* xgetbv */
> +  : "=a" (lo), "=d" (hi) : "c" (reg) );

Please can we have a static inline?  It needs to be volatile, because
the result depends on unspecified other operations, which for xgetbv1
includes any instruction which alters xsave state.

Furthermore, does this actually return the correct result?  I'd prefer
if we didn't have to read from hardware here, but I can't see an
alternative.

From the guests point of view, we should at least have the guests xcr0
in context, but we have xcr0_accum loaded, meaning that the guest is
liable to see returned set bits which are higher than its idea of xcr0.

> +*val = lo | ((uint64_t)hi << 32);
> +HVMTRACE_LONG_2D(XCR_READ, reg, TRC_PAR_LONG(*val));
> +
> +return X86EMUL_OKAY;
> +}
> +
> +static int hvmemul_write_xcr(
> +unsigned int reg,
> +uint64_t val,
> +struct x86_emulate_ctxt *ctxt)
> +{
> +HVMTRACE_LONG_2D(XCR_WRITE, reg, TRC_PAR_LONG(val));
> +if ( likely(handle_xsetbv(reg, val) == 0) )
> +return X86EMUL_OKAY;
> +
> +x86_emul_hw_exception(TRAP_gp_fault, 0, ctxt);
> +return X86EMUL_EXCEPTION;

This exception is inconsistent with unhandleable above.  FTR, I'd expect
all of them to be exception rather than unhandleable.

> +}
> +
>  static int hvmemul_read_msr(
>  unsigned int reg,
>  uint64_t *val,
> @@ -5161,18 +5182,33 @@ x86_emulate(
>  _regs.eflags |= X86_EFLAGS_AC;
>  break;
>  
> -#ifdef __XEN__
> -case 0xd1: /* xsetbv */
> +case 0xd0: /* xgetbv */
>  generate_exception_if(vex.pfx, EXC_UD);
> -if ( !ops->read_cr || ops->read_cr(4, , ctxt) != 
> X86EMUL_OKAY )
> +if ( !ops->read_cr || !ops->read_xcr ||
> + ops->read_cr(4, , ctxt) != X86EMUL_OKAY )
>  cr4 = 0;
>  generate_exception_if(!(cr4 & X86_CR4_OSXSAVE), EXC_UD);
> -generate_exception_if(!mode_ring0() ||
> -  handle_xsetbv(_regs.ecx,
> -_regs.eax | (_regs.rdx << 
> 32)),
> +generate_exception_if(_regs.ecx > (vcpu_has_xgetbv1() ? 1 : 0),
>EXC_GP, 0);

I don't think this filtering is correct.  We don't filter on the xsetbv
side, or for the plain cr/dr index.  It should be up to the hook to
decide whether a specific index is appropriate.

> +rc = ops->read_xcr(_regs.ecx, _val, ctxt);
> +if ( rc != X86EMUL_OKAY )
> +goto done;
> +_regs.r(ax) = (uint32_t)msr_val;
> +_regs.r(dx) = msr_val >> 32;
> +break;
> +
> +case 0xd1: /* xsetbv */
> +generate_exception_if(vex.pfx, EXC_UD);
> +if ( !ops->read_cr || !ops->write_xcr ||
> + ops->read_cr(4, , ctxt) != X86EMUL_OKAY )
> +cr4 = 0;
> +generate_exception_if(!(cr4 & X86_CR4_OSXSAVE), EXC_UD);
> +generate_exception_if(!mode_ring0() || _regs.ecx, EXC_GP, 0);
> +rc = ops->write_xcr(_regs.ecx,
> +_regs.eax | ((uint64_t)_regs.edx << 32), 
> ctxt);
> +if ( rc != X86EMUL_OKAY )
> +goto done;
>  break;
> -#endif
>  
>  case 0xd4: /* vmfunc */
>  generate_exception_if(vex.pfx, EXC_UD);
> --- a/xen/include/asm-x86/x86-defns.h
> +++ b/xen/include/asm-x86/x86-defns.h
> @@ -66,4 +66,28 @@
>  #define X86_CR4_SMAP   0x0020 /* enable SMAP */
>  #define X86_CR4_PKE0x0040 /* enable PKE */
>  
> +/*
> + * XSTATE component 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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  252c5d7892fe76f4587ba43646d4d0c56ff81288
baseline version:
 xen  52ba201362aab4b09d44bcca67967c1053721ac2

Last test of basis   118509  2018-02-01 11:01:11 Z1 days
Testing same since   118537  2018-02-02 11:02:23 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  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
   52ba201362..252c5d7892  252c5d7892fe76f4587ba43646d4d0c56ff81288 -> smoke

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

Re: [Xen-devel] [PATCH v3 11/25] x86emul: place test blobs in executable section

[Andrew Cooper]

On 07/12/17 14:06, Jan Beulich wrote:
> This allows the section contents to be disassembled without going
> through any extra hoops, simplifying the analysis of problems in test
> and/or emulation code.
>
> The blobs being emitted as (r/o) data means we need to accept an
> assembler warning here (about the differing section attributes).
>
> Signed-off-by: Jan Beulich 

What about just giving up their constness?  This is a test program after
all.

~Andrew

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

Re: [Xen-devel] [PATCH v3 10/25] x86emul: support 3DNow! insns

[Andrew Cooper]

On 07/12/17 14:05, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -355,6 +355,36 @@ static const struct {
>  [0xff] = { ModRM }
>  };
>  
> +static const uint16_t _3dnow_table[16] = {

Comment explaining how these mappings work?  It looks like nibble
splits, but I still can't work out how to crossreference with the opcode
tables.

> +[0x0] = (1 << 0xd) /* pi2fd */,
> +[0x1] = (1 << 0xd) /* pf2id */,
> +[0x9] = (1 << 0x0) /* pfcmpge */ |
> +(1 << 0x4) /* pfmin */ |
> +(1 << 0x6) /* pfrcp */ |
> +(1 << 0x7) /* pfrsqrt */ |
> +(1 << 0xa) /* pfsub */ |
> +(1 << 0xe) /* pfadd */,
> +[0xa] = (1 << 0x0) /* pfcmpge */ |
> +(1 << 0x4) /* pfmax */ |
> +(1 << 0x6) /* pfrcpit1 */ |
> +(1 << 0x7) /* pfrsqit1 */ |
> +(1 << 0xa) /* pfsubr */ |
> +(1 << 0xe) /* pfacc */,
> +[0xb] = (1 << 0x0) /* pfcmpeq */ |
> +(1 << 0x4) /* pfmul */ |
> +(1 << 0x6) /* pfrcpit2 */ |
> +(1 << 0x7) /* pmulhrw */ |
> +(1 << 0xf) /* pavgusb */,
> +};
> +
> +static const uint16_t _3dnow_ext_table[16] = {
> +[0x1] = (1 << 0xd) /* pi2fw */,
> +[0x1] = (1 << 0xc) /* pf2iw */,

You presumably want an | in here instead?

> +[0x8] = (1 << 0xa) /* pfnacc */ |
> +(1 << 0xa) /* pfpnacc */,
> +[0xb] = (1 << 0xb) /* pfswapd */,
> +};
> +
>  /*
>   * "two_op" and "four_op" below refer to the number of register operands
>   * (one of which possibly also allowing to be a memory one). The named
> @@ -1671,6 +1701,8 @@ static bool vcpu_has(
>  #define vcpu_has_rdrand()  vcpu_has( 1, ECX, 30, ctxt, ops)
>  #define vcpu_has_mmxext() (vcpu_has(0x8001, EDX, 22, ctxt, ops) || \
> vcpu_has_sse())
> +#define vcpu_has_3dnow_ext()   vcpu_has(0x8001, EDX, 30, ctxt, ops)
> +#define vcpu_has_3dnow()   vcpu_has(0x8001, EDX, 31, ctxt, ops)
>  #define vcpu_has_lahf_lm() vcpu_has(0x8001, ECX,  0, ctxt, ops)
>  #define vcpu_has_cr8_legacy()  vcpu_has(0x8001, ECX,  4, ctxt, ops)
>  #define vcpu_has_lzcnt()   vcpu_has(0x8001, ECX,  5, ctxt, ops)
> @@ -5505,6 +5537,26 @@ x86_emulate(
>  case X86EMUL_OPC(0x0f, 0x19) ... X86EMUL_OPC(0x0f, 0x1f): /* nop */
>  break;
>  

0f 0d prefetches?  They are 3DNow instructions, but available on later
processors.

~Andrew

> +case X86EMUL_OPC(0x0f, 0x0e): /* femms */
> +host_and_vcpu_must_have(3dnow);
> +asm volatile ( "femms" );
> +break;
> +
> +case X86EMUL_OPC(0x0f, 0x0f): /* 3DNow! */
> +if ( _3dnow_ext_table[(imm1 >> 4) & 0xf] & (1 << (imm1 & 0xf)) )
> +host_and_vcpu_must_have(3dnow_ext);
> +else if ( _3dnow_table[(imm1 >> 4) & 0xf] & (1 << (imm1 & 0xf)) )
> +host_and_vcpu_must_have(3dnow);
> +else
> +generate_exception(EXC_UD);
> +
> +get_fpu(X86EMUL_FPU_mmx, );
> +
> +d = DstReg | SrcMem;
> +op_bytes = 8;
> +state->simd_size = simd_other;
> +goto simd_0f_imm8;
> +
>  #define CASE_SIMD_PACKED_INT(pfx, opc)   \
>  case X86EMUL_OPC(pfx, opc):  \
>  case X86EMUL_OPC_66(pfx, opc)
> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -71,6 +71,8 @@
>   && boot_cpu_has(X86_FEATURE_FFXSR))
>  #define cpu_has_page1gb boot_cpu_has(X86_FEATURE_PAGE1GB)
>  #define cpu_has_rdtscp  boot_cpu_has(X86_FEATURE_RDTSCP)
> +#define cpu_has_3dnow_ext   boot_cpu_has(X86_FEATURE_3DNOWEXT)
> +#define cpu_has_3dnow   boot_cpu_has(X86_FEATURE_3DNOW)
>  
>  /* CPUID level 0x8001.ecx */
>  #define cpu_has_cmp_legacy  boot_cpu_has(X86_FEATURE_CMP_LEGACY)
>
>


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

Re: [Xen-devel] [PATCH v3 09/25] x86emul: support XOP insns

[Andrew Cooper]

On 07/12/17 14:04, Jan Beulich wrote:
> @@ -8027,6 +8060,13 @@ x86_emulate(
>  generate_exception_if(vex.w, EXC_UD);
>  goto simd_0f_imm8_avx;
>  
> +case X86EMUL_OPC_VEX_66(0x0f3a, 0x48): /* vpermil2ps 
> $imm,{x,y}mm/mem,{x,y}mm,{x,y}mm,{x,y}mm */
> +   /* vpermil2ps 
> $imm,{x,y}mm,{x,y}mm/mem,{x,y}mm,{x,y}mm */
> +case X86EMUL_OPC_VEX_66(0x0f3a, 0x49): /* vpermil2pd 
> $imm,{x,y}mm/mem,{x,y}mm,{x,y}mm,{x,y}mm */
> +   /* vpermil2pd 
> $imm,{x,y}mm,{x,y}mm/mem,{x,y}mm,{x,y}mm */
> +host_and_vcpu_must_have(xop);
> +goto simd_0f_imm8_ymm;

Is this correct?  VEX.W selects which operand may be the memory operand,
and I don't see anything in the decode which copes, or anything in the
stub which adjusts .W.

~Andrew

___
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/acpi: add retrieval function for rsdp address

[Rafael J. Wysocki]

On Thu, Feb 1, 2018 at 4:45 PM, Andy Shevchenko
 wrote:
> On Thu, Feb 1, 2018 at 9:57 AM, Rafael J. Wysocki  wrote:
>> On Wed, Jan 31, 2018 at 4:43 PM, Andy Shevchenko
>>  wrote:
>>> On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki  
>>> wrote:
 On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko
  wrote:
>
>>> Instead of declaring function as __weak, establish a new struct for
>>> ACPI related stubs and incorporate it into x86_init.
>>>
>>> That is my proposal. I think I would go this way in my case where I
>>> need to treat differently ACPI HW reduced initialization of legacy
>>> devices.
>>
>> IOW you'd like to have a set of ACPI init callbacks that could be
>> defined by an arch, right?
>
> Correct!

OK

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

Re: [Xen-devel] [PATCH v3 08/25] x86emul: add tables for XOP 08 and 09 extension spaces

[Andrew Cooper]

On 07/12/17 14:04, Jan Beulich wrote:
> Convert the few existing opcodes so far supported.
>
> Also adjust two vex_* case labels to better be ext_* (the values are
> identical).
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -458,6 +458,20 @@ static const opcode_desc_t xop_table[] =
>  DstReg|SrcImm|ModRM,
>  };
>  
> +static const struct {
> +uint8_t simd_size:5;
> +uint8_t two_op:1;
> +uint8_t four_op:1;
> +} ext8f08_table[256] = {
> +};
> +
> +static const struct {
> +uint8_t simd_size:5;
> +uint8_t two_op:1;
> +} ext8f09_table[256] = {
> +[0x01 ... 0x02] = { .two_op = 1 },
> +};
> +

What about 8f0a ?  We've got emulation for bextr already, and might want
to consider #GRP4 seeing as we expose LWP to guests.

>  #define REX_PREFIX 0x40
>  #define REX_B 0x01
>  #define REX_X 0x02
> @@ -2726,7 +2740,7 @@ x86_decode(
>  }
>  break;
>  
> -case vex_0f38:
> +case ext_0f38:
>  d = ext0f38_table[b].to_mem ? DstMem | SrcReg
>  : DstReg | SrcMem;
>  if ( ext0f38_table[b].two_op )
> @@ -2736,7 +2750,14 @@ x86_decode(
>  state->simd_size = ext0f38_table[b].simd_size;
>  break;
>  
> -case vex_0f3a:
> +case ext_8f09:
> +if ( ext8f09_table[b].two_op )
> +d |= TwoOp;
> +state->simd_size = ext8f09_table[b].simd_size;
> +break;
> +
> +case ext_0f3a:
> +case ext_8f08:
>  /*
>   * Cannot update d here yet, as the immediate operand still
>   * needs fetching.
> @@ -2928,6 +2949,15 @@ x86_decode(
>  break;
>  
>  case ext_8f08:
> +d = DstReg | SrcMem;
> +if ( ext8f08_table[b].two_op )
> +d |= TwoOp;
> +else if ( ext8f08_table[b].four_op && !mode_64bit() )
> +imm1 &= 0x7f;
> +state->desc = d;
> +state->simd_size = ext8f08_table[b].simd_size;
> +break;

I presume that these don't actually impact our currently implemented XOP
instructions?

~Andrew

> +
>  case ext_8f09:
>  case ext_8f0a:
>  break;
>
>
>


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

[Xen-devel] [PATCH v2 0/3] xen/arm: SMCCC fixes and PSCI clean-up

[Julien Grall]

Hi all,

This small patch series contains SMCCC fixes (see #2) and PSCI clean-up.

Cheers,

Julien Grall (3):
  xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU
  xen/arm: vsmc: Don't implement function ID that doesn't exist
  xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

 xen/arch/arm/vpsci.c | 155 +--
 xen/arch/arm/vsmc.c  | 126 ---
 xen/include/asm-arm/perfc_defn.h |   2 -
 xen/include/asm-arm/psci.h   |  23 --
 xen/include/asm-arm/smccc.h  |  20 -
 xen/include/asm-arm/vpsci.h  |  13 
 6 files changed, 177 insertions(+), 162 deletions(-)
 create mode 100644 xen/include/asm-arm/vpsci.h

-- 
2.11.0


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

[Xen-devel] [PATCH v2 1/3] xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU

[Julien Grall]

The PSCI call MIGRATE and MIGRATE_INFO_UP_CPU are optional and
implemented as just returning PSCI_NOT_SUPPORTED (aka UNKNOWN_FUNCTION
for SMCCC).

The new SMCCC framework is able to deal with unimplemented function and
return the proper error code. So remove the implementations for both
function.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Remove define in psci.h
- Update SSSC_SMCCC_FUNCTION_COUNT
---
 xen/arch/arm/vpsci.c | 10 --
 xen/arch/arm/vsmc.c  | 16 +---
 xen/include/asm-arm/perfc_defn.h |  2 --
 xen/include/asm-arm/psci.h   |  4 
 4 files changed, 1 insertion(+), 31 deletions(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index cd724904ef..979d32ed6d 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -172,21 +172,11 @@ int32_t do_psci_0_2_affinity_info(register_t 
target_affinity,
 return PSCI_0_2_AFFINITY_LEVEL_OFF;
 }
 
-int32_t do_psci_0_2_migrate(uint32_t target_cpu)
-{
-return PSCI_NOT_SUPPORTED;
-}
-
 uint32_t do_psci_0_2_migrate_info_type(void)
 {
 return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
 }
 
-register_t do_psci_0_2_migrate_info_up_cpu(void)
-{
-return PSCI_NOT_SUPPORTED;
-}
-
 void do_psci_0_2_system_off( void )
 {
 struct domain *d = current->domain;
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index c9064de37a..997f2e0ebc 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -28,7 +28,7 @@
 #define XEN_SMCCC_FUNCTION_COUNT 3
 
 /* Number of functions currently supported by Standard Service Service Calls. 
*/
-#define SSSC_SMCCC_FUNCTION_COUNT 13
+#define SSSC_SMCCC_FUNCTION_COUNT 11
 
 static bool fill_uid(struct cpu_user_regs *regs, xen_uuid_t uuid)
 {
@@ -157,11 +157,6 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
 return true;
 
-case PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
-perfc_incr(vpsci_migrate_info_up_cpu);
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
-return true;
-
 case PSCI_0_2_FN_SYSTEM_OFF:
 perfc_incr(vpsci_system_off);
 do_psci_0_2_system_off();
@@ -206,15 +201,6 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 return true;
 }
 
-case PSCI_0_2_FN_MIGRATE:
-{
-uint32_t tcpu = PSCI_ARG32(regs, 1);
-
-perfc_incr(vpsci_cpu_migrate);
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate(tcpu));
-return true;
-}
-
 case ARM_SMCCC_FUNC_CALL_COUNT:
 return fill_function_call_count(regs, SSSC_SMCCC_FUNCTION_COUNT);
 
diff --git a/xen/include/asm-arm/perfc_defn.h b/xen/include/asm-arm/perfc_defn.h
index 5f957ee6ec..a7acb7d21c 100644
--- a/xen/include/asm-arm/perfc_defn.h
+++ b/xen/include/asm-arm/perfc_defn.h
@@ -27,12 +27,10 @@ PERFCOUNTER(vpsci_cpu_on,  "vpsci: cpu_on")
 PERFCOUNTER(vpsci_cpu_off, "vpsci: cpu_off")
 PERFCOUNTER(vpsci_version, "vpsci: version")
 PERFCOUNTER(vpsci_migrate_info_type,   "vpsci: migrate_info_type")
-PERFCOUNTER(vpsci_migrate_info_up_cpu, "vpsci: migrate_info_up_cpu")
 PERFCOUNTER(vpsci_system_off,  "vpsci: system_off")
 PERFCOUNTER(vpsci_system_reset,"vpsci: system_reset")
 PERFCOUNTER(vpsci_cpu_suspend, "vpsci: cpu_suspend")
 PERFCOUNTER(vpsci_cpu_affinity_info,   "vpsci: cpu_affinity_info")
-PERFCOUNTER(vpsci_cpu_migrate, "vpsci: cpu_migrate")
 
 PERFCOUNTER(vgicd_reads,"vgicd: read")
 PERFCOUNTER(vgicd_writes,   "vgicd: write")
diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
index 635ea5dae4..32c1f81f21 100644
--- a/xen/include/asm-arm/psci.h
+++ b/xen/include/asm-arm/psci.h
@@ -37,9 +37,7 @@ int32_t do_psci_0_2_cpu_on(register_t target_cpu, register_t 
entry_point,
register_t context_id);
 int32_t do_psci_0_2_affinity_info(register_t target_affinity,
   uint32_t lowest_affinity_level);
-int32_t do_psci_0_2_migrate(uint32_t target_cpu);
 uint32_t do_psci_0_2_migrate_info_type(void);
-register_t do_psci_0_2_migrate_info_up_cpu(void);
 void do_psci_0_2_system_off(void);
 void do_psci_0_2_system_reset(void);
 
@@ -57,9 +55,7 @@ void do_psci_0_2_system_reset(void);
 #define PSCI_0_2_FN_CPU_OFF 2
 #define PSCI_0_2_FN_CPU_ON  3
 #define PSCI_0_2_FN_AFFINITY_INFO   4
-#define PSCI_0_2_FN_MIGRATE 5
 #define PSCI_0_2_FN_MIGRATE_INFO_TYPE   6
-#define PSCI_0_2_FN_MIGRATE_INFO_UP_CPU 7
 #define PSCI_0_2_FN_SYSTEM_OFF  8
 #define PSCI_0_2_FN_SYSTEM_RESET9
 
-- 
2.11.0


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

[Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Julien Grall]

At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).

This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI functions.

Therefore move PSCI dispatching in two new functions do_vpsci_0_1_call
and do_vpsci_0_2_call. The former will handle PSCI 0.1 call while the latter
0.2 or later call.

At the same time, a new header vpsci.h was created to contain all
definitions for virtual PSCI and avoid confusion with the host PSCI.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Add a 'v' in the function names to help distinguish virtual vs
physical PSCI
- Introduce vpsci.h and VSCPI_NR_FUNCS
---
 xen/arch/arm/vpsci.c| 147 +++-
 xen/arch/arm/vsmc.c |  99 ++---
 xen/include/asm-arm/psci.h  |  19 --
 xen/include/asm-arm/vpsci.h |  13 
 4 files changed, 152 insertions(+), 126 deletions(-)
 create mode 100644 xen/include/asm-arm/vpsci.h

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 979d32ed6d..884f0fa710 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -16,7 +16,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
@@ -91,12 +91,12 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 return PSCI_SUCCESS;
 }
 
-int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
+static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
 {
 return do_common_cpu_on(vcpuid, entry_point, 0 , PSCI_VERSION(0, 1));
 }
 
-int32_t do_psci_cpu_off(uint32_t power_state)
+static int32_t do_psci_cpu_off(uint32_t power_state)
 {
 struct vcpu *v = current;
 if ( !test_and_set_bit(_VPF_down, >pause_flags) )
@@ -104,13 +104,14 @@ int32_t do_psci_cpu_off(uint32_t power_state)
 return PSCI_SUCCESS;
 }
 
-uint32_t do_psci_0_2_version(void)
+static uint32_t do_psci_0_2_version(void)
 {
 return PSCI_VERSION(0, 2);
 }
 
-register_t do_psci_0_2_cpu_suspend(uint32_t power_state, register_t 
entry_point,
-register_t context_id)
+static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
+  register_t entry_point,
+  register_t context_id)
 {
 struct vcpu *v = current;
 
@@ -123,13 +124,14 @@ register_t do_psci_0_2_cpu_suspend(uint32_t power_state, 
register_t entry_point,
 return PSCI_SUCCESS;
 }
 
-int32_t do_psci_0_2_cpu_off(void)
+static int32_t do_psci_0_2_cpu_off(void)
 {
 return do_psci_cpu_off(0);
 }
 
-int32_t do_psci_0_2_cpu_on(register_t target_cpu, register_t entry_point,
-   register_t context_id)
+static int32_t do_psci_0_2_cpu_on(register_t target_cpu,
+  register_t entry_point,
+  register_t context_id)
 {
 return do_common_cpu_on(target_cpu, entry_point, context_id,
 PSCI_VERSION(0, 2));
@@ -144,8 +146,8 @@ static const unsigned long target_affinity_mask[] = {
 #endif
 };
 
-int32_t do_psci_0_2_affinity_info(register_t target_affinity,
-  uint32_t lowest_affinity_level)
+static int32_t do_psci_0_2_affinity_info(register_t target_affinity,
+ uint32_t lowest_affinity_level)
 {
 struct domain *d = current->domain;
 struct vcpu *v;
@@ -172,23 +174,140 @@ int32_t do_psci_0_2_affinity_info(register_t 
target_affinity,
 return PSCI_0_2_AFFINITY_LEVEL_OFF;
 }
 
-uint32_t do_psci_0_2_migrate_info_type(void)
+static uint32_t do_psci_0_2_migrate_info_type(void)
 {
 return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
 }
 
-void do_psci_0_2_system_off( void )
+static void do_psci_0_2_system_off( void )
 {
 struct domain *d = current->domain;
 domain_shutdown(d,SHUTDOWN_poweroff);
 }
 
-void do_psci_0_2_system_reset(void)
+static void do_psci_0_2_system_reset(void)
 {
 struct domain *d = current->domain;
 domain_shutdown(d,SHUTDOWN_reboot);
 }
 
+#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
+#define PSCI_ARG(reg, n) get_user_reg(reg, n)
+
+#ifdef CONFIG_ARM_64
+#define PSCI_ARG32(reg, n) (uint32_t)(get_user_reg(reg, n))
+#else
+#define PSCI_ARG32(reg, n) PSCI_ARG(reg, n)
+#endif
+
+/*
+ * PSCI 0.1 calls. It will return false if the function ID is not
+ * handled.
+ */
+bool do_vpsci_0_1_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+switch ( (uint32_t)get_user_reg(regs, 0) )
+{
+case PSCI_cpu_off:
+{
+uint32_t pstate = PSCI_ARG32(regs, 1);
+
+perfc_incr(vpsci_cpu_off);
+PSCI_SET_RESULT(regs, do_psci_cpu_off(pstate));
+return true;
+}
+case PSCI_cpu_on:
+{
+uint32_t vcpuid = PSCI_ARG32(regs, 1);
+  

[Xen-devel] [PATCH v2 2/3] xen/arm: vsmc: Don't implement function ID that doesn't exist

[Julien Grall]

The current implementation of SMCCC relies on the fact only function
number (bits [15:0]) is enough to identify what to implement.

However, PSCI call are only available in the range 0x8400-0x841F
and 0xC400-0xC41F. Furthermore, not all SMC32 functions have
equivalent in the SMC64. This is the case of:
* PSCI_VERSION
* CPU_OFF
* MIGRATE_INFO_TYPE
* SYSTEM_OFF
* SYSTEM_RESET

Similarly call count, call uid, revision can only be query using smc32/hvc32
fast calls (See 6.2 in ARM DEN 0028B).

Xen should only implement identifier existing in the specification in
order to avoid potential clash with later revision. Therefore rework the
vsmc code to use the whole function identifier rather than only the
function number.

At the same time, the new macros for call count, call uid, revision are
renamed to better suit the spec.

Lastly, update SSSC_SMCCC_FUNCTION_COUNT to match the correct number of
funtions. Note that version is not updated because the number has always
been wrong, and nobody could properly use it.

Signed-off-by: Julien Grall 

---
This should be backported to Xen 4.10 as we should not implement
functions identifier that does not exist toprevent clash with a
later revision.

Changes in v2:
- Rename the call count, call uid, revision macros
- Update SSSC_SMCCC_FUNCTION_COUNT
---
 xen/arch/arm/vsmc.c | 39 ++-
 xen/include/asm-arm/smccc.h | 20 +---
 2 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 997f2e0ebc..3d8cbcc808 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -28,7 +28,7 @@
 #define XEN_SMCCC_FUNCTION_COUNT 3
 
 /* Number of functions currently supported by Standard Service Service Calls. 
*/
-#define SSSC_SMCCC_FUNCTION_COUNT 11
+#define SSSC_SMCCC_FUNCTION_COUNT 14
 
 static bool fill_uid(struct cpu_user_regs *regs, xen_uuid_t uuid)
 {
@@ -84,13 +84,15 @@ static bool fill_function_call_count(struct cpu_user_regs 
*regs, uint32_t cnt)
 /* SMCCC interface for hypervisor. Tell about itself. */
 static bool handle_hypervisor(struct cpu_user_regs *regs)
 {
-switch ( smccc_get_fn(get_user_reg(regs, 0)) )
+uint32_t fid = (uint32_t)get_user_reg(regs, 0);
+
+switch ( fid )
 {
-case ARM_SMCCC_FUNC_CALL_COUNT:
+case ARM_SMCCC_CALL_COUNT_FID(HYPERVISOR):
 return fill_function_call_count(regs, XEN_SMCCC_FUNCTION_COUNT);
-case ARM_SMCCC_FUNC_CALL_UID:
+case ARM_SMCCC_CALL_UID_FID(HYPERVISOR):
 return fill_uid(regs, XEN_SMCCC_UID);
-case ARM_SMCCC_FUNC_CALL_REVISION:
+case ARM_SMCCC_REVISION_FID(HYPERVISOR):
 return fill_revision(regs, XEN_SMCCC_MAJOR_REVISION,
  XEN_SMCCC_MINOR_REVISION);
 default:
@@ -140,36 +142,37 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 {
 uint32_t fid = (uint32_t)get_user_reg(regs, 0);
 
-switch ( smccc_get_fn(fid) )
+switch ( fid )
 {
-case PSCI_0_2_FN_PSCI_VERSION:
+case PSCI_0_2_FN32(PSCI_VERSION):
 perfc_incr(vpsci_version);
 PSCI_SET_RESULT(regs, do_psci_0_2_version());
 return true;
 
-case PSCI_0_2_FN_CPU_OFF:
+case PSCI_0_2_FN32(CPU_OFF):
 perfc_incr(vpsci_cpu_off);
 PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
 return true;
 
-case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
+case PSCI_0_2_FN32(MIGRATE_INFO_TYPE):
 perfc_incr(vpsci_migrate_info_type);
 PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
 return true;
 
-case PSCI_0_2_FN_SYSTEM_OFF:
+case PSCI_0_2_FN32(SYSTEM_OFF):
 perfc_incr(vpsci_system_off);
 do_psci_0_2_system_off();
 PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 return true;
 
-case PSCI_0_2_FN_SYSTEM_RESET:
+case PSCI_0_2_FN32(SYSTEM_RESET):
 perfc_incr(vpsci_system_reset);
 do_psci_0_2_system_reset();
 PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 return true;
 
-case PSCI_0_2_FN_CPU_ON:
+case PSCI_0_2_FN32(CPU_ON):
+case PSCI_0_2_FN64(CPU_ON):
 {
 register_t vcpuid = PSCI_ARG(regs, 1);
 register_t epoint = PSCI_ARG(regs, 2);
@@ -180,7 +183,8 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 return true;
 }
 
-case PSCI_0_2_FN_CPU_SUSPEND:
+case PSCI_0_2_FN32(CPU_SUSPEND):
+case PSCI_0_2_FN64(CPU_SUSPEND):
 {
 uint32_t pstate = PSCI_ARG32(regs, 1);
 register_t epoint = PSCI_ARG(regs, 2);
@@ -191,7 +195,8 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 return true;
 }
 
-case PSCI_0_2_FN_AFFINITY_INFO:
+case PSCI_0_2_FN32(AFFINITY_INFO):
+case PSCI_0_2_FN64(AFFINITY_INFO):
 {
 register_t taff = PSCI_ARG(regs, 1);
 uint32_t laff = PSCI_ARG32(regs, 2);
@@ -201,13 +206,13 @@ static bool handle_sssc(struct 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start   fail REGR. vs. 118324

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118324
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118324
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118324
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118324
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-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-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-amd64-amd64-libvirt 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-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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 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-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail 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-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxb2fe5fa68642860e7de76167c3111623aa0d5de1
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z8 days
Failing since118362  2018-01-26 16:56:17 Z6 days6 attempts
Testing same since   118501  2018-01-31 23:33:17 Z1 days1 attempts


1194 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  

[Xen-devel] [PATCH v3 4/4] xen/arm: Don't crash the domain on invalid HVC immediate

[Julien Grall]

domain_crash_synchronous() should only be used when something went wrong
in Xen. It is better to inject to the guest as it will be in a better
position to provide helpful information (stack trace...).

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

---

We potentially want to return -1 instead. This would make Xen more
future-proof if we decide to implement the other HVC immediate.

Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/traps.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1e85f99ec1..1cba7e584d 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1471,14 +1471,17 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
 #endif
 
 static void do_trap_hypercall(struct cpu_user_regs *regs, register_t *nr,
-  unsigned long iss)
+  const union hsr hsr)
 {
 arm_hypercall_fn_t call = NULL;
 
 BUILD_BUG_ON(NR_hypercalls < ARRAY_SIZE(arm_hypercall_table) );
 
-if ( iss != XEN_HYPERCALL_TAG )
-domain_crash_synchronous();
+if ( hsr.iss != XEN_HYPERCALL_TAG )
+{
+gprintk(XENLOG_WARNING, "Invalid HVC imm 0x%x\n", hsr.iss);
+return inject_undef_exception(regs, hsr);
+}
 
 if ( *nr >= ARRAY_SIZE(arm_hypercall_table) )
 {
@@ -2109,7 +2112,7 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
 if ( hsr.iss == 0 )
 return do_trap_hvc_smccc(regs);
 nr = regs->r12;
-do_trap_hypercall(regs, , hsr.iss);
+do_trap_hypercall(regs, , hsr);
 regs->r12 = (uint32_t)nr;
 break;
 }
@@ -2123,7 +2126,7 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
 #endif
 if ( hsr.iss == 0 )
 return do_trap_hvc_smccc(regs);
-do_trap_hypercall(regs, >x16, hsr.iss);
+do_trap_hypercall(regs, >x16, hsr);
 break;
 case HSR_EC_SMC64:
 /*
-- 
2.11.0


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

[Xen-devel] [PATCH v3 2/4] xen/arm: io: Distinguish unhandled IO from aborted one

[Julien Grall]

Currently, Xen is considering that an IO could either be handled or
unhandled. When unhandled, the stage-2 abort function will try another
way to resolve the abort.

However, the MMIO emulation may return unhandled when the address
belongs to an emulated range but was not correct. In that case, Xen
should avoid to try another way and directly inject a guest data abort.

Introduce a tri-state return to distinguish the following state:
* IO_ABORT: The IO was handled but resulted in an abort
* IO_HANDLED: The IO was handled
* IO_UNHANDLED: The IO was unhandled

For now, it is considered that an IO belonging to an emulated range
could either be handled or inject an abort. This could be revisit in the
future if overlapped region exist (or we want to try another way to
resolve the abort).

Signed-off-by: Julien Grall 

---
Changes in v2:
- Always return IO_ABORT when the check failed because we know
it was targeted emulated IO.
- Fix typoes
---
 xen/arch/arm/io.c  | 32 ++--
 xen/arch/arm/traps.c   | 18 +++---
 xen/include/asm-arm/mmio.h | 13 ++---
 3 files changed, 43 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index c3e9239ffe..1f4cb8f37d 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -26,8 +26,9 @@
 
 #include "decode.h"
 
-static int handle_read(const struct mmio_handler *handler, struct vcpu *v,
-   mmio_info_t *info)
+static enum io_state handle_read(const struct mmio_handler *handler,
+ struct vcpu *v,
+ mmio_info_t *info)
 {
 const struct hsr_dabt dabt = info->dabt;
 struct cpu_user_regs *regs = guest_cpu_user_regs();
@@ -40,7 +41,7 @@ static int handle_read(const struct mmio_handler *handler, 
struct vcpu *v,
 uint8_t size = (1 << dabt.size) * 8;
 
 if ( !handler->ops->read(v, info, , handler->priv) )
-return 0;
+return IO_ABORT;
 
 /*
  * Sign extend if required.
@@ -60,17 +61,20 @@ static int handle_read(const struct mmio_handler *handler, 
struct vcpu *v,
 
 set_user_reg(regs, dabt.reg, r);
 
-return 1;
+return IO_HANDLED;
 }
 
-static int handle_write(const struct mmio_handler *handler, struct vcpu *v,
-mmio_info_t *info)
+static enum io_state handle_write(const struct mmio_handler *handler,
+  struct vcpu *v,
+  mmio_info_t *info)
 {
 const struct hsr_dabt dabt = info->dabt;
 struct cpu_user_regs *regs = guest_cpu_user_regs();
+int ret;
 
-return handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
-   handler->priv);
+ret = handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
+  handler->priv);
+return ( ret ) ? IO_HANDLED : IO_ABORT;
 }
 
 /* This function assumes that mmio regions are not overlapped */
@@ -103,9 +107,9 @@ static const struct mmio_handler *find_mmio_handler(struct 
domain *d,
 return handler;
 }
 
-int try_handle_mmio(struct cpu_user_regs *regs,
-const union hsr hsr,
-paddr_t gpa)
+enum io_state try_handle_mmio(struct cpu_user_regs *regs,
+  const union hsr hsr,
+  paddr_t gpa)
 {
 struct vcpu *v = current;
 const struct mmio_handler *handler = NULL;
@@ -119,11 +123,11 @@ int try_handle_mmio(struct cpu_user_regs *regs,
 
 handler = find_mmio_handler(v->domain, info.gpa);
 if ( !handler )
-return 0;
+return IO_UNHANDLED;
 
 /* All the instructions used on emulated MMIO region should be valid */
 if ( !dabt.valid )
-return 0;
+return IO_ABORT;
 
 /*
  * Erratum 766422: Thumb store translation fault to Hypervisor may
@@ -138,7 +142,7 @@ int try_handle_mmio(struct cpu_user_regs *regs,
 if ( rc )
 {
 gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
-return 0;
+return IO_ABORT;
 }
 }
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 2f8d790bb3..1e85f99ec1 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1964,10 +1964,21 @@ static void do_trap_stage2_abort_guest(struct 
cpu_user_regs *regs,
  *
  * Note that emulated region cannot be executed
  */
-if ( is_data && try_handle_mmio(regs, hsr, gpa) )
+if ( is_data )
 {
-advance_pc(regs, hsr);
-return;
+enum io_state state = try_handle_mmio(regs, hsr, gpa);
+
+switch ( state )
+{
+case IO_ABORT:
+goto inject_abt;
+case IO_HANDLED:
+advance_pc(regs, hsr);
+return;
+case IO_UNHANDLED:
+/* IO 

[Xen-devel] [PATCH v3 0/4] xen/arm: Inject an exception to the guest rather than crashing it

[Julien Grall]

Hi all,

This small series replaces all call to domain_crash_synchronous by injecting
an exception to the guest.

This will result to a nicer trace from the guest (no need to manually walk
the stack) and give a chance to the guest to give a bit more information on
what it was doing.

Cheers,

Julien Grall (4):
  xen/arm: traps: Merge try_handle_mmio() and handle_mmio()
  xen/arm: io: Distinguish unhandled IO from aborted one
  xen/arm: Don't crash domain on bad MMIO emulation
  xen/arm: Don't crash the domain on invalid HVC immediate

 xen/arch/arm/io.c  | 65 -
 xen/arch/arm/traps.c   | 72 +++---
 xen/arch/arm/vgic-v2.c |  2 --
 xen/arch/arm/vgic-v3-its.c |  3 --
 xen/arch/arm/vgic-v3.c |  8 --
 xen/arch/arm/vpl011.c  |  2 --
 xen/include/asm-arm/mmio.h | 11 ++-
 7 files changed, 84 insertions(+), 79 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH v3 1/4] xen/arm: traps: Merge try_handle_mmio() and handle_mmio()

[Julien Grall]

At the moment, try_handle_mmio() will do check on the HSR and bail out
if one check fail. This means that another method will be tried to
handle the fault even for bad access on emulated region. While this
should not be an issue, this is not future proof.

Move the checks of try_handle_mmio() in handle_mmio() after we identified
the fault to target an emulated MMIO. While this does not fix the potential
fall-through, a follow-up patch will do by distinguish the potential error.

Note that the handle_mmio() was renamed to try_handle_mmio() and the
prototype adapted.

While merging the 2 functions, remove the check whether the fault is
stage-2 abort on stage-1 translation walk because the instruction
syndrome will always be invalid (see B3-1433 in DDI 0406C.c and
D10-2460 in DDI 0487C.a).

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch added
---
 xen/arch/arm/io.c  | 43 ++-
 xen/arch/arm/traps.c   | 41 -
 xen/include/asm-arm/mmio.h |  4 +++-
 3 files changed, 41 insertions(+), 47 deletions(-)

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index c748d8f5bf..c3e9239ffe 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -20,9 +20,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+#include "decode.h"
+
 static int handle_read(const struct mmio_handler *handler, struct vcpu *v,
mmio_info_t *info)
 {
@@ -100,19 +103,49 @@ static const struct mmio_handler 
*find_mmio_handler(struct domain *d,
 return handler;
 }
 
-int handle_mmio(mmio_info_t *info)
+int try_handle_mmio(struct cpu_user_regs *regs,
+const union hsr hsr,
+paddr_t gpa)
 {
 struct vcpu *v = current;
 const struct mmio_handler *handler = NULL;
+const struct hsr_dabt dabt = hsr.dabt;
+mmio_info_t info = {
+.gpa = gpa,
+.dabt = dabt
+};
+
+ASSERT(hsr.ec == HSR_EC_DATA_ABORT_LOWER_EL);
 
-handler = find_mmio_handler(v->domain, info->gpa);
+handler = find_mmio_handler(v->domain, info.gpa);
 if ( !handler )
 return 0;
 
-if ( info->dabt.write )
-return handle_write(handler, v, info);
+/* All the instructions used on emulated MMIO region should be valid */
+if ( !dabt.valid )
+return 0;
+
+/*
+ * Erratum 766422: Thumb store translation fault to Hypervisor may
+ * not have correct HSR Rt value.
+ */
+if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
+ dabt.write )
+{
+int rc;
+
+rc = decode_instruction(regs, );
+if ( rc )
+{
+gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
+return 0;
+}
+}
+
+if ( info.dabt.write )
+return handle_write(handler, v, );
 else
-return handle_read(handler, v, info);
+return handle_read(handler, v, );
 }
 
 void register_mmio_handler(struct domain *d,
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c8534d6cff..2f8d790bb3 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -51,8 +51,6 @@
 #include 
 #include 
 
-#include "decode.h"
-
 /* The base of the stack must always be double-word aligned, which means
  * that both the kernel half of struct cpu_user_regs (which is pushed in
  * entry.S) and struct cpu_info (which lives at the bottom of a Xen
@@ -1864,45 +1862,6 @@ static inline bool hpfar_is_valid(bool s1ptw, uint8_t 
fsc)
 return s1ptw || (fsc == FSC_FLT_TRANS && !check_workaround_834220());
 }
 
-static bool try_handle_mmio(struct cpu_user_regs *regs,
-const union hsr hsr,
-paddr_t gpa)
-{
-const struct hsr_dabt dabt = hsr.dabt;
-mmio_info_t info = {
-.gpa = gpa,
-.dabt = dabt
-};
-int rc;
-
-ASSERT(hsr.ec == HSR_EC_DATA_ABORT_LOWER_EL);
-
-/* stage-1 page table should never live in an emulated MMIO region */
-if ( dabt.s1ptw )
-return false;
-
-/* All the instructions used on emulated MMIO region should be valid */
-if ( !dabt.valid )
-return false;
-
-/*
- * Erratum 766422: Thumb store translation fault to Hypervisor may
- * not have correct HSR Rt value.
- */
-if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
- dabt.write )
-{
-rc = decode_instruction(regs, );
-if ( rc )
-{
-gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
-return false;
-}
-}
-
-return !!handle_mmio();
-}
-
 /*
  * When using ACPI, most of the MMIO regions will be mapped on-demand
  * in stage-2 page tables for the hardware domain because Xen is not
diff --git a/xen/include/asm-arm/mmio.h b/xen/include/asm-arm/mmio.h
index 37e2b7a707..c941073257 100644
--- a/xen/include/asm-arm/mmio.h
+++ b/xen/include/asm-arm/mmio.h

[Xen-devel] [PATCH v3 3/4] xen/arm: Don't crash domain on bad MMIO emulation

[Julien Grall]

Now the MMIO emulation is able to distinguish unhandled IO from aborted
one, there are no need to crash the domain when the region is access
with a bad width.

Instead let Xen inject a data abort to the guest and decide what to do.

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

---
Changes in v2
- Add Stefano's reviewed-by
---
 xen/arch/arm/vgic-v2.c | 2 --
 xen/arch/arm/vgic-v3-its.c | 3 ---
 xen/arch/arm/vgic-v3.c | 8 
 xen/arch/arm/vpl011.c  | 2 --
 4 files changed, 15 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 2bdb25261a..646d1f3d12 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -348,7 +348,6 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 bad_width:
 printk(XENLOG_G_ERR "%pv: vGICD: bad read width %d r%d offset %#08x\n",
v, dabt.size, dabt.reg, gicd_reg);
-domain_crash_synchronous();
 return 0;
 
 read_as_zero_32:
@@ -613,7 +612,6 @@ bad_width:
 printk(XENLOG_G_ERR
"%pv: vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
v, dabt.size, dabt.reg, r, gicd_reg);
-domain_crash_synchronous();
 return 0;
 
 write_ignore_32:
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index d8fa44258d..32061c6b03 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -1136,7 +1136,6 @@ read_reserved:
 bad_width:
 printk(XENLOG_G_ERR "vGITS: bad read width %d r%d offset %#04lx\n",
info->dabt.size, info->dabt.reg, (unsigned long)info->gpa & 0x);
-domain_crash_synchronous();
 
 return 0;
 }
@@ -1446,8 +1445,6 @@ bad_width:
 printk(XENLOG_G_ERR "vGITS: bad write width %d r%d offset %#08lx\n",
info->dabt.size, info->dabt.reg, (unsigned long)info->gpa & 0x);
 
-domain_crash_synchronous();
-
 return 0;
 }
 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index af16dfd005..2ad8a6be62 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -328,7 +328,6 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 bad_width:
 printk(XENLOG_G_ERR "%pv vGICR: bad read width %d r%d offset %#08x\n",
v, dabt.size, dabt.reg, gicr_reg);
-domain_crash_synchronous();
 return 0;
 
 read_as_zero_64:
@@ -648,7 +647,6 @@ bad_width:
 printk(XENLOG_G_ERR
   "%pv: vGICR: bad write width %d r%d=%"PRIregister" offset %#08x\n",
   v, dabt.size, dabt.reg, r, gicr_reg);
-domain_crash_synchronous();
 return 0;
 
 write_ignore_64:
@@ -760,7 +758,6 @@ static int __vgic_v3_distr_common_mmio_read(const char 
*name, struct vcpu *v,
 bad_width:
 printk(XENLOG_G_ERR "%pv: %s: bad read width %d r%d offset %#08x\n",
v, name, dabt.size, dabt.reg, reg);
-domain_crash_synchronous();
 return 0;
 
 read_as_zero:
@@ -876,7 +873,6 @@ bad_width:
 printk(XENLOG_G_ERR
"%pv: %s: bad write width %d r%d=%"PRIregister" offset %#08x\n",
v, name, dabt.size, dabt.reg, r, reg);
-domain_crash_synchronous();
 return 0;
 
 write_ignore_32:
@@ -937,7 +933,6 @@ static int vgic_v3_rdistr_sgi_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 bad_width:
 printk(XENLOG_G_ERR "%pv: vGICR: SGI: bad read width %d r%d offset 
%#08x\n",
v, dabt.size, dabt.reg, gicr_reg);
-domain_crash_synchronous();
 return 0;
 
 read_as_zero_32:
@@ -1017,7 +1012,6 @@ bad_width:
 printk(XENLOG_G_ERR
"%pv: vGICR: SGI: bad write width %d r%d=%"PRIregister" offset 
%#08x\n",
v, dabt.size, dabt.reg, r, gicr_reg);
-domain_crash_synchronous();
 return 0;
 
 write_ignore_32:
@@ -1268,7 +1262,6 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 bad_width:
 printk(XENLOG_G_ERR "%pv: vGICD: bad read width %d r%d offset %#08x\n",
v, dabt.size, dabt.reg, gicd_reg);
-domain_crash_synchronous();
 return 0;
 
 read_as_zero_32:
@@ -1456,7 +1449,6 @@ bad_width:
 printk(XENLOG_G_ERR
"%pv: vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
v, dabt.size, dabt.reg, r, gicd_reg);
-domain_crash_synchronous();
 return 0;
 
 write_ignore_32:
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 725b2e03ad..7788c2fc32 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -296,7 +296,6 @@ static int vpl011_mmio_read(struct vcpu *v,
 bad_width:
 gprintk(XENLOG_ERR, "vpl011: bad read width %d r%d offset %#08x\n",
 dabt.size, dabt.reg, vpl011_reg);
-domain_crash_synchronous();
 return 0;
 
 }
@@ -366,7 +365,6 @@ write_ignore:
 bad_width:
 gprintk(XENLOG_ERR, "vpl011: bad write width %d r%d offset %#08x\n",
 dabt.size, dabt.reg, vpl011_reg);
-domain_crash_synchronous();
 return 0;
 
 }
-- 
2.11.0

Re: [Xen-devel] [PATCHv2] xen-netfront: remove warning when unloading module

[Oleksandr Andrushchenko]

On 02/02/2018 10:54 AM, Eduardo Otubo wrote:

On Wed, Jan 31, 2018 at 05:00:23PM +0200, Oleksandr Andrushchenko wrote:

Hi, Eduardo!

I am working on a frontend driver (PV DRM) and also seeing some strange

things on driver unloading:

xt# rmmod -f drm_xen_front.ko
[ 3236.462497] [drm] Unregistering XEN PV vdispl
[ 3236.485745] [drm:xen_drv_remove [drm_xen_front]] *ERROR* Backend state is
InitWait while removing driver
[ 3236.486950] vdispl vdispl-0: 22 freeing event channel 11
[ 3236.496123] vdispl vdispl-0: failed to write error node for
device/vdispl/0 (22 freeing event channel 11)
[ 3236.496271] vdispl vdispl-0: 22 freeing event channel 12
[ 3236.501633] vdispl vdispl-0: failed to write error node for
device/vdispl/0 (22 freeing event channel 12)

These are somewhat different from your use-case with grant references, but I
have a question:

do you really see that XenbusStateClosed and XenbusStateClosing are

called? In my driver I can't see those and once I tried to dig deeper into
the problem

I saw that on driver removal it is disconnected from XenBus, so no backend
state

change events come in via .otherend_changed callback.

The only difference I see here is that the backend is a user-space
application

Thank you,
Oleksandr

To be honest, most of the things I assumed were true, according to some talks on
IRC with maintainers. Since I assumed it was true I started to write code based
on that and all the behaviors that followed were correct according to my
assumptions (and discussions).

But if you find something else weird, please let me know and we can fix it.

There is nothing wrong with the patch. One thing that
I cannot get in my driver is that .otherend_changed callback
is not called on .remove. Please see [1]

On 11/23/2017 04:18 PM, Eduardo Otubo wrote:

v2:
   * Replace busy wait with wait_event()/wake_up_all()
   * Cannot garantee that at the time xennet_remove is called, the
 xen_netback state will not be XenbusStateClosed, so added a
 condition for that
   * There's a small chance for the xen_netback state is
 XenbusStateUnknown by the time the xen_netfront switches to Closed,
 so added a condition for that.

When unloading module xen_netfront from guest, dmesg would output
warning messages like below:

[  105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use!
[  105.236839] deferring g.e. 0x903 (pfn 0x35805)

This problem relies on netfront and netback being out of sync. By the time
netfront revokes the g.e.'s netback didn't have enough time to free all of
them, hence displaying the warnings on dmesg.

The trick here is to make netfront to wait until netback frees all the g.e.'s
and only then continue to cleanup for the module removal, and this is done by
manipulating both device states.

Signed-off-by: Eduardo Otubo 
---
   drivers/net/xen-netfront.c | 18 ++
   1 file changed, 18 insertions(+)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 8b8689c6d887..391432e2725d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -87,6 +87,8 @@ struct netfront_cb {
   /* IRQ name is queue name with "-tx" or "-rx" appended */
   #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3)
+static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);
+
   struct netfront_stats {
u64 packets;
u64 bytes;
@@ -2021,10 +2023,12 @@ static void netback_changed(struct xenbus_device *dev,
break;
case XenbusStateClosed:
+   wake_up_all(_unload_q);
if (dev->state == XenbusStateClosed)
break;
/* Missed the backend's CLOSING state -- fallthrough */
case XenbusStateClosing:
+   wake_up_all(_unload_q);
xenbus_frontend_closed(dev);
break;
}
@@ -2130,6 +2134,20 @@ static int xennet_remove(struct xenbus_device *dev)
dev_dbg(>dev, "%s\n", dev->nodename);
+   if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) {
+   xenbus_switch_state(dev, XenbusStateClosing);
+   wait_event(module_unload_q,
+  xenbus_read_driver_state(dev->otherend) ==
+  XenbusStateClosing);
+
+   xenbus_switch_state(dev, XenbusStateClosed);
+   wait_event(module_unload_q,
+  xenbus_read_driver_state(dev->otherend) ==
+  XenbusStateClosed ||
+  xenbus_read_driver_state(dev->otherend) ==
+  XenbusStateUnknown);
+   }
+
xennet_disconnect_backend(info);
unregister_netdev(info->netdev);

[1] https://patchwork.kernel.org/patch/10195163/

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

Re: [Xen-devel] [PATCH v3 07/25] x86emul: support AVX2 gather insns

[Jan Beulich]

>>> On 01.02.18 at 21:53,  wrote:
> On 07/12/17 14:03, Jan Beulich wrote:
>> @@ -2805,13 +2808,17 @@ x86_decode(
>>  ea.type = OP_MEM;
>>  if ( modrm_rm == 4 )
>>  {
>> -sib = insn_fetch_type(uint8_t);
>> -sib_index = ((sib >> 3) & 7) | ((rex_prefix << 2) & 8);
>> -sib_base  = (sib & 7) | ((rex_prefix << 3) & 8);
>> -if ( sib_index != 4 && !(d & vSIB) )
>> -ea.mem.off = *decode_register(sib_index, state->regs,
>> -  false);
>> -ea.mem.off <<= (sib >> 6) & 3;
>> +uint8_t sib = insn_fetch_type(uint8_t);
>> +uint8_t sib_base = (sib & 7) | ((rex_prefix << 3) & 8);
>> +
>> +state->sib_index = ((sib >> 3) & 7) | ((rex_prefix << 2) & 
>> 8);
>> +state->sib_scale = (sib >> 6) & 3;
>> +if ( state->sib_index != 4 && !(d & vSIB) )
>> +{
>> +ea.mem.off = *decode_register(state->sib_index,
>> +  state->regs, false);
>> +ea.mem.off <<= state->sib_scale;
> 
> This is a functional change.

In what way? The code is just being re-organized, so that the two
pieces of information needed later go into the new state fields. Are
you perhaps referring to the shift previously having happened
outside the if()? With the condition being false, that was simply a
shifting zero left (or else it would have been wrong to sit outside
the if()).

>> @@ -7472,6 +7479,110 @@ x86_emulate(
>>  break;
>>  }
>>  
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x90): /* vpgatherd{d,q} 
>> {x,y}mm,mem,{x,y}mm */
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x91): /* vpgatherq{d,q} 
>> {x,y}mm,mem,{x,y}mm */
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x92): /* vgatherdp{s,d} 
>> {x,y}mm,mem,{x,y}mm */
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x93): /* vgatherqp{s,d} 
>> {x,y}mm,mem,{x,y}mm */
>> +{
>> +unsigned int mask_reg = ~vex.reg & (mode_64bit() ? 0xf : 7);
>> +typeof(vex) *pvex;
>> +union {
>> +int32_t dw[8];
>> +int64_t qw[4];
>> +} index, mask;
>> +
>> +ASSERT(ea.type == OP_MEM);
>> +generate_exception_if(modrm_reg == state->sib_index ||
>> +  modrm_reg == mask_reg ||
>> +  state->sib_index == mask_reg, EXC_UD);
>> +generate_exception_if(!cpu_has_avx, EXC_UD);
>> +vcpu_must_have(avx2);
>> +get_fpu(X86EMUL_FPU_ymm, );
>> +
>> +/* Read destination, index, and mask registers. */
>> +opc = init_prefixes(stub);
>> +pvex = copy_VEX(opc, vex);
>> +pvex->opcx = vex_0f;
>> +opc[0] = 0x7f; /* vmovdqa */
>> +/* Use (%rax) as destination and modrm_reg as source. */
>> +pvex->r = !mode_64bit() || !(modrm_reg & 8);
>> +pvex->b = 1;
>> +opc[1] = (modrm_reg & 7) << 3;
>> +pvex->reg = 0xf;
>> +opc[2] = 0xc3;
>> +
>> +invoke_stub("", "", "=m" (*mmvalp) : "a" (mmvalp));
>> +
>> +pvex->pfx = vex_f3; /* vmovdqu */
>> +/* Switch to sib_index as source. */
>> +pvex->r = !mode_64bit() || !(state->sib_index & 8);
>> +opc[1] = (state->sib_index & 7) << 3;
>> +
>> +invoke_stub("", "", "=m" (index) : "a" ());
>> +
>> +/* Switch to mask_reg as source. */
>> +pvex->r = !mode_64bit() || !(mask_reg & 8);
>> +opc[1] = (mask_reg & 7) << 3;
>> +
>> +invoke_stub("", "", "=m" (mask) : "a" ());
>> +put_stub(stub);
>> +
>> +/* Clear untouched parts of the destination and mask values. */
>> +n = 1 << (2 + vex.l - ((b & 1) | vex.w));
>> +op_bytes = 4 << vex.w;
>> +memset((void *)mmvalp + n * op_bytes, 0, 32 - n * op_bytes);
>> +memset((void *) + n * op_bytes, 0, 32 - n * op_bytes);
>> +
>> +for ( i = 0; i < n && rc == X86EMUL_OKAY; ++i )
>> +{
>> +if ( (vex.w ? mask.qw[i] : mask.dw[i]) < 0 )
>> +{
>> +signed long idx = b & 1 ? index.qw[i] : index.dw[i];
>> +
>> +rc = ops->read(ea.mem.seg,
>> +   ea.mem.off + (idx << state->sib_scale),
>> +   (void *)mmvalp + i * op_bytes, op_bytes, 
>> ctxt);
>> +if ( rc != X86EMUL_OKAY )
>> +break;
>> +
>> +#ifdef __XEN__
>> +if ( i + 1 < n && local_events_need_delivery() )
>> +rc = X86EMUL_RETRY;
>> +#endif
>> +}
>> +
>> +if ( vex.w )
>> +mask.qw[i] = 0;
>> +else
>> +mask.dw[i] = 0;
>> +}
> 
> The incomplete case here is rather more complicated.  In the case that
> rc != OK and local events are pending, RF needs setting, 

[Xen-devel] [PATCH v1 4/4] hvm/svm: Enable CR events

[Alexandru Isaila]

This commit enables controlregister events for svm.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/svm/svm.c| 11 +++
 xen/include/asm-x86/monitor.h |  3 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index dc3ad0b..4b34586 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -60,6 +60,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 void svm_asm_do_resume(void);
@@ -560,6 +561,16 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
 svm_fpu_enter(v);
 }
 
+if ( paging_mode_hap(v->domain) )
+{
+uint32_t intercepts = vmcb_get_cr_intercepts(vmcb);
+
+/* Trap CR3 updates if CR3 memory events are enabled. */
+if ( v->domain->arch.monitor.write_ctrlreg_enabled &
+ monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
+   vmcb_set_cr_intercepts(vmcb, intercepts | 
CR_INTERCEPT_CR3_WRITE);
+}
+
 value = v->arch.hvm_vcpu.guest_cr[0] | hw_cr0_mask;
 if ( !paging_mode_hap(v->domain) )
 value |= X86_CR0_PG | X86_CR0_WP;
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 4d8887e..b06ee4e 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -96,7 +96,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 {
 capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
(1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR);
+   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG);
 }
 
 if ( hvm_funcs.set_descriptor_access_exiting )
-- 
2.7.4


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

[Xen-devel] [PATCH v1 1/4] asm-x86/monitor: Enable svm monitor events

[Alexandru Isaila]

This commit separates the svm caps from the vmx caps.

Signed-off-by: Alexandru Isaila 
---
 xen/include/asm-x86/monitor.h | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index a0444d1..3706b7a 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -74,21 +74,28 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
  * At the moment only Intel HVM domains are supported. However, event
  * delivery could be extended to AMD and PV domains.
  */
-if ( !is_hvm_domain(d) || !cpu_has_vmx )
+if ( !is_hvm_domain(d) )
 return capabilities;
 
-capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
-
-/* Since we know this is on VMX, we can just call the hvm func */
-if ( hvm_is_singlestep_supported() )
-capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
+if( cpu_has_vmx )
+{
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
+
+/* Since we know this is on VMX, we can just call the hvm func */
+if ( hvm_is_singlestep_supported() )
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
+}
+else if ( cpu_has_svm )
+{
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
+}
 
 if ( hvm_funcs.set_descriptor_access_exiting )
 capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);
-- 
2.7.4


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

[Xen-devel] [PATCH v1 3/4] hvm/svm: Enable MSR events

[Alexandru Isaila]

This commit enables MSR events for svm.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/svm/svm.c| 9 +
 xen/include/asm-x86/monitor.h | 3 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 14a5f60..dc3ad0b 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -163,6 +163,14 @@ void svm_intercept_msr(struct vcpu *v, uint32_t msr, int 
flags)
 __clear_bit(msr * 2 + 1, msr_bit);
 }
 
+static void svm_enable_msr_interception(struct domain *d, uint32_t msr)
+{
+struct vcpu *v;
+
+for_each_vcpu ( d, v )
+svm_intercept_msr(v, msr, MSR_INTERCEPT_WRITE);
+}
+
 static void svm_save_dr(struct vcpu *v)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -2464,6 +2472,7 @@ static struct hvm_function_table __initdata 
svm_function_table = {
 .fpu_dirty_intercept  = svm_fpu_dirty_intercept,
 .msr_read_intercept   = svm_msr_read_intercept,
 .msr_write_intercept  = svm_msr_write_intercept,
+.enable_msr_interception = svm_enable_msr_interception,
 .set_rdtsc_exiting= svm_set_rdtsc_exiting,
 .set_descriptor_access_exiting = svm_set_descriptor_access_exiting,
 .get_insn_bytes   = svm_get_insn_bytes,
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 68a210a..4d8887e 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -95,7 +95,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 else if ( cpu_has_svm )
 {
 capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT);
+   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR);
 }
 
 if ( hvm_funcs.set_descriptor_access_exiting )
-- 
2.7.4


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

[Xen-devel] [PATCH v1 0/4] hvm/svm: Enable vm events for SVM

[Alexandru Isaila]

Hi all,

This series provides a skeleton for enabling vm_events on SVM. For the
first step, the MSR, CR, Breakpoint and GuestRequest have been tested
and added to the capabilities list.

Cheers,

Alexandru Isaila

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

Re: [Xen-devel] [PATCH v2] x86/xen: init %gs very early to avoid page faults with stack protector

[Juergen Gross]

On 02/02/18 01:36, Chris Patterson wrote:
> Works great, tested it and it fixes booting Linux v4.15 kernel for me :)

Can I add your "Tested-by:" to the patch when committing it?


Juergen

> 
> Cheers!
> 
> On Thu, Feb 1, 2018 at 3:17 PM, Boris Ostrovsky
>  wrote:
>> On 02/01/2018 07:40 AM, Juergen Gross wrote:
>>> When running as Xen pv guest %gs is initialized some time after
>>> C code is started. Depending on stack protector usage this might be
>>> too late, resulting in page faults.
>>>
>>> So setup %gs and MSR_GS_BASE in assembly code already.
>>>
>>> Cc: sta...@vger.kernel.org
>>> Signed-off-by: Juergen Gross 
>>
>> Reviewed-by: Boris Ostrovsky 
>>
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xenproject.org
>> https://lists.xenproject.org/mailman/listinfo/xen-devel
> 


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

Re: [Xen-devel] [PATCH v3 06/25] x86emul: support most remaining AVX2 insns

[Jan Beulich]

>>> On 01.02.18 at 20:45,  wrote:
> On 07/12/17 14:03, Jan Beulich wrote:
>> @@ -2973,7 +2985,7 @@ x86_decode(
>>  }
>>  break;
>>  
>> -case simd_scalar_fp:
>> +case simd_scalar_fp: /* case simd_scalar_dq: */
> 
> I don't see this case label used, or introduced in any later patches. 
> Is it stale?

Oh, indeed it is. And it's been so long that I don't even recall what
it was used for.

>> @@ -6070,6 +6082,10 @@ x86_emulate(
>>  case X86EMUL_OPC_VEX_66(0x0f38, 0x40): /* vpmulld 
>> {x,y}mm/mem,{x,y}mm,{x,y}mm */
>>  if ( !vex.l )
>>  goto simd_0f_avx;
>> +/* fall through */
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x45): /* vpsrlv{d,q} 
>> {x,y}mm/mem,{x,y}mm,{x,y}mm */
> 
> 0x46 / vpsrav{d,q}?  You add a decode for it above, but I don't see an
> introduced case.

See further down - it doesn't fit here very well because there's only
vpsravd, but no vpsravq (which only appears in AVX512).

>> @@ -7150,12 +7169,16 @@ x86_emulate(
>>  fic.insn_bytes = PFX_BYTES + 3;
>>  break;
>>  
>> -case X86EMUL_OPC_VEX_66(0x0f38, 0x19): /* vbroadcastsd m64,ymm */
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x19): /* vbroadcastsd xmm/m64,ymm */
>>  case X86EMUL_OPC_VEX_66(0x0f38, 0x1a): /* vbroadcastf128 m128,ymm */
>>  generate_exception_if(!vex.l, EXC_UD);
>>  /* fall through */
>> -case X86EMUL_OPC_VEX_66(0x0f38, 0x18): /* vbroadcastss m32,{x,y}mm */
>> -generate_exception_if(ea.type != OP_MEM, EXC_UD);
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x18): /* vbroadcastss xmm/m32,{x,y}mm 
>> */
> 
> It would help reviewability substantially if you split bugfixes of
> existing code out separately from introduction of new code, especially
> given the quantity of new additions here.  These comment changes are
> particularly deceptive.

This is not a bugfix - the register forms appear only in AVX2.
Normally I would have added their support right when the
instructions were added for AVX, but it was George who noticed
them missing after the AVX patch had gone in already. Changing
the code here still fits under the topic of the patch.

>>  case X86EMUL_OPC_VEX_66(0x0f38, 0x0c): /* vpermilps 
>> {x,y}mm/mem,{x,y}mm,{x,y}mm */
>>  case X86EMUL_OPC_VEX_66(0x0f38, 0x0d): /* vpermilpd 
>> {x,y}mm/mem,{x,y}mm,{x,y}mm */
>> @@ -7254,6 +7277,11 @@ x86_emulate(
>>  op_bytes = 8 << vex.l;
>>  goto simd_0f_ymm;
>>  
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x16): /* vpermps ymm/m256,ymm,ymm */
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x36): /* vpermd ymm/m256,ymm,ymm */
>> +generate_exception_if(!vex.l || vex.w, EXC_UD);
>> +goto simd_0f_avx2;
>> +
> 
> Looking at these additions, the case labels look like they need sorting
> again.  Are you going to organise that in a later patch?

I don't understand. Together with context above and ...

>>  case X86EMUL_OPC_VEX_66(0x0f38, 0x20): /* vpmovsxbw xmm/mem,{x,y}mm */
>>  case X86EMUL_OPC_VEX_66(0x0f38, 0x21): /* vpmovsxbd xmm/mem,{x,y}mm */
>>  case X86EMUL_OPC_VEX_66(0x0f38, 0x22): /* vpmovsxbq xmm/mem,{x,y}mm */

... here I don't see what's wrong. The lowest entry in each block
of case statements wanting similar treatment rules: 0x16 is above
0x0d and below 0x20.

>> @@ -7370,6 +7398,80 @@ x86_emulate(
>>  generate_exception_if(vex.l, EXC_UD);
>>  goto simd_0f_avx;
>>  
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x58): /* vpbroadcastd xmm/m32,{x,y}mm 
>> */
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x59): /* vpbroadcastq xmm/m64,{x,y}mm 
>> */
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x78): /* vpbroadcastb xmm/m8,{x,y}mm */
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x79): /* vpbroadcastw xmm/m16,{x,y}mm 
>> */
>> +op_bytes = 1 << ((!(b & 0x20) * 2) + (b & 1));
>> +/* fall through */
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x46): /* vpsravd 
>> {x,y}mm/mem,{x,y}mm,{x,y}mm */
>> +generate_exception_if(vex.w, EXC_UD);
> 
> Oh - here is vpsrav{d,q}.  Why is it not with its companions?  The
> manual does curiously omit mention of the W1 encoding for VEX (unlike
> its companions), but all 3 have W0 and W1 mentioned for EVEX encoding. 
> Judging by them all having identical behaviour, and this one not being
> declared as suffering a fault because of W, I expect that it is probably
> encoded as WIG.

Without trying out (which is unreliable as they might change things
between silicon revisions), I have to follow what the SDM and/or XED
say, and both say W0. We both know that things aren't always
consistent in the manual, so I prefer to use the tighter variant in case
of doubt - imo it's always better to relax things down the road than to
rely on catching faults raised from the stubs.

And trying it out (again; I'm sure I did so a year ago when this was
all put together), my Haswell faults for the W1 encoding.

> I've noticed lower down as well that you are inconsistent with vex.w
> 

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

[Jan Beulich]

>>> On 01.02.18 at 15:38,  wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -916,6 +916,19 @@ Controls EPT related features.
>  
>  Specify which console gdbstub should use. See **console**.
>  
> +### gnttab
> +> `= List of [ max_ver:, transitive= ]`

I realize you don't want to change this as people already use it, but
I'd still like to give my usual comment: I'd prefer if we could avoid
introducing further underscore-containing (sub)options. I really don't
understand why everyone does this: Dashes are easier to type on
all keyboards I'm aware of, and there's no need to mimic C identifier
names for command line options.

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -97,6 +97,40 @@ static unsigned int __read_mostly max_maptrack_frames =
> DEFAULT_MAX_MAPTRACK_FRAMES;
>  integer_runtime_param("gnttab_max_maptrack_frames", max_maptrack_frames);
>  
> +static unsigned int __read_mostly opt_gnttab_max_version = 2;
> +static bool __read_mostly opt_transitive_grants = true;
> +
> +static int __init parse_gnttab(const char *s)
> +{
> +const char *ss;
> +int val, rc = 0;
> +
> +do {
> +ss = strchr(s, ',');
> +if ( !ss )
> +ss = strchr(s, '\0');
> +
> +if ( !strncmp(s, "max_ver:", 8) )
> +{
> +long ver = simple_strtol(s + 8, NULL, 10);

In particular with you already having determined the intended end
of the number, wouldn't it make sense to refuse non-number input,
by checking ss against what simple_strtol() would provide if the
middle parameter wasn't NULL?

> @@ -3424,7 +3459,10 @@ do_grant_table_op(
>  break;
>  
>  case GNTTABOP_set_version:
> -rc = gnttab_set_version(guest_handle_cast(uop, 
> gnttab_set_version_t));
> +if ( opt_gnttab_max_version == 1 )
> +rc = -ENOSYS; /* Behave as before set_version was introduced. */
> +else
> +rc = gnttab_set_version(guest_handle_cast(uop, 
> gnttab_set_version_t));
>  break;

I can sort of see why you want it this way, but why do you mean to
penalize any guest simply setting the version to 1 regardless of its
current setting (like might e.g. be needed in kexec-like situations)?
Guests may assume the availability of set_version by looking at the
Xen version number (whether that's an entirely valid thing to do is
a separate question).

Jan


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

[Xen-devel] [PATCH V3] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Razvan Cojocaru]

The emulation layers of Xen lack PCID support, and as we only offer
PCID to HAP guests, all writes to CR3 are handled by hardware,
except when introspection is involved. Consequently, trying to set
CR3 when the noflush bit is set in hvm_set_cr3() leads to domain
crashes. The workaround is to clear the noflush bit in
hvm_set_cr3(). CR3 values in hvm_monitor_cr() are also sanitized.
Additionally, a bool parameter now propagates to
{svm,vmx}_update_guest_cr(), so that no flushes occur when
the bit was set.

Signed-off-by: Razvan Cojocaru 
Reported-by: Bitweasil 
Suggested-by: Andrew Cooper 

---
Changes since V2:
 - Fixed the write_ctrlreg.index check (the proper comparison
   is with VM_EVENT_X86_CR3, not 3). Noticed by Tamas.
---
 xen/arch/x86/hvm/domain.c |  6 +++---
 xen/arch/x86/hvm/hvm.c| 25 -
 xen/arch/x86/hvm/monitor.c|  3 +++
 xen/arch/x86/hvm/svm/nestedsvm.c  |  4 ++--
 xen/arch/x86/hvm/svm/svm.c| 22 ++
 xen/arch/x86/hvm/svm/vmcb.c   |  4 ++--
 xen/arch/x86/hvm/vmx/vmcs.c   |  4 ++--
 xen/arch/x86/hvm/vmx/vmx.c| 16 +---
 xen/arch/x86/mm.c |  2 +-
 xen/arch/x86/mm/hap/hap.c |  6 +++---
 xen/arch/x86/mm/shadow/common.c   |  2 +-
 xen/arch/x86/mm/shadow/multi.c|  6 +++---
 xen/arch/x86/mm/shadow/none.c |  2 +-
 xen/arch/x86/monitor.c|  2 +-
 xen/include/asm-x86/hvm/hvm.h | 10 +++---
 xen/include/asm-x86/hvm/svm/svm.h |  2 +-
 xen/include/asm-x86/paging.h  |  7 ---
 17 files changed, 73 insertions(+), 50 deletions(-)

diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c
index 6047464..9be085e 100644
--- a/xen/arch/x86/hvm/domain.c
+++ b/xen/arch/x86/hvm/domain.c
@@ -287,9 +287,9 @@ int arch_set_info_hvm_guest(struct vcpu *v, const 
vcpu_hvm_context_t *ctx)
 return -EINVAL;
 }
 
-hvm_update_guest_cr(v, 0);
-hvm_update_guest_cr(v, 3);
-hvm_update_guest_cr(v, 4);
+hvm_update_guest_cr(v, 0, false);
+hvm_update_guest_cr(v, 3, false);
+hvm_update_guest_cr(v, 4, false);
 hvm_update_guest_efer(v);
 
 if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) )
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 18d721d..10c62fb 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2171,7 +2171,7 @@ static void hvm_update_cr(struct vcpu *v, unsigned int 
cr, unsigned long value)
 {
 v->arch.hvm_vcpu.guest_cr[cr] = value;
 nestedhvm_set_cr(v, cr, value);
-hvm_update_guest_cr(v, cr);
+hvm_update_guest_cr(v, cr, false);
 }
 
 int hvm_set_cr0(unsigned long value, bool_t may_defer)
@@ -2297,6 +2297,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 struct vcpu *v = current;
 struct page_info *page;
 unsigned long old = v->arch.hvm_vcpu.guest_cr[3];
+bool noflush = false;
 
 if ( may_defer && unlikely(v->domain->arch.monitor.write_ctrlreg_enabled &
monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3)) )
@@ -2313,6 +2314,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 }
 }
 
+if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */
+{
+noflush = !!(value & X86_CR3_NOFLUSH);
+value &= X86_CR3_NOFLUSH_DISABLE_MASK;
+}
+
 if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
  (value != v->arch.hvm_vcpu.guest_cr[3]) )
 {
@@ -2330,7 +2337,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 }
 
 v->arch.hvm_vcpu.guest_cr[3] = value;
-paging_update_cr3(v);
+paging_update_cr3(v, noflush);
 return X86EMUL_OKAY;
 
  bad_cr3:
@@ -3059,7 +3066,7 @@ void hvm_task_switch(
 hvm_set_segment_register(v, x86_seg_tr, );
 
 v->arch.hvm_vcpu.guest_cr[0] |= X86_CR0_TS;
-hvm_update_guest_cr(v, 0);
+hvm_update_guest_cr(v, 0, false);
 
 if ( (taskswitch_reason == TSW_iret ||
   taskswitch_reason == TSW_jmp) && otd_writable )
@@ -3895,16 +3902,16 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs, 
uint16_t ip)
 memset(>arch.debugreg, 0, sizeof(v->arch.debugreg));
 
 v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_ET;
-hvm_update_guest_cr(v, 0);
+hvm_update_guest_cr(v, 0, false);
 
 v->arch.hvm_vcpu.guest_cr[2] = 0;
-hvm_update_guest_cr(v, 2);
+hvm_update_guest_cr(v, 2, false);
 
 v->arch.hvm_vcpu.guest_cr[3] = 0;
-hvm_update_guest_cr(v, 3);
+hvm_update_guest_cr(v, 3, false);
 
 v->arch.hvm_vcpu.guest_cr[4] = 0;
-hvm_update_guest_cr(v, 4);
+hvm_update_guest_cr(v, 4, false);
 
 v->arch.hvm_vcpu.guest_efer = 0;
 hvm_update_guest_efer(v);
@@ -4031,7 +4038,7 @@ static int hvmop_flush_tlb_all(void)
 
 /* Flush paging-mode soft state (e.g., va->gfn cache; PAE PDPE cache). */
 for_each_vcpu ( d, v )
-paging_update_cr3(v);
+paging_update_cr3(v,