date:20190625

branch xen-unstable
xenbranch xen-unstable
job build-armhf
testid xen-build

Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  37677d7db39a3c250ad661d00fb7c3b59d047b1f
  Bug not present: c0a9956b32e2806a9d50ce8c651ace140f5f79f1
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/138520/


  commit 37677d7db39a3c250ad661d00fb7c3b59d047b1f
  Author: Markus Armbruster 
  Date:   Tue Jun 4 20:16:17 2019 +0200
  
  Clean up a few header guard symbols
  
  Commit 58ea30f5145 "Clean up header guards that don't match their file
  name" messed up contrib/elf2dmp/qemu_elf.h and
  tests/migration/migration-test.h.
  
  It missed target/cris/opcode-cris.h and
  tests/uefi-test-tools/UefiTestToolsPkg/Include/Guid/BiosTablesTest.h
  due to the scripts/clean-header-guards.pl bug fixed in the previous
  commit.
  
  Commit a8b991b52dc "Clean up ill-advised or unusual header guards"
  missed include/hw/xen/io/ring.h for the same reason.
  
  Commit 3979fca4b69 "disas: Rename include/disas/bfd.h back to
  include/disas/dis-asm.h" neglected to update the guard symbol for the
  rename.
  
  Commit a331c6d7741 "semihosting: implement a semihosting console"
  created include/hw/semihosting/console.h with an ill-advised guard
  symbol.
  
  Clean them up.
  
  Signed-off-by: Markus Armbruster 
  Message-Id: <20190604181618.19980-4-arm...@redhat.com>
  Reviewed-by: Philippe Mathieu-DaudÃ© 
  Tested-by: Philippe Mathieu-DaudÃ© 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/build-armhf.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/build-armhf.xen-build 
--summary-out=tmp/138520.bisection-summary --basis-template=137600 
--blessings=real,real-bisect qemu-mainline build-armhf xen-build
Searching for failure / basis pass:
 138372 fail [host=cubietruck-picasso] / 137600 ok.
Failure / basis pass flights: 138372 / 137600
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 719a684d7df1b5b5627f42447be4f12aab038343 
474f3938d79ab36b9231c9ad3b5a9314c2aeacde 
6e56ed129c9782ba050a5fbfbf4ac12335b230f7 
7d1460c991ac45cccbf9ba3d8aa137029c2bf312
Basis pass f0718d1d6b47745a4249f4006807a45f2245dba1 
a578cdfbdd8f9beff5ced52b7826ddb1669abbbf 
0932c20560574696cf87ddd12623e8c423ee821b 
844aa0a13d34e9a341a8374119d2ed67d4dcd6bb
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/osstest/ovmf.git#f0718d1d6b47745a4249f4006807a45f2245dba1-719a684d7df1b5b5627f42447be4f12aab038343
 
git://git.qemu.org/qemu.git#a578cdfbdd8f9beff5ced52b7826ddb1669abbbf-474f3938d79ab36b9231c9ad3b5a9314c2aeacde
 
git://xenbits.xen.org/osstest/seabios.git#0932c20560574696cf87ddd12623e8c423ee821b-6e56ed129c9782ba050a5fbfbf4ac12335b230f7
 
git://xenbits.xen.org/xen.git#844aa0a13d34e9a341a8374119d2ed67d4dcd6bb-7d1460c991ac45cccbf9\
 ba3d8aa137029c2bf312
Loaded 15324 nodes in revision graph
Searching for test results:
 137600 pass f0718d1d6b47745a4249f4006807a45f2245dba1 
a578cdfbdd8f9beff5ced52b7826ddb1669abbbf 
0932c20560574696cf87ddd12623e8c423ee821b 
844aa0a13d34e9a341a8374119d2ed67d4dcd6bb
 137734 [host=cubietruck-gleizes]
 137697 [host=cubietruck-gleizes]
 137930 [host=cubietruck-gleizes]
 137871 [host=cubietruck-gleizes]
 138031 [host=cubietruck-gleizes]
 138157 [host=cubietruck-gleizes]
 138258 [host=cubietruck-gleizes]
 138404 [host=cubietruck-gleizes]
 138372 fail 719a684d7df1b5b5627f42447be4f12aab038343 
474f3938d79ab36b9231c9ad3b5a9314c2aeacde 
6e56ed129c9782ba050a5fbfbf4ac12335b230f7 
7d1460c991ac45cccbf9ba3d8aa137029c2bf312
 138371 [host=cubietruck-gleizes]
 138377 [host=cubietruck-gleizes]
 138338 [host=cubietruck-gleizes]
 138391 [host=cubietruck-gleizes]
 138380 [host=cubietruck-gleizes]
 138373 [host=cubietruck-gleizes]
 138381 [host=cubietruck-gleizes]
 138387 [host=cubietruck-gleizes]
 138385 [host=cubietruck-gleizes]
 138389 [host=cubietruck-gleizes]
 138395 [host=cubietruck-gleizes]
 138481 pass 4eb0acb1e2bef27d29ed8cc6200a9963b5cb0565 
d3e3413bd6a8c0287dbad8942e208d562fd8e29e 
85137fb5f2dfa5f83e9e340ca881c634ae14d4e9 
07513e15e6e7e5163bf4f59c747825cce748531c
 138431 [host=cubietruck-gleizes]
 138470 fail 2378ea55151eef8284b4cf35e95b058b0e591ea0 
541617cad3445fdc6735e9e5752e1f698e337737 
85137fb5f2dfa5f83e9e340ca881c634ae14d4e9 
508908fd449d7b5801ec6b06e5bb263b55fc
 138514 pass

Re: [Xen-devel] PCI Passthrough bug with x86 HVM


On 26.06.19 00:10, Stefano Stabellini wrote:

On Tue, 25 Jun 2019, Juergen Gross wrote:

On 24.06.19 20:45, Stefano Stabellini wrote:

Hi all,

I might have found a bug with PCI passthrough to a Linux HVM guest on
x86 with Xen 4.12. It is not easy for me to get access, and especially
change components, on this particular system, and I don't have access to
other x86 boxes at the moment, so apologies for the partial information
report. The setup is as follow:

