[Xen-devel] [xen-4.9-testing test] 112449: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
96

Regressions which are regarded as allowable (not blocking):
 build-arm64   2 hosts-allocate broken REGR. vs. 96
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 96
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 96

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 62
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 62
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 96
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 96
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 13 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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   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-qemut-win10-i386 10 windows-installfail 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
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  f4f02f121f271ee0722723e393226687b42e29a1
baseline version:
 xen  0fada059a7948153976cc152e36633dee3d5b273

Last test of basis   96  2017-06-29 17:21:55 Z   36 days
Testing same since   112449  2017-08-04 16:13:57 Z0 days1 attempts

[Xen-devel] [xen-unstable-smoke test] 112458: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 
112402
 test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 112402

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  32e7db7f6fbb91dac1e4e1bbcab4851c4606e0fa
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112402  2017-07-31 21:02:08 Z4 days
Failing since112418  2017-08-03 11:04:58 Z1 days   18 attempts
Testing same since   112448  2017-08-04 16:01:08 Z0 days6 attempts


People who touched revisions under test:
  Andrii Anisov 
  He Chen 
  Ian Jackson 
  Iurii Konovalenko 
  Iurii Mykhalskyi 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Marek Marczykowski-Górecki 
  Praveen Kumar 
  Rusty Bird 
  Sergej Proskurin 
  Stefano Stabellini 
  Wei Liu 
  Xiao Liang 
  xiliang 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs
broken-step build-arm64-pvops capture-logs

Not pushing.

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

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112437 
pass in 112447
 test-armhf-armhf-xl-credit2   6 xen-installfail pass in 112437

Regressions which are regarded as allowable (not blocking):
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112286
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112286
 build-arm64   2 hosts-allocate broken REGR. vs. 112286

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 112286
 build-arm64-pvops 3 capture-logs  broken blocked in 112286
 build-arm64   3 capture-logs  broken blocked in 112286
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
112286
 test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 112437 never pass
 test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 112437 never 
pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112274
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112286
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112286
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112286
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112286
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112286
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112286
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail 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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail 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-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4
baseline version:
 

[Xen-devel] [xen-unstable-smoke test] 112457: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 
112402
 test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 112402

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  32e7db7f6fbb91dac1e4e1bbcab4851c4606e0fa
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112402  2017-07-31 21:02:08 Z4 days
Failing since112418  2017-08-03 11:04:58 Z1 days   17 attempts
Testing same since   112448  2017-08-04 16:01:08 Z0 days5 attempts


People who touched revisions under test:
  Andrii Anisov 
  He Chen 
  Ian Jackson 
  Iurii Konovalenko 
  Iurii Mykhalskyi 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Marek Marczykowski-Górecki 
  Praveen Kumar 
  Rusty Bird 
  Sergej Proskurin 
  Stefano Stabellini 
  Wei Liu 
  Xiao Liang 
  xiliang 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Not pushing.

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

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

[Xen-devel] [PATCH] x86: remove an ASSERT to avoid crash when destroy a domain.

[Yi Sun]

In 'psr_free_cos', we should not use 'ASSERT(socket_info)' because
the 'socket_info' is allocated only if 'psr' boot parameter is set.
So remove it and use 'psr_alloc_feat_enabled' to check if 'socket_info'
is valid or not to avoid crash.

Signed-off-by: Yi Sun 
---
 xen/arch/x86/psr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 7d9fa26..9ce8f17 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -1294,11 +1294,11 @@ static void psr_free_cos(struct domain *d)
 {
 unsigned int socket, cos;
 
-ASSERT(socket_info);
-
 if ( !d->arch.psr_cos_ids )
 return;
 
+ASSERT(socket_info);
+
 /* Domain is destroyed so its cos_ref should be decreased. */
 for ( socket = 0; socket < nr_sockets; socket++ )
 {
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v4] x86/hvm: Allow guest_request vm_events coming from userspace

[Tamas K Lengyel]

On Fri, Aug 4, 2017 at 5:32 AM, Alexandru Isaila 
wrote:

> In some introspection usecases, an in-guest agent needs to communicate
> with the external introspection agent.  An existing mechanism is
> HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
> like all other hypercalls.
>
> Introduce a mechanism whereby the introspection agent can whitelist the
> use of HVMOP_guest_request_vm_event directly from userspace.
>
> Signed-off-by: Alexandru Isaila 
>
> ---
> Changes since V3:
> - Changed commit message
> - Added new lines
> - Indent the maximum space on the defines
> - Chaned the name of the define/function name/struct member
>   from vmcall to event
> ---
>  tools/libxc/include/xenctrl.h |  1 +
>  tools/libxc/xc_monitor.c  | 14 ++
>  xen/arch/x86/hvm/hypercall.c  |  5 +
>  xen/common/monitor.c  | 14 ++
>  xen/include/public/domctl.h   | 21 +++--
>  xen/include/xen/sched.h   |  5 +++--
>  6 files changed, 48 insertions(+), 12 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index bde8313..90a056f 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2022,6 +2022,7 @@ int xc_monitor_descriptor_access(xc_interface *xch,
> domid_t domain_id,
>   bool enable);
>  int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
>   bool enable, bool sync);
> +int xc_allow_guest_userspace_event(xc_interface *xch, domid_t domain_id,
> bool enable);
>  int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
>  bool enable, bool sync);
>  int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
> index b44ce93..6064c39 100644
> --- a/tools/libxc/xc_monitor.c
> +++ b/tools/libxc/xc_monitor.c
> @@ -161,6 +161,20 @@ int xc_monitor_guest_request(xc_interface *xch,
> domid_t domain_id, bool enable,
>  return do_domctl(xch, );
>  }
>
> +int xc_allow_guest_userspace_event(xc_interface *xch, domid_t domain_id,
> bool enable)
>

This function should be prefixed with "xc_monitor_" like all the rest of
the functions here.


