Re: [Xen-devel] [PATCH v13 12/23] x86: refactor psr: L3 CAT: set value: implement write msr flow.

[Yi Sun]

On 17-07-12 23:20:24, Jan Beulich wrote:
> >>> Yi Sun  07/13/17 5:00 AM >>>
> >On 17-07-12 13:37:02, Jan Beulich wrote:
> >> >>> Yi Sun  07/06/17 4:07 AM >>>
> >> >v13:
> >> >- use 'skip_prior_features'.
> >> >- add 'const' for some variables.
> >> 
> >> You didn't go quite far enough with this:
> >> 
> >> >+struct cos_write_info
> >> >+{
> >> >+unsigned int cos;
> >> >+struct feat_node *feature;
> >> >+const uint32_t *val;
> >> 
> >> With this, ...
> >> 
> >> >static int write_psr_msrs(unsigned int socket, unsigned int cos,
> >>>uint32_t val[], unsigned int array_len,
> >>
> >> ... I can't see why this can't be const too. Of course that would then 
> >> affect an
> >> earlier patch.
> >> 
> >The 'val' is input into 'skip_prior_features'. In 'skip_prior_features', 
> >there
> >is '*val += props->cos_num;' to change the value. So, I do not add 'const' 
> >here.
> >Of course, I can change the way to skip value array, e.g. using a variable as
> >index. Which one do you like?
> 
> Oh, I see. But yes, I still think it would be nice for const-ness to be
> expressible irrespective of this helper function, so making it e.g. just 
> update
> "len" without passing in the array pointer at all (leaving that part to the 
> caller)
> would seem desirable. Or possibly not even pass "array_len" via indirection,
> instead making the function return a non-negative increment value for the
> caller to apply to both (keeping negative value to indicate errors). But if 
> you
> think it's better the way it is, I could also live with it.
> 
Thank you! I will try to implement a version out according to your comments.

> >> >+if ( socket == cpu_to_socket(smp_processor_id()) )
> >> >+do_write_psr_msrs(&data);
> >> >+else
> >> >+{
> >> >+unsigned int cpu = get_socket_cpu(socket);
> >> >+
> >> >+if ( cpu >= nr_cpu_ids )
> >> >+return -ENOTSOCK;
> >> >+on_selected_cpus(cpumask_of(cpu), do_write_psr_msrs, &data, 1);
> >> 
> >> How frequent an operation can this be? Considering that the actual MSR 
> >> write(s)
> >> in the handler is (are) conditional I wonder whether it wouldn't be 
> >> worthwhile
> >> trying to avoid the IPI altogether, by pre-checking whether any write 
> >> actually
> >> needs doing.
> >> 
> >Yes, I think I can check if the value to set is same as 
> >'feat->cos_reg_val[cos]'
> >before calling IPI.
> 
> Well, as said - whether it's worth the extra effort depends on whether there 
> is
> a (reasonable) scenario where this function may be executed frequently.
> 
This function is executed when 'psr-cat-set' command is executed. I consult
the libvirt guy, this command may be executed frequently under some scenarios.
E.g. user may dynamically adjust the cache allocation for VMs according to CMT
result.

> >There is one more thing. During implementing MBA, I find there is an issue 
> >here.
> >The current codes in 'struct cos_write_info' and 'write_psr_msrs' only 
> >consider
> >one feature's value setting. In fact, we should consider to set all values in
> >'val' array to the MSRs with new cos id for all features.
> >
> >So, the 'cos_write_info' should be something like below to input feature 
> >array
> >and props array to handle all features. Of course, we do not need skip value
> >array anymore.
> >
> >struct cos_write_info
> >{
> >unsigned int cos;
> >struct feat_node **features;
> >uint32_t *val;
> >unsigned int array_len;
> >const struct feat_props **props;
> >};
> 
> As you can likely understand, I can't really judge on this without seeing what
> you need this for. So I'd suggest to keep things the way they are in this 
> series
> and discuss changes to it in the context of that other series of yours.
> 
Ok, I will keep the codes in current series. Will modify them in MBA patch set
for review.

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

[Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send

[Andrew Cooper]

The event channel ABI passes a pointer to a subop-specific structure.  Some of
these structures however are smaller than the pointers passed in the ABI;
EVTCHNOP_send specifically passes a 4 byte evtchn port, using a 4 or 8 byte
pointer.

For translated guests (x86 HVM and all ARM), passing the port number directly
avoids a guest pagetable walk, which can be very expensive for Xen to perform.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Juergen Gross 
CC: Roger Pau Monné 
CC: Wei Liu 

RFC: is it worth converting the close, unmask, reset (and possibly
expand_array) as well?
---
 xen/common/event_channel.c |  4 
 xen/include/public/event_channel.h | 13 ++---
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index c69f9db..79d8614 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1098,6 +1098,10 @@ long do_event_channel_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 break;
 }
 
+case EVTCHNOP_send_imm:
+rc = evtchn_send(current->domain, (unsigned long)arg.p);
+break;
+
 case EVTCHNOP_status: {
 struct evtchn_status status;
 if ( copy_from_guest(&status, arg, 1) != 0 )
diff --git a/xen/include/public/event_channel.h 
b/xen/include/public/event_channel.h
index 44c549d..834787a 100644
--- a/xen/include/public/event_channel.h
+++ b/xen/include/public/event_channel.h
@@ -57,6 +57,9 @@
  * `
  * @cmd  == EVTCHNOP_* (event-channel operation).
  * @args == struct evtchn_* Operation-specific extra arguments (NULL if none).
+ *
+ * For @cmd with an _imm suffix, data are passed as an integer, rather than a
+ * pointer to a structure.
  */
 
 /* ` enum event_channel_op { // EVTCHNOP_* => struct evtchn_* */
@@ -64,7 +67,7 @@
 #define EVTCHNOP_bind_virq1
 #define EVTCHNOP_bind_pirq2
 #define EVTCHNOP_close3
-#define EVTCHNOP_send 4
+#define EVTCHNOP_send 4 /* Deprecated.  Use EVTCHNOP_send_imm in 
preference. */
 #define EVTCHNOP_status   5
 #define EVTCHNOP_alloc_unbound6
 #define EVTCHNOP_bind_ipi 7
@@ -74,6 +77,7 @@
 #define EVTCHNOP_init_control11
 #define EVTCHNOP_expand_array12
 #define EVTCHNOP_set_priority13
+#define EVTCHNOP_send_imm14
 /* ` } */
 
 typedef uint32_t evtchn_port_t;
@@ -186,8 +190,11 @@ struct evtchn_close {
 typedef struct evtchn_close evtchn_close_t;
 
 /*
- * EVTCHNOP_send: Send an event to the remote end of the channel whose local
- * endpoint is .
+ * EVTCHNOP_send{,_imm}: Send an event to the remote end of the channel whose
+ * local endpoint is .
+ *
+ * For EVTCHNOP_send, arg is a pointer to an evtchn_send_t.  For
+ * EVTCHNOP_send_imm, arg is the port directly.
  */
 struct evtchn_send {
 /* IN parameters. */
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 15/15] xen: tools: expose EPC in ACPI table

[Huang, Kai]

On 7/12/2017 11:05 PM, Andrew Cooper wrote:

On 09/07/17 10:16, Kai Huang wrote:
On physical machine EPC is exposed in ACPI table via "INT0E0C". 
Although EPC
can be discovered by CPUID but Windows driver requires EPC to be 
exposed in

ACPI table as well. This patch exposes EPC in ACPI table.


:(


diff --git a/tools/libacpi/dsdt.asl b/tools/libacpi/dsdt.asl
index fa8ff317b2..25ce196028 100644
--- a/tools/libacpi/dsdt.asl
+++ b/tools/libacpi/dsdt.asl
@@ -441,6 +441,55 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", 
"HVM", 0)

  }
  }
  }
+
+Device (EPC)


Would it not be better to put this into an SSDT, and only expose it to 
the guest if SGX is advertised?


You mean to create dedicated ssdt_epc.asl? I thought about this, but I 
am not quite sure if we can, because new EPC device will need to refer 
\_SB.EMIN, and \_SB.ELEN, which are in acpi_info, to get EPC base and 
size. Can we refer acpi_info in dedicated ssdt_epc.asl?


Thanks,
-Kai



~Andrew

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


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

[Xen-devel] [linux-4.9 test] 111737: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
111411
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
111411

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail like 111411
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 111411
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 111411
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111411
 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-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-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-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-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  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-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-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install 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

version targeted for testing:
 linuxc48f76d680ad9ad443290ce0f1e8f92db6986bf5
baseline version:
 linux9f86f302ec0e37e84617481c587e11c47a397e3f

Last test of basis   111411  2017-07-05 13:19:38 Z7 days
Testing same since   111737  2017-07-12 15:28:11 Z0 days1 attempts


People who touched revisions under test:
  "Yan, Zheng" 
  Adrian Salido 
  Al Viro 
  Alan Stern 
  Alexandre TORGUE 
  Andreas Gruenbacher 
  Bartosz Markowski 
  Benjamin H

Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Andrew Cooper
> Sent: 13 July 2017 09:51
> To: Xen-devel 
> Cc: Juergen Gross ; Stefano Stabellini
> ; Wei Liu ; Andrew Cooper
> ; Julien Grall ; Jan
> Beulich ; Roger Pau Monne 
> Subject: [Xen-devel] [PATCH RFC] xen/evtchn: Implement
> EVTCHNOP_send_imm as a companian to EVTCHNOP_send
> 
> The event channel ABI passes a pointer to a subop-specific structure.  Some
> of
> these structures however are smaller than the pointers passed in the ABI;
> EVTCHNOP_send specifically passes a 4 byte evtchn port, using a 4 or 8 byte
> pointer.
> 
> For translated guests (x86 HVM and all ARM), passing the port number
> directly
> avoids a guest pagetable walk, which can be very expensive for Xen to
> perform.
> 
> Signed-off-by: Andrew Cooper 

LGTM. I suspect this will help performance of PV drivers quite a bit.

Reviewed-by: Paul Durrant 

> ---
> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Juergen Gross 
> CC: Roger Pau Monné 
> CC: Wei Liu 
> 
> RFC: is it worth converting the close, unmask, reset (and possibly
> expand_array) as well?
> ---
>  xen/common/event_channel.c |  4 
>  xen/include/public/event_channel.h | 13 ++---
>  2 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index c69f9db..79d8614 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1098,6 +1098,10 @@ long do_event_channel_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  break;
>  }
> 
> +case EVTCHNOP_send_imm:
> +rc = evtchn_send(current->domain, (unsigned long)arg.p);
> +break;
> +
>  case EVTCHNOP_status: {
>  struct evtchn_status status;
>  if ( copy_from_guest(&status, arg, 1) != 0 )
> diff --git a/xen/include/public/event_channel.h
> b/xen/include/public/event_channel.h
> index 44c549d..834787a 100644
> --- a/xen/include/public/event_channel.h
> +++ b/xen/include/public/event_channel.h
> @@ -57,6 +57,9 @@
>   * `
>   * @cmd  == EVTCHNOP_* (event-channel operation).
>   * @args == struct evtchn_* Operation-specific extra arguments (NULL if
> none).
> + *
> + * For @cmd with an _imm suffix, data are passed as an integer, rather than
> a
> + * pointer to a structure.
>   */
> 
>  /* ` enum event_channel_op { // EVTCHNOP_* => struct evtchn_* */
> @@ -64,7 +67,7 @@
>  #define EVTCHNOP_bind_virq1
>  #define EVTCHNOP_bind_pirq2
>  #define EVTCHNOP_close3
> -#define EVTCHNOP_send 4
> +#define EVTCHNOP_send 4 /* Deprecated.  Use
> EVTCHNOP_send_imm in preference. */
>  #define EVTCHNOP_status   5
>  #define EVTCHNOP_alloc_unbound6
>  #define EVTCHNOP_bind_ipi 7
> @@ -74,6 +77,7 @@
>  #define EVTCHNOP_init_control11
>  #define EVTCHNOP_expand_array12
>  #define EVTCHNOP_set_priority13
> +#define EVTCHNOP_send_imm14
>  /* ` } */
> 
>  typedef uint32_t evtchn_port_t;
> @@ -186,8 +190,11 @@ struct evtchn_close {
>  typedef struct evtchn_close evtchn_close_t;
> 
>  /*
> - * EVTCHNOP_send: Send an event to the remote end of the channel
> whose local
> - * endpoint is .
> + * EVTCHNOP_send{,_imm}: Send an event to the remote end of the
> channel whose
> + * local endpoint is .
> + *
> + * For EVTCHNOP_send, arg is a pointer to an evtchn_send_t.  For
> + * EVTCHNOP_send_imm, arg is the port directly.
>   */
>  struct evtchn_send {
>  /* IN parameters. */
> --
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [distros-debian-wheezy test] 71687: tolerable trouble: broken/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 build-arm64   2 hosts-allocate   broken like 71654
 build-arm64-pvops 2 hosts-allocate   broken like 71654
 build-arm64-pvops 3 capture-logs broken like 71654
 build-arm64   3 capture-logs broken like 71654

baseline version:
 flight   71654

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  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.


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71686 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71686/

Regressions :-(

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

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   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail blocked in 71655
 test-armhf-armhf-libvirt14 saverestore-support-check fail blocked in 71655
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail blocked in 71655
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 71655
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 71655
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-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-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 18 guest-start/win.repeat  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuuaa916e409c04cb614ec2fee8b6b33836bf5998bb
baseline version:
 qemuu2185c93ba80f81bfa27ce6f259c7f2ef4f08b668

Last test of basis71655  2017-07-06 07:57:38 Z7 days
Testing same since71686  2017-07-13 05:18:17 Z0 days1 attempts


People who touched revisions under test:
  Aaron Larson 
  Alex Williamson 
  Alistair Francis 
  Anoob Soman 
  Anthony Liguori 
  Anthony PERARD 
  Christian Borntraeger 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel P. Berrange 
  David Gibson 
  Dong Jia Shi 
  Dr. David Alan Gilbert 
  Emilio G. Cota 
  Eric Blake 
  Fam Zheng 
  Greg Kurz 
  Halil Pasic 
  Hervé Poussineau 
  Jason Wang 
  Jiang Biao 
  Juan Quintela 
  Kevin Wolf 
  Laurent Vivier 
  Paolo Bonzini 
  Peter Maydell 
  Peter Xu 
  Pranith Kumar 
  QingFeng Hao 
  Richard Henderson 
  Ross Lagerwall 
  Sergio Andres Gomez Del Real 
  Stefano Stabellin

Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send

[Juergen Groß]

On 07/13/2017 09:50 AM, Andrew Cooper wrote:

The event channel ABI passes a pointer to a subop-specific structure.  Some of
these structures however are smaller than the pointers passed in the ABI;
EVTCHNOP_send specifically passes a 4 byte evtchn port, using a 4 or 8 byte
pointer.

For translated guests (x86 HVM and all ARM), passing the port number directly
avoids a guest pagetable walk, which can be very expensive for Xen to perform.

Signed-off-by: Andrew Cooper 


I'm absolutely in favor of the approach.

Could we please discuss which hypercalls should offer an immediate
variant before implementing one after the other? I believe those should
all be introduced at the same time in order to make deciding which
variant to use in domU easier: I don't want to have a boolean for each
possible hypercall, but just one.

Juergen

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

Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send

[Wei Liu]

On Thu, Jul 13, 2017 at 12:14:35PM +0200, Juergen Groß wrote:
> On 07/13/2017 09:50 AM, Andrew Cooper wrote:
> > The event channel ABI passes a pointer to a subop-specific structure.  Some 
> > of
> > these structures however are smaller than the pointers passed in the ABI;
> > EVTCHNOP_send specifically passes a 4 byte evtchn port, using a 4 or 8 byte
> > pointer.
> > 
> > For translated guests (x86 HVM and all ARM), passing the port number 
> > directly
> > avoids a guest pagetable walk, which can be very expensive for Xen to 
> > perform.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> I'm absolutely in favor of the approach.
> 

+1

> Could we please discuss which hypercalls should offer an immediate
> variant before implementing one after the other? I believe those should
> all be introduced at the same time in order to make deciding which
> variant to use in domU easier: I don't want to have a boolean for each
> possible hypercall, but just one.

+1

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

[Xen-devel] Dump FDT for Linux Guest from Xen

[Waseem, Amna]

Hello All,


Is there a way to dump FDT prepared by Xen given to Linux Guest while booting 
Domain 0.


I want to see flattened device tree created by Xen by remapping I/O and IRQs 
for Guest.


Is there a simple API to dump the flattened device?


Regards

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

Re: [Xen-devel] [OSSTEST PATCH v12 18/21] TestSupport: Implement target_cmd_subunit a subunit stream parser into substeps

[Ian Jackson]

Anthony PERARD writes ("[OSSTEST PATCH v12 18/21] TestSupport: Implement 
target_cmd_subunit a subunit stream parser into substeps"):
> target_cmd_subunit can be used like target_cmd, but the command would
> needs to output a subunit v1 stream, which will be parsed and turned
> into osstest substeps. The command can be `| subunit-2to1` in order to
> turn a subunit v2 stream into v1.

Thanks.

> Currently, time is not taken into account, and all substeps will have
> bogus timestamp as the output of the command is parsed after it has
> runned.

I think this is not a critical problem, but fixing it would be nice at
some point.

> +sub subunit_result_to_osstest_result ($) {
> +my ($ret) = @_;
> +return "pass" if $ret eq "success" or $ret eq "successful";
> +return "fail" if $ret eq "failure";
> +return "skip" if $ret eq "skip";
> +return "fail" if $ret eq "error";
> +}

I think this needs to die at the end, if the input is not recognised.

> +sub subunit_sanitize ($) {
> +my ($testname) = @_;
> +$testname =~ s/ /_/g;
> +return $testname;
> +}

This function should have a more specific name.  Also it needs to be a
whitelist.

> +sub target_cmd_subunit ($$;$$) {
> +my $stdout = IO::File::new_tmpfile();
> +my $rc = tcmd(undef,$stdout,0, 'osstest', @_);

It would be better to staxh the original subunit output.  And I would
prefer to avoid direct use of tcmd here.  So can you introduce
   target_cmd_stashed
which calls open_unique_stashfile and tcmd, and then use that in your
subunit subroutine?  (And yes this might duplicte output I think.)

I'm not sure target_cmd_subunit is quite the right name.  Maybe
target_subunit_cmd ?

> +while (<$stdout>) {
> +if (/^time: (\d+)-(\d+)-(\d+) (\d+):(\d+):(\d+)(\.\d+)?Z$/) {
> +# This is the timestamp for the next events
> +} elsif (/^test: (.+)\n/) {
> +$logfilename = subunit_sanitize($1) . '.log';
> +$fh = open_unique_stashfile(\$logfilename);
> +substep_start(subunit_sanitize($1), $logfilename);
> +} elsif (/^(success(ful)?|failure|skip|error): (.+?)( \[( 
> multipart)?)?$/) {

Please assign your $n to local variables, rather than leaving them in
$3 etc. to be used much later.  (And don't capture things if you don't
intend to, so in that case use ?:).  What does the multpart mean ?
Does this code need to care ?  Does the subunit protocol insist that
the spaces are single spaces ?  If not you need to use \s+.  You may
want to use the extended regexp syntax.

> +if ($4) {
> +my $test_output = "";
> +while (<$stdout>) {
> +last if (/^\]$/);
> +$test_output .= $_;
> +}
> +print $fh $test_output or die $!;

Why do you bother accumulating this in $test_output rather than just
printing it ?

Does the subunit protocol not have any escaping ?  (Ie, what happens
if a thing run as part of a subunit test actually generates a line of
log output "]" ?)  If it does havve some escaping you need to
de-escape it.

> +}
> +close $fh or die $!;
> +substep_finish(subunit_sanitize($3), 
> subunit_result_to_osstest_result($1));
> +}

What are subunit v1 consumers supposed to do with 1. unknown keywords
2. syntax errors ?

I doubt that the answer to (2) is to ignore them as you do here...

Thanks,
Ian.

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

Re: [Xen-devel] [OSSTEST PATCH v12 19/21] ts-openstack-tempest: Use target_cmd_subunit

[Ian Jackson]

Anthony PERARD writes ("[OSSTEST PATCH v12 19/21] ts-openstack-tempest: Use 
target_cmd_subunit"):
> Signed-off-by: Anthony PERARD 

Acked-by: Ian Jackson 

Subject to my comments aboout the name of the function, of course.

Ian.

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

[Xen-devel] [linux-3.18 test] 111745: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 111523 
pass in 111745
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 111724 pass in 
111523
 test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail in 111724 
pass in 111745
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 18 guest-start/debianhvm.repeat 
fail in 111724 pass in 111745
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 111724 pass in 
111745
 test-amd64-amd64-xl-rtds 10 debian-install fail pass in 111523
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail pass in 111724
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
111724

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
 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
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 110441
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111523 
blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111523 
blocked in 110441
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 111724 blocked in 
110441
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111724 
like 110441
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 110441
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110441
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  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-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-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-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-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-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-raw 12 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-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail ne

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-credit2  15 guest-saverestorefail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 21 guest-start/debian  fail REGR. vs. 110515
 test-amd64-amd64-xl-multivcpu 15 guest-saverestore   fail REGR. vs. 110515
 test-amd64-amd64-pair21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-i386-libvirt  16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-xl-xsm   16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-xl  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-libvirt 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-libvirt-xsm  16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-amd  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-i386-libvirt-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-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-libvirt-xsm 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-xl   16 guest-localmigrate   fail REGR. vs. 110515
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 110515
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 110515
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-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-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-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail  

Re: [Xen-devel] [PATCH v4 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

[Jan Beulich]

>>> Roger Pau Monne  06/30/17 5:01 PM >>>
> --- /dev/null
> +++ b/tools/tests/vpci/Makefile
> @@ -0,0 +1,40 @@
> +
> +XEN_ROOT=$(CURDIR)/../../..
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +TARGET := test_vpci
> +
> +.PHONY: all
> +all: $(TARGET)
> +
> +.PHONY: run
> +run: $(TARGET)
> +./$(TARGET) > $(TARGET).out

Is this a good way to run a test? Aiui it'll result in there not being
anything visible immediately; one has to go look at the produced file.
I'd suggest to leave it to the person invoking "make run" whether to
redirect output.

> +$(TARGET): vpci.c vpci.h list.h
> +$(HOSTCC) -g -o $@ vpci.c main.c

If you compile main.c, why is there no dependency on it? And how about
emul.h?

> +.PHONY: clean
> +clean:
> +rm -rf $(TARGET) $(TARGET).out *.o *~ vpci.h vpci.c list.h
> +
> +.PHONY: distclean
> +distclean: clean
> +
> +.PHONY: install
> +install:
> +
> +vpci.h: $(XEN_ROOT)/xen/include/xen/vpci.h
> +sed -e '/#include/d' <$< >$@

Couldn't you combine this and list.h's rule into a pattern one?

> --- /dev/null
> +++ b/tools/tests/vpci/emul.h
> @@ -0,0 +1,117 @@
> +/*
> + * Unit tests for the generic vPCI handler code.
> + *
> + * Copyright (C) 2017 Citrix Systems R&D
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#ifndef _TEST_VPCI_
> +#define _TEST_VPCI_
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define container_of(ptr, type, member) ({  \
> +typeof(((type *)0)->member) *__mptr = (ptr);\
> +(type *)((char *)__mptr - offsetof(type, member));  \

I don't know what tools maintainers think about such name space
violations; in hypervisor code I'd ask you to avoid leading underscores
in macro local variables (same in min()/max() and elsewhere then).

> +/* Read a 32b register using all possible sizes. */
> +void multiread4(unsigned int reg, uint32_t val)
> +{
> +unsigned int i;
> +
> +/* Read using bytes. */
> +for ( i = 0; i < 4; i++ )
> +VPCI_READ_CHECK(reg + i, 1, (val >> (i * 8)) & UINT8_MAX);
> +
> +/* Read using 2bytes. */
> +for ( i = 0; i < 2; i++ )
> +VPCI_READ_CHECK(reg + i * 2, 2, (val >> (i * 2 * 8)) & UINT16_MAX);
> +
> +VPCI_READ_CHECK(reg, 4, val);
> +}
> +
> +void multiwrite4_check(unsigned int reg, uint32_t val)

Naming question again: Why the _check suffix here, but not on the read
function above?

> +{
> +unsigned int i;
> +
> +/* Write using bytes. */
> +for ( i = 0; i < 4; i++ )
> +VPCI_WRITE_CHECK(reg + i, 1, (val >> (i * 8)) & UINT8_MAX);
> +multiread4(reg, val);
> +
> +/* Write using 2bytes. */
> +for ( i = 0; i < 2; i++ )
> +VPCI_WRITE_CHECK(reg + i * 2, 2, (val >> (i * 2 * 8)) & UINT16_MAX);
> +multiread4(reg, val);
> +
> +VPCI_WRITE_CHECK(reg, 4, val);
> +multiread4(reg, val);
> +}

Wouldn't it be better to vary the value written between the individual
sizes? Perhaps move the 32-bit write between the two loops, using ~val?
Otherwise you won't know whether what you read back is a result of the
writes you actually mean to test or earlier ones?

> +int
> +main(int argc, char **argv)
> +{
> +/* Index storage by offset. */
> +uint32_t r0 = 0xdeadbeef;
> +uint8> +uint16_t r20[2] = { 0 };

Just { } will suffice.

> +uint32_t r24 = 0;
> +uint8_t r28, r30;
> +unsigned int i;
> +int rc;
> +
> +INIT_LIST_HEAD(&vpci.handlers);
> +
> +VPCI_ADD_REG(vpci_read32, vpci_write32, 0, 4, r0);
> +VPCI_READ_CHECK(0, 4, 0xdeadbeef);

Why aren't you using r0 here?

> +VPCI_WRITE_CHECK(0, 4, 0xbcbcbcbc);
> +
> +VPCI_ADD_REG(vpci_read8, vpci_write8, 5, 1, r5);
> +VPCI_READ_CHECK(5, 1, 0xef);
> +VPCI_WRITE_CHECK(5, 1, 0xba);
> +
> +VPCI_ADD_REG(vpci_read8, vpci_write8, 6, 1, r6);
> +VPCI_READ_CHECK(6, 1, 0xbe);
> +VPCI_WRITE_CHECK(6, 1, 0xba);
> +
> +VPCI_ADD_REG(vpci_read8, vpci_write8, 7, 1, r7);
> +VPCI_READ_CHECK(7, 1, 0xef);
> +VPCI_WRITE_CHECK(7, 1, 0xbd);
> +
> +VPCI_ADD_REG(vpci_read16, vpci_write16, 12, 2, r12);
> +VPCI_READ_CHECK(12, 2, 0x8696);
> +VPCI_READ_CHECK(12, 4, 0x8696);
> +
> +/*
> + * At this point we have the following layout:
> + *
> + * 322416 8 0
> + *  +-+-+-+-+
> + *  |  r0   | 0
> + *  +-+---

Re: [Xen-devel] [OSSTEST PATCH v12 18/21] TestSupport: Implement target_cmd_subunit a subunit stream parser into substeps

[Anthony PERARD]

On Thu, Jul 13, 2017 at 02:28:11PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[OSSTEST PATCH v12 18/21] TestSupport: Implement 
> target_cmd_subunit a subunit stream parser into substeps"):
> > Currently, time is not taken into account, and all substeps will have
> > bogus timestamp as the output of the command is parsed after it has
> > runned.
> 
> I think this is not a critical problem, but fixing it would be nice at
> some point.

The subunit stream contains the timestamps, so it just a matter of
having substep_* taking it as an argument.

> > +sub subunit_result_to_osstest_result ($) {
> > +my ($ret) = @_;
> > +return "pass" if $ret eq "success" or $ret eq "successful";
> > +return "fail" if $ret eq "failure";
> > +return "skip" if $ret eq "skip";
> > +return "fail" if $ret eq "error";
> > +}
> 
> I think this needs to die at the end, if the input is not recognised.

Will do.

> > +sub subunit_sanitize ($) {
> > +my ($testname) = @_;
> > +$testname =~ s/ /_/g;
> > +return $testname;
> > +}
> 
> This function should have a more specific name.  Also it needs to be a
> whitelist.

What about subunit_sanitize_testname?

What kind of whitelist? What should it includes?

> > +sub target_cmd_subunit ($$;$$) {
> > +my $stdout = IO::File::new_tmpfile();
> > +my $rc = tcmd(undef,$stdout,0, 'osstest', @_);
> 
> It would be better to staxh the original subunit output.  And I would
> prefer to avoid direct use of tcmd here.  So can you introduce
>target_cmd_stashed
> which calls open_unique_stashfile and tcmd, and then use that in your
> subunit subroutine?  (And yes this might duplicte output I think.)

Will do. And yes, this will duplicate most of the output. But it can
help debug osstest, for everything that the parser ignore.

> 
> I'm not sure target_cmd_subunit is quite the right name.  Maybe
> target_subunit_cmd ?

OK.

> > +while (<$stdout>) {
> > +if (/^time: (\d+)-(\d+)-(\d+) (\d+):(\d+):(\d+)(\.\d+)?Z$/) {
> > +# This is the timestamp for the next events
> > +} elsif (/^test: (.+)\n/) {
> > +$logfilename = subunit_sanitize($1) . '.log';
> > +$fh = open_unique_stashfile(\$logfilename);
> > +substep_start(subunit_sanitize($1), $logfilename);
> > +} elsif (/^(success(ful)?|failure|skip|error): (.+?)( \[( 
> > multipart)?)?$/) {
> 
> Please assign your $n to local variables, rather than leaving them in
> $3 etc. to be used much later.  (And don't capture things if you don't
> intend to, so in that case use ?:).  What does the multpart mean ?
> Does this code need to care ?

multipart just describes how the following lines are formated, it would
have the 'content-type:' and the size of the output. non-multipart is
just followed by text, and ends with '\n]\n' (both format do).

I don't think the code needs to care about it, just that it may or
may not be there.

> Does the subunit protocol insist that
> the spaces are single spaces ?  If not you need to use \s+.  You may
> want to use the extended regexp syntax.

Looking at a description of the protocol and at the subunit code, does
are single spaces.

What do you mean by "extended" ? Maybe operator like /.+?/, or maybe
/(?pattern)/ ?

> > +if ($4) {
> > +my $test_output = "";
> > +while (<$stdout>) {
> > +last if (/^\]$/);
> > +$test_output .= $_;
> > +}
> > +print $fh $test_output or die $!;
> 
> Why do you bother accumulating this in $test_output rather than just
> printing it ?

No reason, I'll print.

> Does the subunit protocol not have any escaping ?  (Ie, what happens
> if a thing run as part of a subunit test actually generates a line of
> log output "]" ?)  If it does havve some escaping you need to
> de-escape it.

Without "multipart", there does not seems to be any escaping. With
multipart, the size of the output is in the protocol, I could extend the
parser take it into account. It's just more work.

FYI, part of the protocol about the output (with the beginning of
DETAILS been "\[( multipart)?" in the regex):

DETAILS ::= BRACKETED | MULTIPART
BRACKETED ::= '[' CR UTF8-lines ']' CR
MULTIPART ::= '[ multipart' CR PART* ']' CR
PART ::= PART_TYPE CR NAME CR PART_BYTES CR
PART_TYPE ::= Content-Type: type/sub-type(;parameter=value,parameter=value)
PART_BYTES ::= (DIGITS CR LF BYTE{DIGITS})* '0' CR LF

> > +}
> > +close $fh or die $!;
> > +substep_finish(subunit_sanitize($3), 
> > subunit_result_to_osstest_result($1));
> > +}
> 
> What are subunit v1 consumers supposed to do with 1. unknown keywords
> 2. syntax errors ?
> I doubt that the answer to (2) is to ignore them as you do here...

"unexpected lines [...] should be forwarded unaltered". That's is in the
readme of python-subunit project.

As for keywords that can exist, there is "tags:", but in the case of
tempe

[Xen-devel] [xen-unstable test] 111751: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 111664
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 111664
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 111664
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 111693
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111722
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111722
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 111722
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111722
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111722
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-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-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-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   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-libvirt-xsm 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-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  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   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-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  614a14736e33fb84872eb00f08799ebbc73a96c6
baseline version:
 xen  89df98b77d28136c4d7aade13a1c8bc154d2919f

Last test of basis   111722  2017-07-12 07:18:53 Z1 days
Testing same since   111751  2017-07-12 23:54:26 Z0 days1 attempts


People who touched revisions under test:
  Wei Liu 
  Xiong Zhang 

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

Re: [Xen-devel] [PATCH v1] xen/grant-table: log the lack of grants

[Wengang]

Hi,

Anyone can you please review this patch?

thanks,

wengang


On 07/07/2017 11:23 AM, Wengang Wang wrote:

log a message when we enter this situation:
1) we already allocated the max number of available grants from hypervisor
and
2) we still need more (but the request fails because of 1)).

Sometimes the lack of grants causes IO hangs in xen_blkfront devices.
Adding this log would help debuging.

Signed-off-by: Wengang Wang 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Junxiao Bi 
---
  drivers/xen/grant-table.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index d6786b8..2c6a911 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -42,6 +42,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -1072,8 +1073,14 @@ static int gnttab_expand(unsigned int req_entries)
cur = nr_grant_frames;
extra = ((req_entries + (grefs_per_grant_frame-1)) /
 grefs_per_grant_frame);
-   if (cur + extra > gnttab_max_grant_frames())
+   if (cur + extra > gnttab_max_grant_frames()) {
+   pr_warn_ratelimited("xen/grant-table: max_grant_frames reached"
+   " cur=%u extra=%u limit=%u"
+   " gnttab_free_count=%u req_entries=%u\n",
+   cur, extra, gnttab_max_grant_frames(),
+   gnttab_free_count, req_entries);
return -ENOSPC;
+   }
  
  	rc = gnttab_map(cur, cur + extra - 1);

if (rc == 0)



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

Re: [Xen-devel] [OSSTEST PATCH v12 18/21] TestSupport: Implement target_cmd_subunit a subunit stream parser into substeps

[Anthony PERARD]

On Thu, Jul 13, 2017 at 03:43:55PM +0100, Anthony PERARD wrote:
> On Thu, Jul 13, 2017 at 02:28:11PM +0100, Ian Jackson wrote:
> > Anthony PERARD writes ("[OSSTEST PATCH v12 18/21] TestSupport: Implement 
> > target_cmd_subunit a subunit stream parser into substeps"):
> > > +sub target_cmd_subunit ($$;$$) {
> > > +my $stdout = IO::File::new_tmpfile();
> > > +my $rc = tcmd(undef,$stdout,0, 'osstest', @_);
> > 
> > It would be better to staxh the original subunit output.  And I would
> > prefer to avoid direct use of tcmd here.  So can you introduce
> >target_cmd_stashed
> > which calls open_unique_stashfile and tcmd, and then use that in your
> > subunit subroutine?  (And yes this might duplicte output I think.)
> 
> Will do. And yes, this will duplicate most of the output. But it can
> help debug osstest, for everything that the parser ignore.

I can't figure out what should target_cmd_stashed prototype be. Should
it be like target_cmd_output (returning the output of the cmd) ? Or
maybe like target_cmd but return a filename (which contain the output of
the cmd) ? I thought also about returning an file descriptor but it may
not be a good idee to leave the caller with an open fd.

Also, how to call the stashed file ? So far, I would go with "$job". Or
maybe adding an argument to target_cmd_stashed so the caller can choose
a filename.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v13 12/23] x86: refactor psr: L3 CAT: set value: implement write msr flow.

[Jan Beulich]

>>> Yi Sun  07/13/17 9:34 AM >>>
>On 17-07-12 23:20:24, Jan Beulich wrote:
>> >>> Yi Sun  07/13/17 5:00 AM >>>
>> >On 17-07-12 13:37:02, Jan Beulich wrote:
>> >> >>> Yi Sun  07/06/17 4:07 AM >>>
>> >> >+if ( socket == cpu_to_socket(smp_processor_id()) )
>> >> >+do_write_psr_msrs(&data);
>> >> >+else
>> >> >+{
>> >> >+unsigned int cpu = get_socket_cpu(socket);
>> >> >+
>> >> >+if ( cpu >= nr_cpu_ids )
>> >> >+return -ENOTSOCK;
>> >> >+on_selected_cpus(cpumask_of(cpu), do_write_psr_msrs, &data, 1);
>> >> 
>> >> How frequent an operation can this be? Considering that the actual MSR 
>> >> write(s)
>> >> in the handler is (are) conditional I wonder whether it wouldn't be 
>> >> worthwhile
>> >> trying to avoid the IPI altogether, by pre-checking whether any write 
>> >> actually
>> >> needs doing.
>> >> 
>> >Yes, I think I can check if the value to set is same as 
>> >'feat->cos_reg_val[cos]'
>> >before calling IPI.
>> 
>> Well, as said - whether it's worth the extra effort depends on whether there 
>> is
>> a (reasonable) scenario where this function may be executed frequently.
>> 
>This function is executed when 'psr-cat-set' command is executed. I consult
>the libvirt guy, this command may be executed frequently under some scenarios.
>E.g. user may dynamically adjust the cache allocation for VMs according to CMT
>result.

Hmm, that's not something I would call frequent - in the whole invocation of the
user mode process the IPI will be lost in the noise. "Frequent" would be 
something
the kernel does without direct user mode triggering, like on the context switch
path, in code running from a timer, or some such.

Jan


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

Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send

[Jan Beulich]

>>> Andrew Cooper  07/13/17 9:50 AM >>>
>RFC: is it worth converting the close, unmask, reset (and possibly
>expand_array) as well?

I can't see close and even more so reset to be performance critical.
Unmask otoh may be (depending on use); no sure about expand_array.

Jan


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

Re: [Xen-devel] [PATCH v4 2/9] x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas

[Jan Beulich]

>>> Roger Pau Monne  06/30/17 5:02 PM >>>
> @@ -1041,6 +1043,24 @@ static int __init pvh_setup_acpi(struct domain *d, 
> paddr_t start_info)
>  return 0;
>  }
>  
> +int __init pvh_setup_mmcfg(struct domain *d)

Didn't I point out that __init van't be correct here, and instead this
needs to be __hwdom_init? I can see that the only current caller is
__init, but that merely suggests there is a second call missing.

> +{
> +unsigned int i;
> +int rc;
> +
> +for ( i = 0; i < pci_mmcfg_config_num; i++ )
> +{
> +rc = register_vpci_mmcfg_handler(d, pci_mmcfg_config[i].address,
> + 
> pci_mmcfg_config[i].start_bus_number,
> + pci_mmcfg_config[i].end_bus_number,
> + pci_mmcfg_config[i].pci_segment);
> +if ( rc )
> +return rc;

I would make this a best effort thing, i.e. issue a log message upon
failure but continue the loop. There's a good chance Dom0 will still
be able to come up.

> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -261,11 +261,11 @@ void register_g2m_portio_handler(struct domain *d)
>  static int vpci_access_check(unsigned int reg, unsigned int len)
>  {
>  /* Check access size. */
> -if ( len != 1 && len != 2 && len != 4 )
> +if ( len != 1 && len != 2 && len != 4 && len != 8 )
>  return -EINVAL;
>  
> -/* Check if access crosses a double-word boundary. */
> -if ( (reg & 3) + len > 4 )
> +/* Check if access crosses a double-word boundary or it's not aligned. */
> +if ( (len <= 4 && (reg & 3) + len > 4) || (len == 8 && (reg & 3) != 0) )
>  return -EINVAL;

For one I suppose you mean "& 7" in the 8-byte case. And then I don't
understand why you permit mis-aligned 2-byte writes, but not mis-aligned
4-byte ones as long as they fall withing a quad-word. Any such asymmetry
needs at least a comment.

> @@ -398,6 +398,188 @@ void register_vpci_portio_handler(struct domain *d)
>  handler->ops = &vpci_portio_ops;
>  }
>  
> +struct hvm_mmcfg {
> +paddr_t addr;
> +size_t size;

paddr_t and size_t don't really fit together, most notably on 32-bit.
As I don't think any individual range can possibly be 4Gb or larger, I
think unsigned int would suffice here.

> +unsigned int bus;
> +unsigned int segment;

Depending on how many instances of this structure we expect, it may be
worthwhile to limit these two to 8 and 16 bits respectively.

> +/* Handlers to trap PCI ECAM config accesses. */

An "ECAM" did survive here.

> +static const struct hvm_mmcfg *vpci_mmcfg_find(struct domain *d,
> +   unsigned long addr)

paddr_t (to match the structure field)

> +static void vpci_mmcfg_decode_addr(const struct hvm_mmcfg *mmcfg,
> +   unsigned long addr, unsigned int *bus,

Same here (and it seems more below). Also, just like in patch 1,
perhaps return the register by value rather than via indirection.

> +   unsigned int *slot, unsigned int *func,
> +   unsigned int *reg)
> +{
> +addr -= mmcfg->addr;
> +*bus = ((addr >> 20) & 0xff) + mmcfg->bus;
> +*slot = (addr >> 15) & 0x1f;
> +*func = (addr >> 12) & 0x7;
> +*reg = addr & 0xfff;

Iirc there already was a comment to use manifest constants or macros
here.

> +static int vpci_mmcfg_accept(struct vcpu *v, unsigned long addr)
> +{
> +struct domain *d = v->domain;
> +bool found;
> +
> +vpci_lock(d);
> +found = vpci_mmcfg_find(d, addr);
> +vpci_unlock(d);

The latest here I wonder whether the lock wouldn't better be an r/w one.

> +static int vpci_mmcfg_read(struct vcpu *v, unsigned long addr,
> +   unsigned int len, unsigned long *data)

uint64_t * (to be 32-bit compatible)

> +{
> +struct domain *d = v->domain;
> +   > +
> +vpci_lock(d);
> +mmcfg = vpci_mmcfg_find(d, addr);
> +if ( !mmcfg )
> +{
> +vpci_unlock(d);
> +return X86EMUL_OKAY;
> +}
> +
> +vpci_mmcfg_decode_addr(mmcfg, addr, &bus, &slot, &func, ®);
> +
> +if ( vpci_access_check(reg, len) )
> +{
> +vpci_unlock(d);
> +return X86EMUL_OKAY;
> +}
> +
> +pcidevs_lock();
> +if ( len == 8 )
> +{
> +/*
> + * According to the PCIe 3.1A specification:
> + *  - Configuration Reads and Writes must usually be DWORD or smaller
> + *in size.
> + *  - Because Root Complex implementations are not required to 
> support
> + *accesses to a RCRB that cross DW boundaries [...] software
> + *should take care not to cause the generation of such accesses
> + *when accessing a RCRB unless the Root Complex will support the
> + *access.
> + *  Xen however supports 8byte accesses by splitting them into two
> + *  4

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  3d52a8444bc01d8d3d1b7a38976633fcbc645d21
baseline version:
 libvirt  fde654be5307a570b7b0f31537e18e70a274cd50

Last test of basis   111718  2017-07-12 04:21:05 Z1 days
Testing same since   111755  2017-07-13 04:20:19 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Michal Privoznik 

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



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

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

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
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=libvirt
+ re

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

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71688 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71688/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 71684
 test-armhf-armhf-examine 10 examine-serial/bootloader fail REGR. vs. 71684
 test-armhf-armhf-examine 11 examine-serial/kernel fail REGR. vs. 71684
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-installfail REGR. vs. 71684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
71684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
71684
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
71684

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   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-libvirt-xsm 14 saverestore-support-checkfail   like 71684
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 71684
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   like 71684
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 71684
 test-amd64-amd64-xl-rtds 10 debian-install   fail   like 71684
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 71684
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 71684
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail 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-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-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-raw 12 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass

version targeted for testing:
 xen  614a14736e33fb84872eb00f08799ebbc73a96c6
baseline version:
 xen  89df98b77d28136c4d7aade13a1c8bc154d2919f

Last test of basis716

[Xen-devel] [linux-4.9 test] 111763: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
111411
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 111411

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail in 111737 
pass in 111763
 test-arm64-arm64-xl-credit2   7 xen-boot   fail pass in 111737
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail pass in 111737

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

Re: [Xen-devel] [PATCH v13 12/23] x86: refactor psr: L3 CAT: set value: implement write msr flow.

[Yi Sun]

On 17-07-13 13:21:46, Jan Beulich wrote:
> >>> Yi Sun  07/13/17 9:34 AM >>>
> >On 17-07-12 23:20:24, Jan Beulich wrote:
> >> >>> Yi Sun  07/13/17 5:00 AM >>>
> >> >On 17-07-12 13:37:02, Jan Beulich wrote:
> >> >> >>> Yi Sun  07/06/17 4:07 AM >>>
> >> >> >+if ( socket == cpu_to_socket(smp_processor_id()) )
> >> >> >+do_write_psr_msrs(&data);
> >> >> >+else
> >> >> >+{
> >> >> >+unsigned int cpu = get_socket_cpu(socket);
> >> >> >+
> >> >> >+if ( cpu >= nr_cpu_ids )
> >> >> >+return -ENOTSOCK;
> >> >> >+on_selected_cpus(cpumask_of(cpu), do_write_psr_msrs, &data, 
> >> >> >1);
> >> >> 
> >> >> How frequent an operation can this be? Considering that the actual MSR 
> >> >> write(s)
> >> >> in the handler is (are) conditional I wonder whether it wouldn't be 
> >> >> worthwhile
> >> >> trying to avoid the IPI altogether, by pre-checking whether any write 
> >> >> actually
> >> >> needs doing.
> >> >> 
> >> >Yes, I think I can check if the value to set is same as 
> >> >'feat->cos_reg_val[cos]'
> >> >before calling IPI.
> >> 
> >> Well, as said - whether it's worth the extra effort depends on whether 
> >> there is
> >> a (reasonable) scenario where this function may be executed frequently.
> >> 
> >This function is executed when 'psr-cat-set' command is executed. I consult
> >the libvirt guy, this command may be executed frequently under some 
> >scenarios.
> >E.g. user may dynamically adjust the cache allocation for VMs according to 
> >CMT
> >result.
> 
> Hmm, that's not something I would call frequent - in the whole invocation of 
> the
> user mode process the IPI will be lost in the noise. "Frequent" would be 
> something
> the kernel does without direct user mode triggering, like on the context 
> switch
> path, in code running from a timer, or some such.
> 
Then, it is not 'Frequent'. This function is only trigger by user. So, I
will keep current codes. Thanks!

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

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

Re: [Xen-devel] [PATCH v8 1/5] x86: add simple udelay calibration

[Dou Liyang]

Hi, Lu

At 07/13/2017 11:00 AM, Lu Baolu wrote:

Hi,

On 07/13/2017 09:39 AM, Dou Liyang wrote:

Hi, Lu

At 07/13/2017 09:17 AM, Lu Baolu wrote:

Hi,

On 07/12/2017 04:02 PM, Dou Liyang wrote:

Hi, Lu

At 05/05/2017 08:50 PM, Boris Ostrovsky wrote:

On 05/05/2017 01:41 AM, Lu Baolu wrote:

Hi,

On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:

On 03/21/2017 04:01 AM, Lu Baolu wrote:

Add a simple udelay calibration in x86 architecture-specific
boot-time initializations. This will get a workable estimate
for loops_per_jiffy. Hence, udelay() could be used after this
initialization.

This breaks Xen PV guests since at this point, and until
x86_init.paging.pagetable_init() which is when pvclock_vcpu_time_info is
mapped, they cannot access pvclock.

Is it reasonable to do this before tsc_init() is called? (The failure
has nothing to do with tsc_init(), really --- it's just that it is
called late enough that Xen PV guests get properly initialized.) If it
is, would it be possible to move simple_udelay_calibration() after
x86_init.paging.pagetable_init()?

This is currently only used for bare metal. How about by-pass it
for Xen PV guests?


It is fixed this for Xen PV guests now (in the sense that we don't crash
anymore) but my question is still whether this is not too early. Besides
tsc_init() (which might not be important here), at the time when
simple_udelay_calibration() is invoked we haven't yet called:
* kvmclock_init(), which sets calibration routines for KVM
* init_hypervisor_platform(), which sets calibration routines for vmware
and Xen HVM
* x86_init.paging.pagetable_init(), which sets calibration routines for
Xen PV



I guess these may have been missed.

Do you have any comments about these?



The patch will be available in 4.13-rc1.


Yes, I have seen it in the upstream.

Firstly, I also met this problem want to call udelay() earlier than
*loops_per_jiffy* setup like you[1]. So I am very interesting in this
patch. ;)

I am also confused about the questions which Boris asked:

whether do the CPU and TSC calibration too early just for using
udelay()?

this design broke our interface of x86_paltform.calibrate_cpu/tsc.

And I also have a question below.

[...]



+static void __init simple_udelay_calibration(void)
+{
+unsigned int tsc_khz, cpu_khz;
+unsigned long lpj;
+
+if (!boot_cpu_has(X86_FEATURE_TSC))
+return;


if we don't have the TSC feature in booting CPU and
it returns here,  can we use udelay() correctly like before?



If we have TSC feature, we calculate a preciser loops_per_jiffy here.
Otherwise, we just keep it as before. This function doesn't broke the
use of udelay().


Oh, I see.

In  XDbC (XHCI debug capability), we just want the udelay() work more 
precisely in the TSC supported system.


It is different with my problem I missed.

Thanks for your kind explanation. :)

Thanks,

dou



Best regards,
Lu Baolu



[1] https://lkml.org/lkml/2017/7/3/276

Thanks,

dou.


Thanks,

dou.


+
+cpu_khz = x86_platform.calibrate_cpu();
+tsc_khz = x86_platform.calibrate_tsc();
+
+tsc_khz = tsc_khz ? : cpu_khz;
+if (!tsc_khz)
+return;
+
+lpj = tsc_khz * 1000;
+do_div(lpj, HZ);
+loops_per_jiffy = lpj;
+}
+
 /*
  * Determine if we were loaded by an EFI loader.  If so, then we have also been
  * passed the efi memmap, systab, etc., so we should use these data structures
@@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
  */
 x86_configure_nx();

+simple_udelay_calibration();
+
 parse_early_param();

 #ifdef CONFIG_MEMORY_HOTPLUG








--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html









--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html










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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf b926f2f2a4cd404df1d2c1dddbcd1178acc63b5e
baseline version:
 ovmf b1fe2029fa2f473922fb830a2e33c5ae0c0ae20d

Last test of basis   111715  2017-07-12 03:10:33 Z2 days
Testing same since   111785  2017-07-14 00:47:37 Z0 days1 attempts


People who touched revisions under test:
  Michael 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.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=b926f2f2a4cd404df1d2c1dddbcd1178acc63b5e
+ . ./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 
b926f2f2a4cd404df1d2c1dddbcd1178acc63b5e
+ branch=ovmf
+ revision=b926f2f2a4cd404df1d2c1dddbcd1178acc63b5e
+ . ./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
+ '[' xb926f2f2a4cd404df1d2c1dddbcd1178acc63b5e = 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
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvo

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 111732

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111732
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 111732
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111732
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111732
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 111732
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111732
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-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-libvirt-xsm 13 migrate-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-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 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-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-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu31fe1c414501047cbb91b695bdccc0068496dcf6
baseline version:
 qemuuaa916e409c04cb614ec2fee8b6b33836bf5998bb

Last test of basis   111732  2017-07-12 09:56:34 Z1 days
Testing same since   111765  2017-07-13 10:20:16 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Lluís Vilanova 
  Peter Maydell 
  Stefan Hajnoczi 

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

[Xen-devel] [linux-3.18 test] 111770: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 111523 
pass in 111770
 test-amd64-amd64-xl-rtds 10 debian-install   fail in 111745 pass in 111523
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 111745 pass in 
111770
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 111745 
pass in 111770
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail pass in 111523
 test-amd64-amd64-xl-rtds  7 xen-boot   fail pass in 111745
 test-armhf-armhf-xl-arndale   6 xen-installfail pass in 111745

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
 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
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 110441
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111523 
blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111523 
blocked in 110441
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 111745 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 111745 never 
pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 110441
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail like 110441
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110441
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  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-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   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-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-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-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-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-raw 12 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-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-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux

Re: [Xen-devel] [PATCH v4 00/17] xen: common: rbtree: ported updates from Linux tree

[Praveen Kumar]

On Tue, 2017-07-04 at 14:44 +0530, Praveen Kumar wrote:
> On Tue, 2017-07-04 at 10:49 +0200, Dario Faggioli wrote:
> > 
> > On Tue, 2017-07-04 at 01:28 +0530, Praveen Kumar wrote:
> > > 
> > > 
> > > Below are the categorized Linux commit versions which are not
> > > imported :
> > > 
> > > Augmented rbtree :
> > > 14b94af0b251a2c80885b60538166fb7d04a642e
> > > 9d9e6f9703bbd642f3f2f807e6aaa642a4cbcec9
> > > 9c079add0d0f45220f4bb37febf0621137ec2d38
> > > 3cb7a56344ca45ee56d71c5f8fe9f922306bff1f
> > > 
> > > Add postorder iteration functions:
> > > 9dee5c51516d2c3fff22633c1272c5652e68075a
> > > 
> > > RCU related implementation :
> > > 
> > What about "Lockless access improvements"
> > 
Dario,

Did you mean to import Lockless improvement with the updated patch ?
Can you please provide more clarity on this. Thanks in advance.

> > > 
> > > 
> > > ce093a04543c403d52c1a5788d8cb92e47453aba
> > > 
> > Mmm... this last one is "lib/rbtree.c: fix typo in comment of
> > rb_erase_color". Did we agree together of excluding it? If yes,
> > can
> > you state here why? If not, why are we excluding it? :-)
> > 
> >  
> The respective patch has subsequent changes done on top of augmented
> and other features, which we excluded. So, I think, its not
> applicable
> for now.
> 
> Regards,
> 
> ~Praveen.

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

Re: [Xen-devel] [PATCH v4 00/17] xen: common: rbtree: ported updates from Linux tree

[Praveen Kumar]

On Tue, 2017-07-04 at 10:45 +0200, Dario Faggioli wrote:
> On Tue, 2017-07-04 at 02:27 -0600, Jan Beulich wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > On 03.07.17 at 21:58,  wrote:
> > > 
> > > Use of designated initializers :
> > > f231aebfc4cae2f6ed27a46a31e2630909513d77
> > 
> > Unless none of the changes actually apply to our code, I can't see
> > why we wouldn't want to take something like this. I do note though
> > that only augmenting callbacks are being affected, in which case
> > grouping the commit there would have been better for people to
> > understand why you exclude it.
> > 
> I agree.
> 
> It's actually ok to keep this out, but it should be listed in the
> first
>  group of excluded commits ("Augmented rbtree").
> 
> Dario

Yes, this should be part of "Augmented rbtree" list. Will send the
updated patches soon. Thanks.

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

Re: [Xen-devel] [PATCH v4 01/17] rbtree: changes to inline coding conventions with Linux tree

[Praveen Kumar]

On Tue, 2017-07-04 at 02:24 -0600, Jan Beulich wrote:
> > 
> > > 
> > > > 
> > > > On 03.07.17 at 21:58,  wrote:
> > The patch inlines the rbtree related files to Linux coding
> > conventions to have
> > limited conflicts in future while porting from Linux tree.
> 
> "inlines" has a different meaning most of the time - how about
> "brings in line" (but I'll be happy to be corrected by a native
> speaker)? This would then also call for a change to the subject.
> 
> What I'm missing though is a reference to the Linux version to
> compare with - this is especially relevant because the format
> the patch brings the code into is not normal Linux style (but I
> do see that e.g. in 3.0 such oddities indeed existed).
> 
Jan,

Is it ok to add the last reference from Linux tree, which has already
been ported to Xen code base till date, so that we can diff from start
and verify that its only coding style changed and not anything else ?

> Also please state explicitly whether what you do are _only_
> style changes, making quite a bit of a difference to the level
> of review needed.

Sure, will update the same. Thanks.
> 
> Jan
> 

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

[Xen-devel] [PATCH v7 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system

[Dou Liyang]

XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus()
initializes interrupts in the XEN PV specific way and does not invoke
native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is
not invoked either.

The invocation of x86_init.intr_mode_init() will be moved from
native_smp_prepare_cpus() in a follow up patch to solve .

That move would cause the invocation of x86_init.intr_mode_init() for XEN
PV platforms. To prevent that, override the default x86_init.intr_mode_init()
callback with a noop().

[Rewrited by Thomas Gleixner ]

Signed-off-by: Dou Liyang 
Cc: xen-de...@lists.xenproject.org
Cc: boris.ostrov...@oracle.com
---
 arch/x86/xen/enlighten_pv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 811e4dd..07147dd 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1250,6 +1250,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
x86_platform.get_nmi_reason = xen_get_nmi_reason;
 
x86_init.resources.memory_setup = xen_memory_setup;
+   x86_init.irqs.intr_mode_init= x86_init_noop;
x86_init.oem.arch_setup = xen_arch_setup;
x86_init.oem.banner = xen_banner;
 
-- 
2.5.5




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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf b926f2f2a4cd404df1d2c1dddbcd1178acc63b5e
baseline version:
 ovmf b1fe2029fa2f473922fb830a2e33c5ae0c0ae20d

Last test of basis71685  2017-07-12 07:19:30 Z1 days
Testing same since71689  2017-07-14 03:51:09 Z0 days1 attempts


People who touched revisions under test:
  Michael 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 b926f2f2a4cd404df1d2c1dddbcd1178acc63b5e
Author: Michael Kinney 
Date:   Tue Jan 31 09:21:20 2017 -0800

BaseTools/Build: Support python scripts in PREBUILD/POSTBUILD

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

Add shell=True in Popen() calls to support direct execution of
python scripts

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
Reviewed-by: Yonghong Zhu 

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