- two PCI devices have been assigned to a HVM guest, everything is fine
- reboot the guest from inside, i.e. `reboot' in Linux
- after the reboot completes, only one device is assigned

Before the reboot, I see all the appropriate xenstore entries for both
devices. Everything is fine. After the reboot, I can only see the
xenstore entries of one device. It is as if the other device
"disappeared" without throwing any errors.


Can you please post the Xenstore entries before the reboot?

I think the numbering scheme of PCI devices in Xenstore isn't like that
of other devices...


See attached. The domid goes from 3 to 5, because I shutdown domid 3
normally the first time around, instead of rebooting.



As I thought. Working on a patch.


Juergen

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

Re: [Xen-devel] [PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently

2019-06-25 Thread Dave Hansen

On 6/12/19 11:48 PM, Nadav Amit wrote:
> To improve TLB shootdown performance, flush the remote and local TLBs
> concurrently. Introduce flush_tlb_multi() that does so. The current
> flush_tlb_others() interface is kept, since paravirtual interfaces need
> to be adapted first before it can be removed. This is left for future
> work. In such PV environments, TLB flushes are not performed, at this
> time, concurrently.
> 
> Add a static key to tell whether this new interface is supported.
> 
> Cc: "K. Y. Srinivasan" 
> Cc: Haiyang Zhang 
> Cc: Stephen Hemminger 
> Cc: Sasha Levin 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Borislav Petkov 
> Cc: x...@kernel.org
> Cc: Juergen Gross 
> Cc: Paolo Bonzini 
> Cc: Dave Hansen 
> Cc: Andy Lutomirski 
> Cc: Peter Zijlstra 
> Cc: Boris Ostrovsky 
> Cc: linux-hyp...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: k...@vger.kernel.org
> Cc: xen-devel@lists.xenproject.org
> Signed-off-by: Nadav Amit 
> ---
>  arch/x86/hyperv/mmu.c |  2 +
>  arch/x86/include/asm/paravirt.h   |  8 +++
>  arch/x86/include/asm/paravirt_types.h |  6 +++
>  arch/x86/include/asm/tlbflush.h   |  6 +++
>  arch/x86/kernel/kvm.c |  1 +
>  arch/x86/kernel/paravirt.c|  3 ++
>  arch/x86/mm/tlb.c | 71 ++-
>  arch/x86/xen/mmu_pv.c |  2 +
>  8 files changed, 87 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
> index e65d7fe6489f..ca28b400c87c 100644
> --- a/arch/x86/hyperv/mmu.c
> +++ b/arch/x86/hyperv/mmu.c
> @@ -233,4 +233,6 @@ void hyperv_setup_mmu_ops(void)
>   pr_info("Using hypercall for remote TLB flush\n");
>   pv_ops.mmu.flush_tlb_others = hyperv_flush_tlb_others;
>   pv_ops.mmu.tlb_remove_table = tlb_remove_table;
> +
> + static_key_disable(_tlb_multi_enabled.key);
>  }
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index c25c38a05c1c..192be7254457 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -47,6 +47,8 @@ static inline void slow_down_io(void)
>  #endif
>  }
>  
> +DECLARE_STATIC_KEY_TRUE(flush_tlb_multi_enabled);
> +
>  static inline void __flush_tlb(void)
>  {
>   PVOP_VCALL0(mmu.flush_tlb_user);
> @@ -62,6 +64,12 @@ static inline void __flush_tlb_one_user(unsigned long addr)
>   PVOP_VCALL1(mmu.flush_tlb_one_user, addr);
>  }
>  
> +static inline void flush_tlb_multi(const struct cpumask *cpumask,
> +const struct flush_tlb_info *info)
> +{
> + PVOP_VCALL2(mmu.flush_tlb_multi, cpumask, info);
> +}
> +
>  static inline void flush_tlb_others(const struct cpumask *cpumask,
>   const struct flush_tlb_info *info)
>  {
> diff --git a/arch/x86/include/asm/paravirt_types.h 
> b/arch/x86/include/asm/paravirt_types.h
> index 946f8f1f1efc..b93b3d90729a 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -211,6 +211,12 @@ struct pv_mmu_ops {
>   void (*flush_tlb_user)(void);
>   void (*flush_tlb_kernel)(void);
>   void (*flush_tlb_one_user)(unsigned long addr);
> + /*
> +  * flush_tlb_multi() is the preferred interface, which is capable to
> +  * flush both local and remote CPUs.
> +  */
> + void (*flush_tlb_multi)(const struct cpumask *cpus,
> + const struct flush_tlb_info *info);
>   void (*flush_tlb_others)(const struct cpumask *cpus,
>const struct flush_tlb_info *info);
>  
> diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
> index dee375831962..79272938cf79 100644
> --- a/arch/x86/include/asm/tlbflush.h
> +++ b/arch/x86/include/asm/tlbflush.h
> @@ -569,6 +569,9 @@ static inline void flush_tlb_page(struct vm_area_struct 
> *vma, unsigned long a)
>   flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, PAGE_SHIFT, false);
>  }
>  
> +void native_flush_tlb_multi(const struct cpumask *cpumask,
> +  const struct flush_tlb_info *info);
> +
>  void native_flush_tlb_others(const struct cpumask *cpumask,
>const struct flush_tlb_info *info);
>  
> @@ -593,6 +596,9 @@ static inline void arch_tlbbatch_add_mm(struct 
> arch_tlbflush_unmap_batch *batch,
>  extern void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch);
>  
>  #ifndef CONFIG_PARAVIRT
> +#define flush_tlb_multi(mask, info)  \
> + native_flush_tlb_multi(mask, info)
> +
>  #define flush_tlb_others(mask, info) \
>   native_flush_tlb_others(mask, info)
>  
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 5169b8cc35bb..00d81e898717 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -630,6 +630,7 @@ static void __init kvm_guest_init(void)
>

Re: [Xen-devel] [PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently

2019-06-25 Thread Dave Hansen

On 6/25/19 7:35 PM, Nadav Amit wrote:
>>> const struct flush_tlb_info *f = info;
>>> +   enum tlb_flush_reason reason;
>>> +
>>> +   reason = (f->mm == NULL) ? TLB_LOCAL_SHOOTDOWN : TLB_LOCAL_MM_SHOOTDOWN;
>>
>> Should we just add the "reason" to flush_tlb_info?  It's OK-ish to imply
>> it like this, but seems like it would be nicer and easier to track down
>> the origins of these things if we did this at the caller.
> 
> I prefer not to. I want later to inline flush_tlb_info into the same
> cacheline that holds call_function_data. Increasing the size of
> flush_tlb_info for no good reason will not help…

Well, flush_tlb_info is at 6/8ths of a cacheline at the moment.
call_function_data is 3/8ths.  To me, that means we have some slack in
the size.


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

[Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm

branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build

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:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  b41666f2c17f01c437c870389ab713ee62ae3526
  Bug not present: 85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/138530/


  commit b41666f2c17f01c437c870389ab713ee62ae3526
  Author: Roger Pau MonnÃ© 
  Date:   Tue Jun 25 15:39:44 2019 +0200
  
  config: don't hardcode toolchain binaries
  
  Currently the names of the build toolchain binaries are hardcoded in
  StdGNU.mk, and the values from the environment are ignored.
  
  Switch StdGNU.mk to use '?=' instead of '=', so that values from the
  environment are used if present, else default to the values provided
  by the config file.
  
  This change fixes the gitlab CI loop, that was relying on passing
  custom values in the environment variables for the compiler and the
  linker.
  
  Signed-off-by: Roger Pau MonnÃ© 
  Acked-by: Andrew Cooper 
  Acked-by: Ian Jackson 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build
 --summary-out=tmp/138530.bisection-summary --basis-template=138424 
--blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
 138519 fail [host=laxton1] / 138424 [host=laxton0] 138355 [host=laxton0] 
138347 [host=rochester1] 138342 ok.
Failure / basis pass flights: 138519 / 138342
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Basis pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
11911563610786615c2b3a01cdcaaf09a6f9e38d
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-9cca02d8ffc23e9688a971d858e4ffdff5389b11
 
git://xenbits.xen.org/xen.git#11911563610786615c2b3a01cdcaaf09a6f9e38d-1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Loaded 1001 nodes in revision graph
Searching for test results:
 138262 [host=rochester1]
 138257 [host=rochester1]
 138242 [host=rochester1]
 138268 [host=rochester0]
 138271 [host=rochester1]
 138277 [host=rochester0]
 138294 [host=rochester0]
 138295 [host=rochester0]
 138302 [host=rochester0]
 138355 [host=laxton0]
 138328 [host=rochester0]
 138317 [host=laxton0]
 138347 [host=rochester1]
 138342 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
11911563610786615c2b3a01cdcaaf09a6f9e38d
 138424 [host=laxton0]
 138493 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138482 [host=rochester0]
 138489 [host=rochester1]
 138485 [host=rochester0]
 138497 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138501 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138505 [host=rochester1]
 138510 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138517 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138519 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138522 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
11911563610786615c2b3a01cdcaaf09a6f9e38d
 138523 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
 138524 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
560cf418c8455cd8d79ad353f6f9193a2e2554e4
 138525 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
 138526 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
b41666f2c17f01c437c870389ab713ee62ae3526
 138527 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
 138528 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
b41666f2c17f01c437c870389ab713ee62ae3526
 138529 pass 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
 138530 fail 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
b41666f2c17f01c437c870389ab713ee62ae3526
Searching for interesting versions
 Result found: flight 138342 (pass), for basis pass
 Result found: flight 138493 (fail), for basis failure
 Repro found: flight 138522 (pass), for basis pass
 Repro found: flight 138523 (fail), for basis failure
 0 revisions at 9cca02d8ffc23e9688a971d858e4ffdff5389b11 
85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
No revisions left to test, checking graph state.
 Result found:

Re: [Xen-devel] [PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently

2019-06-25 Thread Andy Lutomirski

On Tue, Jun 25, 2019 at 8:48 PM Nadav Amit  wrote:
>
> > On Jun 25, 2019, at 8:36 PM, Andy Lutomirski  wrote:
> >
> > On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit  wrote:
> >> To improve TLB shootdown performance, flush the remote and local TLBs
> >> concurrently. Introduce flush_tlb_multi() that does so. The current
> >> flush_tlb_others() interface is kept, since paravirtual interfaces need
> >> to be adapted first before it can be removed. This is left for future
> >> work. In such PV environments, TLB flushes are not performed, at this
> >> time, concurrently.
> >
> > Would it be straightforward to have a default PV flush_tlb_multi()
> > that uses flush_tlb_others() under the hood?
>
> I prefer not to have a default PV implementation that should anyhow go away.
>
> I can create unoptimized untested versions for Xen and Hyper-V, if you want.
>

I think I prefer that approach.  We should be able to get the
maintainers to test it.  I don't love having legacy paths in there,
ahem, UV.

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

Re: [Xen-devel] [PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently

2019-06-25 Thread Nadav Amit

> On Jun 25, 2019, at 8:36 PM, Andy Lutomirski  wrote:
> 
> On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit  wrote:
>> To improve TLB shootdown performance, flush the remote and local TLBs
>> concurrently. Introduce flush_tlb_multi() that does so. The current
>> flush_tlb_others() interface is kept, since paravirtual interfaces need
>> to be adapted first before it can be removed. This is left for future
>> work. In such PV environments, TLB flushes are not performed, at this
>> time, concurrently.
> 
> Would it be straightforward to have a default PV flush_tlb_multi()
> that uses flush_tlb_others() under the hood?

I prefer not to have a default PV implementation that should anyhow go away.

I can create unoptimized untested versions for Xen and Hyper-V, if you want.


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

Re: [Xen-devel] [PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently

2019-06-25 Thread Andy Lutomirski

On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit  wrote:
>
> To improve TLB shootdown performance, flush the remote and local TLBs
> concurrently. Introduce flush_tlb_multi() that does so. The current
> flush_tlb_others() interface is kept, since paravirtual interfaces need
> to be adapted first before it can be removed. This is left for future
> work. In such PV environments, TLB flushes are not performed, at this
> time, concurrently.

Would it be straightforward to have a default PV flush_tlb_multi()
that uses flush_tlb_others() under the hood?

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

Re: [Xen-devel] [PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently

2019-06-25 Thread Nadav Amit

> On Jun 25, 2019, at 8:00 PM, Dave Hansen  wrote:
> 
> On 6/25/19 7:35 PM, Nadav Amit wrote:
 const struct flush_tlb_info *f = info;
 +  enum tlb_flush_reason reason;
 +
 +  reason = (f->mm == NULL) ? TLB_LOCAL_SHOOTDOWN : TLB_LOCAL_MM_SHOOTDOWN;
>>> 
>>> Should we just add the "reason" to flush_tlb_info?  It's OK-ish to imply
>>> it like this, but seems like it would be nicer and easier to track down
>>> the origins of these things if we did this at the caller.
>> 
>> I prefer not to. I want later to inline flush_tlb_info into the same
>> cacheline that holds call_function_data. Increasing the size of
>> flush_tlb_info for no good reason will not help…
> 
> Well, flush_tlb_info is at 6/8ths of a cacheline at the moment.
> call_function_data is 3/8ths.  To me, that means we have some slack in
> the size.

I do not understand your math.. :(

6 + 3 > 8 so putting both flush_tlb_info and call_function_data does not
leave us any slack (we can save one qword, so we can actually put them
at the same cacheline).

You can see my current implementation here:

https://lore.kernel.org/lkml/20190531063645.4697-4-na...@vmware.com/T/#m0ab5fe0799ba9ff0d41197f1095679fe26aebd57
https://lore.kernel.org/lkml/20190531063645.4697-4-na...@vmware.com/T/#m7b35a93dffd23fbb7ca813c795a0777d4cdcb51b

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

[Xen-devel] [xen-unstable-smoke test] 138519: regressions - trouble: blocked/fail

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days   10 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days9 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich

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

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux72f67fd749dba12f6412b8d57e680b435c3f284a
baseline version:
 linuxf4e2dd989e87a5982ae52bf5dc150287da8d729b

Last test of basis   138023  2019-06-19 13:45:18 Z6 days
Testing same since   138284  2019-06-22 06:40:58 Z3 days2 attempts

[Xen-devel] [linux-4.4 test] 138399: tolerable FAIL - PUSHED

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds  7 xen-boot fail in 138285 pass in 138399
 test-armhf-armhf-xl-vhd 10 debian-di-install fail in 138285 pass in 138399
 test-amd64-amd64-xl-qemut-ws16-amd64  7 xen-boot   fail pass in 138285
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail pass in 
138285
 test-armhf-armhf-examine  8 reboot fail pass in 138285

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

version targeted for testing:
 linux30874325504004c57f7b4f7163cead251a91662a
baseline version:
 linux33790f2eda7393d422927078597a33475792c82c

Last test of basis   138012  2019-06-19

[Xen-devel] [xen-unstable-smoke bisection] complete build-amd64

branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build

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:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
  Bug not present: e0b77cb77ef2b36b8cbd2273cff833f773208d0a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/138516/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-amd64.xen-build 
--summary-out=tmp/138521.bisection-summary --basis-template=138424 
--blessings=real,real-bisect --flight=138521 xen-unstable-smoke build-amd64 
xen-build
Searching for failure / basis pass:
 138519 fail [host=pinot0] / 138424 [host=albana0] 138355 [host=albana0] 138347 
[host=baroque1] 138342 [host=albana1] 138328 [host=chardonnay1] 138317 
[host=albana1] 138295 [host=debina1] 138277 [host=godello1] 138257 
[host=godello0] 138242 [host=baroque1] 138228 [host=albana1] 138205 
[host=godello0] 138176 [host=godello0] 138054 [host=godello1] 138039 
[host=albana1] 138020 [host=debina1] 137985 [host=godello1] 137971 
[host=chardonnay1] 137904 [host=albana0] 137888 [host=albana1] 137732 [host=al\
 bana1] 137726 [host=godello1] 137716 [host=albana0] 137683 [host=debina1] 
137679 [host=godello0] 137676 [host=godello0] 137675 [host=pinot1] 137665 
[host=godello0] 137662 [host=albana1] 137658 [host=albana1] 137643 
[host=albana1] 137587 [host=godello1] 137586 [host=elbling1] 137452 
[host=chardonnay0] 137391 [host=pinot1] 137387 [host=fiano1] 137386 
[host=italia1] 137380 [host=godello1] 137276 [host=godello1] 137263 
[host=chardonnay0] 137250 [host=albana1] 137233 [host=albana1] 137117 
[host=godel\
 lo1] 137109 [host=godello0] 137079 [host=albana1] 137072 [host=albana1] 137036 
[host=godello0] 137007 [host=godello0] 136914 [host=godello1] 136906 
[host=godello0] 136891 [host=albana1] 136860 [host=godello1] 136752 
[host=chardonnay0] 136699 [host=rimava1] 136687 [host=fiano1] 136665 
[host=albana1] 136652 [host=albana1] 136636 [host=debina1] 136633 
[host=godello1] 136618 [host=chardonnay0] 136463 [host=godello1] 136453 
[host=godello1] 136442 [host=chardonnay1] 136387 [host=pinot1] 136374 [host=g\
 odello1] 136364 [host=albana0] 136354 [host=albana0] 136343 [host=debina1] 
136330 [host=chardonnay1] 136327 [host=albana0] 136317 [host=godello1] 136309 
[host=albana0] 136304 [host=godello0] 136179 [host=albana0] 136178 
[host=elbling1] 136170 [host=debina1] 135857 [host=albana0] 135319 
[host=italia1] 135316 [host=godello0] 135310 [host=albana1] 135308 
[host=debina1] 135306 [host=fiano1] 135305 [host=godello0] 135304 
[host=chardonnay0] 135297 [host=albana0] 135294 [host=italia0] 135293 
[host=gode\
 llo0] 135285 [host=godello0] 135280 [host=debina1] 135277 [host=godello0] 
135272 [host=godello0] 135267 [host=rimava1] 135252 [host=italia1] 135245 
[host=baroque0] 135228 [host=baroque0] 135215 [host=godello0] 135211 
[host=baroque0] 135204 [host=rimava1] 135198 [host=chardonnay1] 135183 
[host=chardonnay0] 135173 [host=chardonnay1] 135168 [host=pinot1] 135163 
[host=italia1] 135158 [host=debina1] 135155 [host=debina1] 135143 
[host=debina1] 135128 [host=godello1] 135118 [host=italia1] 135103 [host=\
 godello0] 135096 [host=baroque0] 135080 [host=italia0] 135075 [host=albana1] 
135071 [host=chardonnay1] 135062 [host=fiano1] 135052 [host=italia0] 135045 
[host=baroque0] 135039 [host=pinot1] 135033 [host=italia0] 135028 
[host=italia0] 135025 [host=pinot1] 135022 [host=godello1] 135018 
[host=baroque0] 135016 [host=godello1] 135013 [host=baroque0] 135009 
[host=debina1] 135007 [host=godello1] 135001 [host=debina1] 134995 
[host=albana0] 134992 [host=baroque0] 134988 [host=debina1] 134986 [host=albana\
 1] 134983 [host=debina1] 134980 [host=debina1] 134973 [host=baroque0] 134969 
[host=godello1] 134966 [host=italia1] 134959 [host=italia1] 134952 
[host=elbling1] 134945 [host=albana1] 134937 [host=albana1] 134936 
[host=albana1] 134933 [host=italia0] 134928 [host=elbling1] 134924 
[host=godello0] 134916 [host=albana0] 134910 [host=italia0] 134903 
[host=chardonnay0] 134891 [host=albana1] 134882 [host=debina1] 134869 
[host=albana1] 134863 [host=baroque0] 134858 [host=fiano1] 134850 
[host=baroque0] 134\
 843 [host=godello0] 134838 [host=rimava1] 134834 [host=albana1] 133991 
[host=albana0] 133988 [host=godello0] 133977 [host=albana0] 133948 
[host=godello0] 133927 [host=godello0] 133911 [host=godello0] 133907 
[host=merlot0] 133900 [host=albana0] 133841 [host=albana0] 133837 
[host=chardonnay1] 133836 [host=godello0] 133804 [host=godello0] 133802

Re: [Xen-devel] [PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently

2019-06-25 Thread Nadav Amit

> On Jun 25, 2019, at 2:29 PM, Dave Hansen  wrote:
> 
> On 6/12/19 11:48 PM, Nadav Amit wrote:
>> To improve TLB shootdown performance, flush the remote and local TLBs
>> concurrently. Introduce flush_tlb_multi() that does so. The current
>> flush_tlb_others() interface is kept, since paravirtual interfaces need
>> to be adapted first before it can be removed. This is left for future
>> work. In such PV environments, TLB flushes are not performed, at this
>> time, concurrently.
>> 
>> Add a static key to tell whether this new interface is supported.
>> 
>> Cc: "K. Y. Srinivasan" 
>> Cc: Haiyang Zhang 
>> Cc: Stephen Hemminger 
>> Cc: Sasha Levin 
>> Cc: Thomas Gleixner 
>> Cc: Ingo Molnar 
>> Cc: Borislav Petkov 
>> Cc: x...@kernel.org
>> Cc: Juergen Gross 
>> Cc: Paolo Bonzini 
>> Cc: Dave Hansen 
>> Cc: Andy Lutomirski 
>> Cc: Peter Zijlstra 
>> Cc: Boris Ostrovsky 
>> Cc: linux-hyp...@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org
>> Cc: virtualizat...@lists.linux-foundation.org
>> Cc: k...@vger.kernel.org
>> Cc: xen-devel@lists.xenproject.org
>> Signed-off-by: Nadav Amit 
>> ---
>> arch/x86/hyperv/mmu.c |  2 +
>> arch/x86/include/asm/paravirt.h   |  8 +++
>> arch/x86/include/asm/paravirt_types.h |  6 +++
>> arch/x86/include/asm/tlbflush.h   |  6 +++
>> arch/x86/kernel/kvm.c |  1 +
>> arch/x86/kernel/paravirt.c|  3 ++
>> arch/x86/mm/tlb.c | 71 ++-
>> arch/x86/xen/mmu_pv.c |  2 +
>> 8 files changed, 87 insertions(+), 12 deletions(-)
>> 
>> diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
>> index e65d7fe6489f..ca28b400c87c 100644
>> --- a/arch/x86/hyperv/mmu.c
>> +++ b/arch/x86/hyperv/mmu.c
>> @@ -233,4 +233,6 @@ void hyperv_setup_mmu_ops(void)
>>  pr_info("Using hypercall for remote TLB flush\n");
>>  pv_ops.mmu.flush_tlb_others = hyperv_flush_tlb_others;
>>  pv_ops.mmu.tlb_remove_table = tlb_remove_table;
>> +
>> +static_key_disable(_tlb_multi_enabled.key);
>> }
>> diff --git a/arch/x86/include/asm/paravirt.h 
>> b/arch/x86/include/asm/paravirt.h
>> index c25c38a05c1c..192be7254457 100644
>> --- a/arch/x86/include/asm/paravirt.h
>> +++ b/arch/x86/include/asm/paravirt.h
>> @@ -47,6 +47,8 @@ static inline void slow_down_io(void)
>> #endif
>> }
>> 
>> +DECLARE_STATIC_KEY_TRUE(flush_tlb_multi_enabled);
>> +
>> static inline void __flush_tlb(void)
>> {
>>  PVOP_VCALL0(mmu.flush_tlb_user);
>> @@ -62,6 +64,12 @@ static inline void __flush_tlb_one_user(unsigned long 
>> addr)
>>  PVOP_VCALL1(mmu.flush_tlb_one_user, addr);
>> }
>> 
>> +static inline void flush_tlb_multi(const struct cpumask *cpumask,
>> +   const struct flush_tlb_info *info)
>> +{
>> +PVOP_VCALL2(mmu.flush_tlb_multi, cpumask, info);
>> +}
>> +
>> static inline void flush_tlb_others(const struct cpumask *cpumask,
>>  const struct flush_tlb_info *info)
>> {
>> diff --git a/arch/x86/include/asm/paravirt_types.h 
>> b/arch/x86/include/asm/paravirt_types.h
>> index 946f8f1f1efc..b93b3d90729a 100644
>> --- a/arch/x86/include/asm/paravirt_types.h
>> +++ b/arch/x86/include/asm/paravirt_types.h
>> @@ -211,6 +211,12 @@ struct pv_mmu_ops {
>>  void (*flush_tlb_user)(void);
>>  void (*flush_tlb_kernel)(void);
>>  void (*flush_tlb_one_user)(unsigned long addr);
>> +/*
>> + * flush_tlb_multi() is the preferred interface, which is capable to
>> + * flush both local and remote CPUs.
>> + */
>> +void (*flush_tlb_multi)(const struct cpumask *cpus,
>> +const struct flush_tlb_info *info);
>>  void (*flush_tlb_others)(const struct cpumask *cpus,
>>   const struct flush_tlb_info *info);
>> 
>> diff --git a/arch/x86/include/asm/tlbflush.h 
>> b/arch/x86/include/asm/tlbflush.h
>> index dee375831962..79272938cf79 100644
>> --- a/arch/x86/include/asm/tlbflush.h
>> +++ b/arch/x86/include/asm/tlbflush.h
>> @@ -569,6 +569,9 @@ static inline void flush_tlb_page(struct vm_area_struct 
>> *vma, unsigned long a)
>>  flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, PAGE_SHIFT, false);
>> }
>> 
>> +void native_flush_tlb_multi(const struct cpumask *cpumask,
>> + const struct flush_tlb_info *info);
>> +
>> void native_flush_tlb_others(const struct cpumask *cpumask,
>>   const struct flush_tlb_info *info);
>> 
>> @@ -593,6 +596,9 @@ static inline void arch_tlbbatch_add_mm(struct 
>> arch_tlbflush_unmap_batch *batch,
>> extern void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch);
>> 
>> #ifndef CONFIG_PARAVIRT
>> +#define flush_tlb_multi(mask, info) \
>> +native_flush_tlb_multi(mask, info)
>> +
>> #define flush_tlb_others(mask, info) \
>>  native_flush_tlb_others(mask, info)
>> 
>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>> index 5169b8cc35bb..00d81e898717 100644
>> ---

[Xen-devel] [freebsd-master test] 138419: all pass - PUSHED

flight 138419 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138419/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 freebsd  fc870a6df90c3876ec348720e21e74beb8b70d92
baseline version:
 freebsd  5b2895d685cc9e708a1fabc6acd2f25460e43526

Last test of basis   138174  2019-06-21 09:19:35 Z4 days
Testing same since   138419  2019-06-24 09:19:38 Z1 days1 attempts


People who touched revisions under test:
  ae 
  alc 
  arichardson 
  asomers 
  cy 
  dougm 
  dteske 
  emaste 
  ian 
  imp 
  johalun 
  kib 
  lwhsu 
  mav 
  rlibby 
  scottl 
  sevan 
  vangyzen 

jobs:
 build-amd64-freebsd-againpass
 build-amd64-freebsd  pass
 build-amd64-xen-freebsd  pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/freebsd.git
   5b2895d685c..fc870a6df90  fc870a6df90c3876ec348720e21e74beb8b70d92 -> 
tested/master

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

[Xen-devel] [xen-unstable-smoke test] 138517: regressions - trouble: blocked/fail

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days9 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days8 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH 12/17] xen/arm64: head: Move assembly switch to the runtime PT in secondary CPUs path

On Mon, 10 Jun 2019, Julien Grall wrote:
> The assembly switch to the runtime PT is only necessary for the
> secondary CPUs. So move the code in the secondary CPUs path.
> 
> While this is definitely not compliant with the Arm Arm as we are
> switching between two differents set of page-tables without turning off
> the MMU. Turning off the MMU is impossible here as the ID map may clash
> with other mappings in the runtime page-tables. This will require more
> rework to avoid the problem. So for now add a TODO in the code.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> ---
>  xen/arch/arm/arm64/head.S | 33 +
>  1 file changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index d673f7c0d8..6be4af7579 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -344,6 +344,23 @@ GLOBAL(init_secondary)
>  brx0
>  secondary_switched:
>  blsetup_fixmap
> +
> +/*
> + * Non-boot CPUs need to move on to the proper pagetables, which were
> + * setup in init_secondary_pagetables.
> + *
> + * XXX: This is not compliant with the Arm Arm.
> + */
> +ldr   x4, =init_ttbr /* VA of TTBR0_EL2 stashed by CPU 0 */
> +ldr   x4, [x4]   /* Actual value */
> +dsb   sy
> +msr   TTBR0_EL2, x4
> +dsb   sy
> +isb
> +tlbi  alle2
> +dsb   sy /* Ensure completion of TLB flush */
> +isb
> +
>  b launch
>  ENDPROC(init_secondary)
>  
> @@ -657,22 +674,6 @@ ENDPROC(setup_fixmap)
>  launch:
>  PRINT("- Ready -\r\n")
>  
> -/* The boot CPU should go straight into C now */
> -cbz   x22, launch
> -
> -/* Non-boot CPUs need to move on to the proper pagetables, which were
> - * setup in init_secondary_pagetables. */
> -
> -ldr   x4, =init_ttbr /* VA of TTBR0_EL2 stashed by CPU 0 */
> -ldr   x4, [x4]   /* Actual value */
> -dsb   sy
> -msr   TTBR0_EL2, x4
> -dsb   sy
> -isb
> -tlbi  alle2
> -dsb   sy /* Ensure completion of TLB flush */
> -isb
> -
>  ldr   x0, =init_data
>  add   x0, x0, #INITINFO_stack /* Find the boot-time stack */
>  ldr   x0, [x0]
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 11/17] xen/arm64: head: Document enable_mmu()

On Mon, 10 Jun 2019, Julien Grall wrote:
> Document the behavior and the main registers usage within enable_mmu().
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/head.S | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 7b92c1c8eb..d673f7c0d8 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -583,6 +583,13 @@ virtphys_clash:
>  ret
>  ENDPROC(create_page_tables)
>  
> +/*
> + * Turn on the Data Cache and the MMU. The function will return on the ID
> + * mapping. In other word, the caller is responsible to switch to the runtime
> + * mapping.
> + *
> + * Clobbers x0 - x1
> + */

as it calls PRINT, shouldn't it be x0 - x3?

>  enable_mmu:
>  PRINT("- Turning on paging -\r\n")
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 10/17] xen/arm64: head: Improve coding style and document create_pages_tables()

On Mon, 10 Jun 2019, Julien Grall wrote:
> Adjust the coding style used in the comments within create_pages_tables()
> 
> Lastly, document the behavior and the main registers usage within the
> function. Note that x25 is now only used within the function, so it does
> not need to be part of the common register.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/head.S | 34 +++---
>  1 file changed, 23 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index ee0024173e..7b92c1c8eb 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -70,7 +70,7 @@
>   *  x22 - is_secondary_cpu
>   *  x23 - UART address
>   *  x24 -
> - *  x25 - identity map in place
> + *  x25 -
>   *  x26 - skip_zero_bss (boot cpu only)
>   *  x27 -
>   *  x28 -
> @@ -443,16 +443,27 @@ cpu_init:
>  ret
>  ENDPROC(cpu_init)
>  
> +/*
> + * Rebuild the boot pagetable's first-level entries. The structure
> + * is described in mm.c.
> + *
> + * After the CPU enables paging it will add the fixmap mapping
> + * to these page tables, however this may clash with the 1:1
> + * mapping. So each CPU must rebuild the page tables here with
> + * the 1:1 in place.
> + *
> + * Inputs:
> + *   x19: paddr(start)
> + *   x20: phys offset

Is x20 actually used?

The rest looks fine.


> + * Clobbers x0 - x4, x25
> + *
> + * Register usage within this function:
> + *   x25: Identity map in place
> + */
>  create_page_tables:
> -/* Rebuild the boot pagetable's first-level entries. The structure
> - * is described in mm.c.
> - *
> - * After the CPU enables paging it will add the fixmap mapping
> - * to these page tables, however this may clash with the 1:1
> - * mapping. So each CPU must rebuild the page tables here with
> - * the 1:1 in place. */
> -
> -/* If Xen is loaded at exactly XEN_VIRT_START then we don't
> +/*
> + * If Xen is loaded at exactly XEN_VIRT_START then we don't
>   * need an additional 1:1 mapping, the virtual mapping will
>   * suffice.
>   */
> @@ -476,7 +487,8 @@ create_page_tables:
>  cbz   x1, 1f /* It's in slot 0, map in boot_first
>* or boot_second later on */
>  
> -/* Level zero does not support superpage mappings, so we have
> +/*
> + * Level zero does not support superpage mappings, so we have
>   * to use an extra first level page in which we create a 1GB mapping.
>   */
>  load_paddr x2, boot_first_id
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 06/17] xen/arm64: head: Introduce distinct paths for the boot CPU and secondary CPUs

On Mon, 10 Jun 2019, Julien Grall wrote:
> The boot code is currently quite difficult to go through because of the
> lack of documentation and a number of indirection to avoid executing
> some path in either the boot CPU or secondary CPUs.
> 
> In an attempt to make the boot code easier to follow, each parts of the
> boot are now in separate functions. Furthermore, the paths for the boot
> CPU and secondary CPUs are now distincted and for now will call each
> functions.
> 
> Follow-ups will remove unecessary calls and do further improvement
> (such as adding documentation and reshuffling).
> 
> Note that the switch from using the ID mapping to the runtime mapping
> is duplicated for each path. This is because in the future we will need
> to stay longer in the ID mapping for the boot CPU.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/head.S | 57 
> ---
>  1 file changed, 49 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 9142b4a774..ccd8a1b0a8 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -290,7 +290,19 @@ real_start_efi:
>  
>  mov   x22, #0/* x22 := is_secondary_cpu */
>  
> -b common_start
> +blcheck_cpu_mode
> +blzero_bss
> +blcpu_init
> +blcreate_page_tables
> +blenable_mmu
> +
> +/* We are still in the ID map. Jump to the runtime Virtual Address. 
> */
> +ldr   x0, =primary_switched
> +brx0
> +primary_switched:
> +blsetup_fixmap
> +b launch
> +ENDPROC(real_start)
>  
>  GLOBAL(init_secondary)
>  msr   DAIFSet, 0xf   /* Disable all interrupts */
> @@ -324,9 +336,21 @@ GLOBAL(init_secondary)
>  print_reg x24
>  PRINT(" booting -\r\n")
>  #endif
> -
> -common_start:
> -
> +blcheck_cpu_mode
> +blzero_bss
> +blcpu_init
> +blcreate_page_tables
> +blenable_mmu
> +
> +/* We are still in the ID map. Jump to the runtime Virtual Address. 
> */
> +ldr   x0, =secondary_switched
> +brx0
> +secondary_switched:
> +blsetup_fixmap
> +b launch
> +ENDPROC(init_secondary)
> +
> +check_cpu_mode:
>  PRINT("- Current EL ")
>  mrs   x5, CurrentEL
>  print_reg x5
> @@ -343,7 +367,10 @@ common_start:
>  b fail
>  
>  el2:PRINT("- Xen starting at EL2 -\r\n")
> +ret
> +ENDPROC(check_cpu_mode)
>  
> +zero_bss:
>  /* Zero BSS only when requested */
>  cbnz  x26, skip_bss
>  
> @@ -356,6 +383,10 @@ el2:PRINT("- Xen starting at EL2 -\r\n")
>  b.lo  1b
>  
>  skip_bss:
> +ret
> +ENDPROC(zero_bss)
> +
> +cpu_init:
>  PRINT("- Setting up control registers -\r\n")
>  
>  /* Set up memory attribute type tables */
> @@ -390,7 +421,10 @@ skip_bss:
>   * are handled using the EL2 stack pointer, rather
>   * than SP_EL0. */
>  msr spsel, #1
> +ret
> +ENDPROC(cpu_init)
>  
> +create_page_tables:
>  /* Rebuild the boot pagetable's first-level entries. The structure
>   * is described in mm.c.
>   *
> @@ -515,6 +549,10 @@ virtphys_clash:
>  b fail
>  
>  1:
> +ret
> +ENDPROC(create_page_tables)
> +
> +enable_mmu:
>  PRINT("- Turning on paging -\r\n")
>  
>  /*
> @@ -524,16 +562,16 @@ virtphys_clash:
>  tlbi  alle2  /* Flush hypervisor TLBs */
>  dsb   nsh
>  
> -ldr   x1, =paging/* Explicit vaddr, not RIP-relative */
>  mrs   x0, SCTLR_EL2
>  orr   x0, x0, #SCTLR_Axx_ELx_M  /* Enable MMU */
>  orr   x0, x0, #SCTLR_Axx_ELx_C  /* Enable D-cache */
>  dsb   sy /* Flush PTE writes and finish reads */
>  msr   SCTLR_EL2, x0  /* now paging is enabled */
>  isb  /* Now, flush the icache */
> -brx1 /* Get a proper vaddr into PC */
> -paging:
> +ret
> +ENDPROC(enable_mmu)
>  
> +setup_fixmap:
>  /* Now we can install the fixmap and dtb mappings, since we
>   * don't need the 1:1 map any more */
>  dsb   sy
> @@ -575,7 +613,10 @@ paging:
>  tlbi  alle2
>  dsb   sy /* Ensure completion of TLB flush */
>  isb
> +ret
> +ENDPROC(setup_fixmap)
>  
> +launch:
>  PRINT("- Ready -\r\n")
>  
>  /* The boot CPU should go straight into C now */
> @@ -594,7 +635,6 @@ paging:
>  dsb   sy /* Ensure completion of TLB flush */
>  isb
>  
> -launch:

Just below PRINT("- Ready -\r\n"), there is still a:

  cbz   x22, launch

moving the launch label up it looks like it will cause an infinite loop?

Everything else looks good, and I

Re: [Xen-devel] [PATCH 07/17] xen/arm64: head: Rework and document check_cpu_mode()

On Mon, 10 Jun 2019, Julien Grall wrote:
> A branch in the success case can be avoided by inverting the branch
> condition. At the same time, remove a pointless comment as Xen can only
> run at EL2.
> 
> Lastly, document the behavior and the main registers usage within the
> function.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/arm64/head.S | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index ccd8a1b0a8..87fcd3be6c 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -350,6 +350,13 @@ secondary_switched:
>  b launch
>  ENDPROC(init_secondary)
>  
> +/*
> + * Check if the CPU has been booted in Hypervisor mode.
> + * This function will never return when the CPU is booted in another mode
> + * than Hypervisor mode.
> + *
> + * Clobbers x0 - x5
> + */
>  check_cpu_mode:
>  PRINT("- Current EL ")
>  mrs   x5, CurrentEL
> @@ -359,15 +366,13 @@ check_cpu_mode:
>  /* Are we in EL2 */
>  cmp   x5, #PSR_MODE_EL2t
>  ccmp  x5, #PSR_MODE_EL2h, #0x4, ne
> -b.eq  el2 /* Yes */
> -
> +b.ne  1f /* No */
> +ret
> +1:
>  /* OK, we're boned. */
>  PRINT("- Xen must be entered in NS EL2 mode -\r\n")
>  PRINT("- Please update the bootloader -\r\n")
>  b fail
> -
> -el2:PRINT("- Xen starting at EL2 -\r\n")
> -ret
>  ENDPROC(check_cpu_mode)
>  
>  zero_bss:
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 09/17] xen/arm64: head: Improve coding style and document cpu_init()

On Mon, 10 Jun 2019, Julien Grall wrote:
> Adjust the coding style used in the comments within cpu_init(). Take the
> opportunity to alter the early print to match the function name.
> 
> Lastly, document the behavior and the main registers usage within the
> function.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/head.S | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 6aa3148192..ee0024173e 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -396,19 +396,26 @@ skip_bss:
>  ret
>  ENDPROC(zero_bss)
>  
> +/*
> + * Initialize the processor for turning the MMU on.
> + *
> + * Clobbers x0 - x4

Shouldn't it be x0 - x3?

The rest looks fine.


> + */
>  cpu_init:
> -PRINT("- Setting up control registers -\r\n")
> +PRINT("- Initialize CPU -\r\n")
>  
>  /* Set up memory attribute type tables */
>  ldr   x0, =MAIRVAL
>  msr   mair_el2, x0
>  
> -/* Set up TCR_EL2:
> +/*
> + * Set up TCR_EL2:
>   * PS -- Based on ID_AA64MMFR0_EL1.PARange
>   * Top byte is used
>   * PT walks use Inner-Shareable accesses,
>   * PT walks are write-back, write-allocate in both cache levels,
> - * 48-bit virtual address space goes through this table. */
> + * 48-bit virtual address space goes through this table.
> + */
>  ldr   x0, 
> =(TCR_RES1|TCR_SH0_IS|TCR_ORGN0_WBWA|TCR_IRGN0_WBWA|TCR_T0SZ(64-48))
>  /* ID_AA64MMFR0_EL1[3:0] (PARange) corresponds to TCR_EL2[18:16] 
> (PS) */
>  mrs   x1, ID_AA64MMFR0_EL1
> @@ -427,9 +434,11 @@ cpu_init:
>  ldr   x0, =(HSCTLR_BASE)
>  msr   SCTLR_EL2, x0
>  
> -/* Ensure that any exceptions encountered at EL2
> +/*
> + * Ensure that any exceptions encountered at EL2
>   * are handled using the EL2 stack pointer, rather
> - * than SP_EL0. */
> + * than SP_EL0.
> + */
>  msr spsel, #1
>  ret
>  ENDPROC(cpu_init)
> -- 
> 2.11.0
> 

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

[Xen-devel] [xen-unstable-smoke test] 138510: regressions - trouble: blocked/fail

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days8 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days7 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH 05/17] xen/arm64: head: Introduce print_reg

On Mon, 10 Jun 2019, Julien Grall wrote:
> At the moment, the user should save x30/lr if it cares about it.
> 
> Follow-up patches will introduce more use of putn in place where lr
> should be preserved.
> 
> Furthermore, any user of putn should also move the value to register x0
> if it was stored in a different register.
> 
> For convenience, a new macro is introduced to print a given register.
> The macro will take care for us to move the value to x0 and also
> preserve lr.
> 
> Lastly the new macro is used to replace all the callsite of putn. This
> will simplify rework/review later on.
> 
> Note that CurrentEL is now stored in x5 instead of x4 because the latter
> will be clobbered by the macro print_reg.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/head.S | 29 ++---
>  1 file changed, 22 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 84e26582c4..9142b4a774 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -90,8 +90,25 @@
>  blputs; \
>  mov   lr, x3  ; \
>  RODATA_STR(98, _s)
> +
> +/*
> + * Macro to print the value of register \xb
> + *
> + * Clobbers x0 - x4
> + */
> +.macro print_reg xb
> +mov   x4, lr
> +mov   x0, \xb
> +blputn
> +mov   lr, x4

I have the same weird issues with my compiler as before, replacing 'lr'
with 'x30' solves the problem.

This patch looks OK though.


> +.endm
> +
>  #else /* CONFIG_EARLY_PRINTK */
>  #define PRINT(s)
> +
> +.macro print_reg xb
> +.endm
> +
>  #endif /* !CONFIG_EARLY_PRINTK */
>  
>  /* Load the physical address of a symbol into xb */
> @@ -304,22 +321,20 @@ GLOBAL(init_secondary)
>  #ifdef CONFIG_EARLY_PRINTK
>  ldr   x23, =EARLY_UART_BASE_ADDRESS /* x23 := UART base address */
>  PRINT("- CPU ")
> -mov   x0, x24
> -blputn
> +print_reg x24
>  PRINT(" booting -\r\n")
>  #endif
>  
>  common_start:
>  
>  PRINT("- Current EL ")
> -mrs   x4, CurrentEL
> -mov   x0, x4
> -blputn
> +mrs   x5, CurrentEL
> +print_reg x5
>  PRINT(" -\r\n")
>  
>  /* Are we in EL2 */
> -cmp   x4, #PSR_MODE_EL2t
> -ccmp  x4, #PSR_MODE_EL2h, #0x4, ne
> +cmp   x5, #PSR_MODE_EL2t
> +ccmp  x5, #PSR_MODE_EL2h, #0x4, ne
>  b.eq  el2 /* Yes */
>  
>  /* OK, we're boned. */
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 04/17] xen/arm64: head: Don't "reserve" x24 for the CPUID

On Mon, 10 Jun 2019, Julien Grall wrote:
> After the recent rework, the CPUID is only used at the very beginning of
> the secondary CPUs boot path. So there is no need to "reserve" x24 for
> he CPUID.

If you are going to resend the series it would probably make sense to
fold it in the previous patch, but it is also OK as is

Acked-by: Stefano Stabellini 


> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/head.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index fd432ee15d..84e26582c4 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -69,7 +69,7 @@
>   *  x21 - DTB address (boot cpu only)
>   *  x22 - is_secondary_cpu
>   *  x23 - UART address
> - *  x24 - cpuid
> + *  x24 -
>   *  x25 - identity map in place
>   *  x26 - skip_zero_bss
>   *  x27 -
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 02/17] xen/arm64: head: Don't clobber x30/lr in the macro PRINT

On Tue, 25 Jun 2019, Stefano Stabellini wrote:
> On Mon, 10 Jun 2019, Julien Grall wrote:
> >>  The current implementation of the macro PRINT will clobber x30/lr. This
> > means the user should save lr if it cares about it.
> 
> By x30/lr, do you mean x0-x3 and lr? I would prefer a clearer
> expression.

No of course not! You meant x30 which is a synonym of lr! It is just
that in this case it is also supposed to clobber x0-x3 -- I got
confused! The commit message is also fine as is then. More below.


> Reviewed-by: Stefano Stabellini 
> 
> 
> > Follow-up patches will introduce more use of PRINT in place where lr
> > should be preserved. Rather than requiring all the users to preserve lr,
> > the macro PRINT is modified to save and restore it.
> > 
> > While the comment state x3 will be clobbered, this is not the case. So
> > PRINT will use x3 to preserve lr.
> > 
> > Lastly, take the opportunity to move the comment on top of PRINT and use
> > PRINT in init_uart. Both changes will be helpful in a follow-up patch.
> > 
> > Signed-off-by: Julien Grall 
> > ---
> >  xen/arch/arm/arm64/head.S | 14 +-
> >  1 file changed, 9 insertions(+), 5 deletions(-)
> > 
> > diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> > index c8bbdf05a6..a5147c8d80 100644
> > --- a/xen/arch/arm/arm64/head.S
> > +++ b/xen/arch/arm/arm64/head.S
> > @@ -78,12 +78,17 @@
> >   *  x30 - lr
> >   */
> >  
> > -/* Macro to print a string to the UART, if there is one.
> > - * Clobbers x0-x3. */
> >  #ifdef CONFIG_EARLY_PRINTK
> > +/*
> > + * Macro to print a string to the UART, if there is one.
> > + *
> > + * Clobbers x0 - x3
> > + */
> >  #define PRINT(_s)   \
> > +mov   x3, lr  ; \
> >  adr   x0, 98f ; \
> >  blputs; \
> > +mov   lr, x3  ; \
> >  RODATA_STR(98, _s)

Strangely enough I get a build error with gcc 7.3.1, but if I use x30
instead of lr, it builds fine. Have you seen this before?
The error is:

arm64/head.S: Assembler messages:
arm64/head.S:272: Error: operand 1 must be an integer register -- `mov lr,x3'
[...]
arm64/head.S:272: Error: undefined symbol lr used as an immediate value
[...]

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

