Re: [Xen-devel] [PATCH 05/15] xen: p2m: new 'p2m_epc' type for EPC mapping

[Huang, Kai]

On 7/13/2017 12:21 AM, George Dunlap wrote:



On Jul 12, 2017, at 1:01 PM, Andrew Cooper  wrote:

On 09/07/17 10:12, Kai Huang wrote:

A new 'p2m_epc' type is added for EPC mapping type. Two wrapper functions
set_epc_p2m_entry and clear_epc_p2m_entry are also added for further use.


Other groups in Intel have been looking to reduce the number of p2m types we 
have, so we can use more hardware defined bits in the EPT pagetable entries.

If we need a new type then we will certainly add one, but it is not clear why 
this type is needed.


Does the hypervisor need to know which pages of a domain’s p2m 1) have valid 
config set up, but 2) aren’t accessible to itself or any other domain?


Hi Andrew, George,

Actually I haven't thought this thoroughly, but my first glance is 
there's no existing p2m_type that can be reasonably used for EPC. 
Probably p2m_ram_rw or p2m_mmio_direct are two potential candidates. For 
EPC, for *static partitioning* Xen hypervisor just needs to setup 
mappings and then leave it until guest is destroyed. But for p2m_ram_rw 
and p2m_mmio_direct there are additional logic when Xen learns about the 
two types. To me adding 'p2m_epc' is more straightforward and safe. 
Maybe we can change to a more generic name such as 'p2m_ram_encrypted'? 
But again I am not sure other encryption technology can also be applied 
to EPC.




  -George
___
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 08/15] xen: x86: add SGX cpuid handling support.

[Huang, Kai]

On 7/12/2017 10:56 PM, Andrew Cooper wrote:

On 09/07/17 10:10, Kai Huang wrote:

This patch adds SGX to cpuid handling support. In init_guest_cpuid, for
raw_policy and host_policy, physical EPC info is reported, but for 
pv_max_policy
and hvm_max_policy EPC is hidden, as for particular domain, it's EPC 
base and
size are from tookstack, and it is meaningless to contain physical EPC 
info in
them. Before domain's EPC base and size are properly configured, 
guest's SGX
cpuid should report invalid EPC, which is also consistent with HW 
behavior.


Currently all EPC pages are fully populated for domain when it is 
created.
Xen gets domain's EPC base and size from toolstack via 
XEN_DOMCTL_set_cpuid,

so domain's EPC pages are also populated in XEN_DOMCTL_set_cpuid, after
receiving valid EPC base and size. Failure to populate EPC (such as 
there's

no enough free EPC pages) results in domain creation failure by making
XEN_DOMCTL_set_cpuid return error.

Signed-off-by: Kai Huang 
---
  xen/arch/x86/cpuid.c| 87 
-

  xen/arch/x86/domctl.c   | 47 +++-
  xen/include/asm-x86/cpuid.h | 26 +-
  3 files changed, 157 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index d359e090f3..db896be2e8 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include 
  const uint32_t known_features[] = INIT_KNOWN_FEATURES;
  const uint32_t special_features[] = INIT_SPECIAL_FEATURES;
@@ -158,6 +159,44 @@ static void recalculate_xstate(struct 
cpuid_policy *p)

  }
  }
+static void recalculate_sgx(struct cpuid_policy *p, bool_t hide_epc)


Across the entire series, please use bool rather than bool_t.

Hi Andrew,

Thank you very much for comments.

Will do.



Why do we need this hide_epc parameter?  If we aren't providing any epc 
resource to the guest, the entire sgx union should be zero and the SGX 
feature bit should be hidden.


My intention was to hide physical EPC info for pv_max_policy and 
hvm_max_policy (recalculate_sgx is also called by 
calculate_pv_max_policy and calculate_hvm_max_policy), as they are for 
guest and don't need physical EPC info. But keeping physical EPC info in 
them does no harm so I think we can simply remove hide_epc.


IMO we cannot check whether EPC is valid and zero sgx union in 
recalculate_sgx, as it is called for each CPUID. For example, it is 
called for SGX subleaf 0, and 1, and then 2, and when subleaf 0 and 1 
are called, the EPC resource is 0 (hasn't been configured).





+{
+if ( !p->feat.sgx )
+{
+memset(>sgx, 0, sizeof (p->sgx));
+return;
+}
+
+if ( !p->sgx.sgx1 )
+{
+memset(>sgx, 0, sizeof (p->sgx));
+return;
+}


These two clauses can be combined.


Will do.




+
+/*
+ * SDM 42.7.2.1 SECS.ATTRIBUTE.XFRM:
+ *
+ * Legal value for SECS.ATTRIBUTE.XFRM conform to these 
requirements:

+ *  - XFRM[1:0] must be set to 0x3;
+ *  - If processor does not support XSAVE, or if the system 
software has not

+ *enabled XSAVE, then XFRM[63:2] must be 0.
+ *  - If the processor does support XSAVE, XFRM must contain a 
value that

+ *would be legal if loaded into XCR0.
+ */
+p->sgx.xfrm_low = 0x3;
+p->sgx.xfrm_high = 0;
+if ( p->basic.xsave )
+{
+p->sgx.xfrm_low |= p->xstate.xcr0_low;
+p->sgx.xfrm_high |= p->xstate.xcr0_high;
+}


There is a bug here, but it will disappear with my CPUID work.  At the 
moment, the job of this function is to sanitise values handed by the 
toolstack, which includes zeroing all the reserved bits.  This is 
because there is currently no way to signal a failure.


When I fix the toolstack interface, the toolstack will propose a new 
CPUID policy, and Xen will have a function to check it against the 
architectural requirements.  At that point, we will be applying checks, 
but not modifying the contents.


I think I need to look at your design first and then I should be able to 
understand your comment. :)





+
+if ( hide_epc )
+{
+memset(>sgx.raw[0x2], 0, sizeof (struct cpuid_leaf));
+}
+}
+
  /*
   * Misc adjustments to the policy.  Mostly clobbering reserved 
fields and
   * duplicating shared fields.  Intentionally hidden fields are 
annotated.

@@ -239,7 +278,7 @@ static void __init calculate_raw_policy(void)
  {
  switch ( i )
  {
-case 0x4: case 0x7: case 0xd:
+case 0x4: case 0x7: case 0xd: case 0x12:
  /* Multi-invocation leaves.  Deferred. */
  continue;
  }
@@ -299,6 +338,19 @@ static void __init calculate_raw_policy(void)
  }
  }