> +{
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_monitor_op;
> +domctl.domain = domain_id;
> +domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
> +: XEN_DOMCTL_MONITOR_OP_DISABLE;
> +domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_GUEST
> _USERSPACE_EVENT;
> +
> +return do_domctl(xch, );
> +}
> +
> +
>  int xc_monitor_emulate_each_rep(xc_interface *xch, domid_t domain_id,
>  bool enable)
>  {
> diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
> index e7238ce..8eb5f49 100644
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -155,6 +155,11 @@ int hvm_hypercall(struct cpu_user_regs *regs)
>  /* Fallthrough to permission check. */
>  case 4:
>  case 2:
> +if ( currd->monitor.guest_request_userspace_event &&

+eax == __HYPERVISOR_hvm_op &&
> +(mode == 8 ? regs->rdi : regs->ebx) ==
> HVMOP_guest_request_vm_event )
> +break;
> +
>  if ( unlikely(hvm_get_cpl(curr)) )
>  {
>  default:
> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
> index 451f42f..21a1457 100644
> --- a/xen/common/monitor.c
> +++ b/xen/common/monitor.c
> @@ -79,6 +79,20 @@ int monitor_domctl(struct domain *d, struct
> xen_domctl_monitor_op *mop)
>  break;
>  }
>
> +case XEN_DOMCTL_MONITOR_EVENT_GUEST_USERSPACE_EVENT:
> +{
> +bool_t old_status = d->monitor.guest_request_enabled;
>

You are checking guest_request enabled here while later setting
guest_request_userspace_event. These are two separate monitor options,
adjust accordingly.


> +
> +if ( unlikely(old_status == requested_status) )
> +return -EEXIST;
> +
> +domain_pause(d);
> +d->monitor.guest_request_sync = mop->u.guest_request.sync;
>

You are setting guest_request_sync here which is a setting belonging to
guest_request_enabled. If you need sync/async option for the userspace
guest request it should be a separate bit. Since the toolstack side you add
in this patch never sets the sync option I assume that is not the case, so
remove this.


> +d->monitor.guest_request_userspace_event = requested_status;
> +domain_unpause(d);
> +break;
> +}
> +
>  default:
>  /* Give arch-side the chance to handle this event */
>  return arch_monitor_domctl_event(d, mop);
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index ff39762..870495c 100644
> --- 

[Xen-devel] [xen-unstable-smoke test] 112453: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 
112402
 test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 112402

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  32e7db7f6fbb91dac1e4e1bbcab4851c4606e0fa
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112402  2017-07-31 21:02:08 Z4 days
Failing since112418  2017-08-03 11:04:58 Z1 days   16 attempts
Testing same since   112448  2017-08-04 16:01:08 Z0 days4 attempts


People who touched revisions under test:
  Andrii Anisov 
  He Chen 
  Ian Jackson 
  Iurii Konovalenko 
  Iurii Mykhalskyi 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Marek Marczykowski-Górecki 
  Praveen Kumar 
  Rusty Bird 
  Sergej Proskurin 
  Stefano Stabellini 
  Wei Liu 
  Xiao Liang 
  xiliang 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Not pushing.

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

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112422
 test-armhf-armhf-xl-multivcpu  7 xen-bootfail REGR. vs. 112422

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112422
 build-arm64-xsm   2 hosts-allocate  broken like 112422
 build-arm64   2 hosts-allocate  broken like 112422
 build-arm64   3 capture-logsbroken like 112422
 build-arm64-pvops 3 capture-logsbroken like 112422
 build-arm64-xsm   3 capture-logsbroken like 112422
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
112422
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112422
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112422
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112422
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112422
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112422
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-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-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   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

version targeted for testing:
 qemuu413ff8be2fcb5e5c4422f5c1bacdb7e5b5915e5e
baseline version:
 qemuuaaaec6acad7cf97372d48c1b09126a09697519c8

Last test of basis   112422  2017-08-03 11:26:23 Z1 days
Testing same since   112444  2017-08-04 11:16:55 Z0 days1 attempts


People who touched revisions under test:
  Hervé Poussineau 
  Peter Maydell 
  Prasad J Pandit 
  Samuel Thibault 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 

[Xen-devel] [linux-3.18 test] 112443: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale 16 guest-start/debian.repeat fail in 112431 pass 
in 112443
 test-armhf-armhf-xl-multivcpu  6 xen-install fail in 112431 pass in 112443
 test-armhf-armhf-libvirt-raw  6 xen-installfail pass in 112431

Regressions which are regarded as allowable (not blocking):
 build-arm64   2 hosts-allocate broken REGR. vs. 112102
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 build-arm64   3 capture-logs  broken blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 112431 blocked in 
112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 112431 like 
112102
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 112431 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112085
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-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-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail 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-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-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-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-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
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 

[Xen-devel] [xen-unstable-smoke test] 112451: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 
112402
 test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 112402

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl  12 guest-startfail pass in 112450

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 test-armhf-armhf-xl 13 migrate-support-check fail in 112450 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 112450 never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  32e7db7f6fbb91dac1e4e1bbcab4851c4606e0fa
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112402  2017-07-31 21:02:08 Z4 days
Failing since112418  2017-08-03 11:04:58 Z1 days   15 attempts
Testing same since   112448  2017-08-04 16:01:08 Z0 days3 attempts


People who touched revisions under test:
  Andrii Anisov 
  He Chen 
  Ian Jackson 
  Iurii Konovalenko 
  Iurii Mykhalskyi 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Marek Marczykowski-Górecki 
  Praveen Kumar 
  Rusty Bird 
  Sergej Proskurin 
  Stefano Stabellini 
  Wei Liu 
  Xiao Liang 
  xiliang 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  fail
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Not pushing.

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

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

[Xen-devel] [linux-linus test] 112442: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  7 reboot   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 110515
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
110515
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 110515
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 110515
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 110515

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 110515
 build-arm64   2 hosts-allocate broken REGR. vs. 110515
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 110515
 build-arm64-pvops 3 capture-logs  broken blocked in 110515
 build-arm64   3 capture-logs  broken blocked in 110515
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-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-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-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-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl 

Re: [Xen-devel] [PATCH RFC v1 2/3] libxl: enable per-VCPU work conserving flag for RTDS

[Meng Xu]

On Fri, Aug 4, 2017 at 10:34 AM, Wei Liu  wrote:
> On Fri, Aug 04, 2017 at 02:53:51PM +0200, Dario Faggioli wrote:
>> On Fri, 2017-08-04 at 13:10 +0100, Wei Liu wrote:
>> > On Fri, Aug 04, 2017 at 10:13:18AM +0200, Dario Faggioli wrote:
>> > > On Thu, 2017-08-03 at 17:39 -0400, Meng Xu wrote:
>> > > >
>> > > *HOWEVER*, in this case, we do have that 'extratime' field already,
>> > > as
>> > > a leftover from SEDF, which is there taking space and cluttering
>> > > the
>> > > interface, so why don't make good use of it. Especially considering
>> > > it
>> > > was used for _exactly_ the same thing, and with _exactly_ the same
>> > > meaning, and even for a very similar (i.e., SEDF was also real-
>> > > time)
>> > > kind of scheduler.
>> >
>> > Correct me if I'm wrong:
>> >
>> > 1. extratime is ever only used in SEDF
>> > 2. SEDF is removed
>> >
>> > That means we do have extratime to use in all other schedulers.
>> >
>> I'm not sure what you mean with this last line.
>>
>> IAC, this is how our the related data structures looks like, right now:
>>
>> libxl_sched_params = Struct("sched_params",[
>> ("vcpuid",   integer, {'init_val': 
>> 'LIBXL_SCHED_PARAM_VCPU_INDEX_DEFAULT'}),
>> ("weight",   integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT'}),
>> ("cap",  integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT'}),
>> ("period",   integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT'}),
>> ("extratime",integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
>> ("budget",   integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),
>> ])
>>
>> The extratime field is there. Any scheduler can use it, if it wants
>> (and in the way it wants). Currently, no one of them does that.
>
> Right, that's what I wanted to know.
>
>>
>> libxl_domain_sched_params = Struct("domain_sched_params",[
>> ("sched",libxl_scheduler),
>> ("weight",   integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT'}),
>> ("cap",  integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT'}),
>> ("period",   integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT'}),
>> ("budget",   integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),
>>
>> # The following three parameters ('slice', 'latency' and 'extratime') 
>> are deprecated,
>> # and will have no effect if used, since the SEDF scheduler has been 
>> removed.
>> # Note that 'period' was an SDF parameter too, but it is still effective 
>> as it is
>> # now used (together with 'budget') by the RTDS scheduler.
>> ("slice",integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT'}),
>> ("latency",  integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT'}),
>> ("extratime",integer, {'init_val': 
>> 'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
>> ])
>>
>> Same here. 'slice', 'latency' and 'extratime' are there because we
>> deprecate, but don't remove stuff. They're not used in any way. [*]
>>
>> If, at some point, I'd decide to develop a feature for, say Credit2,
>> that controll the latency (whatever that would mean, it's just an
>> example! :-D) of domains, I think I'll use this 'latency' field, for
>> its interface, instead of adding some other stuff.
>>
>> > However, please consider the possibility of reintroducing SEDF in the
>> > future. Suppose that would happen, does extratime still has the same
>> > semantics?
>> >
>> Well, I guess yes. But how does this matter? Each scheduler can, if it
>> wants, use all these parameters in the way it actuallly prefers. So,
>> the fact that RTDS will be using 'extratime' for letting vCPUs execute
>> past their own real-time reservation, does not prevent the reintroduced
>> SEDF --nor any other already existing or new scheduler-- to also use
>> it, for similar (or maybe even not so similar) purposes.
>>
>> Or am I missing something?
>
> If extratime means different things to different schedulers, it's going
> to be confusing. As a layperson I can't tell what extratime is or how it
> is supposed to be used. I would like to have the field to have only one
> meaning.

Right now, extratime is not used by any scheduler. It was used in SEDF only.

Since RTDS is the first scheduler to use the extratime after SEDF is
depreciated, if we will use it, it only has one meaning: if extratime
is non-zero, it indicates the VCPU will get extra time.

I guess I lean to use extratime in the RTDS now.

Best,

Meng
---
Meng Xu
PhD Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH RFC v1 3/3] xl: enable per-VCPU work conserving flag for RTDS

[Meng Xu]

On Fri, Aug 4, 2017 at 5:01 AM, Dario Faggioli
 wrote:
> On Thu, 2017-08-03 at 18:02 -0400, Meng Xu wrote:
>> On Thu, Aug 3, 2017 at 12:03 PM, Dario Faggioli
>>  wrote:
>> >
>> > > @@ -702,14 +705,18 @@ int main_sched_rtds(int argc, char **argv)
>> > >  int *vcpus = (int *)xmalloc(sizeof(int)); /* IDs of VCPUs
>> > > that
>> > > change */
>> > >  int *periods = (int *)xmalloc(sizeof(int)); /* period is in
>> > > microsecond */
>> > >  int *budgets = (int *)xmalloc(sizeof(int)); /* budget is in
>> > > microsecond */
>> > > +int *workconservings = (int *)xmalloc(sizeof(int)); /*
>> > > budget is
>> > > in microsecond */
>> > >
>> >
>> > Yeah, budget is in microseconds. But this is not budget! :-P
>>
>> Ah, my bad..
>>
>> >
>> > In fact (jokes apart), it can be just a bool, can't it?
>>
>> Yes, bool is enough.
>> Is "workconserving" too long here?
>>
> So, I don't want to turn this into a discussion about what colour we
> should paint the infamous bikeshed... but, yeah, I don't especially
> like this name! :-P
>
> An I mean, not only here, but everywhere you've used it (changelogs,
> other patches, etc.).
>
> There are two reasons for that:
>  - it's indeed very long;
>  - being work conserving is (or at least, I've always heard it used
>and used it myself) a characteristic of a scheduling algorithm (or
>of its implementation), *not* of a task/vcpu/schedulable entity.

Fair enough. I agree work conserving  is not a good name.

>
>It is the scheduler that is work conserving, iff it never let CPUs
>sit idle, when there is work to do. In our case here, the scheduler
>is work conserving if all the vCPUs has this flag set. It's not,
>if even just one has it clear.
>
>And by putting workconserving-ness at the vCPU level, it looks to
>me that we're doing something terminologically wrong, and
>potentially confusing.
>
> I didn't bring this up before, because I'm a bit afraid that it's just
> be being picky... but since you mentioned this yourself.
>
>> I thought about alternative names, such as "wc", "workc", and
>> "extratime". None of them is good enough.
>>
> Yep, I agree that contractions like 'wc' or 'workc' are pretty bad.
> 'extratime', I'd actually like it better, TBH.
>
>> The ideal one should be much
>> shorter and easy to link to "work conserving". :(
>> If we use "extratime", it may cause confusion with the "extratime" in
>> the depreciated SEDF. (That is my concern of reusing the EXTRATIME in
>> the libxl_type.idl.)
>>
> Well, but SEDF being gone (and since quite a few time), and the fact
> that RTDS and SEDF have not really never been there together, does
> leave very few room for confusion, I think.
>
> While in academia (e.g., in the GRUB == Gready Reclaming of Unused
> Bandwidth papers), what you're trying to achieved, I've heard it called
> 'reclaiming' (as I'm sure you have as well :-)), and my friends that
> are still working on Linux, are actually using it in there:
>
> https://lkml.org/lkml/2017/5/18/1128
> https://lkml.org/lkml/2017/5/18/1137 <-- SCHED_FLAG_RECLAIM
>
> I'm not so sure about it... As I'm not sure the meaning would appear
> obvious, to people not into RT scheduling research.
>
> And even from this point of view, 'extratime' seems a lot better to me.
> And if it were me doing this, I'd probably use it, both in the
> internals and in the interface.
>

I'm thinking between reclaim and extratime.
I will use extratime since extratime is already in the libxl.
extratime means the VCPU will have extra time. It's the scheduler to
determine how much extratime it will get.

Thanks,

Meng

---
Meng Xu
PhD Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH RFC v1 2/3] libxl: enable per-VCPU work conserving flag for RTDS

[Dario Faggioli]

On Fri, 2017-08-04 at 15:34 +0100, Wei Liu wrote:
> On Fri, Aug 04, 2017 at 02:53:51PM +0200, Dario Faggioli wrote:
> > 
> > Well, I guess yes. But how does this matter? Each scheduler can, if
> > it
> > wants, use all these parameters in the way it actuallly prefers.
> > So,
> > the fact that RTDS will be using 'extratime' for letting vCPUs
> > execute
> > past their own real-time reservation, does not prevent the
> > reintroduced
> > SEDF --nor any other already existing or new scheduler-- to also
> > use
> > it, for similar (or maybe even not so similar) purposes.
> > 
> > Or am I missing something?
> 
> If extratime means different things to different schedulers, it's
> going
> to be confusing. As a layperson I can't tell what extratime is or how
> it
> is supposed to be used. I would like to have the field to have only
> one
> meaning.
>
Well, I do see what you mean, but then I don't understand why we have
the data structure organized like this, i.e., with all the parameters
for all the schedulers in the same struct.

IAC:
- extratime was only used by SEDF
- SEDF is not coming back, at least not in the form it had when it was
removed, because it was bitrotten and buggy, and RTDS has actually
replaced it
- if a correct version of SEDF would ever come back, and live alongside
with RTDS, both the schedulers would use extratime to mean the same
(although, of course, actual use and implementation may vary)

This should be enough to address your concerns. Let me know if it's
not. :-)

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

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

[Xen-devel] [xen-unstable-smoke test] 112450: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 
112402
 test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 112402

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  32e7db7f6fbb91dac1e4e1bbcab4851c4606e0fa
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112402  2017-07-31 21:02:08 Z3 days
Failing since112418  2017-08-03 11:04:58 Z1 days   14 attempts
Testing same since   112448  2017-08-04 16:01:08 Z0 days2 attempts


People who touched revisions under test:
  Andrii Anisov 
  He Chen 
  Ian Jackson 
  Iurii Konovalenko 
  Iurii Mykhalskyi 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Marek Marczykowski-Górecki 
  Praveen Kumar 
  Rusty Bird 
  Sergej Proskurin 
  Stefano Stabellini 
  Wei Liu 
  Xiao Liang 
  xiliang 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Not pushing.

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

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

[Xen-devel] [linux-next test] 112441: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64  7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 112430
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 112430
 test-amd64-amd64-xl-qemut-ws16-amd64  7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 112430
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 112430
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 112430
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 112430
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 112430
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 112430
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 112430
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 112430
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 112430
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 112430
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 112430
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 112430
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 112430
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
112430
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 112430
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 112430
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 112430
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 112430
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 112430
 test-amd64-amd64-xl-qemut-win10-i386  7 xen-boot fail REGR. vs. 112430
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 112430
 test-amd64-amd64-xl-pvh-amd   7 xen-boot fail REGR. vs. 112430
 test-amd64-amd64-qemuu-nested-amd  7 xen-bootfail REGR. vs. 112430
 test-amd64-amd64-xl-qemuu-win7-amd64  7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
112430
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 112430
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 112430
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 112430
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 112430
 test-amd64-i386-examine   7 reboot   fail REGR. vs. 112430
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 112430

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  7 xen-boot fail REGR. vs. 112430

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 112430
 build-arm64-pvops 2 hosts-allocate  broken like 112430
 build-arm64-xsm   2 hosts-allocate  broken like 112430
 build-arm64   3 capture-logsbroken like 112430
 build-arm64-xsm   3 capture-logs

Re: [Xen-devel] [PATCH 3/3] xen: remove not used trace functions

[Boris Ostrovsky]

On 08/04/2017 07:36 AM, Juergen Gross wrote:
> There are some Xen specific trace functions defined in
> include/trace/events/xen.h. Remove them.
>
> Signed-off-by: Juergen Gross 

(Again, adding Ingo and Steven)

Reviewed-by: Boris Ostrovsky 

although I think "s/some Xen/some unused Xen/" in the commit message
would make it clearer.

> ---
>  include/trace/events/xen.h | 20 
>  1 file changed, 20 deletions(-)
>
> diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
> index 677e8ac2bb81..1b4fed72f573 100644
> --- a/include/trace/events/xen.h
> +++ b/include/trace/events/xen.h
> @@ -248,16 +248,6 @@ TRACE_EVENT(xen_mmu_set_p4d,
> (int)sizeof(p4dval_t) * 2, (unsigned long 
> long)pgd_val(native_make_pgd(__entry->p4dval)),
> (int)sizeof(p4dval_t) * 2, (unsigned long 
> long)__entry->p4dval)
>   );
> -
> -TRACE_EVENT(xen_mmu_pud_clear,
> - TP_PROTO(pud_t *pudp),
> - TP_ARGS(pudp),
> - TP_STRUCT__entry(
> - __field(pud_t *, pudp)
> - ),
> - TP_fast_assign(__entry->pudp = pudp),
> - TP_printk("pudp %p", __entry->pudp)
> - );
>  #else
>  
>  TRACE_EVENT(xen_mmu_set_pud,
> @@ -277,16 +267,6 @@ TRACE_EVENT(xen_mmu_set_pud,
>  
>  #endif
>  
> -TRACE_EVENT(xen_mmu_pgd_clear,
> - TP_PROTO(pgd_t *pgdp),
> - TP_ARGS(pgdp),
> - TP_STRUCT__entry(
> - __field(pgd_t *, pgdp)
> - ),
> - TP_fast_assign(__entry->pgdp = pgdp),
> - TP_printk("pgdp %p", __entry->pgdp)
> - );
> -
>  DECLARE_EVENT_CLASS(xen_mmu_ptep_modify_prot,
>   TP_PROTO(struct mm_struct *mm, unsigned long addr,
>pte_t *ptep, pte_t pteval),


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

Re: [Xen-devel] [PATCH 2/3] xen: remove unused function xen_set_domain_pte()

[Boris Ostrovsky]

On 08/04/2017 07:36 AM, Juergen Gross wrote:
> The function xen_set_domain_pte() is used nowhere in the kernel.
> Remove it.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 

(+ Ingo and Steven who are maintainers of include/trace/events/xen.h)

> ---
>  arch/x86/include/asm/xen/page.h |  2 --
>  arch/x86/xen/mmu_pv.c   | 20 
>  include/trace/events/xen.h  | 18 --
>  3 files changed, 40 deletions(-)
>
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 497f7d28c1d6..07b6531813c4 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -314,8 +314,6 @@ static inline pte_t __pte_ma(pteval_t x)
>  #define p4d_val_ma(x)((x).p4d)
>  #endif
>  
> -void xen_set_domain_pte(pte_t *ptep, pte_t pteval, unsigned domid);
> -
>  xmaddr_t arbitrary_virt_to_machine(void *address);
>  unsigned long arbitrary_virt_to_mfn(void *vaddr);
>  void make_lowmem_page_readonly(void *vaddr);
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index cab28cf2cffb..0422ee7e70b3 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -162,26 +162,6 @@ static bool xen_page_pinned(void *ptr)
>   return PagePinned(page);
>  }
>  
> -void xen_set_domain_pte(pte_t *ptep, pte_t pteval, unsigned domid)
> -{
> - struct multicall_space mcs;
> - struct mmu_update *u;
> -
> - trace_xen_mmu_set_domain_pte(ptep, pteval, domid);
> -
> - mcs = xen_mc_entry(sizeof(*u));
> - u = mcs.args;
> -
> - /* ptep might be kmapped when using 32-bit HIGHPTE */
> - u->ptr = virt_to_machine(ptep).maddr;
> - u->val = pte_val_ma(pteval);
> -
> - MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, domid);
> -
> - xen_mc_issue(PARAVIRT_LAZY_MMU);
> -}
> -EXPORT_SYMBOL_GPL(xen_set_domain_pte);
> -
>  static void xen_extend_mmu_update(const struct mmu_update *update)
>  {
>   struct multicall_space mcs;
> diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
> index b70a38b7fa84..677e8ac2bb81 100644
> --- a/include/trace/events/xen.h
> +++ b/include/trace/events/xen.h
> @@ -149,24 +149,6 @@ DECLARE_EVENT_CLASS(xen_mmu__set_pte,
>  DEFINE_XEN_MMU_SET_PTE(xen_mmu_set_pte);
>  DEFINE_XEN_MMU_SET_PTE(xen_mmu_set_pte_atomic);
>  
> -TRACE_EVENT(xen_mmu_set_domain_pte,
> - TP_PROTO(pte_t *ptep, pte_t pteval, unsigned domid),
> - TP_ARGS(ptep, pteval, domid),
> - TP_STRUCT__entry(
> - __field(pte_t *, ptep)
> - __field(pteval_t, pteval)
> - __field(unsigned, domid)
> - ),
> - TP_fast_assign(__entry->ptep = ptep;
> -__entry->pteval = pteval.pte;
> -__entry->domid = domid),
> - TP_printk("ptep %p pteval %0*llx (raw %0*llx) domid %u",
> -   __entry->ptep,
> -   (int)sizeof(pteval_t) * 2, (unsigned long 
> long)pte_val(native_make_pte(__entry->pteval)),
> -   (int)sizeof(pteval_t) * 2, (unsigned long 
> long)__entry->pteval,
> -   __entry->domid)
> - );
> -
>  TRACE_EVENT(xen_mmu_set_pte_at,
>   TP_PROTO(struct mm_struct *mm, unsigned long addr,
>pte_t *ptep, pte_t pteval),


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

Re: [Xen-devel] [PATCH 1/3] xen: remove tests for pvh mode in pure pv paths

[Boris Ostrovsky]

On 08/04/2017 07:36 AM, Juergen Gross wrote:
> Remove the last tests for XENFEAT_auto_translated_physmap in pure
> PV-domain specific paths. PVH V1 is gone and the feature will always
> be "false" in PV guests.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 

I wonder whether the remaining use of this flag can be replaced with
appropriate xen_*_domain()?

-boris


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

[Xen-devel] [PATCH v7 2/2] x86/monitor: Notify monitor if an emulation fails.

[Petre Pircalabu]

If case of a vm_event with the emulate_flags set, if the instruction
is not implemented by the emulator, the monitor should be notified instead
of directly injecting a hw exception.
This behavior can be used to re-execute an instruction not supported by
the emulator using the real processor (e.g. altp2m) instead of just
crashing.

Signed-off-by: Petre Pircalabu 
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_monitor.c  | 14 ++
 xen/arch/x86/hvm/emulate.c|  4 
 xen/arch/x86/hvm/monitor.c| 17 +
 xen/arch/x86/monitor.c| 13 +
 xen/include/asm-x86/domain.h  |  1 +
 xen/include/asm-x86/hvm/monitor.h |  1 +
 xen/include/asm-x86/monitor.h |  3 ++-
 xen/include/public/domctl.h   |  1 +
 xen/include/public/vm_event.h |  2 ++
 10 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c7710b8..abb9cac 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2027,6 +2027,8 @@ int xc_monitor_debug_exceptions(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
 int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
bool enable);
+int xc_monitor_emul_unimplemented(xc_interface *xch, domid_t domain_id,
+  bool enable);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b44ce93..8a76ec1 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -216,6 +216,20 @@ int xc_monitor_privileged_call(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, );
 }
 
+int xc_monitor_emul_unimplemented(xc_interface *xch, domid_t domain_id,
+  bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED;
+
+return do_domctl(xch, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 56056ce..0669b13 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -14,12 +14,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2114,6 +2116,8 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
  */
 return;
 case X86EMUL_UNIMPLEMENTED:
+if ( hvm_monitor_emul_unimplemented() )
+return;
 case X86EMUL_UNHANDLEABLE:
 hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", );
 hvm_inject_hw_exception(trapnr, errcode);
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index a7ccfc4..3551463 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -57,6 +57,23 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
value, unsigned long old
 return 0;
 }
 
+bool hvm_monitor_emul_unimplemented(void)
+{
+struct vcpu *curr = current;
+
+/*
+ * Send a vm_event to the monitor to signal that the current
+ * instruction couldn't be emulated.
+ */
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_EMUL_UNIMPLEMENTED,
+.vcpu_id  = curr->vcpu_id,
+};
+
+return curr->domain->arch.monitor.emul_unimplemented_enabled &&
+monitor_traps(curr, true, ) == 1;
+}
+
 void hvm_monitor_msr(unsigned int msr, uint64_t value)
 {
 struct vcpu *curr = current;
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 706454f..e59f1f5 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -283,6 +283,19 @@ int arch_monitor_domctl_event(struct domain *d,
 break;
 }
 
+case XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED:
+{
+bool old_status = ad->monitor.emul_unimplemented_enabled;
+
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;
+
+domain_pause(d);
+ad->monitor.emul_unimplemented_enabled = requested_status;
+domain_unpause(d);
+break;
+}
+
 default:
 /*
  * Should not be reached unless arch_monitor_get_capabilities() is
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index c10522b..091447d 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -405,6 +405,7 @@ struct arch_domain
 unsigned int debug_exception_sync: 1;
 unsigned int cpuid_enabled   : 1;
 unsigned 

[Xen-devel] [PATCH v7 0/2] Singlestep unimplemented x86emul instructions

[Petre Pircalabu]

This patchset implements a new way of handling the instructions unimplemented
in x86emul. Instead of inserting a hardware exception the monitor will
be notified and it will to try to single-step the faulty instruction using the
real processor and then resume execution of the normal instruction flow.

---
Changed since v1:
  * Removed the emulation kind check when calling hvm_inject_hw_exception

Changed since v2:
  * Removed a file added by mistake

Changed since v3:
  * Removed extra stray line
  * Added the _enabled suffix to the emul_unhandleable monitor option

Changed since v4
  * Fixed return expression of hvm_monitor_emul_unhandleable handle
  monitor_traps failures.
  * Removed stray parantheses.

Changed since v5:
  * Removed unnecessary "else" when calling hvm_monitor_emul_unhandleable.
  * Added extra line in arch_monitor_domctl_event.

Changed since v6:
  * add the distinction between unimplemented instructions and emulation 
failures.
  * changed "emul_unhandleable" event name to "emul_unimplemented"

Petre Pircalabu (2):
  x86emul: New return code for unimplemented instruction
  x86/monitor: Notify monitor if an emulation fails.

 tools/libxc/include/xenctrl.h  |  2 ++
 tools/libxc/xc_monitor.c   | 14 ++
 xen/arch/x86/hvm/emulate.c |  5 +
 xen/arch/x86/hvm/monitor.c | 17 +
 xen/arch/x86/monitor.c | 13 +
 xen/arch/x86/x86_emulate/x86_emulate.c |  2 +-
 xen/arch/x86/x86_emulate/x86_emulate.h |  2 ++
 xen/include/asm-x86/domain.h   |  1 +
 xen/include/asm-x86/hvm/monitor.h  |  1 +
 xen/include/asm-x86/monitor.h  |  3 ++-
 xen/include/public/domctl.h|  1 +
 xen/include/public/vm_event.h  |  2 ++
 12 files changed, 61 insertions(+), 2 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v7 1/2] x86emul: New return code for unimplemented instruction

[Petre Pircalabu]

Enforce the distinction between an instruction not implemented by the emulator
and the failure to emulate that instruction.

Signed-off-by: Petre Pircalabu 
---
 xen/arch/x86/hvm/emulate.c | 1 +
 xen/arch/x86/x86_emulate/x86_emulate.c | 2 +-
 xen/arch/x86/x86_emulate/x86_emulate.h | 2 ++
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 3a8db21..56056ce 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2113,6 +2113,7 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
  * consistent with X86EMUL_RETRY.
  */
 return;
+case X86EMUL_UNIMPLEMENTED:
 case X86EMUL_UNHANDLEABLE:
 hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", );
 hvm_inject_hw_exception(trapnr, errcode);
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 2201852..75be853 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7717,7 +7717,7 @@ x86_emulate(
 
 default:
 cannot_emulate:
-rc = X86EMUL_UNHANDLEABLE;
+rc = X86EMUL_UNIMPLEMENTED;
 goto done;
 }
 
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h 
b/xen/arch/x86/x86_emulate/x86_emulate.h
index 4ddf111..645d923 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -133,6 +133,8 @@ struct x86_emul_fpu_aux {
   * Undefined behavior when used anywhere else.
   */
 #define X86EMUL_DONE   4
+ /* The instruction is not implemented by the emulator. */
+#define X86EMUL_UNIMPLEMENTED  5
 
 /* FPU sub-types which may be requested via ->get_fpu(). */
 enum x86_emulate_fpu_type {
-- 
2.7.4


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

[Xen-devel] [xen-unstable-smoke test] 112448: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 
112402
 test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 112402

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  32e7db7f6fbb91dac1e4e1bbcab4851c4606e0fa
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112402  2017-07-31 21:02:08 Z3 days
Failing since112418  2017-08-03 11:04:58 Z1 days   13 attempts
Testing same since   112448  2017-08-04 16:01:08 Z0 days1 attempts


People who touched revisions under test:
  Andrii Anisov 
  He Chen 
  Ian Jackson 
  Iurii Konovalenko 
  Iurii Mykhalskyi 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Marek Marczykowski-Górecki 
  Praveen Kumar 
  Rusty Bird 
  Sergej Proskurin 
  Stefano Stabellini 
  Wei Liu 
  Xiao Liang 
  xiliang 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Not pushing.

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

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

Re: [Xen-devel] [RFC PATCH 4/4] libxl: support creation and destruction of static shared memory areas

[Zhongze Liu]

Hi Wei,

Thank you for reviewing my patch.

2017-08-04 23:20 GMT+08:00 Wei Liu :
> I skim through this patch and have some questions.
>
> On Fri, Aug 04, 2017 at 10:20:25AM +0800, Zhongze Liu wrote:
>> +
>> +static int libxl__sshm_add_master(libxl__gc *gc, uint32_t domid,
>> +  libxl_static_shm *sshm)
>> +{
>> +int rc, aborting;
>> +char *sshm_path, *dom_path, *dom_role_path;
>> +char *ents[11];
>> +struct xs_permissions noperm;
>> +xs_transaction_t xt = XBT_NULL;
>> +
>> +sshm_path = libxl__xs_get_sshmpath(gc, sshm->id);
>> +dom_path = libxl__xs_get_dompath(gc, domid);
>> +/* the domain should be in xenstore by now */
>> +assert(dom_path);
>> +dom_role_path = GCSPRINTF("%s/static_shm/%s/role", dom_path, sshm->id);
>> +
>> +
>> + retry_transaction:
>> +/* Within the transaction, goto out by default means aborting */
>> +aborting = 1;
>> +rc = libxl__xs_transaction_start(gc, );
>> +if (rc) { goto out; }
>
> if (rc) goto out;

OK. Will remove all the {}. BTW, do I have to place "goto out;" in a newline?

>
>> +
>> +if (NULL == libxl__xs_read(gc, xt, sshm_path)) {
>
> !libxl__xs_read
>
> We don't use "Yoda conditions".

I'll turn all the Yoda conditions into "natural" ones.

>
>> +rc = libxl__xs_write_checked(gc, xt, dom_role_path, "master");
>> +if (rc) { goto out; };
>> +
>> +ents[0] = "master";
>> +ents[1] = GCSPRINTF("%"PRIu32, domid);
>> +ents[2] = "begin";
>> +ents[3] = GCSPRINTF("0x%"PRIx64, sshm->begin);
>> +ents[4] = "end";
>> +ents[5] = GCSPRINTF("0x%"PRIx64, sshm->end);
>> +ents[6] = "prot";
>> +ents[7] = libxl__strdup(gc, libxl_sshm_prot_to_string(sshm->prot));
>> +ents[8] = "cache_policy";
>> +ents[9] = libxl__strdup(gc,
>> +  libxl_sshm_cachepolicy_to_string(sshm->cache_policy));
>> +ents[10] = NULL;
>> +
>
> These aren't going to change from iteration to iteration, so you can
> prepare them before entering the loop.
>
> BTW it would be cleaner to use a for (;;) {} or while (1) {} loop to
> implement this instead of using goto label. You can then eliminate the
> TRY_TRANSACTION_OR_FAIL macro.

OK. I'll move the entries out of the iteration. And yes, using an
infinite loop and
break on appropriate conditions will make it more concise.

>
>> +/* could only be accessed by Dom0 */
>> +noperm.id = 0;
>> +noperm.perms = XS_PERM_NONE;
>> +libxl__xs_mknod(gc, xt, sshm_path, , 1);
>> +libxl__xs_writev(gc, xt, sshm_path, ents);
>> +} else {
>> +SSHM_ERROR(domid, sshm->id, "can only have one master.");
>> +rc = ERROR_FAIL;
>> +goto out;
>> +}
>> +
>> +aborting = rc = 0;
>> +
>> + out:
>> +TRY_TRANSACTION_OR_FAIL(aborting);
>> +return rc;
>> +}
>> +
> [...]
>> +static int libxl__sshm_del_single(libxl__gc *gc, xs_transaction_t xt,
>> +  uint32_t domid, const char *id, bool 
>> master)
>> +{
>> +char *sshm_path, *slaves_path;
>> +
>> +sshm_path = libxl__xs_get_sshmpath(gc, id);
>> +slaves_path = GCSPRINTF("%s/slaves", sshm_path);
>> +
>> +if (master) {
>> +/* we know that domid can't be both a master and a slave for one id,
>
> Is this enforced in code?

Yes...and...no. I've done this in libxl__sshm_add_slave() by doing:

+if (NULL != libxl__xs_read(gc, xt, dom_sshm_path)) {
+SSHM_ERROR(domid, sshm->id,
+   "domain tried to share the same region twice.");
+rc = ERROR_FAIL;
+goto out;
+}

Maybe the comment is a little bit confusing. What I was planning to do is to
place such a check in both *_add_slave() and *_add_master(), so that one
ID can't appear twice within one domain, so that one domain will not be able
to be both a master and a slave.

>
>> + * so the number of slaves won't change during iteration. Simply 
>> check
>> + * sshm_path/slavea to tell if there are still living slaves. */
>> +if (NULL != libxl__xs_read(gc, xt, slaves_path)) {
>> +SSHM_ERROR(domid, id,
>> +   "can't remove master when there are living slaves.");
>> +return ERROR_FAIL;
>
> Isn't this going to leave a half-destructed domain in userspace
> components? Maybe we should proceed anyway?

This is also among the points that I'm not very sure. What is the best way
to handle this type of error during domain destruction?

>
>> +}
>> +libxl__xs_path_cleanup(gc, xt, sshm_path);
>> +} else {
>> +libxl__xs_path_cleanup(gc, xt,
>> +GCSPRINTF("%s/%"PRIu32, slaves_path, domid));
>
> Is this really enough? What will happen to the mapping? You merely
> delete the xenstore node for it but the mapping is still there.
>
> I suppose you're relying on the hypervisor to 

Re: [Xen-devel] [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree

[Praveen Kumar]

I tried applying the patches generated from Linux tree and updating
the file location ( as per the Xen tree location ); some of the
places, I was facing issues.
Adding comment to the file, resolved some of the patching issues. So,
this is my understanding ( could be completely wrong ) that, with the
change in location and difference in code statements, the patch
application have failed. Please suggest if I can perform this is a
better way. Thanks in advance.

On Fri, Aug 4, 2017 at 10:34 PM, Jan Beulich  wrote:
 Praveen Kumar  08/04/17 7:00 PM >>>
>>There will be issue while directly applying the patch from Linux tree
>>( having changed the file name ) as the line number changes.
>
> How do line numbers matter?
>
> Jan
>

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

Re: [Xen-devel] [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree

[Jan Beulich]

>>> Praveen Kumar  08/04/17 7:00 PM >>>
>There will be issue while directly applying the patch from Linux tree
>( having changed the file name ) as the line number changes.

How do line numbers matter?

Jan


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

[Xen-devel] [PATCH v6 5/8] spinlock: Introduce spin_lock_cb()

[Boris Ostrovsky]

While waiting for a lock we may want to periodically run some
code. This code may, for example, allow the caller to release
resources held by it that are no longer needed in the critical
section protected by the lock.

Specifically, this feature will be needed by scrubbing code where
the scrubber, while waiting for heap lock to merge back clean
pages, may be requested by page allocator (which is currently
holding the lock) to abort merging and release the buddy page head
that the allocator wants.

We could use spin_trylock() but since it doesn't take lock ticket
it may take long time until the lock is taken. Instead we add
spin_lock_cb() that allows us to grab the ticket and execute a
callback while waiting. This callback is executed on every iteration
of the spinlock waiting loop.

Since we may be sleeping in the lock until it is released we need a
mechanism that will make sure that the callback has a chance to run.
We add spin_lock_kick() that will wake up the waiter.

Signed-off-by: Boris Ostrovsky 
---
 xen/common/spinlock.c  | 9 -
 xen/include/xen/spinlock.h | 8 
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 2a06406..3c1caae 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -129,7 +129,7 @@ static always_inline u16 observe_head(spinlock_tickets_t *t)
 return read_atomic(>head);
 }
 
-void _spin_lock(spinlock_t *lock)
+void inline _spin_lock_cb(spinlock_t *lock, void (*cb)(void *), void *data)
 {
 spinlock_tickets_t tickets = SPINLOCK_TICKET_INC;
 LOCK_PROFILE_VAR;
@@ -140,6 +140,8 @@ void _spin_lock(spinlock_t *lock)
 while ( tickets.tail != observe_head(>tickets) )
 {
 LOCK_PROFILE_BLOCK;
+if ( unlikely(cb) )
+cb(data);
 arch_lock_relax();
 }
 LOCK_PROFILE_GOT;
@@ -147,6 +149,11 @@ void _spin_lock(spinlock_t *lock)
 arch_lock_acquire_barrier();
 }
 
+void _spin_lock(spinlock_t *lock)
+{
+ _spin_lock_cb(lock, NULL, NULL);
+}
+
 void _spin_lock_irq(spinlock_t *lock)
 {
 ASSERT(local_irq_is_enabled());
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index c1883bd..91bfb95 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -153,6 +153,7 @@ typedef struct spinlock {
 #define spin_lock_init(l) (*(l) = (spinlock_t)SPIN_LOCK_UNLOCKED)
 
 void _spin_lock(spinlock_t *lock);
+void _spin_lock_cb(spinlock_t *lock, void (*cond)(void *), void *data);
 void _spin_lock_irq(spinlock_t *lock);
 unsigned long _spin_lock_irqsave(spinlock_t *lock);
 
@@ -169,6 +170,7 @@ void _spin_lock_recursive(spinlock_t *lock);
 void _spin_unlock_recursive(spinlock_t *lock);
 
 #define spin_lock(l)  _spin_lock(l)
+#define spin_lock_cb(l, c, d) _spin_lock_cb(l, c, d)
 #define spin_lock_irq(l)  _spin_lock_irq(l)
 #define spin_lock_irqsave(l, f) \
 ({  \
@@ -190,6 +192,12 @@ void _spin_unlock_recursive(spinlock_t *lock);
 1 : ({ local_irq_restore(flags); 0; }); \
 })
 
+#define spin_lock_kick(l)   \
+({  \
+smp_mb();   \
+arch_lock_signal(); \
+})
+
 /* Ensure a lock is quiescent between two critical operations. */
 #define spin_barrier(l)   _spin_barrier(l)
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v6 3/8] mm: Scrub pages in alloc_heap_pages() if needed

[Boris Ostrovsky]

When allocating pages in alloc_heap_pages() first look for clean pages. If none
is found then retry, take pages marked as unscrubbed and scrub them.

Note that we shouldn't find unscrubbed pages in alloc_heap_pages() yet. However,
this will become possible when we stop scrubbing from free_heap_pages() and
instead do it from idle loop.

Since not all allocations require clean pages (such as xenheap allocations)
introduce MEMF_no_scrub flag that callers can set if they are willing to
consume unscrubbed pages.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
Changes in v6:
* Dropped unnecessary need_scrub.

 xen/common/page_alloc.c | 33 +
 xen/include/xen/mm.h|  4 +++-
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 6d7422d..eedff2d 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -706,6 +706,7 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 nodemask_t nodemask = d ? d->node_affinity : node_online_map;
 unsigned int j, zone, nodemask_retry = 0;
 struct page_info *pg;
+bool use_unscrubbed = (memflags & MEMF_no_scrub);
 
 if ( node == NUMA_NO_NODE )
 {
@@ -737,8 +738,20 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 
 /* Find smallest order which can satisfy the request. */
 for ( j = order; j <= MAX_ORDER; j++ )
+{
 if ( (pg = page_list_remove_head((node, zone, j))) )
-return pg;
+{
+/*
+ * We grab single pages (order=0) even if they are
+ * unscrubbed. Given that scrubbing one page is fairly 
quick
+ * it is not worth breaking higher orders.
+ */
+if ( (order == 0) || use_unscrubbed ||
+ pg->u.free.first_dirty == INVALID_DIRTY_IDX)
+return pg;
+page_list_add_tail(pg, (node, zone, j));
+}
+}
 } while ( zone-- > zone_lo ); /* careful: unsigned zone may wrap */
 
 if ( (memflags & MEMF_exact_node) && req_node != NUMA_NO_NODE )
@@ -822,6 +835,10 @@ static struct page_info *alloc_heap_pages(
 }
 
 pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d);
+/* Try getting a dirty buddy if we couldn't get a clean one. */
+if ( !pg && !(memflags & MEMF_no_scrub) )
+pg = get_free_buddy(zone_lo, zone_hi, order,
+memflags | MEMF_no_scrub, d);
 if ( !pg )
 {
 /* No suitable memory blocks. Fail the request. */
@@ -867,7 +884,15 @@ static struct page_info *alloc_heap_pages(
 for ( i = 0; i < (1 << order); i++ )
 {
 /* Reference count must continuously be zero for free pages. */
-BUG_ON(pg[i].count_info != PGC_state_free);
+BUG_ON((pg[i].count_info & ~PGC_need_scrub) != PGC_state_free);
+
+if ( test_bit(_PGC_need_scrub, [i].count_info) )
+{
+if ( !(memflags & MEMF_no_scrub) )
+scrub_one_page([i]);
+node_need_scrub[node]--;
+}
+
 pg[i].count_info = PGC_state_inuse;
 
 if ( !(memflags & MEMF_no_tlbflush) )
@@ -1751,7 +1776,7 @@ void *alloc_xenheap_pages(unsigned int order, unsigned 
int memflags)
 ASSERT(!in_irq());
 
 pg = alloc_heap_pages(MEMZONE_XEN, MEMZONE_XEN,
-  order, memflags, NULL);
+  order, memflags | MEMF_no_scrub, NULL);
 if ( unlikely(pg == NULL) )
 return NULL;
 
@@ -1801,7 +1826,7 @@ void *alloc_xenheap_pages(unsigned int order, unsigned 
int memflags)
 if ( !(memflags >> _MEMF_bits) )
 memflags |= MEMF_bits(xenheap_bits);
 
-pg = alloc_domheap_pages(NULL, order, memflags);
+pg = alloc_domheap_pages(NULL, order, memflags | MEMF_no_scrub);
 if ( unlikely(pg == NULL) )
 return NULL;
 
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 503b92e..e1f9c42 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -248,7 +248,9 @@ struct npfec {
 #define  MEMF_no_tlbflush (1U<<_MEMF_no_tlbflush)
 #define _MEMF_no_icache_flush 7
 #define  MEMF_no_icache_flush (1U<<_MEMF_no_icache_flush)
-#define _MEMF_node8
+#define _MEMF_no_scrub8
+#define  MEMF_no_scrub(1U<<_MEMF_no_scrub)
+#define _MEMF_node16
 #define  MEMF_node_mask   ((1U << (8 * sizeof(nodeid_t))) - 1)
 #define  MEMF_node(n) n) + 1) & MEMF_node_mask) << _MEMF_node)
 #define  MEMF_get_node(f) f) >> _MEMF_node) - 1) & MEMF_node_mask)
-- 
1.8.3.1


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

[Xen-devel] [PATCH v6 0/8] Memory scrubbing from idle loop

[Boris Ostrovsky]

Changes in v6:
* Changed first_dirty tracking from pointer-based to index-based (patch 1)
* Added/modified a few ASSERT()s
* Moved/modifed a couple of comments
* Adjusted width of INVALID_DIRTY_IDX

(see per-patch changes)

When a domain is destroyed the hypervisor must scrub domain's pages before
giving them to another guest in order to prevent leaking the deceased
guest's data. Currently this is done during guest's destruction, possibly
causing very lengthy cleanup process.

This series adds support for scrubbing released pages from idle loop,
making guest destruction significantly faster. For example, destroying a
1TB guest can now be completed in 40+ seconds as opposed to about 9 minutes
using existing scrubbing algorithm.

Briefly, the new algorithm places dirty pages at the end of heap's page list
for each node/zone/order to avoid having to scan full list while searching
for dirty pages. One processor form each node checks whether the node has any
dirty pages and, if such pages are found, scrubs them. Scrubbing itself
happens without holding heap lock so other users may access heap in the
meantime. If while idle loop is scrubbing a particular chunk of pages this
chunk is requested by the heap allocator, scrubbing is immediately stopped.

On the allocation side, alloc_heap_pages() first tries to satisfy allocation
request using only clean pages. If this is not possible, the search is
repeated and dirty pages are scrubbed by the allocator.

This series is somewhat based on earlier work by Bob Liu.

V1:
* Only set PGC_need_scrub bit for the buddy head, thus making it unnecessary
  to scan whole buddy
* Fix spin_lock_cb()
* Scrub CPU-less nodes
* ARM support. Note that I have not been able to test this, only built the
  binary
* Added scrub test patch (last one). Not sure whether it should be considered
  for committing but I have been running with it.

V2:
* merge_chunks() returns new buddy head
* scrub_free_pages() returns softirq pending status in addition to (factored 
out)
  status of unscrubbed memory
* spin_lock uses inlined spin_lock_cb()
* scrub debugging code checks whole page, not just the first word.

V3:
* Keep dirty bit per page
* Simplify merge_chunks() (now merge_and_free_buddy())
* When scrubbing memmory-only nodes try to find the closest node.

V4:
* Keep track of dirty pages in a buddy with page_info.u.free.first_dirty.
* Drop patch 1 (factoring out merge_and_free_buddy()) since there is only
  one caller now
* Drop patch patch 5 (from V3) since we are not breaking partially-scrubbed
  buddy anymore
* Extract search loop in alloc_heap_pages() into get_free_buddy() (patch 2)
* Add MEMF_no_scrub flag

V5:
* Make page_info.u.free and union and use bitfields there.
* Bug fixes


Deferred:
* Per-node heap locks. In addition to (presumably) improving performance in
  general, once they are available we can parallelize scrubbing further by
  allowing more than one core per node to do idle loop scrubbing.
* AVX-based scrubbing
* Use idle loop scrubbing during boot.


Boris Ostrovsky (8):
  mm: Place unscrubbed pages at the end of pagelist
  mm: Extract allocation loop from alloc_heap_pages()
  mm: Scrub pages in alloc_heap_pages() if needed
  mm: Scrub memory from idle loop
  spinlock: Introduce spin_lock_cb()
  mm: Keep heap accessible to others while scrubbing
  mm: Print number of unscrubbed pages in 'H' debug handler
  mm: Make sure pages are scrubbed

 xen/Kconfig.debug  |   7 +
 xen/arch/arm/domain.c  |   8 +-
 xen/arch/x86/domain.c  |   8 +-
 xen/arch/x86/domain_page.c |   6 +-
 xen/common/page_alloc.c| 616 ++---
 xen/common/spinlock.c  |   9 +-
 xen/include/asm-arm/mm.h   |  30 ++-
 xen/include/asm-x86/mm.h   |  30 ++-
 xen/include/xen/mm.h   |   5 +-
 xen/include/xen/spinlock.h |   8 +
 10 files changed, 621 insertions(+), 106 deletions(-)

-- 
1.8.3.1


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

[Xen-devel] [PATCH v6 4/8] mm: Scrub memory from idle loop

[Boris Ostrovsky]

Instead of scrubbing pages during guest destruction (from
free_heap_pages()) do this opportunistically, from the idle loop.

We might come to scrub_free_pages()from idle loop while another CPU
uses mapcache override, resulting in a fault while trying to do
__map_domain_page() in scrub_one_page(). To avoid this, make mapcache
vcpu override a per-cpu variable.

Signed-off-by: Boris Ostrovsky 
---
CC: Dario Faggioli 
---
Changes in v6:
* Moved final softirq_pending() test from scrub_free_pages() to idle loop.


 xen/arch/arm/domain.c  |   8 ++-
 xen/arch/x86/domain.c  |   8 ++-
 xen/arch/x86/domain_page.c |   6 +--
 xen/common/page_alloc.c| 119 -
 xen/include/xen/mm.h   |   1 +
 5 files changed, 124 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2dc8b0a..d7961bb 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -51,7 +51,13 @@ void idle_loop(void)
 /* Are we here for running vcpu context tasklets, or for idling? */
 if ( unlikely(tasklet_work_to_do(cpu)) )
 do_tasklet();
-else
+/*
+ * Test softirqs twice --- first to see if should even try scrubbing
+ * and then, after it is done, whether softirqs became pending
+ * while we were scrubbing.
+ */
+else if ( !softirq_pending(cpu) && !scrub_free_pages() &&
+!softirq_pending(cpu) )
 {
 local_irq_disable();
 if ( cpu_is_haltable(cpu) )
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index baaf815..9b4b959 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -122,7 +122,13 @@ static void idle_loop(void)
 /* Are we here for running vcpu context tasklets, or for idling? */
 if ( unlikely(tasklet_work_to_do(cpu)) )
 do_tasklet();
-else
+/*
+ * Test softirqs twice --- first to see if should even try scrubbing
+ * and then, after it is done, whether softirqs became pending
+ * while we were scrubbing.
+ */
+else if ( !softirq_pending(cpu) && !scrub_free_pages()  &&
+!softirq_pending(cpu) )
 pm_idle();
 do_softirq();
 /*
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 71baede..0783c1e 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -18,12 +18,12 @@
 #include 
 #include 
 
-static struct vcpu *__read_mostly override;
+static DEFINE_PER_CPU(struct vcpu *, override);
 
 static inline struct vcpu *mapcache_current_vcpu(void)
 {
 /* In the common case we use the mapcache of the running VCPU. */
-struct vcpu *v = override ?: current;
+struct vcpu *v = this_cpu(override) ?: current;
 
 /*
  * When current isn't properly set up yet, this is equivalent to
@@ -59,7 +59,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
 
 void __init mapcache_override_current(struct vcpu *v)
 {
-override = v;
+this_cpu(override) = v;
 }
 
 #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index eedff2d..3f04f16 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1024,15 +1024,86 @@ static int reserve_offlined_page(struct page_info *head)
 return count;
 }
 
-static void scrub_free_pages(unsigned int node)
+static nodemask_t node_scrubbing;
+
+/*
+ * If get_node is true this will return closest node that needs to be scrubbed,
+ * with appropriate bit in node_scrubbing set.
+ * If get_node is not set, this will return *a* node that needs to be scrubbed.
+ * node_scrubbing bitmask will no be updated.
+ * If no node needs scrubbing then NUMA_NO_NODE is returned.
+ */
+static unsigned int node_to_scrub(bool get_node)
 {
-struct page_info *pg;
-unsigned int zone;
+nodeid_t node = cpu_to_node(smp_processor_id()), local_node;
+nodeid_t closest = NUMA_NO_NODE;
+u8 dist, shortest = 0xff;
 
-ASSERT(spin_is_locked(_lock));
+if ( node == NUMA_NO_NODE )
+node = 0;
 
-if ( !node_need_scrub[node] )
-return;
+if ( node_need_scrub[node] &&
+ (!get_node || !node_test_and_set(node, node_scrubbing)) )
+return node;
+
+/*
+ * See if there are memory-only nodes that need scrubbing and choose
+ * the closest one.
+ */
+local_node = node;
+for ( ; ; )
+{
+do {
+node = cycle_node(node, node_online_map);
+} while ( !cpumask_empty(_to_cpumask(node)) &&
+  (node != local_node) );
+
+if ( node == local_node )
+break;
+
+if ( node_need_scrub[node] )
+{
+if ( !get_node )
+return node;
+
+dist = __node_distance(local_node, node);
+
+/*
+ * Grab the 

[Xen-devel] [PATCH v6 6/8] mm: Keep heap accessible to others while scrubbing

[Boris Ostrovsky]

Instead of scrubbing pages while holding heap lock we can mark
buddy's head as being scrubbed and drop the lock temporarily.
If someone (most likely alloc_heap_pages()) tries to access
this chunk it will signal the scrubber to abort scrub by setting
head's BUDDY_SCRUB_ABORT bit. The scrubber checks this bit after
processing each page and stops its work as soon as it sees it.

Signed-off-by: Boris Ostrovsky 
---
Changes in v6:
* Made ASSERT explicitly test for  BUDDY_NOT_SCRUBBING.
* Added a comment explaining why we set buddy's first_dirty in the lock's 
callback.

 xen/common/page_alloc.c  | 111 +--
 xen/include/asm-arm/mm.h |  26 +++
 xen/include/asm-x86/mm.h |  27 
 3 files changed, 142 insertions(+), 22 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 3f04f16..e0bbc27 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -687,6 +687,7 @@ static void page_list_add_scrub(struct page_info *pg, 
unsigned int node,
 {
 PFN_ORDER(pg) = order;
 pg->u.free.first_dirty = first_dirty;
+pg->u.free.scrub_state = BUDDY_NOT_SCRUBBING;
 
 if ( first_dirty != INVALID_DIRTY_IDX )
 {
@@ -697,6 +698,25 @@ static void page_list_add_scrub(struct page_info *pg, 
unsigned int node,
 page_list_add(pg, (node, zone, order));
 }
 
+static void check_and_stop_scrub(struct page_info *head)
+{
+if ( head->u.free.scrub_state == BUDDY_SCRUBBING )
+{
+struct page_info pg;
+
+head->u.free.scrub_state = BUDDY_SCRUB_ABORT;
+spin_lock_kick();
+for ( ; ; )
+{
+/* Can't ACCESS_ONCE() a bitfield. */
+pg.u.free.val = ACCESS_ONCE(head->u.free.val);
+if ( pg.u.free.scrub_state != BUDDY_SCRUB_ABORT )
+break;
+cpu_relax();
+}
+}
+}
+
 static struct page_info *get_free_buddy(unsigned int zone_lo,
 unsigned int zone_hi,
 unsigned int order, unsigned int 
memflags,
@@ -741,14 +761,19 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 {
 if ( (pg = page_list_remove_head((node, zone, j))) )
 {
+if ( pg->u.free.first_dirty == INVALID_DIRTY_IDX )
+return pg;
 /*
  * We grab single pages (order=0) even if they are
  * unscrubbed. Given that scrubbing one page is fairly 
quick
  * it is not worth breaking higher orders.
  */
-if ( (order == 0) || use_unscrubbed ||
- pg->u.free.first_dirty == INVALID_DIRTY_IDX)
+if ( (order == 0) || use_unscrubbed )
+{
+check_and_stop_scrub(pg);
 return pg;
+}
+
 page_list_add_tail(pg, (node, zone, j));
 }
 }
@@ -929,6 +954,7 @@ static int reserve_offlined_page(struct page_info *head)
 
 cur_head = head;
 
+check_and_stop_scrub(head);
 /*
  * We may break the buddy so let's mark the head as clean. Then, when
  * merging chunks back into the heap, we will see whether the chunk has
@@ -1090,6 +1116,29 @@ static unsigned int node_to_scrub(bool get_node)
 return closest;
 }
 
+struct scrub_wait_state {
+struct page_info *pg;
+unsigned int first_dirty;
+bool drop;
+};
+
+static void scrub_continue(void *data)
+{
+struct scrub_wait_state *st = data;
+
+if ( st->drop )
+return;
+
+if ( st->pg->u.free.scrub_state == BUDDY_SCRUB_ABORT )
+{
+/* There is a waiter for this buddy. Release it. */
+st->drop = true;
+st->pg->u.free.first_dirty = st->first_dirty;
+smp_wmb();
+st->pg->u.free.scrub_state = BUDDY_NOT_SCRUBBING;
+}
+}
+
 bool scrub_free_pages(void)
 {
 struct page_info *pg;
@@ -1112,25 +1161,53 @@ bool scrub_free_pages(void)
 do {
 while ( !page_list_empty((node, zone, order)) )
 {
-unsigned int i;
+unsigned int i, dirty_cnt;
+struct scrub_wait_state st;
 
 /* Unscrubbed pages are always at the end of the list. */
 pg = page_list_last((node, zone, order));
 if ( pg->u.free.first_dirty == INVALID_DIRTY_IDX )
 break;
 
+ASSERT(pg->u.free.scrub_state == BUDDY_NOT_SCRUBBING);
+pg->u.free.scrub_state = BUDDY_SCRUBBING;
+
+spin_unlock(_lock);
+
+dirty_cnt = 0;
+
 for ( i = pg->u.free.first_dirty; i < (1U << order); i++)
 {
 if ( test_bit(_PGC_need_scrub, [i].count_info) )
 {
  

[Xen-devel] [PATCH v6 8/8] mm: Make sure pages are scrubbed

[Boris Ostrovsky]

Add a debug Kconfig option that will make page allocator verify
that pages that were supposed to be scrubbed are, in fact, clean.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 xen/Kconfig.debug   |  7 ++
 xen/common/page_alloc.c | 63 -
 2 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 689f297..195d504 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -114,6 +114,13 @@ config DEVICE_TREE_DEBUG
  logged in the Xen ring buffer.
  If unsure, say N here.
 
+config SCRUB_DEBUG
+   bool "Page scrubbing test"
+   default DEBUG
+   ---help---
+ Verify that pages that need to be scrubbed before being allocated to
+ a guest are indeed scrubbed.
+
 endif # DEBUG || EXPERT
 
 endmenu
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 7cd736c..aac1ff2 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -170,6 +170,10 @@ boolean_param("bootscrub", opt_bootscrub);
 static unsigned long __initdata opt_bootscrub_chunk = MB(128);
 size_param("bootscrub_chunk", opt_bootscrub_chunk);
 
+#ifdef CONFIG_SCRUB_DEBUG
+static bool __read_mostly boot_scrub_done;
+#endif
+
 /*
  * Bit width of the DMA heap -- used to override NUMA-node-first.
  * allocation strategy, which can otherwise exhaust low memory.
@@ -698,6 +702,43 @@ static void page_list_add_scrub(struct page_info *pg, 
unsigned int node,
 page_list_add(pg, (node, zone, order));
 }
 
+/* SCRUB_PATTERN needs to be a repeating series of bytes. */
+#ifndef NDEBUG
+#define SCRUB_PATTERN0xc2c2c2c2c2c2c2c2ULL
+#else
+#define SCRUB_PATTERN0ULL
+#endif
+#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
+
+static void poison_one_page(struct page_info *pg)
+{
+#ifdef CONFIG_SCRUB_DEBUG
+mfn_t mfn = _mfn(page_to_mfn(pg));
+uint64_t *ptr;
+
+ptr = map_domain_page(mfn);
+*ptr = ~SCRUB_PATTERN;
+unmap_domain_page(ptr);
+#endif
+}
+
+static void check_one_page(struct page_info *pg)
+{
+#ifdef CONFIG_SCRUB_DEBUG
+mfn_t mfn = _mfn(page_to_mfn(pg));
+const uint64_t *ptr;
+unsigned int i;
+
+if ( !boot_scrub_done )
+return;
+
+ptr = map_domain_page(mfn);
+for ( i = 0; i < PAGE_SIZE / sizeof (*ptr); i++ )
+ASSERT(ptr[i] == SCRUB_PATTERN);
+unmap_domain_page(ptr);
+#endif
+}
+
 static void check_and_stop_scrub(struct page_info *head)
 {
 if ( head->u.free.scrub_state == BUDDY_SCRUBBING )
@@ -932,6 +973,9 @@ static struct page_info *alloc_heap_pages(
  * guest can control its own visibility of/through the cache.
  */
 flush_page_to_ram(page_to_mfn([i]), !(memflags & 
MEMF_no_icache_flush));
+
+if ( !(memflags & MEMF_no_scrub) )
+check_one_page([i]);
 }
 
 spin_unlock(_lock);
@@ -1306,7 +1350,10 @@ static void free_heap_pages(
 set_gpfn_from_mfn(mfn + i, INVALID_M2P_ENTRY);
 
 if ( need_scrub )
+{
 pg[i].count_info |= PGC_need_scrub;
+poison_one_page([i]);
+}
 }
 
 avail[node][zone] += 1 << order;
@@ -1664,7 +1711,12 @@ static void init_heap_pages(
 nr_pages -= n;
 }
 
+#ifndef CONFIG_SCRUB_DEBUG
 free_heap_pages(pg + i, 0, false);
+#else
+free_heap_pages(pg + i, 0, boot_scrub_done);
+#endif
+   
 }
 }
 
@@ -1930,6 +1982,10 @@ void __init scrub_heap_pages(void)
 
 printk("done.\n");
 
+#ifdef CONFIG_SCRUB_DEBUG
+boot_scrub_done = true;
+#endif
+
 /* Now that the heap is initialized, run checks and set bounds
  * for the low mem virq algorithm. */
 setup_low_mem_virq();
@@ -2203,12 +2259,16 @@ void free_domheap_pages(struct page_info *pg, unsigned 
int order)
 
 spin_unlock_recursive(>page_alloc_lock);
 
+#ifndef CONFIG_SCRUB_DEBUG
 /*
  * Normally we expect a domain to clear pages before freeing them,
  * if it cares about the secrecy of their contents. However, after
  * a domain has died we assume responsibility for erasure.
  */
 scrub = !!d->is_dying;
+#else
+scrub = true;
+#endif
 }
 else
 {
@@ -2300,7 +2360,8 @@ void scrub_one_page(struct page_info *pg)
 
 #ifndef NDEBUG
 /* Avoid callers relying on allocations returning zeroed pages. */
-unmap_domain_page(memset(__map_domain_page(pg), 0xc2, PAGE_SIZE));
+unmap_domain_page(memset(__map_domain_page(pg),
+ SCRUB_BYTE_PATTERN, PAGE_SIZE));
 #else
 /* For a production build, clear_page() is the fastest way to scrub. */
 clear_domain_page(_mfn(page_to_mfn(pg)));
-- 
1.8.3.1


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

[Xen-devel] [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist

[Boris Ostrovsky]

. so that it's easy to find pages that need to be scrubbed (those pages are
now marked with _PGC_need_scrub bit).

We keep track of the first unscrubbed page in a page buddy using first_dirty
field. For now it can have two values, 0 (whole buddy needs scrubbing) or
INVALID_DIRTY_IDX (the buddy does not need to be scrubbed). Subsequent patches
will allow scrubbing to be interrupted, resulting in first_dirty taking any
value.

Signed-off-by: Boris Ostrovsky 
---
Changes in v6:
* Track indexes and not pointers in alloc_heap_pages() and 
reserve_offlined_page()
  when breaking a potentially dirty buddy and merging the fragments.
* Reduced (by one bit) width of INVALID_DIRTY_IDX
* Added a coupe of ASSERT()s

 xen/common/page_alloc.c  | 194 ++-
 xen/include/asm-arm/mm.h |  18 -
 xen/include/asm-x86/mm.h |  17 -
 3 files changed, 193 insertions(+), 36 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 8bcef6a..9e787e0 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -383,6 +383,8 @@ typedef struct page_list_head 
heap_by_zone_and_order_t[NR_ZONES][MAX_ORDER+1];
 static heap_by_zone_and_order_t *_heap[MAX_NUMNODES];
 #define heap(node, zone, order) ((*_heap[node])[zone][order])
 
+static unsigned long node_need_scrub[MAX_NUMNODES];
+
 static unsigned long *avail[MAX_NUMNODES];
 static long total_avail_pages;
 
@@ -678,13 +680,30 @@ static void check_low_mem_virq(void)
 }
 }
 
+/* Pages that need a scrub are added to tail, otherwise to head. */
+static void page_list_add_scrub(struct page_info *pg, unsigned int node,
+unsigned int zone, unsigned int order,
+unsigned int first_dirty)
+{
+PFN_ORDER(pg) = order;
+pg->u.free.first_dirty = first_dirty;
+
+if ( first_dirty != INVALID_DIRTY_IDX )
+{
+ASSERT(first_dirty < (1U << order));
+page_list_add_tail(pg, (node, zone, order));
+}
+else
+page_list_add(pg, (node, zone, order));
+}
+
 /* Allocate 2^@order contiguous pages. */
 static struct page_info *alloc_heap_pages(
 unsigned int zone_lo, unsigned int zone_hi,
 unsigned int order, unsigned int memflags,
 struct domain *d)
 {
-unsigned int i, j, zone = 0, nodemask_retry = 0;
+unsigned int i, j, zone = 0, nodemask_retry = 0, first_dirty;
 nodeid_t first_node, node = MEMF_get_node(memflags), req_node = node;
 unsigned long request = 1UL << order;
 struct page_info *pg;
@@ -798,12 +817,26 @@ static struct page_info *alloc_heap_pages(
 return NULL;
 
  found: 
+
+first_dirty = pg->u.free.first_dirty;
+
 /* We may have to halve the chunk a number of times. */
 while ( j != order )
 {
-PFN_ORDER(pg) = --j;
-page_list_add_tail(pg, (node, zone, j));
-pg += 1 << j;
+j--;
+page_list_add_scrub(pg, node, zone, j,
+(1U << j) > first_dirty ?
+first_dirty : INVALID_DIRTY_IDX);
+pg += 1U << j;
+
+if ( first_dirty != INVALID_DIRTY_IDX )
+{
+/* Adjust first_dirty */
+if ( first_dirty >= 1U << j )
+first_dirty -= 1U << j;
+else
+first_dirty = 0; /* We've moved past original first_dirty */
+}
 }
 
 ASSERT(avail[node][zone] >= request);
@@ -850,12 +883,20 @@ static int reserve_offlined_page(struct page_info *head)
 unsigned int node = phys_to_nid(page_to_maddr(head));
 int zone = page_to_zone(head), i, head_order = PFN_ORDER(head), count = 0;
 struct page_info *cur_head;
-int cur_order;
+unsigned int cur_order, first_dirty;
 
 ASSERT(spin_is_locked(_lock));
 
 cur_head = head;
 
+/*
+ * We may break the buddy so let's mark the head as clean. Then, when
+ * merging chunks back into the heap, we will see whether the chunk has
+ * unscrubbed pages and set its first_dirty properly.
+ */
+first_dirty = head->u.free.first_dirty;
+head->u.free.first_dirty = INVALID_DIRTY_IDX;
+
 page_list_del(head, (node, zone, head_order));
 
 while ( cur_head < (head + (1 << head_order)) )
@@ -866,6 +907,8 @@ static int reserve_offlined_page(struct page_info *head)
 if ( page_state_is(cur_head, offlined) )
 {
 cur_head++;
+if ( first_dirty != INVALID_DIRTY_IDX && first_dirty )
+first_dirty--;
 continue;
 }
 
@@ -873,6 +916,8 @@ static int reserve_offlined_page(struct page_info *head)
 
 while ( cur_order < head_order )
 {
+unsigned int idx = INVALID_DIRTY_IDX;
+
 next_order = cur_order + 1;
 
 if ( (cur_head + (1 << next_order)) >= (head + ( 1 << head_order)) 
)
@@ -892,8 +937,28 @@ static int reserve_offlined_page(struct page_info *head)
 {
 merge:
   

[Xen-devel] [PATCH v6 7/8] mm: Print number of unscrubbed pages in 'H' debug handler

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Wei Liu 
---
 xen/common/page_alloc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index e0bbc27..7cd736c 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2323,6 +2323,13 @@ static void dump_heap(unsigned char key)
 printk("heap[node=%d][zone=%d] -> %lu pages\n",
i, j, avail[i][j]);
 }
+
+for ( i = 0; i < MAX_NUMNODES; i++ )
+{
+if ( !node_need_scrub[i] )
+continue;
+printk("Node %d has %lu unscrubbed pages\n", i, node_need_scrub[i]);
+}
 }
 
 static __init int register_heap_trigger(void)
-- 
1.8.3.1


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

[Xen-devel] [PATCH v6 2/8] mm: Extract allocation loop from alloc_heap_pages()

[Boris Ostrovsky]

This will make code a bit more readable, especially with changes that
will be introduced in subsequent patches.

Signed-off-by: Boris Ostrovsky 
---
Changes in v6:
* Rebased due to changes in the first patch (thus dropped Jan's ACK)

 xen/common/page_alloc.c | 139 +++-
 1 file changed, 77 insertions(+), 62 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 9e787e0..6d7422d 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -697,22 +697,15 @@ static void page_list_add_scrub(struct page_info *pg, 
unsigned int node,
 page_list_add(pg, (node, zone, order));
 }
 
-/* Allocate 2^@order contiguous pages. */
-static struct page_info *alloc_heap_pages(
-unsigned int zone_lo, unsigned int zone_hi,
-unsigned int order, unsigned int memflags,
-struct domain *d)
+static struct page_info *get_free_buddy(unsigned int zone_lo,
+unsigned int zone_hi,
+unsigned int order, unsigned int 
memflags,
+const struct domain *d)
 {
-unsigned int i, j, zone = 0, nodemask_retry = 0, first_dirty;
 nodeid_t first_node, node = MEMF_get_node(memflags), req_node = node;
-unsigned long request = 1UL << order;
+nodemask_t nodemask = d ? d->node_affinity : node_online_map;
+unsigned int j, zone, nodemask_retry = 0;
 struct page_info *pg;
-nodemask_t nodemask = (d != NULL ) ? d->node_affinity : node_online_map;
-bool_t need_tlbflush = 0;
-uint32_t tlbflush_timestamp = 0;
-
-/* Make sure there are enough bits in memflags for nodeID. */
-BUILD_BUG_ON((_MEMF_bits - _MEMF_node) < (8 * sizeof(nodeid_t)));
 
 if ( node == NUMA_NO_NODE )
 {
@@ -728,34 +721,6 @@ static struct page_info *alloc_heap_pages(
 first_node = node;
 
 ASSERT(node < MAX_NUMNODES);
-ASSERT(zone_lo <= zone_hi);
-ASSERT(zone_hi < NR_ZONES);
-
-if ( unlikely(order > MAX_ORDER) )
-return NULL;
-
-spin_lock(_lock);
-
-/*
- * Claimed memory is considered unavailable unless the request
- * is made by a domain with sufficient unclaimed pages.
- */
-if ( (outstanding_claims + request >
-  total_avail_pages + tmem_freeable_pages()) &&
-  ((memflags & MEMF_no_refcount) ||
-   !d || d->outstanding_pages < request) )
-goto not_found;
-
-/*
- * TMEM: When available memory is scarce due to tmem absorbing it, allow
- * only mid-size allocations to avoid worst of fragmentation issues.
- * Others try tmem pools then fail.  This is a workaround until all
- * post-dom0-creation-multi-page allocations can be eliminated.
- */
-if ( ((order == 0) || (order >= 9)) &&
- (total_avail_pages <= midsize_alloc_zone_pages) &&
- tmem_freeable_pages() )
-goto try_tmem;
 
 /*
  * Start with requested node, but exhaust all node memory in requested 
@@ -767,17 +732,17 @@ static struct page_info *alloc_heap_pages(
 zone = zone_hi;
 do {
 /* Check if target node can support the allocation. */
-if ( !avail[node] || (avail[node][zone] < request) )
+if ( !avail[node] || (avail[node][zone] < (1UL << order)) )
 continue;
 
 /* Find smallest order which can satisfy the request. */
 for ( j = order; j <= MAX_ORDER; j++ )
 if ( (pg = page_list_remove_head((node, zone, j))) )
-goto found;
+return pg;
 } while ( zone-- > zone_lo ); /* careful: unsigned zone may wrap */
 
 if ( (memflags & MEMF_exact_node) && req_node != NUMA_NO_NODE )
-goto not_found;
+return NULL;
 
 /* Pick next node. */
 if ( !node_isset(node, nodemask) )
@@ -794,46 +759,96 @@ static struct page_info *alloc_heap_pages(
 {
 /* When we have tried all in nodemask, we fall back to others. */
 if ( (memflags & MEMF_exact_node) || nodemask_retry++ )
-goto not_found;
+return NULL;
 nodes_andnot(nodemask, node_online_map, nodemask);
 first_node = node = first_node(nodemask);
 if ( node >= MAX_NUMNODES )
-goto not_found;
+return NULL;
 }
 }
+}
+
+/* Allocate 2^@order contiguous pages. */
+static struct page_info *alloc_heap_pages(
+unsigned int zone_lo, unsigned int zone_hi,
+unsigned int order, unsigned int memflags,
+struct domain *d)
+{
+nodeid_t node;
+unsigned int i, buddy_order, zone, first_dirty;
+unsigned long request = 1UL << order;
+struct page_info *pg;
+bool need_tlbflush = false;
+uint32_t tlbflush_timestamp = 0;
+
+/* Make sure there are enough bits in memflags for nodeID. */
+BUILD_BUG_ON((_MEMF_bits - 

Re: [Xen-devel] [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree

[Praveen Kumar]

Hi Dario,

On Thu, Aug 3, 2017 at 4:07 PM, Dario Faggioli
 wrote:
> On Fri, 2017-07-14 at 07:05 -0600, Jan Beulich wrote:
>> > > > On 14.07.17 at 14:51,  wrote:
>> >
>> > Agreed, I shouldn't have added.
>> > rbtree.h file does include incline functions which are actually
>> > commented, and in order to have complete similarity I did include
>> > the
>> > same here.
>> >
>> > Also, rbtree.c does have comment in header note being modified, for
>> > the
>> > same reason.
>> >
>> > Further, do you suggest to keep the old ones, but that may cause
>> > porting issue and it won't be exact replica from Linux base. Please
>> > suggest.
>>
>> I'm fine with comment updates, _as long as you say so_ in the
>> commit message. If you say "only style changes", then there
>> ought to be no additions whatsoever.
>>
> I fully agree with Jan.
>
> And, as him, I also think you can update the header comments at the
> beginning of both rbtree.c and rbtree.h files, as soon as you mention
> that in the changelog.
>

Sure, will try to update with each patch individually in the header
comments ( if there are any version change ).

> *HOWEVER*, about this change, in both .c and .h:
>
> @@ -14,7 +14,8 @@
>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 .
> +  along with this program; if not, write to the Free Software
> +  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>
>linux/lib/rbtree.c
>  */
>
> This comes from 443701ef "Replace FSF street address with canonical
> URL" (check with `git blame xen/common/rbtree.c'), and I think we
> should leave this alone (i.e., keep the url, and not change back to the
> physical address).
>
> I understand it then will be a difference between our rbtree.{c,h} and
> Linux's ones, but I think it's one difference it's worth living with
> (and, honestly, I really don't expect this specific thing to cause much
> issues in future 'backports' from Linux).
>
> If others agree on this too, that would mean you basically would let
> the header comment of rbtree.c alone, while in rbtree.h, you "just" add
> the commented API usage example functions.
>

There will be issue while directly applying the patch from Linux tree
( having changed the file name ) as the line number changes. Because
of which I included the commented code. Further to this, for some of
the patches shared, I was also facing porting issue with and has been
manually ported. So, I am thinking if maintaining complete accuracy /
replica with Linux tree will give any benefit ?

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

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

Re: [Xen-devel] [Patch for staging 2/2] x86: remove an ASSERT to avoid crash when destroy a domain.

[Jan Beulich]

>>> Yi Sun  08/04/17 11:45 AM >>>
>--- a/xen/arch/x86/psr.c
>+++ b/xen/arch/x86/psr.c
>@@ -1294,9 +1294,7 @@ static void psr_free_cos(struct domain *d)
>{
>unsigned int socket, cos;
 >
>- ASSERT(socket_info);
>-
>-if ( !d->arch.psr_cos_ids )
>+if ( !d->arch.psr_cos_ids || !psr_alloc_feat_enabled() )
>return;
 
Isn't it rather that you want to move the ASSERT() past this check? I don't see
why you need both checks, as d->arch.psr_cos_ids is only being allocated if
psr_alloc_feat_enabled() returns true.

Jan


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

Re: [Xen-devel] [PATCH v2 2/3] x86/vlapic: Keep timer running when switching between one-shot and periodic mode

[Anthony PERARD]

On Fri, Aug 04, 2017 at 09:48:59AM -0600, Jan Beulich wrote:
> >> Anthony PERARD  08/04/17 1:38 PM >>>
> >On Thu, Aug 03, 2017 at 09:21:57AM -0600, Jan Beulich wrote:
> >> >>> Anthony PERARD  07/18/17 7:12 PM >>>
> >> >@@ -818,6 +840,7 @@ static void vlapic_reg_write(struct vcpu *v,
> >> >if ( !vlapic_lvtt_oneshot(vlapic) && !vlapic_lvtt_period(vlapic) )
> >> >break;
> >>  >
> >> >+vlapic->timer_last_update = hvm_get_guest_time(current);
> >> >vlapic_set_reg(vlapic, APIC_TMICT, val);
> >>  >
> >> >vlapic_update_timer(vlapic, vlapic_get_reg(vlapic, APIC_LVTT));
> >> 
> >> Why is this addition needed? vlapic_update_timer() sets timer_last_update
> >> anyway. As it looks all you want is the value to be non-zero, which can be
> >> done with less overhead and should be stated so in a comment.
> >
> >This is not true, the value is used before been set. It is used to
> >calculate how much time have passed since tmict was set. Before been set
> >again, there is this:
> >time_passed = hvm_get_guest_time(current) - vlapic->timer_last_update;
> 
> Hmm, then I'm even more puzzled - the two hvm_get_guest_time() calls
> will then result in a small but non-zero delta. Is that really intended?

It is not really intended, but I did not see it as an issue either. I
can try to get rid of the first assignment, but the function is going to
needs an extra argument, something that say that timer_last_update is
not accurate should not be used or that tmict as just been updated.

I'll see what I can do.

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2 1/3] x86/vlapic: Introduce vlapic_update_timer

[Anthony PERARD]

On Fri, Aug 04, 2017 at 09:40:32AM -0600, Jan Beulich wrote:
> >>> Anthony PERARD  08/04/17 12:52 PM >>>
> >On Thu, Aug 03, 2017 at 08:59:10AM -0600, Jan Beulich wrote:
> >> >>> Anthony PERARD  07/18/17 7:10 PM >>>
> >> >+static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt);
> >> >+{
> >> >+uint64_t period;
> >> >+uint64_t delta;
> >> 
> >> Why two lines (but see also below)?
> >
> >Why not? Anyway, I'll change it.
> >
> >Also I realize that delta is going to be initialize to 0 here in the
> >next patch, which is why I think there is two lines.
> 
> For both this and ...
> 
> >> >+bool is_periodic;
> >> >+
> >> >+is_periodic = (lvtt & APIC_TIMER_MODE_MASK) == 
> >> >APIC_TIMER_MODE_PERIODIC;
> >> >+
> >> >+period = (uint64_t)vlapic_get_reg(vlapic, APIC_TMICT)
> >> >+* APIC_BUS_CYCLE_NS * vlapic->hw.timer_divisor;
> >> >+
> >> >+/* Calculate the next time the timer should trigger an interrupt. */
> >> >+delta = period;
> >> 
> >> What is the point of having the same value in two variables?
> >
> >It might look like it but there are not the same values, the description
> >is accurate, even if the calculation at this stage is very simple.
> >
> >More importantly, this line is going away in the next patch and will be
> >replaced by a more complexe calculation.
> 
> ... and this - irrespective of subsequent patches, the one here would better
> be self-contained, or otherwise its description should point out that certain
> things are done in a way easing subsequent ones (but only if that was really
> the case, which I don't think it is here - as you say, the questionable
> constructs are being touched again later anyway, so could as well be left
> out).

Fine, I'll get rid of delta in this patch.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH] tools/libxl: Fix a segment fault when mmio_hole is set in hvm.cfg

[Wei Liu]

On Wed, Aug 02, 2017 at 12:32:58PM -0700, Christopher Clark wrote:
> On Wed, Jul 12, 2017 at 3:15 AM, Wei Liu  wrote:
> >
> > On Thu, Jul 13, 2017 at 10:03:39AM +0800, Xiong Zhang wrote:
> > > When valid mmio_hole is set in hvm.cfg, segment fault happens at accessing
> > > localents pointer.
> > >
> > > Because the size of localents pointer isn't enough to store appended
> > > mmio_hole_size parameter.
> > >
> > > Signed-off-by: Xiong Zhang 
> > > ---
> > >
> > > tools/libxl/libxl_create.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > >diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > >index bffbc45..1158303 100644
> > >--- a/tools/libxl/libxl_create.c
> > >+++ b/tools/libxl/libxl_create.c
> > >@@ -451,7 +451,7 @@ int libxl__domain_build(libxl__gc *gc,
> > > vments[4] = "start_time";
> > > vments[5] = GCSPRINTF("%lu.%02d", 
> > > start_time.tv_sec,(int)start_time.tv_usec/1);
> > >
> > >-localents = libxl__calloc(gc, 9, sizeof(char *));
> > >+localents = libxl__calloc(gc, 11, sizeof(char *));
> > > i = 0;
> > > localents[i++] = "platform/acpi";
> > > localents[i++] = libxl__acpi_defbool_val(info) ? "1" : "0";
> >
> >
> > Acked-by: Wei Liu 
> >
> > Ian please backport this.
> 
> 
> Bump: the above patch still needs to be backported into 4.9 please.
> 
> master commit: 614a14736e33fb84872eb00f08799ebbc73a96c6

In Ian's absence I have cherry-picked this to 4.9 branch. Older branches
don't need this patch.

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

Re: [Xen-devel] [PATCH v2 2/3] x86/vlapic: Keep timer running when switching between one-shot and periodic mode

[Jan Beulich]

>> Anthony PERARD  08/04/17 1:38 PM >>>
>On Thu, Aug 03, 2017 at 09:21:57AM -0600, Jan Beulich wrote:
>> >>> Anthony PERARD  07/18/17 7:12 PM >>>
>> >@@ -818,6 +840,7 @@ static void vlapic_reg_write(struct vcpu *v,
>> >if ( !vlapic_lvtt_oneshot(vlapic) && !vlapic_lvtt_period(vlapic) )
>> >break;
>>  >
>> >+vlapic->timer_last_update = hvm_get_guest_time(current);
>> >vlapic_set_reg(vlapic, APIC_TMICT, val);
>>  >
>> >vlapic_update_timer(vlapic, vlapic_get_reg(vlapic, APIC_LVTT));
>> 
>> Why is this addition needed? vlapic_update_timer() sets timer_last_update
>> anyway. As it looks all you want is the value to be non-zero, which can be
>> done with less overhead and should be stated so in a comment.
>
>This is not true, the value is used before been set. It is used to
>calculate how much time have passed since tmict was set. Before been set
>again, there is this:
>time_passed = hvm_get_guest_time(current) - vlapic->timer_last_update;

Hmm, then I'm even more puzzled - the two hvm_get_guest_time() calls
will then result in a small but non-zero delta. Is that really intended?

Jan


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

Re: [Xen-devel] [PATCH v2 1/3] x86/vlapic: Introduce vlapic_update_timer

[Jan Beulich]

>>> Anthony PERARD  08/04/17 12:52 PM >>>
>On Thu, Aug 03, 2017 at 08:59:10AM -0600, Jan Beulich wrote:
>> >>> Anthony PERARD  07/18/17 7:10 PM >>>
>> >+static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt);
>> >+{
>> >+uint64_t period;
>> >+uint64_t delta;
>> 
>> Why two lines (but see also below)?
>
>Why not? Anyway, I'll change it.
>
>Also I realize that delta is going to be initialize to 0 here in the
>next patch, which is why I think there is two lines.

For both this and ...

>> >+bool is_periodic;
>> >+
>> >+is_periodic = (lvtt & APIC_TIMER_MODE_MASK) == 
>> >APIC_TIMER_MODE_PERIODIC;
>> >+
>> >+period = (uint64_t)vlapic_get_reg(vlapic, APIC_TMICT)
>> >+* APIC_BUS_CYCLE_NS * vlapic->hw.timer_divisor;
>> >+
>> >+/* Calculate the next time the timer should trigger an interrupt. */
>> >+delta = period;
>> 
>> What is the point of having the same value in two variables?
>
>It might look like it but there are not the same values, the description
>is accurate, even if the calculation at this stage is very simple.
>
>More importantly, this line is going away in the next patch and will be
>replaced by a more complexe calculation.

... and this - irrespective of subsequent patches, the one here would better
be self-contained, or otherwise its description should point out that certain
things are done in a way easing subsequent ones (but only if that was really
the case, which I don't think it is here - as you say, the questionable
constructs are being touched again later anyway, so could as well be left
out).

Jan


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

Re: [Xen-devel] [RFC PATCH 4/4] libxl: support creation and destruction of static shared memory areas

[Wei Liu]

I skim through this patch and have some questions.

On Fri, Aug 04, 2017 at 10:20:25AM +0800, Zhongze Liu wrote:
> +
> +static int libxl__sshm_add_master(libxl__gc *gc, uint32_t domid,
> +  libxl_static_shm *sshm)
> +{
> +int rc, aborting;
> +char *sshm_path, *dom_path, *dom_role_path;
> +char *ents[11];
> +struct xs_permissions noperm;
> +xs_transaction_t xt = XBT_NULL;
> +
> +sshm_path = libxl__xs_get_sshmpath(gc, sshm->id);
> +dom_path = libxl__xs_get_dompath(gc, domid);
> +/* the domain should be in xenstore by now */
> +assert(dom_path);
> +dom_role_path = GCSPRINTF("%s/static_shm/%s/role", dom_path, sshm->id);
> +
> +
> + retry_transaction:
> +/* Within the transaction, goto out by default means aborting */
> +aborting = 1;
> +rc = libxl__xs_transaction_start(gc, );
> +if (rc) { goto out; }

if (rc) goto out;

> +
> +if (NULL == libxl__xs_read(gc, xt, sshm_path)) {

!libxl__xs_read

We don't use "Yoda conditions".

> +rc = libxl__xs_write_checked(gc, xt, dom_role_path, "master");
> +if (rc) { goto out; };
> +
> +ents[0] = "master";
> +ents[1] = GCSPRINTF("%"PRIu32, domid);
> +ents[2] = "begin";
> +ents[3] = GCSPRINTF("0x%"PRIx64, sshm->begin);
> +ents[4] = "end";
> +ents[5] = GCSPRINTF("0x%"PRIx64, sshm->end);
> +ents[6] = "prot";
> +ents[7] = libxl__strdup(gc, libxl_sshm_prot_to_string(sshm->prot));
> +ents[8] = "cache_policy";
> +ents[9] = libxl__strdup(gc,
> +  libxl_sshm_cachepolicy_to_string(sshm->cache_policy));
> +ents[10] = NULL;
> +

These aren't going to change from iteration to iteration, so you can
prepare them before entering the loop.

BTW it would be cleaner to use a for (;;) {} or while (1) {} loop to
implement this instead of using goto label. You can then eliminate the
TRY_TRANSACTION_OR_FAIL macro.

> +/* could only be accessed by Dom0 */
> +noperm.id = 0;
> +noperm.perms = XS_PERM_NONE;
> +libxl__xs_mknod(gc, xt, sshm_path, , 1);
> +libxl__xs_writev(gc, xt, sshm_path, ents);
> +} else {
> +SSHM_ERROR(domid, sshm->id, "can only have one master.");
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +
> +aborting = rc = 0;
> +
> + out:
> +TRY_TRANSACTION_OR_FAIL(aborting);
> +return rc;
> +}
> +
[...]
> +static int libxl__sshm_del_single(libxl__gc *gc, xs_transaction_t xt,
> +  uint32_t domid, const char *id, bool 
> master)
> +{
> +char *sshm_path, *slaves_path;
> +
> +sshm_path = libxl__xs_get_sshmpath(gc, id);
> +slaves_path = GCSPRINTF("%s/slaves", sshm_path);
> +
> +if (master) {
> +/* we know that domid can't be both a master and a slave for one id,

Is this enforced in code?

> + * so the number of slaves won't change during iteration. Simply 
> check
> + * sshm_path/slavea to tell if there are still living slaves. */
> +if (NULL != libxl__xs_read(gc, xt, slaves_path)) {
> +SSHM_ERROR(domid, id,
> +   "can't remove master when there are living slaves.");
> +return ERROR_FAIL;

Isn't this going to leave a half-destructed domain in userspace
components? Maybe we should proceed anyway?

> +}
> +libxl__xs_path_cleanup(gc, xt, sshm_path);
> +} else {
> +libxl__xs_path_cleanup(gc, xt,
> +GCSPRINTF("%s/%"PRIu32, slaves_path, domid));

Is this really enough? What will happen to the mapping? You merely
delete the xenstore node for it but the mapping is still there.

I suppose you're relying on the hypervisor to remove the mapping from
p2m?

> +}
> +
> +return 0;
> +}
> +
[...]
> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
> index c4a18df353..d91fbf5fda 100644
> --- a/tools/libxl/libxl_xshelp.c
> +++ b/tools/libxl/libxl_xshelp.c
> @@ -193,6 +193,14 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
>  return s;
>  }
>  
> +char *libxl__xs_get_sshmpath(libxl__gc *gc, const char *id)
> +{
> +char *s = GCSPRINTF("/local/static_shm/%s", id);
> +if (!s)
> +LOGE(ERROR, "cannot allocate static shm path");

GCSPRINTF can't fail. You can eliminate the check.

> +return s;
> +}
> +
>  int libxl__xs_read_mandatory(libxl__gc *gc, xs_transaction_t t,
>   const char *path, const char **result_out)
>  {
> -- 
> 2.13.3
> 

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

[Xen-devel] [xen-unstable-smoke test] 112446: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 
112402
 test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 112402

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  b93d8718cab0b4b7c4155609d8775d9e53b1d880
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112402  2017-07-31 21:02:08 Z3 days
Failing since112418  2017-08-03 11:04:58 Z1 days   12 attempts
Testing same since   112445  2017-08-04 12:02:09 Z0 days2 attempts


People who touched revisions under test:
  Andrii Anisov 
  He Chen 
  Ian Jackson 
  Iurii Konovalenko 
  Iurii Mykhalskyi 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Marek Marczykowski-Górecki 
  Praveen Kumar 
  Rusty Bird 
  Sergej Proskurin 
  Stefano Stabellini 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Not pushing.

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

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

Re: [Xen-devel] Runtime adjustment of hypervisor parameters

[Juergen Gross]

On 04/08/17 15:57, Andrew Cooper wrote:
> On 04/08/17 14:36, Juergen Gross wrote:
>> On 04/08/17 15:23, Andrew Cooper wrote:
>>> On 04/08/17 14:20, Juergen Gross wrote:
 Last year Jan posted a patch series to change hypervisor log level
 thresholds via xl command [1]. This approach was later modified by Wei
 resulting in patch series [2].

 I'd like to follow up with another approach being able to do the same,
 but being much more flexible:

 Instead of controlling only loglvl I suggest to add a xl command

 xl xen-param 

 which will take a  string being parsed by the hypervisor
 the same way it is parsing boot parameters. Allowed parameters are
 specified in the hypervisor the same way as boot parameters, but with
 another set of macros (e.g. custom_runtime_param(), ...). Often enough
 (e.g. in the loglvl case) the definitions could be just the same, while
 in other cases they might differ a little bit (example: conring_size
 would require a different handling as at boot time due to race
 condition handling).

 Parsing functions could be reused in most cases, they'd just need to
 lose the __init modifier.

 What do you think: is this approach sensible, or can I just put it into
 /dev/null instead of starting with the patches?
>>> What sort of parameters were you thinking of tweaking?  (Without any
>>> evidence) I'm going to go out on a limb and say that most of the
>>> hypervisor command line parameters are not safe to play with after boot.
>> The following would be a nice start for discussion:
>>
>> async-show-all, console_timestamps, conswitch,
> 
> conswitch can already be altered using `xl debug-keys`
> 
>> guest_loglvl, loglvl, hvm_debug,
> 
> I'm getting slowly more annoyed with the scattergun approach of
> hvm_debug and the trace logic when it comes to the subset they each have
> of functionality.
> 
> I've a cunning plan which I was going to propose once Paul's general
> mapping patches are a little better formed, whereby we can control
> action logging on a per-domain or per-vcpu basis, rather than getting a
> full-system torrent or nothing.
> 
>> hvm_fep,
> 
> This is a parameter for reasons of security (i.e. if you didn't choose
> it at boot, its definitely not usable in the system).  I plan to make it
> also need to be opted-in to at the toolstack level at domain build time.
> 
> It isn't currently safe to try and flip this option behind the back of a
> domain, as the alteration only happens when constructing the vcpu.
> 
>> hvm_port80,
> 
> I have to admit that I question the utility of this at all.  I was
> considering killing it completely, not least because it makes
> nested-virt IO bitmap handling far harder.
> 
>> iommu_dev_iotlb_timeout, irq_ratelimit,
>> nmi, noreboot, reboot, sync_console, vpmu,
> 
> My CPUID series will hopefully sort vpmu out properly.  (like hvm_fep)
> needing to opt in to it in the Xen command line (due to its security
> status), and then opt in to it at the toolstack level.
> 
>>  watchdog_timeout

Which parameters should be changeable is subject to discussion. I just
wanted to show there are more than 1 or 2 possible candidates.

> I think there is merit in having a whitelist of parameters we think are
> safe to be altered at runtime, and a dom0 mechanism of tweaking them.

That's what I'm suggesting.

The whitelist is a natural result from the need to specify each runtime
changeable parameter via another macro, e.g.:

 custom_param("console_timestamps", parse_console_timestamps);
+custom_runtime_param("console_timestamps", parse_console_timestamps);

For security reasons I would add another parameter switching runtime
modifications of parameters off for the running session (can be
specified as boot parameter to switch it off for the complete session,
or via runtime parameter change to do so e.g. after initializing the
settings via init script).


Juergen


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

Re: [Xen-devel] Runtime adjustment of hypervisor parameters

[Juergen Gross]

On 04/08/17 15:47, Wei Liu wrote:
> On Fri, Aug 04, 2017 at 03:20:09PM +0200, Juergen Gross wrote:
>> Last year Jan posted a patch series to change hypervisor log level
>> thresholds via xl command [1]. This approach was later modified by Wei
>> resulting in patch series [2].
>>
>> I'd like to follow up with another approach being able to do the same,
>> but being much more flexible:
>>
>> Instead of controlling only loglvl I suggest to add a xl command
>>
>> xl xen-param 
>>
>> which will take a  string being parsed by the hypervisor
>> the same way it is parsing boot parameters. Allowed parameters are
>> specified in the hypervisor the same way as boot parameters, but with
>> another set of macros (e.g. custom_runtime_param(), ...). Often enough
>> (e.g. in the loglvl case) the definitions could be just the same, while
>> in other cases they might differ a little bit (example: conring_size
>> would require a different handling as at boot time due to race
>> condition handling).
>>
>> Parsing functions could be reused in most cases, they'd just need to
>> lose the __init modifier.
>>
>> What do you think: is this approach sensible, or can I just put it into
>> /dev/null instead of starting with the patches?
>>
> 
> To me this isn't so much about implementation details. It seems that it
> would increase the maintenance burden because now we need to distinguish
> and keep track of the runtime tunable options, which leads to more code
> and documentation. We need to consider the benefit gain first.

The additional amount of code needed would be less than for dedicated
sysctl options for each possible parameter, as existing parsing logic
could be just reused.

Documentation would be limited to the single new xl command and a note
for each parameter in docs/misc/xen-command-line.markdown whether it is
supported for runtime changes.


Juergen

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

Re: [Xen-devel] [PATCH v2] xl: add --clear option to dmesg command

[Wei Liu]

On Fri, Aug 04, 2017 at 10:34:18PM +0800, Xiao Liang wrote:
> Yes, the full name is "Xiao Liang". Thanks :)
> 

Cool, thanks for confirming. I will push your patch shortly.

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

Re: [Xen-devel] [PATCH v2] xl: add --clear option to dmesg command

[Xiao Liang]

Yes, the full name is "Xiao Liang". Thanks :)

On 08/04/2017 07:05 PM, Wei Liu wrote:

On Fri, Aug 04, 2017 at 11:57:53AM +0100, Wei Liu wrote:

On Tue, Aug 01, 2017 at 05:10:27PM +0100, Wei Liu wrote:

On Tue, Aug 01, 2017 at 11:57:50PM +0800, Xiao Liang wrote:

From: xiliang 

The manual of xl says --clear option is supported and that option worked for 
xm. Add that to xl now.

I will wrap this long line to 72 columns while committing.


Signed-off-by: xiliang 

I was about to commit this, but I realised "xiliang" as your name seems
wrong. Should it be "Xi Liang" instead?

I think it should be "Xiao Liang" because that is what is in your email
handle.



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

Re: [Xen-devel] [PATCH RFC v1 2/3] libxl: enable per-VCPU work conserving flag for RTDS

[Wei Liu]

On Fri, Aug 04, 2017 at 02:53:51PM +0200, Dario Faggioli wrote:
> On Fri, 2017-08-04 at 13:10 +0100, Wei Liu wrote:
> > On Fri, Aug 04, 2017 at 10:13:18AM +0200, Dario Faggioli wrote:
> > > On Thu, 2017-08-03 at 17:39 -0400, Meng Xu wrote:
> > > > 
> > > *HOWEVER*, in this case, we do have that 'extratime' field already,
> > > as
> > > a leftover from SEDF, which is there taking space and cluttering
> > > the
> > > interface, so why don't make good use of it. Especially considering
> > > it
> > > was used for _exactly_ the same thing, and with _exactly_ the same
> > > meaning, and even for a very similar (i.e., SEDF was also real-
> > > time)
> > > kind of scheduler.
> > 
> > Correct me if I'm wrong:
> > 
> > 1. extratime is ever only used in SEDF
> > 2. SEDF is removed
> > 
> > That means we do have extratime to use in all other schedulers.
> > 
> I'm not sure what you mean with this last line.
> 
> IAC, this is how our the related data structures looks like, right now:
> 
> libxl_sched_params = Struct("sched_params",[
> ("vcpuid",   integer, {'init_val': 
> 'LIBXL_SCHED_PARAM_VCPU_INDEX_DEFAULT'}),
> ("weight",   integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT'}),
> ("cap",  integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT'}),
> ("period",   integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT'}),
> ("extratime",integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
> ("budget",   integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),
> ])
> 
> The extratime field is there. Any scheduler can use it, if it wants
> (and in the way it wants). Currently, no one of them does that.

Right, that's what I wanted to know.

> 
> libxl_domain_sched_params = Struct("domain_sched_params",[
> ("sched",libxl_scheduler),
> ("weight",   integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT'}),
> ("cap",  integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT'}),
> ("period",   integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT'}),
> ("budget",   integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),
> 
> # The following three parameters ('slice', 'latency' and 'extratime') are 
> deprecated,
> # and will have no effect if used, since the SEDF scheduler has been 
> removed.
> # Note that 'period' was an SDF parameter too, but it is still effective 
> as it is
> # now used (together with 'budget') by the RTDS scheduler.
> ("slice",integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT'}),
> ("latency",  integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT'}),
> ("extratime",integer, {'init_val': 
> 'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
> ])
> 
> Same here. 'slice', 'latency' and 'extratime' are there because we
> deprecate, but don't remove stuff. They're not used in any way. [*]
> 
> If, at some point, I'd decide to develop a feature for, say Credit2,
> that controll the latency (whatever that would mean, it's just an
> example! :-D) of domains, I think I'll use this 'latency' field, for
> its interface, instead of adding some other stuff.
> 
> > However, please consider the possibility of reintroducing SEDF in the
> > future. Suppose that would happen, does extratime still has the same
> > semantics?
> > 
> Well, I guess yes. But how does this matter? Each scheduler can, if it
> wants, use all these parameters in the way it actuallly prefers. So,
> the fact that RTDS will be using 'extratime' for letting vCPUs execute
> past their own real-time reservation, does not prevent the reintroduced
> SEDF --nor any other already existing or new scheduler-- to also use
> it, for similar (or maybe even not so similar) purposes.
> 
> Or am I missing something?

If extratime means different things to different schedulers, it's going
to be confusing. As a layperson I can't tell what extratime is or how it
is supposed to be used. I would like to have the field to have only one
meaning.

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

[Xen-devel] [xen-unstable test] 112437: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112286
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112286
 build-arm64   2 hosts-allocate broken REGR. vs. 112286

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 112286
 build-arm64-pvops 3 capture-logs  broken blocked in 112286
 build-arm64   3 capture-logs  broken blocked in 112286
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
112286
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112274
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112286
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112286
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112286
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112286
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112286
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-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-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail 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-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4
baseline version:
 xen  55924baf2211ddcf5ba8f702c9a4c07730e0c8e8

Last test of basis   112286  2017-07-25 10:59:15 Z   10 days
Failing since112306  

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ef3d1df77bbd5227c76306e5c64c66d82805bbd9
baseline version:
 ovmf 09cc872d0242304329e6c21e91bef14fa9949744

Last test of basis71937  2017-08-04 08:18:46 Z0 days
Testing same since71938  2017-08-04 12:17:30 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Eric Dong 
  Fu Siyuan 
  Hao Wu 
  Star Zeng 

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



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

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

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


Push not applicable.


commit ef3d1df77bbd5227c76306e5c64c66d82805bbd9
Author: Dandan Bi 
Date:   Fri Jul 28 10:40:14 2017 +0800

MdeModulePkg/DisplayEngine: Fix incorrect display issue

In a form, some new menus may be dynamically inserted between highlight
menu and previous top of screen menu when some question are refreshed.
So the highlight menu and previous top of screen menu perhaps can't be
shown in one page. Existing codes miss to handle this case then will
cause incorrect display.This patch is to fix this display issue.

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 

commit ba78032bc8c9f74a4c4cc4917a3284a51840ec70
Author: Dandan Bi 
Date:   Fri Jul 28 16:19:22 2017 +0800

BaseTools/VfrCompile: Remove the MAX_PATH limitation

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=579

Since we have already used LongFilePath() to convert
file path, so we can remove the MAX_PATH limitation.

Cc: Eric Dong 
Cc: Liming Gao 
Cc: Daniel Díaz 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 

commit 8c1e13d327e6c0409435edaa89b909fbdef49232
Author: Dandan Bi 
Date:   Tue Jul 11 15:35:14 2017 +0800

BaseTools/VfrCompile: Fix segmentation fault issues

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=532

(1) Add NULL check before using a pointer.
(2) Use "%s" format string in DebugError function to
avoid crash caused by incorrect input.

Cc: Bo Chen 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 

commit 41c9011cc166cff8a27a7e90592d81ba570b42ff
Author: Fu Siyuan 
Date:   Thu Aug 3 14:38:51 2017 +0800

NetworkPkg: iSCSI should allow to set 6 or 12 length of ISID keyword.

The last 3 bytes of ISID should be able to changed by setting the keyword 
with
a value with length 6 (only last 3 bytes) or 12 (full ISID) according to the
keyword definition in UEFI configuration namespace website.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
Reviewed-by: Ye Ting 

commit bc2300577ffddcdf5b4b015f252f8357663217a7
Author: Eric Dong 
Date:   Fri Aug 4 09:59:08 2017 +0800

UefiCpuPkg: Enable Processor Trace feature.

Cc: Jeff Fan 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 

Re: [Xen-devel] [PATCH v15 00/23] Enable L2 Cache Allocation Technology & Refactor psr.c

[Yi Sun]

On 17-08-04 12:36:46, Yi Sun wrote:
> On 17-08-04 10:21:51, Yi Sun wrote:
> > On 17-08-03 18:50:02, Boris Ostrovsky wrote:
> > > 
> > > 
> > > On 08/03/2017 11:37 AM, Andrew Cooper wrote:
> > > >(XEN) [ 1071.542500] Xen call trace:
> > > >(XEN) [ 1071.542505][] psr_domain_free+0x23/0xcc
> > > >(XEN) [ 1071.542514][] 
> > > >arch_domain_destroy+0x88/0x8f
> > > >(XEN) [ 1071.542521][] 
> > > >domain.c#complete_domain_destroy+0x6f/0x192
> > > >(XEN) [ 1071.542528][] 
> > > >rcupdate.c#rcu_process_callbacks+0x141/0x1a3
> > > >(XEN) [ 1071.542536][] 
> > > >softirq.c#__do_softirq+0x7f/0x8a
> > > >(XEN) [ 1071.542542][] 
> > > >process_pending_softirqs+0x35/0x37
> > > >(XEN) [ 1071.542551][] 
> > > >mwait-idle.c#mwait_idle+0xfc/0x2dd
> > > >(XEN) [ 1071.542557][] domain.c#idle_loop+0x72/0x8a
> > > >(XEN) [ 1071.542561]
> > > >(XEN) [ 1071.916649]
> > > >(XEN) [ 1071.918881] 
> > > >(XEN) [ 1071.924987] Panic on CPU 14:
> > > >(XEN) [ 1071.928771] Assertion 'socket_info' failed at psr.c:1297
> > > >(XEN) [ 1071.935265] 
> > > >(XEN) [ 1071.941375]
> > > >(XEN) [ 1071.943606] Reboot in five seconds...
> > > >
> > > >The hardware is SandyBridge-EN, which has no PSR support as far as I am 
> > > >aware.  As a first thought, psr_free_domain() should not be making any 
> > > >assertions about hardware state.
> > > 
> > > Not surprisingly, I hit this as well.
> > > 
> > > It seems to me that socket_info is set only if "psr" boot parameter
> > > is explicitly set *and* opt_cos_max is not sufficiently low. So
> > > ASSERT() should be either turned into 'if' or possibly be swapped
> > > with d->arch.psr_cos_ids test.
> > > 
> > Very sorry for this. As you mentioned, the 'socket_info' is allocated only 
> > if
> > "psr" boot parameter is set. So, I should not use "ASSERT(socket_info)" in
> > 'psr_free_cos()' which is called by 'psr_domain_free'.
> > 
> > I will send an update patch out to fix this. Thanks!
> > 
> Below patch is submitted to fix this.
> [PATCH v15.2 08/23] x86: refactor psr: L3 CAT: set value: implement framework.
> 
Just for notice, the fix patch based on staging branch is below:
[Patch for staging 2/2] x86: remove an ASSERT to avoid crash when destroy a 
domain.

Thanks,
Sun Yi

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

Re: [Xen-devel] Runtime adjustment of hypervisor parameters

[Andrew Cooper]

On 04/08/17 14:36, Juergen Gross wrote:
> On 04/08/17 15:23, Andrew Cooper wrote:
>> On 04/08/17 14:20, Juergen Gross wrote:
>>> Last year Jan posted a patch series to change hypervisor log level
>>> thresholds via xl command [1]. This approach was later modified by Wei
>>> resulting in patch series [2].
>>>
>>> I'd like to follow up with another approach being able to do the same,
>>> but being much more flexible:
>>>
>>> Instead of controlling only loglvl I suggest to add a xl command
>>>
>>> xl xen-param 
>>>
>>> which will take a  string being parsed by the hypervisor
>>> the same way it is parsing boot parameters. Allowed parameters are
>>> specified in the hypervisor the same way as boot parameters, but with
>>> another set of macros (e.g. custom_runtime_param(), ...). Often enough
>>> (e.g. in the loglvl case) the definitions could be just the same, while
>>> in other cases they might differ a little bit (example: conring_size
>>> would require a different handling as at boot time due to race
>>> condition handling).
>>>
>>> Parsing functions could be reused in most cases, they'd just need to
>>> lose the __init modifier.
>>>
>>> What do you think: is this approach sensible, or can I just put it into
>>> /dev/null instead of starting with the patches?
>> What sort of parameters were you thinking of tweaking?  (Without any
>> evidence) I'm going to go out on a limb and say that most of the
>> hypervisor command line parameters are not safe to play with after boot.
> The following would be a nice start for discussion:
>
> async-show-all, console_timestamps, conswitch,

conswitch can already be altered using `xl debug-keys`

> guest_loglvl, loglvl, hvm_debug,

I'm getting slowly more annoyed with the scattergun approach of
hvm_debug and the trace logic when it comes to the subset they each have
of functionality.

I've a cunning plan which I was going to propose once Paul's general
mapping patches are a little better formed, whereby we can control
action logging on a per-domain or per-vcpu basis, rather than getting a
full-system torrent or nothing.

> hvm_fep,

This is a parameter for reasons of security (i.e. if you didn't choose
it at boot, its definitely not usable in the system).  I plan to make it
also need to be opted-in to at the toolstack level at domain build time.

It isn't currently safe to try and flip this option behind the back of a
domain, as the alteration only happens when constructing the vcpu.

> hvm_port80,

I have to admit that I question the utility of this at all.  I was
considering killing it completely, not least because it makes
nested-virt IO bitmap handling far harder.

> iommu_dev_iotlb_timeout, irq_ratelimit,
> nmi, noreboot, reboot, sync_console, vpmu,

My CPUID series will hopefully sort vpmu out properly.  (like hvm_fep)
needing to opt in to it in the Xen command line (due to its security
status), and then opt in to it at the toolstack level.

>  watchdog_timeout


I think there is merit in having a whitelist of parameters we think are
safe to be altered at runtime, and a dom0 mechanism of tweaking them.

~Andrew

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

Re: [Xen-devel] [RFC PATCH 3/4] x86/p2m : remove checks that forbid adding foreign pages between HVM guests

[Zhongze Liu]

Hi Wei,

Yes, indeed. Before the teardown is implemented, even if I simply
remove the first
check, when I try to destroy the master domain, the domain will become a zombie,
because the refcount of the shared pages won't be correctly decreased on slave
destruction.

I don't know why this hasn't been done, so I'm separating this patch
out to serve
as a place to discuss this problem.

For this GSoC project, I would also ask if there is any temporary workaround.
While waiting for any further suggestions and answers, I'll continue
to work on the ARM side.

Cheers,

Zhongze Liu

2017-08-04 21:27 GMT+08:00 Wei Liu :
> On Fri, Aug 04, 2017 at 10:20:24AM +0800, Zhongze Liu wrote:
>> Two checks in the p2m code forbids sharing physical pages among DomU's by 
>> using
>> xc_add_to_physmap_batch with XENMAPSPACE_gmfn_foreign. Just simply remove 
>> them
>> in this RFC patch to ask for suggestions on how to properly handle this.
>>
>> This is for the proposal "Allow setting up shared memory areas between VMs
>> from xl config file" (see [1]).
>>
>> [1] 
>> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
>>
>> Signed-off-by: Zhongze Liu 
>> ---
>> Cc: George Dunlap 
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> Cc: xen-devel@lists.xen.org
>> ---
>>  xen/arch/x86/mm/p2m.c | 20 +++-
>>  1 file changed, 15 insertions(+), 5 deletions(-)
>>
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index e8a57d118c..3ee4c14ed4 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2531,8 +2531,13 @@ int p2m_add_foreign(struct domain *tdom, unsigned 
>> long fgfn,
>>   * hvm fixme: until support is added to p2m teardown code to cleanup any
>>   * foreign entries, limit this to hardware domain only.
>
> This HVM fixme needs to be fixed before the check can go away. This is
> going to be a non-trivial project, but it is going to be useful in its
> own right.

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

Re: [Xen-devel] Runtime adjustment of hypervisor parameters

[Wei Liu]

On Fri, Aug 04, 2017 at 03:20:09PM +0200, Juergen Gross wrote:
> Last year Jan posted a patch series to change hypervisor log level
> thresholds via xl command [1]. This approach was later modified by Wei
> resulting in patch series [2].
> 
> I'd like to follow up with another approach being able to do the same,
> but being much more flexible:
> 
> Instead of controlling only loglvl I suggest to add a xl command
> 
> xl xen-param 
> 
> which will take a  string being parsed by the hypervisor
> the same way it is parsing boot parameters. Allowed parameters are
> specified in the hypervisor the same way as boot parameters, but with
> another set of macros (e.g. custom_runtime_param(), ...). Often enough
> (e.g. in the loglvl case) the definitions could be just the same, while
> in other cases they might differ a little bit (example: conring_size
> would require a different handling as at boot time due to race
> condition handling).
> 
> Parsing functions could be reused in most cases, they'd just need to
> lose the __init modifier.
> 
> What do you think: is this approach sensible, or can I just put it into
> /dev/null instead of starting with the patches?
> 

To me this isn't so much about implementation details. It seems that it
would increase the maintenance burden because now we need to distinguish
and keep track of the runtime tunable options, which leads to more code
and documentation. We need to consider the benefit gain first.

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

[Xen-devel] [xen-unstable-smoke test] 112445: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 
112402
 test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 112402

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  b93d8718cab0b4b7c4155609d8775d9e53b1d880
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112402  2017-07-31 21:02:08 Z3 days
Failing since112418  2017-08-03 11:04:58 Z1 days   11 attempts
Testing same since   112445  2017-08-04 12:02:09 Z0 days1 attempts


People who touched revisions under test:
  Andrii Anisov 
  He Chen 
  Ian Jackson 
  Iurii Konovalenko 
  Iurii Mykhalskyi 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Marek Marczykowski-Górecki 
  Praveen Kumar 
  Rusty Bird 
  Sergej Proskurin 
  Stefano Stabellini 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Not pushing.

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

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

Re: [Xen-devel] [PATCH 5/5] tools/libxenctrl: use new xenforeignmemory API to seed grant table

[Juergen Gross]

On 04/08/17 15:21, Wei Liu wrote:
> On Fri, Aug 04, 2017 at 03:02:03PM +0200, Marek Marczykowski-Górecki wrote:
>> On Fri, Aug 04, 2017 at 01:26:21PM +0100, Wei Liu wrote:
>>> On Wed, Aug 02, 2017 at 10:59:49AM +0100, Paul Durrant wrote:
 A previous patch added support for priv-mapping guest resources directly
 (rather than having to foreign-map, which requires P2M modification for
 HVM guests).

 This patch makes use of the new API to seed the guest grant table unless
 the underlying infrastructure (i.e. privcmd) doesn't support it, in which
 case the old scheme is used.

>>>
>>> The code mostly looks fine.
>>>
>>> What's the benefit of doing this?
>>
>> Also, I see changed signature of xc_dom_gnttab_seed (it got is_hvm
>> parameter). Wei, what is the policy for backward incompatible libxc API
>> changes?
> 
> libxc isn't stable, so functions might get deleted / updated at any
> point.
> 
> Most libxc functions are quite simple and are quite "close" to the
> hypervisor.
> 
> The non-trivial functions I know of are VMI related ones but I think
> users in that area already have the right expectation.
> 
> An important user of unstable libxc APIs is QEMU. It probes for specific
> functions in the configure script to handle compatibility issues.

Right now qemu can just use the version of libxc instead of doing it via
tests. :-)


Juergen

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

Re: [Xen-devel] Runtime adjustment of hypervisor parameters

[Juergen Gross]

On 04/08/17 15:23, Andrew Cooper wrote:
> On 04/08/17 14:20, Juergen Gross wrote:
>> Last year Jan posted a patch series to change hypervisor log level
>> thresholds via xl command [1]. This approach was later modified by Wei
>> resulting in patch series [2].
>>
>> I'd like to follow up with another approach being able to do the same,
>> but being much more flexible:
>>
>> Instead of controlling only loglvl I suggest to add a xl command
>>
>> xl xen-param 
>>
>> which will take a  string being parsed by the hypervisor
>> the same way it is parsing boot parameters. Allowed parameters are
>> specified in the hypervisor the same way as boot parameters, but with
>> another set of macros (e.g. custom_runtime_param(), ...). Often enough
>> (e.g. in the loglvl case) the definitions could be just the same, while
>> in other cases they might differ a little bit (example: conring_size
>> would require a different handling as at boot time due to race
>> condition handling).
>>
>> Parsing functions could be reused in most cases, they'd just need to
>> lose the __init modifier.
>>
>> What do you think: is this approach sensible, or can I just put it into
>> /dev/null instead of starting with the patches?
> 
> What sort of parameters were you thinking of tweaking?  (Without any
> evidence) I'm going to go out on a limb and say that most of the
> hypervisor command line parameters are not safe to play with after boot.

The following would be a nice start for discussion:

async-show-all, console_timestamps, conswitch, guest_loglvl, loglvl,
hvm_debug, hvm_fep, hvm_port80, iommu_dev_iotlb_timeout, irq_ratelimit,
nmi, noreboot, reboot, sync_console, vpmu, watchdog_timeout


Juergen

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

Re: [Xen-devel] [RFC PATCH 3/4] x86/p2m : remove checks that forbid adding foreign pages between HVM guests

[Wei Liu]

On Fri, Aug 04, 2017 at 10:20:24AM +0800, Zhongze Liu wrote:
> Two checks in the p2m code forbids sharing physical pages among DomU's by 
> using
> xc_add_to_physmap_batch with XENMAPSPACE_gmfn_foreign. Just simply remove them
> in this RFC patch to ask for suggestions on how to properly handle this.
> 
> This is for the proposal "Allow setting up shared memory areas between VMs
> from xl config file" (see [1]).
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
> 
> Signed-off-by: Zhongze Liu 
> ---
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: xen-devel@lists.xen.org
> ---
>  xen/arch/x86/mm/p2m.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index e8a57d118c..3ee4c14ed4 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2531,8 +2531,13 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
> fgfn,
>   * hvm fixme: until support is added to p2m teardown code to cleanup any
>   * foreign entries, limit this to hardware domain only.

This HVM fixme needs to be fixed before the check can go away. This is
going to be a non-trivial project, but it is going to be useful in its
own right.

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

Re: [Xen-devel] Runtime adjustment of hypervisor parameters

[Andrew Cooper]

On 04/08/17 14:20, Juergen Gross wrote:
> Last year Jan posted a patch series to change hypervisor log level
> thresholds via xl command [1]. This approach was later modified by Wei
> resulting in patch series [2].
>
> I'd like to follow up with another approach being able to do the same,
> but being much more flexible:
>
> Instead of controlling only loglvl I suggest to add a xl command
>
> xl xen-param 
>
> which will take a  string being parsed by the hypervisor
> the same way it is parsing boot parameters. Allowed parameters are
> specified in the hypervisor the same way as boot parameters, but with
> another set of macros (e.g. custom_runtime_param(), ...). Often enough
> (e.g. in the loglvl case) the definitions could be just the same, while
> in other cases they might differ a little bit (example: conring_size
> would require a different handling as at boot time due to race
> condition handling).
>
> Parsing functions could be reused in most cases, they'd just need to
> lose the __init modifier.
>
> What do you think: is this approach sensible, or can I just put it into
> /dev/null instead of starting with the patches?

What sort of parameters were you thinking of tweaking?  (Without any
evidence) I'm going to go out on a limb and say that most of the
hypervisor command line parameters are not safe to play with after boot.

~Andrew

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

Re: [Xen-devel] [PATCH 5/5] tools/libxenctrl: use new xenforeignmemory API to seed grant table

[Wei Liu]

On Fri, Aug 04, 2017 at 03:02:03PM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Aug 04, 2017 at 01:26:21PM +0100, Wei Liu wrote:
> > On Wed, Aug 02, 2017 at 10:59:49AM +0100, Paul Durrant wrote:
> > > A previous patch added support for priv-mapping guest resources directly
> > > (rather than having to foreign-map, which requires P2M modification for
> > > HVM guests).
> > > 
> > > This patch makes use of the new API to seed the guest grant table unless
> > > the underlying infrastructure (i.e. privcmd) doesn't support it, in which
> > > case the old scheme is used.
> > > 
> > 
> > The code mostly looks fine.
> > 
> > What's the benefit of doing this?
> 
> Also, I see changed signature of xc_dom_gnttab_seed (it got is_hvm
> parameter). Wei, what is the policy for backward incompatible libxc API
> changes?

libxc isn't stable, so functions might get deleted / updated at any
point.

Most libxc functions are quite simple and are quite "close" to the
hypervisor.

The non-trivial functions I know of are VMI related ones but I think
users in that area already have the right expectation.

An important user of unstable libxc APIs is QEMU. It probes for specific
functions in the configure script to handle compatibility issues.

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

[Xen-devel] Runtime adjustment of hypervisor parameters

[Juergen Gross]

Last year Jan posted a patch series to change hypervisor log level
thresholds via xl command [1]. This approach was later modified by Wei
resulting in patch series [2].

I'd like to follow up with another approach being able to do the same,
but being much more flexible:

Instead of controlling only loglvl I suggest to add a xl command

xl xen-param 

which will take a  string being parsed by the hypervisor
the same way it is parsing boot parameters. Allowed parameters are
specified in the hypervisor the same way as boot parameters, but with
another set of macros (e.g. custom_runtime_param(), ...). Often enough
(e.g. in the loglvl case) the definitions could be just the same, while
in other cases they might differ a little bit (example: conring_size
would require a different handling as at boot time due to race
condition handling).

Parsing functions could be reused in most cases, they'd just need to
lose the __init modifier.

What do you think: is this approach sensible, or can I just put it into
/dev/null instead of starting with the patches?


Juergen

[1]
https://lists.xenproject.org/archives/html/xen-devel/2016-03/msg00694.html
[2]
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00228.html

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

Re: [Xen-devel] [PATCH 5/5] tools/libxenctrl: use new xenforeignmemory API to seed grant table

[Marek Marczykowski-Górecki]

On Fri, Aug 04, 2017 at 01:26:21PM +0100, Wei Liu wrote:
> On Wed, Aug 02, 2017 at 10:59:49AM +0100, Paul Durrant wrote:
> > A previous patch added support for priv-mapping guest resources directly
> > (rather than having to foreign-map, which requires P2M modification for
> > HVM guests).
> > 
> > This patch makes use of the new API to seed the guest grant table unless
> > the underlying infrastructure (i.e. privcmd) doesn't support it, in which
> > case the old scheme is used.
> > 
> 
> The code mostly looks fine.
> 
> What's the benefit of doing this?

Also, I see changed signature of xc_dom_gnttab_seed (it got is_hvm
parameter). Wei, what is the policy for backward incompatible libxc API
changes?

> > NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params() was
> >   actually unnecessary, as the grant table has already been seeded
> >   by a prior call to xc_dom_gnttab_init() made by libxl__build_dom().
> > 
> > Signed-off-by: Paul Durrant 
> > ---
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> 
> BTW Marek needs to be CC on changes to Python bindings. I've done that
> for you.

For Python bits:
Acked-by: Marek Marczykowski-Górecki 

> > ---
> >  tools/libxc/include/xc_dom.h|   8 +--
> >  tools/libxc/xc_dom_boot.c   | 102 
> > 
> >  tools/libxc/xc_sr_restore_x86_hvm.c |  10 ++--
> >  tools/libxc/xc_sr_restore_x86_pv.c  |   2 +-
> >  tools/libxl/libxl_dom.c |   1 -
> >  tools/python/xen/lowlevel/xc/xc.c   |   6 +--
> >  6 files changed, 92 insertions(+), 37 deletions(-)
> > 
> > diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> > index ce47058c41..d6ca0a8680 100644
> > --- a/tools/libxc/include/xc_dom.h
> > +++ b/tools/libxc/include/xc_dom.h
> > @@ -323,12 +323,8 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, 
> > xen_pfn_t pfn,
> >  int xc_dom_boot_image(struct xc_dom_image *dom);
> >  int xc_dom_compat_check(struct xc_dom_image *dom);
> >  int xc_dom_gnttab_init(struct xc_dom_image *dom);
> > -int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> > -   xen_pfn_t console_gmfn,
> > -   xen_pfn_t xenstore_gmfn,
> > -   domid_t console_domid,
> > -   domid_t xenstore_domid);
> > -int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
> > +int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
> > +   bool is_hvm,
> > xen_pfn_t console_gmfn,
> > xen_pfn_t xenstore_gmfn,
> > domid_t console_domid,
> > diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
> > index c3b44dd399..fc3174ad7e 100644
> > --- a/tools/libxc/xc_dom_boot.c
> > +++ b/tools/libxc/xc_dom_boot.c
> > @@ -280,11 +280,11 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface 
> > *xch, domid_t domid)
> >  return gmfn;
> >  }
> >  
> > -int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
> > -   xen_pfn_t console_gmfn,
> > -   xen_pfn_t xenstore_gmfn,
> > -   domid_t console_domid,
> > -   domid_t xenstore_domid)
> > +static int compat_gnttab_seed(xc_interface *xch, domid_t domid,
> > +  xen_pfn_t console_gmfn,
> > +  xen_pfn_t xenstore_gmfn,
> > +  domid_t console_domid,
> > +  domid_t xenstore_domid)
> >  {
> >  
> >  xen_pfn_t gnttab_gmfn;
> > @@ -337,11 +337,11 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t 
> > domid,
> >  return 0;
> >  }
> >  
> > -int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> > -   xen_pfn_t console_gpfn,
> > -   xen_pfn_t xenstore_gpfn,
> > -   domid_t console_domid,
> > -   domid_t xenstore_domid)
> > +static int compat_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> > +  xen_pfn_t console_gpfn,
> > +  xen_pfn_t xenstore_gpfn,
> > +  domid_t console_domid,
> > +  domid_t xenstore_domid)
> >  {
> >  int rc;
> >  xen_pfn_t scratch_gpfn;
> > @@ -380,7 +380,7 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t 
> > domid,
> >  return -1;
> >  }
> >  
> > -rc = xc_dom_gnttab_seed(xch, domid,
> > +rc = compat_gnttab_seed(xch, domid,
> >  console_gpfn, xenstore_gpfn,
> >  console_domid, xenstore_domid);
> >  if (rc != 0)
> > @@ -405,18 +405,78 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t 
> > domid,
> >  return 0;
> >  }
> >  
> > -int 

Re: [Xen-devel] [PATCH RFC v1 2/3] libxl: enable per-VCPU work conserving flag for RTDS

[Dario Faggioli]

On Fri, 2017-08-04 at 13:10 +0100, Wei Liu wrote:
> On Fri, Aug 04, 2017 at 10:13:18AM +0200, Dario Faggioli wrote:
> > On Thu, 2017-08-03 at 17:39 -0400, Meng Xu wrote:
> > > 
> > *HOWEVER*, in this case, we do have that 'extratime' field already,
> > as
> > a leftover from SEDF, which is there taking space and cluttering
> > the
> > interface, so why don't make good use of it. Especially considering
> > it
> > was used for _exactly_ the same thing, and with _exactly_ the same
> > meaning, and even for a very similar (i.e., SEDF was also real-
> > time)
> > kind of scheduler.
> 
> Correct me if I'm wrong:
> 
> 1. extratime is ever only used in SEDF
> 2. SEDF is removed
> 
> That means we do have extratime to use in all other schedulers.
> 
I'm not sure what you mean with this last line.

IAC, this is how our the related data structures looks like, right now:

libxl_sched_params = Struct("sched_params",[
("vcpuid",   integer, {'init_val': 
'LIBXL_SCHED_PARAM_VCPU_INDEX_DEFAULT'}),
("weight",   integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT'}),
("cap",  integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT'}),
("period",   integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT'}),
("extratime",integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
("budget",   integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),
])

The extratime field is there. Any scheduler can use it, if it wants
(and in the way it wants). Currently, no one of them does that.

libxl_domain_sched_params = Struct("domain_sched_params",[
("sched",libxl_scheduler),
("weight",   integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT'}),
("cap",  integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT'}),
("period",   integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT'}),
("budget",   integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),

# The following three parameters ('slice', 'latency' and 'extratime') are 
deprecated,
# and will have no effect if used, since the SEDF scheduler has been 
removed.
# Note that 'period' was an SDF parameter too, but it is still effective as 
it is
# now used (together with 'budget') by the RTDS scheduler.
("slice",integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT'}),
("latency",  integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT'}),
("extratime",integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
])

Same here. 'slice', 'latency' and 'extratime' are there because we
deprecate, but don't remove stuff. They're not used in any way. [*]

If, at some point, I'd decide to develop a feature for, say Credit2,
that controll the latency (whatever that would mean, it's just an
example! :-D) of domains, I think I'll use this 'latency' field, for
its interface, instead of adding some other stuff.

> However, please consider the possibility of reintroducing SEDF in the
> future. Suppose that would happen, does extratime still has the same
> semantics?
> 
Well, I guess yes. But how does this matter? Each scheduler can, if it
wants, use all these parameters in the way it actuallly prefers. So,
the fact that RTDS will be using 'extratime' for letting vCPUs execute
past their own real-time reservation, does not prevent the reintroduced
SEDF --nor any other already existing or new scheduler-- to also use
it, for similar (or maybe even not so similar) purposes.

Or am I missing something?

> > IAC, final say is Wei's and Ian's, and although I do have a
> > preference,
> > which I voiced, I'm totally fine with whichever between the two
> > approaches they advise us to take. :-)
> > 
> 
> I will leave this to you two to decide. I don't think I have an
> opinion
> here as long as the things I mentioned above are taken into
> consideration.
>
Ok, thanks. :-)

My preference remains reusing extratime. It's there, it fit the
purpose, I don't see why introducing new fields.

Regards,
Dario

[*] The reason why extratime is in both libxl_sched_params and
libxl_domain_sched_params, while slice and latency (all three of them
were SEDF only parameters) are only in the latter is not really clear
to me right now. libxl_domain_sched_params was there before, and so I
understand why everything is there.

I don't remember why, when adding libxl_sched_params, we decided to add
extratime, as no one was using it... It's quite possible that we did
that, because we knew we could use it in RTDS in future, for this very
purpose! :-)
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___

Re: [Xen-devel] [PATCH v1] tools/libxc: use superpages during restore of HVM guest

[Olaf Hering]

On Fri, Aug 04, Wei Liu wrote:

> Can you split this patch into several:
> 1. code movement
> 2. refactoring / introduction of new hooks
> 3. implementing the new algorithm

I tried that, it did not work well. But, I can try again if required.

Olaf


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

Re: [Xen-devel] [PATCH v1] tools/libxc: use superpages during restore of HVM guest

[Wei Liu]

On Fri, Aug 04, 2017 at 07:43:47AM +0200, Olaf Hering wrote:
> On Wed, Aug 02, Olaf Hering wrote:
> 
> > +++ b/tools/libxc/xc_sr_restore_x86_hvm.c
> 
> > +#define SUPERPAGE_2MB_SHIFT   9
> > +#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
> > +#define SUPERPAGE_1GB_SHIFT   18
> > +#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
> 
> I think these can be moved to a header file. xc_dom_x86.c and
> xc_sr_restore_x86_hvm.c use xc_dom.h.
> 
> > +static int x86_hvm_populate_pfns(struct xc_sr_context *ctx, unsigned count,
> > + const xen_pfn_t *original_pfns,
> > + const uint32_t *types)
> > +{
> > +xc_interface *xch = ctx->xch;
> > +xen_pfn_t min_pfn = original_pfns[0], max_pfn = original_pfns[0];
> > +unsigned i;
> > +int rc = -1;
> > +
> > +for ( i = 0; i < count; ++i )
> > +{
> > +if (original_pfns[i] < min_pfn)
> > +min_pfn = original_pfns[i];
> > +if (original_pfns[i] > max_pfn)
> > +max_pfn = original_pfns[i];
> > +if ( (types[i] != XEN_DOMCTL_PFINFO_XTAB &&
> > +  types[i] != XEN_DOMCTL_PFINFO_BROKEN) &&
> > + !pfn_is_populated(ctx, original_pfns[i]) )
> 
> Are these types used at all for a HVM domU? Otherwise this condition can
> be simplified to just check the populated state.

I *think* XTAB is PV only but BROKEN applies to both PV and HVM.

Maybe someone more familiar with the bit can chime in to provide more
information.

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

Re: [Xen-devel] [PATCH v1] tools/libxc: use superpages during restore of HVM guest

[Wei Liu]

On Wed, Aug 02, 2017 at 03:45:25PM +0200, Olaf Hering wrote:
> During creating of a HVM domU meminit_hvm() tries to map superpages.
> After save/restore or migration this mapping is lost, everything is
> allocated in single pages. This causes a performance degradition after
> migration.
> 
> Add neccessary code to preallocate a superpage for the chunk of pfns
> that is received. In case a pfn was not populated on the sending side it
> must be freed on the receiving side to avoid over-allocation.
> 
> The existing code for x86_pv is moved unmodified into its own file.
> 

Can you split this patch into several:

1. code movement
2. refactoring / introduction of new hooks
3. implementing the new algorithm

Thanks

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

Re: [Xen-devel] [PATCH 5/5] tools/libxenctrl: use new xenforeignmemory API to seed grant table

[Wei Liu]

On Wed, Aug 02, 2017 at 10:59:49AM +0100, Paul Durrant wrote:
> A previous patch added support for priv-mapping guest resources directly
> (rather than having to foreign-map, which requires P2M modification for
> HVM guests).
> 
> This patch makes use of the new API to seed the guest grant table unless
> the underlying infrastructure (i.e. privcmd) doesn't support it, in which
> case the old scheme is used.
> 

The code mostly looks fine.

What's the benefit of doing this?

> NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params() was
>   actually unnecessary, as the grant table has already been seeded
>   by a prior call to xc_dom_gnttab_init() made by libxl__build_dom().
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 

BTW Marek needs to be CC on changes to Python bindings. I've done that
for you.

> ---
>  tools/libxc/include/xc_dom.h|   8 +--
>  tools/libxc/xc_dom_boot.c   | 102 
> 
>  tools/libxc/xc_sr_restore_x86_hvm.c |  10 ++--
>  tools/libxc/xc_sr_restore_x86_pv.c  |   2 +-
>  tools/libxl/libxl_dom.c |   1 -
>  tools/python/xen/lowlevel/xc/xc.c   |   6 +--
>  6 files changed, 92 insertions(+), 37 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index ce47058c41..d6ca0a8680 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -323,12 +323,8 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, 
> xen_pfn_t pfn,
>  int xc_dom_boot_image(struct xc_dom_image *dom);
>  int xc_dom_compat_check(struct xc_dom_image *dom);
>  int xc_dom_gnttab_init(struct xc_dom_image *dom);
> -int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> -   xen_pfn_t console_gmfn,
> -   xen_pfn_t xenstore_gmfn,
> -   domid_t console_domid,
> -   domid_t xenstore_domid);
> -int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
> +int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
> +   bool is_hvm,
> xen_pfn_t console_gmfn,
> xen_pfn_t xenstore_gmfn,
> domid_t console_domid,
> diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
> index c3b44dd399..fc3174ad7e 100644
> --- a/tools/libxc/xc_dom_boot.c
> +++ b/tools/libxc/xc_dom_boot.c
> @@ -280,11 +280,11 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch, 
> domid_t domid)
>  return gmfn;
>  }
>  
> -int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
> -   xen_pfn_t console_gmfn,
> -   xen_pfn_t xenstore_gmfn,
> -   domid_t console_domid,
> -   domid_t xenstore_domid)
> +static int compat_gnttab_seed(xc_interface *xch, domid_t domid,
> +  xen_pfn_t console_gmfn,
> +  xen_pfn_t xenstore_gmfn,
> +  domid_t console_domid,
> +  domid_t xenstore_domid)
>  {
>  
>  xen_pfn_t gnttab_gmfn;
> @@ -337,11 +337,11 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
>  return 0;
>  }
>  
> -int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> -   xen_pfn_t console_gpfn,
> -   xen_pfn_t xenstore_gpfn,
> -   domid_t console_domid,
> -   domid_t xenstore_domid)
> +static int compat_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> +  xen_pfn_t console_gpfn,
> +  xen_pfn_t xenstore_gpfn,
> +  domid_t console_domid,
> +  domid_t xenstore_domid)
>  {
>  int rc;
>  xen_pfn_t scratch_gpfn;
> @@ -380,7 +380,7 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t 
> domid,
>  return -1;
>  }
>  
> -rc = xc_dom_gnttab_seed(xch, domid,
> +rc = compat_gnttab_seed(xch, domid,
>  console_gpfn, xenstore_gpfn,
>  console_domid, xenstore_domid);
>  if (rc != 0)
> @@ -405,18 +405,78 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t 
> domid,
>  return 0;
>  }
>  
> -int xc_dom_gnttab_init(struct xc_dom_image *dom)
> +int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
> +   bool is_hvm, xen_pfn_t console_gmfn,
> +   xen_pfn_t xenstore_gmfn, domid_t console_domid,
> +   domid_t xenstore_domid)
>  {
> -if ( xc_dom_translated(dom) ) {
> -return xc_dom_gnttab_hvm_seed(dom->xch, dom->guest_domid,
> -  dom->console_pfn, dom->xenstore_pfn,
> -

Re: [Xen-devel] [PATCH 4/5] tools/libxenforeignmemory: add support for resource mapping

[Wei Liu]

On Wed, Aug 02, 2017 at 10:59:48AM +0100, Paul Durrant wrote:
> A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
> resources for direct priv-mapping.
> 
> This patch adds new functionality into libxenforeignmemory to make use
> of a new privcmd ioctl [1] that uses the new memory op to make such
> resources available via mmap(2).
> 
> [1] 
> http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=c5cf2b15f7a448277716a7e96fea1c93df6c17a5
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/include/xen-sys/Linux/privcmd.h  | 11 ++
>  tools/libs/foreignmemory/core.c| 42 
>  .../libs/foreignmemory/include/xenforeignmemory.h  | 39 +++
>  tools/libs/foreignmemory/libxenforeignmemory.map   |  5 +++
>  tools/libs/foreignmemory/linux.c   | 45 
> ++
>  tools/libs/foreignmemory/private.h | 30 +++
>  6 files changed, 172 insertions(+)

You forgot to bump the version number in Makefile

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

Re: [Xen-devel] [PATCH RFC v1 2/3] libxl: enable per-VCPU work conserving flag for RTDS

[Wei Liu]

On Tue, Aug 01, 2017 at 02:33:53PM -0400, Meng Xu wrote:
> Modify libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set
> functions to support per-VCPU work conserving flag
> 
> Signed-off-by: Meng Xu 
> ---
>  tools/libxl/libxl.h | 1 +

Missing a LIBXL_HAVE

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

Re: [Xen-devel] [PATCH RFC v1 2/3] libxl: enable per-VCPU work conserving flag for RTDS

[Wei Liu]

On Fri, Aug 04, 2017 at 10:13:18AM +0200, Dario Faggioli wrote:
> On Thu, 2017-08-03 at 17:39 -0400, Meng Xu wrote:
> > On Thu, Aug 3, 2017 at 11:53 AM, Dario Faggioli
> >  wrote:
> > > 
> > > How about, here at libxl level, we use the "extratime" field that
> > > we
> > > have as a leftover from SEDF (and which had, in that scheduler, a
> > > similar meaning)?
> > > 
> > > If we don't want to use that one, and we want a new field, I
> > > suggest
> > > thinking to a shorter name.
> > 
> > How about 'LIBXL_DOMAIN_SCHED_PARAM_FLAG'?
> > We use a bit in the flag field in the sched_rt.c to indicate if a
> > VCPU
> > is work-conserving. 
> >
> This is entirely in the hands of tools maintainers, especially
> considering this is the libxl API.
> 
> In general, yes, for the same reasons I suggested using flags in both
> Xen interface and implementation, I also like using flags here. 
> 
> *HOWEVER*, in this case, we do have that 'extratime' field already, as
> a leftover from SEDF, which is there taking space and cluttering the
> interface, so why don't make good use of it. Especially considering it
> was used for _exactly_ the same thing, and with _exactly_ the same
> meaning, and even for a very similar (i.e., SEDF was also real-time)
> kind of scheduler.

Correct me if I'm wrong:

1. extratime is ever only used in SEDF
2. SEDF is removed

That means we do have extratime to use in all other schedulers.

However, please consider the possibility of reintroducing SEDF in the
future. Suppose that would happen, does extratime still has the same
semantics?

> 
> Also, note that Xen interface and libxl API are different, and the same
> concepts, does not necessarily have to be used in lockstep. It may or
> may not be the best/easies/whatever thing to actually do, but on a case
> by case basis.
> 

Indeed.

> IAC, final say is Wei's and Ian's, and although I do have a preference,
> which I voiced, I'm totally fine with whichever between the two
> approaches they advise us to take. :-)
> 

I will leave this to you two to decide. I don't think I have an opinion
here as long as the things I mentioned above are taken into
consideration.

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ef3d1df77bbd5227c76306e5c64c66d82805bbd9
baseline version:
 ovmf 09cc872d0242304329e6c21e91bef14fa9949744

Last test of basis   112433  2017-08-04 00:48:35 Z0 days
Testing same since   112439  2017-08-04 08:03:58 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Eric Dong 
  Fu Siyuan 
  Hao Wu 
  Star Zeng 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v15 01/23] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document

[Wei Liu]

On Fri, Aug 04, 2017 at 12:40:25PM +0800, Yi Sun wrote:
> On 17-08-03 13:26:37, Wei Liu wrote:
> > On Tue, Aug 01, 2017 at 04:48:32PM +0800, Yi Sun wrote:
> > > This patch creates CAT and CDP feature document in doc/features/. It 
> > > describes
> > > key points to implement L3 CAT/CDP and L2 CAT which is described in 
> > > details in
> > > Intel SDM "INTEL? RESOURCE DIRECTOR TECHNOLOGY (INTEL? RDT) ALLOCATION 
> > > FEATURES".
> > > 
> > > Signed-off-by: Yi Sun 
> > > Reviewed-by: Konrad Rzeszutek Wilk 
> > > Reviewed-by: Wei Liu 
> > 
> > https://travis-ci.org/xen-project/xen/jobs/260567408
> > 
> > pandoc: Cannot decode byte '\xae': Data.Text.Encoding.Fusion.streamUtf8: 
> > Invalid UTF-8 stream
> > 
> > Please submit a patch to fix it.
> 
> I am afraid this is caused by the special charactor '®' (ASCII: xAE) as below:
> "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION FEATURES" 
> [Intel® 64 and IA-32 Architectures Software Developer Manuals, 
> vol3](http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html)
> 
> I have removed it from the doc and created a patch. But before send the patch
> out, how can I have a test to check if my assumption is correct?
> 
> I have executed 'make dist' and did not see any issue. But I met below error
> when I tried './scripts/travis-build' after the full build.

That script is not supposed to run by you directly. The error is
irrelevant to your changes.

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

Re: [Xen-devel] [PATCH v4 06/13] libxl: change p9 to use generec add function

[Wei Liu]

On Wed, Aug 02, 2017 at 02:37:10PM +0300, Oleksandr Grytsov wrote:
[...]
> >> >> From other side this rename touches only internals changes: no changes
> >> >> in config file
> >> >> or CLI interface.
> >> >>
> >> >
> >> > As said, the framework need to be ready to deal with PCI anyway.
> >> >
> >> > What sort of issues do you foresee here?
> >>
> >> Do you mean in case to rework PCI to use the device framework?
> >>
> >
> > No, I mean adding the new hook. You said "handle irregular device name
> > looks not so good"
> 
> As for me when only internal name of structure or fields are changed
> then it should not break anyone configs, setup etc.
> Creating hooks in this case makes code hard to read and maintain.
> 

I think you missed my points:

1. libxl types generated from libxl_types.idl aren't just used by xl.
Some applications will use libxl types directly. Not breaking xl config
doesn't mean not breaking other toolstacks like libvirt. In this
particular case, I think we might be able to change p9 to p9s because it
is only released a few months back because the only other known
toolstack that uses libxl can't possibly use that field at the moment.
But Ian might disagree.

2. There is another type, pci dev, that has been there since forever. We
need a hook to deal with it, we can't rename it.

1 and 2 are orthogonal. 2 is a hard requirement.

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

[Xen-devel] [xen-unstable-smoke test] 112440: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 
112402
 test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 112402

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  dbf2a768565d8b79c65471a3d3b982b2874d6492
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112402  2017-07-31 21:02:08 Z3 days
Testing same since   112418  2017-08-03 11:04:58 Z1 days   10 attempts


People who touched revisions under test:
  Andrii Anisov 
  He Chen 
  Iurii Konovalenko 
  Iurii Mykhalskyi 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Praveen Kumar 
  Rusty Bird 
  Sergej Proskurin 
  Stefano Stabellini 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Not pushing.

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

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

Re: [Xen-devel] [PATCH v4] x86/hvm: Allow guest_request vm_events coming from userspace

[Andrew Cooper]

On 04/08/17 12:32, Alexandru Isaila wrote:
> In some introspection usecases, an in-guest agent needs to communicate
> with the external introspection agent.  An existing mechanism is
> HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
> like all other hypercalls.
>
> Introduce a mechanism whereby the introspection agent can whitelist the
> use of HVMOP_guest_request_vm_event directly from userspace.
>
> Signed-off-by: Alexandru Isaila 

Reviewed-by: Andrew Cooper , with one note to
whoever commits it...

> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
> index 451f42f..21a1457 100644
> --- a/xen/common/monitor.c
> +++ b/xen/common/monitor.c
> @@ -79,6 +79,20 @@ int monitor_domctl(struct domain *d, struct 
> xen_domctl_monitor_op *mop)
>  break;
>  }
>  
> +case XEN_DOMCTL_MONITOR_EVENT_GUEST_USERSPACE_EVENT:
> +{
> +bool_t old_status = d->monitor.guest_request_enabled;

bool.

~Andrew

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

Re: [Xen-devel] [PATCH v2 3/3] x86/vlapic: Apply change to TDCR right away to the timer

[Anthony PERARD]

On Thu, Aug 03, 2017 at 09:29:02AM -0600, Jan Beulich wrote:
> >>> Anthony PERARD  07/18/17 7:10 PM >>>
> >@@ -701,6 +702,13 @@ static void vlapic_update_timer(struct vlapic *vlapic, 
> >uint32_t lvtt);
> >delta = period - time_passed;
> >}
>  >
> >+if ( vlapic->hw.timer_divisor != old_divisor )
> >+{
> >+period = (uint64_t)vlapic_get_reg(vlapic, APIC_TMICT)
> >+* APIC_BUS_CYCLE_NS * vlapic->hw.timer_divisor;
> >+delta = delta * vlapic->hw.timer_divisor / old_divisor;
> >+}
> 
> Isn't this calculation pointless when delta is zero?

Yeah, I guess it is. I'll move this if block into the next one, which is
if (delta && X).

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2 2/3] x86/vlapic: Keep timer running when switching between one-shot and periodic mode

[Anthony PERARD]

On Thu, Aug 03, 2017 at 09:21:57AM -0600, Jan Beulich wrote:
> >>> Anthony PERARD  07/18/17 7:12 PM >>>
> >@@ -678,18 +679,29 @@ static void vlapic_tdt_pt_cb(struct vcpu *v, void 
> >*data)
> >static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt);
> >{
> >uint64_t period;
> >-uint64_t delta;
> >-bool is_periodic;
> >+uint64_t delta = 0;
> >+bool is_oneshot, is_periodic;
>  >
> >is_periodic = (lvtt & APIC_TIMER_MODE_MASK) == APIC_TIMER_MODE_PERIODIC;
> >+is_oneshot = (lvtt & APIC_TIMER_MODE_MASK) == APIC_TIMER_MODE_ONESHOT;
>  >
>  >period = (uint64_t)vlapic_get_reg(vlapic, APIC_TMICT)
> >* APIC_BUS_CYCLE_NS * vlapic->hw.timer_divisor;
>  >
> >/* Calculate the next time the timer should trigger an interrupt. */
> >-delta = period;
> >+if ( period && vlapic->timer_last_update )
> >+{
> >+uint64_t time_passed = hvm_get_guest_time(current)
> >+- vlapic->timer_last_update;
> >+
> >+/* This depends of the previous mode, if a new mode is set */
> 
> It's nice that you add such a comment, but this really documents a
> requirement the caller has to fulfill, so I'm afraid it's somewhat misplaced.

It's a comment about why I'm using vlapic_lvtt_period() here instead of
the local variable is_periodic. Also, the requirement for the caller is
already documented.

> >+if ( vlapic_lvtt_period(vlapic) )
> >+time_passed %= period;
> >+if ( time_passed < period )
> >+delta = period - time_passed;
> 
> Why is this second step not also dependent on the timer previously
> having been periodic? This is particularly relevant in connection with ...

This is the same algorithme as the one used to calculate the current
value of the counter register TMCCT. The second steps only depends on
when the initial-counter register TMICT was set and what is value was.
Since the periodicity of the timer is been take care in the first step,
it does not matter any more if the timer was previously periodic or
one-shot.

"period" here is the initial value of the counter and "time_passed"
correspond to how much time have passed since TMCCT have been reset to
the value in TMICT, either because TMICT was set or because the timer
was periodic.

> >+}
>  >
> >-if ( delta )
> >+if ( delta && (is_oneshot || is_periodic) )
> >{
> >TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(delta),
> >TRC_PAR_LONG(is_periodic ? period : 0LL),
> >@@ -702,7 +714,11 @@ static void vlapic_update_timer(struct vlapic *vlapic, 
> >uint32_t lvtt);
> >is_periodic ? vlapic_pt_cb : NULL,
> >>timer_last_update);
>  >
> >-vlapic->timer_last_update = vlapic->pt.last_plt_gtime;
> >+/* For the case where the timer was periodic and it is now
> >+ * one-shot, timer_last_update should be the value of the last time
> >+ * the interrupt was triggered.
> >+ */
> >+vlapic->timer_last_update = vlapic->pt.last_plt_gtime + delta - 
> >period;
>  
> ,,, this. Note how the comment talks about a change from one-shot to
> periodic, but how the code does not obviously alter behavior in only that
> one case.

I need to think about it.

When TMICT is changed, delta == period, so the value is not altered.

When the timer mode is changed, delta and period are going to be
different. And the difference is going to be, how much time have passed
since TMICT was set or since the last time a periodic timer reach 0.

So the comment is inappropriate here. It might be usefull in the commit
message, and I may need a better comment on why I'm doing +delta-period.

> >@@ -818,6 +840,7 @@ static void vlapic_reg_write(struct vcpu *v,
> >if ( !vlapic_lvtt_oneshot(vlapic) && !vlapic_lvtt_period(vlapic) )
> >break;
>  >
> >+vlapic->timer_last_update = hvm_get_guest_time(current);
> >vlapic_set_reg(vlapic, APIC_TMICT, val);
>  >
> >vlapic_update_timer(vlapic, vlapic_get_reg(vlapic, APIC_LVTT));
> 
> Why is this addition needed? vlapic_update_timer() sets timer_last_update
> anyway. As it looks all you want is the value to be non-zero, which can be
> done with less overhead and should be stated so in a comment.

This is not true, the value is used before been set. It is used to
calculate how much time have passed since tmict was set. Before been set
again, there is this:
time_passed = hvm_get_guest_time(current) - vlapic->timer_last_update;

-- 
Anthony PERARD

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

[Xen-devel] [PATCH 2/3] xen: remove unused function xen_set_domain_pte()

[Juergen Gross]

The function xen_set_domain_pte() is used nowhere in the kernel.
Remove it.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/xen/page.h |  2 --
 arch/x86/xen/mmu_pv.c   | 20 
 include/trace/events/xen.h  | 18 --
 3 files changed, 40 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 497f7d28c1d6..07b6531813c4 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -314,8 +314,6 @@ static inline pte_t __pte_ma(pteval_t x)
 #define p4d_val_ma(x)  ((x).p4d)
 #endif
 
-void xen_set_domain_pte(pte_t *ptep, pte_t pteval, unsigned domid);
-
 xmaddr_t arbitrary_virt_to_machine(void *address);
 unsigned long arbitrary_virt_to_mfn(void *vaddr);
 void make_lowmem_page_readonly(void *vaddr);
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index cab28cf2cffb..0422ee7e70b3 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -162,26 +162,6 @@ static bool xen_page_pinned(void *ptr)
return PagePinned(page);
 }
 
-void xen_set_domain_pte(pte_t *ptep, pte_t pteval, unsigned domid)
-{
-   struct multicall_space mcs;
-   struct mmu_update *u;
-
-   trace_xen_mmu_set_domain_pte(ptep, pteval, domid);
-
-   mcs = xen_mc_entry(sizeof(*u));
-   u = mcs.args;
-
-   /* ptep might be kmapped when using 32-bit HIGHPTE */
-   u->ptr = virt_to_machine(ptep).maddr;
-   u->val = pte_val_ma(pteval);
-
-   MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, domid);
-
-   xen_mc_issue(PARAVIRT_LAZY_MMU);
-}
-EXPORT_SYMBOL_GPL(xen_set_domain_pte);
-
 static void xen_extend_mmu_update(const struct mmu_update *update)
 {
struct multicall_space mcs;
diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
index b70a38b7fa84..677e8ac2bb81 100644
--- a/include/trace/events/xen.h
+++ b/include/trace/events/xen.h
@@ -149,24 +149,6 @@ DECLARE_EVENT_CLASS(xen_mmu__set_pte,
 DEFINE_XEN_MMU_SET_PTE(xen_mmu_set_pte);
 DEFINE_XEN_MMU_SET_PTE(xen_mmu_set_pte_atomic);
 
-TRACE_EVENT(xen_mmu_set_domain_pte,
-   TP_PROTO(pte_t *ptep, pte_t pteval, unsigned domid),
-   TP_ARGS(ptep, pteval, domid),
-   TP_STRUCT__entry(
-   __field(pte_t *, ptep)
-   __field(pteval_t, pteval)
-   __field(unsigned, domid)
-   ),
-   TP_fast_assign(__entry->ptep = ptep;
-  __entry->pteval = pteval.pte;
-  __entry->domid = domid),
-   TP_printk("ptep %p pteval %0*llx (raw %0*llx) domid %u",
- __entry->ptep,
- (int)sizeof(pteval_t) * 2, (unsigned long 
long)pte_val(native_make_pte(__entry->pteval)),
- (int)sizeof(pteval_t) * 2, (unsigned long 
long)__entry->pteval,
- __entry->domid)
-   );
-
 TRACE_EVENT(xen_mmu_set_pte_at,
TP_PROTO(struct mm_struct *mm, unsigned long addr,
 pte_t *ptep, pte_t pteval),
-- 
2.12.3


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

[Xen-devel] [PATCH 1/3] xen: remove tests for pvh mode in pure pv paths

[Juergen Gross]

Remove the last tests for XENFEAT_auto_translated_physmap in pure
PV-domain specific paths. PVH V1 is gone and the feature will always
be "false" in PV guests.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/xen/page.h |  3 ---
 arch/x86/xen/p2m.c  | 25 +
 arch/x86/xen/setup.c|  5 +
 3 files changed, 2 insertions(+), 31 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 8417ef7c3885..497f7d28c1d6 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -158,9 +158,6 @@ static inline unsigned long 
mfn_to_pfn_no_overrides(unsigned long mfn)
unsigned long pfn;
int ret;
 
-   if (xen_feature(XENFEAT_auto_translated_physmap))
-   return mfn;
-
if (unlikely(mfn >= machine_to_phys_nr))
return ~0;
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 276da636dd39..6083ba462f35 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -212,8 +212,7 @@ void __ref xen_build_mfn_list_list(void)
unsigned int level, topidx, mididx;
unsigned long *mid_mfn_p;
 
-   if (xen_feature(XENFEAT_auto_translated_physmap) ||
-   xen_start_info->flags & SIF_VIRT_P2M_4TOOLS)
+   if (xen_start_info->flags & SIF_VIRT_P2M_4TOOLS)
return;
 
/* Pre-initialize p2m_top_mfn to be completely missing */
@@ -269,9 +268,6 @@ void __ref xen_build_mfn_list_list(void)
 
 void xen_setup_mfn_list_list(void)
 {
-   if (xen_feature(XENFEAT_auto_translated_physmap))
-   return;
-
BUG_ON(HYPERVISOR_shared_info == _dummy_shared_info);
 
if (xen_start_info->flags & SIF_VIRT_P2M_4TOOLS)
@@ -291,9 +287,6 @@ void __init xen_build_dynamic_phys_to_machine(void)
 {
unsigned long pfn;
 
-if (xen_feature(XENFEAT_auto_translated_physmap))
-   return;
-
xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
xen_p2m_size = ALIGN(xen_start_info->nr_pages, P2M_PER_PAGE);
 
@@ -540,9 +533,6 @@ int xen_alloc_p2m_entry(unsigned long pfn)
unsigned long addr = (unsigned long)(xen_p2m_addr + pfn);
unsigned long p2m_pfn;
 
-   if (xen_feature(XENFEAT_auto_translated_physmap))
-   return 0;
-
ptep = lookup_address(addr, );
BUG_ON(!ptep || level != PG_LEVEL_4K);
pte_pg = (pte_t *)((unsigned long)ptep & ~(PAGE_SIZE - 1));
@@ -640,9 +630,6 @@ unsigned long __init set_phys_range_identity(unsigned long 
pfn_s,
if (unlikely(pfn_s >= xen_p2m_size))
return 0;
 
-   if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
-   return pfn_e - pfn_s;
-
if (pfn_s > pfn_e)
return 0;
 
@@ -660,10 +647,6 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned 
long mfn)
pte_t *ptep;
unsigned int level;
 
-   /* don't track P2M changes in autotranslate guests */
-   if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
-   return true;
-
if (unlikely(pfn >= xen_p2m_size)) {
BUG_ON(mfn != INVALID_P2M_ENTRY);
return true;
@@ -711,9 +694,6 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref 
*map_ops,
int i, ret = 0;
pte_t *pte;
 
-   if (xen_feature(XENFEAT_auto_translated_physmap))
-   return 0;
-
if (kmap_ops) {
ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
kmap_ops, count);
@@ -756,9 +736,6 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref 
*unmap_ops,
 {
int i, ret = 0;
 
-   if (xen_feature(XENFEAT_auto_translated_physmap))
-   return 0;
-
for (i = 0; i < count; i++) {
unsigned long mfn = __pfn_to_mfn(page_to_pfn(pages[i]));
unsigned long pfn = page_to_pfn(pages[i]);
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index c81046323ebc..ac55c02f98e9 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -340,8 +340,6 @@ static void __init xen_do_set_identity_and_remap_chunk(
 
WARN_ON(size == 0);
 
-   BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
-
mfn_save = virt_to_mfn(buf);
 
for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
@@ -1024,8 +1022,7 @@ void __init xen_pvmmu_arch_setup(void)
 void __init xen_arch_setup(void)
 {
xen_panic_handler_init();
-   if (!xen_feature(XENFEAT_auto_translated_physmap))
-   xen_pvmmu_arch_setup();
+   xen_pvmmu_arch_setup();
 
 #ifdef CONFIG_ACPI
if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
-- 
2.12.3


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

[Xen-devel] [PATCH 0/3] xen: do some cleanups

[Juergen Gross]

Remove stuff no longer needed.

Juergen Gross (3):
  xen: remove tests for pvh mode in pure pv paths
  xen: remove unused function xen_set_domain_pte()
  xen: remove not used trace functions

 arch/x86/include/asm/xen/page.h |  5 -
 arch/x86/xen/mmu_pv.c   | 20 
 arch/x86/xen/p2m.c  | 25 +
 arch/x86/xen/setup.c|  5 +
 include/trace/events/xen.h  | 38 --
 5 files changed, 2 insertions(+), 91 deletions(-)

-- 
2.12.3


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

[Xen-devel] [PATCH 3/3] xen: remove not used trace functions

[Juergen Gross]

There are some Xen specific trace functions defined in
include/trace/events/xen.h. Remove them.

Signed-off-by: Juergen Gross 
---
 include/trace/events/xen.h | 20 
 1 file changed, 20 deletions(-)

diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
index 677e8ac2bb81..1b4fed72f573 100644
--- a/include/trace/events/xen.h
+++ b/include/trace/events/xen.h
@@ -248,16 +248,6 @@ TRACE_EVENT(xen_mmu_set_p4d,
  (int)sizeof(p4dval_t) * 2, (unsigned long 
long)pgd_val(native_make_pgd(__entry->p4dval)),
  (int)sizeof(p4dval_t) * 2, (unsigned long 
long)__entry->p4dval)
);
-
-TRACE_EVENT(xen_mmu_pud_clear,
-   TP_PROTO(pud_t *pudp),
-   TP_ARGS(pudp),
-   TP_STRUCT__entry(
-   __field(pud_t *, pudp)
-   ),
-   TP_fast_assign(__entry->pudp = pudp),
-   TP_printk("pudp %p", __entry->pudp)
-   );
 #else
 
 TRACE_EVENT(xen_mmu_set_pud,
@@ -277,16 +267,6 @@ TRACE_EVENT(xen_mmu_set_pud,
 
 #endif
 
-TRACE_EVENT(xen_mmu_pgd_clear,
-   TP_PROTO(pgd_t *pgdp),
-   TP_ARGS(pgdp),
-   TP_STRUCT__entry(
-   __field(pgd_t *, pgdp)
-   ),
-   TP_fast_assign(__entry->pgdp = pgdp),
-   TP_printk("pgdp %p", __entry->pgdp)
-   );
-
 DECLARE_EVENT_CLASS(xen_mmu_ptep_modify_prot,
TP_PROTO(struct mm_struct *mm, unsigned long addr,
 pte_t *ptep, pte_t pteval),
-- 
2.12.3


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

[Xen-devel] [PATCH v4] x86/hvm: Allow guest_request vm_events coming from userspace

[Alexandru Isaila]

In some introspection usecases, an in-guest agent needs to communicate
with the external introspection agent.  An existing mechanism is
HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
like all other hypercalls.

Introduce a mechanism whereby the introspection agent can whitelist the
use of HVMOP_guest_request_vm_event directly from userspace.

Signed-off-by: Alexandru Isaila 

---
Changes since V3:
- Changed commit message
- Added new lines
- Indent the maximum space on the defines
- Chaned the name of the define/function name/struct member
  from vmcall to event
---
 tools/libxc/include/xenctrl.h |  1 +
 tools/libxc/xc_monitor.c  | 14 ++
 xen/arch/x86/hvm/hypercall.c  |  5 +
 xen/common/monitor.c  | 14 ++
 xen/include/public/domctl.h   | 21 +++--
 xen/include/xen/sched.h   |  5 +++--
 6 files changed, 48 insertions(+), 12 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index bde8313..90a056f 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2022,6 +2022,7 @@ int xc_monitor_descriptor_access(xc_interface *xch, 
domid_t domain_id,
  bool enable);
 int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
  bool enable, bool sync);
+int xc_allow_guest_userspace_event(xc_interface *xch, domid_t domain_id, bool 
enable);
 int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
 bool enable, bool sync);
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b44ce93..6064c39 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -161,6 +161,20 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
domain_id, bool enable,
 return do_domctl(xch, );
 }
 
+int xc_allow_guest_userspace_event(xc_interface *xch, domid_t domain_id, bool 
enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_GUEST_USERSPACE_EVENT;
+
+return do_domctl(xch, );
+}
+
+
 int xc_monitor_emulate_each_rep(xc_interface *xch, domid_t domain_id,
 bool enable)
 {
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index e7238ce..8eb5f49 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -155,6 +155,11 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 /* Fallthrough to permission check. */
 case 4:
 case 2:
+if ( currd->monitor.guest_request_userspace_event &&
+eax == __HYPERVISOR_hvm_op &&
+(mode == 8 ? regs->rdi : regs->ebx) == 
HVMOP_guest_request_vm_event )
+break;
+
 if ( unlikely(hvm_get_cpl(curr)) )
 {
 default:
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index 451f42f..21a1457 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -79,6 +79,20 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 break;
 }
 
+case XEN_DOMCTL_MONITOR_EVENT_GUEST_USERSPACE_EVENT:
+{
+bool_t old_status = d->monitor.guest_request_enabled;
+
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;
+
+domain_pause(d);
+d->monitor.guest_request_sync = mop->u.guest_request.sync;
+d->monitor.guest_request_userspace_event = requested_status;
+domain_unpause(d);
+break;
+}
+
 default:
 /* Give arch-side the chance to handle this event */
 return arch_monitor_domctl_event(d, mop);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index ff39762..870495c 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1073,16 +1073,17 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
 #define XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES  2
 #define XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP  3
 
-#define XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG 0
-#define XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR1
-#define XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP2
-#define XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT   3
-#define XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST 4
-#define XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION   5
-#define XEN_DOMCTL_MONITOR_EVENT_CPUID 6
-#define XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL   7
-#define XEN_DOMCTL_MONITOR_EVENT_INTERRUPT 8
-#define XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS   9
+#define XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 09cc872d0242304329e6c21e91bef14fa9949744
baseline version:
 ovmf bb4831c03dd15ff8528dcdbc7d2ad1835f55563e

Last test of basis71934  2017-08-04 00:19:04 Z0 days
Testing same since71937  2017-08-04 08:18:46 Z0 days1 attempts


People who touched revisions under test:
  Michael D Kinney 

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



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

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

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


Push not applicable.


commit 09cc872d0242304329e6c21e91bef14fa9949744
Author: Michael D Kinney 
Date:   Thu Aug 3 11:44:31 2017 -0700

OvmfPkg: Undo removal of License.txt

Undo removal of OvmfPkg/License.txt in commit


https://github.com/tianocore/edk2/commit/2a98de03444e6a1e04030e70bb85e62de6b82edc

Cc: Leif Lindholm 
Cc: Andrew Fish 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
Reviewed-by: Jordan Justen 
Reviewed-by: Leif Lindholm 

commit 827a09d0246b64ce0553e8e87d819bcc773b1d6f
Author: Michael D Kinney 
Date:   Wed Jul 19 14:28:14 2017 -0700

edk2: Add Readme.md to root of edk2 repository

https://bugzilla.tianocore.org/show_bug.cgi?id=643

Add Readme.md with a brief description of the EDK II
open source project along with links to contribution
agreement, licenses, and resources.

Cc: Leif Lindholm 
Cc: Andrew Fish 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
Reviewed-by: Jordan Justen 
Reviewed-by: Leif Lindholm 

commit 2a98de03444e6a1e04030e70bb85e62de6b82edc
Author: Michael D Kinney 
Date:   Wed Jul 19 14:30:30 2017 -0700

edk2: Move License.txt file to root

https://bugzilla.tianocore.org/show_bug.cgi?id=642

Add top level License.txt file with the BSD 2-Clause
License that is used by the majority of the EKD II open
source project content.  Merge copyright statements
from the BSD 2-Clause License files in each package
directory and remove the duplication License.txt
file from package directories.

Cc: Leif Lindholm 
Cc: Andrew Fish 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
Reviewed-by: Jordan Justen 
Reviewed-by: Leif Lindholm 

commit f4a8878b090ced9175ee343f20838a15dfa74ae2
Author: Michael D Kinney 
Date:   Mon Jul 24 14:53:10 2017 -0700

edk2: Reformat TianoCore Contribution Agreement 1.1

https://bugzilla.tianocore.org/show_bug.cgi?id=629

Update formatting of Contributions.txt to line wrap
at 80 columns.

Cc: Leif Lindholm 
Cc: Andrew Fish 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
Reviewed-by: Jordan Justen 
Reviewed-by: Leif Lindholm 

[Xen-devel] [distros-debian-jessie test] 71936: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

flight 71936 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71936/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 6 kernel-build  fail REGR. vs. 71901

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-jessie-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-i386-jessie-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-jessie-netboot-pvgrub  1 build-check(1) blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken like 71901
 build-arm64   2 hosts-allocate   broken like 71901
 build-arm64-pvops 3 capture-logs broken like 71901
 build-arm64   3 capture-logs broken like 71901
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 migrate-support-check fail 
blocked in 71901
 test-armhf-armhf-armhf-jessie-netboot-pygrub 13 saverestore-support-check fail 
blocked in 71901
 test-armhf-armhf-armhf-jessie-netboot-pygrub 15 guest-start/debian.repeat fail 
blocked in 71901

baseline version:
 flight   71901

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopsfail
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub blocked 
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-arm64-arm64-armhf-jessie-netboot-pygrub blocked 
 test-armhf-armhf-armhf-jessie-netboot-pygrub fail
 test-amd64-amd64-i386-jessie-netboot-pygrub  blocked 



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

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

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


Push not applicable.


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

Re: [Xen-devel] [Patch for staging 1/2] docs: remove a special character to avoid html creation error.

[Wei Liu]

On Fri, Aug 04, 2017 at 05:29:36PM +0800, Yi Sun wrote:
> The '®' (a special character) may cause html document creation
> failure. So remove it from the feature document.

Not sure how you tested it but the original error was found by pandoc.

> 
> Signed-off-by: Yi Sun 

Change looks good:

Tested-by: Wei Liu 
Acked-by: Wei Liu 

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

[Xen-devel] [qemu-upstream-unstable baseline-only test] 71935: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71935 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71935/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
71596

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 19 leak-check/check  fail REGR. vs. 71596
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 71596

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-libvirt14 saverestore-support-check fail blocked in 71596
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail blocked in 71596
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail blocked in 71596
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-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  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 qemuuc7c6232bd304568d4da4bef521603aae0035e172
baseline version:
 qemuu414d069b38ab114b89085e44989bf57604ea86d7

Last test of basis71596  2017-06-25 05:14:43 Z   40 days
Testing same since71935  2017-08-04 05:54:01 Z0 days1 attempts


People who touched revisions under test:
  Alastair D'Silva 
  Alberto Garcia 
  Alex Bennée 
  Alex Kompel 
  Alex Williamson 
  Alex Zuepke 
  Alexander Boettcher 
  Alexander Graf 
  Alexander Indenbaum 
  Alexey Kardashevskiy 
  Alistair Francis 
  Allan Wirth 
  Amit Shah 

Re: [Xen-devel] [PATCH v2] xl: add --clear option to dmesg command

[Wei Liu]

On Fri, Aug 04, 2017 at 11:57:53AM +0100, Wei Liu wrote:
> On Tue, Aug 01, 2017 at 05:10:27PM +0100, Wei Liu wrote:
> > On Tue, Aug 01, 2017 at 11:57:50PM +0800, Xiao Liang wrote:
> > > From: xiliang 
> > > 
> > > The manual of xl says --clear option is supported and that option worked 
> > > for xm. Add that to xl now.
> > 
> > I will wrap this long line to 72 columns while committing.
> > 
> > > 
> > > Signed-off-by: xiliang 
> 
> I was about to commit this, but I realised "xiliang" as your name seems
> wrong. Should it be "Xi Liang" instead?

I think it should be "Xiao Liang" because that is what is in your email
handle.

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

Re: [Xen-devel] [PATCH v2] xl: add --clear option to dmesg command

[Wei Liu]

On Tue, Aug 01, 2017 at 05:10:27PM +0100, Wei Liu wrote:
> On Tue, Aug 01, 2017 at 11:57:50PM +0800, Xiao Liang wrote:
> > From: xiliang 
> > 
> > The manual of xl says --clear option is supported and that option worked 
> > for xm. Add that to xl now.
> 
> I will wrap this long line to 72 columns while committing.
> 
> > 
> > Signed-off-by: xiliang 

I was about to commit this, but I realised "xiliang" as your name seems
wrong. Should it be "Xi Liang" instead?

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

Re: [Xen-devel] [PATCH v2 1/3] x86/vlapic: Introduce vlapic_update_timer

[Anthony PERARD]

On Thu, Aug 03, 2017 at 08:59:10AM -0600, Jan Beulich wrote:
> >>> Anthony PERARD  07/18/17 7:10 PM >>>
> >There should not be any functionality change with this patch.
> >
> >This function is used when the APIC_TMICT register is updated.
> >
> >vlapic_update_timer is introduce as it will be use also when the
> >registers APIC_LVTT and APIC_TDCR are updated.
> >
> >Signed-off-by: Anthony PERARD 
> >---
> 
> Missing brief revision log here.

It would have been "New patch", since I've rewrite all patches and
reorganize the serie. But the revision log is in the cover letter.

> >+static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt);
> >+{
> >+uint64_t period;
> >+uint64_t delta;
> 
> Why two lines (but see also below)?

Why not? Anyway, I'll change it.

Also I realize that delta is going to be initialize to 0 here in the
next patch, which is why I think there is two lines.

> >+bool is_periodic;
> >+
> >+is_periodic = (lvtt & APIC_TIMER_MODE_MASK) == APIC_TIMER_MODE_PERIODIC;
> >+
> >+period = (uint64_t)vlapic_get_reg(vlapic, APIC_TMICT)
> >+* APIC_BUS_CYCLE_NS * vlapic->hw.timer_divisor;
> >+
> >+/* Calculate the next time the timer should trigger an interrupt. */
> >+delta = period;
> 
> What is the point of having the same value in two variables?

It might look like it but there are not the same values, the description
is accurate, even if the calculation at this stage is very simple.

More importantly, this line is going away in the next patch and will be
replaced by a more complexe calculation.


Thanks,

-- 
Anthony PERARD

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

[Xen-devel] [linux-3.18 test] 112431: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale  16 guest-start/debian.repeat  fail pass in 112421
 test-armhf-armhf-xl-multivcpu  6 xen-install   fail pass in 112421

Regressions which are regarded as allowable (not blocking):
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64   2 hosts-allocate broken REGR. vs. 112102

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 build-arm64   3 capture-logs  broken blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 112102
 test-amd64-i386-freebsd10-amd64 19 guest-start/freebsd.repeat fail in 112421 
like 112085
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 112421 never 
pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 112421 
never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112085
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail 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  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-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-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-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
 

Re: [Xen-devel] Next Xen ARM community call - Wednesday 2nd August 2017

[Mirela Simonovic]

Hi Stefano,

Thank you, we're looking into this.

Regards,
Mirela

On Wed, Aug 2, 2017 at 8:25 PM, Stefano Stabellini 
wrote:

> Hi everybody,
>
> the Xen based suspend notification interface is implemented in Linux by
> drivers/xen/manage.c. The guest monitors a node on xenstore named
> "control/shutdown", one of the possible commands is "suspend".
>
> See the corresponding libxl__domain_pvcontrol_* functions and their
> callers under tools/libxl. You can see that libxl is able to detect if
> the PV protocol is supported by the guest calling
> libxl__domain_pvcontrol_available, although the detection wouldn't work
> today for ARM guests.
>
> You might also want to give a look at drivers/xen/cpu_hotplug.c (also in
> Linux) which is the implementation of the PV cpu hotplug protocol.
> See libxl__set_vcpuonline_xenstore in tools/libxl/libxl_domain.c.
>
> I am sorry this protocol is not properly documented anywhere (as far as
> I am aware). However, it is so simple that you should be able to
> understand how it works just from the code.
>
>
>
> On Wed, 2 Aug 2017, Mirela Simonovic wrote:
> > Hi,
> > Thanks for the invite, please find the presentationhere: https://
> docs.google.com/presentation/d/1PhK9bdLyY_DSr8RbSs7LDdLWADbSW7YGwwnkpMLWeQ
> > g/edit#slide=id.g24c05965d7_0_15
> >
> > Regards,
> > Mirela
> >
> > On Tue, Aug 1, 2017 at 7:43 PM, Stefano Stabellini <
> sstabell...@kernel.org> wrote:
> >   On Tue, 1 Aug 2017, Julien Grall wrote:
> >   > On 01/08/17 17:44, Edgar E. Iglesias wrote:
> >   > > On Wed, Jul 26, 2017 at 04:59:43PM +0100, Julien Grall wrote:
> >   > > > Hi all,
> >   > > >
> >   > > > The next Xen ARM community call will be Wednesday 2nd August
> 2017 5pm
> >   BST.
> >   > > >
> >   > > > Do you have any specific topic you would like to discuss?
> >   > >
> >   > > CC: Davorin and Mirella from Aggios
> >   > >
> >   > > Hi Julien,
> >   >
> >   > Hi,
> >   >
> >   > > I was talking with the Aggios folks today and they were
> wondering if
> >   > > it's possible to share screens to present slides during the
> call?
> >   > > I'm guessing not, since the info below only has dial in info.
> >   >
> >   > It sounds like it is possible to share screen but I can't find a
> public
> >   link
> >   > for it :/.
> >   >
> >   > I can look for an alternative (I have plenty of choice at Arm
> :)) if it is
> >   > something people wants to do in the future. But for tomorrow, it
> might be
> >   > difficult to get something up by tomorrow.
> >   >
> >   > Can you upload the slides somewhere and send a link by e-mail?
> >
> >   Sending the slides by email beforehand is always a good idea.
> However,
> >   it's 2017 and we *have* to be able to share slides live during a
> meeting
> >   :-)
> >
> >   I talked with Julien: we are going to use my uberconference
> details for
> >   the call, which supports dialing in by phone, from your PC and
> slide
> >   sharing:
> >
> >
> >   Join the call: https://www.uberconference.com/stefano-stabellini
> >   US dial-in number: 669-999-0613
> >   No PIN needed
> >
> >   For the international numbers, go to
> >   https://www.uberconference.com/stefano-stabellini and choose
> "Join by
> >   Phone", a list of international numbers and a pin will be provided.
> >
> >   I'll also send another reminder tomorrow.
> >
> >
> >   Cheers,
> >
> >   Stefano
> >
> >
> >
> >
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [libvirt test] 112436: tolerable trouble: blocked/broken/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 112406
 build-arm64-xsm   2 hosts-allocate  broken like 112406
 build-arm64-pvops 2 hosts-allocate  broken like 112406
 build-arm64   3 capture-logsbroken like 112406
 build-arm64-xsm   3 capture-logsbroken like 112406
 build-arm64-pvops 3 capture-logsbroken like 112406
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112406
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112406
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112406
 test-amd64-amd64-libvirt 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-amd64-amd64-libvirt-xsm 13 migrate-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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  64665fa82f605a5e9aaafd4327fd7cf53751b1bd
baseline version:
 libvirt  861dd1234f1776e149c9fe5486f7efc07294a655

Last test of basis   112406  2017-08-01 04:20:17 Z3 days
Testing same since   112436  2017-08-04 04:25:05 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Daniel P. Berrange 
  Daniel Veillard 
  John Ferlan 
  Julio Faracco 
  Ján Tomko 
  Martin Kletzander 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Peter Krempa 

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

[Xen-devel] [linux-linus test] 112430: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  7 reboot   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 110515
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
110515
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 110515
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 110515
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 110515

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 110515
 build-arm64   2 hosts-allocate broken REGR. vs. 110515
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 110515
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 110515
 build-arm64-pvops 3 capture-logs  broken blocked in 110515
 build-arm64   3 capture-logs  broken blocked in 110515
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 110515
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-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-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-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-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-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 

Re: [Xen-devel] xen-blkfront hang

[Roger Pau Monné]

On Fri, Aug 04, 2017 at 05:36:29PM +0800, Dongli Zhang wrote:
> 
> 
> On 08/04/2017 05:13 PM, Roger Pau Monné wrote:
> > On Fri, Aug 04, 2017 at 10:00:09AM +0200, Valentin Vidic wrote:
> >> On Mon, Jul 31, 2017 at 09:09:19AM +0800, Dongli Zhang wrote:
> >>> To verify whether the above patch would help, please check the 
> >>> nr_grant_frames
> >>> value in guest domU. If this value is exactly the same of maximum grant 
> >>> frames
> >>> (by default, xen mainline uses 32) and the number of free grant 
> >>> references is
> >>> very small, the above patch might help.
> >>
> >> You are right, this is what I get after the machine hangs:
> >>
> >>   crash> print nr_grant_frames 
> >>   $1 = 32
> >>   crash> print gnttab_free_count 
> >>   $2 = 9
> >>
> >>> The best way is to increase the gnttab_max_frames to larger value (e.g.,  
> >>> 256)
> >>> in dom0 xen.gz grub.
> >>
> >> Thank you, this seems to help.  The test machine does not hang now and
> >> the numbers are looking better now:
> >>
> >>   crash> print nr_grant_frames 
> >>   $1 = 59
> >>   crash> print gnttab_free_count 
> >>   $2 = 356
> > 
> > At some point I've already expressed my opinion that having a
> > per-queue list of persistent grants was not a good idea. Now I think
> > the only solution is to remove persistent grants, or to lower the
> > default number of per-queue persistent grants to a ridiculously low
> > value.
> 
> It would be more efficient if (1) persistent grants are shared by all queues 
> and

There was a complain that having a shared pool of persistent grants
introduced too much contention.

> (2) there is a new mechanism to allow frontend to actively ask backend to 
> unmap
> existing persistent grants. So far, it is backend's responsibility to decide
> when to unmap persistent grants.

Hm, I would rather remove them than make the protocol more complex.

Roger.

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

[Xen-devel] [Patch for staging 1/2] docs: remove a special character to avoid html creation error.

[Yi Sun]

The '®' (a special character) may cause html document creation
failure. So remove it from the feature document.

Signed-off-by: Yi Sun 
---
 docs/features/intel_psr_cat_cdp.pandoc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/docs/features/intel_psr_cat_cdp.pandoc 
b/docs/features/intel_psr_cat_cdp.pandoc
index acf877b..04fb256 100644
--- a/docs/features/intel_psr_cat_cdp.pandoc
+++ b/docs/features/intel_psr_cat_cdp.pandoc
@@ -1,5 +1,5 @@
 % Intel Cache Allocation Technology and Code and Data Prioritization Features
-% Revision 1.15
+% Revision 1.16
 
 \clearpage
 
@@ -438,7 +438,7 @@ N/A
 
 # References
 
-"INTEL� RESOURCE DIRECTOR TECHNOLOGY (INTEL� RDT) ALLOCATION FEATURES" [Intel� 
64 and IA-32 Architectures Software Developer Manuals, 
vol3](http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html)
+"INTEL RESOURCE DIRECTOR TECHNOLOGY (INTEL RDT) ALLOCATION FEATURES" [Intel 64 
and IA-32 Architectures Software Developer Manuals, 
vol3](http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html)
 
 # History
 
@@ -468,4 +468,7 @@ Date   Revision Version  Notes
  1. Fix a typo.
 2017-08-01 1.15 Xen 4.10 Changes:
  1. Add 'alt_type' in 'feat_props' structure.
+2017-08-04 1.16 Xen 4.10 Changes:
+ 1. Remove special character which may cause
+html creation failure.
 --   ---
-- 
1.9.1


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

[Xen-devel] [Patch for staging 2/2] x86: remove an ASSERT to avoid crash when destroy a domain.

[Yi Sun]

In 'psr_free_cos', we should not use 'ASSERT(socket_info)' because
the 'socket_info' is allocated only if 'psr' boot parameter is set.
So remove it and use 'psr_alloc_feat_enabled' to check if 'socket_info'
is valid or not to avoid crash.

Signed-off-by: Yi Sun 
---
 xen/arch/x86/psr.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 7d9fa26..13c0daa 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -1294,9 +1294,7 @@ static void psr_free_cos(struct domain *d)
 {
 unsigned int socket, cos;
 
-ASSERT(socket_info);
-
-if ( !d->arch.psr_cos_ids )
+if ( !d->arch.psr_cos_ids || !psr_alloc_feat_enabled() )
 return;
 
 /* Domain is destroyed so its cos_ref should be decreased. */
-- 
1.9.1


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

Re: [Xen-devel] xen-blkfront hang

[Dongli Zhang]

On 08/04/2017 05:13 PM, Roger Pau Monné wrote:
> On Fri, Aug 04, 2017 at 10:00:09AM +0200, Valentin Vidic wrote:
>> On Mon, Jul 31, 2017 at 09:09:19AM +0800, Dongli Zhang wrote:
>>> To verify whether the above patch would help, please check the 
>>> nr_grant_frames
>>> value in guest domU. If this value is exactly the same of maximum grant 
>>> frames
>>> (by default, xen mainline uses 32) and the number of free grant references 
>>> is
>>> very small, the above patch might help.
>>
>> You are right, this is what I get after the machine hangs:
>>
>>   crash> print nr_grant_frames 
>>   $1 = 32
>>   crash> print gnttab_free_count 
>>   $2 = 9
>>
>>> The best way is to increase the gnttab_max_frames to larger value (e.g.,  
>>> 256)
>>> in dom0 xen.gz grub.
>>
>> Thank you, this seems to help.  The test machine does not hang now and
>> the numbers are looking better now:
>>
>>   crash> print nr_grant_frames 
>>   $1 = 59
>>   crash> print gnttab_free_count 
>>   $2 = 356
> 
> At some point I've already expressed my opinion that having a
> per-queue list of persistent grants was not a good idea. Now I think
> the only solution is to remove persistent grants, or to lower the
> default number of per-queue persistent grants to a ridiculously low
> value.

It would be more efficient if (1) persistent grants are shared by all queues and
(2) there is a new mechanism to allow frontend to actively ask backend to unmap
existing persistent grants. So far, it is backend's responsibility to decide
when to unmap persistent grants.

Dongli Zhang

> 
> Roger.
> 

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

Re: [Xen-devel] [PATCH v7 00/14] arm/mem_access: Walk guest page tables in SW if mem_access is active

[Sergej Proskurin]

Hi Julien,

Sorry for the late reply.

On 07/31/2017 04:38 PM, Julien Grall wrote:
> 
> 
> On 18/07/17 13:24, Sergej Proskurin wrote:
>> Hi all,
> 
> Hi,
> 
>>
>> The function p2m_mem_access_check_and_get_page is called from the function
>> get_page_from_gva if mem_access is active and the hardware-aided translation 
>> of
>> the given guest virtual address (gva) into machine address fails. That is, if
>> the stage-2 translation tables constrain access to the guests's page tables,
>> hardware-assisted translation will fail. The idea of the function
>> p2m_mem_access_check_and_get_page is thus to translate the given gva and 
>> check
>> the requested access rights in software. However, as the current 
>> implementation
>> of p2m_mem_access_check_and_get_page makes use of the hardware-aided gva to 
>> ipa
>> translation, the translation might also fail because of reasons stated above
>> and will become equally relevant for the altp2m implementation on ARM.  As
>> such, we provide a software guest translation table walk to address the above
>> mentioned issue.
>>
>> The current version of the implementation supports translation of both the
>> short-descriptor as well as the long-descriptor translation table format on
>> ARMv7 and ARMv8 (AArch32/AArch64).
>>
>> This revised version incorporates the comments of the previous patch series. 
>> In
>> this patch version we refine the definition of PAGE_SIZE_GRAN and
>> PAGE_MASK_GRAN. In particular, we use PAGE_SIZE_GRAN to define PAGE_MASK_GRAN
>> and thus avoid these defines to have a differing type. We also changed the
>> previously introduced macro BITS_PER_LONG_LONG to BITS_PER_LLONG. Further
>> changes comprise minor adjustments in comments and renaming of macros and
>> function parameters. Some additional changes comprising code readability and
>> correct type usage have been made and stated in the individual commits.
>>
>> The following patch series can be found on Github[0].
> 
> I tried this series today with the change [1] in Xen to check the translation
> is valid. However, I got a failure when booting non-LPAE arm32 Dom0:
> 

That's odd.. Thanks for the information. I will investigate this issue
next week, as soon as I have access to our ARMv7 board.

> (XEN) Loading kernel from boot module @ 80008000
> (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> (XEN) BANK[0] 0x00a000-0x00c000 (512MB)
> (XEN) Grant table range: 0x00ffe0-0x00ffe6a000
> (XEN) Loading zImage from 80008000 to 
> a780-a7f50e28
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Loading dom0 DTB to 0xa800-0xa8001f8e
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) guest_walk_tables: gva 0xffeff018 pipa 0x1c090018
> (XEN) access_guest_memory_by_ipa: gpa 0xa0207ff8
> (XEN) access_guest_memory_by_ipa: gpa 0xa13aebfc
> (XEN) d0: guestcopy: failed to get table entry.
> (XEN) Xen BUG at traps.c:2737
> (XEN) [ Xen-4.10-unstable  arm32  debug=y   Not tainted ]
> (XEN) CPU:0
> (XEN) PC: 00264dc0 do_trap_guest_sync+0x161c/0x1804
> (XEN) CPSR:   a05a MODE:Hypervisor
> (XEN)  R0: ffea R1:  R2:  R3: 004a
> (XEN)  R4: 93830007 R5: 47fcff58 R6: 93830007 R7: 0007
> (XEN)  R8: 1c09 R9:  R10: R11:47fcff54 R12:ffea
> (XEN) HYP: SP: 47fcfee4 LR: 00258dec
> (XEN) 
> (XEN)   VTCR_EL2: 80003558
> (XEN)  VTTBR_EL2: 00010008f3ffc000
> (XEN) 
> (XEN)  SCTLR_EL2: 30cd187f
> (XEN)HCR_EL2: 0038663f
> (XEN)  TTBR0_EL2: fff02000
> (XEN) 
> (XEN)ESR_EL2: 
> (XEN)  HPFAR_EL2: 001c0900
> (XEN)  HDFAR: ffeff018
> (XEN)  HIFAR: 
> (XEN) 
> (XEN) Xen stack trace from sp=47fcfee4:
> (XEN) 47fcff34 00256008 47fcfefc 47fcfefc 20da 0004 
> 47fd48f4
> (XEN)002d5ef0 0004 002d1f00 0004  002d1f00 c163f740 
> 93830007
> (XEN)ffeff018 1c090018  47fcff44 c15e70ac 005b c15e70ac 
> c074400c
> (XEN)0031  c0743ff8 47fcff58 00268ce0 c15e70ac 005b 
> 0031
> (XEN)ffeff000 c15e70ac 005b c15e70ac c074400c 0031  
> c0743ff8
> (XEN) 001f   c074401c 21d3 93830007 
> 
> (XEN)c161cac0 c161cac0 c1501de0 c0735640 c161cacc c161cacc c161cad8 
> c161cad8
> (XEN)     c161cae4 c161cae4 
> 41d3
> (XEN)     dfdfdfcf cfdfdfdf
> (XEN) Xen call trace:
> (XEN)[<00264dc0>] do_trap_guest_sync+0x161c/0x1804 (PC)
> (XEN)[<00258dec>] access_guest_memory_by_ipa+0x25c/0x284 (LR)
> (XEN)[<00268ce0>] entry.o#return_from_trap+0/0x4
> (XEN) 
> (XEN) 
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) Xen BUG at traps.c:2737
> (XEN) 
> (XEN) 
> (XEN) Reboot in five seconds...
> 
> The IPA 

Re: [Xen-devel] xen-blkfront hang

[Roger Pau Monné]

On Fri, Aug 04, 2017 at 10:00:09AM +0200, Valentin Vidic wrote:
> On Mon, Jul 31, 2017 at 09:09:19AM +0800, Dongli Zhang wrote:
> > To verify whether the above patch would help, please check the 
> > nr_grant_frames
> > value in guest domU. If this value is exactly the same of maximum grant 
> > frames
> > (by default, xen mainline uses 32) and the number of free grant references 
> > is
> > very small, the above patch might help.
> 
> You are right, this is what I get after the machine hangs:
> 
>   crash> print nr_grant_frames 
>   $1 = 32
>   crash> print gnttab_free_count 
>   $2 = 9
> 
> > The best way is to increase the gnttab_max_frames to larger value (e.g.,  
> > 256)
> > in dom0 xen.gz grub.
> 
> Thank you, this seems to help.  The test machine does not hang now and
> the numbers are looking better now:
> 
>   crash> print nr_grant_frames 
>   $1 = 59
>   crash> print gnttab_free_count 
>   $2 = 356

At some point I've already expressed my opinion that having a
per-queue list of persistent grants was not a good idea. Now I think
the only solution is to remove persistent grants, or to lower the
default number of per-queue persistent grants to a ridiculously low
value.

Roger.

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