Re: [Xen-devel] [PATCH 03/17] xen/arm64: head: Rework UART initialization on boot CPU

On Mon, 10 Jun 2019, Julien Grall wrote:
> Anything executed after the label common_start can be executed on all
> CPUs. However most of the instructions executed between the label
> common_start and init_uart are not executed on the boot CPU.
> 
> The only instructions executed are to lookup the CPUID so it can be
> printed on the console (if earlyprintk is enabled). Printing the CPUID
> is not entirely useful to have for the boot CPU and requires a
> conditional branch to bypass unused instructions.
> 
> Furthermore, the function init_uart is only called for boot CPU
> requiring another conditional branch. This makes the code a bit tricky
> to follow.
> 
> The UART initialization is now moved before the label common_start. This
> now requires to have a slightly altered print for the boot CPU and set
> the early UART base address in each the two path (boot CPU and
> secondary CPUs).
> 
> This has the nice effect to remove a couple of conditional branch in
> the code.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/arm64/head.S | 29 +++--
>  1 file changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index a5147c8d80..fd432ee15d 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -265,6 +265,12 @@ real_start_efi:
>  load_paddr x21, _sdtb
>  #endif
>  
> +/* Initialize the UART if earlyprintk has been enabled. */
> +#ifdef CONFIG_EARLY_PRINTK
> +blinit_uart
> +#endif
> +PRINT("- Boot CPU booting -\r\n")
> +
>  mov   x22, #0/* x22 := is_secondary_cpu */
>  
>  b common_start
> @@ -281,14 +287,11 @@ GLOBAL(init_secondary)
>  /* Boot CPU already zero BSS so skip it on secondary CPUs. */
>  mov   x26, #1/* X26 := skip_zero_bss */
>  
> -common_start:
>  mrs   x0, mpidr_el1
>  ldr   x13, =(~MPIDR_HWID_MASK)
>  bic   x24, x0, x13   /* Mask out flags to get CPU ID */
>  
> -/* Non-boot CPUs wait here until __cpu_up is ready for them */
> -cbz   x22, 1f
> -
> +/* Wait here until __cpu_up is ready to handle the CPU */
>  load_paddr x0, smp_up_cpu
>  dsb   sy
>  2:  ldr   x1, [x0]
> @@ -300,14 +303,14 @@ common_start:
>  
>  #ifdef CONFIG_EARLY_PRINTK
>  ldr   x23, =EARLY_UART_BASE_ADDRESS /* x23 := UART base address */
> -cbnz  x22, 1f
> -blinit_uart /* Boot CPU sets up the UART too */
> -1:  PRINT("- CPU ")
> +PRINT("- CPU ")
>  mov   x0, x24
>  blputn
>  PRINT(" booting -\r\n")
>  #endif
>  
> +common_start:
> +
>  PRINT("- Current EL ")
>  mrs   x4, CurrentEL
>  mov   x0, x4
> @@ -628,10 +631,16 @@ ENTRY(switch_ttbr)
>  ret
>  
>  #ifdef CONFIG_EARLY_PRINTK
> -/* Bring up the UART.
> - * x23: Early UART base address
> - * Clobbers x0-x1 */
> +/*
> + * Initialize the UART. Should only be called on the boot CPU.
> + *
> + * Ouput:
> + *  x23: Early UART base physical address
> + *
> + * Clobbers x0 - x1
> + */
>  init_uart:
> +ldr   x23, =EARLY_UART_BASE_ADDRESS
>  #ifdef EARLY_PRINTK_INIT_UART
>  early_uart_init x23, 0
>  #endif
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 02/17] xen/arm64: head: Don't clobber x30/lr in the macro PRINT

On Mon, 10 Jun 2019, Julien Grall wrote:
>>  The current implementation of the macro PRINT will clobber x30/lr. This
> means the user should save lr if it cares about it.

By x30/lr, do you mean x0-x3 and lr? I would prefer a clearer
expression.

Reviewed-by: Stefano Stabellini 