+if ( p->basic.max_leaf >= SGX_CPUID )
+{
+/*
+ * For raw policy we just report native CPUID. For EPC on 
native it's
+ * possible that we will have 

Re: [Xen-devel] [PATCH v13 13/23] x86: refactor psr: CDP: implement CPU init flow.

[Jan Beulich]

>>> "Jan Beulich"  07/13/17 7:24 AM >>>
 Yi Sun  07/13/17 5:04 AM >>>
>>On 17-07-12 13:52:35, Jan Beulich wrote:
>>> >>> Yi Sun  07/06/17 4:07 AM >>>
>>> >This patch implements the CPU init flow for CDP. The flow is almost
>>> >same as L3 CAT.
>>> >
>>> >Note: CDP does NOT work until you apply the later patches of CDP.
>>> >"x86: refactor psr: CDP: implement get hw info flow."
>>> >"x86: refactor psr: CDP: implement set value callback function."
>>> 
>>> This is _not_ what I did ask for in what I assume ...
>>> 
>>> >v13:
>>> >- add commit message.
>>> 
>>> ... this refers to: The problem isn't that it won't work, but that it'll 
>>> crash the
>>> hypervisor. So what I had expected you to add is a note _after_ the first
>>> --- separator that this patch should not be applied without the other two
>>> ones. Or alternatively for this one to add stubs which the subsequent
>>> patches would then fill.
>>> 
>>Oh, ok. I will move the comments under the first '---'. Furthermore, I'd like
>>to add a 'stub_write_msr()' here to avoid crash. Will replace the stub 
>>function
>>to real function when implementing the write flow.
>
>Just to avoid any misunderstanding: I hope you don't mean to indeed
>introduce and then replace a function by that name. Just like you've done
>in earlier patches, introduce the function with it final name right away, and
>just fill its body in the later patch.

Oh, and - when you go this route, the must-be-committed-together requirement
would go away altogether, so no need for such a remark anymore.

Jan


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

Re: [Xen-devel] [PATCH v13 13/23] x86: refactor psr: CDP: implement CPU init flow.

[Jan Beulich]

>>> Yi Sun  07/13/17 5:04 AM >>>
>On 17-07-12 13:52:35, Jan Beulich wrote:
>> >>> Yi Sun  07/06/17 4:07 AM >>>
>> >This patch implements the CPU init flow for CDP. The flow is almost
>> >same as L3 CAT.
>> >
>> >Note: CDP does NOT work until you apply the later patches of CDP.
>> >"x86: refactor psr: CDP: implement get hw info flow."
>> >"x86: refactor psr: CDP: implement set value callback function."
>> 
>> This is _not_ what I did ask for in what I assume ...
>> 
>> >v13:
>> >- add commit message.
>> 
>> ... this refers to: The problem isn't that it won't work, but that it'll 
>> crash the
>> hypervisor. So what I had expected you to add is a note _after_ the first
>> --- separator that this patch should not be applied without the other two
>> ones. Or alternatively for this one to add stubs which the subsequent
>> patches would then fill.
>> 
>Oh, ok. I will move the comments under the first '---'. Furthermore, I'd like
>to add a 'stub_write_msr()' here to avoid crash. Will replace the stub function
>to real function when implementing the write flow.

Just to avoid any misunderstanding: I hope you don't mean to indeed
introduce and then replace a function by that name. Just like you've done
in earlier patches, introduce the function with it final name right away, and
just fill its body in the later patch.

>> >+if ( (regs.c & PSR_CAT_CDP_CAPABILITY) && (opt_psr & PSR_CDP) )
>> >+{
>> >+feat = feat_l3_cdp;
>> >+feat_l3_cdp = NULL;
>> >+if ( !cat_init_feature(®s, feat, info, FEAT_TYPE_L3_CDP) )
>> >+feat_props[FEAT_TYPE_L3_CDP] = _cdp_props;
>> >+}
>> >+else
>> >+{
>> >+feat = feat_l3_cat;
>> >+feat_l3_cat = NULL;
>> >+if ( !cat_init_feature(®s, feat, info, FEAT_TYPE_L3_CAT) )
>> >+feat_props[FEAT_TYPE_L3_CAT] = _cat_props;
>> >+}
>> 
>> ... wouldn't it be a good idea to then try to setup plain L3 CAT here?
>> 
>DYM if CDP init fails, enter CAT init flow to make CAT work at least?

Yes.

Jan


___
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 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.

>> >+if ( socket == cpu_to_socket(smp_processor_id()) )
>> >+do_write_psr_msrs();
>> >+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, , 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.

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

Jan


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

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

[Mauro Carvalho Chehab]

Em Tue, 11 Jul 2017 15:35:15 -0700
Linus Torvalds  escreveu:

> [ Very random list of maintainers and mailing lists, at least
> partially by number of warnings generated by gcc-7.1.1 that is then
> correlated with the get_maintainers script ]

Under drivers/media, I fixed a bunch of gcc 7.1 warnings before the
merge window. While most were just noise, some actually pointed to
human errors.

Now, gcc-7.1.1 produces only 6 warnings with W=1 on x86_64 (allyesconfig), 
either due to unused-but-set-variable or unused-const-variable. I guess
both warning options are disabled by default. Anyway, I have patches
to fix them already. I'll send you later.

The atomisp staging driver is a completely different beast, with would
produce itself a huge amount of warnings. I ended by adding some
logic on drivers/staging/media/atomisp/ Makefiles to disable them:

ccflags-y += $(call cc-disable-warning, missing-declarations)
ccflags-y += $(call cc-disable-warning, missing-prototypes)
ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
ccflags-y += $(call cc-disable-warning, unused-const-variable)
ccflags-y += $(call cc-disable-warning, suggest-attribute=format)
ccflags-y += $(call cc-disable-warning, implicit-fallthrough)

(there's actually one patch pending related to atomisp, that I'll also
be sending you soon - meant to avoid warnings if compiled with an older
gcc version)

Thanks,
Mauro

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair  16 debian-install/dst_host fail in 111703 pass in 111732
 test-armhf-armhf-xl 16 guest-start/debian.repeat fail in 111703 pass in 111732
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail in 111703 pass in 
111732
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 111703

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 111379
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 111379
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail like 111379
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111403
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111403
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111403
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111403
 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-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 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-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-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:
 qemuuaa916e409c04cb614ec2fee8b6b33836bf5998bb
baseline version:
 qemuu2185c93ba80f81bfa27ce6f259c7f2ef4f08b668

Last test of basis   111403  2017-07-05 10:31:25 Z7 days
Failing since111475  2017-07-06 11:14:43 Z6 days9 attempts
Testing same since   111703  2017-07-11 22:26:01 Z1 days2 attempts


People who touched revisions under test:
  Aaron Larson 
  Alex Williamson 
  Alistair Francis 
  Anoob Soman 
  Anthony Liguori 
  Anthony PERARD 

Re: [Xen-devel] [PATCH 04/15] xen: mm: add ioremap_cache

[Huang, Kai]

On 7/12/2017 7:13 PM, Julien Grall wrote:



On 07/12/2017 02:52 AM, Huang, Kai wrote:

Hi Julien,


Hello Kai,

Please avoid top-posting.


Sorry. Will avoid in the future :)




Thanks for pointing out. I'll move to x86 specific.

I've cc-ed all maintainers reported by ./scripts/get_maintainer.pl, 
looks this script doesn't report all maintainers. Sorry. I'll add ARM 
maintainers next time. 


I would always double check the result of scripts/get_maintainer.pl. I 
am aware of a bug in scripts/get_maintainers.pl where only maintainer of 
the specific component (here x86) are listed, even when you touch common 
code.


In this case, I didn't ask to CC ARM maintainers, but CC "THE REST" 
group (see MAINTAINERS).


Understood. I'll follow in the future.

Thanks,
-Kai


Cheers,



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

Re: [Xen-devel] [PATCH 04/15] xen: mm: add ioremap_cache

[Huang, Kai]

On 7/12/2017 6:17 PM, Jan Beulich wrote:

Julien Grall  07/11/17 10:15 PM >>>

On 07/09/2017 09:10 AM, Kai Huang wrote:

Currently Xen only has non-cacheable version of ioremap. Although EPC is
reported as reserved memory in e820 but it can be mapped as cacheable. This
patch adds ioremap_cache (cacheable version of ioremap).

Signed-off-by: Kai Huang 
---
   xen/arch/x86/mm.c  | 15 +--
   xen/include/xen/vmap.h |  1 +


First of all, this is common code and the "REST" maintainers should have
been CCed for this include.

But xen/include/xen/vmap.h is common code and going to break ARM. We
already have an inline implementation of ioremap_nocache. You should
move the definition in x86 specific headers.


Indeed, plus the ARM implementation actually shows how this would better
be done: Have a function allowing more than just true/false to be passed in,
to eventually also allow having ioremap_wc() and alike as wrappers. As long
as it's x86-specific I'd then also suggest calling the new wrapper function
ioremap_wb() (as "cache" may also mean WT).


Hi Jan,

Thanks for comments. I'll do as you suggested.

Thanks,
-Kai


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 02/15] xen: vmx: detect ENCLS VMEXIT

[Huang, Kai]

On 7/13/2017 6:54 AM, Jan Beulich wrote:

Andrew Cooper  07/12/17 1:12 PM >>>

On 09/07/17 10:09, Kai Huang wrote:

If ENCLS VMEXIT is not present then we cannot support SGX virtualization.
This patch detects presence of ENCLS VMEXIT. A Xen boot boolean parameter
'sgx' is also added to manually enable/disable SGX.

Signed-off-by: Kai Huang 


At a minimum, you also need to modify calculate_hvm_max_policy() to hide
SGX if we don't have ENCLS intercept support.


Actually IMO this is not needed, as I added an __initcall(sgx_init) (see 
patch 0003), where I will call setup_clear_cpu_cap(X86_FEATURE_SGX) if 
for any reason boot_sgx_cpuidata (which contains common SGX cpuid info 
shared by all cores) doesn't have valid SGX info. if ENCLS VMEXIT is not 
present, then detect_sgx won't be called for any core so that 
X86_FEATURE_SGX will be cleared in boot_cpu_data. As init_guest_cpuid is 
called after all __initcalls are called, so if ENCLS VMEXIT is not 
present, or sgx is disabled via boot parameter, then even for 
host_policy, it won't have SGX.


Of course if we changed the implementation of __initcall(sgx_init), we 
probably need to explicitly clear SGX here. Anyway clearing SGX here 
doesn't have any harm, so I am completely fine to do it if you think it 
is necessary.




Additionally I think the command line option should default to off initially
and it needs an entry in the command line option doc.


Sure. I'll change default to 0 and change the doc as well.

Thanks,
-Kai


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

[Xen-devel] [linux-next test] 111726: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  7 reboot   fail REGR. vs. 111677
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 111677
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 111677
 test-armhf-armhf-examine  5 xen-install  fail REGR. vs. 111677
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 111677
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
111677

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 16 guest-localmigrate fail blocked in 111677
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail blocked in 
111677
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
111677
 test-amd64-amd64-xl-credit2  15 guest-saverestorefail  like 111677
 test-amd64-amd64-xl-xsm  16 guest-localmigrate   fail  like 111677
 test-amd64-amd64-libvirt-pair 21 guest-start/debian   fail like 111677
 test-amd64-i386-pair 21 guest-start/debian   fail  like 111677
 test-amd64-amd64-libvirt 16 guest-saverestore.2  fail  like 111677
 test-amd64-i386-libvirt  16 guest-saverestore.2  fail  like 111677
 test-amd64-i386-xl-xsm   16 guest-localmigrate   fail  like 111677
 test-amd64-i386-libvirt-pair 21 guest-start/debian   fail  like 111677
 test-amd64-amd64-xl-multivcpu 15 guest-saverestorefail like 111677
 test-amd64-amd64-xl  16 guest-localmigrate   fail  like 111677
 test-amd64-i386-xl   16 guest-localmigrate   fail  like 111677
 test-amd64-amd64-libvirt-xsm 16 guest-saverestore.2  fail  like 111677
 test-amd64-i386-libvirt-xsm  16 guest-saverestore.2  fail  like 111677
 test-amd64-amd64-xl-pvh-amd  16 guest-localmigrate   fail  like 111677
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111677
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111677
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111677
 test-amd64-amd64-libvirt 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-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-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-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-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
 

Re: [Xen-devel] [PATCH v13 16/23] x86: L2 CAT: implement CPU init flow.

[Yi Sun]

On 17-07-12 14:09:40, Jan Beulich wrote:
> >>> Yi Sun  07/06/17 4:07 AM >>>
> >This patch implements the CPU init flow for L2 CAT.
> >
> >Note: L2 CAT does NOT work until you apply the later patches of L2 CAT.
> >"x86: L2 CAT: implement get hw info flow."
> >"x86: L2 CAT: implement get value flow."
> >"x86: L2 CAT: implement set value flow."
> 
> Same comment as on the respective CDP one.
> 
Will change it.

> >@@ -269,6 +271,12 @@ static bool psr_check_cbm(unsigned int cbm_len, 
> >unsigned long cbm)
>  >}
>  >
>  >/* CAT common functions implementation. */
> >+static char *feat_name[FEAT_TYPE_NUM] = {
> 
> const char * const
> 
> Additionally - do you need or plan to use this in more than one function? If
> not, it should be made local to its only user. If so, the variable name should
> include "cat", as these appear to be CAT-specific feature names only.
> 
This should be moved into cat_init_feature() as a local array. Thanks!

> Jan

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

Re: [Xen-devel] [PATCH v13 13/23] x86: refactor psr: CDP: implement CPU init flow.

[Yi Sun]

On 17-07-12 13:52:35, Jan Beulich wrote:
> >>> Yi Sun  07/06/17 4:07 AM >>>
> >This patch implements the CPU init flow for CDP. The flow is almost
> >same as L3 CAT.
> >
> >Note: CDP does NOT work until you apply the later patches of CDP.
> >"x86: refactor psr: CDP: implement get hw info flow."
> >"x86: refactor psr: CDP: implement set value callback function."
> 
> This is _not_ what I did ask for in what I assume ...
> 
> >v13:
> >- add commit message.
> 
> ... this refers to: The problem isn't that it won't work, but that it'll 
> crash the
> hypervisor. So what I had expected you to add is a note _after_ the first
> --- separator that this patch should not be applied without the other two
> ones. Or alternatively for this one to add stubs which the subsequent
> patches would then fill.
> 
Oh, ok. I will move the comments under the first '---'. Furthermore, I'd like
to add a 'stub_write_msr()' here to avoid crash. Will replace the stub function
to real function when implementing the write flow.

> >@@ -262,6 +280,29 @@ static int cat_init_feature(const struct cpuid_leaf 
> >*regs,
>  >
>  >break;
>  >
> >+case FEAT_TYPE_L3_CDP:
> >+{
> >+uint64_t val;
> >+
> >+if ( feat->cos_max < 3 )
> >+return -ENOENT;
> 
> In the admittedly unlikely event that this return path gets taken (or any 
> other
> current or future one), ...
> 
> >@@ -1277,11 +1331,20 @@ static void psr_cpu_init(void)
>  >{
>  >cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 1, ®s);
>  >
> >-feat = feat_l3_cat;
> >-feat_l3_cat = NULL;
> >-
> >-if ( !cat_init_feature(®s, feat, info, FEAT_TYPE_L3_CAT) )
> >-feat_props[FEAT_TYPE_L3_CAT] = _cat_props;
> >+if ( (regs.c & PSR_CAT_CDP_CAPABILITY) && (opt_psr & PSR_CDP) )
> >+{
> >+feat = feat_l3_cdp;
> >+feat_l3_cdp = NULL;
> >+if ( !cat_init_feature(®s, feat, info, FEAT_TYPE_L3_CDP) )
> >+feat_props[FEAT_TYPE_L3_CDP] = _cdp_props;
> >+}
> >+else
> >+{
> >+feat = feat_l3_cat;
> >+feat_l3_cat = NULL;
> >+if ( !cat_init_feature(®s, feat, info, FEAT_TYPE_L3_CAT) )
> >+feat_props[FEAT_TYPE_L3_CAT] = _cat_props;
> >+}
> 
> ... wouldn't it be a good idea to then try to setup plain L3 CAT here?
> 
DYM if CDP init fails, enter CAT init flow to make CAT work at least?

> I also notice that (already in patch 4) you leak feat here in case
> cat_init_feature() fails. You should put it back into the static helper 
> variable
> you've taken it from. Furthermore, since you use at most one of feat_l3_cat
> and feat_l3_cdp, so I don't see why you need to allocate two of them.
> 
Ok, I will keep the helper variable if cat_init_feature() fails.

Will converge the 'feat_l3_cat' and 'feat_l3_cdp' to one.

> Jan

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

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-credit2

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-credit2
testid guest-saverestore

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  130568d5eac5537cbd64cfb12103550af90edb79
  Bug not present: a37484638ca5e0aa7c205ecb91c9ace92e83c32c
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/111753/


  (Revision log too long, omitted.)


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-credit2.guest-saverestore
 --summary-out=tmp/111753.bisection-summary --basis-template=110515 
--blessings=real,real-bisect linux-linus test-amd64-amd64-xl-credit2 
guest-saverestore
Searching for failure / basis pass:
 111714 fail [host=fiano1] / 111363 [host=pinot1] 111332 [host=rimava0] 111280 
[host=baroque1] 111222 [host=italia1] 83 [host=elbling0] 48 
[host=pinot0] 24 [host=italia0] 111081 [host=merlot1] 110984 
[host=huxelrebe1] 110950 [host=godello1] 110908 [host=elbling1] 110560 
[host=godello0] 110547 [host=baroque0] 110536 [host=huxelrebe0] 110515 
[host=fiano0] 110486 [host=pinot1] 110464 [host=chardonnay1] 110427 
[host=italia1] 110399 [host=merlot0] 110380 [host=baroque1] 110346 
[host=pinot0] 110288 [host=nobling0] 110236 [host=italia0] 110131 
[host=chardonnay0] 110093 [host=huxelrebe1] 110060 [host=elbling0] 110038 
[host=nobling1] 110025 [host=rimava1] 110016 [host=merlot1] 110006 
[host=godello0] 109994 [host=godello1] 109963 [host=rimava0] 109943 
[host=huxelrebe0] 109920 ok.
Failure / basis pass flights: 111714 / 109920
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 130568d5eac5537cbd64cfb12103550af90edb79 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
d23afa6399a78ca7d0ed3294119632535828c9d8
Basis pass a37484638ca5e0aa7c205ecb91c9ace92e83c32c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
876800d5f9de8b15355172794cb82f505dd26e18
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#a37484638ca5e0aa7c205ecb91c9ace92e83c32c-130568d5eac5537cbd64cfb12103550af90edb79
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7-414d069b38ab114b89085e44989bf57604ea86d7
 
git://xenbits.xen.org/xen.git#876800d5f9de8b15355172794cb82f505dd26e18-d23afa6399a78ca7d0ed3294119632535828c9d8
From 
git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
   235b84f..edaf382  master -> origin/master
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 2007 nodes in revision graph
Searching for test results:
 109758 [host=chardonnay1]
 109778 [host=pinot0]
 109832 [host=baroque0]
 109809 [host=merlot0]
 109801 [host=fiano0]
 109821 [host=baroque1]
 109839 [host=elbling1]
 109889 [host=pinot1]
 109858 [host=italia1]
 109920 pass a37484638ca5e0aa7c205ecb91c9ace92e83c32c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
876800d5f9de8b15355172794cb82f505dd26e18
 109943 [host=huxelrebe0]
 109994 [host=godello1]
 109963 [host=rimava0]
 110016 [host=merlot1]
 110006 [host=godello0]
 110038 [host=nobling1]
 110025 [host=rimava1]
 110060 [host=elbling0]
 110093 [host=huxelrebe1]
 110131 [host=chardonnay0]
 110236 [host=italia0]
 110346 [host=pinot0]
 110288 [host=nobling0]
 110380 [host=baroque1]
 110399 [host=merlot0]
 110427 [host=italia1]
 110464 [host=chardonnay1]
 110486 [host=pinot1]
 110515 [host=fiano0]
 110547 [host=baroque0]
 110536 [host=huxelrebe0]
 110560 [host=godello0]
 110908 [host=elbling1]
 110950 

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

[Lu Baolu]

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().

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

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

[Yi Sun]

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?

> >enum psr_feat_type feat_type)
> >{
> >-return -ENOENT;
> >+int ret;
> >+struct psr_socket_info *info = get_socket_info(socket);
> >+struct cos_write_info data =
> >+{
> >+.cos = cos,
> >+.feature = info->features[feat_type],
> >+.props = feat_props[feat_type],
> >+};
> >+
> >+if ( cos > info->features[feat_type]->cos_max )
> >+return -EINVAL;
> >+
> >+/* Skip to the feature's value head. */
> >+ret = skip_prior_features(, _len, feat_type);
> >+if ( ret )
> >+return ret;
> >+
> >+if ( array_len < feat_props[feat_type]->cos_num )
> >+return -ENOSPC;
> >+
> >+data.val = val;
> >+
> >+if ( socket == cpu_to_socket(smp_processor_id()) )
> >+do_write_psr_msrs();
> >+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, , 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.

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;
};

> 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 v9 7/7] tools/xen-mceinj: add support of injecting LMCE

[Haozhong Zhang]

On 07/12/17 09:26 -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 12, 2017 at 10:04:40AM +0800, Haozhong Zhang wrote:
> > If option '-l' or '--lmce' is specified and the host supports LMCE,
> > xen-mceinj will inject LMCE to CPU specified by '-c' (or CPU0 if '-c'
> > is not present).
> > 
> > Signed-off-by: Haozhong Zhang 
> > Acked-by: Wei Liu 
> > ---
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> > ---
> >  tools/tests/mce-test/tools/xen-mceinj.c | 50 
> > +++--
> >  1 file changed, 48 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
> > b/tools/tests/mce-test/tools/xen-mceinj.c
> > index bae5a46eb5..380e42190c 100644
> > --- a/tools/tests/mce-test/tools/xen-mceinj.c
> > +++ b/tools/tests/mce-test/tools/xen-mceinj.c
[..]
> >  
> > +static int inject_lmce(xc_interface *xc_handle, unsigned int cpu)
> > +{
> > +uint8_t *cpumap = NULL;
> > +size_t cpumap_size, line, shift;
> > +unsigned int nr_cpus;
> > +int ret;
> > +
> > +nr_cpus = mca_cpuinfo(xc_handle);
> > +if ( !nr_cpus )
> > +err(xc_handle, "Failed to get mca_cpuinfo");
> > +if ( cpu >= nr_cpus )
> > +err(xc_handle, "-c %u is larger than %u", cpu, nr_cpus - 1);
> > +
> > +cpumap_size = (nr_cpus + 7) / 8;
> 
> bitmap_size
>

IIUC, these bitmap_* functions/macros are libxc internals and should
not be used here.

Haozhong

___
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 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?


[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










___
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

[Lu Baolu]

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.

Best regards,
Lu Baolu

>> -boris
>>
>>
>>>
>>> Best regards,
>>> Lu Baolu
>>>
 -boris


> Cc: Ingo Molnar 
> Cc: x...@kernel.org
> Signed-off-by: Lu Baolu 
> ---
>  arch/x86/kernel/setup.c | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 4bf0c89..e70204e 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, 
> unsigned long v, void *p)
>  return 0;
>  }
>
> +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 it returns here,  can we use udelay() correctly like before?
>
> 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
>


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

[Xen-devel] [xen-unstable test] 111722: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail in 111693 pass in 111722
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail pass in 111693

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail in 111693 like 111664
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeatfail  like 111619
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 111645
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail like 111645
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111693
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111693
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 111693
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 111693
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111693
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111693
 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-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-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-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 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-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  89df98b77d28136c4d7aade13a1c8bc154d2919f
baseline version:
 xen  89df98b77d28136c4d7aade13a1c8bc154d2919f

Last test of basis   111722  2017-07-12 07:18:53 Z0 days
Testing same since  (not found) 0 attempts

Re: [Xen-devel] [PATCH v1 3/3] xen/livepatch/ARM32: Don't crash on livepatches loaded with wrong alignment.

[Jan Beulich]

>>> "Jan Beulich"  07/11/17 10:07 PM >>>
>What you may want to consider is silently padding sections to a multiple
>of their specified alignment.

I actually think now that it was a bad idea to suggest this, in particular in 
this
context. If you followed that road, you'd end up with a random alignment
dependency of on section on whatever the prior section's alignment happens
to be.

Jan


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

Re: [Xen-devel] Problem with commit bf22ff45bed664aefb5c4e43029057a199b7070c

[Thomas Gleixner]

On Wed, 12 Jul 2017, Thomas Gleixner wrote:
> On Mon, 10 Jul 2017, Juergen Gross wrote:
> > It is based on suspend/resume framework. The main work to be done
> > additionally is to disconnect from the pv-backends at save time and
> > connect to the pv-backends again at restore time.
> > 
> > The main function triggering all that is xen_suspend() (as seen in
> > above backtrace).
> 
> The untested patch below should give you hooks to do what you need to do.
> 
> Add the irq_suspend/resume callbacks and set the IRQCHIP_GENERIC_SUSPEND
> flag on your xen irqchip, so it actually gets invoked.
> 
> I have to make that opt in right now because the callbacks are used in the
> generic irqchip implementation already. We can revisit that when you can
> confirm that this is actually solving the problem.

There might be an even simpler solution.

As this is using the regular suspend_device_irqs() call, you just might get
away with setting IRQCHIP_MASK_ON_SUSPEND for your irq chip. That does not
use the lazy disable approach, it also masks all interrupts which are not
marked as wakeup irqs. I assume none of them is when you do that
save/restore dance.

That said, you still might make the whole mechanism cleaner by using the
irq chip callbacks so you can avoid traversing all the interrupts another
time. But I can't say for sure as I got lost in that xen event channel code.

Thanks,

tglx


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

Re: [Xen-devel] [PATCH v13 16/23] x86: L2 CAT: implement CPU init flow.

[Jan Beulich]

>>> Yi Sun  07/06/17 4:07 AM >>>
>This patch implements the CPU init flow for L2 CAT.
>
>Note: L2 CAT does NOT work until you apply the later patches of L2 CAT.
>"x86: L2 CAT: implement get hw info flow."
>"x86: L2 CAT: implement get value flow."
>"x86: L2 CAT: implement set value flow."

Same comment as on the respective CDP one.

>@@ -269,6 +271,12 @@ static bool psr_check_cbm(unsigned int cbm_len, unsigned 
>long cbm)
 >}
 >
 >/* CAT common functions implementation. */
>+static char *feat_name[FEAT_TYPE_NUM] = {

const char * const

Additionally - do you need or plan to use this in more than one function? If
not, it should be made local to its only user. If so, the variable name should
include "cat", as these appear to be CAT-specific feature names only.

Jan


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

Re: [Xen-devel] [PATCH v13 15/23] x86: refactor psr: CDP: implement set value callback function.

[Jan Beulich]

>>> Yi Sun  07/06/17 4:07 AM >>>
>--- a/xen/arch/x86/psr.c
>+++ b/xen/arch/x86/psr.c
>@@ -373,12 +373,21 @@ static bool l3_cdp_get_feat_info(const struct feat_node 
>*feat,
 >return true;
 >}
 >
>+static void l3_cdp_write_msr(unsigned int cos, uint32_t val, enum cbm_type 
>type)
>+{
>+wrmsrl(((type == PSR_CBM_TYPE_L3_DATA) ?
>+MSR_IA32_PSR_L3_MASK_DATA(cos) :
>+MSR_IA32_PSR_L3_MASK_CODE(cos)),
>+   val);
>+}
>+
 >static const struct feat_props l3_cdp_props = {
 >.cos_num = 2,
 >.type[0] = PSR_CBM_TYPE_L3_DATA,
 >.type[1] = PSR_CBM_TYPE_L3_CODE,
>-.alt_type = FEAT_TYPE_L3_CAT,
>+.alt_type = PSR_CBM_TYPE_L3,

I did wonder about the value set in the earlier patch, but if you change it here
this is a pretty clear sign that you really should set it to the intended value
right away. With this taken care of (or a good reason provided why it needs
to be the way it is)
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v13 13/23] x86: refactor psr: CDP: implement CPU init flow.

[Jan Beulich]

>>> Yi Sun  07/06/17 4:07 AM >>>
>This patch implements the CPU init flow for CDP. The flow is almost
>same as L3 CAT.
>
>Note: CDP does NOT work until you apply the later patches of CDP.
>"x86: refactor psr: CDP: implement get hw info flow."
>"x86: refactor psr: CDP: implement set value callback function."

This is _not_ what I did ask for in what I assume ...

>v13:
>- add commit message.

... this refers to: The problem isn't that it won't work, but that it'll crash 
the
hypervisor. So what I had expected you to add is a note _after_ the first
--- separator that this patch should not be applied without the other two
ones. Or alternatively for this one to add stubs which the subsequent
patches would then fill.

>@@ -262,6 +280,29 @@ static int cat_init_feature(const struct cpuid_leaf *regs,
 >
 >break;
 >
>+case FEAT_TYPE_L3_CDP:
>+{
>+uint64_t val;
>+
>+if ( feat->cos_max < 3 )
>+return -ENOENT;

In the admittedly unlikely event that this return path gets taken (or any other
current or future one), ...

>@@ -1277,11 +1331,20 @@ static void psr_cpu_init(void)
 >{
 >cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 1, ®s);
 >
>-feat = feat_l3_cat;
>-feat_l3_cat = NULL;
>-
>-if ( !cat_init_feature(®s, feat, info, FEAT_TYPE_L3_CAT) )
>-feat_props[FEAT_TYPE_L3_CAT] = _cat_props;
>+if ( (regs.c & PSR_CAT_CDP_CAPABILITY) && (opt_psr & PSR_CDP) )
>+{
>+feat = feat_l3_cdp;
>+feat_l3_cdp = NULL;
>+if ( !cat_init_feature(®s, feat, info, FEAT_TYPE_L3_CDP) )
>+feat_props[FEAT_TYPE_L3_CDP] = _cdp_props;
>+}
>+else
>+{
>+feat = feat_l3_cat;
>+feat_l3_cat = NULL;
>+if ( !cat_init_feature(®s, feat, info, FEAT_TYPE_L3_CAT) )
>+feat_props[FEAT_TYPE_L3_CAT] = _cat_props;
>+}

... wouldn't it be a good idea to then try to setup plain L3 CAT here?

I also notice that (already in patch 4) you leak feat here in case
cat_init_feature() fails. You should put it back into the static helper variable
you've taken it from. Furthermore, since you use at most one of feat_l3_cat
and feat_l3_cdp, so I don't see why you need to allocate two of them.

Jan


___
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/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.

>enum psr_feat_type feat_type)
>{
>-return -ENOENT;
>+int ret;
>+struct psr_socket_info *info = get_socket_info(socket);
>+struct cos_write_info data =
>+{
>+.cos = cos,
>+.feature = info->features[feat_type],
>+.props = feat_props[feat_type],
>+};
>+
>+if ( cos > info->features[feat_type]->cos_max )
>+return -EINVAL;
>+
>+/* Skip to the feature's value head. */
>+ret = skip_prior_features(, _len, feat_type);
>+if ( ret )
>+return ret;
>+
>+if ( array_len < feat_props[feat_type]->cos_num )
>+return -ENOSPC;
>+
>+data.val = val;
>+
>+if ( socket == cpu_to_socket(smp_processor_id()) )
>+do_write_psr_msrs();
>+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, , 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.

Jan


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

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

[osstest service owner]

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

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 111724
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 111706 pass in 
111724
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 111706 
pass in 111724
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail in 111706 pass in 
111724
 test-amd64-amd64-xl-rtds 10 debian-install fail pass in 111523
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail pass in 111523
 test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail pass in 
111706
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 18 guest-start/debianhvm.repeat 
fail pass in 111706
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 111706

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-qemuu-win7-amd64 17 guest-stop   fail blocked in 110441
 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-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-amd64-xl-qemut-ws16-amd64 10 windows-installfail 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-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
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   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-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
 

Re: [Xen-devel] [PATCH v13 09/23] x86: refactor psr: L3 CAT: set value: assemble features value array.

[Jan Beulich]

>>> Yi Sun  07/06/17 4:07 AM >>>
>Only can one COS ID be used by one domain at one time. That means all enabled
>features' COS registers at this COS ID are valid for this domain at that time.
>
>When user updates a feature's value, we need make sure all other features'
>values are not affected. So, we firstly need gather an array which contains
>all features current values and replace the setting feature's value in array
>to new value.
>
>Then, we can try to find if there is a COS ID on which all features' COS
>registers values are same as the array. If we can find, we just use this COS
>ID. If fail to find, we need pick a new COS ID.
>
>This patch implements value array assembling flow.
>
>Signed-off-by: Yi Sun 
>Reviewed-by: Jan Beulich 

This was perhaps premature because of ...

>v13:
>- remove an unnecessary blank line.
  >(suggested by Jan Beulich)
>- add a new function 'skip_prior_features()' to skip value array according
  >to feature type. This function will be used in later patches too.

... this.

>+static int skip_prior_features(uint32_t **val,
>+   unsigned int *array_len,
>+   enum psr_feat_type feat_type)
>+{
>+unsigned int i;
>+
>+for ( i = 0; i < feat_type; i++ )
>+{
>+const struct feat_props * props = feat_props[i];

Stray blank after *. Other than that you can retain the R-b, and the cosmetic
issue here could be taken care of while committing if no other need arises for
sending another version.

Jan


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

Re: [Xen-devel] [PATCH v13 08/23] x86: refactor psr: L3 CAT: set value: implement framework.

[Jan Beulich]

>>> Yi Sun  07/06/17 4:08 AM >>>
>As set value flow is the most complicated one in psr, it will be
>divided to some patches to make things clearer. This patch
>implements the set value framework to show a whole picture firstly.
>
>It also changes domctl interface to make it more general.
>
>To make the set value flow be general and can support multiple features
>at same time, it includes below steps:
>1. Test and set dom_ids bit corresponding to the domain. If the old bit is 0
   >which means the domain's COS ID is invalid, restore COS ID to 0. If the
   >COS ID is valid, get the COS ID that current domain is using.
>2. Gather a value array to store all features current value
   >into it and replace the current value of the feature which is
   >being set to the new input value.
>3. Find if there is already a COS ID on which all features'
   >values are same as the array. Then, we can reuse this COS
   >ID.
>4. If fail to find, we need pick an available COS ID. Only COS ID which ref
   >is 0 or 1 can be picked.
>5. Write the feature's MSRs according to the COS ID.
>6. Update ref according to COS ID.
>7. Save the COS ID into current domain's psr_cos_ids[socket] so that we
   >can know which COS the domain is using on the socket.
>
>So, some functions are abstracted and the callback functions will be
>implemented in next patches.
>
>Here is an example to understand the process. The CPU supports
>two featuers, e.g. L3 CAT and L2 CAT. User wants to set L3 CAT
>of Dom1 to 0x1ff.
>1. At the initial time, the old_cos of Dom1 is 0. The COS registers values
>are below at this time.
>---
>| COS 0 | COS 1 | COS 2 | ... |
>---
>L3 CAT  | 0x7ff | 0x7ff | 0x7ff | ... |
>---
>L2 CAT  | 0xff  | 0xff  | 0xff  | ... |
>---
>
>2. Gather the value array and insert new value into it:
>val[0]: 0x1ff
>val[1]: 0xff
>
>3. It cannot find a matching COS.
>
>4. Pick COS 1 to store the value set.
>
>5. Write the L3 CAT COS 1 registers. The COS registers values are
>changed to below now.
>---
>| COS 0 | COS 1 | COS 2 | ... |
>---
>L3 CAT  | 0x7ff | 0x1ff | ...   | ... |
>---
>L2 CAT  | 0xff  | 0xff  | ...   | ... |
>---
>
>6. The ref[1] is increased to 1 because Dom1 is using it now.
>
>7. Save 1 to Dom1's psr_cos_ids[socket].
>
>Then, user wants to set L3 CAT of Dom2 to 0x1ff too. The old_cos
>of Dom2 is 0 too. Repeat above flow.
>
>The val array assembled is:
>val[0]: 0x1ff
>val[1]: 0xff
>
>So, it can find a matching COS, COS 1. Then, it can reuse COS 1
>for Dom2.
>
>The ref[1] is increased to 2 now because both Dom1 and Dom2 are
>using this COS ID. Set 1 to Dom2's psr_cos_ids[socket].
>
>There is one thing need to emphasize that we need restore domain's COS ID to
>0 when socket is offline. Otherwise, a wrong COS ID will be used when the
>socket is online again. That may cause user see the wrong CBM shown. But it
>takes much time to iterate all domains to restore COS ID to 0. So, we define
>a 'dom_ids[]' to represents all domains, one bit corresponds to one domain.
>If the bit is 0 when entering 'psr_ctxt_switch_to', that means this is the
>first time the domain is switched to this socket or domain's COS ID has not
>been set since the socket is online. So, the COS ID set to ASSOC register on
>this socket should be default value, 0. If not, that means the domain's COS
>ID has been set when the socket was online. So, this COS ID is valid and we
>can directly use it. We restore the domain's COS ID to 0 if the bit
>corresponding to the domain is 0 but the domain's COS ID is not 0 when
>'psr_get_val' and 'psr_set_val' is called. This can avoid CPU serialization
>if restoring action is exectued in 'psr_ctxt_switch_to'.
>
>Signed-off-by: Yi Sun 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 02/15] xen: vmx: detect ENCLS VMEXIT

[Jan Beulich]

>>> Andrew Cooper  07/12/17 1:12 PM >>>
>On 09/07/17 10:09, Kai Huang wrote:
>> If ENCLS VMEXIT is not present then we cannot support SGX virtualization.
>> This patch detects presence of ENCLS VMEXIT. A Xen boot boolean parameter
>> 'sgx' is also added to manually enable/disable SGX.
>>
>> Signed-off-by: Kai Huang 
>
>At a minimum, you also need to modify calculate_hvm_max_policy() to hide 
>SGX if we don't have ENCLS intercept support.

Additionally I think the command line option should default to off initially
and it needs an entry in the command line option doc.

Jan


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

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

[Tamas K Lengyel]

On Wed, Jul 12, 2017 at 11:21 AM, Petre Pircalabu
 wrote:
> If case of a vm_event with the emulate_flags set, if the instruction
> cannot be emulated, the monitor should be notified instead of directly
> injecting a hw exception.
> This behavior can be used to re-execute an instruction not supported by
> the emulator using the real processor (e.g. altp2m) instead of just
> crashing.
>
> Signed-off-by: Petre Pircalabu 
>
> ---
> Changed since v1:
>   * Removed the emulation kind check when calling hvm_inject_hw_exception
>
> Changed since v2:
>   * Removed a file added by mistake
>
> Changed since v3:
>   * Removed extra stray line
>   * Added the _enabled suffix to the emul_unhandleable monitor option
> ---
>  tools/libxc/include/xenctrl.h |  2 ++
>  tools/libxc/xc_monitor.c  | 14 ++
>  xen/arch/x86/hvm/emulate.c|  5 -
>  xen/arch/x86/hvm/monitor.c| 18 ++
>  xen/arch/x86/monitor.c| 12 
>  xen/include/asm-x86/domain.h  |  1 +
>  xen/include/asm-x86/hvm/monitor.h |  1 +
>  xen/include/asm-x86/monitor.h |  3 ++-
>  xen/include/public/domctl.h   |  1 +
>  xen/include/public/vm_event.h |  2 ++
>  10 files changed, 57 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index c51bb3b..8deb5ac 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2029,6 +2029,8 @@ int xc_monitor_debug_exceptions(xc_interface *xch, 
> domid_t domain_id,
>  int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
>  int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
> bool enable);
> +int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
> + bool enable);
>  /**
>   * This function enables / disables emulation for each REP for a
>   * REP-compatible instruction.
> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
> index b44ce93..8e72c6c 100644
> --- a/tools/libxc/xc_monitor.c
> +++ b/tools/libxc/xc_monitor.c
> @@ -216,6 +216,20 @@ int xc_monitor_privileged_call(xc_interface *xch, 
> domid_t domain_id,
>  return do_domctl(xch, );
>  }
>
> +int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
> + bool enable)
> +{
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_monitor_op;
> +domctl.domain = domain_id;
> +domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
> +: XEN_DOMCTL_MONITOR_OP_DISABLE;
> +domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE;
> +
> +return do_domctl(xch, );
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index e97aa69..f52aa87 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -14,12 +14,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2101,7 +2103,8 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
> unsigned int trapnr,
>  return;
>  case X86EMUL_UNHANDLEABLE:
>  hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", );
> -hvm_inject_hw_exception(trapnr, errcode);
> +if ( !hvm_monitor_emul_unhandleable() )
> +hvm_inject_hw_exception(trapnr, errcode);
>  break;
>  case X86EMUL_EXCEPTION:
>  hvm_inject_event();
> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> index a7ccfc4..977a96b 100644
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -57,6 +57,24 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
> value, unsigned long old
>  return 0;
>  }
>
> +bool hvm_monitor_emul_unhandleable(void)
> +{
> +struct vcpu *curr = current;
> +struct domain *d = curr->domain;
> +
> +/*
> + * Send a vm_event to the monitor to signal that the current
> + * instruction couldn't be emulated.
> + */
> +vm_event_request_t req = {
> +.reason = VM_EVENT_REASON_EMUL_UNHANDLEABLE,
> +.vcpu_id  = curr->vcpu_id,
> +};
> +
> +return ( d->arch.monitor.emul_unhandleable_enabled &&
> + monitor_traps(curr, true, ) );

So what happens if monitor_traps fails and returns -1? Since this gets
treated as a boolean, we will return true here and just silently
swallow the problem and likely make the VM hang in a loop. I think it
would be appropriate to crash the vm here if we can't emulate and also
can't notify the listener.

> +}
> +
>  void hvm_monitor_msr(unsigned int msr, uint64_t value)
>  {
>  struct vcpu *curr = current;
> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c

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

[Razvan Cojocaru]

On 07/12/2017 08:21 PM, Petre Pircalabu wrote:
> If case of a vm_event with the emulate_flags set, if the instruction
> cannot be emulated, the monitor should be notified instead of directly
> injecting a hw exception.
> This behavior can be used to re-execute an instruction not supported by
> the emulator using the real processor (e.g. altp2m) instead of just
> crashing.
> 
> Signed-off-by: Petre Pircalabu 
> 
> ---
> Changed since v1:
>   * Removed the emulation kind check when calling hvm_inject_hw_exception
> 
> Changed since v2:
>   * Removed a file added by mistake
> 
> Changed since v3:
>   * Removed extra stray line
>   * Added the _enabled suffix to the emul_unhandleable monitor option

I think for these mechanical-only changes you could have kept Wei's ack.


Thanks,
Razvan

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

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

[Petre Pircalabu]

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

Signed-off-by: Petre Pircalabu 

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

Changed since v2:
  * Removed a file added by mistake

Changed since v3:
  * Removed extra stray line
  * Added the _enabled suffix to the emul_unhandleable monitor option
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_monitor.c  | 14 ++
 xen/arch/x86/hvm/emulate.c|  5 -
 xen/arch/x86/hvm/monitor.c| 18 ++
 xen/arch/x86/monitor.c| 12 
 xen/include/asm-x86/domain.h  |  1 +
 xen/include/asm-x86/hvm/monitor.h |  1 +
 xen/include/asm-x86/monitor.h |  3 ++-
 xen/include/public/domctl.h   |  1 +
 xen/include/public/vm_event.h |  2 ++
 10 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c51bb3b..8deb5ac 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2029,6 +2029,8 @@ int xc_monitor_debug_exceptions(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
 int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
bool enable);
+int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
+ bool enable);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b44ce93..8e72c6c 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -216,6 +216,20 @@ int xc_monitor_privileged_call(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, );
 }
 
+int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
+ bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE;
+
+return do_domctl(xch, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index e97aa69..f52aa87 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -14,12 +14,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2101,7 +2103,8 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
 return;
 case X86EMUL_UNHANDLEABLE:
 hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", );
-hvm_inject_hw_exception(trapnr, errcode);
+if ( !hvm_monitor_emul_unhandleable() )
+hvm_inject_hw_exception(trapnr, errcode);
 break;
 case X86EMUL_EXCEPTION:
 hvm_inject_event();
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index a7ccfc4..977a96b 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -57,6 +57,24 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
value, unsigned long old
 return 0;
 }
 
+bool hvm_monitor_emul_unhandleable(void)
+{
+struct vcpu *curr = current;
+struct domain *d = curr->domain;
+
+/*
+ * Send a vm_event to the monitor to signal that the current
+ * instruction couldn't be emulated.
+ */
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_EMUL_UNHANDLEABLE,
+.vcpu_id  = curr->vcpu_id,
+};
+
+return ( d->arch.monitor.emul_unhandleable_enabled &&
+ monitor_traps(curr, true, ) );
+}
+
 void hvm_monitor_msr(unsigned int msr, uint64_t value)
 {
 struct vcpu *curr = current;
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 706454f..f791372 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -283,6 +283,18 @@ int arch_monitor_domctl_event(struct domain *d,
 break;
 }
 
+case XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE:
+{
+bool old_status = ad->monitor.emul_unhandleable_enabled;
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;
+
+domain_pause(d);
+ad->monitor.emul_unhandleable_enabled = requested_status;
+domain_unpause(d);
+break;
+}
+
 default:
 /*
  * Should not be reached unless arch_monitor_get_capabilities() is
diff 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111662
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111662
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111662
 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  fde654be5307a570b7b0f31537e18e70a274cd50
baseline version:
 libvirt  405c0f07f5c444c52bd6cc95476753c7c8b2ffe2

Last test of basis   111662  2017-07-11 04:25:02 Z1 days
Testing same since   111718  2017-07-12 04:21:05 Z0 days1 attempts


People who touched revisions under test:
  Cédric Bosdonnat 
  Daniel P. Berrange 
  John Ferlan 
  Ján Tomko 
  Michal Privoznik 
  Peter Krempa 

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

Re: [Xen-devel] [PATCH v3 04/11] libxl: add generic function to add device

[Oleksandr Grytsov]

On Tue, Jul 4, 2017 at 12:41 PM, Oleksandr Grytsov  wrote:
>>> >> > > I don't see exiting device ported to the new framework, why?
>>> >> >
>>> >> > Good question. I think it is a little dangerous and may introduce 
>>> >> > regression.
>>> >> > But definitely it should be done. I can do these changes but I don't 
>>> >> > have
>>> >> > visibility how to check each device.
>>> >>
>>> >> Please just do it. We have a lot of time during development and RC
>>> >> period for people to test your changes.
>>> >
>>> > And I forget to say, please use one patch for one device type.
>>>
>>> Should it be in this patch set or better to create new one for each device?
>>>
>>
>> Those patches should be in this series.  One for each device for ease of
>> review please, and arrange it a way such that I can partially apply this
>> series.
>
> Ok. I will wait for your feedback about this series and will prepare v4 with
> fixes and changes for other devices.
>
> Thanks.

Hi Wei,

I've prepared new patch set. It is on my github [1].
I would appreciate if you review it before I send it.

The main changes are:
* libxl__device_add renamed to libxl__device_add_async and reworked
  to match the former design;
* libxl__device_add used for devices which don't require updating domain
  config but simple write to Xen Store (9pfs, vkb, vfb);
* following devices are changed to use the libxl__device_add:
  9pfs, vkb, vfb, nic, vtpm. Other device (console, pci, usb, disk) have
  very different adding pattern and require to unreasonable extend
  libxl__device_add_async and its parameters;
* disk device list changed to use libxl__device_list;
* small previous comments are applied.

[1] https://github.com/al1img/xen/tree/xl-vdispl-v4

-- 
Best Regards,
Oleksandr Grytsov.

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

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

[Tamas K Lengyel]

On Wed, Jul 12, 2017 at 2:43 AM, Petre Pircalabu
 wrote:
> If case of a vm_event with the emulate_flags set, if the instruction
> cannot be emulated, the monitor should be notified instead of directly
> injecting a hw exception.
> This behavior can be used to re-execute an instruction not supported by
> the emulator using the real processor (e.g. altp2m) instead of just
> crashing.
>
> Signed-off-by: Petre Pircalabu 
>
> ---
> Changed since v1:
>   * Removed the emulation kind check when calling hvm_inject_hw_exception
>
> Changed since v2:
>   * Removed a file added by mistake
> ---
>  tools/libxc/include/xenctrl.h |  2 ++
>  tools/libxc/xc_monitor.c  | 14 ++
>  xen/arch/x86/hvm/emulate.c|  5 -
>  xen/arch/x86/hvm/monitor.c| 19 +++
>  xen/arch/x86/monitor.c| 12 
>  xen/include/asm-x86/domain.h  |  1 +
>  xen/include/asm-x86/hvm/monitor.h |  1 +
>  xen/include/asm-x86/monitor.h |  3 ++-
>  xen/include/public/domctl.h   |  1 +
>  xen/include/public/vm_event.h |  2 ++
>  10 files changed, 58 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index c51bb3b..8deb5ac 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2029,6 +2029,8 @@ int xc_monitor_debug_exceptions(xc_interface *xch, 
> domid_t domain_id,
>  int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
>  int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
> bool enable);
> +int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
> + bool enable);
>  /**
>   * This function enables / disables emulation for each REP for a
>   * REP-compatible instruction.
> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
> index b44ce93..8e72c6c 100644
> --- a/tools/libxc/xc_monitor.c
> +++ b/tools/libxc/xc_monitor.c
> @@ -216,6 +216,20 @@ int xc_monitor_privileged_call(xc_interface *xch, 
> domid_t domain_id,
>  return do_domctl(xch, );
>  }
>
> +int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
> + bool enable)
> +{
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_monitor_op;
> +domctl.domain = domain_id;
> +domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
> +: XEN_DOMCTL_MONITOR_OP_DISABLE;
> +domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE;
> +
> +return do_domctl(xch, );
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index e97aa69..f52aa87 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -14,12 +14,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2101,7 +2103,8 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
> unsigned int trapnr,
>  return;
>  case X86EMUL_UNHANDLEABLE:
>  hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", );
> -hvm_inject_hw_exception(trapnr, errcode);
> +if ( !hvm_monitor_emul_unhandleable() )
> +hvm_inject_hw_exception(trapnr, errcode);
>  break;
>  case X86EMUL_EXCEPTION:
>  hvm_inject_event();
> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> index a7ccfc4..02e0ba5 100644
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -57,6 +57,25 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
> value, unsigned long old
>  return 0;
>  }
>
> +

Stray extra line here.

> +bool hvm_monitor_emul_unhandleable(void)
> +{
> +struct vcpu *curr = current;
> +struct domain *d = curr->domain;
> +
> +/*
> + * Send a vm_event to the monitor to signal that the current
> + * instruction couldn't be emulated.
> + */
> +vm_event_request_t req = {
> +.reason = VM_EVENT_REASON_EMUL_UNHANDLEABLE,
> +.vcpu_id  = curr->vcpu_id,
> +};
> +
> +return ( d->arch.monitor.emul_unhandleable &&
> + monitor_traps(curr, true, ) );
> +}
> +
>  void hvm_monitor_msr(unsigned int msr, uint64_t value)
>  {
>  struct vcpu *curr = current;
> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> index 706454f..51252fe 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -283,6 +283,18 @@ int arch_monitor_domctl_event(struct domain *d,
>  break;
>  }
>
> +case XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE:
> +{
> +bool old_status = ad->monitor.emul_unhandleable;
> +if ( unlikely(old_status == requested_status) )
> +return -EEXIST;
> 

Re: [Xen-devel] Problem with commit bf22ff45bed664aefb5c4e43029057a199b7070c

[Thomas Gleixner]

On Mon, 10 Jul 2017, Juergen Gross wrote:
> On 07/07/17 19:11, Thomas Gleixner wrote:
> > On Fri, 7 Jul 2017, Thomas Gleixner wrote:
> > 
> >> On Fri, 7 Jul 2017, Juergen Gross wrote:
> >>
> >>> Commit bf22ff45bed664aefb5c4e43029057a199b7070c ("genirq: Avoid
> >>> unnecessary low level irq function calls") breaks Xen guest
> >>> save/restore handling.
> >>>
> >>> The main problem are the PV devices using Xen event channels as
> >>> interrupt sources which are represented as an "irq chip" in the kernel.
> >>> When saving the guest the event channels are masked internally. At
> >>> restore time event channels are re-established and unmasked via
> >>> irq_startup().
> > 
> > And how exactly gets irq_startup() invoked on those event channels?
> 
> [   30.791879] Call Trace:
> [   30.791883]  ? irq_get_irq_data+0xe/0x20
> [   30.791886]  enable_dynirq+0x23/0x30
> [   30.791888]  unmask_irq.part.33+0x26/0x40
> [   30.791890]  irq_enable+0x65/0x70
> [   30.791891]  irq_startup+0x3c/0x110
> [   30.791893]  __enable_irq+0x37/0x60
> [   30.791895]  resume_irqs+0xbe/0xe0
> [   30.791897]  irq_pm_syscore_resume+0x13/0x20
> [   30.791900]  syscore_resume+0x50/0x1b0
> [   30.791902]  xen_suspend+0x76/0x140
> 
> > 
> >>> I have a patch repairing the issue, but I'm not sure if this way to do
> >>> it would be accepted. I have exported mask_irq() and I'm doing the
> >>> masking now through this function. Would the attached patch be
> >>> acceptable? Or is there a better way to solve the problem?
> >>
> >> Without looking at the patch (too lazy to fiddle with attachments right
> >> now), this is definitely wrong. I'll have a look later tonight.
> > 
> > Not that I'm surprised, but that patch is exactly what I expected. Export a
> > random function, which helps to paper over the real problem and run away.
> > These functions are internal for a reason and we worked hard on making
> > people understand that fiddling with the internals of interrupts is a
> > NONO. If there are special requirements for a good reason, then we create
> > proper interfaces and infrastructure, if there is no good reason, then the
> > problematic code needs to be fixed. There is no exception for XEN.
> 
> I'm absolutely on your side here. That was the reason I didn't send
> the patch right away, but asked how to solve my issue in a way which
> isn't "quick and dirty". The patch was just the easiest way to explain
> what should be the result of the proper solution.

Fair enough!

> > Can you please explain how that save/restore stuff works and which
> > functions are involved?
> 
> It is based on suspend/resume framework. The main work to be done
> additionally is to disconnect from the pv-backends at save time and
> connect to the pv-backends again at restore time.
> 
> The main function triggering all that is xen_suspend() (as seen in
> above backtrace).

The untested patch below should give you hooks to do what you need to do.

Add the irq_suspend/resume callbacks and set the IRQCHIP_GENERIC_SUSPEND
flag on your xen irqchip, so it actually gets invoked.

I have to make that opt in right now because the callbacks are used in the
generic irqchip implementation already. We can revisit that when you can
confirm that this is actually solving the problem.

Thanks,

tglx

8<--
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -476,6 +476,8 @@ struct irq_chip {
  * IRQCHIP_SKIP_SET_WAKE:  Skip chip.irq_set_wake(), for this irq chip
  * IRQCHIP_ONESHOT_SAFE:   One shot does not require mask/unmask
  * IRQCHIP_EOI_THREADED:   Chip requires eoi() on unmask in threaded mode
+ * IRQCHIP_GENERIC_SUSPEND:Use the suspend/resume callbacks in
+ * device_irq_suspend/resume
  */
 enum {
IRQCHIP_SET_TYPE_MASKED = (1 <<  0),
@@ -485,6 +487,7 @@ enum {
IRQCHIP_SKIP_SET_WAKE   = (1 <<  4),
IRQCHIP_ONESHOT_SAFE= (1 <<  5),
IRQCHIP_EOI_THREADED= (1 <<  6),
+   IRQCHIP_GENERIC_SUSPEND = (1 <<  7),
 };
 
 #include 
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -70,6 +70,8 @@ void irq_pm_remove_action(struct irq_des
 
 static bool suspend_device_irq(struct irq_desc *desc)
 {
+   struct irq_chip *chip;
+
if (!desc->action || irq_desc_is_chained(desc) ||
desc->no_suspend_depth)
return false;
@@ -94,8 +96,13 @@ static bool suspend_device_irq(struct ir
 * chip level. The chip implementation indicates that with
 * IRQCHIP_MASK_ON_SUSPEND.
 */
-   if (irq_desc_get_chip(desc)->flags & IRQCHIP_MASK_ON_SUSPEND)
+   chip = irq_desc_get_chip(desc);
+   if (chip->flags & IRQCHIP_MASK_ON_SUSPEND)
mask_irq(desc);
+
+   if ((chip->flags & IRQCHIP_GENERIC_SUSPEND) && chip->irq_suspend)
+   chip->irq_suspend(>irq_data);
+
return true;
 }
 
@@ -138,6 +145,8 @@ EXPORT_SYMBOL_GPL(suspend_device_irqs);
 
 static void 

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

[osstest service owner]

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

Regressions :-(

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

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

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
---
 ts-openstack-tempest | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ts-openstack-tempest b/ts-openstack-tempest
index ae3662f..f6b655f 100755
--- a/ts-openstack-tempest
+++ b/ts-openstack-tempest
@@ -53,10 +53,10 @@ sub tempest() {
 my $regex = "(?!.*\\[.*\\bslow\\b.*\\]|$ignored_tests)".
 "(^tempest\\.(api|scenario|thirdparty))";
 
-target_cmd($ho, <

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

[Anthony PERARD]

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.

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.

Signed-off-by: Anthony PERARD 
---
 Osstest/TestSupport.pm | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 7215156..f3174d2 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -55,6 +55,7 @@ BEGIN {
 
   target_cmd_root_status target_cmd_output_root_status
   target_cmd_root target_cmd target_cmd_build
+  target_cmd_subunit
   target_cmd_output_root target_cmd_output
   target_cmd_inputfh_root sshuho
   target_getfile target_getfile_root
@@ -737,6 +738,48 @@ sub target_cmd_root ($$;$$) { tcmd(undef,undef,0, 
'root',@_); }
 # Instead, returns the wait status (ie, what came in $?)
 sub target_cmd_root_status ($$;$$) { tcmd(undef,undef,1, 'root',@_); }
 
+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";
+}
+sub subunit_sanitize ($) {
+my ($testname) = @_;
+$testname =~ s/ /_/g;
+return $testname;
+}
+
+sub target_cmd_subunit ($$;$$) {
+my $stdout = IO::File::new_tmpfile();
+my $rc = tcmd(undef,$stdout,0, 'osstest', @_);
+$stdout->seek(0,0) or die "$stdout $!";
+my $logfilename = undef;
+my $fh = undef;
+
+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)?)?$/) {
+if ($4) {
+my $test_output = "";
+while (<$stdout>) {
+last if (/^\]$/);
+$test_output .= $_;
+}
+print $fh $test_output or die $!;
+}
+close $fh or die $!;
+substep_finish(subunit_sanitize($3), 
subunit_result_to_osstest_result($1));
+}
+}
+}
+
 sub tcmdout {
 my $stdout= IO::File::new_tmpfile();
 my $badstatusok = $_[1];
-- 
Anthony PERARD


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

[Xen-devel] [OSSTEST PATCH v12 20/21] Create a flight to test OpenStack with xen-unstable and libvirt

[Anthony PERARD]

This patch creates a flight "openstack-ocata", with those jobs:
  build-amd64
  build-amd64-libvirt
  build-amd64-pvops
  build-amd64-xsm
  build-arm64
  build-arm64-libvirt
  build-arm64-pvops
  build-arm64-xsm
  build-armhf
  build-armhf-libvirt
  build-armhf-pvops
  build-armhf-xsm
  test-amd64-amd64-devstack
  test-amd64-amd64-devstack-xsm
  test-arm64-arm64-devstack
  test-arm64-arm64-devstack-xsm
  test-armhf-armhf-devstack
  test-armhf-armhf-devstack-xsm

This would be a flight to test a stable release of OpenStack against
Xen.

OpenStack have many different repo which should be in sync, so we should
attempd to grab the revisions of the stable branch of every OpenStack
tree, for now, the runvars REVISION_* of tree other than nova is set to
"origin/stable/ocata", except Tempest does not have stable branch and
should be able to test any OpenStack version.

Signed-off-by: Anthony PERARD 
---
 ap-common| 19 +++
 ap-fetch-version |  6 ++
 ap-fetch-version-old |  7 +++
 ap-print-url |  3 +++
 ap-push  |  7 +++
 cr-daily-branch  | 31 +++
 cr-for-branches  |  2 +-
 cri-common   |  1 +
 make-flight  | 46 +-
 9 files changed, 120 insertions(+), 2 deletions(-)

diff --git a/ap-common b/ap-common
index cbb815c..adfdc11 100644
--- a/ap-common
+++ b/ap-common
@@ -54,6 +54,24 @@
 : ${PUSH_TREE_OVMF:=$XENBITS:/home/xen/git/osstest/ovmf.git}
 : ${BASE_TREE_OVMF:=git://xenbits.xen.org/osstest/ovmf.git}
 
+define_openstack_trees() {
+local openstack_trees=(cinder glance keystone neutron nova requirements
+tempest)
+local tree
+local url
+
+: ${GIT_OPENSTACK_ORG:=git://git.openstack.org}
+: ${TREE_OPENSTACK_DEVSTACK:=$GIT_OPENSTACK_ORG/openstack-dev/devstack.git}
+for tree in "${openstack_trees[@]}"; do
+url=$GIT_OPENSTACK_ORG/openstack/$tree.git
+eval ": \${TREE_OPENSTACK_${tree^^}:=$url}"
+done
+}
+
+define_openstack_trees
+: 
${PUSH_TREE_OPENSTACK_NOVA:=$XENBITS:/home/xen/git/osstest/openstack-nova.git}
+: ${BASE_TREE_OPENSTACK_NOVA:=git://xenbits.xen.org/osstest/openstack-nova.git}
+
 : ${TREE_LINUXFIRMWARE:=git://xenbits.xen.org/osstest/linux-firmware.git}
 : ${PUSH_TREE_LINUXFIRMWARE:=$XENBITS:/home/osstest/ext/linux-firmware.git}
 : 
${UPSTREAM_TREE_LINUXFIRMWARE:=$GIT_KERNEL_ORG/pub/scm/linux/kernel/git/firmware/linux-firmware.git}
@@ -82,6 +100,7 @@ fi
 : ${LOCALREV_SEABIOS:=daily-cron.$branch}
 : ${LOCALREV_OVMF:=daily-cron.$branch}
 : ${LOCALREV_XTF:=daily-cron.$branch}
+: ${LOCALREV_OPENSTACK_NOVA:=daily-cron.$branch}
 
 : ${TREEBASE_LINUX_XCP:=http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27}
 
diff --git a/ap-fetch-version b/ap-fetch-version
index a107c93..03381fd 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -106,6 +106,12 @@ ovmf)
repo_tree_rev_fetch_git ovmf \
$TREE_OVMF_UPSTREAM master $LOCALREV_OVMF
;;
+openstack-ocata)
+os_release=${branch#openstack-}
+repo_tree_rev_fetch_git "openstack-nova" \
+"$TREE_OPENSTACK_NOVA" "stable/$os_release" \
+"$LOCALREV_OPENSTACK_NOVA"
+;;
 osstest)
 if [ "x$OSSTEST_USE_HEAD" = "xy" ] ; then
git update-ref -m "Arranging to test HEAD" \
diff --git a/ap-fetch-version-old b/ap-fetch-version-old
index 3cbc176..6403bda 100755
--- a/ap-fetch-version-old
+++ b/ap-fetch-version-old
@@ -35,6 +35,7 @@ check_ap_fetch_placeholders
 : ${BASE_LOCALREV_XTF:=daily-cron.$branch.old}
 : ${BASE_LOCALREV_OVMF:=daily-cron.$branch.old}
 : ${BASE_TAG_LIBVIRT:=xen-tested-master}
+: ${BASE_LOCALREV_OPENSTACK_NOVA:=daily-cron.$branch.old}
 
 if info_linux_tree "$branch"; then
repo_tree_rev_fetch_git linux \
@@ -114,6 +115,12 @@ ovmf)
repo_tree_rev_fetch_git ovmf \
$BASE_TREE_OVMF xen-tested-master $BASE_LOCALREV_OVMF
;;
+openstack-ocata)
+os_release="${branch##*-}"
+repo_tree_rev_fetch_git openstack-nova \
+"$BASE_TREE_OPENSTACK_NOVA" "xen-tested-stable-$os_release" \
+"$BASE_LOCALREV_OPENSTACK_NOVA"
+;;
 osstest)
if [ "x$OSSTEST_USE_HEAD" != "xy" ] ; then
git fetch -f $HOME/testing.git production:ap-fetch
diff --git a/ap-print-url b/ap-print-url
index 93c14b3..cfba1d4 100755
--- a/ap-print-url
+++ b/ap-print-url
@@ -67,6 +67,9 @@ ovmf)
 osstest)
echo none:;
;;
+openstack-ocata)
+   echo $TREE_OPENSTACK_NOVA
+   ;;
 *)
echo >&2 "branch $branch ?"
exit 1
diff --git a/ap-push b/ap-push
index a27ccc2..6c9bddf 100755
--- a/ap-push
+++ b/ap-push
@@ -41,6 +41,7 @@ TREE_RUMPRUN=$PUSH_TREE_RUMPRUN
 TREE_SEABIOS=$PUSH_TREE_SEABIOS
 TREE_OVMF=$PUSH_TREE_OVMF
 TREE_XTF=$PUSH_TREE_XTF
+TREE_OPENSTACK_NOVA=$PUSH_TREE_OPENSTACK_NOVA
 
 if info_linux_tree "$branch"; then
cd $repos/linux
@@ 

[Xen-devel] [OSSTEST PATCH v12 16/21] ts-logs-capture: Capture OpenStack logs

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 ts-logs-capture | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ts-logs-capture b/ts-logs-capture
index 061a118..0e3d267 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -171,6 +171,12 @@ sub fetch_logs_host () {
 
   /var/core/*.core
 
+  /var/log/openstack/*.log
+  /etc/nova/*
+  /etc/neutron/*
+  /etc/cinder/*
+  
/home/osstest/build.*.test-*-devstack/tempest/etc/tempest.conf
+
   )];
 if (!try_fetch_logs($ho, $logs)) {
 logm("log fetching failed, trying hard host reboot...");
-- 
Anthony PERARD


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

[Xen-devel] [OSSTEST PATCH v12 14/21] ts-openstack-tempest: Update list of skipped tests

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
---
 ts-openstack-tempest | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/ts-openstack-tempest b/ts-openstack-tempest
index b95043a..ae3662f 100755
--- a/ts-openstack-tempest
+++ b/ts-openstack-tempest
@@ -31,23 +31,20 @@ sub tempest() {
 my $scenario = 'tempest.scenario';
 my $volume_boot_pattern =
 "$scenario.test_volume_boot_pattern.TestVolumeBootPattern";
-my $shelve_instance = "$scenario.test_shelve_instance.TestShelveInstance";
-
-# Ignore tests which try to boot a guest with /dev/vda as boot device name.
-push @ignored_tests,
-"^\Q$volume_boot_pattern.test_volume_boot_pattern\E";
-push @ignored_tests,
-"^\Q$volume_boot_pattern.test_create_ebs_image_and_check_boot\E";
-push @ignored_tests,
-"^\Q$shelve_instance.test_shelve_volume_backed_instance\E";
 
 # Those tests access a volume through iSCSI. This does not work when both
 # the server and client of iSCSI are on the same Xen host (both in dom0),
 # Linux 4.0 is the first Linux to have a fix.
 push @ignored_tests,
-"^\Q${volume_boot_pattern}V2.test_volume_boot_pattern\E";
+"^\Q${volume_boot_pattern}.test_volume_boot_pattern\E";
+push @ignored_tests,
+"^\Q${volume_boot_pattern}.test_create_ebs_image_and_check_boot\E";
+
+# See nova.git:devstack/tempest-dsvm-tempest-xen-rc
+push @ignored_tests,
+
"^\Qtempest.api.compute.admin.test_volume_swap.TestVolumeSwap.test_volume_swap\E";
 push @ignored_tests,
-"^\Q${volume_boot_pattern}V2.test_create_ebs_image_and_check_boot\E";
+
"^\Qtempest.api.compute.images.test_images.ImagesTestJSON.test_create_image_from_paused_server\E";
 
 # This regex below select the tests to run and exclude the ones marked as
 # slow as well as the explicit tests listed above.  It is based on the one
-- 
Anthony PERARD


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

[Xen-devel] [OSSTEST PATCH v12 13/21] ts-openstack-tempest: Fix tempest invocation

[Anthony PERARD]

./run_tempest.sh is deprecated.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 ts-openstack-tempest | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ts-openstack-tempest b/ts-openstack-tempest
index 82e9a71..b95043a 100755
--- a/ts-openstack-tempest
+++ b/ts-openstack-tempest
@@ -58,7 +58,8 @@ sub tempest() {
 
 target_cmd($ho, <

[Xen-devel] [OSSTEST PATCH v12 12/21] ts-openstack-deploy: Ignore libvirt-python version and use latest

[Anthony PERARD]

Devstack is going to try to install a specific version of libvirt-python
(currently 2.5.0) but this fail with libvirt installed by osstest.
Remove the requirement and use the latest available instead.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 ts-openstack-deploy | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index befe3d3..00f262f 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -93,6 +93,21 @@ END
 }
 );
 
+target_editfile($ho,
+"$builddir/requirements/upper-constraints.txt",
+sub {
+while () {
+# Ignore libvirt-python requirement and install latest,
+# otherwise it's not going to work with latest libvirt
+# installed by osstest.
+if (m/^libvirt-python===.*$/) {
+next;
+}
+print EO or die $!;
+}
+}
+);
+
 # Package python-systemd does not exist in Debian installed by osstest
 target_editfile($ho, "$builddir/devstack/files/debs/general", sub {
 while () {
-- 
Anthony PERARD


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

[Xen-devel] [OSSTEST PATCH v12 11/21] ts-openstack-deploy: Apply a Tempest patch

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 ts-openstack-deploy | 9 +
 1 file changed, 9 insertions(+)

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index f677513..befe3d3 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -137,6 +137,15 @@ END
 <

[Xen-devel] [OSSTEST PATCH v12 15/21] ts-openstack-deploy: Move logs to /var/log/openstack

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 ts-openstack-deploy | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index 00f262f..e7c94a5 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -58,7 +58,7 @@ DEST=$builddir
 DATA_DIR=\$DEST/data
 SERVICE_DIR=\$DEST/status
 SUBUNIT_OUTPUT=\$DEST/devstack.subunit
-LOGFILE=\$DEST/logs/stack.sh.log
+LOGDIR=/var/log/openstack
 LOG_COLOR=False
 LIBVIRT_TYPE=xen
 disable_service horizon
-- 
Anthony PERARD


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

[Xen-devel] [OSSTEST PATCH v12 10/21] ts-openstack-deploy: Increase open fd limit for RabbitMQ

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
---
 ts-openstack-deploy | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index 2107760..f677513 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -130,6 +130,13 @@ END
 osstest ALL=(ALL) NOPASSWD:ALL
 Defaults:osstest env_keep += "CURL_CA_BUNDLE"
 END
+
+# Increase open fd limit of RabbitMQ server (message broker)
+# https://bugs.launchpad.net/devstack/+bug/1703651
+target_putfilecontents_root_stash($ho, 100,
+<

[Xen-devel] [OSSTEST PATCH v12 17/21] ts-openstack-deploy: Increase devstack timeout

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 ts-openstack-deploy | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index e7c94a5..875c4a7 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -169,7 +169,7 @@ sub deploy() {
 $httpproxy .=
 "\nCURL_CA_BUNDLE=$mitmcert; export CURL_CA_BUNDLE"
 if $mitmcert;
-target_cmd($ho, <

[Xen-devel] [OSSTEST PATCH v12 21/21] make-flight: Increase dom0_mem for openstack flight

[Anthony PERARD]

With 4G for dom0_mem, a host running devstack is using about 1.5G of
swap.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 make-flight | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/make-flight b/make-flight
index 3771b16..16fe062 100755
--- a/make-flight
+++ b/make-flight
@@ -717,7 +717,7 @@ do_openstack_tests () {
 job_create_test test-$xenarch$kern-$dom0arch-devstack \
 test-devstack libvirt $xenarch $dom0arch \
 $os_runvars \
-dom0_mem=4000 \
+dom0_mem=6000 \
 enable_xsm=$xsm \
 all_hostflags=$most_hostflags
 done
-- 
Anthony PERARD


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

[Xen-devel] [OSSTEST PATCH v12 05/21] ts-openstack-deploy: set CURL_CA_BUNDLE

[Anthony PERARD]

From: Ian Jackson 

This overrides pip's attempt to specify a specific certificate bundle,
and is necessary if we have a MITM SSL proxy.

The security implications are not ideal, because the MITM proxy will
allow any X.509 cert from any CA, whereas pip would only allow an
expected cert.  But we got pip via plain https to start with...

CC: Anthony PERARD 
Signed-off-by: Ian Jackson 
---
 ts-openstack-deploy | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index d2971f5..6d7de1c 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -137,7 +137,10 @@ END
 
 sub deploy() {
 my $httpproxy = http_proxy_envsettings($ho);
-
+my $mitmcert = target_https_mitm_proxy_cert_path($ho);
+$httpproxy .=
+"\nCURL_CA_BUNDLE=$mitmcert; export CURL_CA_BUNDLE"
+if $mitmcert;
 target_cmd($ho, <

[Xen-devel] [OSSTEST PATCH v12 02/21] ts-openstack-tempest: Run Tempest to check OpenStack

[Anthony PERARD]

This script runs the OpenStack integration test suite, Tempest.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Campbell 
Acked-by: Ian Jackson 
---
 sg-run-job   |  1 +
 ts-openstack-tempest | 65 
 2 files changed, 66 insertions(+)
 create mode 100755 ts-openstack-tempest

diff --git a/sg-run-job b/sg-run-job
index 6092384..5f15821 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -632,6 +632,7 @@ proc run-job/test-rumprun {} {
 proc need-hosts/test-devstack {} { return host }
 proc run-job/test-devstack {} {
 run-ts . = ts-openstack-deploy + host
+run-ts . = ts-openstack-tempest + host
 }
 
 if {[file exists sg-run-job-adhoc]} {
diff --git a/ts-openstack-tempest b/ts-openstack-tempest
new file mode 100755
index 000..82e9a71
--- /dev/null
+++ b/ts-openstack-tempest
@@ -0,0 +1,65 @@
+#!/usr/bin/perl
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2016 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+use strict qw(vars);
+use Osstest;
+use Osstest::TestSupport;
+use Osstest::BuildSupport;
+
+tsreadconfig();
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho = selecthost($whhost);
+our $builddir = target_jobdir($ho);
+
+sub tempest() {
+my @ignored_tests;
+my $scenario = 'tempest.scenario';
+my $volume_boot_pattern =
+"$scenario.test_volume_boot_pattern.TestVolumeBootPattern";
+my $shelve_instance = "$scenario.test_shelve_instance.TestShelveInstance";
+
+# Ignore tests which try to boot a guest with /dev/vda as boot device name.
+push @ignored_tests,
+"^\Q$volume_boot_pattern.test_volume_boot_pattern\E";
+push @ignored_tests,
+"^\Q$volume_boot_pattern.test_create_ebs_image_and_check_boot\E";
+push @ignored_tests,
+"^\Q$shelve_instance.test_shelve_volume_backed_instance\E";
+
+# Those tests access a volume through iSCSI. This does not work when both
+# the server and client of iSCSI are on the same Xen host (both in dom0),
+# Linux 4.0 is the first Linux to have a fix.
+push @ignored_tests,
+"^\Q${volume_boot_pattern}V2.test_volume_boot_pattern\E";
+push @ignored_tests,
+"^\Q${volume_boot_pattern}V2.test_create_ebs_image_and_check_boot\E";
+
+# This regex below select the tests to run and exclude the ones marked as
+# slow as well as the explicit tests listed above.  It is based on the one
+# that can be found in tempest.git/tox.ini in the section [testenv:full].
+my $ignored_tests = join("|", @ignored_tests);
+my $regex = "(?!.*\\[.*\\bslow\\b.*\\]|$ignored_tests)".
+"(^tempest\\.(api|scenario|thirdparty))";
+
+target_cmd($ho, <

[Xen-devel] [OSSTEST PATCH v12 07/21] ts-openstack-deploy: Try to disable use of SYSTEMD

[Anthony PERARD]

There is USE_SYSTEMD off by default, but it is now turned on if
USE_SCREEN if off. Try to keep use of systemd disabled.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 ts-openstack-deploy | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index 147071f..1349009 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -45,7 +45,6 @@ sub checkout () {
 [[local|localrc]]
 # Everything should be cloned by osstest, so devstack don't have to do it
 ERROR_ON_CLONE=True
-USE_SCREEN=False
 ADMIN_PASSWORD=secretadmin
 DATABASE_PASSWORD=secretdatabase
 RABBIT_PASSWORD=secretrabbit
@@ -71,6 +70,9 @@ disable_service q-meta
 disable_service q-agt
 disable_service q-l3
 enable_service n-net
+USE_SYSTEMD=False
+# To keep systemd off, we need to enable use of screen
+USE_SCREEN=True
 [[post-config|\$CINDER_CONF]]
 [lvmdriver-1]
 volume_group = $vg
-- 
Anthony PERARD


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

[Xen-devel] [OSSTEST PATCH v12 00/21] Have OpenStack tested on top of xen's master and libvirt's master.

[Anthony PERARD]

Now powered with subunit-to-substep engine.

The Tempest test names reported via subunit are in the form:
tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,id-bdbb5441-9204-419d-a225-b4fdbfb1a1a8,image,network,volume]

so very long. Sometime, it in the form: "setUpClass ($classname)" for skipped
or failed tests preparation.

git tree:
https://xenbits.xen.org/git-http/people/aperard/osstest.git
tag: openstack-v12

(Acked, New):
A  ts-openstack-deploy: Deploy OpenStack on a host with devstack
A  ts-openstack-tempest: Run Tempest to check OpenStack
A  ts-openstack-deploy: Set http proxy
A  TestSupport: provide target_https_mitm_proxy_cert_path
A  ts-openstack-deploy: set CURL_CA_BUNDLE
A  ts-openstack-deploy: Keep CURL_CA_BUNDLE when sudo is called
A  ts-openstack-deploy: Try to disable use of SYSTEMD
A  ts-kernel-build: Enable network related modules for Neutron
A  ts-openstack-deploy: Switch to Neutron for network
   ts-openstack-deploy: Increase open fd limit for RabbitMQ
A  ts-openstack-deploy: Apply a Tempest patch
A  ts-openstack-deploy: Ignore libvirt-python version and use latest
A  ts-openstack-tempest: Fix tempest invocation
   ts-openstack-tempest: Update list of skipped tests
A  ts-openstack-deploy: Move logs to /var/log/openstack
A  ts-logs-capture: Capture OpenStack logs
A  ts-openstack-deploy: Increase devstack timeout
 N TestSupport: Implement target_cmd_subunit a subunit stream parser into 
substeps
 N ts-openstack-tempest: Use target_cmd_subunit
   Create a flight to test OpenStack with xen-unstable and libvirt
A  make-flight: Increase dom0_mem for openstack flight

Changes in V12:
- new patches to introduce a subunit stream parser and have subunit tests
  appears as substeps.
- rework openstack flight generation, get rid of the patch that introduced
  'openstack' branch which is not used, have the flight test a stable branch of
  openstack (release Ocata), branch name: openstack-ocata

Changes in V11:
- plenty of new patches, on top of the original 3 patches that were acked.
- and an attempt at creating a flight for a stable branch of openstack. But
  there is many git tree to pull the branch from.

Anthony PERARD (18):
  ts-openstack-deploy: Deploy OpenStack on a host with devstack
  ts-openstack-tempest: Run Tempest to check OpenStack
  ts-openstack-deploy: Keep CURL_CA_BUNDLE when sudo is called
  ts-openstack-deploy: Try to disable use of SYSTEMD
  ts-kernel-build: Enable network related modules for Neutron
  ts-openstack-deploy: Switch to Neutron for network
  ts-openstack-deploy: Increase open fd limit for RabbitMQ
  ts-openstack-deploy: Apply a Tempest patch
  ts-openstack-deploy: Ignore libvirt-python version and use latest
  ts-openstack-tempest: Fix tempest invocation
  ts-openstack-tempest: Update list of skipped tests
  ts-openstack-deploy: Move logs to /var/log/openstack
  ts-logs-capture: Capture OpenStack logs
  ts-openstack-deploy: Increase devstack timeout
  TestSupport: Implement target_cmd_subunit a subunit stream parser into
substeps
  ts-openstack-tempest: Use target_cmd_subunit
  Create a flight to test OpenStack with xen-unstable and libvirt
  make-flight: Increase dom0_mem for openstack flight

Ian Jackson (3):
  ts-openstack-deploy: Set http proxy
  TestSupport: provide target_https_mitm_proxy_cert_path
  ts-openstack-deploy: set CURL_CA_BUNDLE

 Osstest/TestSupport.pm |  50 ++
 ap-common  |  19 ++
 ap-fetch-version   |   6 ++
 ap-fetch-version-old   |   7 ++
 ap-print-url   |   3 +
 ap-push|   7 ++
 cr-daily-branch|  31 +
 cr-for-branches|   2 +-
 cri-common |   1 +
 make-flight|  46 -
 sg-run-job |   6 ++
 ts-kernel-build|  17 -
 ts-logs-capture|   6 ++
 ts-openstack-deploy| 182 +
 ts-openstack-tempest   |  63 +
 15 files changed, 442 insertions(+), 4 deletions(-)
 create mode 100755 ts-openstack-deploy
 create mode 100755 ts-openstack-tempest

-- 
Anthony PERARD


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

[Xen-devel] [OSSTEST PATCH v12 01/21] ts-openstack-deploy: Deploy OpenStack on a host with devstack

[Anthony PERARD]

This script installs any necessary packages and clones all of the OpenStack
trees which are used by devstack to deploy OpenStack.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 sg-run-job  |   5 ++
 ts-openstack-deploy | 148 
 2 files changed, 153 insertions(+)
 create mode 100755 ts-openstack-deploy

diff --git a/sg-run-job b/sg-run-job
index b1f94f4..6092384 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -629,6 +629,11 @@ proc run-job/test-rumprun {} {
  ts-guest-destroy-hardhost   $g   +
 }
 
+proc need-hosts/test-devstack {} { return host }
+proc run-job/test-devstack {} {
+run-ts . = ts-openstack-deploy + host
+}
+
 if {[file exists sg-run-job-adhoc]} {
 source sg-run-job-adhoc
 }
diff --git a/ts-openstack-deploy b/ts-openstack-deploy
new file mode 100755
index 000..6f061eb
--- /dev/null
+++ b/ts-openstack-deploy
@@ -0,0 +1,148 @@
+#!/usr/bin/perl
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2016 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+use strict qw(vars);
+use Osstest;
+use Osstest::TestSupport;
+use Osstest::BuildSupport;
+
+tsreadconfig();
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho = selecthost($whhost);
+our $builddir = target_jobdir($ho);
+
+sub packages () {
+target_install_packages($ho, qw(git sudo));
+}
+sub checkout () {
+prepbuilddirs();
+build_clone($ho, 'openstack_cinder',   $builddir, 'cinder');
+build_clone($ho, 'openstack_devstack', $builddir, 'devstack');
+build_clone($ho, 'openstack_glance',   $builddir, 'glance');
+build_clone($ho, 'openstack_keystone', $builddir, 'keystone');
+build_clone($ho, 'openstack_nova', $builddir, 'nova');
+build_clone($ho, 'openstack_requirements', $builddir, 'requirements');
+build_clone($ho, 'openstack_tempest',  $builddir, 'tempest');
+
+my $vg = target_choose_vg($ho, 10*1024); # 10GB
+target_putfilecontents_stash($ho, 60,
+<

[Xen-devel] [OSSTEST PATCH v12 04/21] TestSupport: provide target_https_mitm_proxy_cert_path

[Anthony PERARD]

From: Ian Jackson 

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 6e19b28..7215156 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -64,6 +64,7 @@ BEGIN {
   target_put_guest_image target_editfile
   target_editfile_cancel target_fetchurl
   http_proxy_envsettings
+  target_https_mitm_proxy_cert_path
   target_editfile_root target_file_exists
   target_editfile_kvp_replace
   target_run_apt
@@ -2714,4 +2715,10 @@ sub target_https_mitm_proxy_setup ($) {
 target_cmd_root($ho, 'update-ca-certificates', 300);
 }
 
+sub target_https_mitm_proxy_cert_path ($) {
+my ($ho) = @_;
+return undef unless length $c{HttpsProxyMITMCert};
+return '/etc/ssl/certs/osstest.pem';
+}
+
 1;
-- 
Anthony PERARD


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

[Xen-devel] [OSSTEST PATCH v12 06/21] ts-openstack-deploy: Keep CURL_CA_BUNDLE when sudo is called

[Anthony PERARD]

This is part of commit "ts-openstack-deploy: set CURL_CA_BUNDLE" but
also allow pip to work when it is called via sudo without preserving the
existing environment variables.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 ts-openstack-deploy | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index 6d7de1c..147071f 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -132,6 +132,7 @@ END
 target_putfilecontents_root_stash($ho, 100,
 <

[Xen-devel] [OSSTEST PATCH v12 09/21] ts-openstack-deploy: Switch to Neutron for network

[Anthony PERARD]

nova-network is not supported anymore and Neutron is the default.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 ts-openstack-deploy | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index 1349009..2107760 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -35,6 +35,7 @@ sub checkout () {
 build_clone($ho, 'openstack_devstack', $builddir, 'devstack');
 build_clone($ho, 'openstack_glance',   $builddir, 'glance');
 build_clone($ho, 'openstack_keystone', $builddir, 'keystone');
+build_clone($ho, 'openstack_neutron',  $builddir, 'neutron');
 build_clone($ho, 'openstack_nova', $builddir, 'nova');
 build_clone($ho, 'openstack_requirements', $builddir, 'requirements');
 build_clone($ho, 'openstack_tempest',  $builddir, 'tempest');
@@ -63,13 +64,6 @@ LIBVIRT_TYPE=xen
 disable_service horizon
 disable_service n-novnc
 disable_service dstat
-# Disable neutron and switch back to nova-network
-disable_service q-svc
-disable_service q-dhcp
-disable_service q-meta
-disable_service q-agt
-disable_service q-l3
-enable_service n-net
 USE_SYSTEMD=False
 # To keep systemd off, we need to enable use of screen
 USE_SCREEN=True
-- 
Anthony PERARD


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

[Xen-devel] [OSSTEST PATCH v12 03/21] ts-openstack-deploy: Set http proxy

[Anthony PERARD]

From: Ian Jackson 

This allows ./stack.sh to access the global internet.

CC: Anthony PERARD 
Signed-off-by: Ian Jackson 
---
 ts-openstack-deploy | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index 6f061eb..d2971f5 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -136,8 +136,11 @@ END
 }
 
 sub deploy() {
+my $httpproxy = http_proxy_envsettings($ho);
+
 target_cmd($ho, <

[Xen-devel] [OSSTEST PATCH v12 08/21] ts-kernel-build: Enable network related modules for Neutron

[Anthony PERARD]

Those options/modules are needed to run OpenStack Neutron with Open
vSwitch.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 ts-kernel-build | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/ts-kernel-build b/ts-kernel-build
index 94e67a4..0bcd340 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -252,10 +252,23 @@ setopt CONFIG_BLK_DEV_LOOP y
 
 setopt CONFIG_PACKET y
 
-# needed for OpenStack
-# because: https://bugzilla.redhat.com/show_bug.cgi?id=910619#c6
+# Used by OpenStack Neutron with Open vSwitch
+setopt CONFIG_OPENVSWITCH m
+setopt CONFIG_IP6_NF_RAW m
+setopt CONFIG_IP_NF_RAW m
+setopt CONFIG_IP_SET m
+setopt CONFIG_IP_SET_HASH_NET m
 setopt CONFIG_NETFILTER_ADVANCED y
+setopt CONFIG_NETFILTER_XT_CONNMARK m
+setopt CONFIG_NETFILTER_XT_MATCH_COMMENT m
+setopt CONFIG_NETFILTER_XT_MATCH_MAC m
+setopt CONFIG_NETFILTER_XT_MATCH_PHYSDEV m
+setopt CONFIG_NETFILTER_XT_SET m
 setopt CONFIG_NETFILTER_XT_TARGET_CHECKSUM m
+setopt CONFIG_NETFILTER_XT_TARGET_CT m
+setopt CONFIG_NETFILTER_XT_TARGET_REDIRECT m
+setopt CONFIG_NF_CONNTRACK_ZONES y
+setopt CONFIG_VETH m
 
 # Used by OpenStack Tempest to test encrypted volume
 setopt CONFIG_CRYPTO_XTS m
-- 
Anthony PERARD


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

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

Last test of basis71682  2017-07-12 03:20:15 Z0 days
Testing same since71685  2017-07-12 07:19:30 Z0 days1 attempts


People who touched revisions under test:
  Eric Dong 

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 b1fe2029fa2f473922fb830a2e33c5ae0c0ae20d
Author: Eric Dong 
Date:   Tue Jul 11 10:07:36 2017 +0800

UefiCpuPkg CpuCommonFeaturesLib: Fix smx/vmx enable logic error.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
Reviewed: Jeff Fan 

commit 05973f9e8aa6f50ff177610bc791a16540963a9a
Author: Eric Dong 
Date:   Tue Jul 11 10:06:56 2017 +0800

UefiCpuPkg RegisterCpuFeaturesLib: Add error handling code.

Add error handling code when initialize the CPU feature failed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
Reviewed-by: Jeff Fan 

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

Re: [Xen-devel] [PATCH v3 03/11] libxl: add generic function to get and free device list

[Wei Liu]

On Wed, Jul 12, 2017 at 04:43:23PM +0300, Oleksandr Grytsov wrote:
> On Wed, Jul 12, 2017 at 12:51 PM, Wei Liu  wrote:
> > On Mon, Jul 10, 2017 at 03:26:12PM +0300, Oleksandr Grytsov wrote:
> >> It means for each device where getting device list is required there will 
> >> be
> >> GC_INIT(ctc)
> >>
> >> libxl__device_list(gc, ...)
> >>
> >> GC_FREE
> >>
> >> instead of just:
> >>
> >> libxl__device_list(ctx, ...);
> >
> > I think this is worth it because we might need to use the
> > libl__device_list function internally.
> 
> I've reworked the patch series and done it in following way:
> 
> libxl__device_list takes gc and interface function init CTX:
> 
> libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t
> domid, int *num)
> {
> libxl_device_disk *r;
> 
> GC_INIT(ctx);
> 
> r = libxl__device_list(gc, __disk_devtype, domid, "disk", num);
> 
> GC_FREE;
> 
> return r;
> }
> 
> There was comment to use libxl_malloc instead of malloc in libxl__device_list.
> But it can't be used because calling GC_FREE frees the list.
> So I've left malloc and free the list in libxl__device_list_free.
> 

You can pass in NO_GC (NOGC) to libxl__malloc.

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install   fail REGR. vs. 71668
 test-amd64-amd64-examine  7 rebootfail REGR. vs. 71668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 10 debian-installfail REGR. vs. 71668
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 71668

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-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
71668
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stopfail blocked in 71668
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   like 71668
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 71668
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   like 71668
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 71668
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-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
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 17 guest-stop fail never pass

version targeted for testing:
 xen  89df98b77d28136c4d7aade13a1c8bc154d2919f
baseline version:
 xen  d23afa6399a78ca7d0ed3294119632535828c9d8

Last test of basis71668  2017-07-07 14:21:03 Z4 days
Testing same since71684  2017-07-12 07:16:11 Z0 days1 

Re: [Xen-devel] [edk2] OVMF Secure Boot variable storage issue

[Konrad Rzeszutek Wilk]

On Thu, Jul 06, 2017 at 02:55:27PM -0400, Jason Dickens wrote:
> Thanks for the response Bill. If I should recognize your name, I'm sorry,
> I'm bad with names, but I have been doing a lot of work with Wind River
> recently (and in the past) so its possible I should.
> 
> Actually, I should have mentioned I'm using Xen with full virtualization.
> This means that OVMF firmware can't change without rebuilding Xen. For
> reasons I don't know, it seems the Xen build uses the firmware image by
> first converting it to a C array and then compiling it in.
> 

That can be changed - it already has the mechanism to "slurp" binary
blobs from the host. The only reason it does that right now is mostly
historic - all BIOS images where compiled in 'hvmloader'.

> However, I'm not sure that's the real issue. As far as I'm aware, OVMF
> implements NvVars on the VM image to provide non-volatile storage instead of
> actually modifying the image. As I mentioned, "some" configuration changes
> do persist such as changing the screen resolution in the OVMF settings. Also
> I can see that NvVars is updating its modification time after setting secure
> boot variables. What I'm trying to determine is if there a particular reason
> or implementation problem that causes secure boot settings not persist.
> 
> 
> 
> On 7/6/2017 2:30 PM, Bill Paul wrote:
> > Of all the gin joints in all the towns in all the world, Jason Dickens had 
> > to
> > walk into mine at 10:31:18 on Thursday 06 July 2017 and say:
> > 
> > > All,
> > > 
> > > I'm trying to understand why the secure boot variables (PK, KEK, db,
> > > etc) when using the OVMF build are not retained across reboot? It seems
> > > that this code uses roughly the same SetVariable, GetVariable2 approach
> > > as say the PlatformConfig uses to store screen resolution (which is
> > > retained). Additionally, the NvVars file is being at least touched by
> > > the secure boot configuration. So why are none of the keys retained on
> > > the next reboot?
> > If you're running OVMF in the QEMU simulator, and you're using the -bios
> > option, try using the -pflash option instead.
> > 
> > I know that when using -bios, QEMU only pretends to allow writes to the
> > firmware region, and if you stop QEMU all changes are discarded. The same
> > might be true if you just trigger a hard reboot in the simulator too.
> > 
> > If you use -pflash instead, your changes will be saved. Note that this means
> > your OVMF image will be modified, so keep a copy of the original elsewhere 
> > so
> > that you can start over fresh again if you need to.
> > 
> > (Unfortunately I don't think OVMF has a "load factor defaults" option in its
> > internal menus.)
> > 
> > -Bill
> > > I know this was an issue in the past, but I haven't found the resolution?
> > > 
> > > Jason
> > > 
> > > 
> > > ___
> > > edk2-devel mailing list
> > > edk2-de...@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> 
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

[Arnd Bergmann]

On Wed, Jul 12, 2017 at 3:10 PM, Greg Kroah-Hartman
 wrote:
> On Tue, Jul 11, 2017 at 03:35:15PM -0700, Linus Torvalds wrote:
>> [ Very random list of maintainers and mailing lists, at least
>> partially by number of warnings generated by gcc-7.1.1 that is then
>> correlated with the get_maintainers script ]
>>
>> So I upgraded one of my boxes to F26, which upgraded the compiler to 
>> gcc-7.1.1
>>
>> Which in turn means that my nice clean allmodconfig compile is not an
>> unholy mess of annoying new warnings.
>
> I asked Arnd about this the other day on IRC as I've hit this as well on
> the stable releases, and it's really annoying.  He mentioned that he had
> lots of these warnings fixed, but didn't push most of the changes out
> yet.

To clarify: most of the patches I wrote ended up getting merged, but
there were a couple that I did not submit a second time after they
got dropped, but I gave up on trying to fix the new -Wformat warnings
and simply disabled them, hoping someone else would do it before me,
or that the gcc developers would find a way to reduce the false-positive
ones before the release.

>  Arnd, any repo with them in it that we could look at?

I have a private tree on my workstation that has lots of random
crap, and I rebase it all the time but normally don't publish it.

I have uploaded today's snapshot to

git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git randconfig-4.13-next

The way I work with this is helpful to catch build regressions as soon
as they happen, but not so good in finding things that I have either
submitted a patch for before and don't remember if it should be
resubmitted, or stuff that I decided I didn't want to deal with at some
point.

I was already planning to start over from scratch one of these days,
and cherry-pick+resubmit the patches that are actually required
for randconfig builds.

>> Anyway, it would be lovely if some of the more affected developers
>> would take a look at gcc-7.1.1 warnings. Right now I get about three
>> *thousand* lines of warnings from a "make allmodconfig" build, which
>> makes them a bit overwhelming.
>
> I only have 310 when building the 4.12.0 release with 7.1.1, I wonder if
> Fedora turned more warnings on in their compiler release, I'm running
> Arch here:
> $ gcc --version
> gcc (GCC) 7.1.1 20170621

This is what I get in today's linux-next:

$ grep error: 4.13-next-allmod-warning | sed -e 's:^.*\[-W:-W:' | sort
| uniq -c | cut -f 1 -d\] | sort -n
  1 -Werror=parentheses
  2 -Werror=tautological-compare
  2 -Werror=unused-result
 34 -Werror=format-overflow=
 41 -Werror=int-in-bool-context
233 -Werror=format-truncation=

I'll resubmit the patches for -Wparenthese, -Wtautological-compar,
-Wunused-result and -Wint-in-bool-context that I had sent earlier,
plus a new patch to move -Wformat-truncation into W=1.

  Arnd

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

Re: [Xen-devel] [PATCH v3 03/11] libxl: add generic function to get and free device list

[Oleksandr Grytsov]

On Wed, Jul 12, 2017 at 12:51 PM, Wei Liu  wrote:
> On Mon, Jul 10, 2017 at 03:26:12PM +0300, Oleksandr Grytsov wrote:
>> It means for each device where getting device list is required there will be
>> GC_INIT(ctc)
>>
>> libxl__device_list(gc, ...)
>>
>> GC_FREE
>>
>> instead of just:
>>
>> libxl__device_list(ctx, ...);
>
> I think this is worth it because we might need to use the
> libl__device_list function internally.

I've reworked the patch series and done it in following way:

libxl__device_list takes gc and interface function init CTX:

libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t
domid, int *num)
{
libxl_device_disk *r;

GC_INIT(ctx);

r = libxl__device_list(gc, __disk_devtype, domid, "disk", num);

GC_FREE;

return r;
}

There was comment to use libxl_malloc instead of malloc in libxl__device_list.
But it can't be used because calling GC_FREE frees the list.
So I've left malloc and free the list in libxl__device_list_free.

-- 
Best Regards,
Oleksandr Grytsov.

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

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

[Arnd Bergmann]

On Wed, Jul 12, 2017 at 5:41 AM, Linus Torvalds
 wrote:

>
> We also have about a bazillion
>
> warning: ‘*’ in boolean context, suggest ‘&&’ instead
>
> warnings in drivers/ata/libata-core.c, all due to a single macro that
> uses a pattern that gcc-7.1.1 doesn't like. The warning looks a bit
> debatable, but I suspect the macro could easily be changed too.
>
> Tejun, would you hate just moving the "multiply by 1000" part _into_
> that EZ() macro? Something like the attached (UNTESTED!) patch?

Tejun applied an almost identical patch of mine a while ago, but it seems to
have gotten lost in the meantime in some rebase:

https://patchwork.kernel.org/patch/9721397/
https://patchwork.kernel.org/patch/9721399/

I guess I should have resubmitted the second patch with the suggested
improvement.

 Arnd

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

Re: [Xen-devel] [PATCH v9 7/7] tools/xen-mceinj: add support of injecting LMCE

[Konrad Rzeszutek Wilk]

On Wed, Jul 12, 2017 at 10:04:40AM +0800, Haozhong Zhang wrote:
> If option '-l' or '--lmce' is specified and the host supports LMCE,
> xen-mceinj will inject LMCE to CPU specified by '-c' (or CPU0 if '-c'
> is not present).
> 
> Signed-off-by: Haozhong Zhang 
> Acked-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/tests/mce-test/tools/xen-mceinj.c | 50 
> +++--
>  1 file changed, 48 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
> b/tools/tests/mce-test/tools/xen-mceinj.c
> index bae5a46eb5..380e42190c 100644
> --- a/tools/tests/mce-test/tools/xen-mceinj.c
> +++ b/tools/tests/mce-test/tools/xen-mceinj.c
> @@ -56,6 +56,8 @@
>  #define MSR_IA32_MC0_MISC0x0403
>  #define MSR_IA32_MC0_CTL20x0280
>  
> +#define MCG_STATUS_LMCE  0x8
> +
>  struct mce_info {
>  const char *description;
>  uint8_t mcg_stat;
> @@ -113,6 +115,7 @@ static struct mce_info mce_table[] = {
>  #define LOGFILE stdout
>  
>  int dump;
> +int lmce;
>  struct xen_mc_msrinject msr_inj;
>  
>  static void Lprintf(const char *fmt, ...)
> @@ -212,6 +215,35 @@ static int inject_mce(xc_interface *xc_handle, int 
> cpu_nr)
>  return xc_mca_op(xc_handle, );
>  }
>  
> +static int inject_lmce(xc_interface *xc_handle, unsigned int cpu)
> +{
> +uint8_t *cpumap = NULL;
> +size_t cpumap_size, line, shift;
> +unsigned int nr_cpus;
> +int ret;
> +
> +nr_cpus = mca_cpuinfo(xc_handle);
> +if ( !nr_cpus )
> +err(xc_handle, "Failed to get mca_cpuinfo");
> +if ( cpu >= nr_cpus )
> +err(xc_handle, "-c %u is larger than %u", cpu, nr_cpus - 1);
> +
> +cpumap_size = (nr_cpus + 7) / 8;

bitmap_size

> +cpumap = malloc(cpumap_size);

bitmap_alloc ?
> +if ( !cpumap )
> +err(xc_handle, "Failed to allocate cpumap\n");
> +memset(cpumap, 0, cpumap_size);

bitmap_clear?

> +line = cpu / 8;

BITMAP_ENTRY?
> +shift = cpu % 8;

BITMAP_SHIFT?
> +memset(cpumap + line, 1 << shift, 1);
> +
> +ret = xc_mca_op_inject_v2(xc_handle, XEN_MC_INJECT_TYPE_LMCE,
> +  cpumap, cpumap_size * 8);
> +
> +free(cpumap);
> +return ret;
> +}
> +
>  static uint64_t bank_addr(int bank, int type)
>  {
>  uint64_t addr;
> @@ -330,8 +362,15 @@ static int inject(xc_interface *xc_handle, struct 
> mce_info *mce,
>uint32_t cpu_nr, uint32_t domain, uint64_t gaddr)
>  {
>  int ret = 0;
> +uint8_t mcg_status = mce->mcg_stat;
>  
> -ret = inject_mcg_status(xc_handle, cpu_nr, mce->mcg_stat, domain);
> +if ( lmce )
> +{
> +if ( mce->cmci )
> +err(xc_handle, "No support to inject CMCI as LMCE");
> +mcg_status |= MCG_STATUS_LMCE;
> +}
> +ret = inject_mcg_status(xc_handle, cpu_nr, mcg_status, domain);
>  if ( ret )
>  err(xc_handle, "Failed to inject MCG_STATUS MSR");
>  
> @@ -354,6 +393,8 @@ static int inject(xc_interface *xc_handle, struct 
> mce_info *mce,
>  err(xc_handle, "Failed to inject MSR");
>  if ( mce->cmci )
>  ret = inject_cmci(xc_handle, cpu_nr);
> +else if ( lmce )
> +ret = inject_lmce(xc_handle, cpu_nr);
>  else
>  ret = inject_mce(xc_handle, cpu_nr);
>  if ( ret )
> @@ -393,6 +434,7 @@ static struct option opts[] = {
>  {"dump", 0, 0, 'D'},
>  {"help", 0, 0, 'h'},
>  {"page", 0, 0, 'p'},
> +{"lmce", 0, 0, 'l'},
>  {"", 0, 0, '\0'}
>  };
>  
> @@ -409,6 +451,7 @@ static void help(void)
> "  -d, --domain=DOMID   target domain, the default is Xen 
> itself\n"
> "  -h, --help   print this page\n"
> "  -p, --page=ADDR  physical address to report\n"
> +   "  -l, --lmce   inject as LMCE (Intel only)\n"
> "  -t, --type=ERROR error type\n");
>  
>  for ( i = 0; i < MCE_TABLE_SIZE; i++ )
> @@ -438,7 +481,7 @@ int main(int argc, char *argv[])
>  }
>  
>  while ( 1 ) {
> -c = getopt_long(argc, argv, "c:Dd:t:hp:", opts, _index);
> +c = getopt_long(argc, argv, "c:Dd:t:hp:l", opts, _index);
>  if ( c == -1 )
>  break;
>  switch ( c ) {
> @@ -463,6 +506,9 @@ int main(int argc, char *argv[])
>  case 't':
>  type = strtol(optarg, NULL, 0);
>  break;
> +case 'l':
> +lmce = 1;
> +break;
>  case 'h':
>  default:
>  help();
> -- 
> 2.11.0
> 
> 
> ___
> 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 v9 6/7] tools/libxc: add support of injecting MC# to specified CPUs

[Konrad Rzeszutek Wilk]

On Wed, Jul 12, 2017 at 10:04:39AM +0800, Haozhong Zhang wrote:
> Though XEN_MC_inject_v2 allows injecting MC# to specified CPUs, the
> current xc_mca_op() does not use this feature and not provide an
> interface to callers. This commit add a new xc_mca_op_inject_v2() that
> receives a cpumap providing the set of target CPUs.
> 
> Signed-off-by: Haozhong Zhang 
> Acked-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxc/include/xenctrl.h |  2 ++
>  tools/libxc/xc_misc.c | 52 
> ++-
>  2 files changed, 53 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index c51bb3b448..552a4fd47d 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1809,6 +1809,8 @@ int xc_cpuid_apply_policy(xc_interface *xch,
>  void xc_cpuid_to_str(const unsigned int *regs,
>   char **strs); /* some strs[] may be NULL if ENOMEM */
>  int xc_mca_op(xc_interface *xch, struct xen_mc *mc);
> +int xc_mca_op_inject_v2(xc_interface *xch, unsigned int flags,
> +xc_cpumap_t cpumap, unsigned int nr_cpus);
>  #endif
>  
>  struct xc_px_val {
> diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
> index 88084fde30..2303293c6c 100644
> --- a/tools/libxc/xc_misc.c
> +++ b/tools/libxc/xc_misc.c
> @@ -341,7 +341,57 @@ int xc_mca_op(xc_interface *xch, struct xen_mc *mc)
>  xc_hypercall_bounce_post(xch, mc);
>  return ret;
>  }
> -#endif
> +
> +int xc_mca_op_inject_v2(xc_interface *xch, unsigned int flags,
> +xc_cpumap_t cpumap, unsigned int nr_bits)
> +{
> +int ret = -1;
> +struct xen_mc mc_buf, *mc = _buf;
> +struct xen_mc_inject_v2 *inject = >u.mc_inject_v2;
> +
> +DECLARE_HYPERCALL_BOUNCE(cpumap, 0, XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +DECLARE_HYPERCALL_BOUNCE(mc, sizeof(*mc), 
> XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> +
> +memset(mc, 0, sizeof(*mc));
> +
> +if ( cpumap )
> +{
> +if ( !nr_bits )
> +{
> +errno = EINVAL;
> +goto out;
> +}
> +
> +HYPERCALL_BOUNCE_SET_SIZE(cpumap, (nr_bits + 7) / 8);

bitmap_size ?

> +if ( xc_hypercall_bounce_pre(xch, cpumap) )
> +{
> +PERROR("Could not bounce cpumap memory buffer");
> +goto out;
> +}
> +set_xen_guest_handle(inject->cpumap.bitmap, cpumap);
> +inject->cpumap.nr_bits = nr_bits;
> +}
> +
> +inject->flags = flags;
> +mc->cmd = XEN_MC_inject_v2;
> +mc->interface_version = XEN_MCA_INTERFACE_VERSION;
> +
> +if ( xc_hypercall_bounce_pre(xch, mc) )
> +{
> +PERROR("Could not bounce xen_mc memory buffer");
> +goto out_free_cpumap;
> +}
> +
> +ret = xencall1(xch->xcall, __HYPERVISOR_mca, 
> HYPERCALL_BUFFER_AS_ARG(mc));
> +
> +xc_hypercall_bounce_post(xch, mc);
> +out_free_cpumap:
> +if ( cpumap )
> +xc_hypercall_bounce_post(xch, cpumap);
> +out:
> +return ret;
> +}
> +#endif /* __i386__ || __x86_64__ */
>  
>  int xc_perfc_reset(xc_interface *xch)
>  {
> -- 
> 2.11.0
> 
> 
> ___
> 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] Lots of new warnings with gcc-7.1.1

[Greg Kroah-Hartman]

On Tue, Jul 11, 2017 at 03:35:15PM -0700, Linus Torvalds wrote:
> [ Very random list of maintainers and mailing lists, at least
> partially by number of warnings generated by gcc-7.1.1 that is then
> correlated with the get_maintainers script ]
> 
> So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.1.1
> 
> Which in turn means that my nice clean allmodconfig compile is not an
> unholy mess of annoying new warnings.

I asked Arnd about this the other day on IRC as I've hit this as well on
the stable releases, and it's really annoying.  He mentioned that he had
lots of these warnings fixed, but didn't push most of the changes out
yet.  Arnd, any repo with them in it that we could look at?

> Normally I hate the stupid new warnings, but this time around they are
> actually exactly the kinds of warnings you'd want to see and that are
> hard for humans to pick out errors: lots of format errors wrt limited
> buffer sizes.
> 
> At the same time, many of them *are* annoying. We have various limited
> buffers that are limited for a good reason, and some of the format
> truncation warnings are about numbers in the range {0-MAX_INT], where
> we definitely know that we don't need to worry about the really big
> ones.
> 
> After all, we're using "snprintf()" for a reason - we *want* to
> truncate if the buffer is too small.

Yeah, that's the warnings in the USB core code, we "know" this will not
happen, and we are using snprintf() for that reason as well, I don't
know how to fool gcc into the fact that it's all ok here.

> Anyway, it would be lovely if some of the more affected developers
> would take a look at gcc-7.1.1 warnings. Right now I get about three
> *thousand* lines of warnings from a "make allmodconfig" build, which
> makes them a bit overwhelming.

I only have 310 when building the 4.12.0 release with 7.1.1, I wonder if
Fedora turned more warnings on in their compiler release, I'm running
Arch here:
$ gcc --version
gcc (GCC) 7.1.1 20170621

thanks,

greg k-h

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

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

Last test of basis   111535  2017-07-07 15:02:42 Z4 days
Testing same since   111733  2017-07-12 11:03:10 Z0 days1 attempts


People who touched revisions under test:
  Wei Liu 
  Xiong Zhang 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=614a14736e33fb84872eb00f08799ebbc73a96c6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
614a14736e33fb84872eb00f08799ebbc73a96c6
+ branch=xen-unstable-smoke
+ revision=614a14736e33fb84872eb00f08799ebbc73a96c6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x614a14736e33fb84872eb00f08799ebbc73a96c6 = 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
++ : 

Re: [Xen-devel] [PATCH 05/15] xen: p2m: new 'p2m_epc' type for EPC mapping

[George Dunlap]

> On Jul 12, 2017, at 1:01 PM, Andrew Cooper  wrote:
> 
> On 09/07/17 10:12, Kai Huang wrote:
>> A new 'p2m_epc' type is added for EPC mapping type. Two wrapper functions
>> set_epc_p2m_entry and clear_epc_p2m_entry are also added for further use.
> 
> Other groups in Intel have been looking to reduce the number of p2m types we 
> have, so we can use more hardware defined bits in the EPT pagetable entries.
> 
> If we need a new type then we will certainly add one, but it is not clear why 
> this type is needed.

Does the hypervisor need to know which pages of a domain’s p2m 1) have valid 
config set up, but 2) aren’t accessible to itself or any other domain?

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

Re: [Xen-devel] [PATCH 5/25] Xen/doc: Add Xen virtual IOMMU doc

[Lan Tianyu]

On 2017年07月12日 15:26, Julien Grall wrote:
> Hi,
> 
> On 07/12/2017 04:09 AM, Lan Tianyu wrote:
>> On 2017年07月08日 00:08, Julien Grall wrote:
 Because we now just have onE vIOMMU, all virtual interrupt will be
 bound
 to it. If need to support mult-vIOMMU, we can add device-scope
 field(sbdf array or some thing like that) in the structure and specify
 what devices should be under one vIOMMU.
>>>
>>> I am not sure to follow the argument here. Even if you have only one
>>> vIOMMU you need to be able to do the correspondence between the virtual
>>> MasterID (for PCI it is based on the RID) and the host MasterID.
> 
> 
>>   Sorry for later response.
>>   MasterID you mentioned here is sbdf, right? Binding between sbdf
>> and vsbdf(virtual sbdf) should be in the device pass through related
>> interface(e.g, xc_domain_bind_pt_irq_int() has already done such similar
>> thing that bind vsbdf with real interrupt of hypervisor.).
> 
> The MasterID is not the sbdf. It is an identifier based on the tuple
> (Hostbridge, Requester ID). The RequesterID (RID), might be the bdf of
> the device or something different if there is DMA aliases.
> 
> The relation between MasterID and the tuple is defined by the hardware
> and will be reported by the firmware tables.

OK. This seems ARM specific, right? From my view, Binding virtual
MasterID with physical one still should be in pass through domctl and
we may store the relationship in the hypervisor at that point.

> 
>>   vIOMMU device model can get vsbdf when guest configure vIOMMU entry
>> and hypervisor can do conversion between sbdf and vsbdf. For interrupt
>> remapping on virtual VTD, we don't find such requirement so far and got
>> enough data from IOAPIC/MSI entry and interrupt remapping entry of
>> virtual VTD. So we don't extend pass through interface.
> 
> Well, you have to think how this could be extended in the future. This
> is quite important to plan head for stable ABI.

Sure.

> Thankfully, you seem to
> use DOMCTL, so I guess we don't have to worry too much...

I try to make new vIOMMU DOMCTL general enough for all vendors.
Operations of Create/destroy and Query capabilities are necessary for
all vendor. I don't have other vendor IOMMU's knowledge and Any
suggestions are very appreciated. Thanks.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH 02/15] xen: vmx: detect ENCLS VMEXIT

[Andrew Cooper]

On 09/07/17 10:09, Kai Huang wrote:

If ENCLS VMEXIT is not present then we cannot support SGX virtualization.
This patch detects presence of ENCLS VMEXIT. A Xen boot boolean parameter
'sgx' is also added to manually enable/disable SGX.

Signed-off-by: Kai Huang 


At a minimum, you also need to modify calculate_hvm_max_policy() to hide 
SGX if we don't have ENCLS intercept support.


~Andrew

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

Re: [Xen-devel] [PATCH 01/15] xen: x86: expose SGX to HVM domain in CPU featureset

[Andrew Cooper]

On 09/07/17 10:04, Kai Huang wrote:

Expose SGX in CPU featureset for HVM domain. SGX will not be supported for
PV domain, as ENCLS (which SGX driver in guest essentially runs) must run
in ring 0, while PV kernel runs in ring 3. Theoretically we can support SGX
in PV domain via either emulating #GP caused by ENCLS running in ring 3, or
by PV ENCLS but it is really not necessary at this stage. And currently SGX
is only exposed to HAP HVM domain (we can add for shadow in the future).

SGX Launch Control is also exposed in CPU featureset for HVM domain. SGX
Launch Control depends on SGX.

Signed-off-by: Kai Huang 


I think its perfectly reasonable to restrict to HVM guests to start 
with, although I don't see how shadow vs HAP has any impact at this 
stage?  All that matters is that the EPC pages appear in the guests p2m.


~Andrew

___
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

[Andrew Cooper]

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?


~Andrew

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

Re: [Xen-devel] [PATCH 05/15] xen: p2m: new 'p2m_epc' type for EPC mapping

[Andrew Cooper]

On 09/07/17 10:12, Kai Huang wrote:

A new 'p2m_epc' type is added for EPC mapping type. Two wrapper functions
set_epc_p2m_entry and clear_epc_p2m_entry are also added for further use.


Other groups in Intel have been looking to reduce the number of p2m 
types we have, so we can use more hardware defined bits in the EPT 
pagetable entries.


If we need a new type then we will certainly add one, but it is not 
clear why this type is needed.


~Andrew

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

Re: [Xen-devel] [PATCH 08/15] xen: x86: add SGX cpuid handling support.

[Andrew Cooper]

On 09/07/17 10:10, Kai Huang wrote:

This patch adds SGX to cpuid handling support. In init_guest_cpuid, for
raw_policy and host_policy, physical EPC info is reported, but for pv_max_policy
and hvm_max_policy EPC is hidden, as for particular domain, it's EPC base and
size are from tookstack, and it is meaningless to contain physical EPC info in
them. Before domain's EPC base and size are properly configured, guest's SGX
cpuid should report invalid EPC, which is also consistent with HW behavior.

Currently all EPC pages are fully populated for domain when it is created.
Xen gets domain's EPC base and size from toolstack via XEN_DOMCTL_set_cpuid,
so domain's EPC pages are also populated in XEN_DOMCTL_set_cpuid, after
receiving valid EPC base and size. Failure to populate EPC (such as there's
no enough free EPC pages) results in domain creation failure by making
XEN_DOMCTL_set_cpuid return error.

Signed-off-by: Kai Huang 
---
  xen/arch/x86/cpuid.c| 87 -
  xen/arch/x86/domctl.c   | 47 +++-
  xen/include/asm-x86/cpuid.h | 26 +-
  3 files changed, 157 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index d359e090f3..db896be2e8 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include 
  
  const uint32_t known_features[] = INIT_KNOWN_FEATURES;

  const uint32_t special_features[] = INIT_SPECIAL_FEATURES;
@@ -158,6 +159,44 @@ static void recalculate_xstate(struct cpuid_policy *p)
  }
  }
  