> Follow-up patches will introduce more use of PRINT in place where lr
> should be preserved. Rather than requiring all the users to preserve lr,
> the macro PRINT is modified to save and restore it.
> 
> While the comment state x3 will be clobbered, this is not the case. So
> PRINT will use x3 to preserve lr.
> 
> Lastly, take the opportunity to move the comment on top of PRINT and use
> PRINT in init_uart. Both changes will be helpful in a follow-up patch.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/head.S | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index c8bbdf05a6..a5147c8d80 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -78,12 +78,17 @@
>   *  x30 - lr
>   */
>  
> -/* Macro to print a string to the UART, if there is one.
> - * Clobbers x0-x3. */
>  #ifdef CONFIG_EARLY_PRINTK
> +/*
> + * Macro to print a string to the UART, if there is one.
> + *
> + * Clobbers x0 - x3
> + */
>  #define PRINT(_s)   \
> +mov   x3, lr  ; \
>  adr   x0, 98f ; \
>  blputs; \
> +mov   lr, x3  ; \
>  RODATA_STR(98, _s)
>  #else /* CONFIG_EARLY_PRINTK */
>  #define PRINT(s)
> @@ -630,9 +635,8 @@ init_uart:
>  #ifdef EARLY_PRINTK_INIT_UART
>  early_uart_init x23, 0
>  #endif
> -adr   x0, 1f
> -b puts
> -RODATA_STR(1, "- UART enabled -\r\n")
> +PRINT("- UART enabled -\r\n")
> +ret
>  
>  /* Print early debug messages.
>   * x0: Nul-terminated string to print.
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 01/17] xen/arm64: head Mark the end of subroutines with ENDPROC

On Mon, 10 Jun 2019, Julien Grall wrote:
> putn() and puts() are two subroutines. Add ENDPROC for the benefits of
> static analysis tools and the reader.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/arm64/head.S | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index ddd3a33108..c8bbdf05a6 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -646,6 +646,7 @@ puts:
>  b puts
>  1:
>  ret
> +ENDPROC(puts)
>  
>  /* Print a 32-bit number in hex.  Specific to the PL011 UART.
>   * x0: Number to print.
> @@ -664,6 +665,7 @@ putn:
>  subs  x3, x3, #1
>  b.ne  1b
>  ret
> +ENDPROC(putn)
>  
>  hex:.ascii "0123456789abcdef"
>  .align 2
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] PCI Passthrough bug with x86 HVM

On Tue, 25 Jun 2019, Roger Pau Monné wrote:
> On Mon, Jun 24, 2019 at 11:47:09AM -0700, Stefano Stabellini wrote:
> > + xen-devel
> > 
> > On Mon, 24 Jun 2019, Stefano Stabellini wrote:
> > > Hi all,
> > > 
> > > I might have found a bug with PCI passthrough to a Linux HVM guest on
> > > x86 with Xen 4.12. It is not easy for me to get access, and especially
> > > change components, on this particular system, and I don't have access to
> > > other x86 boxes at the moment, so apologies for the partial information
> > > report. The setup is as follow:
> > > 
> > > - two PCI devices have been assigned to a HVM guest, everything is fine
> > > - reboot the guest from inside, i.e. `reboot' in Linux
> > > - after the reboot completes, only one device is assigned
> 
> Can you provide the xl debug log of the whole process?

See attached.


> > > Before the reboot, I see all the appropriate xenstore entries for both
> > > devices. Everything is fine. After the reboot, I can only see the
> > > xenstore entries of one device. It is as if the other device
> > > "disappeared" without throwing any errors.
> 
> So there are no errors on the hypervisor dmesg or the xl logs at all?

Nope. Only:

[445257.718590] xen_pciback: vpci: :00:0e.0: assign to virtual slot 0
[445257.733048] pciback :00:0e.0: registering for 4
[445257.741257] xen_pciback: vpci: :03:00.0: assign to virtual slot 1
[445257.758836] pciback :03:00.0: registering for 4
[445340.380219] xen_pciback: vpci: :00:0e.0: assign to virtual slot 0
[445340.391755] pciback :00:0e.0: registering for 5



> > > Have you seen this before? Do you know if it has been fixed in staging?
> > > I noticed this fix which seems to be very relevant:
> > > 
> > > https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg01616.html
> > > 
> > > but it is already included in 4.12.
> 
> AFAICT your issue seems related to xl/libxl not properly re-adding the
> devices on reboot. The fix above had to do with leaving devices in a
> broken state under some circumstances (ie: they where always attached
> to the guest, just not working properly).

Yes, it looks like it is as you describe.Waiting for domain test-multi-adapters.1 (domid 4) to die [pid 1536]
libxl: debug: libxl_event.c:639:libxl__ev_xswatch_register: watch 
w=0x7f67c0e09880 wpath=@releaseDomain token=3/0: register slotnum=3
libxl: debug: libxl_event.c:576:watchfd_callback: watch w=0x7f67c0e09880 
wpath=@releaseDomain token=3/0: event epath=@releaseDomain
libxl: debug: libxl_domain.c:767:domain_death_xswatch_callback: Domain 
4:[evg=0x7f67c0e09a20] nentries=1 rc=1 4..4
libxl: debug: libxl_domain.c:778:domain_death_xswatch_callback: Domain 
4:[evg=0x7f67c0e09a20]   got=domaininfos[0] got->domain=4
libxl: debug: libxl_domain.c:804:domain_death_xswatch_callback: Domain 4:Exists 
shutdown_reported=0 dominf.flags=0102
libxl: debug: libxl_domain.c:771:domain_death_xswatch_callback: [evg=0] all 
reported
libxl: debug: libxl_domain.c:833:domain_death_xswatch_callback: domain death 
search done
libxl: debug: libxl_event.c:576:watchfd_callback: watch w=0x7f67c0e09880 
wpath=@releaseDomain token=3/0: event epath=@releaseDomain
libxl: debug: libxl_domain.c:767:domain_death_xswatch_callback: Domain 
4:[evg=0x7f67c0e09a20] nentries=1 rc=1 4..4
libxl: debug: libxl_domain.c:778:domain_death_xswatch_callback: Domain 
4:[evg=0x7f67c0e09a20]   got=domaininfos[0] got->domain=4
libxl: debug: libxl_domain.c:804:domain_death_xswatch_callback: Domain 4:Exists 
shutdown_reported=0 dominf.flags=10106
libxl: debug: libxl_domain.c:816:domain_death_xswatch_callback:  shutdown 
reporting
libxl: debug: libxl_domain.c:771:domain_death_xswatch_callback: [evg=0] all 
reported
libxl: debug: libxl_domain.c:833:domain_death_xswatch_callback: domain death 
search done
Domain 4 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
libxl: debug: libxl_qmp.c:813:libxl__qmp_initialize: Domain 4:connected to 
/var/run/xen/qmp-libxl-4
libxl: debug: libxl_qmp.c:350:qmp_handle_response: Domain 4:message type: qmp
libxl: debug: libxl_qmp.c:365:qmp_handle_response: Domain 4:QEMU version: 3.0.0
libxl: debug: libxl_qmp.c:666:qmp_send_prepare: Domain 4:next qmp command: 
'{"execute":"qmp_capabilities","id":1}
'
libxl: debug: libxl_qmp.c:350:qmp_handle_response: Domain 4:message type: return
libxl: debug: libxl_qmp.c:666:qmp_send_prepare: Domain 4:next qmp command: 
'{"execute":"query-cpus","id":2}
'
libxl: debug: libxl_qmp.c:350:qmp_handle_response: Domain 4:message type: return
libxl: debug: libxl_domain.c:1749:libxl_retrieve_domain_configuration: Domain 
4:No vtpm from xenstore
libxl: debug: libxl_domain.c:1749:libxl_retrieve_domain_configuration: Domain 
4:No vusb from xenstore
libxl: debug: libxl_domain.c:1749:libxl_retrieve_domain_configuration: Domain 
4:No vusb from xenstore
libxl: warning: libxl_domain.c:1767:libxl_retrieve_domain_configuration: Domain 
4:Device present in JSON but not in xenstore, ignored
libxl:

Re: [Xen-devel] Migrating key developer docs to xen.git sphinx docs and refreshing them in the process


Hi Stefano,

On 6/25/19 10:18 PM, Stefano Stabellini wrote:

On Tue, 25 Jun 2019, Julien Grall wrote:

The point here is that we can be flexible and creative about the way to
maintain the docs on xen.git. But as a technology is certainly better
than the wiki: we don't have to keep them all up-to-date with the code,
but at least this way we have a chance (if we want to). If we leave them
on the wiki, there is no chance.


I can't see how xen.git is going to be better if "we don't have to keep
them
all up-to-date".


That's because a contributor could add a patch at the end of a series to
update one of the docs, even if the doc in question comes with no
promises of being up-to-date.


I think this is going the wrong direction. The goal of using xen.git is to try
to keep the documentation up-to-date.


Is the goal to keep the documentation fully up-to-date, or more
up-to-date than what we currently have on the wiki? I don't see this as
black and white. There are lot of stages of "up-to-dateness" in between.


From the discussion it is pretty that we want the doc fully up-to-date.




But my point here is most of the board should be trivial. The most of the
non-trivial setup require non-upstream patch. While I am happy to see that
on
the wiki, I think xen.git should not promote such configuration at all. We
are
working upstream, not with unknown/untrusted stack.

For some working fully upstream, I don't think xen.git should promote any
distros/versions of the kernel. However, this is ok on the wiki.


I would like to see the wiki disappear completely in the long term. As
we are moving more content to xen.git, it is not a good idea to have two
places where we keep information, for similar reasons why you suggested
to use in-code comments instead of docs to document interfaces. It
just takes more efforts to maintain information in two places and they
tend to get out of sync with each others.

If we make the wiki go away (I hope so), we'll need a place to store the
Arm board-specific documents, and other tutorials.


Removing the wiki is an honorable goal, however I don't think all the wiki is
suitable for xen.git. The Arm board-specific documents is an example.

You actually haven't addressed my concern above. If you look at the wiki, a
lot of them ([1], [2], [3]) contains non-upstreamed work or non-upstreamable
hack.

For those containing only upstream work [4], the example is focusing on one
set of distros. In the case of QEMU, I already had some people asking whether
it is possible to use without U-boot. Why would we promote Ubuntu and not
something else?

Overall, there are so many configurations possible (kernel, u-boot,
distributions) that it does not makes sense to keep track of that in xen.git.

Instead, I think we should write generic doc on how to boot Xen on a
U-boot/UEFI setup and inviting the users to look into more details for his
board.


I don't think that we should host non-upstreamable hacks in general
either in xen.git. However, some boards require specific Linux kernel
trees to boot that are not upstream, so there is a fine line between
"non-upstreamable hack" and "following the docs and code provided with a
given board".

Similarly, I don't think we should have distro-specific information in
xen.git (or the wiki) either but sometimes we need to pick one as an
example. Otherwise, the tutorial wouldn't be complete.

In the case of the board specific files, we do both these things, but
because they are unavoidable, not because somebody wanted to advertise
Ubuntu, or preferred to use a private Linux kernel tree over upstream.
If that is the case, we should not import them into xen.git.


That's not correct, it is unavoidable because we never worked with the 
distros to integrate Xen on Arm. So we pile up crap as we can't say 
"Please select your distros and install Xen from the package".


Basically, we are doing the job of a distro. Instead, we should focus at 
better integration in distros such as Yocto, Zephyr.




I also agree with you that if we are going to host only docs 100%
accurate, generic, and fully maintained by us on xen.git, then we should
NOT have the board specific docs there. But I would say that there is a
benefit in having docs not maintained by us and potentially not fully
up-to-date on xen.git that are useful to the community, like the board
specific docs. It would be easier to keep them "somewhat up to date"
release by release compared to the wiki, and in the future turn them
into "fully up to date" docs if we get more engagement.

If we leave them in the wiki I have the impression that their only
possible future is to rot and die...

This is not something that is going to happen anytime soon, so I think
we should take Lars' suggestion and talk about it at the Summit.


Sounds good to me.

Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 138505: regressions - trouble: blocked/fail

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days7 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days6 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich

Re: [Xen-devel] Migrating key developer docs to xen.git sphinx docs and refreshing them in the process

On Tue, 25 Jun 2019, Julien Grall wrote:
> > > > The point here is that we can be flexible and creative about the way to
> > > > maintain the docs on xen.git. But as a technology is certainly better
> > > > than the wiki: we don't have to keep them all up-to-date with the code,
> > > > but at least this way we have a chance (if we want to). If we leave them
> > > > on the wiki, there is no chance.
> > > 
> > > I can't see how xen.git is going to be better if "we don't have to keep
> > > them
> > > all up-to-date".
> > 
> > That's because a contributor could add a patch at the end of a series to
> > update one of the docs, even if the doc in question comes with no
> > promises of being up-to-date.
> 
> I think this is going the wrong direction. The goal of using xen.git is to try
> to keep the documentation up-to-date.

Is the goal to keep the documentation fully up-to-date, or more
up-to-date than what we currently have on the wiki? I don't see this as
black and white. There are lot of stages of "up-to-dateness" in between.

> > > But my point here is most of the board should be trivial. The most of the
> > > non-trivial setup require non-upstream patch. While I am happy to see that
> > > on
> > > the wiki, I think xen.git should not promote such configuration at all. We
> > > are
> > > working upstream, not with unknown/untrusted stack.
> > > 
> > > For some working fully upstream, I don't think xen.git should promote any
> > > distros/versions of the kernel. However, this is ok on the wiki.
> > 
> > I would like to see the wiki disappear completely in the long term. As
> > we are moving more content to xen.git, it is not a good idea to have two
> > places where we keep information, for similar reasons why you suggested
> > to use in-code comments instead of docs to document interfaces. It
> > just takes more efforts to maintain information in two places and they
> > tend to get out of sync with each others.
> > 
> > If we make the wiki go away (I hope so), we'll need a place to store the
> > Arm board-specific documents, and other tutorials.
> 
> Removing the wiki is an honorable goal, however I don't think all the wiki is
> suitable for xen.git. The Arm board-specific documents is an example.
> 
> You actually haven't addressed my concern above. If you look at the wiki, a
> lot of them ([1], [2], [3]) contains non-upstreamed work or non-upstreamable
> hack.
> 
> For those containing only upstream work [4], the example is focusing on one
> set of distros. In the case of QEMU, I already had some people asking whether
> it is possible to use without U-boot. Why would we promote Ubuntu and not
> something else?
> 
> Overall, there are so many configurations possible (kernel, u-boot,
> distributions) that it does not makes sense to keep track of that in xen.git.
> 
> Instead, I think we should write generic doc on how to boot Xen on a
> U-boot/UEFI setup and inviting the users to look into more details for his
> board.

I don't think that we should host non-upstreamable hacks in general
either in xen.git. However, some boards require specific Linux kernel
trees to boot that are not upstream, so there is a fine line between
"non-upstreamable hack" and "following the docs and code provided with a
given board".

Similarly, I don't think we should have distro-specific information in
xen.git (or the wiki) either but sometimes we need to pick one as an
example. Otherwise, the tutorial wouldn't be complete.

In the case of the board specific files, we do both these things, but
because they are unavoidable, not because somebody wanted to advertise
Ubuntu, or preferred to use a private Linux kernel tree over upstream.
If that is the case, we should not import them into xen.git.

I also agree with you that if we are going to host only docs 100%
accurate, generic, and fully maintained by us on xen.git, then we should
NOT have the board specific docs there. But I would say that there is a
benefit in having docs not maintained by us and potentially not fully
up-to-date on xen.git that are useful to the community, like the board
specific docs. It would be easier to keep them "somewhat up to date"
release by release compared to the wiki, and in the future turn them
into "fully up to date" docs if we get more engagement.

If we leave them in the wiki I have the impression that their only
possible future is to rot and die...

This is not something that is going to happen anytime soon, so I think
we should take Lars' suggestion and talk about it at the Summit.

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

[Xen-devel] [xen-unstable-smoke test] 138501: regressions - trouble: blocked/fail

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

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  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days6 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days5 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

2019-06-25 Thread Rich Persaud

> On Jun 25, 2019, at 16:17, Julien Grall  wrote:
> 
> Hi Rich,
> 
> On 6/25/19 8:38 PM, Rich Persaud wrote:
>>> On Jun 25, 2019, at 12:36, Lars Kurth  wrote:
>>> 
>>> Hi all:
>>> please add your agenda items. I had only ONE series which was highlighted 
>>> as needing attention from others. Is this seriously the only one?
>> Proposed agenda item: in the absence of Jira tickets, would it be useful to 
>> have a list (e.g. generated by a script) with the lifecycle status of all 
>> outstanding patch series, e.g.
>> METADATA
>> - bug fix / improvement / refactor / cleanup / new feature
>> - impacted Xen subsystems/components/features
>> - targeted version of Xen
>> - contributing person/org
>> - relevance of patch series to the goals set by RM for the next Xen release
>> - related patch series (with below status info)
>> STATUS:
>> - patch series version
>> - date of patch series v1
>> - no responses received + ping count + days since submission + days since 
>> ping
>> - reviewed with objections
>> - reviewed without objections, awaiting ack
>> - acked, awaiting merge
>> From such a summary, patch series could be prioritized for review/triage in 
>> the community call, based on uniform criteria and project-wide context.
> 
> While I think raising awareness of the stuck series is a good idea. I still 
> have some concern regarding the prioritization. Who is going to consume the 
> result of the discussion? Is it the maintainers?

Anyone who typically answers the question raised by Lars in this thread, 
presumably a subset of call attendees.

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

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items


Hi Rich,

On 6/25/19 8:38 PM, Rich Persaud wrote:

On Jun 25, 2019, at 12:36, Lars Kurth  wrote:

Hi all:
please add your agenda items. I had only ONE series which was highlighted as 
needing attention from others. Is this seriously the only one?


Proposed agenda item: in the absence of Jira tickets, would it be useful to 
have a list (e.g. generated by a script) with the lifecycle status of all 
outstanding patch series, e.g.

METADATA

- bug fix / improvement / refactor / cleanup / new feature
- impacted Xen subsystems/components/features
- targeted version of Xen
- contributing person/org
- relevance of patch series to the goals set by RM for the next Xen release
- related patch series (with below status info)

STATUS:

- patch series version
- date of patch series v1
- no responses received + ping count + days since submission + days since ping
- reviewed with objections
- reviewed without objections, awaiting ack
- acked, awaiting merge

 From such a summary, patch series could be prioritized for review/triage in 
the community call, based on uniform criteria and project-wide context.


While I think raising awareness of the stuck series is a good idea. I 
still have some concern regarding the prioritization. Who is going to 
consume the result of the discussion? Is it the maintainers?


Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 138497: regressions - trouble: blocked/fail

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days5 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

2019-06-25 Thread Rich Persaud

> On Jun 25, 2019, at 12:36, Lars Kurth  wrote:
> 
> Hi all:
> please add your agenda items. I had only ONE series which was highlighted as 
> needing attention from others. Is this seriously the only one?

Proposed agenda item: in the absence of Jira tickets, would it be useful to 
have a list (e.g. generated by a script) with the lifecycle status of all 
outstanding patch series, e.g.

METADATA

- bug fix / improvement / refactor / cleanup / new feature
- impacted Xen subsystems/components/features
- targeted version of Xen
- contributing person/org
- relevance of patch series to the goals set by RM for the next Xen release
- related patch series (with below status info)

STATUS:

- patch series version
- date of patch series v1
- no responses received + ping count + days since submission + days since ping
- reviewed with objections
- reviewed without objections, awaiting ack
- acked, awaiting merge

From such a summary, patch series could be prioritized for review/triage in the 
community call, based on uniform criteria and project-wide context.

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

Re: [Xen-devel] Migrating key developer docs to xen.git sphinx docs and refreshing them in the process

2019-06-25 Thread Rich Persaud

> On Jun 25, 2019, at 12:34, Lars Kurth  wrote:
> 
> On 25/06/2019, 14:47, "Andrew Cooper"  wrote:
> 
>>   On 25/06/2019 13:15, Lars Kurth wrote:
>> On 25/06/2019, 10:03, "Julien Grall"  wrote:
>> 
> The point here is that we can be flexible and creative about the way to
> maintain the docs on xen.git. But as a technology is certainly better
> than the wiki: we don't have to keep them all up-to-date with the code,
> but at least this way we have a chance (if we want to). If we leave them
> on the wiki, there is no chance.
 
 I can't see how xen.git is going to be better if "we don't have to keep 
 them
 all up-to-date".
>>> 
>>> That's because a contributor could add a patch at the end of a series to
>>> update one of the docs, even if the doc in question comes with no
>>> promises of being up-to-date.
>> 
>>   I think this is going the wrong direction. The goal of using xen.git is to 
>> try 
>>   to keep the documentation up-to-date.
>> 
>> I agree with Julien and this was also not my intention. The reason why I 
>> brought this up now is that the in-tree docs are pretty much a mess today 
>> and are stale in many ways. And they look TERRIBLE and are not easily 
>> searchable. However, Andy's latest set of patches provide an opportunity to 
>> consolidate some of the in-tree docs in a nicely rendered and searchable 
>> format.
> 
>   So the plan here is to get a consistent and uniform set of high quality
>   docs.
> 
>   As fair warning, I'm intending to be fairly strict with what goes in
>   (quality wise), because I'm going to do my best to ensure that the
>   sphinx documentation doesn't devolve into the mess that wiki or the
>   majority of docs/ currently is.
> 
> I wholeheartedly agree
> 
>> I have been focussing on process related and key developer related docs, 
>> because who maintains them is not actually an issue in theory. Everyone 
>> really ought to care, because everyone is impacted by these.
> 
>   The key point is for maintainers/reviewers to be aware of whether
>   documentation exists for the area of code being modified, and if so,
>   whether the submitted patch should also patch the documentation.
> 
> I am wondering whether this is something which could be addressed. One 
> possibility may be to have SUPPORT.md point to documentation. But that is 
> kind of assuming that SUPPORT.md works and is widely used. There may be 
> better or orthogonal ways to point to relevant docs (e.g. by pointing to docs 
> in header files and other source files). 
> 
>   Reviewers tend to be fairly good at noticing patches which also need to
>   patch docs/misc/xen-command-line.pandoc (submitters, less so), but this
>   approach needs extending to the whole of the sphinx docs (which in turn
>   requires the docs to stay high quality so its easy for maintainers to
>   know what is where).
> 
> Although this does not apply in my proposal, I think the key issue has been 
> that reviewers and submitters of code often don't use our documentation. The 
> wiki is seen as a separate thing and also has the disadvantage that it 
> doesn't lend itself to supporting different versions of Xen. And most of the 
> time, developers do not use it and neither contribute to it.
> 
> My hope was that by hosting documentation related to contribution workflow 
> and other essential tasks close to other useful documentation this would 
> enable change.
> 
> @Andy and others: I need to know whether you agree with my proposal and 
> whether anyone has other suggestions.

If not already present in the release manager process checklist, we could 
specify documentation-related updates for each release, e.g. minimum text for 
new features, revisions to modified features, SUPPORT.md updates.

Rich

(resend with non-bulkmail address)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Migrating key developer docs to xen.git sphinx docs and refreshing them in the process

2019-06-25 Thread P S



> On Jun 25, 2019, at 12:34, Lars Kurth  wrote:
> 
> 
> 
> On 25/06/2019, 14:47, "Andrew Cooper"  wrote:
> 
>>On 25/06/2019 13:15, Lars Kurth wrote:
>> On 25/06/2019, 10:03, "Julien Grall"  wrote:
>> 
> The point here is that we can be flexible and creative about the way to
> maintain the docs on xen.git. But as a technology is certainly better
> than the wiki: we don't have to keep them all up-to-date with the code,
> but at least this way we have a chance (if we want to). If we leave them
> on the wiki, there is no chance.
 
 I can't see how xen.git is going to be better if "we don't have to keep 
 them
 all up-to-date".
>>> 
>>> That's because a contributor could add a patch at the end of a series to
>>> update one of the docs, even if the doc in question comes with no
>>> promises of being up-to-date.
>> 
>>I think this is going the wrong direction. The goal of using xen.git is 
>> to try 
>>to keep the documentation up-to-date.
>> 
>> I agree with Julien and this was also not my intention. The reason why I 
>> brought this up now is that the in-tree docs are pretty much a mess today 
>> and are stale in many ways. And they look TERRIBLE and are not easily 
>> searchable. However, Andy's latest set of patches provide an opportunity to 
>> consolidate some of the in-tree docs in a nicely rendered and searchable 
>> format.
> 
>So the plan here is to get a consistent and uniform set of high quality
>docs.
> 
>As fair warning, I'm intending to be fairly strict with what goes in
>(quality wise), because I'm going to do my best to ensure that the
>sphinx documentation doesn't devolve into the mess that wiki or the
>majority of docs/ currently is.
> 
> I wholeheartedly agree
> 
>> I have been focussing on process related and key developer related docs, 
>> because who maintains them is not actually an issue in theory. Everyone 
>> really ought to care, because everyone is impacted by these.
> 
>The key point is for maintainers/reviewers to be aware of whether
>documentation exists for the area of code being modified, and if so,
>whether the submitted patch should also patch the documentation.
> 
> I am wondering whether this is something which could be addressed. One 
> possibility may be to have SUPPORT.md point to documentation. But that is 
> kind of assuming that SUPPORT.md works and is widely used. There may be 
> better or orthogonal ways to point to relevant docs (e.g. by pointing to docs 
> in header files and other source files). 
> 
>Reviewers tend to be fairly good at noticing patches which also need to
>patch docs/misc/xen-command-line.pandoc (submitters, less so), but this
>approach needs extending to the whole of the sphinx docs (which in turn
>requires the docs to stay high quality so its easy for maintainers to
>know what is where).
> 
> Although this does not apply in my proposal, I think the key issue has been 
> that reviewers and submitters of code often don't use our documentation. The 
> wiki is seen as a separate thing and also has the disadvantage that it 
> doesn't lend itself to supporting different versions of Xen. And most of the 
> time, developers do not use it and neither contribute to it.
> 
> My hope was that by hosting documentation related to contribution workflow 
> and other essential tasks close to other useful documentation this would 
> enable change.
> 
> @Andy and others: I need to know whether you agree with my proposal and 
> whether anyone has other suggestions.

If not already present in the release manager process checklist, we could 
specify documentation-related updates for each release, e.g. minimum text for 
new features, revisions to modified features, SUPPORT.md updates.

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

[Xen-devel] [linux-4.14 test] 138388: tolerable FAIL - PUSHED

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linuxa5758c5311775625be7f6dd54757ed356dbf2977
baseline version:
 linuxbb263a2a2d4380a56edab6dce5a2c064769676fb

Last test of basis   138099  2019-06-20 08:28:33 Z5 days
Testing same since   138282  2019-06-22 06:40:45 Z3 days2 attempts


People who touched revisions under test:
  Ajay Kaher 
  Al Viro 
  Alexander Lochmann 
  Amit Cohen 
  Andrea Arcangeli 
  Andrew Morton 
  Anju T Sudhakar 
  Arnaldo Carvalho de Melo 
  Bard Liao 
  Benjamin Tissoires 
  Borislav Petkov 
  Christoph Hellwig 
  Dan Carpenter 
  David S. Miller 
  Dmitry Bogdanov 
  Don Brace 
  Eric

[Xen-devel] [xen-unstable-smoke test] 138493: regressions - trouble: blocked/fail

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days4 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich

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

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf be5903ad1e244cbb0930161fb361ed0b699c4cb8
baseline version:
 ovmf 719a684d7df1b5b5627f42447be4f12aab038343

Last test of basis   138234  2019-06-21 20:47:50 Z3 days
Testing same since   138392  2019-06-24 01:39:04 Z1 days1 attempts


People who touched revisions under test:
  Bret Barkelew 
  Chu, Maggie 
  Maggie Chu 
  Zhichao gao 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   719a684d7d..be5903ad1e  be5903ad1e244cbb0930161fb361ed0b699c4cb8 -> 
xen-tested-master

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

[Xen-devel] [xen-unstable-smoke test] 138489: regressions - trouble: blocked/fail

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days3 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich

Re: [Xen-devel] Migrating key developer docs to xen.git sphinx docs and refreshing them in the process

On 25/06/2019 17:34, Lars Kurth wrote:
>
> On 25/06/2019, 14:47, "Andrew Cooper"  wrote:
>
> On 25/06/2019 13:15, Lars Kurth wrote:
> > On 25/06/2019, 10:03, "Julien Grall"  wrote:
> >
> > >>> The point here is that we can be flexible and creative about 
> the way to
> > >>> maintain the docs on xen.git. But as a technology is certainly 
> better
> > >>> than the wiki: we don't have to keep them all up-to-date with 
> the code,
> > >>> but at least this way we have a chance (if we want to). If we 
> leave them
> > >>> on the wiki, there is no chance.
> > >>
> > >> I can't see how xen.git is going to be better if "we don't have 
> to keep them
> > >> all up-to-date".
> > > 
> > > That's because a contributor could add a patch at the end of a 
> series to
> > > update one of the docs, even if the doc in question comes with no
> > > promises of being up-to-date.
> > 
> > I think this is going the wrong direction. The goal of using 
> xen.git is to try 
> > to keep the documentation up-to-date.
> > 
> > I agree with Julien and this was also not my intention. The reason why 
> I brought this up now is that the in-tree docs are pretty much a mess today 
> and are stale in many ways. And they look TERRIBLE and are not easily 
> searchable. However, Andy's latest set of patches provide an opportunity to 
> consolidate some of the in-tree docs in a nicely rendered and searchable 
> format.
> 
> So the plan here is to get a consistent and uniform set of high quality
> docs.
> 
> As fair warning, I'm intending to be fairly strict with what goes in
> (quality wise), because I'm going to do my best to ensure that the
> sphinx documentation doesn't devolve into the mess that wiki or the
> majority of docs/ currently is.
>
> I wholeheartedly agree
> 
> > I have been focussing on process related and key developer related 
> docs, because who maintains them is not actually an issue in theory. Everyone 
> really ought to care, because everyone is impacted by these.
> 
> The key point is for maintainers/reviewers to be aware of whether
> documentation exists for the area of code being modified, and if so,
> whether the submitted patch should also patch the documentation.
>
> I am wondering whether this is something which could be addressed. One 
> possibility may be to have SUPPORT.md point to documentation. But that is 
> kind of assuming that SUPPORT.md works and is widely used. There may be 
> better or orthogonal ways to point to relevant docs (e.g. by pointing to docs 
> in header files and other source files).
> 
> Reviewers tend to be fairly good at noticing patches which also need to
> patch docs/misc/xen-command-line.pandoc (submitters, less so), but this
> approach needs extending to the whole of the sphinx docs (which in turn
> requires the docs to stay high quality so its easy for maintainers to
> know what is where).
> 
> Although this does not apply in my proposal, I think the key issue has been 
> that reviewers and submitters of code often don't use our documentation. The 
> wiki is seen as a separate thing and also has the disadvantage that it 
> doesn't lend itself to supporting different versions of Xen. And most of the 
> time, developers do not use it and neither contribute to it.

It is a positive feedback cycle.  Noone uses our documentation because
its terrible, so the documentation stays in a terrible state.

As soon as the docs start to improve, the awareness will improve.

That said, there is still a responsibility for maintainers to be aware
of the documentation for their own areas, and to ensure the
documentation is maintained to the same high standard as we expect from
our code.

>
> My hope was that by hosting documentation related to contribution workflow 
> and other essential tasks close to other useful documentation this would 
> enable change.
>
> @Andy and others: I need to know whether you agree with my proposal and 
> whether anyone has other suggestions.

Absolutely.  "how to submit changes" is one of the most cited wiki
pages, and having that in sphinx will cause loads of people to be aware
that we do have other docs in sphinx as well.  The fact that everything
is properly indexed is a massive benefit here.

~Andrew

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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 6 kernel-build fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
133580

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

version targeted for testing:
 linux4b972a01a7da614b4796475f933094751a295a2f
baseline version:
 linux736706bee3298208343a76096370e4f6a5c55915

Last test of basis   133580  2019-03-04 19:53:09 Z  112 days
Failing since133605  2019-03-05 20:03:14 Z  111 days   57 attempts
Testing same since   138386  2019-06-23 19:51:35 Z1 days1 attempts


3386 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-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

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

2019-06-25 Thread Lars Kurth

Hi all:
please add your agenda items. I had only ONE series which was highlighted as 
needing attention from others. Is this seriously the only one?
Regards
Lars

On 21/06/2019, 16:45, "Lars Kurth"  wrote:

Hi all,

Please propose topics by either editing the running agenda document at 
https://cryptpad.fr/pad/#/2/pad/edit/V-JctV2vBlEnwliVLBlFLY7n/ or by replying 
to the mail.

Note that currently I have
* Nothing under: 
   D) New Series / Series that need attention / Series that are important
* A prep item for the developer summit proposed by Jan at the last meeting
I also made some progress on the code of conduct topic and am about to send 
a mail to xen-devel@

Best Regards
Lars

== Dial-in Information ==

 ## Meeting time
 15:00 - 16:00 UTC
 Further International meeting times: 
 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=6=27=15=0=0=225=224=24=179=136=37=33

 ## Dial in details
 Web: https://www.gotomeet.me/larskurth

 You can also dial in using your phone.
 Access Code: 906-886-965

 China (Toll Free): 4008 811084
 Germany: +49 692 5736 7317
 Poland (Toll Free): 00 800 1124759
 United Kingdom: +44 330 221 0088
 United States: +1 (571) 317-3129

 More phone numbers
 Australia: +61 2 9087 3604
 Austria: +43 7 2081 5427
 Argentina (Toll Free): 0 800 444 3375
 Bahrain (Toll Free): 800 81 111
 Belarus (Toll Free): 8 820 0011 0400
 Belgium: +32 28 93 7018
 Brazil (Toll Free): 0 800 047 4906
 Bulgaria (Toll Free): 00800 120 4417
 Canada: +1 (647) 497-9391
 Chile (Toll Free): 800 395 150
 Colombia (Toll Free): 01 800 518 4483
  Czech Republic (Toll Free): 800 500448
 Denmark: +45 32 72 03 82
 Finland: +358 923 17 0568
 France: +33 170 950 594
 Greece (Toll Free): 00 800 4414 3838
 Hong Kong (Toll Free): 30713169
 Hungary (Toll Free): (06) 80 986 255
 Iceland (Toll Free): 800 7204
 India (Toll Free): 18002669272
 Indonesia (Toll Free): 007 803 020 5375
 Ireland: +353 15 360 728
 Israel (Toll Free): 1 809 454 830
 Italy: +39 0 247 92 13 01
 Japan (Toll Free): 0 120 663 800
 Korea, Republic of (Toll Free): 00798 14 207 4914
 Luxembourg (Toll Free): 800 85158
 Malaysia (Toll Free): 1 800 81 6854
 Mexico (Toll Free): 01 800 522 1133
 Netherlands: +31 207 941 377
 New Zealand: +64 9 280 6302
 Norway: +47 21 93 37 51
 Panama (Toll Free): 00 800 226 7928
 Peru (Toll Free): 0 800 77023
 Philippines (Toll Free): 1 800 1110 1661
 Portugal (Toll Free): 800 819 575
 Romania (Toll Free): 0 800 410 029
 Russian Federation (Toll Free): 8 800 100 6203
 Saudi Arabia (Toll Free): 800 844 3633
 Singapore (Toll Free): 18007231323
 South Africa (Toll Free): 0 800 555 447
 Spain: +34 932 75 2004
 Sweden: +46 853 527 827
 Switzerland: +41 225 4599 78
 Taiwan (Toll Free): 0 800 666 854
 Thailand (Toll Free): 001 800 011 023
 Turkey (Toll Free): 00 800 4488 23683
 Ukraine (Toll Free): 0 800 50 1733
 United Arab Emirates (Toll Free): 800 044 40439
 Uruguay (Toll Free): 0004 019 1018
 Viet Nam (Toll Free): 122 80 481

 First GoToMeeting? Let's do a quick system check:
 https://link.gotomeeting.com/system-check









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

Re: [Xen-devel] Migrating key developer docs to xen.git sphinx docs and refreshing them in the process

2019-06-25 Thread Lars Kurth

On 25/06/2019, 14:47, "Andrew Cooper"  wrote:

On 25/06/2019 13:15, Lars Kurth wrote:
> On 25/06/2019, 10:03, "Julien Grall"  wrote:
>
> >>> The point here is that we can be flexible and creative about the 
way to
> >>> maintain the docs on xen.git. But as a technology is certainly 
better
> >>> than the wiki: we don't have to keep them all up-to-date with the 
code,
> >>> but at least this way we have a chance (if we want to). If we 
leave them
> >>> on the wiki, there is no chance.
> >>
> >> I can't see how xen.git is going to be better if "we don't have to 
keep them
> >> all up-to-date".
> > 
> > That's because a contributor could add a patch at the end of a 
series to
> > update one of the docs, even if the doc in question comes with no
> > promises of being up-to-date.
> 
> I think this is going the wrong direction. The goal of using xen.git 
is to try 
> to keep the documentation up-to-date.
> 
> I agree with Julien and this was also not my intention. The reason why I 
brought this up now is that the in-tree docs are pretty much a mess today and 
are stale in many ways. And they look TERRIBLE and are not easily searchable. 
However, Andy's latest set of patches provide an opportunity to consolidate 
some of the in-tree docs in a nicely rendered and searchable format.

So the plan here is to get a consistent and uniform set of high quality
docs.

As fair warning, I'm intending to be fairly strict with what goes in
(quality wise), because I'm going to do my best to ensure that the
sphinx documentation doesn't devolve into the mess that wiki or the
majority of docs/ currently is.

I wholeheartedly agree

> I have been focussing on process related and key developer related docs, 
because who maintains them is not actually an issue in theory. Everyone really 
ought to care, because everyone is impacted by these.

The key point is for maintainers/reviewers to be aware of whether
documentation exists for the area of code being modified, and if so,
whether the submitted patch should also patch the documentation.

I am wondering whether this is something which could be addressed. One 
possibility may be to have SUPPORT.md point to documentation. But that is kind 
of assuming that SUPPORT.md works and is widely used. There may be better or 
orthogonal ways to point to relevant docs (e.g. by pointing to docs in header 
files and other source files). 

Reviewers tend to be fairly good at noticing patches which also need to
patch docs/misc/xen-command-line.pandoc (submitters, less so), but this
approach needs extending to the whole of the sphinx docs (which in turn
requires the docs to stay high quality so its easy for maintainers to
know what is where).

Although this does not apply in my proposal, I think the key issue has been 
that reviewers and submitters of code often don't use our documentation. The 
wiki is seen as a separate thing and also has the disadvantage that it doesn't 
lend itself to supporting different versions of Xen. And most of the time, 
developers do not use it and neither contribute to it.

My hope was that by hosting documentation related to contribution workflow and 
other essential tasks close to other useful documentation this would enable 
change.

@Andy and others: I need to know whether you agree with my proposal and whether 
anyone has other suggestions.

Regards
Lars

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

[Xen-devel] [xen-unstable-smoke test] 138485: regressions - trouble: blocked/fail

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Failing since138482  2019-06-25 15:00:47 Z0 days2 attempts
Testing same since   138485  2019-06-25 16:00:57 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:53 2019 +0200

drop __get_cpu_var() and __get_cpu_ptr()

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich 
Date:   Tue Jun 25 17:34:11 2019 +0200

x86: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich 
Date:   Tue Jun 25 17:33:40 2019 +0200

x86/mcheck: replace remaining uses of __get_cpu_var()

this_cpu() is shorter, and when there are multiple uses in a function
per_cpu() it's also more efficient.

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

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich 
Date:   Tue Jun 25 17:32:37 2019 +0200

x86/mcheck: allow varying bank counts per CPU

Up to now we've been assuming that all CPUs would have the same number
of reporting banks. However, on upcoming AMD CPUs this isn't the case,
and one can observe

(XEN) mce.c:666: Different bank number on cpu 

indicating that Machine Check support would not be enabled on the
affected CPUs. Convert the count variable to a per-CPU one, and adjust
code where needed to cope with the values not being the same. In
particular the mcabanks_alloc() invocations during AP bringup need to
now allocate maximum-size bitmaps, because the truly needed size can't
be known until we actually execute on that CPU, yet mcheck_init() gets
called too early to do any allocations itself.

Take the liberty and also
- make mca_cap_init() static,
- replace several __get_cpu_var() uses when a local variable suitable
  for use with per_cpu() appears,
- correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
- replace a BUG() by panic().

Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH 3/3] page-alloc: Clamp get_free_buddy() to online nodes

On 25/06/2019 16:51, Jan Beulich wrote:
 On 25.06.19 at 16:43,  wrote:
>> d->node_affinity defaults to NODE_MASK_ALL which has bits set outside of
>> node_online_map.  This in turn causes the loop in get_free_buddy() to waste
>> effort iterating over offline nodes.
>>
>> Always clamp d->node_affinity to node_online_map when in use.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
> despite ...
>
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -811,11 +811,15 @@ static struct page_info *get_free_buddy(unsigned int 
>> zone_lo,
>>  const struct domain *d)
>>  {
>>  nodeid_t first, node = MEMF_get_node(memflags), req_node = node;
>> -nodemask_t nodemask = d ? d->node_affinity : node_online_map;
>> +nodemask_t nodemask;
>>  unsigned int j, zone, nodemask_retry = 0;
>>  struct page_info *pg;
>>  bool use_unscrubbed = (memflags & MEMF_no_scrub);
>>  
>> +/* Clamp nodemask to node_online_map and optionally d->node_affinity. */
>> +nodes_and(, _online_map,
>> +  d ? >node_affinity : _online_map);
> ... finding it a little odd (inefficient) to AND node_online_map with itself.

Well - there is an O(n) loop for the copy, and an O(n) loop for and, or
a single O(n) loop which does both when realising that foo = a & a is a
copy operation in disguise.

~Andrew

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

Re: [Xen-devel] [xen-4.6-testing test] 138333: regressions - FAIL

Jan Beulich writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> I've taken a look. The guests now triple fault during BIOS initialization:

Thanks.  Hrm.

> I wouldn't be surprised if the rombios build is broken - did you happen
> to compare those binaries? Otoh I can't seem to spot any fixes in
> master that would look like possibly addressing build issues with a
> newer tool chain (other than cases where the build itself would fail).

No, I haven't compared the rombios binaries.

> Irrespective of this I'm not really opposed to a force push as you've
> suggested, despite being afraid that this may hide an actual issue.
> That's even more so that by now 4.7 has gone out of security
> support, and hence we only need it now for 4.8's -prev tests.

Indeed, precisely.  Are happy with me doing a force push now ?

Ian.

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

Re: [Xen-devel] [PATCH 3/3] page-alloc: Clamp get_free_buddy() to online nodes

>>> On 25.06.19 at 16:43,  wrote:
> d->node_affinity defaults to NODE_MASK_ALL which has bits set outside of
> node_online_map.  This in turn causes the loop in get_free_buddy() to waste
> effort iterating over offline nodes.
> 
> Always clamp d->node_affinity to node_online_map when in use.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
despite ...

> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -811,11 +811,15 @@ static struct page_info *get_free_buddy(unsigned int 
> zone_lo,
>  const struct domain *d)
>  {
>  nodeid_t first, node = MEMF_get_node(memflags), req_node = node;
> -nodemask_t nodemask = d ? d->node_affinity : node_online_map;
> +nodemask_t nodemask;
>  unsigned int j, zone, nodemask_retry = 0;
>  struct page_info *pg;
>  bool use_unscrubbed = (memflags & MEMF_no_scrub);
>  
> +/* Clamp nodemask to node_online_map and optionally d->node_affinity. */
> +nodes_and(, _online_map,
> +  d ? >node_affinity : _online_map);

... finding it a little odd (inefficient) to AND node_online_map with itself.

Jan



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

Re: [Xen-devel] [PATCH 4/3] nodemask: Don't opencode cycle_node()

>>> On 25.06.19 at 16:58,  wrote:
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 2/3] nodemask: Remove implicit addressof from the API

>>> On 25.06.19 at 16:43,  wrote:
> The nodemask API differs from the cpumask API because each wrapper to bitmap
> operations is further wrapped by a macro which takes the address of the
> nodemask objects.
> 
> This results in code which is slightly confusing to read as it doesn't follow
> C's calling conventions, and prohibits the use of slightly more complicated
> constructs for specifying parameters.
> 
> Drop all wrapping macros, rename the nodemask static inline functions to drop
> the double underscores, and feed MAX_NUMNODES into appropriate locations.
> 
> Take the opportunity to drop a compiler workaround for node_isset() for GCC
> 3.3.2 which is long out of support, and implment it with a static inline.
> 
> Update all callers to use the correct indirection themselves.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

I'm okay with this in principle, so
Acked-by: Jan Beulich 
(with one aspect addressed below), but to be honest I would
have hoped that the switch to the cpumask.h model would also
imply a switch to the naming used there (e.g. nodemask_and()).
This would have provided the opportunity to not do the entire
switch in one patch.

> -/* No static inline type checking - see Subtlety (1) above. */
> -#define node_isset(node, nodemask) test_bit((node), (nodemask).bits)
> +static inline int node_isset(int node, const nodemask_t *src)
> +{
> + return test_bit(node, src->bits);
> +}

Since this is a new function, could I ask that you make it return bool?
(Same for the test_and_... and a few others below then.) And (also
elsewhere) could I further ask that plain int be switched to unsigned
int at this occasion?

> -#define nodes_shift_right(dst, src, n) \
> - __nodes_shift_right(&(dst), &(src), (n), MAX_NUMNODES)
> -static inline void __nodes_shift_right(nodemask_t *dstp,
> - const nodemask_t *srcp, int n, int 
> nbits)
> +static inline void nodes_shift_right(nodemask_t *dstp, const nodemask_t 
> *srcp,
> +  int n)
>  {
> - bitmap_shift_right(dstp->bits, srcp->bits, n, nbits);
> + bitmap_shift_right(dstp->bits, srcp->bits, n, MAX_NUMNODES);
>  }
>  
> -#define nodes_shift_left(dst, src, n) \
> - __nodes_shift_left(&(dst), &(src), (n), MAX_NUMNODES)
> -static inline void __nodes_shift_left(nodemask_t *dstp,
> - const nodemask_t *srcp, int n, int 
> nbits)
> +static inline void nodes_shift_left(nodemask_t *dstp, const nodemask_t *srcp,
> + int n)
>  {
> - bitmap_shift_left(dstp->bits, srcp->bits, n, nbits);
> + bitmap_shift_left(dstp->bits, srcp->bits, n, MAX_NUMNODES);
>  }

How about ditching rather than adjusting these two?

Jan



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

Re: [Xen-devel] [PATCH 1/3] page-alloc: Rename the first_node local variable

>>> On 25.06.19 at 16:43,  wrote:
> first_node is the name of a local variable, and part of the nodemask API.  The
> only reason this compiles is because the nodemask API is implemented as a
> macro rather than an inline function.
> 
> It is confusing to read, and breaks when the nodemask API is cleaned up.
> Rename the local variable to just 'first' which is still clear in context.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



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

[Xen-devel] [xen-unstable-smoke test] 138482: regressions - trouble: blocked/fail

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 138424
 build-arm64-xsm   6 xen-buildfail REGR. vs. 138424
 build-armhf   6 xen-buildfail REGR. vs. 138424

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  b41666f2c17f01c437c870389ab713ee62ae3526
baseline version:
 xen  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z1 days
Testing same since   138482  2019-06-25 15:00:47 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit b41666f2c17f01c437c870389ab713ee62ae3526
Author: Roger Pau Monné 
Date:   Tue Jun 25 15:39:44 2019 +0200

config: don't hardcode toolchain binaries

Currently the names of the build toolchain binaries are hardcoded in
StdGNU.mk, and the values from the environment are ignored.

Switch StdGNU.mk to use '?=' instead of '=', so that values from the
environment are used if present, else default to the values provided
by the config file.

This change fixes the gitlab CI loop, that was relying on passing
custom values in the environment variables for the compiler and the
linker.

Signed-off-by: Roger Pau Monné 
Acked-by: Andrew Cooper 
Acked-by: Ian Jackson 
(qemu changes not included)

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

Re: [Xen-devel] [xen-4.6-testing test] 138333: regressions - FAIL

>>> On 25.06.19 at 16:12,  wrote:
> Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
>> Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
>> > Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - 
>> > FAIL"):
>> > > Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - 
>> > > FAIL"):
>> > > > These all have `qemut' in common.
>> ...
>> > I'm trying a test with 4.7's version of qemu trad.
>> 
>> This does not work.  4.7's qemu trad doesn't build because of tools
>> library reorganisation.  Reverting those changes to 4.7 produces a
>> qemu trad that is identical to 4.6's.  So the regression is not in
>> qemu.
>> 
>> I suspect a firmware or hvmloader problem.
>> 
>> This is blocking us getting a push for the Xen 4.8 stable branches:
> 
> These have not had a push for, in the case of 4.9, 133 days.

Yes, I had noticed this too. Embarrassing.

> Unless someone explains to me a plan for how to get 4.6 to actually
> work again well enough to test 4.7, or some other better proposal, I
> intend to force push 4.6 at the end of this week.

I've taken a look. The guests now triple fault during BIOS initialization:

(d1218) 18124 bytes of ROMBIOS high-memory extensions:
(d1218)   Relocating to 0xfc001000-0xfc0056cc ... done
...
(XEN) d1218v0 Triple fault - invoking HVM shutdown action 1
(XEN) *** Dumping Dom1218 vcpu#0 state: ***
(XEN) [ Xen-4.6.6  x86_64  debug=y  Not tainted ]
(XEN) CPU:0
(XEN) RIP:0008:[]

[Note in particular this address.]

(XEN) RFLAGS: 00010086   CONTEXT: hvm guest (d1218v0)
(XEN) rax: fc004369   rbx: fc0040e9   rcx: 0002
(XEN) rdx: fc004307   rsi:    rdi: 0020
(XEN) rbp: 0009eed2   rsp: 0009ee96   r8:  
(XEN) r9:     r10:    r11: 
(XEN) r12:    r13:    r14: 
(XEN) r15:    cr0: 0011   cr4: 
(XEN) cr3:    cr2: 
(XEN) ds: 0018   es: 0018   fs:    gs: c900   ss: 0018   cs: 0008

I wouldn't be surprised if the rombios build is broken - did you happen
to compare those binaries? Otoh I can't seem to spot any fixes in
master that would look like possibly addressing build issues with a
newer tool chain (other than cases where the build itself would fail).

Irrespective of this I'm not really opposed to a force push as you've
suggested, despite being afraid that this may hide an actual issue.
That's even more so that by now 4.7 has gone out of security
support, and hence we only need it now for 4.8's -prev tests.

Jan



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

[Xen-devel] [PATCH 4/3] nodemask: Don't opencode cycle_node()

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: George Dunlap 
---
 xen/arch/x86/numa.c | 4 +---
 xen/common/page_alloc.c | 7 ++-
 2 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index c36c69e842..f7d320f207 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -192,9 +192,7 @@ void __init numa_init_array(void)
 if ( cpu_to_node[i] != NUMA_NO_NODE )
 continue;
 numa_set_node(i, rr);
-rr = next_node(rr, _online_map);
-if ( rr == MAX_NUMNODES )
-rr = first_node(_online_map);
+rr = cycle_node(rr, _online_map);
 }
 }
 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index fe1159b352..8858766c97 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -823,11 +823,8 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 if ( node == NUMA_NO_NODE )
 {
 if ( d != NULL )
-{
-node = next_node(d->last_alloc_node, );
-if ( node >= MAX_NUMNODES )
-node = first_node();
-}
+node = cycle_node(d->last_alloc_node, );
+
 if ( node >= MAX_NUMNODES )
 node = cpu_to_node(smp_processor_id());
 }
-- 
2.11.0


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

[Xen-devel] [PATCH 2/3] nodemask: Remove implicit addressof from the API

The nodemask API differs from the cpumask API because each wrapper to bitmap
operations is further wrapped by a macro which takes the address of the
nodemask objects.

This results in code which is slightly confusing to read as it doesn't follow
C's calling conventions, and prohibits the use of slightly more complicated
constructs for specifying parameters.

Drop all wrapping macros, rename the nodemask static inline functions to drop
the double underscores, and feed MAX_NUMNODES into appropriate locations.

Take the opportunity to drop a compiler workaround for node_isset() for GCC
3.3.2 which is long out of support, and implment it with a static inline.

Update all callers to use the correct indirection themselves.

No functional change.

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

v2:
 * New
---
 xen/arch/x86/dom0_build.c  |  12 +--
 xen/arch/x86/numa.c|   8 +-
 xen/arch/x86/srat.c|  15 ++--
 xen/common/domain.c|   8 +-
 xen/common/page_alloc.c|  28 +++
 xen/common/sched_credit.c  |   2 +-
 xen/common/sysctl.c|   2 +-
 xen/include/xen/nodemask.h | 181 ++---
 8 files changed, 110 insertions(+), 146 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index c69570920c..4af2ee0091 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -231,7 +231,7 @@ unsigned int __init dom0_max_vcpus(void)
 
 if ( pv_shim )
 {
-nodes_setall(dom0_nodes);
+nodes_setall(_nodes);
 
 /*
  * When booting in shim mode APs are not started until the guest brings
@@ -246,11 +246,11 @@ unsigned int __init dom0_max_vcpus(void)
 
 for ( i = 0; i < dom0_nr_pxms; ++i )
 if ( (node = pxm_to_node(dom0_pxms[i])) != NUMA_NO_NODE )
-node_set(node, dom0_nodes);
-nodes_and(dom0_nodes, dom0_nodes, node_online_map);
-if ( nodes_empty(dom0_nodes) )
+node_set(node, _nodes);
+nodes_and(_nodes, _nodes, _online_map);
+if ( nodes_empty(_nodes) )
 dom0_nodes = node_online_map;
-for_each_node_mask ( node, dom0_nodes )
+for_each_node_mask ( node, _nodes )
 cpumask_or(_cpus, _cpus, _to_cpumask(node));
 cpumask_and(_cpus, _cpus, cpupool0->cpu_valid);
 if ( cpumask_empty(_cpus) )
@@ -344,7 +344,7 @@ unsigned long __init dom0_compute_nr_pages(
 if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
 parse_dom0_mem(CONFIG_DOM0_MEM);
 
-for_each_node_mask ( node, dom0_nodes )
+for_each_node_mask ( node, _nodes )
 avail += avail_domheap_pages_region(node, 0, 0) +
  initial_images_nrpages(node);
 
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index b3c9c12d7f..c36c69e842 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -186,15 +186,15 @@ void __init numa_init_array(void)
mapping. To avoid this fill in the mapping for all possible
CPUs, as the number of CPUs is not known yet.
We round robin the existing nodes. */
-rr = first_node(node_online_map);
+rr = first_node(_online_map);
 for ( i = 0; i < nr_cpu_ids; i++ )
 {
 if ( cpu_to_node[i] != NUMA_NO_NODE )
 continue;
 numa_set_node(i, rr);
-rr = next_node(rr, node_online_map);
+rr = next_node(rr, _online_map);
 if ( rr == MAX_NUMNODES )
-rr = first_node(node_online_map);
+rr = first_node(_online_map);
 }
 }
 
@@ -271,7 +271,7 @@ void __init numa_initmem_init(unsigned long start_pfn, 
unsigned long end_pfn)
 /* setup dummy node covering all memory */
 memnode_shift = BITS_PER_LONG - 1;
 memnodemap = _memnodemap;
-nodes_clear(node_online_map);
+nodes_clear(_online_map);
 node_set_online(0);
 for ( i = 0; i < nr_cpu_ids; i++ )
 numa_set_node(i, 0);
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index 47a4267220..348bcfea73 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -228,7 +228,7 @@ acpi_numa_x2apic_affinity_init(const struct 
acpi_srat_x2apic_cpu_affinity *pa)
}
 
apicid_to_node[pa->apic_id] = node;
-   node_set(node, processor_nodes_parsed);
+   node_set(node, _nodes_parsed);
acpi_numa = 1;
printk(KERN_INFO "SRAT: PXM %u -> APIC %08x -> Node %u\n",
   pxm, pa->apic_id, node);
@@ -261,7 +261,7 @@ acpi_numa_processor_affinity_init(const struct 
acpi_srat_cpu_affinity *pa)
return;
}
apicid_to_node[pa->apic_id] = node;
-   node_set(node, processor_nodes_parsed);
+   node_set(node, _nodes_parsed);
acpi_numa = 1;
printk(KERN_INFO "SRAT: PXM %u -> APIC %02x -> Node %u\n",
   pxm, pa->apic_id, node);
@@ -332,7 +332,7 @@ acpi_numa_memory_affinity_init(const struct 
acpi_srat_mem_affinity *ma)
if (!(ma->flags &

[Xen-devel] [PATCH 3/3] page-alloc: Clamp get_free_buddy() to online nodes

d->node_affinity defaults to NODE_MASK_ALL which has bits set outside of
node_online_map.  This in turn causes the loop in get_free_buddy() to waste
effort iterating over offline nodes.

Always clamp d->node_affinity to node_online_map when in use.

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

v2:
 * Rebase over the nodemask API change, and implement with a single
   nodes_and()
---
 xen/common/page_alloc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 7bba5b0b2e..fe1159b352 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -811,11 +811,15 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 const struct domain *d)
 {
 nodeid_t first, node = MEMF_get_node(memflags), req_node = node;
-nodemask_t nodemask = d ? d->node_affinity : node_online_map;
+nodemask_t nodemask;
 unsigned int j, zone, nodemask_retry = 0;
 struct page_info *pg;
 bool use_unscrubbed = (memflags & MEMF_no_scrub);
 
+/* Clamp nodemask to node_online_map and optionally d->node_affinity. */
+nodes_and(, _online_map,
+  d ? >node_affinity : _online_map);
+
 if ( node == NUMA_NO_NODE )
 {
 if ( d != NULL )
-- 
2.11.0


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

[Xen-devel] [PATCH 1/3] page-alloc: Rename the first_node local variable

first_node is the name of a local variable, and part of the nodemask API.  The
only reason this compiles is because the nodemask API is implemented as a
macro rather than an inline function.

It is confusing to read, and breaks when the nodemask API is cleaned up.
Rename the local variable to just 'first' which is still clear in context.

No functional change.

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

v2:
 * New
---
 xen/common/page_alloc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 7825fd8c42..7bbb44f7d1 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -810,7 +810,7 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 unsigned int order, unsigned int 
memflags,
 const struct domain *d)
 {
-nodeid_t first_node, node = MEMF_get_node(memflags), req_node = node;
+nodeid_t first, node = MEMF_get_node(memflags), req_node = node;
 nodemask_t nodemask = d ? d->node_affinity : node_online_map;
 unsigned int j, zone, nodemask_retry = 0;
 struct page_info *pg;
@@ -832,7 +832,7 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 ASSERT_UNREACHABLE();
 return NULL;
 }
-first_node = node;
+first = node;
 
 /*
  * Start with requested node, but exhaust all node memory in requested
@@ -878,19 +878,19 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 {
 /* Very first node may be caller-specified and outside nodemask. */
 ASSERT(!nodemask_retry);
-first_node = node = first_node(nodemask);
+first = node = first_node(nodemask);
 if ( node < MAX_NUMNODES )
 continue;
 }
 else if ( (node = next_node(node, nodemask)) >= MAX_NUMNODES )
 node = first_node(nodemask);
-if ( node == first_node )
+if ( node == first )
 {
 /* When we have tried all in nodemask, we fall back to others. */
 if ( (memflags & MEMF_exact_node) || nodemask_retry++ )
 return NULL;
 nodes_andnot(nodemask, node_online_map, nodemask);
-first_node = node = first_node(nodemask);
+first = node = first_node(nodemask);
 if ( node >= MAX_NUMNODES )
 return NULL;
 }
-- 
2.11.0


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

[Xen-devel] [PATCH v2 0/3] nodemask: API cleanup and fixes

This series supersedes the single "page-alloc: Clamp get_free_buddy() to
online nodes" patch, and performs some preparatory cleanup.

Andrew Cooper (3):
  page-alloc: Rename the first_node local variable
  nodemask: Remove implicit addressof from the API
  page-alloc: Clamp get_free_buddy() to online nodes

 xen/arch/x86/dom0_build.c  |  12 +--
 xen/arch/x86/numa.c|   8 +-
 xen/arch/x86/srat.c|  15 ++--
 xen/common/domain.c|   8 +-
 xen/common/page_alloc.c|  40 +-
 xen/common/sched_credit.c  |   2 +-
 xen/common/sysctl.c|   2 +-
 xen/include/xen/nodemask.h | 181 ++---
 8 files changed, 118 insertions(+), 150 deletions(-)

-- 
2.11.0


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

Re: [Xen-devel] [PATCH 3/4] x86/linker: add a reloc section to ELF binary

>>> On 25.06.19 at 14:48,  wrote:
> On Tue, Jun 25, 2019 at 01:08:49PM +0200, Roger Pau Monné wrote:
>> Sorry for not being clear. By remove I mean `git rm
>> xen/arch/x86/efi/relocs-dummy.S` and fix the build, like the diff
>> appended below.
> 
> The chunk below will not work because relocs-dummy is also needed
> by the EFI build. I'm however lost at why this is required, and the
> commit message that introduced the file (bf6501a62e) doesn't add any
> reasoning.
> 
> Is maybe .reloc mandatory for PE format?

Yes, almost. You _can_ have one without .reloc, but then you're tied
to it loading at the linked address. That's fine with an ordinary boot
loader, but it's not an option when this is to get loaded just like a
normal binary, without knowing at which address it'll be placed.
Remember that the EFI boot environment runs in (pseudo)physical
mode, i.e. there's a 1:1 mapping between linear and physical
addresses. Therefore there's no way to predict a memory range
that's always going to be available (and that hence xen.efi could be
linked to load at).

Jan

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

Re: [Xen-devel] [xen-4.6-testing test] 138333: regressions - FAIL

Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> > Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - 
> > FAIL"):
> > > Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - 
> > > FAIL"):
> > > > These all have `qemut' in common.
> ...
> > I'm trying a test with 4.7's version of qemu trad.
> 
> This does not work.  4.7's qemu trad doesn't build because of tools
> library reorganisation.  Reverting those changes to 4.7 produces a
> qemu trad that is identical to 4.6's.  So the regression is not in
> qemu.
> 
> I suspect a firmware or hvmloader problem.
> 
> This is blocking us getting a push for the Xen 4.8 stable branches:

These have not had a push for, in the case of 4.9, 133 days.

Unless someone explains to me a plan for how to get 4.6 to actually
work again well enough to test 4.7, or some other better proposal, I
intend to force push 4.6 at the end of this week.

If, as expected, this causes 4.7 to work except for some or all of the
4.6->4.7 migration tests, I will force push 4.7 too.

Ian.

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

Re: [Xen-devel] [PATCH 3/4] x86/linker: add a reloc section to ELF binary

>>> On 25.06.19 at 13:08,  wrote:
> Sorry for not being clear. By remove I mean `git rm
> xen/arch/x86/efi/relocs-dummy.S` and fix the build, like the diff
> appended below.
> 
> Is there any reason we should keep the dummy .reloc in the ELF
> output?

Yes, there is. And yes, I was afraid you'd mean this.

> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -39,6 +39,7 @@ extern const intpte_t __page_tables_start[], 
> __page_tables_end[];
>  #define PE_BASE_RELOC_HIGHLOW  3
>  #define PE_BASE_RELOC_DIR64   10
>  
> +#ifdef XEN_BUILD_PE

This is an identifier available to Makefiles only. You also can't propagate
it to .c files, as these get compiled just once to produce _both_ PE and
ELF binary. So while what you suggest may build, it'll result in a broken
xen.efi.

Jan

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

Re: [Xen-devel] Migrating key developer docs to xen.git sphinx docs and refreshing them in the process

On 25/06/2019 13:15, Lars Kurth wrote:
> On 25/06/2019, 10:03, "Julien Grall"  wrote:
>
> >>> The point here is that we can be flexible and creative about the way 
> to
> >>> maintain the docs on xen.git. But as a technology is certainly better
> >>> than the wiki: we don't have to keep them all up-to-date with the 
> code,
> >>> but at least this way we have a chance (if we want to). If we leave 
> them
> >>> on the wiki, there is no chance.
> >>
> >> I can't see how xen.git is going to be better if "we don't have to 
> keep them
> >> all up-to-date".
> > 
> > That's because a contributor could add a patch at the end of a series to
> > update one of the docs, even if the doc in question comes with no
> > promises of being up-to-date.
> 
> I think this is going the wrong direction. The goal of using xen.git is 
> to try 
> to keep the documentation up-to-date.
> 
> I agree with Julien and this was also not my intention. The reason why I 
> brought this up now is that the in-tree docs are pretty much a mess today and 
> are stale in many ways. And they look TERRIBLE and are not easily searchable. 
> However, Andy's latest set of patches provide an opportunity to consolidate 
> some of the in-tree docs in a nicely rendered and searchable format.

So the plan here is to get a consistent and uniform set of high quality
docs.

As fair warning, I'm intending to be fairly strict with what goes in
(quality wise), because I'm going to do my best to ensure that the
sphinx documentation doesn't devolve into the mess that wiki or the
majority of docs/ currently is.

> I have been focussing on process related and key developer related docs, 
> because who maintains them is not actually an issue in theory. Everyone 
> really ought to care, because everyone is impacted by these.

The key point is for maintainers/reviewers to be aware of whether
documentation exists for the area of code being modified, and if so,
whether the submitted patch should also patch the documentation.

Reviewers tend to be fairly good at noticing patches which also need to
patch docs/misc/xen-command-line.pandoc (submitters, less so), but this
approach needs extending to the whole of the sphinx docs (which in turn
requires the docs to stay high quality so its easy for maintainers to
know what is where).

~Andrew

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

Re: [Xen-devel] [PATCH] config: don't hardcode toolchain binaries