+static void recalculate_sgx(struct cpuid_policy *p, bool_t hide_epc)


Across the entire series, please use bool rather than bool_t.

Why do we need this hide_epc parameter?  If we aren't providing any epc 
resource to the guest, the entire sgx union should be zero and the SGX 
feature bit should be hidden.



+{
+if ( !p->feat.sgx )
+{
+memset(>sgx, 0, sizeof (p->sgx));
+return;
+}
+
+if ( !p->sgx.sgx1 )
+{
+memset(>sgx, 0, sizeof (p->sgx));
+return;
+}


These two clauses can be combined.


+
+/*
+ * SDM 42.7.2.1 SECS.ATTRIBUTE.XFRM:
+ *
+ * Legal value for SECS.ATTRIBUTE.XFRM conform to these requirements:
+ *  - XFRM[1:0] must be set to 0x3;
+ *  - If processor does not support XSAVE, or if the system software has 
not
+ *enabled XSAVE, then XFRM[63:2] must be 0.
+ *  - If the processor does support XSAVE, XFRM must contain a value that
+ *would be legal if loaded into XCR0.
+ */
+p->sgx.xfrm_low = 0x3;
+p->sgx.xfrm_high = 0;
+if ( p->basic.xsave )
+{
+p->sgx.xfrm_low |= p->xstate.xcr0_low;
+p->sgx.xfrm_high |= p->xstate.xcr0_high;
+}


There is a bug here, but it will disappear with my CPUID work.  At the 
moment, the job of this function is to sanitise values handed by the 
toolstack, which includes zeroing all the reserved bits.  This is 
because there is currently no way to signal a failure.


When I fix the toolstack interface, the toolstack will propose a new 
CPUID policy, and Xen will have a function to check it against the 
architectural requirements.  At that point, we will be applying checks, 
but not modifying the contents.



+
+if ( hide_epc )
+{
+memset(>sgx.raw[0x2], 0, sizeof (struct cpuid_leaf));
+}
+}
+
  /*
   * Misc adjustments to the policy.  Mostly clobbering reserved fields and
   * duplicating shared fields.  Intentionally hidden fields are annotated.
@@ -239,7 +278,7 @@ static void __init calculate_raw_policy(void)
  {
  switch ( i )
  {
-case 0x4: case 0x7: case 0xd:
+case 0x4: case 0x7: case 0xd: case 0x12:
  /* Multi-invocation leaves.  Deferred. */
  continue;
  }