Roger Pau Monne writes ("[PATCH] config: don't hardcode toolchain binaries"):
> Currently the names of the build toolchain binaries are hardcoded in
> StdGNU.mk, and the values from the environment are ignored.
> 
> Switch StdGNU.mk to use '?=' instead of '=', so that values from the
> environment are used if present, else default to the values provided
> by the config file.
> 
> This change fixes the gitlab CI loop, that was relying on passing
> custom values in the environment variables for the compiler and the
> linker.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH] config: don't hardcode toolchain binaries

On Tue, Jun 25, 2019 at 02:41:09PM +0100, Andrew Cooper wrote:
> On 25/06/2019 14:39, Roger Pau Monne wrote:
> > Currently the names of the build toolchain binaries are hardcoded in
> > StdGNU.mk, and the values from the environment are ignored.
> >
> > Switch StdGNU.mk to use '?=' instead of '=', so that values from the
> > environment are used if present, else default to the values provided
> > by the config file.
> >
> > This change fixes the gitlab CI loop, that was relying on passing
> > custom values in the environment variables for the compiler and the
> > linker.
> >
> > Signed-off-by: Roger Pau Monné 
> 
> Acked-by: Andrew Cooper 
> 
> Do we know if the CI loop still holds together with this fixed?

Yes, I've done a test-run with this, see:

https://gitlab.com/xen-project/people/royger/xen/pipelines/67882667

No regressions, everything was still OK.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] config: don't hardcode toolchain binaries

On 25/06/2019 14:39, Roger Pau Monne wrote:
> Currently the names of the build toolchain binaries are hardcoded in
> StdGNU.mk, and the values from the environment are ignored.
>
> Switch StdGNU.mk to use '?=' instead of '=', so that values from the
> environment are used if present, else default to the values provided
> by the config file.
>
> This change fixes the gitlab CI loop, that was relying on passing
> custom values in the environment variables for the compiler and the
> linker.
>
> Signed-off-by: Roger Pau Monné 

Acked-by: Andrew Cooper 

Do we know if the CI loop still holds together with this fixed?

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

[Xen-devel] [PATCH] config: don't hardcode toolchain binaries

2019-06-25 Thread Roger Pau Monne

Currently the names of the build toolchain binaries are hardcoded in
StdGNU.mk, and the values from the environment are ignored.

Switch StdGNU.mk to use '?=' instead of '=', so that values from the
environment are used if present, else default to the values provided
by the config file.

This change fixes the gitlab CI loop, that was relying on passing
custom values in the environment variables for the compiler and the
linker.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 config/StdGNU.mk | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 039274ea61..c9624b043c 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -1,27 +1,27 @@
-AS = $(CROSS_COMPILE)as
-LD = $(CROSS_COMPILE)ld
+AS?= $(CROSS_COMPILE)as
+LD?= $(CROSS_COMPILE)ld
 ifeq ($(clang),y)
-CC = $(CROSS_COMPILE)clang
-CXX= $(CROSS_COMPILE)clang++
-LD_LTO = $(CROSS_COMPILE)llvm-ld
+CC?= $(CROSS_COMPILE)clang
+CXX   ?= $(CROSS_COMPILE)clang++
+LD_LTO?= $(CROSS_COMPILE)llvm-ld
 else
-CC = $(CROSS_COMPILE)gcc
-CXX= $(CROSS_COMPILE)g++
-LD_LTO = $(CROSS_COMPILE)ld
+CC?= $(CROSS_COMPILE)gcc
+CXX   ?= $(CROSS_COMPILE)g++
+LD_LTO?= $(CROSS_COMPILE)ld
 endif
-CPP= $(CC) -E
-AR = $(CROSS_COMPILE)ar
-RANLIB = $(CROSS_COMPILE)ranlib
-NM = $(CROSS_COMPILE)nm
-STRIP  = $(CROSS_COMPILE)strip
-OBJCOPY= $(CROSS_COMPILE)objcopy
-OBJDUMP= $(CROSS_COMPILE)objdump
-SIZEUTIL   = $(CROSS_COMPILE)size
+CPP   ?= $(CC) -E
+AR?= $(CROSS_COMPILE)ar
+RANLIB?= $(CROSS_COMPILE)ranlib
+NM?= $(CROSS_COMPILE)nm
+STRIP ?= $(CROSS_COMPILE)strip
+OBJCOPY   ?= $(CROSS_COMPILE)objcopy
+OBJDUMP   ?= $(CROSS_COMPILE)objdump
+SIZEUTIL  ?= $(CROSS_COMPILE)size
 
 # Allow git to be wrappered in the environment
 GIT?= git
 
-INSTALL  = install
+INSTALL   ?= install
 INSTALL_DIR  = $(INSTALL) -d -m0755 -p
 INSTALL_DATA = $(INSTALL) -m0644 -p
 INSTALL_PROG = $(INSTALL) -m0755 -p
-- 
2.20.1 (Apple Git-117)


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

Re: [Xen-devel] [bug report] xen-pcifront: Xen PCI frontend driver.


On 25.06.19 14:31, Dan Carpenter wrote:

Hi Xen devs,

I get the following static checker warning:

drivers/pci/xen-pcifront.c:107 schedule_pcifront_aer_op()
warn: passing casted pointer '>sh_info->flags' to 'test_bit()' 32 
vs 64.

drivers/pci/xen-pcifront.c
105  static inline void schedule_pcifront_aer_op(struct pcifront_device 
*pdev)
106  {
107  if (test_bit(_XEN_PCIB_active, (unsigned long 
*)>sh_info->flags)

->flags is a u32 so this cast only works on little endian systems.  I
don't know if that matters at all.  This driver has a bunch of similar
issues.  Is Xen x86 only?  It's pretty normal for Intel code to rely on
little endianness...


Xen is running on ARM, too. AFAIK it only supports little endian mode
for guests, though.



108  && !test_and_set_bit(_PDEVB_op_active, >flags)) {
109  dev_dbg(>xdev->dev, "schedule aer frontend 
job\n");
110  schedule_work(>op_work);
111  }
112  }

drivers/pci/xen-pcifront.c:107 schedule_pcifront_aer_op() warn: passing casted pointer 
'>sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/pci/xen-pcifront.c:129 do_pci_op() warn: passing casted pointer 
'>sh_info->flags' to 'set_bit()' 32 vs 64.
drivers/pci/xen-pcifront.c:142 do_pci_op() warn: passing casted pointer 
'>sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/pci/xen-pcifront.c:150 do_pci_op() warn: passing casted pointer 
'>sh_info->flags' to 'clear_bit()' 32 vs 64.
drivers/pci/xen-pcifront.c:162 do_pci_op() warn: passing casted pointer 
'>sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/pci/xen-pcifront.c:670 pcifront_do_aer() warn: passing casted pointer 
'>sh_info->flags' to 'clear_bit()' 32 vs 64.
drivers/xen/mcelog.c:209 xen_mce_log() warn: passing casted pointer 
'_mcelog.flags' to 'set_bit()' 32 vs 64.
drivers/xen/privcmd.c:350 mmap_batch_fn() warn: passing casted pointer 'gfnp' 
to 'xen_remap_domain_gfn_array()' 64 vs 32.
drivers/xen/privcmd.c:827 privcmd_ioctl_mmap_resource() warn: passing casted 
pointer 'pfns' to 'xen_remap_domain_mfn_array()' 64 vs 32.
drivers/xen/xen-pciback/conf_space.c:172 xen_pcibk_config_read() warn: passing 
casted pointer '' to 'pci_read_config_word()' 32 vs 16.
drivers/xen/xen-pciback/conf_space.c:57 conf_space_read() warn: passing casted 
pointer 'value' to 'field->u.w.read()' 32 vs 16.
drivers/xen/xen-pciback/pciback_ops.c:310 xen_pcibk_test_and_schedule_op() warn: passing 
casted pointer '>sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pciback_ops.c:316 xen_pcibk_test_and_schedule_op() warn: passing 
casted pointer '>sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pciback_ops.c:396 xen_pcibk_do_op() warn: passing casted pointer 
'>sh_info->flags' to 'clear_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:731 common_process() warn: passing casted pointer 
'_info->flags' to 'set_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:736 common_process() warn: passing casted pointer 
'_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:741 common_process() warn: passing casted pointer 
'_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:745 common_process() warn: passing casted pointer 
'_info->flags' to 'clear_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:753 common_process() warn: passing casted pointer 
'_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:799 xen_pcibk_slot_reset() warn: passing casted pointer 
'>pdev->sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:857 xen_pcibk_mmio_enabled() warn: passing casted pointer 
'>pdev->sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:916 xen_pcibk_error_detected() warn: passing casted 
pointer '>pdev->sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:969 xen_pcibk_error_resume() warn: passing casted pointer 
'>pdev->sh_info->flags' to 'test_bit()' 32 vs 64.


The sh_info->flags accesses would need to be modified in order to fix
the warnings. Either by adding *_bit32() variants to the kernel or by
using atomic() accesses instead.

Patches welcome. :-)


Juergen

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

Re: [Xen-devel] [PATCH 3/4] x86/linker: add a reloc section to ELF binary

On Tue, Jun 25, 2019 at 01:08:49PM +0200, Roger Pau Monné wrote:
> On Tue, Jun 25, 2019 at 03:18:14AM -0600, Jan Beulich wrote:
> > >>> On 25.06.19 at 10:10,  wrote:
> > > On Mon, Jun 24, 2019 at 01:24:02PM +0200, Daniel Kiper wrote:
> > >> On Fri, Jun 21, 2019 at 12:34:13AM -0600, Jan Beulich wrote:
> > >> > >>> On 19.06.19 at 17:06,  wrote:
> > >> > > On Wed, Jun 19, 2019 at 06:57:05AM -0600, Jan Beulich wrote:
> > >> > >> >>> On 19.06.19 at 13:02,  wrote:
> > >> > >> > If the hypervisor has been built with EFI support (ie: 
> > >> > >> > multiboot2).
> > >> > >> > This allows to position the .reloc section correctly in the output
> > >> > >> > binary, or else the linker might place .reloc before the .text
> > >> > >> > section.
> > >> > >> >
> > >> > >> > Note that the .reloc section is moved before .bss for two 
> > >> > >> > reasons: in
> > >> > >> > order for the resulting binary to not contain any section with 
> > >> > >> > data
> > >> > >> > after .bss, so that the file size can be smaller than the loaded
> > >> > >> > memory size, and because the data it contains is read-only, so it
> > >> > >> > belongs with the other sections containing read-only data.
> > >> > >>
> > >> > >> While this may be fine for ELF, I'm afraid it would be calling for
> > >> > >> subtle issues with xen.efi (i.e. the PE binary): There a .reloc
> > >> > >> section is generally expected to come after "normal" data
> > >> > >> sections.
> > >> > >
> > >> > > OK, would you like me to leave the .reloc section at the previous
> > >> > > position for EFI builds then?
> > >> >
> > >> > Well, this part is a requirement, not a question of me liking you
> > >> > to do so.
> > >> >
> > >> > > Or do we prefer to leave .reloc orphaned in the ELF build?
> > >> >
> > >> > Daniel might have an opinion here with his plans to actually
> > >> > add relocations there in the non-linker-generated-PE build. I
> > >> > don't have a strong opinion either way, as long as the
> > >> > current method of building gets left as is (or even simplified).
> > >> 
> > >> I would not drop .reloc section from xen-syms because it can be useful
> > >> for "manual" EFI image relocs generation. However, I am not strongly
> > >> tied to it. If you wish to drop it go ahead. I can readd it latter if
> > >> I get back to my new PE build work.
> > > 
> > > Do you mean that the dummy .reloc section added to non-PE builds can
> > > be dropped? (ie: remove xen/arch/x86/efi/relocs-dummy.S from the build)
> > 
> > Given my earlier reply it's not clear to me what you mean by "remove"
> > here. As a result ...
> > 
> > > I'm slightly lost, .reloc begin a section that's explicitly added to
> > > non-PE builds by relocs-dummy.S I assumed it was needed for some
> > > reason.
> > 
> > ... it's also not clear what exactly you mean here, and hence whether
> > there's any reason needed beyond the reference to the two bounding
> > symbols by efi_arch_relocate_image().
> 
> Sorry for not being clear. By remove I mean `git rm
> xen/arch/x86/efi/relocs-dummy.S` and fix the build, like the diff
> appended below.

The chunk below will not work because relocs-dummy is also needed
by the EFI build. I'm however lost at why this is required, and the
commit message that introduced the file (bf6501a62e) doesn't add any
reasoning.

Is maybe .reloc mandatory for PE format?

Thanks, Roger.

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

[Xen-devel] [bug report] xen-pcifront: Xen PCI frontend driver.

2019-06-25 Thread Dan Carpenter

Hi Xen devs,

I get the following static checker warning:

drivers/pci/xen-pcifront.c:107 schedule_pcifront_aer_op()
warn: passing casted pointer '>sh_info->flags' to 'test_bit()' 32 
vs 64.

drivers/pci/xen-pcifront.c
   105  static inline void schedule_pcifront_aer_op(struct pcifront_device 
*pdev)
   106  {
   107  if (test_bit(_XEN_PCIB_active, (unsigned long 
*)>sh_info->flags)

->flags is a u32 so this cast only works on little endian systems.  I
don't know if that matters at all.  This driver has a bunch of similar
issues.  Is Xen x86 only?  It's pretty normal for Intel code to rely on
little endianness...

   108  && !test_and_set_bit(_PDEVB_op_active, >flags)) {
   109  dev_dbg(>xdev->dev, "schedule aer frontend 
job\n");
   110  schedule_work(>op_work);
   111  }
   112  }

drivers/pci/xen-pcifront.c:107 schedule_pcifront_aer_op() warn: passing casted 
pointer '>sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/pci/xen-pcifront.c:129 do_pci_op() warn: passing casted pointer 
'>sh_info->flags' to 'set_bit()' 32 vs 64.
drivers/pci/xen-pcifront.c:142 do_pci_op() warn: passing casted pointer 
'>sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/pci/xen-pcifront.c:150 do_pci_op() warn: passing casted pointer 
'>sh_info->flags' to 'clear_bit()' 32 vs 64.
drivers/pci/xen-pcifront.c:162 do_pci_op() warn: passing casted pointer 
'>sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/pci/xen-pcifront.c:670 pcifront_do_aer() warn: passing casted pointer 
'>sh_info->flags' to 'clear_bit()' 32 vs 64.
drivers/xen/mcelog.c:209 xen_mce_log() warn: passing casted pointer 
'_mcelog.flags' to 'set_bit()' 32 vs 64.
drivers/xen/privcmd.c:350 mmap_batch_fn() warn: passing casted pointer 'gfnp' 
to 'xen_remap_domain_gfn_array()' 64 vs 32.
drivers/xen/privcmd.c:827 privcmd_ioctl_mmap_resource() warn: passing casted 
pointer 'pfns' to 'xen_remap_domain_mfn_array()' 64 vs 32.
drivers/xen/xen-pciback/conf_space.c:172 xen_pcibk_config_read() warn: passing 
casted pointer '' to 'pci_read_config_word()' 32 vs 16.
drivers/xen/xen-pciback/conf_space.c:57 conf_space_read() warn: passing casted 
pointer 'value' to 'field->u.w.read()' 32 vs 16.
drivers/xen/xen-pciback/pciback_ops.c:310 xen_pcibk_test_and_schedule_op() 
warn: passing casted pointer '>sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pciback_ops.c:316 xen_pcibk_test_and_schedule_op() 
warn: passing casted pointer '>sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pciback_ops.c:396 xen_pcibk_do_op() warn: passing 
casted pointer '>sh_info->flags' to 'clear_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:731 common_process() warn: passing casted 
pointer '_info->flags' to 'set_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:736 common_process() warn: passing casted 
pointer '_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:741 common_process() warn: passing casted 
pointer '_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:745 common_process() warn: passing casted 
pointer '_info->flags' to 'clear_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:753 common_process() warn: passing casted 
pointer '_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:799 xen_pcibk_slot_reset() warn: passing 
casted pointer '>pdev->sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:857 xen_pcibk_mmio_enabled() warn: passing 
casted pointer '>pdev->sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:916 xen_pcibk_error_detected() warn: passing 
casted pointer '>pdev->sh_info->flags' to 'test_bit()' 32 vs 64.
drivers/xen/xen-pciback/pci_stub.c:969 xen_pcibk_error_resume() warn: passing 
casted pointer '>pdev->sh_info->flags' to 'test_bit()' 32 vs 64.

regards,
dan carpenter

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

Re: [Xen-devel] [PATCH v2 5/7] x86/xen: nopv parameter support for HVM guest


On 24.06.19 14:02, Zhenzhong Duan wrote:

PVH guest needs PV extentions to work, so nopv parameter is ignored
for PVH but not for HVM guest.

In order for nopv parameter to take effect for HVM guest, we need to
distinguish between PVH and HVM guest early in hypervisor detection
code. By moving the detection of PVH in xen_platform_hvm(),
xen_pvh_domain() could be used for that purpose.

Signed-off-by: Zhenzhong Duan 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: xen-devel@lists.xenproject.org
---
  arch/x86/xen/enlighten_hvm.c | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 7fcb4ea..26939e7 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -25,6 +25,7 @@
  #include "mmu.h"
  #include "smp.h"
  
+extern bool nopv;

  static unsigned long shared_info_pfn;
  
  void xen_hvm_init_shared_info(void)

@@ -226,20 +227,24 @@ static uint32_t __init xen_platform_hvm(void)
if (xen_pv_domain())
return 0;
  
+#ifdef CONFIG_XEN_PVH

+   /* Test for PVH domain (PVH boot path taken overrides ACPI flags). */
+   if (!x86_platform.legacy.rtc && x86_platform.legacy.no_vga)
+   xen_pvh = true;


Sorry, this won't work, as ACPI tables are scanned only some time later.

You can test for xen_pvh being true here (for the case where the guest
has been booted via the Xen-PVH boot entry) and handle that case, but
the case of a PVH guest started via the normal boot entry (like via
grub2) and nopv specified is difficult. The only idea I have right now
would be to use another struct hypervisor_x86 for that case which will
only be used for Xen HVM/PVH _and_ nopv specified. It should be a copy
of the bare metal variant, but a special guest_late_init member issuing
a big fat warning in case PVH is being detected.


Juergen

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

Re: [Xen-devel] Migrating key developer docs to xen.git sphinx docs and refreshing them in the process

2019-06-25 Thread Lars Kurth

On 25/06/2019, 10:03, "Julien Grall"  wrote:

>>> The point here is that we can be flexible and creative about the way to
>>> maintain the docs on xen.git. But as a technology is certainly better
>>> than the wiki: we don't have to keep them all up-to-date with the code,
>>> but at least this way we have a chance (if we want to). If we leave them
>>> on the wiki, there is no chance.
>>
>> I can't see how xen.git is going to be better if "we don't have to keep 
them
>> all up-to-date".
> 
> That's because a contributor could add a patch at the end of a series to
> update one of the docs, even if the doc in question comes with no
> promises of being up-to-date.

I think this is going the wrong direction. The goal of using xen.git is to 
try 
to keep the documentation up-to-date.

I agree with Julien and this was also not my intention. The reason why I 
brought this up now is that the in-tree docs are pretty much a mess today and 
are stale in many ways. And they look TERRIBLE and are not easily searchable. 
However, Andy's latest set of patches provide an opportunity to consolidate 
some of the in-tree docs in a nicely rendered and searchable format.

I have been focussing on process related and key developer related docs, 
because who maintains them is not actually an issue in theory. Everyone really 
ought to care, because everyone is impacted by these. 

What happens today for many of these type of docs and/or processes is that:
a) We have discussion about a process / working practice on the list until we 
come to a conclusion
b) Then we take it and copy it to the wiki
Why not merge this into one activity

Both of you are interested in Arm docs, but this is something I will let you 
fight out. 
Maybe you want to chat about this some more at the summit

>> But my point here is most of the board should be trivial. The most of the
>> non-trivial setup require non-upstream patch. While I am happy to see 
that on
>> the wiki, I think xen.git should not promote such configuration at all. 
We are
>> working upstream, not with unknown/untrusted stack.
>>
>> For some working fully upstream, I don't think xen.git should promote any
>> distros/versions of the kernel. However, this is ok on the wiki.
> 
> I would like to see the wiki disappear completely in the long term. As
> we are moving more content to xen.git, it is not a good idea to have two
> places where we keep information, for similar reasons why you suggested
> to use in-code comments instead of docs to document interfaces. It
> just takes more efforts to maintain information in two places and they
> tend to get out of sync with each others.
> 
> If we make the wiki go away (I hope so), we'll need a place to store the
> Arm board-specific documents, and other tutorials.

Removing the wiki is an honorable goal, however I don't think all the wiki 
is 
suitable for xen.git. The Arm board-specific documents is an example.

Removing the wiki was not my aim. The wiki is useful in some cases, but not in 
others.

Lars

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

[Xen-devel] [xen-4.10-testing test] 138376: tolerable FAIL - PUSHED

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  29fd403ef5c02e2cbd0769e64ec0b61e0658d358
baseline version:
 xen  adf037bba1e6af47fef8584c1ad41f424ebda01e

Last test of basis   137381  2019-06-06 10:03:08 Z   19 days
Failing since137727  2019-06-14 14:05:32 Z   10 days4 attempts
Testing same since   138226  2019-06-21 19:05:55 Z3 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Jan Beulich 
  Julien Grall 
  Stefano Stabellini 
  Stefano

[Xen-devel] [PATCH v2 5/7] x86/xen: nopv parameter support for HVM guest

2019-06-25 Thread Zhenzhong Duan

PVH guest needs PV extentions to work, so nopv parameter is ignored
for PVH but not for HVM guest.

In order for nopv parameter to take effect for HVM guest, we need to
distinguish between PVH and HVM guest early in hypervisor detection
code. By moving the detection of PVH in xen_platform_hvm(),
xen_pvh_domain() could be used for that purpose.

Signed-off-by: Zhenzhong Duan 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/xen/enlighten_hvm.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 7fcb4ea..26939e7 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -25,6 +25,7 @@
 #include "mmu.h"
 #include "smp.h"
 
+extern bool nopv;
 static unsigned long shared_info_pfn;
 
 void xen_hvm_init_shared_info(void)
@@ -226,20 +227,24 @@ static uint32_t __init xen_platform_hvm(void)
if (xen_pv_domain())
return 0;
 
+#ifdef CONFIG_XEN_PVH
+   /* Test for PVH domain (PVH boot path taken overrides ACPI flags). */
+   if (!x86_platform.legacy.rtc && x86_platform.legacy.no_vga)
+   xen_pvh = true;
+#endif
+
+   if (!xen_pvh_domain() && nopv)
+   return 0;
+
return xen_cpuid_base();
 }
 
 static __init void xen_hvm_guest_late_init(void)
 {
 #ifdef CONFIG_XEN_PVH
-   /* Test for PVH domain (PVH boot path taken overrides ACPI flags). */
-   if (!xen_pvh &&
-   (x86_platform.legacy.rtc || !x86_platform.legacy.no_vga))
+   if (!xen_pvh)
return;
 
-   /* PVH detected. */
-   xen_pvh = true;
-
/* Make sure we don't fall back to (default) ACPI_IRQ_MODEL_PIC. */
if (!nr_ioapics && acpi_irq_model == ACPI_IRQ_MODEL_PIC)
acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
@@ -258,4 +263,5 @@ static __init void xen_hvm_guest_late_init(void)
.init.init_mem_mapping  = xen_hvm_init_mem_mapping,
.init.guest_late_init   = xen_hvm_guest_late_init,
.runtime.pin_vcpu   = xen_pin_vcpu,
+   .ignore_nopv= true,
 };
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 3/7] x86: Add nopv parameter to disable PV extensions

2019-06-25 Thread Zhenzhong Duan

In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.

However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. As such introduce the
'nopv' parameter that will do it.

There are guest types which just won't work without PV extensions,
like Xen PV, Xen PVH and jailhouse. add a "ignore_nopv" member to
struct hypervisor_x86 set to true for those guest types and call
the detect functions only if nopv is false or ignore_nopv is true.

There is already 'xen_nopv' parameter for XEN platform but not for
others. 'xen_nopv' can then be removed with this change.

Suggested-by: Juergen Gross 
Signed-off-by: Zhenzhong Duan 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Jan Kiszka 
Cc: Boris Ostrovsky 
Cc: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org
---
 Documentation/admin-guide/kernel-parameters.txt |  5 +
 arch/x86/include/asm/hypervisor.h   |  3 +++
 arch/x86/kernel/cpu/hypervisor.c| 11 +++
 arch/x86/kernel/jailhouse.c |  1 +
 arch/x86/xen/enlighten_pv.c |  1 +
 5 files changed, 21 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 138f666..21e08af 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5268,6 +5268,11 @@