@@ -299,6 +338,19 @@ static void __init calculate_raw_policy(void)
  }
  }
  
+if ( p->basic.max_leaf >= SGX_CPUID )

+{
+/*
+ * For raw policy we just report native CPUID. For EPC on native it's
+ * possible that we will have multiple EPC sections (meaning subleaf 3,
+ * 4, ... may also be valid), but as the policy is for guest so we only
+ * need one EPC section (subleaf 2).
+ */
+cpuid_count_leaf(SGX_CPUID, 0, >sgx.raw[0]);
+cpuid_count_leaf(SGX_CPUID, 0, >sgx.raw[0]);
+cpuid_count_leaf(SGX_CPUID, 0, >sgx.raw[0]);


Copy & paste error?  I presume you meant to use leaves 1 and 2 here, 
rather than leaf 0 each time?



+}
+
  /* Extended leaves. */
  cpuid_leaf(0x8000, >extd.raw[0]);
  for ( i = 1; i < min(ARRAY_SIZE(p->extd.raw),
@@ -324,6 +376,8 @@ static void __init calculate_host_policy(void)
  cpuid_featureset_to_policy(boot_cpu_data.x86_capability, p);
  recalculate_xstate(p);
  recalculate_misc(p);
+/* For host policy we report physical EPC */
+

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

[Wei Liu]

On Thu, Jul 13, 2017 at 10:03:39AM +0800, Xiong Zhang wrote:
> When valid mmio_hole is set in hvm.cfg, segment fault happens at accessing
> localents pointer.
> 
> Because the size of localents pointer isn't enough to store appended
> mmio_hole_size parameter.
> 
> Signed-off-by: Xiong Zhang 

Acked-by: Wei Liu 

Ian please backport this.

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

Re: [Xen-devel] [PATCH v3 04/11] libxl: add generic function to add device

[Wei Liu]

On Mon, Jul 10, 2017 at 03:41:28PM +0300, Oleksandr Grytsov wrote:
> On Fri, Jul 7, 2017 at 1:56 PM, Oleksandr Grytsov  wrote:
> > On Fri, Jul 7, 2017 at 1:32 PM, Wei Liu  wrote:
> >> On Fri, Jul 07, 2017 at 01:29:39PM +0300, Oleksandr Grytsov wrote:
> >>  > Actually my the first patch probably was done on the old codebase
> >>> > which doesn't have locking in add function. So new approach is
> >>> > definitely wrong and I will use former one.
> >>>
> >>> Please ignore my above comment. Actually it looks like my new approach
> >>> changes former behavior. I will rework this function to match former one.
> >>>
> >>> Actually new approach
> >>
> >> Hit "Send" too soon?
> >
> > Just forgot to remove this line. So, I will rework this part.
> >
> 
> Few questions about former implementation (I address vtpm as reference
> but questions are related to all devices):
> 
> 1. Using of libxl_device_vtpm vtpm_saved variable. It is unclear why
> we need this additional variable.
> There is no any rollback or cancellation with this variable.
> It is used to be added to the domain config but vtpm from input
> parameter can be used for this reason as well.

The vtpm_saved variable is a copy of the structure passed in by the caller.

We then pass vtpm to the _setdefault function which touches some of the
fields inside.

But then not all the fields changed by the _setdefault function need to
be written to our persistent domain configuration on disk. The fields we
care about are copied back  to vtpm_saved by libxl__update_config_vtpm.
Then we save vtpm_saved.

For your particular device, you should provide a similar update_config
function.

> 
> 2. Why libxl__update_config_vtpm(gc, _saved, vtpm); is called if
> just before we copied
> vtpm_saved from vtpm?
> 
> libxl_device_vtpm_init(_saved);
> libxl_device_vtpm_copy(CTX, _saved, vtpm);
> 
> I see that dev id is updated but it could be done before copy operation.
> 

But for different device type there are different things to save. Vtpm
is a bit more of a simplistic one. See also other update_config
function.

The code structure is deliberated. It is a pattern applicable for all
devices --  the implementer can easily follow the pattern.

> 3. What is reason to call libxl__set_domain_configuration(gc, domid,
> _config); in each
> xen store transaction attempt?
> 

That would ensure the eventual consistency of the file written on disk
and the content in xenstore.

Keep in mind that there could be several threads competing with each
other to manipulate both the file on disk and xenstore.

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

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

[Xiong Zhang]

When valid mmio_hole is set in hvm.cfg, segment fault happens at accessing
localents pointer.

Because the size of localents pointer isn't enough to store appended
mmio_hole_size parameter.

Signed-off-by: Xiong Zhang 
---
 tools/libxl/libxl_create.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index bffbc45..1158303 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -451,7 +451,7 @@ int libxl__domain_build(libxl__gc *gc,
 vments[4] = "start_time";
 vments[5] = GCSPRINTF("%lu.%02d", 
start_time.tv_sec,(int)start_time.tv_usec/1);
 
-localents = libxl__calloc(gc, 9, sizeof(char *));
+localents = libxl__calloc(gc, 11, sizeof(char *));
 i = 0;
 localents[i++] = "platform/acpi";
 localents[i++] = libxl__acpi_defbool_val(info) ? "1" : "0";
-- 
2.7.4


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

[Xen-devel] [qemu-mainline test] 111703: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 16 debian-install/dst_host  fail REGR. vs. 111403
 test-armhf-armhf-xl 16 guest-start/debian.repeat fail REGR. vs. 111403
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 111403

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 111379
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111403
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111403
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111403
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111403
 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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-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-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 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-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-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:
 qemuuaa916e409c04cb614ec2fee8b6b33836bf5998bb
baseline version:
 qemuu2185c93ba80f81bfa27ce6f259c7f2ef4f08b668

Last test of basis   111403  2017-07-05 10:31:25 Z6 days
Failing since111475  2017-07-06 11:14:43 Z5 days8 attempts
Testing same since   111703  2017-07-11 22:26:01 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 
  

Re: [Xen-devel] [PATCH v3 03/11] libxl: add generic function to get and free device list

[Wei Liu]

On Mon, Jul 10, 2017 at 03:26:12PM +0300, Oleksandr Grytsov wrote:
> It means for each device where getting device list is required there will be
> GC_INIT(ctc)
> 
> libxl__device_list(gc, ...)
> 
> GC_FREE
> 
> instead of just:
> 
> libxl__device_list(ctx, ...);

I think this is worth it because we might need to use the
libl__device_list function internally.

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

Re: [Xen-devel] [PATCH v3 03/11] libxl: add generic function to get and free device list

[Wei Liu]

On Mon, Jul 10, 2017 at 03:22:19PM +0300, Oleksandr Grytsov wrote:
> On Thu, Jul 6, 2017 at 6:29 PM, Wei Liu  wrote:
> > On Tue, Jun 27, 2017 at 01:03:19PM +0300, Oleksandr Grytsov wrote:
> >> From: Oleksandr Grytsov 
> >>
> >> Add libxl__device_list, libxl__device_list_free.
> >> Device list is created from libxl xen store entries.
> >> In order to fill libxl device structure from xen store,
> >> the device handling framework extended with from_xenstore callback.
> >> On this callback libxl_device shall be filled with data from
> >> be xen store directory.
> >>
> >> Signed-off-by: Oleksandr Grytsov 
> >> ---
> >>  tools/libxl/libxl_device.c   | 76 
> >> 
> >>  tools/libxl/libxl_internal.h |  8 +
> >>  tools/libxl/libxl_vdispl.c   | 17 --
> >>  3 files changed, 98 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> >> index 00356af..8bcfa2b 100644
> >> --- a/tools/libxl/libxl_device.c
> >> +++ b/tools/libxl/libxl_device.c
> >> @@ -1793,6 +1793,82 @@ out:
> >>  return AO_CREATE_FAIL(rc);
> >>  }
> >>
> >> +void* libxl__device_list(const struct libxl_device_type *dt,
> >> + libxl_ctx *ctx, uint32_t domid, int *num)
> >
> > It should probably take a libxl__gc *gc here.
> >
> >> +{
> >> +GC_INIT(ctx);
> >> +
> >
> > And omit the GC_INIT and GC_FREE.
> >
> 
> In this case I should move GC_INIT and GC_FREE to above function:
> 
> libxl_device_vdispl_list(libxl_ctx *ctx, uint32_t domid, int *num)
> {
>  GC_INIT(ctx);
> 

Yes that's what I meant.

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

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

[Wei Liu]

On Wed, Jul 12, 2017 at 11:43:42AM +0300, Petre Pircalabu wrote:
> If case of a vm_event with the emulate_flags set, if the instruction
> cannot be emulated, the monitor should be notified instead of directly
> injecting a hw exception.
> This behavior can be used to re-execute an instruction not supported by
> the emulator using the real processor (e.g. altp2m) instead of just
> crashing.
> 
> Signed-off-by: Petre Pircalabu 
> 
> ---
> Changed since v1:
>   * Removed the emulation kind check when calling hvm_inject_hw_exception
> 
> Changed since v2:
>   * Removed a file added by mistake
> ---
>  tools/libxc/include/xenctrl.h |  2 ++
>  tools/libxc/xc_monitor.c  | 14 ++

Acked-by: Wei Liu 

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

[Xen-devel] [xen-unstable-coverity test] 111727: regressions - ALL FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 coverity-amd646 coverity-build   fail REGR. vs. 40

version targeted for testing:
 xen  89df98b77d28136c4d7aade13a1c8bc154d2919f
baseline version:
 xen  8b9793bfe614ee53029d2b1672e1080170809dcd

Last test of basis   40  2017-06-28 10:06:03 Z   13 days
Failing since111315  2017-07-02 09:22:26 Z   10 days4 attempts
Testing same since   111597  2017-07-09 09:18:43 Z3 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chao Gao 
  Dongli Zhang 
  Haozhong Zhang 
  Igor Druzhinin 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Marek Marczykowski-Górecki 
  Razvan Cojocaru 
  Sergey Dyasli 
  Stefano Stabellini 
  Thomas Sanders 
  Tim Deegan 
  Wei Liu 
  Xiong Zhang 
  Zhongze Liu 

jobs:
 coverity-amd64   fail



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

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

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

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


Not pushing.

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

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

[Xen-devel] [distros-debian-squeeze test] 71683: regressions - trouble: broken/fail/pass

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-i386-squeeze-netboot-pygrub  7 xen-boot  fail REGR. vs. 71643

Tests which did not succeed, but are not blocking:
 build-arm64-pvops 2 hosts-allocate   broken like 71643
 build-arm64   2 hosts-allocate   broken like 71643
 build-arm64-pvops 3 capture-logs broken like 71643
 build-arm64   3 capture-logs broken like 71643
 test-amd64-i386-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 
71643
 test-amd64-i386-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 
71643
 test-amd64-amd64-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 
71643

baseline version:
 flight   71643

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-squeeze-netboot-pygrubfail
 test-amd64-i386-amd64-squeeze-netboot-pygrub fail
 test-amd64-amd64-i386-squeeze-netboot-pygrub fail
 test-amd64-i386-i386-squeeze-netboot-pygrub  fail



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

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

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


Push not applicable.


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

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

[Petre Ovidiu PIRCALABU]

Hi Tamas,

I have corrected it and resent the patch. 

Thank-you very much for pointing it out,
Petre

On Ma, 2017-07-11 at 23:41 -0600, Tamas K Lengyel wrote:
> On Tue, Jul 11, 2017 at 8:53 AM, Petre Pircalabu
>  wrote:
> > 
> > If case of a vm_event with the emulate_flags set, if the
> > instruction
> > cannot be emulated, the monitor should be notified instead of
> > directly
> > injecting a hw exception.
> > This behavior can be used to re-execute an instruction not
> > supported by
> > the emulator using the real processor (e.g. altp2m) instead of just
> > crashing.
> > 
> > Signed-off-by: Petre Pircalabu 
> > 
> > ---
> > Changed since v1:
> >   * Removed the emulation kind check when calling
> > hvm_inject_hw_exception
> > ---
> >  tools/libxc/include/xenctrl.h  |   2 +
> >  tools/libxc/xc_monitor.c   |  14 ++
> >  ...itor-Notify-monitor-if-an-emulation-fails.patch | 212
> > +
> >  xen/arch/x86/hvm/emulate.c |   5 +-
> >  xen/arch/x86/hvm/monitor.c |  19 ++
> >  xen/arch/x86/monitor.c |  12 ++
> >  xen/include/asm-x86/domain.h   |   1 +
> >  xen/include/asm-x86/hvm/monitor.h  |   1 +
> >  xen/include/asm-x86/monitor.h  |   3 +-
> >  xen/include/public/domctl.h|   1 +
> >  xen/include/public/vm_event.h  |   2 +
> >  11 files changed, 270 insertions(+), 2 deletions(-)
> >  create mode 100644 tools/tests/xen-access/0001-x86-monitor-Notify-
> > monitor-if-an-emulation-fails.patch
> I don't think you meant to add this patch file.
> 
> Tamas
> 
> 
> This email was scanned by Bitdefender
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Petre Pircalabu]

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

Signed-off-by: Petre Pircalabu 

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

Changed since v2:
  * Removed a file added by mistake
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_monitor.c  | 14 ++
 xen/arch/x86/hvm/emulate.c|  5 -
 xen/arch/x86/hvm/monitor.c| 19 +++
 xen/arch/x86/monitor.c| 12 
 xen/include/asm-x86/domain.h  |  1 +
 xen/include/asm-x86/hvm/monitor.h |  1 +
 xen/include/asm-x86/monitor.h |  3 ++-
 xen/include/public/domctl.h   |  1 +
 xen/include/public/vm_event.h |  2 ++
 10 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c51bb3b..8deb5ac 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2029,6 +2029,8 @@ int xc_monitor_debug_exceptions(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
 int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
bool enable);
+int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
+ bool enable);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b44ce93..8e72c6c 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -216,6 +216,20 @@ int xc_monitor_privileged_call(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, );
 }
 
+int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
+ bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE;
+
+return do_domctl(xch, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index e97aa69..f52aa87 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -14,12 +14,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2101,7 +2103,8 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
 return;
 case X86EMUL_UNHANDLEABLE:
 hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", );
-hvm_inject_hw_exception(trapnr, errcode);
+if ( !hvm_monitor_emul_unhandleable() )
+hvm_inject_hw_exception(trapnr, errcode);
 break;
 case X86EMUL_EXCEPTION:
 hvm_inject_event();
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index a7ccfc4..02e0ba5 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -57,6 +57,25 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
value, unsigned long old
 return 0;
 }
 
+
+bool hvm_monitor_emul_unhandleable(void)
+{
+struct vcpu *curr = current;
+struct domain *d = curr->domain;
+
+/*
+ * Send a vm_event to the monitor to signal that the current
+ * instruction couldn't be emulated.
+ */
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_EMUL_UNHANDLEABLE,
+.vcpu_id  = curr->vcpu_id,
+};
+
+return ( d->arch.monitor.emul_unhandleable &&
+ monitor_traps(curr, true, ) );
+}
+
 void hvm_monitor_msr(unsigned int msr, uint64_t value)
 {
 struct vcpu *curr = current;
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 706454f..51252fe 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -283,6 +283,18 @@ int arch_monitor_domctl_event(struct domain *d,
 break;
 }
 
+case XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE:
+{
+bool old_status = ad->monitor.emul_unhandleable;
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;
+
+domain_pause(d);
+ad->monitor.emul_unhandleable = requested_status;
+domain_unpause(d);
+break;
+}
+
 default:
 /*
  * Should not be reached unless arch_monitor_get_capabilities() is
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index c10522b..7f3b54c 100644
--- a/xen/include/asm-x86/domain.h
+++ 

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

[osstest service owner]

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

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 111706
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 111614 pass in 
111523
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 111673 
pass in 111706
 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 111614
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
111673
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail pass in 111673

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 16 guest-localmigrate/x10 fail in 111614 
like 110441
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111614 
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-amd64-xl-qemut-ws16-amd64 10 windows-installfail 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-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
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   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-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 

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

[Dou Liyang]

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?


-boris




Best regards,
Lu Baolu


-boris



Cc: Ingo Molnar 
Cc: x...@kernel.org
Signed-off-by: Lu Baolu 
---
 arch/x86/kernel/setup.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4bf0c89..e70204e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned 
long v, void *p)
return 0;
 }

+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 it returns here,  can we use udelay() correctly like before?

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









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

Re: [Xen-devel] [PATCH] xen/pvcalls: NULL dereference in error handling

[Stefano Stabellini]

On Wed, 12 Jul 2017, Dan Carpenter wrote:
> We accidentally dereference "map" when it's NULL.
> 
> Fixes: b535e2b9b78a ("xen/pvcalls: implement connect command")
> Signed-off-by: Dan Carpenter 

Thanks!

Reviewed-by: Stefano Stabellini 


> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> index d6c4c4aecb41..01b690e1e555 100644
> --- a/drivers/xen/pvcalls-back.c
> +++ b/drivers/xen/pvcalls-back.c
> @@ -424,7 +424,7 @@ static int pvcalls_back_connect(struct xenbus_device *dev,
>   sock);
>   if (!map) {
>   ret = -EFAULT;
> - sock_release(map->sock);
> + sock_release(sock);
>   }
>  
>  out:
> 

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

Re: [Xen-devel] [PATCH 5/25] Xen/doc: Add Xen virtual IOMMU doc

[Julien Grall]

Hi,

On 07/12/2017 04:09 AM, Lan Tianyu wrote:

On 2017年07月08日 00:08, Julien Grall wrote:

Because we now just have onE vIOMMU, all virtual interrupt will be bound
to it. If need to support mult-vIOMMU, we can add device-scope
field(sbdf array or some thing like that) in the structure and specify
what devices should be under one vIOMMU.


I am not sure to follow the argument here. Even if you have only one
vIOMMU you need to be able to do the correspondence between the virtual
MasterID (for PCI it is based on the RID) and the host MasterID.




  Sorry for later response.
  MasterID you mentioned here is sbdf, right? Binding between sbdf
and vsbdf(virtual sbdf) should be in the device pass through related
interface(e.g, xc_domain_bind_pt_irq_int() has already done such similar
thing that bind vsbdf with real interrupt of hypervisor.).


The MasterID is not the sbdf. It is an identifier based on the tuple 
(Hostbridge, Requester ID). The RequesterID (RID), might be the bdf of 
the device or something different if there is DMA aliases.


The relation between MasterID and the tuple is defined by the hardware 
and will be reported by the firmware tables.



  vIOMMU device model can get vsbdf when guest configure vIOMMU entry
and hypervisor can do conversion between sbdf and vsbdf. For interrupt
remapping on virtual VTD, we don't find such requirement so far and got
enough data from IOAPIC/MSI entry and interrupt remapping entry of
virtual VTD. So we don't extend pass through interface.


Well, you have to think how this could be extended in the future. This 
is quite important to plan head for stable ABI. Thankfully, you seem to 
use DOMCTL, so I guess we don't have to worry too much...


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH] xen/pvcalls: NULL dereference in error handling

[Dan Carpenter]

We accidentally dereference "map" when it's NULL.

Fixes: b535e2b9b78a ("xen/pvcalls: implement connect command")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index d6c4c4aecb41..01b690e1e555 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -424,7 +424,7 @@ static int pvcalls_back_connect(struct xenbus_device *dev,
sock);
if (!map) {
ret = -EFAULT;
-   sock_release(map->sock);
+   sock_release(sock);
}
 
 out:

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

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

[osstest service owner]

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

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

Last test of basis   111704  2017-07-11 22:49:23 Z0 days
Testing same since   111715  2017-07-12 03:10:33 Z0 days1 attempts


People who touched revisions under test:
  Eric Dong 

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=b1fe2029fa2f473922fb830a2e33c5ae0c0ae20d
+ . ./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 
b1fe2029fa2f473922fb830a2e33c5ae0c0ae20d
+ branch=ovmf
+ revision=b1fe2029fa2f473922fb830a2e33c5ae0c0ae20d
+ . ./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
+ '[' xb1fe2029fa2f473922fb830a2e33c5ae0c0ae20d = 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
++ : 

Re: [Xen-devel] [PATCH 04/15] xen: mm: add ioremap_cache

[Julien Grall]

On 07/12/2017 02:52 AM, Huang, Kai wrote:

Hi Julien,


Hello Kai,

Please avoid top-posting.



Thanks for pointing out. I'll move to x86 specific.

I've cc-ed all maintainers reported by ./scripts/get_maintainer.pl, 
looks this script doesn't report all maintainers. Sorry. I'll add ARM 
maintainers next time. 


I would always double check the result of scripts/get_maintainer.pl. I 
am aware of a bug in scripts/get_maintainers.pl where only maintainer of 
the specific component (here x86) are listed, even when you touch common 
code.


In this case, I didn't ask to CC ARM maintainers, but CC "THE REST" 
group (see MAINTAINERS).


Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-cubietruck  6 xen-installfail in 111664 pass in 111693
 test-armhf-armhf-xl-xsm   7 xen-boot fail in 111664 pass in 111693
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 111664 pass in 
111693
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
in 111664 pass in 111693
 test-armhf-armhf-xl-rtds 12 guest-startfail pass in 111664

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 111664 
like 111534
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 111664 like 
111534
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 111664 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 111664 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 111389
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 111506
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 111506
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111534
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111534
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111534
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111534
 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-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-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-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   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-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  89df98b77d28136c4d7aade13a1c8bc154d2919f
baseline version:
 xen   

Re: [Xen-devel] [PATCH v9 1/7] x86/domctl: generalize the restore of vMCE parameters

[Jan Beulich]

>>> Haozhong Zhang  07/12/17 4:05 AM >>>
>+static int vcpu_set_vmce(struct vcpu *v,
>+ const struct xen_domctl_ext_vcpucontext *evc)
>+{
>+/*
>+ * Sizes of vMCE parameters used by the current and past versions
>+ * of Xen in descending order. If vMCE parameters are extended,
>+ * remember to add the old size to this array by VMCE_SIZE().
>+ */
>+#define VMCE_SIZE(field) \
>+(offsetof(typeof(evc->vmce), field) + sizeof(evc->vmce.field))
>+
>+static const unsigned int valid_sizes[] = {
>+sizeof(evc->vmce),
>+VMCE_SIZE(caps),
>+};
>+#undef VMCE_SIZE
>+
>+struct hvm_vmce_vcpu vmce = { };
>+unsigned int evc_vmce_size =
>+min(evc->size - offsetof(typeof(*evc), mcg_cap), sizeof(evc->vmce));

I should have noticed this earlier, and I'll try to remember to adjust this 
while
committing: Instead of mcg_cap we really should be using vmce here, as the
former is there solely for backward compatibility purposes (which this
expression doesn't relate to directly).

Jan


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

Re: [Xen-devel] [PATCH 04/15] xen: mm: add ioremap_cache

[Jan Beulich]

>>> Julien Grall  07/11/17 10:15 PM >>>
>On 07/09/2017 09:10 AM, Kai Huang wrote:
>> Currently Xen only has non-cacheable version of ioremap. Although EPC is
>> reported as reserved memory in e820 but it can be mapped as cacheable. This
>> patch adds ioremap_cache (cacheable version of ioremap).
>> 
>> Signed-off-by: Kai Huang 
>> ---
>>   xen/arch/x86/mm.c  | 15 +--
>>   xen/include/xen/vmap.h |  1 +
>
>First of all, this is common code and the "REST" maintainers should have 
>been CCed for this include.
>
>But xen/include/xen/vmap.h is common code and going to break ARM. We 
>already have an inline implementation of ioremap_nocache. You should 
>move the definition in x86 specific headers.

Indeed, plus the ARM implementation actually shows how this would better
be done: Have a function allowing more than just true/false to be passed in,
to eventually also allow having ioremap_wc() and alike as wrappers. As long
as it's x86-specific I'd then also suggest calling the new wrapper function
ioremap_wb() (as "cache" may also mean WT).

Jan


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

Re: [Xen-devel] Notes on stubdoms and latency on ARM

[Dario Faggioli]

On Fri, 2017-07-07 at 14:12 -0700, Stefano Stabellini wrote:
> On Fri, 7 Jul 2017, Volodymyr Babchuk wrote:
> > > > 
> > > Since you are using Credit, can you try to disable context switch
> > > rate
> > > limiting?
> >
> > Yep. You are right. In the environment described above (Case 2) I
> > now
> > get much better results:
> > 
> >  real 1.85
> > user 0.00
> > sys 1.85
> 
> From 113 to 1.85 -- WOW!
> 
> Obviously I am no scheduler expert, but shouldn't we advertise a bit
> better a scheduler configuration option that makes things _one
> hundred
> times faster_ ?! 
>
So, to be fair, so far, we've bitten this hard by this only on
artificially constructed test cases, where either some extreme
assumption were made (e.g., that all the vCPUs except one always run at
100% load) or pinning was used in a weird and suboptimal way. And there
are workload where it has been verified that it helps making
performance better (poor SpecVIRT  results without it was the main
motivation having it upstream, and on by default).

That being said, I personally have never liked rate-limiting, it always
looked to me like the wrong solution.

> It's not even mentioned in
> https://wiki.xen.org/wiki/Tuning_Xen_for_Performance!
> 
Well, for sure it should be mentioned here, you're right!

> Also, it is worrying to me that there are cases were, unless the user
> tweaks the configuration, she is going to get 100x worse performance
> out
> of her system.
>
As I said, it's hard to tell in advance whether it will have a good,
bad, or really bad impact on a specific workload.

I'm starting to think, though, that it may be good to switch to having
it off by default, and then document that if the system is going into
trashing because of too frequent context switches, turning it on may
help.

I'll think about it, and see if I'll be able to run some benchmarks
with it on and off.

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

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