improve timer resolution at the expense of processing
more timer interrupts.
 
+   nopv=   [X86,XEN,KVM,HYPER_V,VMWARE]
+   Disables the PV optimizations forcing the guest to run
+   as generic guest with no PV drivers. Currently support
+   XEN HVM, KVM, HYPER_V and VMWARE guest.
+
xirc2ps_cs= [NET,PCMCIA]
Format:

,[,[,[,]]]
diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h
index 8c5aaba..d75d2ea 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -52,6 +52,9 @@ struct hypervisor_x86 {
 
/* runtime callbacks */
struct x86_hyper_runtime runtime;
+
+   /* ignore nopv parameter */
+   bool ignore_nopv;
 };
 
 extern enum x86_hypervisor_type x86_hyper_type;
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 479ca47..337ff07 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -54,6 +54,14 @@
 enum x86_hypervisor_type x86_hyper_type;
 EXPORT_SYMBOL(x86_hyper_type);
 
+bool __initdata nopv;
+static __init int parse_nopv(char *arg)
+{
+   nopv = true;
+   return 0;
+}
+early_param("nopv", parse_nopv);
+
 static inline const struct hypervisor_x86 * __init
 detect_hypervisor_vendor(void)
 {
@@ -61,6 +69,9 @@
uint32_t pri, max_pri = 0;
 
for (p = hypervisors; p < hypervisors + ARRAY_SIZE(hypervisors); p++) {
+   if (unlikely(nopv) && !(*p)->ignore_nopv)
+   continue;
+
pri = (*p)->detect();
if (pri > max_pri) {
max_pri = pri;
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index d96d563..880329f 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -217,4 +217,5 @@ static bool __init jailhouse_x2apic_available(void)
.detect = jailhouse_detect,
.init.init_platform = jailhouse_init_platform,
.init.x2apic_available  = jailhouse_x2apic_available,
+   .ignore_nopv= true,
 };
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4722ba2..5d16824 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1463,4 +1463,5 @@ static uint32_t __init xen_platform_pv(void)
.detect = xen_platform_pv,
.type   = X86_HYPER_XEN_PV,
.runtime.pin_vcpu   = xen_pin_vcpu,
+   .ignore_nopv= true,
 };
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 4/7] Revert "xen: Introduce 'xen_nopv' to disable PV extensions for HVM guests."

2019-06-25 Thread Zhenzhong Duan

This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.

Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.

Signed-off-by: Zhenzhong Duan 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: xen-devel@lists.xenproject.org
---
 Documentation/admin-guide/kernel-parameters.txt |  4 
 arch/x86/xen/enlighten_hvm.c| 12 +---
 2 files changed, 1 insertion(+), 15 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 21e08af..d5c3dcc 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5251,10 +5251,6 @@
Disables the ticketlock slowpath using Xen PV
optimizations.
 
-   xen_nopv[X86]
-   Disables the PV optimizations forcing the HVM guest to
-   run as generic HVM guest with no PV drivers.
-
xen_scrub_pages=[XEN]
Boolean option to control scrubbing pages before giving 
them back
to Xen, for use by other domains. Can be also changed 
at runtime
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index ac4943c..7fcb4ea 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -210,18 +210,8 @@ static void __init xen_hvm_guest_init(void)
 #endif
 }
 
-static bool xen_nopv;
-static __init int xen_parse_nopv(char *arg)
-{
-   xen_nopv = true;
-   return 0;
-}
-early_param("xen_nopv", xen_parse_nopv);
-
 bool __init xen_hvm_need_lapic(void)
 {
-   if (xen_nopv)
-   return false;
if (xen_pv_domain())
return false;
if (!xen_hvm_domain())
@@ -233,7 +223,7 @@ bool __init xen_hvm_need_lapic(void)
 
 static uint32_t __init xen_platform_hvm(void)
 {
-   if (xen_pv_domain() || xen_nopv)
+   if (xen_pv_domain())
return 0;
 
return xen_cpuid_base();
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH 3/4] x86/linker: add a reloc section to ELF binary

On Tue, Jun 25, 2019 at 03:18:14AM -0600, Jan Beulich wrote:
> >>> On 25.06.19 at 10:10,  wrote:
> > On Mon, Jun 24, 2019 at 01:24:02PM +0200, Daniel Kiper wrote:
> >> On Fri, Jun 21, 2019 at 12:34:13AM -0600, Jan Beulich wrote:
> >> > >>> On 19.06.19 at 17:06,  wrote:
> >> > > On Wed, Jun 19, 2019 at 06:57:05AM -0600, Jan Beulich wrote:
> >> > >> >>> On 19.06.19 at 13:02,  wrote:
> >> > >> > If the hypervisor has been built with EFI support (ie: multiboot2).
> >> > >> > This allows to position the .reloc section correctly in the output
> >> > >> > binary, or else the linker might place .reloc before the .text
> >> > >> > section.
> >> > >> >
> >> > >> > Note that the .reloc section is moved before .bss for two reasons: 
> >> > >> > in
> >> > >> > order for the resulting binary to not contain any section with data
> >> > >> > after .bss, so that the file size can be smaller than the loaded
> >> > >> > memory size, and because the data it contains is read-only, so it
> >> > >> > belongs with the other sections containing read-only data.
> >> > >>
> >> > >> While this may be fine for ELF, I'm afraid it would be calling for
> >> > >> subtle issues with xen.efi (i.e. the PE binary): There a .reloc
> >> > >> section is generally expected to come after "normal" data
> >> > >> sections.
> >> > >
> >> > > OK, would you like me to leave the .reloc section at the previous
> >> > > position for EFI builds then?
> >> >
> >> > Well, this part is a requirement, not a question of me liking you
> >> > to do so.
> >> >
> >> > > Or do we prefer to leave .reloc orphaned in the ELF build?
> >> >
> >> > Daniel might have an opinion here with his plans to actually
> >> > add relocations there in the non-linker-generated-PE build. I
> >> > don't have a strong opinion either way, as long as the
> >> > current method of building gets left as is (or even simplified).
> >> 
> >> I would not drop .reloc section from xen-syms because it can be useful
> >> for "manual" EFI image relocs generation. However, I am not strongly
> >> tied to it. If you wish to drop it go ahead. I can readd it latter if
> >> I get back to my new PE build work.
> > 
> > Do you mean that the dummy .reloc section added to non-PE builds can
> > be dropped? (ie: remove xen/arch/x86/efi/relocs-dummy.S from the build)
> 
> Given my earlier reply it's not clear to me what you mean by "remove"
> here. As a result ...
> 
> > I'm slightly lost, .reloc begin a section that's explicitly added to
> > non-PE builds by relocs-dummy.S I assumed it was needed for some
> > reason.
> 
> ... it's also not clear what exactly you mean here, and hence whether
> there's any reason needed beyond the reference to the two bounding
> symbols by efi_arch_relocate_image().

Sorry for not being clear. By remove I mean `git rm
xen/arch/x86/efi/relocs-dummy.S` and fix the build, like the diff
appended below.

Is there any reason we should keep the dummy .reloc in the ELF
output?

Thanks, Roger.
---8<---
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 4bc0a196e9..5849604766 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -11,6 +11,6 @@ $(call 
cc-option-add,cflags-stack-boundary,CC,-mpreferred-stack-boundary=4)
 $(EFIOBJ): CFLAGS-stack-boundary := $(cflags-stack-boundary)
 
 obj-y := stub.o
-obj-$(XEN_BUILD_EFI) := $(EFIOBJ) relocs-dummy.o
+obj-$(XEN_BUILD_EFI) := $(EFIOBJ)
 extra-$(XEN_BUILD_EFI) += buildid.o
 nocov-$(XEN_BUILD_EFI) += stub.o
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 7a13a30bc0..2cf440e2ae 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -39,6 +39,7 @@ extern const intpte_t __page_tables_start[], 
__page_tables_end[];
 #define PE_BASE_RELOC_HIGHLOW  3
 #define PE_BASE_RELOC_DIR64   10
 
+#ifdef XEN_BUILD_PE
 extern const struct pe_base_relocs {
 u32 rva;
 u32 size;
@@ -97,6 +98,12 @@ static void __init efi_arch_relocate_image(unsigned long 
delta)
 base_relocs = (const void *)(base_relocs->entries + i + (i & 1));
 }
 }
+#else /* !XEN_BUILD_PE */
+static void __init efi_arch_relocate_image(unsigned long delta)
+{
+ASSERT_UNREACHABLE();
+}
+#endif /* XEN_BUILD_PE */
 
 extern const s32 __trampoline_rel_start[], __trampoline_rel_stop[];
 extern const s32 __trampoline_seg_start[], __trampoline_seg_stop[];
diff --git a/xen/arch/x86/efi/relocs-dummy.S b/xen/arch/x86/efi/relocs-dummy.S
deleted file mode 100644
index d928a82d53..00
--- a/xen/arch/x86/efi/relocs-dummy.S
+++ /dev/null
@@ -1,11 +0,0 @@
-
-   .section .reloc, "a", @progbits
-   .balign 4
-GLOBAL(__base_relocs_start)
-   .long 0
-   .long 8
-GLOBAL(__base_relocs_end)
-
-   .globl VIRT_START, ALT_START
-   .equ VIRT_START, XEN_VIRT_START
-   .equ ALT_START, XEN_VIRT_END


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

Re: [Xen-devel] [xen-4.6-testing test] 138333: regressions - FAIL

Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> > Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - 
> > FAIL"):
> > > These all have `qemut' in common.
...
> I'm trying a test with 4.7's version of qemu trad.

This does not work.  4.7's qemu trad doesn't build because of tools
library reorganisation.  Reverting those changes to 4.7 produces a
qemu trad that is identical to 4.6's.  So the regression is not in
qemu.

I suspect a firmware or hvmloader problem.

This is blocking us getting a push for the Xen 4.8 stable branches:

We want to test 4.7->4.8 migration, so we must build 4.7 to test 4.8.
But 4.7 stable does not build (on stretch) and a push of 4.7 is
blocked because:

We want to test 4.6->4.7 migration, so we must build 4.6 to test 4.7.
But 4.6 stable does not build (on stretch) and a push of 4.6 is
blocked because:

4.6 staging does not boot hvm guests with qemu trad.

(There may be other problems too.)

If we were to force push 4.6 then those migration tests of 4.6->4.7
that use qemu-trad would fail because of the same bug.

We could choose to force push 4.7 despite not knowing whether 4.6->4.7
migration still works.

Ian.

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

Re: [Xen-devel] UBSAN report in find_next_bit()


Hi Jan,

On 25/06/2019 10:38, Jan Beulich wrote:

On 24.06.19 at 18:24,  wrote:

ARM64's find_next_bit() explicitly copes with offset >= size, and while
I don't speak ARM asm well enough to work out whether
_find_first_bit_le() copes with offset == size, the vgic.c code
definitely expects it to function in this way.


... Arm32's _find_next{,_zero}_bit_le. You've named the issue the x86
logic has. Arm32's, afaict, will read one byte past the array when offset
and size match and are a multiple of 8.


It took me a bit to get my head around as the code is quite convoluted. But I 
agree with you here, arm32 find_* does not cope with offset == size.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] UBSAN report in find_next_bit()


Hi Andrew,

On 24/06/2019 17:24, Andrew Cooper wrote:

ARM64's find_next_bit() explicitly copes with offset >= size, and while
I don't speak ARM asm well enough to work out whether
_find_first_bit_le() copes with offset == size, the vgic.c code
definitely expects it to function in this way.


I looked at the instance of find_* in arch/arm/vgic.c. AFAICT, all of them will 
always be called with offset < size. Could you point which one you think will 
relies on offset == size?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: Switch OMAP5 secondary cores into hyp mode


Hi Andrew,

On 24/06/2019 13:03, Andrew Cooper wrote:

On 24/06/2019 12:09, Julien Grall wrote:

(+ GSOC mentors and Andre)

Hi Denis,

Thank you for the patch.

First of all, may I ask to CC the other mentors?

On 6/21/19 9:02 PM, Denis Obrezkov wrote:

This function allows xen to bring secondary CPU cores into non-secure
HYP mode. This is done by using a Secure Monitor call.

Signed-off-by: Denis Obrezkov 
---
  xen/arch/arm/arm32/head.S | 11 ++-
  xen/arch/arm/platforms/omap5.c    |  5 +++--
  xen/include/asm-arm/platforms/omap5.h |  3 +++
  3 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 5f817d473e..120e034934 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -36,6 +36,10 @@
  #include EARLY_PRINTK_INC
  #endif
  +
+#define API_HYP_ENTRY 0x102
+#define AUX_CORE_BOOT0_PA   0x48281800
+


I have thought a bit more about the placement of the code. I think it would be 
best if it lives in a separate file (maybe platforms/omap5-head.S).


For something this trivial, it is easy to put straight into omap5.c

Completely untested, but this ought to work:

diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
index 6b5cc15af3..1dcc92d3a4 100644
--- a/xen/arch/arm/platforms/omap5.c
+++ b/xen/arch/arm/platforms/omap5.c
@@ -23,6 +23,16 @@
  #include 
  #include 
  
+void omap5_init_secondary(void);

+asm (
+".text\n\t"
+"omap5_init_secondary:\n\t"
+"ldr   r12, =0x102\n\t" /* API_HYP_ENTRY */
+"adr   r0, init_secondary \n\t"


You cannot use adr on external address for Arm32. This is because the immediate 
constant needs to have a specific format (see "Modified immediate constants in 
ARM instructions" A5.2.4 in ARM DDI 406C.c).


Instead we would need something like:

omap5_init_secondary:
 ldr r12, =0x102
 adr r0, omap5_hyp
 smc #0
omap5_hyp:
 b   init_secondary

Note similar code would be needed for the stub file.


+"smc   #0 \n\t"
+"b init_secondary \n\t"
+);
+
  static uint16_t num_den[8][2] = {
  { 0,  0 },  /* not used */
  {  26 *  64,  26 *  125 },  /* 12.0 Mhz */


I personally find this favourable to introducing new stub files.

Ultimately it is Julien/Stefano's decision, but I'd like to point it out as an 
option for anyone who is unaware.


Thank you for the suggestion :). This was suggested last week, but no-one came 
back explaining how it could be implemented.


The two are fine with me.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/2] xen/ubsan: Support for -fsanitise=builtin

>>> On 24.06.19 at 12:17,  wrote:
> This fixes the UBSAN build for GCC 8 and later.  The sanitiser checks for
> passing 0 to the ctz()/clz() builtins.
> 
> Signed-off-by: Andrew Cooper 

Fundamentally
Acked-by: Jan Beulich 

However,

> --- a/xen/common/ubsan/ubsan.c
> +++ b/xen/common/ubsan/ubsan.c
> @@ -518,3 +518,24 @@ void __ubsan_handle_pointer_overflow(struct 
> pointer_overflow_data *data,
>  
>   ubsan_epilogue();
>  }
> +
> +void __ubsan_handle_invalid_builtin(struct invalid_builtin_data *data)
> +{
> + unsigned long flags;
> + const char *fn;
> +
> + if (suppress_report(>location))
> + return;
> +
> + ubsan_prologue(>location, );
> +
> + switch (data->kind) {
> + case kind_ctz: fn = "ctz"; break;
> + case kind_clz: fn = "clz"; break;
> + default: fn = ""; break;
> + }
> +
> + pr_err("passing zero to %s(), which is not a valid argument\n", fn);

... logging the unknown enumerator value might turn out helpful
down the road.

Jan



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

Re: [Xen-devel] [PATCH v2 1/2] x86/ubsan: Don't perform alignment checking on supporting compilers

>>> On 24.06.19 at 20:25,  wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -138,7 +138,10 @@ $(filter-out %.init.o $(nocov-y),$(obj-y) $(obj-bin-y) 
> $(extra-y)): CFLAGS += $(
>  endif
>  
>  ifeq ($(CONFIG_UBSAN),y)
> -$(filter-out %.init.o $(noubsan-y),$(obj-y) $(obj-bin-y) $(extra-y)): 
> CFLAGS += -fsanitize=undefined
> +UBSAN_FLAGS += -fsanitize=undefined

Here and in the x86 change below to append to UBSAN_FLAGS. I think we
have more such cases, but I also think we shouldn't extend the badness:
We should start with an empty variable, rather than whatever may have
been inherited from the environment.

Also could this become UBSAN_CFLAGS or CFLAGS_UBSAN? Or perhaps
UBSAN_CFLAGS-y / CFLAGS_UBSAN-y, making adding to it easier?

> +# Any -fno-sanitise= options need to come after any -fsanitise= options
> +$(filter-out %.init.o $(noubsan-y),$(obj-y) $(obj-bin-y) $(extra-y)):\

Could you add a blank before the backslash, for readability?

> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -57,6 +57,10 @@ endif
>  $(call cc-option-add,CFLAGS-stack-boundary,CC,-mpreferred-stack-boundary=3)
>  CFLAGS += $(CFLAGS-stack-boundary)
>  
> +ifeq ($(CONFIG_UBSAN),y)
> +$(call cc-option-add,UBSAN_FLAGS,CC,-fno-sanitize=alignment)
> +endif

Perhaps worth adding a short comment as to the "why"? And perhaps
no need for the ifeq()?

Jan

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

Re: [Xen-devel] [PATCH] page-alloc: Clamp get_free_buddy() to online nodes

>>> On 24.06.19 at 20:01,  wrote:
> This patch hides the issue identified in the "UBSAN report in find_next_bit()"
> so probably doesn't want applying until that is resolved.

It does so on systems with less than 64 nodes, afaict.

> A lower overhead option would be to do:
> 
> nodes_and(nodemask, node_online_map, d ? d->node_affinity : node_online_map);
> 
> however this doesn't work because the nodeset_t API has a hidden &(param)
> throughout the API.  I've got half a mind to undo this nonsense and have
> nodemask_t work in exactly the same way as cpumask_t.

Right, we should do such a transformation eventually.

> --- a/xen/include/xen/nodemask.h
> +++ b/xen/include/xen/nodemask.h
> @@ -189,6 +189,12 @@ static inline int __nodes_weight(const nodemask_t *srcp, 
> int nbits)
>   return bitmap_weight(srcp->bits, nbits);
>  }
>  
> +#define nodes_copy(dst, src) __nodes_copy(&(dst), &(src))
> +static inline void __nodes_copy(nodemask_t *dst, nodemask_t *src)
> +{
> + return bitmap_copy(dst->bits, src->bits, MAX_NUMNODES);
> +}

Rather than introducing this, I think structure assignment is meant
to be used (as was the case prior to your change). But if you really
feel like introducing this, then please constify "src". With either
adjustment made,
Reviewed-by: Jan Beulich 

Jan



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

Re: [Xen-devel] UBSAN report in find_next_bit()

>>> On 24.06.19 at 18:24,  wrote:
>> else if ( (node = next_node(node, nodemask)) >= MAX_NUMNODES )
>> node = first_node(nodemask);
> 
> On x86, MAX_NUMNODES is 64, and this part of get_free_buddy() loops over
> nodes {0..63}.  next_node() expands to find_next_bit(..., node+1) which
> passes offset == size on the final iteration.
> 
> find_next_bit() has an optimisation for bitmaps of 64 or fewer bits
> which does:
> 
>> else if ( __builtin_constant_p(size) && s__ <= BITS_PER_LONG )
>> r__ = o__ + __scanbit(*(const unsigned long *)(a__) >> o__, s__);
> 
> UBSAN takes objection to the shift, which in this case is a shift by 64.
> 
> The code in __find_next_bit() makes it clear that offset == size is a
> valid condition, which would suggest that the bug is with the optimisation.

Oh, in particular the ASSERT() there is indeed very clear.

> However, this conclusion contradicts the views of c/s b20079da9 which
> decided that offset == size is not a valid condition.

And that was based on how x86'es find_next{,_zero}_bit() as well
as ...

> ARM64's find_next_bit() explicitly copes with offset >= size, and while
> I don't speak ARM asm well enough to work out whether
> _find_first_bit_le() copes with offset == size, the vgic.c code
> definitely expects it to function in this way.

... Arm32's _find_next{,_zero}_bit_le. You've named the issue the x86
logic has. Arm32's, afaict, will read one byte past the array when offset
and size match and are a multiple of 8.

> As a result, I think the reasoning in c/s b20079da9 is false, and that
> change needs re-adjusting.  I also think that x86's optimisation for
> size == 64 should be considered buggy and fixed.  TBH, I'm not sure the
> optimisation is worthwhile having in the first place.

The question though is whether, alongside offset == size potentially
being meant to be valid, offset > size is to be treated like such, too.

Jan



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

Re: [Xen-devel] [PATCH 3/4] x86/linker: add a reloc section to ELF binary

>>> On 25.06.19 at 10:10,  wrote:
> On Mon, Jun 24, 2019 at 01:24:02PM +0200, Daniel Kiper wrote:
>> On Fri, Jun 21, 2019 at 12:34:13AM -0600, Jan Beulich wrote:
>> > >>> On 19.06.19 at 17:06,  wrote:
>> > > On Wed, Jun 19, 2019 at 06:57:05AM -0600, Jan Beulich wrote:
>> > >> >>> On 19.06.19 at 13:02,  wrote:
>> > >> > If the hypervisor has been built with EFI support (ie: multiboot2).
>> > >> > This allows to position the .reloc section correctly in the output
>> > >> > binary, or else the linker might place .reloc before the .text
>> > >> > section.
>> > >> >
>> > >> > Note that the .reloc section is moved before .bss for two reasons: in
>> > >> > order for the resulting binary to not contain any section with data
>> > >> > after .bss, so that the file size can be smaller than the loaded
>> > >> > memory size, and because the data it contains is read-only, so it
>> > >> > belongs with the other sections containing read-only data.
>> > >>
>> > >> While this may be fine for ELF, I'm afraid it would be calling for
>> > >> subtle issues with xen.efi (i.e. the PE binary): There a .reloc
>> > >> section is generally expected to come after "normal" data
>> > >> sections.
>> > >
>> > > OK, would you like me to leave the .reloc section at the previous
>> > > position for EFI builds then?
>> >
>> > Well, this part is a requirement, not a question of me liking you
>> > to do so.
>> >
>> > > Or do we prefer to leave .reloc orphaned in the ELF build?
>> >
>> > Daniel might have an opinion here with his plans to actually
>> > add relocations there in the non-linker-generated-PE build. I
>> > don't have a strong opinion either way, as long as the
>> > current method of building gets left as is (or even simplified).
>> 
>> I would not drop .reloc section from xen-syms because it can be useful
>> for "manual" EFI image relocs generation. However, I am not strongly
>> tied to it. If you wish to drop it go ahead. I can readd it latter if
>> I get back to my new PE build work.
> 
> Do you mean that the dummy .reloc section added to non-PE builds can
> be dropped? (ie: remove xen/arch/x86/efi/relocs-dummy.S from the build)

Given my earlier reply it's not clear to me what you mean by "remove"
here. As a result ...

> I'm slightly lost, .reloc begin a section that's explicitly added to
> non-PE builds by relocs-dummy.S I assumed it was needed for some
> reason.

... it's also not clear what exactly you mean here, and hence whether
there's any reason needed beyond the reference to the two bounding
symbols by efi_arch_relocate_image().

Jan



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

Re: [Xen-devel] Migrating key developer docs to xen.git sphinx docs and refreshing them in the process

Hi Stefano,

On 25/06/2019 01:02, Stefano Stabellini wrote:

On Mon, 24 Jun 2019, Julien Grall wrote:

Hi Stefano,

On 6/24/19 9:23 PM, Stefano Stabellini wrote:

On Mon, 24 Jun 2019, Julien Grall wrote:

Hi,

On 24/06/2019 19:03, Stefano Stabellini wrote:

On Mon, 24 Jun 2019, Lars Kurth wrote:
I think we all agree by now that maintaining up-to-date docs on the wiki
and keeping them in sync with code changes is hard. I see moving things
from the wiki to xen.git as a great improvement. We have a few Xen on
ARM docs that are worth importing from the wiki:

https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions

I agree for this but ...

And all the board specific docs linked from it, such as:

https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/qemu-system-aarch64
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/FastModels
https://wiki.xenproject.org/wiki/HiKey960

... I think it is a pretty bad idea to import board specific docs. There
are a lot of way to build components for a given board and I am worry of
the overheard for the maintainers to look/maintain the documentation. It
also brings the question of the acceptance/removal of
a board documentation.

That problem can be solved by specifying an appropriate maintenance
model for those documents.

Instead we should provide generic guidance/troubleshoot to the user.
Anything board specific could be maintain on the wiki by someone caring
about the board without having us to gate it.

If we move the docs to xen.git it doesn't immediately imply that the
REST maintainers need to "gate" them. We could make the existing
curators of those pages the maintainers for those files, for example. We
can come up with mode ideas. We could even leave them unmaintained.

I don't think I want to add a random person as a maintainer in xen.git. So at
best we would need a new role.

This is a good point, taking into account the current governance model.
We could use R: for that?

I am not entirely sure, this still mean "THE REST" will be in charge of it.
Anyway, this is not the biggest problem here.

The point here is that we can be flexible and creative about the way to
maintain the docs on xen.git. But as a technology is certainly better
than the wiki: we don't have to keep them all up-to-date with the code,
but at least this way we have a chance (if we want to). If we leave them
on the wiki, there is no chance.

I can't see how xen.git is going to be better if "we don't have to keep them
all up-to-date".

That's because a contributor could add a patch at the end of a series to
update one of the docs, even if the doc in question comes with no
promises of being up-to-date.

I think this is going the wrong direction. The goal of using xen.git is to try
to keep the documentation up-to-date.

But my point here is most of the board should be trivial. The most of the
non-trivial setup require non-upstream patch. While I am happy to see that on
the wiki, I think xen.git should not promote such configuration at all. We are
working upstream, not with unknown/untrusted stack.

For some working fully upstream, I don't think xen.git should promote any
distros/versions of the kernel. However, this is ok on the wiki.

I would like to see the wiki disappear completely in the long term. As
we are moving more content to xen.git, it is not a good idea to have two
places where we keep information, for similar reasons why you suggested
to use in-code comments instead of docs to document interfaces. It
just takes more efforts to maintain information in two places and they
tend to get out of sync with each others.

If we make the wiki go away (I hope so), we'll need a place to store the
Arm board-specific documents, and other tutorials.

Removing the wiki is an honorable goal, however I don't think all the wiki is
suitable for xen.git. The Arm board-specific documents is an example.

You actually haven't addressed my concern above. If you look at the wiki, a lot
of them ([1], [2], [3]) contains non-upstreamed work or non-upstreamable hack.

For those containing only upstream work [4], the example is focusing on one set
of distros. In the case of QEMU, I already had some people asking whether it is
possible to use without U-boot. Why would we promote Ubuntu and not something else?

Overall, there are so many configurations possible (kernel, u-boot,
distributions) that it does not makes sense to keep track of that in xen.git.

Instead, I think we should write generic doc on how to boot Xen on a U-boot/UEFI
setup and inviting the users to look into more details for his board.

Cheers,

[1]
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X

[2]
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Stout
[3] https://wiki.xenproject.org/wiki/HiKey
[4]
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/qemu-system-aarch64

Re: [Xen-devel] [PATCH] xen/arm: io: add function swap_mmio_handler()


HiStefano,

On 25/06/2019 00:59, Stefano Stabellini wrote:

On Mon, 24 Jun 2019, Julien Grall wrote:

Hi,

On 6/24/19 9:17 PM, Stefano Stabellini wrote:

On Mon, 24 Jun 2019, Julien Grall wrote:

Hi Stefano,

On 24/06/2019 19:27, Stefano Stabellini wrote:

On Mon, 24 Jun 2019, Stefano Stabellini wrote:

On Thu, 13 Jun 2019, chenbaodong wrote:

Let me add that if you prefer to document one of the other interfaces
listed above in my email, you are welcome to pick another one. For
example, we are also missing a doc about the DomU memory map, listing
all memory regions with addresses and sizes, both MMIO and normal
memory. For that, most of the information is:

xen/include/public/arch-arm.h

A well written in-code comment in arch-arm.h would be OK, or also a
document under docs/misc/arm.


Please no duplication, it is already quite hard to maintain one place.
Instead, we should document all the headers in a documented format that
can be extracted automatically.


As we have no such thing today (as far as I am aware), please make a
proposal with a bit more details, otherwise I don't think Baodong will
be able to take the next step.


I don't have a concrete proposal so far. Except that documentation outside of
the headers is a no-go from my side. The goal of documenting within the
headers rather than outside is you also help the developer of guest OS.

A few weeks ago Ian Jackson pointed to docs/xen-headers for a potential
syntax. Sadly, there are no documentation of the script so far. I haven't had
time to look it so far.


In that case, I'd suggest for Baodong to either pick the device tree
documentation item (assuming you are OK with that one being under
docs/misc/arm) or just write a normal in-code comment in arch-arm.h for
the domU memory map not worrying about the format of the in-code comment
for now.


I don't think we have specific place for documenting device-tree so 
docs/misc/arm would be suitable.


Regarding in-code comment in arch-arm.h This will always be an improvement to 
what we have. However, it would be good if someone take an action to formalize 
the documentation format.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] mm: fix regression with deferred struct page init


Gentle ping.

I'd really like to have that in 5.2 in order to avoid the regression
introduced with 5.2-rc1.


Juergen

On 20.06.19 18:08, Juergen Gross wrote:

Commit 0e56acae4b4dd4a9 ("mm: initialize MAX_ORDER_NR_PAGES at a time
instead of doing larger sections") is causing a regression on some
systems when the kernel is booted as Xen dom0.

The system will just hang in early boot.

Reason is an endless loop in get_page_from_freelist() in case the first
zone looked at has no free memory. deferred_grow_zone() is always
returning true due to the following code snipplet:

   /* If the zone is empty somebody else may have cleared out the zone */
   if (!deferred_init_mem_pfn_range_in_zone(, zone, , ,
first_deferred_pfn)) {
   pgdat->first_deferred_pfn = ULONG_MAX;
   pgdat_resize_unlock(pgdat, );
   return true;
   }

This in turn results in the loop as get_page_from_freelist() is
assuming forward progress can be made by doing some more struct page
initialization.

Cc: Alexander Duyck 
Fixes: 0e56acae4b4dd4a9 ("mm: initialize MAX_ORDER_NR_PAGES at a time instead of 
doing larger sections")
Suggested-by: Alexander Duyck 
Signed-off-by: Juergen Gross 
---
  mm/page_alloc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d66bc8abe0af..8e3bc949ebcc 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1826,7 +1826,8 @@ deferred_grow_zone(struct zone *zone, unsigned int order)
 first_deferred_pfn)) {
pgdat->first_deferred_pfn = ULONG_MAX;
pgdat_resize_unlock(pgdat, );
-   return true;
+   /* Retry only once. */
+   return first_deferred_pfn != ULONG_MAX;
}
  
  	/*





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

Re: [Xen-devel] [PATCH 3/4] x86/linker: add a reloc section to ELF binary

On Mon, Jun 24, 2019 at 01:24:02PM +0200, Daniel Kiper wrote:
> On Fri, Jun 21, 2019 at 12:34:13AM -0600, Jan Beulich wrote:
> > >>> On 19.06.19 at 17:06,  wrote:
> > > On Wed, Jun 19, 2019 at 06:57:05AM -0600, Jan Beulich wrote:
> > >> >>> On 19.06.19 at 13:02,  wrote:
> > >> > If the hypervisor has been built with EFI support (ie: multiboot2).
> > >> > This allows to position the .reloc section correctly in the output
> > >> > binary, or else the linker might place .reloc before the .text
> > >> > section.
> > >> >
> > >> > Note that the .reloc section is moved before .bss for two reasons: in
> > >> > order for the resulting binary to not contain any section with data
> > >> > after .bss, so that the file size can be smaller than the loaded
> > >> > memory size, and because the data it contains is read-only, so it
> > >> > belongs with the other sections containing read-only data.
> > >>
> > >> While this may be fine for ELF, I'm afraid it would be calling for
> > >> subtle issues with xen.efi (i.e. the PE binary): There a .reloc
> > >> section is generally expected to come after "normal" data
> > >> sections.
> > >
> > > OK, would you like me to leave the .reloc section at the previous
> > > position for EFI builds then?
> >
> > Well, this part is a requirement, not a question of me liking you
> > to do so.
> >
> > > Or do we prefer to leave .reloc orphaned in the ELF build?
> >
> > Daniel might have an opinion here with his plans to actually
> > add relocations there in the non-linker-generated-PE build. I
> > don't have a strong opinion either way, as long as the
> > current method of building gets left as is (or even simplified).
> 
> I would not drop .reloc section from xen-syms because it can be useful
> for "manual" EFI image relocs generation. However, I am not strongly
> tied to it. If you wish to drop it go ahead. I can readd it latter if
> I get back to my new PE build work.

Do you mean that the dummy .reloc section added to non-PE builds can
be dropped? (ie: remove xen/arch/x86/efi/relocs-dummy.S from the build)

I'm slightly lost, .reloc begin a section that's explicitly added to
non-PE builds by relocs-dummy.S I assumed it was needed for some
reason.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v1] x86/mm: Clean IOMMU flags from p2m-pt code

2019-06-25 Thread Alexandru Stefan ISAILA

Are there any thoughts on this patch?

Thanks,
Alex

On 18.06.2019 14:54, Alexandru Stefan ISAILA wrote:
> At the moment the IOMMU flags are not used in p2m-pt and could be used
> on other application.
> 
> This patch aims to clean the use of IOMMU flags on the AMD p2m side.
> 
> Signed-off-by: Alexandru Isaila 
> Suggested-by: George Dunlap 
> ---
>   xen/arch/x86/mm/p2m-pt.c | 85 ++--
>   1 file changed, 3 insertions(+), 82 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> index cafc9f299b..ce6d7cdf9b 100644
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -24,7 +24,6 @@
>* along with this program; If not, see .
>*/
>   
> -#include 
>   #include 
>   #include 
>   #include 
> @@ -36,13 +35,12 @@
>   #include 
>   #include 
>   #include 
> -#include 
>   
>   #include "mm-locks.h"
>   
>   /*
>* We may store INVALID_MFN in PTEs.  We need to clip this to avoid 
> trampling
> - * over higher-order bits (NX, p2m type, IOMMU flags).  We seem to not need
> + * over higher-order bits (NX, p2m type).  We seem to not need
>* to unclip on the read path, as callers are concerned only with p2m type 
> in
>* such cases.
>*/
> @@ -165,16 +163,6 @@ p2m_free_entry(struct p2m_domain *p2m, l1_pgentry_t 
> *p2m_entry, int page_order)
>   // Returns 0 on error.
>   //
>   
> -/* AMD IOMMU: Convert next level bits and r/w bits into 24 bits p2m flags */
> -#define iommu_nlevel_to_flags(nl, f) nl) & 0x7) << 9 )|(((f) & 0x3) << 
> 21))
> -
> -static void p2m_add_iommu_flags(l1_pgentry_t *p2m_entry,
> -unsigned int nlevel, unsigned int flags)
> -{
> -if ( iommu_hap_pt_share )
> -l1e_add_flags(*p2m_entry, iommu_nlevel_to_flags(nlevel, flags));
> -}
> -
>   /* Returns: 0 for success, -errno for failure */
>   static int
>   p2m_next_level(struct p2m_domain *p2m, void **table,
> @@ -203,7 +191,6 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
>   
>   new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
>   
> -p2m_add_iommu_flags(_entry, level, 
> IOMMUF_readable|IOMMUF_writable);
>   rc = p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 
> 1);
>   if ( rc )
>   goto error;
> @@ -242,13 +229,6 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
>   
>   l1_entry = map_domain_page(mfn);
>   
> -/* Inherit original IOMMU permissions, but update Next Level. */
> -if ( iommu_hap_pt_share )
> -{
> -flags &= ~iommu_nlevel_to_flags(~0, 0);
> -flags |= iommu_nlevel_to_flags(level - 1, 0);
> -}
> -
>   for ( i = 0; i < (1u << PAGETABLE_ORDER); i++ )
>   {
>   new_entry = l1e_from_pfn(pfn | (i << ((level - 1) * 
> PAGETABLE_ORDER)),
> @@ -264,8 +244,6 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
>   unmap_domain_page(l1_entry);
>   
>   new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
> -p2m_add_iommu_flags(_entry, level,
> -IOMMUF_readable|IOMMUF_writable);
>   rc = p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry,
> level + 1);
>   if ( rc )
> @@ -470,9 +448,6 @@ static int do_recalc(struct p2m_domain *p2m, unsigned 
> long gfn)
>   }
>   
>   e = l1e_from_pfn(mfn, flags);
> -p2m_add_iommu_flags(, level,
> -(nt == p2m_ram_rw)
> -? IOMMUF_readable|IOMMUF_writable : 0);
>   ASSERT(!needs_recalc(l1, e));
>   }
>   else
> @@ -540,18 +515,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, 
> mfn_t mfn,
>   l2_pgentry_t l2e_content;
>   l3_pgentry_t l3e_content;
>   int rc;
> -unsigned int iommu_pte_flags = p2m_get_iommu_flags(p2mt, mfn);
> -/*
> - * old_mfn and iommu_old_flags control possible flush/update needs on the
> - * IOMMU: We need to flush when MFN or flags (i.e. permissions) change.
> - * iommu_old_flags being initialized to zero covers the case of the entry
> - * getting replaced being a non-present (leaf or intermediate) one. For
> - * present leaf entries the real value will get calculated below, while
> - * for present intermediate entries ~0 (guaranteed != iommu_pte_flags)
> - * will be used (to cover all cases of what the leaf entries underneath
> - * the intermediate one might be).
> - */
> -unsigned int flags, iommu_old_flags = 0;
> +unsigned int flags;
>   unsigned long old_mfn = mfn_x(INVALID_MFN);
>   
>   if ( !sve )
> @@ -599,17 +563,9 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, 
> mfn_t mfn,
>   if ( flags & _PAGE_PRESENT )
>   {
>   if ( flags & _PAGE_PSE )
> -{
>

Re: [Xen-devel] [PATCH v3] x86/altp2m: Add a new hypercall to get the active altp2m index

2019-06-25 Thread Alexandru Stefan ISAILA

Ping,

Any thoughts on this matter are appreciated.

Thanks,
Alex

On 07.06.2019 13:55, Alexandru Stefan ISAILA wrote:
> The patch adds a new lib xc function (xc_altp2m_get_vcpu_p2m_idx) that
> uses a new hvmop (HVMOP_altp2m_get_p2m_idx) to get the active altp2m
> index from a given vcpu.
> 
> Signed-off-by: Alexandru Isaila 
> 
> ---
> Changes since V2:
>   - Update comment and title
>   - Remove redundant max_vcpu check.
> ---
>   tools/libxc/include/xenctrl.h   |  2 ++
>   tools/libxc/xc_altp2m.c | 25 +
>   xen/arch/x86/hvm/hvm.c  | 23 +++
>   xen/include/public/hvm/hvm_op.h |  8 
>   4 files changed, 58 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 538007a6dc..87526af4b4 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1942,6 +1942,8 @@ int xc_altp2m_get_mem_access(xc_interface *handle, 
> uint32_t domid,
>   int xc_altp2m_change_gfn(xc_interface *handle, uint32_t domid,
>uint16_t view_id, xen_pfn_t old_gfn,
>xen_pfn_t new_gfn);
> +int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
> +   uint32_t vcpuid, uint16_t *p2midx);
>   
>   /**
>* Mem paging operations.
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index a86520c232..09dad0355e 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -352,3 +352,28 @@ int xc_altp2m_get_mem_access(xc_interface *handle, 
> uint32_t domid,
>   xc_hypercall_buffer_free(handle, arg);
>   return rc;
>   }
> +
> +int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
> +   uint32_t vcpuid, uint16_t *altp2m_idx)
> +{
> +int rc;
> +
> +DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +
> +arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
> +if ( arg == NULL )
> +return -1;
> +
> +arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
> +arg->cmd = HVMOP_altp2m_get_p2m_idx;
> +arg->domain = domid;
> +arg->u.get_vcpu_p2m_idx.vcpu_id = vcpuid;
> +
> +rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> + HYPERCALL_BUFFER_AS_ARG(arg));
> +if ( !rc )
> +*altp2m_idx = arg->u.get_vcpu_p2m_idx.altp2m_idx;
> +
> +xc_hypercall_buffer_free(handle, arg);
> +return rc;
> +}
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 029eea3b85..4ee7e6ce47 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4500,6 +4500,7 @@ static int do_altp2m_op(
>   case HVMOP_altp2m_set_mem_access_multi:
>   case HVMOP_altp2m_get_mem_access:
>   case HVMOP_altp2m_change_gfn:
> +case HVMOP_altp2m_get_p2m_idx:
>   break;
>   
>   default:
> @@ -4735,6 +4736,28 @@ static int do_altp2m_op(
>   _gfn(a.u.change_gfn.old_gfn),
>   _gfn(a.u.change_gfn.new_gfn));
>   break;
> +
> +case HVMOP_altp2m_get_p2m_idx:
> +{
> +struct vcpu *v;
> +
> +if ( !altp2m_active(d) )
> +{
> +rc = -EOPNOTSUPP;
> +break;
> +}
> +
> +if ( (v = domain_vcpu(d, a.u.get_vcpu_p2m_idx.vcpu_id)) == NULL )
> +{
> +rc = -EINVAL;
> +break;
> +}
> +
> +a.u.get_vcpu_p2m_idx.altp2m_idx = altp2m_vcpu_idx(v);
> +rc = __copy_to_guest(arg, , 1) ? -EFAULT : 0;
> +break;
> +}
> +
>   default:
>   ASSERT_UNREACHABLE();
>   }
> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
> index c6cd12f596..353f8034d9 100644
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -304,6 +304,11 @@ struct xen_hvm_altp2m_change_gfn {
>   typedef struct xen_hvm_altp2m_change_gfn xen_hvm_altp2m_change_gfn_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_change_gfn_t);
>   
> +struct xen_hvm_altp2m_get_vcpu_p2m_idx {
> +uint32_t vcpu_id;
> +uint16_t altp2m_idx;
> +};
> +
>   struct xen_hvm_altp2m_op {
>   uint32_t version;   /* HVMOP_ALTP2M_INTERFACE_VERSION */
>   uint32_t cmd;
> @@ -332,6 +337,8 @@ struct xen_hvm_altp2m_op {
>   #define HVMOP_altp2m_get_mem_access   12
>   /* Disable altp2m event notifications for a given VCPU */
>   #define HVMOP_altp2m_vcpu_disable_notify  13
> +/* Get the active vcpu p2m index */
> +#define HVMOP_altp2m_get_p2m_idx  14
>   domid_t domain;
>   uint16_t pad1;
>   uint32_t pad2;
> @@ -347,6 +354,7 @@ struct xen_hvm_altp2m_op {
>   struct xen_hvm_altp2m_set_mem_access_multi set_mem_access_multi;
>   struct xen_hvm_altp2m_suppress_ve  suppress_ve;
>   struct xen_hvm_altp2m_vcpu_disable_notify  disable_notify;
> +struct xen_hvm_altp2m_get_vcpu_p2m_idx get_vcpu_p2m_idx;
>

Re: [Xen-devel] How to compile Xen 4.12 with Clang on Linux?

On Tue, Jun 25, 2019 at 01:09:22AM +, Johnson, Ethan wrote:
> On 6/20/19 7:01 PM, Andrew Cooper wrote:
> > Xen itself doesn't use autoconf, and needs a bit of extra help getting
> > its options in order.  There is an extra clang=y variable which you need
> > to pass.
> >
> > xen.git$ make -C xen/ CC=clang-7 clang=y
> 
> Thanks! That seems to have worked.
> 
> Now I've got a new issue: it looks like Xen is trying to use an 
> optimization flag that Clang doesn't like:
> 
> --
> [ 16%] Building C object crypto/CMakeFiles/tpm_crypto.dir/hmac.o
> cd 
> /home/ejohns48/Desktop/xen-4.12.0/stubdom/tpm_emulator-x86_64/build/crypto 
> && /usr/bin/clang-7  -I/opt/local/include 
> -I/home/ejohns48/Desktop/xen-4.12.0/stubdom/tpm_emulator-x86_64 
> -I/home/ejohns48/Desktop/xen-4.12.0/stubdom/tpm_emulator-x86_64/build 
> -std=c99 -DTPM_NO_EXTERN -isystem 
> /home/ejohns48/Desktop/xen-4.12.0/stubdom/../extras/mini-os/include 
> -D__MINIOS__ -DHAVE_LIBC -isystem 
> /home/ejohns48/Desktop/xen-4.12.0/stubdom/../extras/mini-os/include/posix 
> -isystem 
> /home/ejohns48/Desktop/xen-4.12.0/stubdom/../tools/xenstore/include 
> -isystem 
> /home/ejohns48/Desktop/xen-4.12.0/stubdom/../extras/mini-os/include/x86 
> -isystem 
> /home/ejohns48/Desktop/xen-4.12.0/stubdom/../extras/mini-os/include/x86/x86_64
>  
> -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem 
> /home/ejohns48/Desktop/xen-4.12.0/stubdom/../extras/mini-os/include/posix 
> -isystem 
> /home/ejohns48/Desktop/xen-4.12.0/stubdom/cross-root-x86_64/x86_64-xen-elf/include
>  
> -isystem /usr/lib/gcc/x86_64-linux-gnu/7/include -isystem 
> /home/ejohns48/Desktop/xen-4.12.0/stubdom/lwip-x86_64/src/include 
> -isystem 
> /home/ejohns48/Desktop/xen-4.12.0/stubdom/lwip-x86_64/src/include/ipv4 
> -I/home/ejohns48/Desktop/xen-4.12.0/stubdom/include 
> -I/home/ejohns48/Desktop/xen-4.12.0/stubdom/../xen/include -mno-red-zone 
> -O1 -fno-omit-frame-pointer -O1 -fno-omit-frame-pointer  -m64 
> -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 
> -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes 
> -Wdeclaration-after-statement -Wno-unused-local-typedefs   
> -fno-stack-protector -fno-exceptions -Wno-declaration-after-statement   
> -Wall -Werror -Wextra -Wno-unused-parameter -Wpointer-arith -Wcast-align 
> -Wwrite-strings -o CMakeFiles/tpm_crypto.dir/hmac.o   -c 
> /home/ejohns48/Desktop/xen-4.12.0/stubdom/tpm_emulator-x86_64/crypto/hmac.c
> clang: error: optimization flag '-fno-reorder-blocks' is not supported 
> [-Werror,-Wignored-optimization-argument]
> --
> 
> I'm seeing this same error on other translation units as well when I run 
> "make" with multiple threads (-j24).
> 
> Is this another thing I can fix with a flag or do I need to dig deeper?

I'm not sure clang/llvm is capable of building stubdomains. The
current gitlab CI loop that tests clang/llvm has the following
snippet:

# newlib cannot be built with clang so we cannot build stubdoms
cfgargs+=("--disable-stubdom")

Which disables the stubdomain build with clang. If you need
stubdomains working with clang/llvm I'm afraid you will have to do
some digging, or else you can just disable them from configure.

Roger.

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

Re: [Xen-devel] PCI Passthrough bug with x86 HVM

On Mon, Jun 24, 2019 at 11:47:09AM -0700, Stefano Stabellini wrote:
> + xen-devel
> 
> On Mon, 24 Jun 2019, Stefano Stabellini wrote:
> > Hi all,
> > 
> > I might have found a bug with PCI passthrough to a Linux HVM guest on
> > x86 with Xen 4.12. It is not easy for me to get access, and especially
> > change components, on this particular system, and I don't have access to
> > other x86 boxes at the moment, so apologies for the partial information
> > report. The setup is as follow:
> > 
> > - two PCI devices have been assigned to a HVM guest, everything is fine
> > - reboot the guest from inside, i.e. `reboot' in Linux
> > - after the reboot completes, only one device is assigned

Can you provide the xl debug log of the whole process?

> > Before the reboot, I see all the appropriate xenstore entries for both
> > devices. Everything is fine. After the reboot, I can only see the
> > xenstore entries of one device. It is as if the other device
> > "disappeared" without throwing any errors.

So there are no errors on the hypervisor dmesg or the xl logs at all?

> > Have you seen this before? Do you know if it has been fixed in staging?
> > I noticed this fix which seems to be very relevant:
> > 
> > https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg01616.html
> > 
> > but it is already included in 4.12.

AFAICT your issue seems related to xl/libxl not properly re-adding the
devices on reboot. The fix above had to do with leaving devices in a
broken state under some circumstances (ie: they where always attached
to the guest, just not working properly).

Thanks, Roger.

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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-prev   6 xen-buildfail REGR. vs. 132889
 build-amd64-prev  6 xen-buildfail REGR. vs. 132889
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
132889
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 132889
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
132889
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
132889
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
132889

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64 17 guest-localmigrate/x10 fail in 138225 pass 
in 138368
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-saverestore fail in 138225 pass 
in 138368
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-localmigrate fail in 138225 pass 
in 138368
 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail in 138225 
pass in 138368
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 17 guest-stop fail pass in 
138225

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

Re: [Xen-devel] [PATCH v8 46/50] x86emul: support GFNI insns