Re: [Xen-devel] [PATCH v3 4/6] ALSA: xen-front: Implement handling of shared buffers

[Oleksandr Andrushchenko]

On 05/15/2018 09:01 AM, Takashi Iwai wrote:

On Tue, 15 May 2018 07:46:38 +0200,
Oleksandr Andrushchenko wrote:

On 05/14/2018 11:28 PM, Takashi Iwai wrote:

On Mon, 14 May 2018 08:27:40 +0200,
Oleksandr Andrushchenko wrote:

--- /dev/null
+++ b/sound/xen/xen_snd_front_shbuf.c
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+/*
+ * Xen para-virtual sound device
+ *
+ * Copyright (C) 2016-2018 EPAM Systems Inc.
+ *
+ * Author: Oleksandr Andrushchenko 
+ */
+
+#include 
+#include 
+
+#include "xen_snd_front_shbuf.h"

Hm, with the local build test, I get the following error:

CC [M]  sound/xen/xen_snd_front_shbuf.o
In file included from sound/xen/xen_snd_front_shbuf.c:11:0:
./include/xen/xen.h:18:8: error: unknown type name ‘bool’
 extern bool xen_pvh;
 ^~~~
 In file included from ./include/xen/interface/xen.h:30:0,
  from ./include/xen/xen.h:29,
  from sound/xen/xen_snd_front_shbuf.c:11:
./arch/x86/include/asm/xen/interface.h:92:21: error: unknown type name 
‘uint64_t’
 DEFINE_GUEST_HANDLE(uint64_t);
 ^

Adding #include  fixed the issue.

Did you really test your patches with the latest Linus tree?

My bad, it does build for ARM (which is my target), but also does
need "#include " for x86 which I didn't build this time.
Sorry about that.

Do you want me to resend this single patch or you can make the change
while applying?

Yes, it's fine.

Thank you


thanks,

Takashi



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

Re: [Xen-devel] [PATCH v3 4/6] ALSA: xen-front: Implement handling of shared buffers

[Takashi Iwai]

On Tue, 15 May 2018 07:46:38 +0200,
Oleksandr Andrushchenko wrote:
> 
> On 05/14/2018 11:28 PM, Takashi Iwai wrote:
> > On Mon, 14 May 2018 08:27:40 +0200,
> > Oleksandr Andrushchenko wrote:
> >> --- /dev/null
> >> +++ b/sound/xen/xen_snd_front_shbuf.c
> >> @@ -0,0 +1,193 @@
> >> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> >> +
> >> +/*
> >> + * Xen para-virtual sound device
> >> + *
> >> + * Copyright (C) 2016-2018 EPAM Systems Inc.
> >> + *
> >> + * Author: Oleksandr Andrushchenko 
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +
> >> +#include "xen_snd_front_shbuf.h"
> > Hm, with the local build test, I get the following error:
> >
> >CC [M]  sound/xen/xen_snd_front_shbuf.o
> >In file included from sound/xen/xen_snd_front_shbuf.c:11:0:
> >./include/xen/xen.h:18:8: error: unknown type name ‘bool’
> > extern bool xen_pvh;
> > ^~~~
> > In file included from ./include/xen/interface/xen.h:30:0,
> >  from ./include/xen/xen.h:29,
> >  from sound/xen/xen_snd_front_shbuf.c:11:
> >./arch/x86/include/asm/xen/interface.h:92:21: error: unknown type name 
> > ‘uint64_t’
> > DEFINE_GUEST_HANDLE(uint64_t);
> > ^
> > 
> > Adding #include  fixed the issue.
> >
> > Did you really test your patches with the latest Linus tree?
> My bad, it does build for ARM (which is my target), but also does
> need "#include " for x86 which I didn't build this time.
> Sorry about that.
> 
> Do you want me to resend this single patch or you can make the change
> while applying?

Yes, it's fine.


thanks,

Takashi

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

Re: [Xen-devel] [PATCH 5/5] docs/pvh: document initial MTRR state

[Jan Beulich]

>>> On 14.05.18 at 18:18,  wrote:
> On Mon, May 14, 2018 at 10:13:47AM -0600, Jan Beulich wrote:
>> >>> On 14.05.18 at 18:03,  wrote:
>> > On Thu, May 10, 2018 at 06:15:05PM +0100, Roger Pau Monne wrote:
>> >> --- a/docs/misc/pvh.markdown
>> >> +++ b/docs/misc/pvh.markdown
>> >> @@ -92,3 +92,18 @@ event channels. Delivery of those interrupts can be 
>> >> configured in the same way
>> >>  as HVM guests, check xen/include/public/hvm/params.h and
>> >>  xen/include/public/hvm/hvm\_op.h for more information about available 
>> >> delivery
>> >>  methods.
>> >> +
>> >> +## MTRR ##
>> >> +
>> >> +### Unprivileged guests ###
>> >> +
>> >> +PVH guests are booted with the default MTRR type set to write-back and 
>> >> MTRR
>> >> +enabled. This allows DomUs to start with a sane MTRR state. Note that 
>> >> this will
>> >> +have to be revisited when pci-passthrough is added to PVH in order to 
>> >> set MMIO
>> >> +regions as UC.
>> > 
>> > My reading is "revisited" implies the default type will change. In fact
>> > it shouldn't. We should clarify: for ram it will remain WB, for MMIO
>> > holes it will be UC.
>> 
>> Why would changing the default late be a problem? A firmware update on
>> bare hardware might also have such an effect. The default type read from
>> the MSR must not change across the lifetime of a VM, but imo may change
>> across reboots of it.
>> 
> 
> Then setting a default here doesn't really help OS developers because
> they will always need to write code to set the correct type -- not that
> this is a big issue, but as I understand it the point here is to avoid
> that.

Hmm, my understanding of the purpose of the series was that it aims at
establishing some sane (i.e. reasonable for an OS to expect) state, instead
of a firm "this will always be this way" one. Furthermore OSes generally
shouldn't find a need to fiddle with MTRRs, provided firmware has done a
proper job setting them up.

Jan



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

Re: [Xen-devel] [RFC][PATCH] KVM: APPLES can improve the performance of applications and virtualized systems by up to 49%

[Wei Liu]

On Sat, May 12, 2018 at 04:27:04PM +0800, Weiwei Jia wrote:
> Dear all,
> 
> Recently, we made a few improvements on effectively utilizing Pause
> Loop Exiting (PLE) support for higher throughput on virtualized
> systems. Basically, it solves two problems: 1) how to adjust
> PLE_Window; 2) how to select virtual CPUs to schedule on VM_EXITs
> caused by PLE. Our tests with standard benchmarks show that the
> approach can improve performance by up to 49%. The approach shows
> promising performance and is easy to implement. We think that it would
> be wonderful if Linux/KVM and XEN can consider the approach.
> 
> We already have a prototype implementation based on KVM (Linux Kernel
> 3.19.8). Our patch for Linux Kernel 3.19.8 and the paper describing
> our idea are available in Github repository [1][2][3]. We are pleased
> to revise our patch in order to merge it into Linux/KVM and XEN. We
> hope that you can test and adopt our approach/techniques. We are
> pleased to get some comments/suggestions on the approach and on how
> the idea can be adopted/tested by Linux/KVM and XEN. Thank you.
> 
> [1] APPLES paper: https://github.com/sysmen/apples/tree/master/paper
> [2] APPLES patch:
> https://github.com/sysmen/apples/blob/master/patches/3.19.8-APPLES.patch
> [3] APPLES patch README:
> https://github.com/sysmen/apples/blob/master/patches/README.txt
> 

Is PV spinlock involved in your test? There is no mention of it in your
paper.

Wei.

> Best Regards,
> Sysmen Research Group
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [PATCH RFC 1/7] xen: Introduce XEN_COMPILE_POSIX_TIME

[Jan Beulich]

>>> On 14.05.18 at 18:25,  wrote:
> On Mon, May 14, 2018 at 04:30:02AM -0600, Jan Beulich wrote:
>> >>> On 08.05.18 at 14:18,  wrote:
>> > On Mon, Apr 30, 2018 at 09:56:38AM -0600, Jan Beulich wrote:
>> >> >>> On 08.07.17 at 23:53,  wrote:
>> >> > @@ -164,6 +165,7 @@ delete-unfresh-files:
>> >> >  include/xen/compile.h: include/xen/compile.h.in .banner
>> >> > @sed -e 's/@@date@@/$(XEN_BUILD_DATE)/g' \
>> >> > -e 's/@@time@@/$(XEN_BUILD_TIME)/g' \
>> >> > +   -e 's/@@posix_time@@/$(XEN_BUILD_POSIX_TIME)/g' \
>> >>
>> >> In order to fill a PE header, do you really need to make this available in
>> >> compile.h?
>> >
>> > Why not? I think that we should have all time related constants defined
>> > in one place. Even if one of them is used just only once.
>>
>> I don't think so, fwiw, i.e. I'd prefer you to consume XEN_BUILD_{DATE,TIME}
>> at the point/place you want/need the time in POSIX form.
> 
> That would be perfect but TimeDateStamp in PE header requires the number of
> seconds since the epoch. And XEN_BUILD_{DATE,TIME} are in different formats.
> Hence, what should I do then?

I'm afraid I don't understand: As long as XEN_BUILD_{DATE,TIME} properly
represent the time you're after in _some_ format, surely there's a way to
convert the format to "seconds since the epoch"?

Jan



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

Re: [Xen-devel] [PATCH 3/5] hvm/mtrr: copy hardware state for Dom0

[Jan Beulich]

>>> On 14.05.18 at 18:33,  wrote:
> On Mon, May 14, 2018 at 08:26:30AM -0600, Jan Beulich wrote:
>> >>> On 10.05.18 at 19:15,  wrote:
>> > Copy the state found on the hardware when creating a PVH Dom0. Since
>> > the memory map provided to a PVH Dom0 is based on the native one using
>> > the same set of MTRR ranges should provide Dom0 with a sane MTRR state
>> > without having to manually build it in Xen.
>> > 
>> > Signed-off-by: Roger Pau Monné 
>> > ---
>> > Cc: Jan Beulich 
>> > Cc: Andrew Cooper 
>> > ---
>> >  xen/arch/x86/hvm/mtrr.c | 23 +++
>> >  1 file changed, 23 insertions(+)
>> > 
>> > diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
>> > index 95a3deabea..1cb000388a 100644
>> > --- a/xen/arch/x86/hvm/mtrr.c
>> > +++ b/xen/arch/x86/hvm/mtrr.c
>> > @@ -176,6 +176,29 @@ int hvm_vcpu_cacheattr_init(struct vcpu *v)
>> >  ((uint64_t)PAT_TYPE_UC_MINUS << 48) |   /* PAT6: UC- */
>> >  ((uint64_t)PAT_TYPE_UNCACHABLE << 56);  /* PAT7: UC */
>> >  
>> > +if ( is_hardware_domain(v->domain) )
>> > +{
>> > +/* Copy values from the host. */
>> > +struct domain *d = v->domain;
>> > +unsigned int i;
>> > +
>> > +if ( mtrr_state.have_fixed )
>> > +for ( i = 0; i < NUM_FIXED_MSR; i++ )
>> > +mtrr_fix_range_msr_set(d, m, i,
>> > +  ((uint64_t 
>> > *)mtrr_state.fixed_ranges)[i]);
>> 
>> The presence/absence of fixed range MTRRs needs to be reflected in the
>> capabilities MSR. Strictly speaking in their absence MSR access attempts to
>> the fixed range MSRs should also cause #GP, as should any attempt to
>> enable them in defType.
> 
> My intention was to always provide the fixed range MTRR capability,
> regardless of whether the underlying hardware has it or not. Then of
> course fixed ranges won't be enabled by default in the deftype MSR if
> the underlying hardware also hasn't got them enabled.

What would the result be of the OS writing to any of these MSRs, or
setting the respective enable bit?

Jan


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

Re: [Xen-devel] [PATCH RFC 2/7] xen/x86: Manually build PE header

[Jan Beulich]

>>> On 14.05.18 at 18:52,  wrote:
> On Mon, May 14, 2018 at 04:40:39AM -0600, Jan Beulich wrote:
>> >>> On 08.05.18 at 14:47,  wrote:
>> > On Fri, May 04, 2018 at 09:38:03AM -0600, Jan Beulich wrote:
>> >> >>> On 08.07.17 at 23:53,  wrote:
>> >> > +/*
>> >> > + * DOS message.
>> >> > + *
>> >> > + * It is copied from binutils package, version 2.28,
>> >> > + * include/coff/pe.h:struct external_PEI_filehdr and
>> >> > + * bfd/peXXigen.c:_bfd_XXi_only_swap_filehdr_out().
>> >> > + */
>> >> > +.long   0x0eba1f0e
>> >> > +.long   0xcd09b400
>> >> > +.long   0x4c01b821
>> >> > +.long   0x685421cd
>> >> > +.long   0x70207369
>> >> > +.long   0x72676f72
>> >> > +.long   0x63206d61
>> >> > +.long   0x6f6e6e61
>> >> > +.long   0x65622074
>> >> > +.long   0x6e757220
>> >> > +.long   0x206e6920
>> >> > +.long   0x20534f44
>> >> > +.long   0x65646f6d
>> >> > +.long   0x0a0d0d2e
>> >> > +.long   0x24
>> >> > +.long   0
>> >>
>> >> Other than what the comment says, this isn't just a message (or else you
>> >> could have used .asciz for the whole thing). I'm not convinced we need
>> >> any of this.
>> >
>> > Potentially we can drop this. However, ld from binutils put this into
>> > EFI binary. And IIRC this is exactly what is embedded by other linkers
>> > into PE/COFF compatible files, e.g. *.efi, *.exe, *.dll, etc. So,
>> > I would leave this just for the sake of compatibility.
>>
>> Having this in .exe files is indeed helpful (or at least was back when DOS 
>> still
>> played some sort of a role). In .dll it is already highly questionable, and
>> hence even more so in .efi. Let's not encode and carry cruft that's not
>> needed for anything.
> 
> OK, but I think that we should leave at least one or two instructions here, 
> e.g.
> hlt and jmp back to it or something like that. Or int 0x21 with 0x4c00 in %ax.
> Latter seems better for me.

I certainly don't mind you doing something minimalistic like what you propose.

Jan



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

Re: [Xen-devel] [PATCH RFC 6/7] xen/x86/efi: Verify dom0 kernel with SHIM_LOCK protocol in efi_multiboot2()

[Jan Beulich]

>>> On 14.05.18 at 18:56,  wrote:
> On Mon, May 14, 2018 at 04:43:13AM -0600, Jan Beulich wrote:
>> >>> On 08.05.18 at 15:09,  wrote:
>> > On Fri, May 04, 2018 at 09:46:33AM -0600, Jan Beulich wrote:
>> >> >>> On 08.07.17 at 23:53,  wrote:
>> >> > @@ -484,9 +497,12 @@ __efi64_mb2_start:
>> >> >  /* Keep the stack aligned. Do not pop a single item off it. */
>> >> >  mov (%rsp),%rdi
>> >> >
>> >> > +mov %r14d,%edx
>> >> > +
>> >> >  /*
>> >> >   * efi_multiboot2() is called according to System V AMD64 ABI:
>> >> > - *   - IN:  %rdi - EFI ImageHandle, %rsi - EFI SystemTable.
>> >> > + *   - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
>> >> > + * %rdx - dom0 kernel module struct address.
>> >>
>> >> How come everything further up treats this as a 32-bit quantity only?
>> >
>> > According to the Multiboot2 spec the bootloader is not allowed to
>> > put the kernel (xen.gz) and the modules above 4 GiB boundary.
>>
>> Interesting - how would they load a 1Gb initrd on a system with just 1Gb
>> RAM below 4Gb? Not to speak of a 4Gb initrd ...
> 
> That is not possible right now. This requires changes in the boot protocol.
> Anyway, have you seen such setups in the wild today?

Years ago we've already had to make our XenoLinux forward port cope with
512Mb+ initrd-s - see the commit introducing XEN_ELFNOTE_MOD_START_PFN,
which tells you that Xen itself needed to be changed for this as well. Those
folks wanted to be able to boot a full fledged distro without loading anything
from disk (or network) post-boot.

Jan



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

[Xen-devel] [PATCH v2 3/6] hvm/mtrr: use the hardware number of variable ranges for Dom0

[Roger Pau Monne]

Expand the size of the variable ranges array to match the size of the
underlying hardware, this is a preparatory change for copying the
hardware MTRR state for Dom0.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v1:
 - Fix hvm_msr_{read,write}_intercept().
 - Relax the checks in hvm_{save/load}_mtrr_msr.
---
 xen/arch/x86/hvm/hvm.c |  7 +--
 xen/arch/x86/hvm/mtrr.c| 34 ++
 xen/include/asm-x86/mtrr.h |  2 ++
 3 files changed, 37 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c23983cdff..8b30c93ec6 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3489,10 +3489,13 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t 
*msr_content)
 index = msr - MSR_MTRRfix4K_C;
 *msr_content = fixed_range_base[index + 3];
 break;
-case MSR_IA32_MTRR_PHYSBASE(0)...MSR_IA32_MTRR_PHYSMASK(MTRR_VCNT-1):
+case MSR_IA32_MTRR_PHYSBASE(0)...MSR_IA32_MTRR_PHYSMASK(MTRR_VCNT_MAX - 1):
 if ( !d->arch.cpuid->basic.mtrr )
 goto gp_fault;
 index = msr - MSR_IA32_MTRR_PHYSBASE(0);
+if ( (index / 2) >=
+ MASK_EXTR(v->arch.hvm_vcpu.mtrr.mtrr_cap, MTRRcap_VCNT) )
+goto gp_fault;
 *msr_content = var_range_base[index];
 break;
 
@@ -3650,7 +3653,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
  index, msr_content) )
 goto gp_fault;
 break;
-case MSR_IA32_MTRR_PHYSBASE(0)...MSR_IA32_MTRR_PHYSMASK(MTRR_VCNT-1):
+case MSR_IA32_MTRR_PHYSBASE(0)...MSR_IA32_MTRR_PHYSMASK(MTRR_VCNT_MAX - 1):
 if ( !d->arch.cpuid->basic.mtrr )
 goto gp_fault;
 if ( !mtrr_var_range_msr_set(v->domain, >arch.hvm_vcpu.mtrr,
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index bdff56a912..e71f428a3d 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -154,14 +154,26 @@ uint8_t pat_type_2_pte_flags(uint8_t pat_type)
 int hvm_vcpu_cacheattr_init(struct vcpu *v)
 {
 struct mtrr_state *m = >arch.hvm_vcpu.mtrr;
+unsigned int num_var_ranges =
+is_hardware_domain(v->domain) ? MASK_EXTR(mtrr_state.mtrr_cap,
+  MTRRcap_VCNT)
+  : MTRR_VCNT;
+
+if ( num_var_ranges > MTRR_VCNT_MAX )
+{
+ASSERT(is_hardware_domain(v->domain));
+printk("WARNING: limited Dom0 variable range MTRRs from %u to %u\n",
+   num_var_ranges, MTRR_VCNT_MAX);
+num_var_ranges = MTRR_VCNT_MAX;
+}
 
 memset(m, 0, sizeof(*m));
 
-m->var_ranges = xzalloc_array(struct mtrr_var_range, MTRR_VCNT);
+m->var_ranges = xzalloc_array(struct mtrr_var_range, num_var_ranges);
 if ( m->var_ranges == NULL )
 return -ENOMEM;
 
-m->mtrr_cap = (1u << 10) | (1u << 8) | MTRR_VCNT;
+m->mtrr_cap = (1u << 10) | (1u << 8) | num_var_ranges;
 
 v->arch.hvm_vcpu.pat_cr =
 ((uint64_t)PAT_TYPE_WRBACK) |   /* PAT0: WB */
@@ -445,6 +457,9 @@ bool_t mtrr_var_range_msr_set(
 uint64_t *var_range_base = (uint64_t*)m->var_ranges;
 
 index = msr - MSR_IA32_MTRR_PHYSBASE(0);
+if ( (index / 2) >= MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT) )
+return 0;
+
 if ( var_range_base[index] == msr_content )
 return 1;
 
@@ -675,6 +690,8 @@ static int hvm_save_mtrr_msr(struct domain *d, 
hvm_domain_context_t *h)
 /* save mtrr */
 for_each_vcpu(d, v)
 {
+unsigned int num_var_ranges;
+
 mtrr_state = >arch.hvm_vcpu.mtrr;
 
 hvm_get_guest_pat(v, _mtrr.msr_pat_cr);
@@ -683,7 +700,11 @@ static int hvm_save_mtrr_msr(struct domain *d, 
hvm_domain_context_t *h)
 | (mtrr_state->enabled << 10);
 hw_mtrr.msr_mtrr_cap = mtrr_state->mtrr_cap;
 
-for ( i = 0; i < MTRR_VCNT; i++ )
+num_var_ranges = MASK_EXTR(mtrr_state->mtrr_cap, MTRRcap_VCNT);
+if ( num_var_ranges > MTRR_VCNT )
+return -EINVAL;
+
+for ( i = 0; i < num_var_ranges; i++ )
 {
 /* save physbase */
 hw_mtrr.msr_mtrr_var[i*2] =
@@ -709,6 +730,7 @@ static int hvm_load_mtrr_msr(struct domain *d, 
hvm_domain_context_t *h)
 struct vcpu *v;
 struct mtrr_state *mtrr_state;
 struct hvm_hw_mtrr hw_mtrr;
+unsigned int num_var_ranges;
 
 vcpuid = hvm_load_instance(h);
 if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
@@ -727,10 +749,14 @@ static int hvm_load_mtrr_msr(struct domain *d, 
hvm_domain_context_t *h)
 
 mtrr_state->mtrr_cap = hw_mtrr.msr_mtrr_cap;
 
+num_var_ranges = MASK_EXTR(mtrr_state->mtrr_cap, MTRRcap_VCNT);
+if ( num_var_ranges > MTRR_VCNT )
+return -EINVAL;
+
 for ( i = 0; i < NUM_FIXED_MSR; 

[Xen-devel] [PATCH v2 5/6] libxc/pvh: set default MTRR type to write-back

[Roger Pau Monne]

And enable MTRR. This allows to provide a sane initial MTRR state for
PVH DomUs. This will have to be expanded when pci-passthrough support
is added to PVH guests, so that MMIO regions of devices are set as
UC.

Note that initial MTRR setup is done by hvmloader for HVM guests,
that's not used by PVH guests.

Signed-off-by: Roger Pau Monné 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/libxc/xc_dom_x86.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index e33a28847d..d28ff4d7e9 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -53,6 +53,9 @@
 #define X86_CR0_PE 0x01
 #define X86_CR0_ET 0x10
 
+#define MTRR_TYPE_WRBACK 6
+#define MTRR_DEF_TYPE_ENABLE (1u << 11)
+
 #define SPECIALPAGE_PAGING   0
 #define SPECIALPAGE_ACCESS   1
 #define SPECIALPAGE_SHARING  2
@@ -931,6 +934,20 @@ static int vcpu_x86_64(struct xc_dom_image *dom)
 return rc;
 }
 
+const static void *hvm_get_save_record(const void *ctx, unsigned int type,
+   unsigned int instance)
+{
+const struct hvm_save_descriptor *header;
+
+for ( header = ctx;
+  header->typecode != HVM_SAVE_CODE(END);
+  ctx += sizeof(*header) + header->length, header = ctx )
+if ( header->typecode == type && header->instance == instance )
+return ctx + sizeof(*header);
+
+return NULL;
+}
+
 static int vcpu_hvm(struct xc_dom_image *dom)
 {
 struct {
@@ -938,9 +955,12 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 HVM_SAVE_TYPE(HEADER) header;
 struct hvm_save_descriptor cpu_d;
 HVM_SAVE_TYPE(CPU) cpu;
+struct hvm_save_descriptor mtrr_d;
+HVM_SAVE_TYPE(MTRR) mtrr;
 struct hvm_save_descriptor end_d;
 HVM_SAVE_TYPE(END) end;
 } bsp_ctx;
+const HVM_SAVE_TYPE(MTRR) *mtrr_record;
 uint8_t *full_ctx = NULL;
 int rc;
 
@@ -1014,6 +1034,30 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 if ( dom->start_info_seg.pfn )
 bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;
 
+/* Set the MTRR. */
+bsp_ctx.mtrr_d.typecode = HVM_SAVE_CODE(MTRR);
+bsp_ctx.mtrr_d.instance = 0;
+bsp_ctx.mtrr_d.length = HVM_SAVE_LENGTH(MTRR);
+
+mtrr_record = hvm_get_save_record(full_ctx, HVM_SAVE_CODE(MTRR), 0);
+if ( !mtrr_record )
+{
+xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+ "%s: unable to get MTRR save record", __func__);
+goto out;
+}
+
+memcpy(_ctx.mtrr, mtrr_record, sizeof(bsp_ctx.mtrr));
+
+/* TODO: maybe this should be a firmware option instead? */
+if ( !dom->device_model )
+/*
+ * Enable MTRR, set default type to WB.
+ * TODO: add MMIO areas as UC when passthrough is supported.
+ */
+bsp_ctx.mtrr.msr_mtrr_def_type = MTRR_TYPE_WRBACK |
+ MTRR_DEF_TYPE_ENABLE;
+
 /* Set the end descriptor. */
 bsp_ctx.end_d.typecode = HVM_SAVE_CODE(END);
 bsp_ctx.end_d.instance = 0;
-- 
2.17.0


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

[Xen-devel] [PATCH v2 6/6] docs/pvh: document initial MTRR state

[Roger Pau Monne]

Provided to both Dom0 and DomUs.

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 
---
Changes since v1:
 - Add an extra paragraph to clarify the initial MTRR state.
---
 docs/misc/pvh.markdown | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/docs/misc/pvh.markdown b/docs/misc/pvh.markdown
index e85fb15374..fc31132618 100644
--- a/docs/misc/pvh.markdown
+++ b/docs/misc/pvh.markdown
@@ -92,3 +92,21 @@ event channels. Delivery of those interrupts can be 
configured in the same way
 as HVM guests, check xen/include/public/hvm/params.h and
 xen/include/public/hvm/hvm\_op.h for more information about available delivery
 methods.
+
+## MTRR ##
+
+### Unprivileged guests ###
+
+PVH guests are booted with the default MTRR type set to write-back and MTRR
+enabled. This allows DomUs to start with a sane MTRR state. Note that this will
+have to be revisited when pci-passthrough is added to PVH in order to set MMIO
+regions as UC.
+
+Xen guarantees that RAM regions will always have the WB cache type set in the
+initial MTRR state, either set by the default MTRR type or by other means.
+
+### Hardware domain ###
+
+A PVH hardware domain is booted with the same MTRR state as the one found on
+the host. This is done because the hardware domain memory map is already a
+modified copy of the host memory map, so the same MTRR setup should work.
-- 
2.17.0


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

[Xen-devel] [PATCH v2 1/6] hvm/mtrr: add emacs local variables block with formatting info

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/mtrr.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index b721c6330f..b3c08c3977 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -853,3 +853,13 @@ int epte_get_entry_emt(struct domain *d, unsigned long 
gfn, mfn_t mfn,
 
 return MTRR_TYPE_UNCACHABLE;
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.17.0


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

[Xen-devel] [PATCH v2 0/6] PVH MTRR initial stat

[Roger Pau Monne]

Hello,

The following patches set a sane initial MTRR state for both Dom0 and
DomU PVH guests. Note that for Dom0 the host MTRR state is used, OTOH
for DomU the default MTRR type is set to write-back.

This should avoid guests having to setup some kind of MTRR state in
order to boot.

Thanks, Roger.

Roger Pau Monne (6):
  hvm/mtrr: add emacs local variables block with formatting info
  mtrr: introduce mask to get VCNT from MTRRcap MSR
  hvm/mtrr: use the hardware number of variable ranges for Dom0
  hvm/mtrr: copy hardware state for Dom0
  libxc/pvh: set default MTRR type to write-back
  docs/pvh: document initial MTRR state

 docs/misc/pvh.markdown  | 18 
 tools/libxc/xc_dom_x86.c| 44 
 xen/arch/x86/cpu/mtrr/main.c|  2 +-
 xen/arch/x86/hvm/hvm.c  |  7 +++-
 xen/arch/x86/hvm/mtrr.c | 74 +
 xen/include/asm-x86/msr-index.h |  4 ++
 xen/include/asm-x86/mtrr.h  |  2 +
 7 files changed, 141 insertions(+), 10 deletions(-)

-- 
2.17.0


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

[Xen-devel] [PATCH v2 2/6] mtrr: introduce mask to get VCNT from MTRRcap MSR

[Roger Pau Monne]

No functional change.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mtrr/main.c| 2 +-
 xen/arch/x86/hvm/mtrr.c | 6 +++---
 xen/include/asm-x86/msr-index.h | 2 ++
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/main.c b/xen/arch/x86/cpu/mtrr/main.c
index 56f71a6e1f..e9df53f00d 100644
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -95,7 +95,7 @@ static void __init set_num_var_ranges(void)
config = 2;
else if (is_cpu(CENTAUR))
config = 8;
-   num_var_ranges = config & 0xff;
+   num_var_ranges = MASK_EXTR(config, MTRRcap_VCNT);
 }
 
 static void __init init_table(void)
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index b3c08c3977..bdff56a912 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -78,7 +78,7 @@ static uint8_t __read_mostly pat_entry_tbl[PAT_TYPE_NUMS] =
 bool_t is_var_mtrr_overlapped(const struct mtrr_state *m)
 {
 unsigned int seg, i;
-unsigned int num_var_ranges = (uint8_t)m->mtrr_cap;
+unsigned int num_var_ranges = MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT);
 
 for ( i = 0; i < num_var_ranges; i++ )
 {
@@ -193,7 +193,7 @@ static int get_mtrr_type(const struct mtrr_state *m,
uint8_t overlap_mtrr = 0;
uint8_t overlap_mtrr_pos = 0;
uint64_tmask = -(uint64_t)PAGE_SIZE << order;
-   unsigned int seg, num_var_ranges = m->mtrr_cap & 0xff;
+   unsigned int seg, num_var_ranges = MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT);
 
if ( unlikely(!(m->enabled & 0x2)) )
return MTRR_TYPE_UNCACHABLE;
@@ -478,7 +478,7 @@ bool_t mtrr_pat_not_equal(struct vcpu *vd, struct vcpu *vs)
 struct mtrr_state *md = >arch.hvm_vcpu.mtrr;
 struct mtrr_state *ms = >arch.hvm_vcpu.mtrr;
 int32_t res;
-uint8_t num_var_ranges = (uint8_t)md->mtrr_cap;
+uint8_t num_var_ranges = MASK_EXTR(md->mtrr_cap, MTRRcap_VCNT);
 
 /* Test fixed ranges. */
 res = memcmp(md->fixed_ranges, ms->fixed_ranges,
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index 6d94d65575..f385fbdc73 100644
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -58,6 +58,8 @@
 #define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
 
 #define MSR_MTRRcap0x00fe
+#define MTRRcap_VCNT   0x00ff
+
 #define MSR_IA32_BBL_CR_CTL0x0119
 
 #define MSR_IA32_SYSENTER_CS   0x0174
-- 
2.17.0


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

[Xen-devel] [PATCH v2 4/6] hvm/mtrr: copy hardware state for Dom0

[Roger Pau Monne]

Copy the state found on the hardware when creating a PVH Dom0. Since
the memory map provided to a PVH Dom0 is based on the native one using
the same set of MTRR ranges should provide Dom0 with a sane MTRR state
without having to manually build it in Xen.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v1:
 - Introduce and use the FE shift into the deftype MTRR MSR.
---
 xen/arch/x86/hvm/mtrr.c | 24 
 xen/include/asm-x86/msr-index.h |  2 ++
 2 files changed, 26 insertions(+)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index e71f428a3d..1e185d29c1 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -185,6 +185,30 @@ int hvm_vcpu_cacheattr_init(struct vcpu *v)
 ((uint64_t)PAT_TYPE_UC_MINUS << 48) |   /* PAT6: UC- */
 ((uint64_t)PAT_TYPE_UNCACHABLE << 56);  /* PAT7: UC */
 
+if ( is_hardware_domain(v->domain) )
+{
+/* Copy values from the host. */
+struct domain *d = v->domain;
+unsigned int i;
+
+if ( mtrr_state.have_fixed )
+for ( i = 0; i < NUM_FIXED_MSR; i++ )
+mtrr_fix_range_msr_set(d, m, i,
+  ((uint64_t 
*)mtrr_state.fixed_ranges)[i]);
+
+for ( i = 0; i < num_var_ranges; i++ )
+{
+mtrr_var_range_msr_set(d, m, MSR_IA32_MTRR_PHYSBASE(i),
+   mtrr_state.var_ranges[i].base);
+mtrr_var_range_msr_set(d, m, MSR_IA32_MTRR_PHYSMASK(i),
+   mtrr_state.var_ranges[i].mask);
+}
+
+mtrr_def_type_msr_set(d, m,
+  mtrr_state.def_type |
+  (mtrr_state.enabled << MTRRdefType_FE_SHIFT));
+}
+
 return 0;
 }
 
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index f385fbdc73..9539d6f42e 100644
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -96,6 +96,8 @@
 #define MSR_MTRRfix4K_F0x026e
 #define MSR_MTRRfix4K_F80000x026f
 #define MSR_MTRRdefType0x02ff
+#define MTRRdefType_FE_SHIFT   10
+#define MTRRdefType_FE (1u << MTRRdefType_FE_SHIFT)
 
 #define MSR_IA32_DEBUGCTLMSR   0x01d9
 #define IA32_DEBUGCTLMSR_LBR   (1<<0) /* Last Branch Record */
-- 
2.17.0


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

[Xen-devel] [PATCH for-4.11 0/3] Support matrix: add missing caveat footnotes

[Ian Jackson]

From: Ian Jackson 

Lars spotted that the support matrix
  https://xenbits.xen.org/docs/unstable/support-matrix.html
is missing some footnotes.  These three patches fix this.  I think
this is release-critical.

Ian Jackson (3):
  docs/parse-support-md: Rename RealSect to RealInSect
  docs/parse-support-md: Provide $sectnode->{RealSectNode}
  docs/parse-support-md: Correctly process caveats in multi-status
sections

 docs/parse-support-md | 54 +++
 1 file changed, 29 insertions(+), 25 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 3/3] docs/parse-support-md: Correctly process caveats in multi-status sections

[Ian Jackson]

When SUPPORT.md uses the syntax
  Status, : 
the caveats were lost (not footnoted) because they were attached
only to .

Caveats occur in running text, so they are necessarily part of a real
section, not an individual status line like that.  So attach them to
the RealSectNode, and look there for them.

Reported-by: Lars Kurth 
Signed-off-by: Ian Jackson 
---
 docs/parse-support-md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/parse-support-md b/docs/parse-support-md
index 278072f..99ce547 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -34,7 +34,7 @@ our $toplevel_sectlist = new_sectlist();
 # $sectlist->{KEY}{Children} = a further $sectlist
 # $sectlist->{KEY}{Key} = KEY
 # $sectlist->{KEY}{RealSectNode} = us, or our parent
-# $sectlist->{KEY}{HasCaveat}[VI] = trueish iff other in a Para
+# $sectlist->{KEY}{RealSectNode}{HasCaveat}[VI] = trueish iff other in a Para
 # $sectlist->{KEY}{RealInSect} = containing real section in @insections, so
 # $sectlist->{KEY}{RealInSect}{HasDescription} = VI for some Emph in Para
 # $sectlist->{KEY}{RealInSect}{Anchor} = value for < id="" > in the pandoc html
@@ -123,7 +123,7 @@ sub ri_Para {
 
 if ($had_feature) {
 my $sectnode = find_current_sectnode();
-$sectnode->{HasCaveat}[$version_index] = 1;
+$sectnode->{RealSectNode}{HasCaveat}[$version_index] = 1;
 } else {
 $insection->{HasDescription} //= $version_index;
 }
@@ -402,7 +402,7 @@ sub write_output_row ($) {
 my $nextcell = '';
 if (!defined $colspan) { # first row of this RealInSect
 $colspan= ' colspan="2"';
-if ($sectnode->{HasCaveat}[$i] && $st
+if ($sectnode->{RealSectNode}{HasCaveat}[$i] && $st
 && $sectnode->{RealInSect}{Anchor}) {
 my $rows = $sectnode->{RealInSect}{OwnRows};
 $nextcell = '

[Xen-devel] [PATCH 1/3] docs/parse-support-md: Rename RealSect to RealInSect

[Ian Jackson]

This makes the distinction between insections and sectnodes clearer.

No functional change.

Signed-off-by: Ian Jackson 
---
 docs/parse-support-md | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/docs/parse-support-md b/docs/parse-support-md
index 1c82f56..8af3acc 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -34,16 +34,16 @@ our $toplevel_sectlist = new_sectlist();
 # $sectlist->{KEY}{Children} = a further $sectlist
 # $sectlist->{KEY}{Key} = KEY
 # $sectlist->{KEY}{HasCaveat}[VI] = trueish iff other in a Para
-# $sectlist->{KEY}{RealSect} = containing real section in @insections, so
-# $sectlist->{KEY}{RealSect}{HasDescription} = VI for some Emph in Para
-# $sectlist->{KEY}{RealSect}{Anchor} = value for < id="" > in the pandoc html
+# $sectlist->{KEY}{RealInSect} = containing real section in @insections, so
+# $sectlist->{KEY}{RealInSect}{HasDescription} = VI for some Emph in Para
+# $sectlist->{KEY}{RealInSect}{Anchor} = value for < id="" > in the pandoc html
 # A $sectnode represents a single section from the original markdown
 # document.  Its subsections are in Children.
 #
 # Also, the input syntax:
 #Status, something or other: Supported
 # is treated as a $sectnode, is as if it were a subsection -
-# one called `something or other'.
+# one called `something or other'.  That is not a `real' section.
 #
 # KEY is the Anchor, or derived from the `something or other'.
 # It is used to match up identical features in different versions.
@@ -70,12 +70,12 @@ sub find_current_sectnode () {
 die unless @insections;
 
 my $sectnode;
-my $realsect;
+my $realinsect;
 foreach my $s (@insections) {
 my $sectlist = $sectnode
 ? $sectnode->{Children} : $toplevel_sectlist;
 my $key = $s->{Key};
-$realsect = $s if $s->{Anchor};
+$realinsect = $s if $s->{Anchor};
 tie %$sectlist, 'Tie::IxHash' unless tied %$sectlist;
 #print STDERR "FIND_CURRENT_SECTNODE ", Dumper($s);
 $sectlist->{$key} //=
@@ -83,7 +83,7 @@ sub find_current_sectnode () {
  Children => new_sectlist(),
  Headline => $s->{Headline},
  Key => $key,
- RealSect => $realsect,
+ RealInSect => $realinsect,
  HasCaveat => [],
 };
 $sectnode = $sectlist->{$key};
@@ -303,21 +303,21 @@ sub count_rows_sectlist ($);
 sub count_rows_sectnode ($) {
 my ($sectnode) = @_;
 my $rows = 0;
-$sectnode->{RealSect}{OwnRows} //= 0;
+$sectnode->{RealInSect}{OwnRows} //= 0;
 if ($sectnode->{Status}) {
 $rows++;
-$sectnode->{RealSect}{OwnRows}++;
+$sectnode->{RealInSect}{OwnRows}++;
 }
 $rows += count_rows_sectlist $sectnode->{Children};
 $sectnode->{Rows} = $rows;
-$sectnode->{RealSect}{Rows} = $rows;
+$sectnode->{RealInSect}{Rows} = $rows;
 return $rows;
 }
 
 # Now we have
 #   $sectnode->{Rows}
-#   $sectnode->{RealSect}{Rows}
-#   $sectnode->{RealSect}{OwnRows}
+#   $sectnode->{RealInSect}{Rows}
+#   $sectnode->{RealInSect}{OwnRows}
 
 sub count_rows_sectlist ($) {
 my ($sectlist) = @_;
@@ -344,9 +344,9 @@ sub o { print @_ or die $!; }
 our @pending_headings;
 
 sub docref_a ($$) {
-my ($i, $realsect) = @_;
+my ($i, $realinsect) = @_;
 return sprintf '',
-$version_urls[$i], $realsect->{Anchor};
+$version_urls[$i], $realinsect->{Anchor};
 }
 
 sub write_output_row ($) {
@@ -372,9 +372,9 @@ sub write_output_row ($) {
 if !%{ $heading->{Children} };
 o(' align="left">');
 my $end_a = '';
-my $desc_i = $heading->{RealSect}{HasDescription};
+my $desc_i = $heading->{RealInSect}{HasDescription};
 if (defined $desc_i) {
-o(docref_a $desc_i, $heading->{RealSect});
+o(docref_a $desc_i, $heading->{RealInSect});
 $end_a= '';
 }
 o($heading->{Headline});
@@ -394,22 +394,22 @@ sub write_output_row ($) {
 for (my $i=0; $i<@version_urls; $i++) {
 my $st = $sectnode->{Status}[$i];
 
-my $colspan = $sectnode->{RealSect}{ColSpan}[$i];
+my $colspan = $sectnode->{RealInSect}{ColSpan}[$i];
 my $nextcell = '';
-if (!defined $colspan) { # first row of this RealSect
+if (!defined $colspan) { # first row of this RealInSect
 $colspan= ' colspan="2"';
 if ($sectnode->{HasCaveat}[$i] && $st
-&& $sectnode->{RealSect}{Anchor}) {
-my $rows = $sectnode->{RealSect}{OwnRows};
+&& $sectnode->{RealInSect}{Anchor}) {
+my $rows = $sectnode->{RealInSect}{OwnRows};
 $nextcell = '1;
 $nextcell .= '>';
-$nextcell .= docref_a $i, $sectnode->{RealSect};
+

Re: [Xen-devel] [PATCH 3/4] tools: xencall, xengnttab, xengntshr: Provide access to internal fds

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] [PATCH 3/4] tools: xencall, xengnttab, 
xengntshr: Provide access to internal fds"):
> These are ABI breakages.

Thanks for the review and sorry to miss that.  You are right.

I have another question, RFC: I have a test C program which links
against Xen libraries and does the actual descriptor auditing.
Current WIP version attached to give you an idea.

Should I submit this for inclusion in xen.git#tools/tests/ ?
Or should I put it in osstest and have osstest build it ?

I think the former is probably better because then it can be used more
widely.

This thing is surrounded by two perl scripts, which grobble around in
/proc.  They contain pathname regexps, some of which are
osstest-specific.  They also have to grobble around in xenstore to
find pids and things.  I'm currently unsure as to whether these
scripts should be in xen.git or osstest.  If they go into xen.git then
they will have to take arguments for the osstest-specific
supplementary regexps, or something, which seems awkward.  So I'm
currently thinking I will put them in osstest.

Opinions welcome.

Ian.

/*
  */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include 
#include 
#include 
#include 

/*
 * Every class needs setup.  setup is called once per class at program
 * startup.
 *
 * Then it can have
 * open test getfd close
 * In which case the core code will for every fd
 * open test getfd dup2 test close
 * And test should call blocked or succeeded and then immediately
 * return, or error out
 *
 * Or it can have
 * check
 * which should call report, or error out
 *
 * Errors: use trouble for simple syscall errors.  Or use err or errx
 * and maybe print fd_desc and test_which, according to the comments
 * in struct classinfo.
 */

static xentoollog_logger *logger;

static int object_fd;
static const char *classname;
static const char *fd_desc;
static const char *test_which;

static const char *test_wh_unrest = "test (unrestricted)";
static const char *test_wh_rest   = "test (restricted)";


static void trouble(const char *what) __attribute__((noreturn));
static void trouble(const char *what) {
fprintf(stderr,
"trouble: %s %s %d (%s) %s: %s\n",
classname, test_which, object_fd, fd_desc, what, strerror(errno));
exit(-1);
}

static void report(const char *pass_or_fail, const char *what,
   const char *notes) {
printf("%s %s %d %s (%s) %s\n",
   classname, pass_or_fail,
   object_fd, what, notes, fd_desc);
if (ferror(stdout) || fflush(stdout)) err(16,"stdout");
}

static void succeeded(const char *what) {
if (test_which == test_wh_unrest) {
/* ok */
test_which = 0;
} else if (test_which == test_wh_rest) {
report("fail",what,"unexpectedly succeeded");
test_which = 0;
} else {
abort();
}
}

static void blocked(const char *what) {
if (test_which == test_wh_rest) {
/* yay */
report("pass", what,"blocked");
test_which = 0;
} else if (test_which == test_wh_unrest) {
err(4,"test blocked on unrestricted fd: %s {%s}",what,test_which);
} else {
abort();
}
}

/* privcmd */

static xc_interface *xch;
static void setup_privcmd(void) { }
static void open_privcmd(void) {
xch = xc_interface_open(logger,0,0);
if (!xch) trouble("xc_interface_open");
}
static void test_privcmd(void) {
int r = xc_get_online_cpus(xch);
if (r>0)
succeeded("xc_get_online_cpus");
else if (r==0)
errx(-1,"xc_get_online_cpus{%s, %s}=0", test_which, fd_desc);
else if (errno==EPERM)
blocked("xc_get_online_cpus");
else
trouble("xc_get_online_cpus");
}
static int getfd_privcmd(void) {
return xencall_fd(xc_interface_xcall_handle(xch));
}
static void close_privcmd(void) {
xc_interface_close(xch);
}

/* gntdev */

static xengntshr_handle *xgs;
static uint32_t gntshr_gref;
static xengnttab_handle *xgt;
static void setup_gntdev(void) {
void *r;
xgs = xengntshr_open(logger,0);
if (!xgs) trouble("xengntshr_open");
r = xengntshr_share_pages(xgs, 0, 1, _gref, 1);
if (!r || r==(void*)-1) trouble("xengntshr_share_pages");
memset(r, 0x55, XC_PAGE_SIZE);
}
static void open_gntdev(void) {
xgt = xengnttab_open(logger,0);
if (!xgt) trouble("xengnttab_open");
}
static void test_gntdev(void) {
char mybuf[XC_PAGE_SIZE];
memset(mybuf, 0xaa, XC_PAGE_SIZE);
xengnttab_grant_copy_segment_t seg;
seg.source.foreign.ref = gntshr_gref;
seg.source.foreign.offset = 0;
seg.source.foreign.domid = 0;
seg.dest.virt = mybuf;
seg.len = 1;
seg.flags = GNTCOPY_source_gref;
for (;;) {
seg.status = 0;
int r = xengnttab_grant_copy(xgt,1,);
if (r<0) {
if (errno==EPERM || errno==ENOTTY)
blocked("xengnttab_grant_copy");
else

Re: [Xen-devel] [PATCH 2/4] libxc: Provide access to internal handles

[Roger Pau Monné]

On Mon, May 14, 2018 at 06:08:57PM +0100, Ian Jackson wrote:
> In order to support auditing of qemu depriv, my audit tool wants to
> know the fd of a privcmd handle on which it can easily make
> hypercalls.  xencall provides such a handle, but has no cooked
> facilities for making hypercalls.  So I open a libxc handle.  That
> means I need to get the privcmd fd out of the libxc handle.
> 
> ISTM that it is best to do this by providing an interface to get the
> underlying library handles for a libxc handle.  This kind of interface
> is quite common elsewhere and has not caused problems.
> 
> libxc is not a stable API so the downside risk of providing this
> access is not significant.
> 
> Signed-off-by: Ian Jackson 
> ---
>  tools/libxc/include/xenctrl.h | 10 ++
>  tools/libxc/xc_private.c  |  5 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 408fa1c..d7733aa 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -183,6 +183,16 @@ enum xc_open_flags {
>   */
>  int xc_interface_close(xc_interface *xch);
>  
> +/**
> + * Return the handles which xch has opened and will use for
> + * hypercalls, foreign memory accesses and device model operations.
> + * These may be used with the corresponding libraries so long as the
> + * xch itself remains open.
> + */
> +struct xencall_handle *xc_interface_xcall_handle(xc_interface *xch);
> +struct xenforeignmemory_handle *xc_interface_fmem_handle(xc_interface *xch);
> +struct xendevicemodel_handle *xc_interface_dmod_handle(xc_interface *xch);

You introduce 3 prototypes but there's only one function being defined
below. Is this patch missing some chunks or I'm missing something
myself?

> +xencall_handle *xc_interface_xcall_handle(xc_interface *xch)
> +{
> +return xch->xcall;
> +}
> +
>  static pthread_key_t errbuf_pkey;
>  static pthread_once_t errbuf_pkey_once = PTHREAD_ONCE_INIT;

Thanks.

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

[Xen-devel] [xen-4.10-testing test] 122725: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-credit2  broken
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 122490
 test-arm64-arm64-libvirt-xsm broken  in 122688
 test-arm64-arm64-libvirt-xsm 4 host-install(4) broken in 122688 REGR. vs. 
122490

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-xl-credit2   4 host-install(4)  broken pass in 122688
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
pass in 122688

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 122688 never pass
 test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 122688 never pass
 test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 122688 never pass
 test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 122688 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-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail 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-amd64-amd64-xl-qemuu-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-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-amd64-amd64-xl-qemuu-ws16-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 

Re: [Xen-devel] Draft NVDIMM proposal

[George Dunlap]

> On May 15, 2018, at 11:05 AM, Roger Pau Monne  wrote:
> 
> Just some replies/questions to some of the points raised below.
> 
> On Fri, May 11, 2018 at 09:33:10AM -0700, Dan Williams wrote:
>> [ adding linux-nvdimm ]
>> 
>> Great write up! Some comments below...
>> 
>> On Wed, May 9, 2018 at 10:35 AM, George Dunlap  
>> wrote:
 To use a namespace, an operating system needs at a minimum two pieces
 of information: The UUID and/or Name of the namespace, and the SPA
 range where that namespace is mapped; and ideally also the Type and
 Abstraction Type to know how to interpret the data inside.
>> 
>> Not necessarily, no. Linux supports "label-less" mode where it exposes
>> the raw capacity of a region in 1:1 mapped namespace without a label.
>> This is how Linux supports "legacy" NVDIMMs that do not support
>> labels.
> 
> In that case, how does Linux know which area of the NVDIMM it should
> use to store the page structures?

The answer to that is right here:

 `fsdax` and `devdax` mode are both designed to make it possible for
 user processes to have direct mapping of NVRAM.  As such, both are
 only suitable for PMEM namespaces (?).  Both also need to have kernel
 page structures allocated for each page of NVRAM; this amounts to 64
 bytes for every 4k of NVRAM.  Memory for these page structures can
 either be allocated out of normal "system" memory, or inside the PMEM
 namespace itself.
 
 In both cases, an "info block", very similar to the BTT info block, is
 written to the beginning of the namespace when created.  This info
 block specifies whether the page structures come from system memory or
 from the namespace itself.  If from the namespace itself, it contains
 information about what parts of the namespace have been set aside for
 Linux to use for this purpose.

That is, each fsdax / devdax namespace has a superblock that, in part, defines 
what parts are used for Linux and what parts are used for data.  Or to put it a 
different way: Linux decides which parts of a namespace to use for page 
structures, and writes it down in the metadata starting in the first page of 
the namespace.


 
 Linux has also defined "Type GUIDs" for these two types of namespace
 to be stored in the namespace label, although these are not yet in the
 ACPI spec.
>> 
>> They never will be. One of the motivations for GUIDs is that an OS can
>> define private ones without needing to go back and standardize them.
>> Only GUIDs that are needed to inter-OS / pre-OS compatibility would
>> need to be defined in ACPI, and there is no expectation that other
>> OSes understand Linux's format for reserving page structure space.
> 
> Maybe it would be helpful to somehow mark those areas as
> "non-persistent" storage, so that other OSes know they can use this
> space for temporary data that doesn't need to survive across reboots?

In theory there’s no reason another OS couldn’t learn Linux’s format, discover 
where the blocks were, and use those blocks for its own purposes while Linux 
wasn’t running.

But that won’t help Xen, as we want to use those blocks while Linux *is* 
running.

 -George

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

Re: [Xen-devel] Draft NVDIMM proposal

[George Dunlap]

On 05/11/2018 05:33 PM, Dan Williams wrote:
> [ adding linux-nvdimm ]
> 
> Great write up! Some comments below...

Thanks for the quick response!

It seems I still have some fundamental misconceptions about what's going
on, so I'd better start with that. :-)

Here's the part that I'm having a hard time getting.

If actual data on the NVDIMMs is a noun, and the act of writing is a
verb, then the SPA and interleave sets are adverbs: they define *how*
the write happens.  When the processor says, "Write to address X", the
memory controller converts address X into a  tuple to actually write the data.

So, who decides what this SPA range and interleave set is?  Can the
operating system change these interleave sets and mappings, or change
data from PMEM to BLK, and is so, how?

If you read through section 13.19 of the UEFI manual, it seems to imply
that this is determined by the label area -- that each DIMM has a
separate label area describing regions local to that DIMM; and that if
you have 4 DIMMs you'll have 4 label areas, and each label area will
have a label describing the DPA region on that DIMM which corresponds to
the interleave set.  And somehow someone sets up the interleave sets and
SPA based on what's written there.

Which would mean that an operating system could change how the
interleave sets work by rewriting the various labels on the DIMMs; for
instance, changing a single 4-way set spanning the entirety of 4 DIMMs,
to one 4-way set spanning half of 4 DIMMs, and 2 2-way sets spanning
half of 2 DIMMs each.

But then you say:

> Unlike NVMe an NVDIMM itself has no concept of namespaces. Some DIMMs
> provide a "label area" which is an out-of-band non-volatile memory
> area where the OS can store whatever it likes. The UEFI 2.7
> specification defines a data format for the definition of namespaces
> on top of persistent memory ranges advertised to the OS via the ACPI
> NFIT structure.

OK, so that sounds like no, that's that what happens.  So where do the
SPA range and interleave sets come from?

Random guess: The BIOS / firmware makes it up.  Either it's hard-coded,
or there's some menu in the BIOS you can use to change things around;
but once it hits the operating system, that's it -- the mapping of SPA
range onto interleave sets onto DIMMs is, from the operating system's
point of view, fixed.

And so (here's another guess) -- when you're talking about namespaces
and label areas, you're talking about namespaces stored *within a
pre-existing SPA range*.  You use the same format as described in the
UEFI spec, but ignore all the stuff about interleave sets and whatever,
and use system physical addresses relative to the SPA range rather than
DPAs.

Is that right?

But then there's things like this:

> There is no obligation for an NVDIMM to provide a label area, and as
> far as I know all NVDIMMs on the market today do not provide a label
> area.
[snip]
> Linux supports "label-less" mode where it exposes
> the raw capacity of a region in 1:1 mapped namespace without a label.
> This is how Linux supports "legacy" NVDIMMs that do not support
> labels.

So are "all NVDIMMs on the market today" then classed as "legacy"
NVDIMMs because they don't support labels?  And if labels are simply the
NVDIMM equivalent of a partition table, then what does it mena to
"support" or "not support" labels?

And then there's this:

> In any
> event we do the DIMM to SPA association first before reading labels.
> The OS calculates a so called "Interleave Set Cookie" from the NFIT
> information to compare against a similar value stored in the labels.
> This lets the OS determine that the Interleave Set composition has not
> changed from when the labels were initially written. An Interleave Set
> Cookie mismatch indicates the labels are stale, corrupted, or that the
> physical composition of the Interleave Set has changed.

So wait, the SPA and interleave sets can actually change?  And the
labels which the OS reads actually are per-DIMM, and do control somehow
how the DPA ranges of individual DIMMs are mapped into interleave sets
and exposed as SPAs?  (And perhaps, can be changed by the operating system?)

And:

> There are checksums in the Namespace definition to account label
> validity. Starting with ACPI 6.2 DSMs for labels are deprecated in
> favor of the new / named methods for label access _LSI, _LSR, and
> _LSW.

Does this mean the methods will use checksums to verify writes to the
label area, and refuse writes which create invalid labels?

If all of the above is true, then in what way can it be said that
"NVDIMM has no concept of namespaces", that an OS can "store whatever it
likes" in the label area, and that UEFI namespaces are "on top of
persistent memory ranges advertised to the OS via the ACPI NFIT structure"?

I'm sorry if this is obvious, but I am exactly as confused as I was
before I started writing this. :-)

This is all pretty foundational.  Xen can read static ACPI tables, but
it can't do AML.  So to do a 

Re: [Xen-devel] [PATCH for-4.11 0/3] Support matrix: add missing caveat footnotes

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH for-4.11 0/3] Support matrix: add missing 
caveat footnotes"):
> For the series:
> Release-acked-by: Juergen Gross 

Thanks.

FYI, example output is here:

 https://xenbits.xen.org/people/iwj/2018/support-matrix-example-E/t.html

For my notes, I made this with

 docs/support-matrix-generate HEAD 
https://xenbits.xen.org/docs/unstable-staging/SUPPORT.html 
refs/remotes/origin/staging-NN 
https://xenbits.xen.org/docs/NN-testing/SUPPORT.html >~/public_html/t.html
 rsync -vP ~/public_html/t.html 
xenbits:public_html/2018/support-matrix-example-E/

Ian.

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

Re: [Xen-devel] [PATCH] tools/ocaml/libs/xc fix gcc-8 format-truncation warning

[Wei Liu]

CC Juergen, I think this should be in 4.11

On Tue, May 15, 2018 at 11:48:43AM +1000, John Thomson wrote:
>  CC   xenctrl_stubs.o
> xenctrl_stubs.c: In function 'failwith_xc':
> xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the 
> last format character [-Werror=format-truncation=]
>   "%d: %s: %s", error->code,
>  ^
> xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) 
> into a destination of size 1028
> snprintf(error_str, sizeof(error_str),
> ^~
>   "%d: %s: %s", error->code,
>   ~~
>   xc_error_code_to_desc(error->code),
>   ~~~
>   error->message);
>   ~~~
> cc1: all warnings being treated as errors
> make[8]: *** 
> [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: 
> xenctrl_stubs.o] Error 1
> m
> 
> Signed-off-by: John Thomson 
> ---
>  tools/ocaml/libs/xc/xenctrl_stubs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
> b/tools/ocaml/libs/xc/xenctrl_stubs.c
> index f97070c8b0..d4309ad97e 100644
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -54,7 +54,7 @@
>  
>  static void Noreturn failwith_xc(xc_interface *xch)
>  {
> - char error_str[1028];
> + char error_str[XC_MAX_ERROR_MSG_LEN + 6];
>   if (xch) {
>   const xc_error *error = xc_get_last_error(xch);
>   if (error->code == XC_ERROR_NONE)
> -- 
> 2.17.0
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Xen-devel] [PATCH v2 3/3] vpci/msi: fix update of bound MSI interrupts

[Roger Pau Monne]

Current update process of already bound MSI interrupts is wrong
because unmap_domain_pirq calls pci_disable_msi, which disables MSI
interrupts on the device. On the other hand map_domain_pirq doesn't
enable MSI, so the current update process of already enabled MSI
entries is wrong because MSI control bit will be disabled by
unmap_domain_pirq and not re-enabled by map_domain_pirq.

In order to fix this avoid unmapping the PIRQs and just update the
binding of the PIRQ. A new arch helper to do that is introduced.

Note that MSI-X is not affected because unmap_domain_pirq only
disables the MSI enable control bit for the MSI case, for MSI-X the
bit is left untouched by unmap_domain_pirq.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/arch/x86/hvm/vmsi.c | 23 +++
 xen/drivers/vpci/msi.c  |  3 +--
 xen/include/xen/vpci.h  |  2 ++
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index acadc23f8d..3001d5c488 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -699,6 +699,29 @@ static int vpci_msi_update(const struct pci_dev *pdev, 
uint32_t data,
 return 0;
 }
 
+int vpci_msi_arch_update(struct vpci_msi *msi, const struct pci_dev *pdev)
+{
+int rc;
+
+ASSERT(msi->arch.pirq != INVALID_PIRQ);
+
+pcidevs_lock();
+rc = vpci_msi_update(pdev, msi->data, msi->address, msi->vectors,
+ msi->arch.pirq, msi->mask);
+if ( rc )
+{
+spin_lock(>domain->event_lock);
+unmap_domain_pirq(pdev->domain, msi->arch.pirq);
+spin_unlock(>domain->event_lock);
+pcidevs_unlock();
+msi->arch.pirq = INVALID_PIRQ;
+return rc;
+}
+pcidevs_unlock();
+
+return 0;
+}
+
 static int vpci_msi_enable(const struct pci_dev *pdev, uint32_t data,
uint64_t address, unsigned int nr,
paddr_t table_base, uint32_t mask)
diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index ad26c38a92..8f15ad7bf2 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -87,8 +87,7 @@ static void update_msi(const struct pci_dev *pdev, struct 
vpci_msi *msi)
 if ( !msi->enabled )
 return;
 
-vpci_msi_arch_disable(msi, pdev);
-if ( vpci_msi_arch_enable(msi, pdev, msi->vectors) )
+if ( vpci_msi_arch_update(msi, pdev) )
 msi->enabled = false;
 }
 
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 72d2225a97..af2b8580ee 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -159,6 +159,8 @@ int __must_check vpci_msi_arch_enable(struct vpci_msi *msi,
   const struct pci_dev *pdev,
   unsigned int vectors);
 void vpci_msi_arch_disable(struct vpci_msi *msi, const struct pci_dev *pdev);
+int __must_check vpci_msi_arch_update(struct vpci_msi *msi,
+  const struct pci_dev *pdev);
 void vpci_msi_arch_init(struct vpci_msi *msi);
 void vpci_msi_arch_print(const struct vpci_msi *msi);
 
-- 
2.17.0


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

[Xen-devel] [PATCH v2 1/3] vpci/msi: fix unbind loop

[Roger Pau Monne]

The current unbind loop on failure in vpci_msi_enable is wrong and
will only work correctly if the initial pirq is 0. Fix this by adding
a proper bound.

Reported-by: Jan Beulich 
Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/vmsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 900d4f67d4..5ab7387d78 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -710,7 +710,7 @@ static int vpci_msi_enable(const struct pci_dev *pdev, 
uint32_t data,
  "%04x:%02x:%02x.%u: failed to bind PIRQ %u: %d\n",
  pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
  PCI_FUNC(pdev->devfn), pirq + i, rc);
-while ( bind.machine_irq-- )
+while ( bind.machine_irq-- > pirq )
 pt_irq_destroy_bind(pdev->domain, );
 spin_lock(>domain->event_lock);
 unmap_domain_pirq(pdev->domain, pirq);
-- 
2.17.0


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

[Xen-devel] [PATCH v2 2/3] vpci/msi: split code to bind pirq

[Roger Pau Monne]

And put it in a separate update function. This is required in order to
improve binding of MSI PIRQs when using vPCI.

No functional change.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/vmsi.c | 73 +
 1 file changed, 45 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 5ab7387d78..acadc23f8d 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -663,6 +663,42 @@ void vpci_msi_arch_mask(struct vpci_msi *msi, const struct 
pci_dev *pdev,
 vpci_mask_pirq(pdev->domain, msi->arch.pirq + entry, mask);
 }
 
+static int vpci_msi_update(const struct pci_dev *pdev, uint32_t data,
+   uint64_t address, unsigned int vectors,
+   unsigned int pirq, uint32_t mask)
+{
+unsigned int i;
+
+ASSERT(pcidevs_locked());
+
+for ( i = 0; i < vectors; i++ )
+{
+uint8_t vector = MASK_EXTR(data, MSI_DATA_VECTOR_MASK);
+uint8_t vector_mask = 0xff >> (8 - fls(vectors) + 1);
+struct xen_domctl_bind_pt_irq bind = {
+.machine_irq = pirq + i,
+.irq_type = PT_IRQ_TYPE_MSI,
+.u.msi.gvec = (vector & ~vector_mask) |
+  ((vector + i) & vector_mask),
+.u.msi.gflags = msi_gflags(data, address, (mask >> i) & 1),
+};
+int rc = pt_irq_create_bind(pdev->domain, );
+
+if ( rc )
+{
+gdprintk(XENLOG_ERR,
+ "%04x:%02x:%02x.%u: failed to bind PIRQ %u: %d\n",
+ pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
+ PCI_FUNC(pdev->devfn), pirq + i, rc);
+while ( bind.machine_irq-- > pirq )
+pt_irq_destroy_bind(pdev->domain, );
+return rc;
+}
+}
+
+return 0;
+}
+
 static int vpci_msi_enable(const struct pci_dev *pdev, uint32_t data,
uint64_t address, unsigned int nr,
paddr_t table_base, uint32_t mask)
@@ -674,7 +710,7 @@ static int vpci_msi_enable(const struct pci_dev *pdev, 
uint32_t data,
 .table_base = table_base,
 .entry_nr = nr,
 };
-unsigned int i, vectors = table_base ? 1 : nr;
+unsigned vectors = table_base ? 1 : nr;
 int rc, pirq = INVALID_PIRQ;
 
 /* Get a PIRQ. */
@@ -690,36 +726,17 @@ static int vpci_msi_enable(const struct pci_dev *pdev, 
uint32_t data,
 return rc;
 }
 
-for ( i = 0; i < vectors; i++ )
+pcidevs_lock();
+rc = vpci_msi_update(pdev, data, address, vectors, pirq, mask);
+if ( rc )
 {
-uint8_t vector = MASK_EXTR(data, MSI_DATA_VECTOR_MASK);
-uint8_t vector_mask = 0xff >> (8 - fls(vectors) + 1);
-struct xen_domctl_bind_pt_irq bind = {
-.machine_irq = pirq + i,
-.irq_type = PT_IRQ_TYPE_MSI,
-.u.msi.gvec = (vector & ~vector_mask) |
-  ((vector + i) & vector_mask),
-.u.msi.gflags = msi_gflags(data, address, (mask >> i) & 1),
-};
-
-pcidevs_lock();
-rc = pt_irq_create_bind(pdev->domain, );
-if ( rc )
-{
-gdprintk(XENLOG_ERR,
- "%04x:%02x:%02x.%u: failed to bind PIRQ %u: %d\n",
- pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
- PCI_FUNC(pdev->devfn), pirq + i, rc);
-while ( bind.machine_irq-- > pirq )
-pt_irq_destroy_bind(pdev->domain, );
-spin_lock(>domain->event_lock);
-unmap_domain_pirq(pdev->domain, pirq);
-spin_unlock(>domain->event_lock);
-pcidevs_unlock();
-return rc;
-}
+spin_lock(>domain->event_lock);
+unmap_domain_pirq(pdev->domain, pirq);
+spin_unlock(>domain->event_lock);
 pcidevs_unlock();
+return rc;
 }
+pcidevs_unlock();
 
 return pirq;
 }
-- 
2.17.0


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

Re: [Xen-devel] [PATCH v2 1/3] xen-hvm: create separate function for ioreq server initialization

[Anthony PERARD]

On Thu, May 10, 2018 at 10:15:16AM +0100, Paul Durrant wrote:
> The code is sufficiently substantial that it improves code readability
> to put it in a new function called by xen_hvm_init() rather than having
> it inline.
> 
> Signed-off-by: Paul Durrant 

Reviewed-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH for-4.11 0/3] Support matrix: add missing caveat footnotes

[Juergen Gross]

On 15/05/18 16:49, Ian Jackson wrote:
> From: Ian Jackson 
> 
> Lars spotted that the support matrix
>   https://xenbits.xen.org/docs/unstable/support-matrix.html
> is missing some footnotes.  These three patches fix this.  I think
> this is release-critical.
> 
> Ian Jackson (3):
>   docs/parse-support-md: Rename RealSect to RealInSect
>   docs/parse-support-md: Provide $sectnode->{RealSectNode}
>   docs/parse-support-md: Correctly process caveats in multi-status
> sections
> 
>  docs/parse-support-md | 54 
> +++
>  1 file changed, 29 insertions(+), 25 deletions(-)
> 

For the series:

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH for-4.11 0/3] Support matrix: add missing caveat footnotes

[Lars Kurth]

This seems to address the issue
Lars

On 15/05/2018, 16:06, "Ian Jackson"  wrote:

Juergen Gross writes ("Re: [PATCH for-4.11 0/3] Support matrix: add missing 
caveat footnotes"):
> For the series:
> Release-acked-by: Juergen Gross 

Thanks.

FYI, example output is here:

 https://xenbits.xen.org/people/iwj/2018/support-matrix-example-E/t.html

For my notes, I made this with

 docs/support-matrix-generate HEAD 
https://xenbits.xen.org/docs/unstable-staging/SUPPORT.html 
refs/remotes/origin/staging-NN 
https://xenbits.xen.org/docs/NN-testing/SUPPORT.html >~/public_html/t.html
 rsync -vP ~/public_html/t.html 
xenbits:public_html/2018/support-matrix-example-E/

Ian.


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

Re: [Xen-devel] [PATCH] tools/ocaml/libs/xc fix gcc-8 format-truncation warning

[Juergen Gross]

On 15/05/18 15:19, Wei Liu wrote:
> CC Juergen, I think this should be in 4.11
> 
> On Tue, May 15, 2018 at 11:48:43AM +1000, John Thomson wrote:
>>  CC   xenctrl_stubs.o
>> xenctrl_stubs.c: In function 'failwith_xc':
>> xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the 
>> last format character [-Werror=format-truncation=]
>>   "%d: %s: %s", error->code,
>>  ^
>> xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 
>> 1029) into a destination of size 1028
>> snprintf(error_str, sizeof(error_str),
>> ^~
>>   "%d: %s: %s", error->code,
>>   ~~
>>   xc_error_code_to_desc(error->code),
>>   ~~~
>>   error->message);
>>   ~~~
>> cc1: all warnings being treated as errors
>> make[8]: *** 
>> [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: 
>> xenctrl_stubs.o] Error 1
>> m
>>
>> Signed-off-by: John Thomson 

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH 4/4] libxl: Provide better error message when qemu restrict user not found

[Roger Pau Monné]

On Mon, May 14, 2018 at 06:08:59PM +0100, Ian Jackson wrote:
> Add mention of LIBXL_QEMU_USER_RANGE_BASE, in case that is what the
> user was intending.
> 
> Signed-off-by: Ian Jackson 

Reviewed-by: Roger Pau Monné 

Thanks.

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

Re: [Xen-devel] [PATCH] tools/ocaml/libs/xc fix gcc-8 format-truncation warning

[Christian Lindig]

> On 15 May 2018, at 02:48, John Thomson  
> wrote:
> 
> CC   xenctrl_stubs.o
> xenctrl_stubs.c: In function 'failwith_xc':
> xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the 
> last format character [-Werror=format-truncation=]
>  "%d: %s: %s", error->code,
> ^
> xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) 
> into a destination of size 1028
>snprintf(error_str, sizeof(error_str),
>^~
>  "%d: %s: %s", error->code,
>  ~~
>  xc_error_code_to_desc(error->code),
>  ~~~
>  error->message);
>  ~~~
> cc1: all warnings being treated as errors
> make[8]: *** 
> [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: 
> xenctrl_stubs.o] Error 1
> m
> 
> Signed-off-by: John Thomson 
> ---
> tools/ocaml/libs/xc/xenctrl_stubs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
> b/tools/ocaml/libs/xc/xenctrl_stubs.c
> index f97070c8b0..d4309ad97e 100644
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -54,7 +54,7 @@
> 
> static void Noreturn failwith_xc(xc_interface *xch)
> {
> - char error_str[1028];
> + char error_str[XC_MAX_ERROR_MSG_LEN + 6];
>   if (xch) {
>   const xc_error *error = xc_get_last_error(xch);
>   if (error->code == XC_ERROR_NONE)
> -- 
> 2.17.0
> 


Acked-by: Christian Lindig 


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

Re: [Xen-devel] Draft NVDIMM proposal

[Roger Pau Monné]

Just some replies/questions to some of the points raised below.

On Fri, May 11, 2018 at 09:33:10AM -0700, Dan Williams wrote:
> [ adding linux-nvdimm ]
> 
> Great write up! Some comments below...
> 
> On Wed, May 9, 2018 at 10:35 AM, George Dunlap  
> wrote:
> >> To use a namespace, an operating system needs at a minimum two pieces
> >> of information: The UUID and/or Name of the namespace, and the SPA
> >> range where that namespace is mapped; and ideally also the Type and
> >> Abstraction Type to know how to interpret the data inside.
> 
> Not necessarily, no. Linux supports "label-less" mode where it exposes
> the raw capacity of a region in 1:1 mapped namespace without a label.
> This is how Linux supports "legacy" NVDIMMs that do not support
> labels.

In that case, how does Linux know which area of the NVDIMM it should
use to store the page structures?

> >> `fsdax` and `devdax` mode are both designed to make it possible for
> >> user processes to have direct mapping of NVRAM.  As such, both are
> >> only suitable for PMEM namespaces (?).  Both also need to have kernel
> >> page structures allocated for each page of NVRAM; this amounts to 64
> >> bytes for every 4k of NVRAM.  Memory for these page structures can
> >> either be allocated out of normal "system" memory, or inside the PMEM
> >> namespace itself.
> >>
> >> In both cases, an "info block", very similar to the BTT info block, is
> >> written to the beginning of the namespace when created.  This info
> >> block specifies whether the page structures come from system memory or
> >> from the namespace itself.  If from the namespace itself, it contains
> >> information about what parts of the namespace have been set aside for
> >> Linux to use for this purpose.
> >>
> >> Linux has also defined "Type GUIDs" for these two types of namespace
> >> to be stored in the namespace label, although these are not yet in the
> >> ACPI spec.
> 
> They never will be. One of the motivations for GUIDs is that an OS can
> define private ones without needing to go back and standardize them.
> Only GUIDs that are needed to inter-OS / pre-OS compatibility would
> need to be defined in ACPI, and there is no expectation that other
> OSes understand Linux's format for reserving page structure space.

Maybe it would be helpful to somehow mark those areas as
"non-persistent" storage, so that other OSes know they can use this
space for temporary data that doesn't need to survive across reboots?

> >> # Proposed design / roadmap
> >>
> >> Initially, dom0 accesses the NVRAM as normal, using static ACPI tables
> >> and the DSM methods; mappings are treated by Xen during this phase as
> >> MMIO.
> >>
> >> Once dom0 is ready to pass parts of a namespace through to a guest, it
> >> makes a hypercall to tell Xen about the namespace.  It includes any
> >> regions of the namespace which Xen may use for 'scratch'; it also
> >> includes a flag to indicate whether this 'scratch' space may be used
> >> for frame tables from other namespaces.
> >>
> >> Frame tables are then created for this SPA range.  They will be
> >> allocated from, in this order: 1) designated 'scratch' range from
> >> within this namespace 2) designated 'scratch' range from other
> >> namespaces which has been marked as sharable 3) system RAM.
> >>
> >> Xen will either verify that dom0 has no existing mappings, or promote
> >> the mappings to full pages (taking appropriate reference counts for
> >> mappings).  Dom0 must ensure that this namespace is not unmapped,
> >> modified, or relocated until it asks Xen to unmap it.
> >>
> >> For Xen frame tables, to begin with, set aside a partition inside a
> >> namespace to be used by Xen.  Pass this in to Xen when activating the
> >> namespace; this could be either 2a or 3a from "Page structure
> >> allocation".  After that, we could decide which of the two more
> >> streamlined approaches (2b or 3b) to pursue.
> >>
> >> At this point, dom0 can pass parts of the mapped namespace into
> >> guests.  Unfortunately, passing files on a fsdax filesystem is
> >> probably not safe; but we can pass in full dev-dax or fsdax
> >> partitions.
> >>
> >> From a guest perspective, I propose we provide static NFIT only, no
> >> access to labels to begin with.  This can be generated in hvmloader
> >> and/or the toolstack acpi code.
> 
> I'm ignorant of Xen internals, but can you not reuse the existing QEMU
> emulation for labels and NFIT?

We only use QEMU for HVM guests, which would still leave PVH guests
without NVDIMM support. Ideally we would like to use the same solution
for both HVM and PVH, which means QEMU cannot be part of that
solution.

Thanks, Roger.

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

[Xen-devel] [PATCH v4 05/10] xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume

[Mirela Simonovic]

In existing code the virtual paging for non-boot CPUs is setup only on boot.
The setup is triggered from start_xen() after all CPUs are brought online.
In other words, the initialization of VTCR_EL2 register is done out of the
cpu_up/start_secondary() control flow. However, the cpu_up flow is also used
to hotplug non-boot CPUs on resume from suspend to RAM state, in which case
the virtual paging will not be configured.

With this patch the setting of paging is triggered from start_secondary()
function using cpu starting notifier (notify_cpu_starting() call). The
notifier is registered in p2m.c using init call. This has to be done with
init call rather than presmp_init because the registered callback depends
on vtcr configuration value which is setup after the presmp init calls
are executed (do_presmp_initcalls() called from start_xen()). Init calls
are executed after initial virtual paging is set up for all CPUs on boot.
This ensures that no callback can fire until the vtcr value is calculated
by Xen and virtual paging is set up initially for all CPUs. Also, this way
the virtual paging setup in boot scenario remains unchanged.

It is assumed here that after the system completed the boot, CPUs that
execute start_secondary() were booted as well when the Xen itself was
booted. According to this assumption non-boot CPUs will always be compliant
with the VTCR_EL2 value that was selected by Xen on boot.
Currently, there is no mechanism to trigger hotplugging of a CPU. This
will be added with the suspend to RAM support for ARM, where the hotplug
of non-boot CPUs will be triggered via enable_nonboot_cpus() call.

Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v2:
-Fix commit message
-Save configured VTCR_EL2 value into static variable that will be used
 by non-boot CPUs on hotplug
-Add setup_virt_paging_secondary() and invoke it from start_secondary()
 if that CPU has to setup virtual paging (if the system state is not boot)

Changes in v3:
-Fix commit message
-Remove setup_virt_paging_secondary() and use notifier to setup virtual
 paging for non-boot CPU on hotplug.
-In setup_virt_paging() use vtcr static variable instead of local val
-In setup_virt_paging_one() use vtcr static variable instead of provided
 argument

Changes in v4:
-Add includes alphabetically
-Add newline before return in cpu_virt_paging_init()
-Fix indentation in cpu_virt_paging_callback() definition
-Use local val in setup_virt_paging() for calculation, assign it to vtcr
 after the calculation is done
-Remove priority initialization in the notifier structure (priority
 doesn't matter here)

Signed-off-by: Mirela Simonovic 
---
 xen/arch/arm/p2m.c | 53 -
 1 file changed, 48 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d43c3aa896..924226f63c 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -1451,10 +1453,12 @@ err:
 return page;
 }
 
-static void __init setup_virt_paging_one(void *data)
+/* VTCR value to be configured by all CPUs. Set only once by the boot CPU */
+static uint64_t __read_mostly vtcr;
+
+static void setup_virt_paging_one(void *data)
 {
-unsigned long val = (unsigned long)data;
-WRITE_SYSREG32(val, VTCR_EL2);
+WRITE_SYSREG32(vtcr, VTCR_EL2);
 isb();
 }
 
@@ -1538,10 +1542,49 @@ void __init setup_virt_paging(void)
 
 /* It is not allowed to concatenate a level zero root */
 BUG_ON( P2M_ROOT_LEVEL == 0 && P2M_ROOT_ORDER > 0 );
-setup_virt_paging_one((void *)val);
-smp_call_function(setup_virt_paging_one, (void *)val, 1);
+vtcr = val;
+setup_virt_paging_one(NULL);
+smp_call_function(setup_virt_paging_one, NULL, 1);
+}
+
+static int cpu_virt_paging_callback(struct notifier_block *nfb,
+unsigned long action,
+void *hcpu)
+{
+switch ( action )
+{
+case CPU_STARTING:
+ASSERT(system_state != SYS_STATE_boot);
+setup_virt_paging_one(NULL);
+break;
+default:
+break;
+}
+
+return NOTIFY_DONE;
 }
 
+static struct notifier_block cpu_virt_paging_nfb = {
+.notifier_call = cpu_virt_paging_callback,
+};
+
+static int __init cpu_virt_paging_init(void)
+{
+register_cpu_notifier(_virt_paging_nfb);
+
+return 0;
+}
+/*
+ * Initialization of the notifier has to be done at init rather than 
presmp_init
+ * phase because: the registered notifier is used to setup virtual paging for
+ * non-boot CPUs after the initial virtual paging for all CPUs is already 
setup,
+ * i.e. when a non-boot CPU is hotplugged after the system has booted. In other
+ * words, the notifier should be registered after the virtual paging is
+ 

[Xen-devel] [PATCH v4 04/10] xen/arm: Remove __initdata and __init to enable CPU hotplug

[Mirela Simonovic]

CPU up flow is currently used during the initial boot to start secondary
CPUs. However, the same flow should be used for CPU hotplug, e.g. when
hotplugging secondary CPUs within the resume procedure (resume from the
suspend to RAM). Therefore, prefixes __initdata and __init had to be removed
from few data structures and functions that are used within the cpu up flow.

Signed-off-by: Mirela Simonovic 
Acked-by: Julien Grall 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v3:
- Added acked-by Julien
---
 xen/arch/arm/arm64/smpboot.c   | 2 +-
 xen/arch/arm/irq.c | 2 +-
 xen/arch/arm/processor.c   | 2 +-
 xen/arch/arm/smpboot.c | 4 ++--
 xen/include/asm-arm/procinfo.h | 4 ++--
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/arm64/smpboot.c b/xen/arch/arm/arm64/smpboot.c
index 4fd0ac68b7..694fbf67e6 100644
--- a/xen/arch/arm/arm64/smpboot.c
+++ b/xen/arch/arm/arm64/smpboot.c
@@ -104,7 +104,7 @@ int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
 return smp_psci_init(cpu);
 }
 
-int __init arch_cpu_up(int cpu)
+int arch_cpu_up(int cpu)
 {
 if ( !smp_enable_ops[cpu].prepare_cpu )
 return -ENODEV;
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index aa4e832cae..098281f8ab 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -65,7 +65,7 @@ irq_desc_t *__irq_to_desc(int irq)
 return _desc[irq-NR_LOCAL_IRQS];
 }
 
-int __init arch_init_one_irq_desc(struct irq_desc *desc)
+int arch_init_one_irq_desc(struct irq_desc *desc)
 {
 desc->arch.type = IRQ_TYPE_INVALID;
 return 0;
diff --git a/xen/arch/arm/processor.c b/xen/arch/arm/processor.c
index ce4385064a..acad8b31d6 100644
--- a/xen/arch/arm/processor.c
+++ b/xen/arch/arm/processor.c
@@ -20,7 +20,7 @@
 
 static DEFINE_PER_CPU(struct processor *, processor);
 
-void __init processor_setup(void)
+void processor_setup(void)
 {
 const struct proc_info_list *procinfo;
 
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 8b1e274bf3..ad1f6b751b 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -52,8 +52,8 @@ nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 static unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
__attribute__((__aligned__(STACK_SIZE)));
 
-/* Initial boot cpu data */
-struct init_info __initdata init_data =
+/* Boot cpu data */
+struct init_info init_data =
 {
 .stack = cpu0_boot_stack,
 };
diff --git a/xen/include/asm-arm/procinfo.h b/xen/include/asm-arm/procinfo.h
index 26306b35f8..02be56e348 100644
--- a/xen/include/asm-arm/procinfo.h
+++ b/xen/include/asm-arm/procinfo.h
@@ -35,9 +35,9 @@ struct proc_info_list {
 struct processor*processor;
 };
 
-const __init struct proc_info_list *lookup_processor_type(void);
+const struct proc_info_list *lookup_processor_type(void);
 
-void __init processor_setup(void);
+void processor_setup(void);
 void processor_vcpu_initialise(struct vcpu *v);
 
 #endif
-- 
2.13.0


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

[Xen-devel] [PATCH v4 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Mirela Simonovic]

On boot, enabling errata workarounds will be triggered by the boot CPU
from start_xen(). On CPU hotplug (non-boot scenario) this would not be
done. This patch adds the code required to enable errata workarounds for
a CPU being hotplugged after the system boots. This is triggered using
a notifier. If the CPU fails to enable workarounds the notifier will
return an error and Xen will hit the BUG_ON() in notify_cpu_starting().
To avoid the BUG_ON() in an error case either enabling notifiers should
be fixed to return void (not propagate error to notify_cpu_starting())
and the errata notifier will always return success for CPU_STARTING
event, or the notify_cpu_starting() and other common code should be
fixed to expect an error at CPU_STARTING phase.

Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v4:
-Add includes alphabetically
-Added newline before the return in cpu_errata_notifier_init()
-Enabling capabilities returns an error if enabling a capability fails
 (enable_nonboot_cpu_caps() returns int instead of void). When enabling
 any of the capability fails the error is remembered into a variable and
 the remaining capabilities are enabled. If enabling multiple capabilities
 fails the error returned by enable_nonboot_cpu_caps() represents the
 error code of the last failure.
-Callback enable_nonboot_cpu_caps() can return an error when CPU_STARTING
 fires. This is not right because of the assumption that starting a CPU
 cannot fail at this phase. Consequently, if an error happens it will
 cause Xen to hit the BUG_ON() in notify_cpu_starting(). In future,
 either this notifier/enabling capabilities should be fixed to always
 return success/void, or notify_cpu_starting() and other common code
 should be fixed to expect an error at CPU_STARTING phase.
-Fix commit message to reflect changes in v4
---
 xen/arch/arm/cpuerrata.c | 49 
 xen/arch/arm/cpufeature.c| 29 
 xen/include/asm-arm/cpufeature.h |  1 +
 3 files changed, 79 insertions(+)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 1baa20654b..b829d226ef 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -1,3 +1,4 @@
+#include 
 #include 
 #include 
 #include 
@@ -5,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -349,6 +351,53 @@ void __init enable_errata_workarounds(void)
 enable_cpu_capabilities(arm_errata);
 }
 
+static int cpu_errata_callback(struct notifier_block *nfb,
+   unsigned long action,
+   void *hcpu)
+{
+int rc = 0;
+
+switch ( action )
+{
+case CPU_STARTING:
+/*
+ * At CPU_STARTING phase no notifier shall return an error, because the
+ * system is designed with the assumption that starting a CPU cannot
+ * fail at this point. If an error happens here it will cause Xen to 
hit
+ * the BUG_ON() in notify_cpu_starting(). In future, either this
+ * notifier/enabling capabilities should be fixed to always return
+ * success/void or notify_cpu_starting() and other common code should 
be
+ * fixed to expect an error at CPU_STARTING phase.
+ */
+ASSERT(system_state != SYS_STATE_boot);
+rc = enable_nonboot_cpu_caps(arm_errata);
+break;
+default:
+break;
+}
+
+return !rc ? NOTIFY_DONE : notifier_from_errno(rc);
+}
+
+static struct notifier_block cpu_errata_nfb = {
+.notifier_call = cpu_errata_callback,
+};
+
+static int __init cpu_errata_notifier_init(void)
+{
+register_cpu_notifier(_errata_nfb);
+
+return 0;
+}
+/*
+ * Initialization has to be done at init rather than presmp_init phase because
+ * the callback should execute only after the secondary CPUs are initially
+ * booted (in hotplug scenarios when the system state is not boot). On boot,
+ * the enabling of errata workarounds will be triggered by the boot CPU from
+ * start_xen().
+ */
+__initcall(cpu_errata_notifier_init);
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 525b45e22f..3aaff4c0e6 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -69,6 +69,35 @@ void __init enable_cpu_capabilities(const struct 
arm_cpu_capabilities *caps)
 }
 
 /*
+ * Run through the enabled capabilities and enable() them on the calling CPU.
+ * If enabling of any capability fails the error is returned. After enabling a
+ * capability fails the error will be remembered into 'rc' and the remaining
+ * capabilities will be enabled. If enabling multiple capabilities fail the
+ * error returned by this function represents the error code of the last
+ * failure.
+ */
+int enable_nonboot_cpu_caps(const struct arm_cpu_capabilities *caps)
+{
+int rc 

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Mirela Simonovic]

Hi Stefano,

On Mon, May 14, 2018 at 6:59 PM, Stefano Stabellini
 wrote:
> On Mon, 14 May 2018, Julien Grall wrote:
>> On 11/05/18 22:47, Stefano Stabellini wrote:
>> > On Fri, 11 May 2018, Dario Faggioli wrote:
>> > > On Fri, 2018-05-11 at 14:08 +0100, Julien Grall wrote:
>> > > > The whole idea here is we have only one place taking the decision and
>> > > > we
>> > > > don't spread BUG_ON()/panic/stop_cpu everywhere. The benefit is
>> > > > having
>> > > > only one place to fix over multiple one because very likely the
>> > > > decision
>> > > > is the same everywhere.
>> > > >
>> > > > I agree that today it will end up to crashing the system because of
>> > > > the
>> > > > BUG_ON. But that's a separate topic.
>> > > >
>> > > Yes!!! :-D
>> > >
>> > > I.e., as I've said countless times, I would think that a series which
>> > > introduces a CPU_STARTING notifier that fails, should also deal with
>> > > adjusting the CPU process accordingly.
>> > >
>> > > *BUT* if you ARM people are ok with arch/arm/ code that does that,
>> > > perhaps with a comment saying something like:
>> > >
>> > > "This will cause us to hit the BUG_ON() in notify_cpu_starting(). To
>> > > fix that, we need to properly change the CPU bringup code, which will
>> > > happen in a leter series."
>> > >
>> > > that would also work, I guess. :-)
>> >
>> > Yes, I think that returning error with an in-code comment on top is the
>> > best solution.
>>
>> It is the second best solution ;). If we consider the notifier can return an
>> error, then best solution is to fix notify_cpu_starting().
>>
>> I would be ok with the second best solution if we have someone to fix it for
>> Xen 4.12. Per my understanding, Mirela is not going to do it. So what's the
>> plan here?
>
> I can look at fixing notify_cpu_starting(). I am also OK with you
> reworking the vmap code as you suggested below. Regardless, I think
> Mirela should go ahead with the comment now. Then, either you or me are
> going to come in and remove the comment one way or another (either
> fixing notify_cpu_starting or imposing all the callbacks to never return
> an error).
>

Thanks, I submitted v4.

Regards,
Mirela

>
>> Another solution is to impose all the enable callbacks to never return an
>> error (AFAICT Linux is just ignoring the return of the callback)).
>>
>> Today, we happen to return an error only in the case vmap is failing (used to
>> remapped vector table read-write). It might be possible to avoid the 
>> potential
>> re-mapping failure by reworking the code.
>>
>> I could explore that solution if we prefer going towards imposing all the
>> enable callbacks to never return an error.

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

[Xen-devel] [PATCH v4 08/10] xen/arm: Disable timers and release their interrupts on CPU hot-unplug

[Mirela Simonovic]

When a CPU is hot-unplugged we need to disable timers and release
their interrupts in order to free the memory that was allocated when
interrupts were requested (using request_irq()). The request_irq()
is called for each timer interrupt when the CPU gets hotplugged
(start_secondary->init_timer_interrupt->request_irq).
With this patch timers will be disabled and interrupts will be
released when the newly added callback receives CPU_DYING event.

Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v3:
-Trigger releasing of timer interrupts using notifiers

Changes in v4:
-Fix commit message to include disabling of timers
-Disable timers prior to releasing interrupts
-Add new line before the return in cpu_time_notifier_init()
-Add includes alphabetically
-Fix indentation in cpu_time_callback() definition
---
 xen/arch/arm/time.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index c11fcfeadd..1635c8822d 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -312,6 +314,21 @@ void init_timer_interrupt(void)
 check_timer_irq_cfg(timer_irq[TIMER_PHYS_NONSECURE_PPI], "NS-physical");
 }
 
+/*
+ * Revert actions done in init_timer_interrupt that are required to properly
+ * disable this CPU.
+ */
+static void deinit_timer_interrupt(void)
+{
+WRITE_SYSREG32(0, CNTP_CTL_EL0);/* Disable physical timer */
+WRITE_SYSREG32(0, CNTHP_CTL_EL2);   /* Disable hypervisor's timer */
+isb();
+
+release_irq(timer_irq[TIMER_HYP_PPI], NULL);
+release_irq(timer_irq[TIMER_VIRT_PPI], NULL);
+release_irq(timer_irq[TIMER_PHYS_NONSECURE_PPI], NULL);
+}
+
 /* Wait a set number of microseconds */
 void udelay(unsigned long usecs)
 {
@@ -340,6 +357,34 @@ void domain_set_time_offset(struct domain *d, int64_t 
time_offset_seconds)
 /* XXX update guest visible wallclock time */
 }
 
+static int cpu_time_callback(struct notifier_block *nfb,
+ unsigned long action,
+ void *hcpu)
+{
+switch ( action )
+{
+case CPU_DYING:
+deinit_timer_interrupt();
+break;
+default:
+break;
+}
+
+return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_time_nfb = {
+.notifier_call = cpu_time_callback,
+};
+
+static int __init cpu_time_notifier_init(void)
+{
+register_cpu_notifier(_time_nfb);
+
+return 0;
+}
+__initcall(cpu_time_notifier_init);
+
 /*
  * Local variables:
  * mode: C
-- 
2.13.0


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

[Xen-devel] [PATCH v4 06/10] xen/common: Restore IRQ affinity when hotplugging a pCPU

[Mirela Simonovic]

Non-boot pCPUs are being hot-unplugged during the system suspend to
RAM and hotplugged during the resume. When non-boot pCPUs are
hot-unplugged the interrupts that were targeted to them are migrated
to the boot pCPU.
On suspend, each guest could have its own wake-up devices/interrupts
(passthrough) that could trigger the system resume. These interrupts
could be targeted to a non-boot pCPU, e.g. if the guest's vCPU is
pinned to a non-boot pCPU. Due to the hot-unplug of non-boot pCPUs
during the suspend such interrupts will be migrated from non-boot pCPUs
to the boot pCPU (this is fine). However, when non-boot pCPUs are
hotplugged on resume, these interrupts are not migrated back to non-boot
pCPUs, i.e. IRQ affinity is not restored on resume (this is wrong).
This patch adds the restoration of IRQ affinity when a pCPU is hotplugged.

Signed-off-by: Mirela Simonovic 
Reviewed-by: Dario Faggioli 

---
CC: George Dunlap 
CC: Dario Faggioli 
---
Changes in v2:
-Instead of checking whether the affinity was broken check whether
 vcpu's processor has changed in order to trigger restoring of the
 IRQ affinity
-Fix commit message

Changes in v4:
-Added reviewed by Dario
---
 xen/common/schedule.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 049f93f7aa..ccf936db83 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -737,6 +737,7 @@ void restore_vcpu_affinity(struct domain *d)
 for_each_vcpu ( d, v )
 {
 spinlock_t *lock;
+unsigned int old_cpu = v->processor;
 
 ASSERT(!vcpu_runnable(v));
 
@@ -769,6 +770,9 @@ void restore_vcpu_affinity(struct domain *d)
 lock = vcpu_schedule_lock_irq(v);
 v->processor = SCHED_OP(vcpu_scheduler(v), pick_cpu, v);
 spin_unlock_irq(lock);
+
+if ( old_cpu != v->processor )
+sched_move_irqs(v);
 }
 
 domain_update_node_affinity(d);
-- 
2.13.0


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

[Xen-devel] [PATCH v4 01/10] xen/arm64: Added handling of the trapped access to OSLSR register

[Mirela Simonovic]

Linux/dom0 accesses OSLSR register when saving CPU context during the
suspend procedure. Xen traps access to this register, but has no handling
for it. Consequently, Xen injects undef exception to linux, causing it to
crash. This patch adds handling of the trapped access to OSLSR as ro/raz.

Signed-off-by: Mirela Simonovic 
Reviewed-by: Stefano Stabellini 
Acked-by: Julien Grall 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v2:
- Commit message fix (arm64 related change instead of arm)
- Add Stefano's reviewed-by

Changes in v3:
- Added Julien's acked-by
---
 xen/arch/arm/arm64/vsysreg.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index c57ac12503..8f80e1735e 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -57,13 +57,14 @@ void do_sysreg(struct cpu_user_regs *regs,
  * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
  *
  * Unhandled:
- *OSLSR_EL1
  *DBGPRCR_EL1
  */
 case HSR_SYSREG_OSLAR_EL1:
 return handle_wo_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
 case HSR_SYSREG_OSDLR_EL1:
 return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
+case HSR_SYSREG_OSLSR_EL1:
+return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, 1);
 
 /*
  * MDCR_EL2.TDA
-- 
2.13.0


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

Re: [Xen-devel] [PATCH 3/5] hvm/mtrr: copy hardware state for Dom0

[Roger Pau Monné]

On Tue, May 15, 2018 at 02:48:16AM -0600, Jan Beulich wrote:
> >>> On 15.05.18 at 10:35,  wrote:
> > On Tue, May 15, 2018 at 01:52:43AM -0600, Jan Beulich wrote:
> >> >>> On 14.05.18 at 18:33,  wrote:
> >> > On Mon, May 14, 2018 at 08:26:30AM -0600, Jan Beulich wrote:
> >> >> >>> On 10.05.18 at 19:15,  wrote:
> >> >> > Copy the state found on the hardware when creating a PVH Dom0. Since
> >> >> > the memory map provided to a PVH Dom0 is based on the native one using
> >> >> > the same set of MTRR ranges should provide Dom0 with a sane MTRR state
> >> >> > without having to manually build it in Xen.
> >> >> > 
> >> >> > Signed-off-by: Roger Pau Monné 
> >> >> > ---
> >> >> > Cc: Jan Beulich 
> >> >> > Cc: Andrew Cooper 
> >> >> > ---
> >> >> >  xen/arch/x86/hvm/mtrr.c | 23 +++
> >> >> >  1 file changed, 23 insertions(+)
> >> >> > 
> >> >> > diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
> >> >> > index 95a3deabea..1cb000388a 100644
> >> >> > --- a/xen/arch/x86/hvm/mtrr.c
> >> >> > +++ b/xen/arch/x86/hvm/mtrr.c
> >> >> > @@ -176,6 +176,29 @@ int hvm_vcpu_cacheattr_init(struct vcpu *v)
> >> >> >  ((uint64_t)PAT_TYPE_UC_MINUS << 48) |   /* PAT6: UC- */
> >> >> >  ((uint64_t)PAT_TYPE_UNCACHABLE << 56);  /* PAT7: UC */
> >> >> >  
> >> >> > +if ( is_hardware_domain(v->domain) )
> >> >> > +{
> >> >> > +/* Copy values from the host. */
> >> >> > +struct domain *d = v->domain;
> >> >> > +unsigned int i;
> >> >> > +
> >> >> > +if ( mtrr_state.have_fixed )
> >> >> > +for ( i = 0; i < NUM_FIXED_MSR; i++ )
> >> >> > +mtrr_fix_range_msr_set(d, m, i,
> >> >> > +  ((uint64_t 
> >> >> > *)mtrr_state.fixed_ranges)[i]);
> >> >> 
> >> >> The presence/absence of fixed range MTRRs needs to be reflected in the
> >> >> capabilities MSR. Strictly speaking in their absence MSR access 
> >> >> attempts to
> >> >> the fixed range MSRs should also cause #GP, as should any attempt to
> >> >> enable them in defType.
> >> > 
> >> > My intention was to always provide the fixed range MTRR capability,
> >> > regardless of whether the underlying hardware has it or not. Then of
> >> > course fixed ranges won't be enabled by default in the deftype MSR if
> >> > the underlying hardware also hasn't got them enabled.
> >> 
> >> What would the result be of the OS writing to any of these MSRs, or
> >> setting the respective enable bit?
> > 
> > Likely the cache attributes for the guest will change if it sets some
> > fixed ranges and enables the FE bit. But I'm not sure why is that a
> > problem.
> 
> "The guest" being Dom0 here, don't forget. I simply don't see how you
> would properly mimic the behavior without there actually being fixed
> range MTRRs. Plus it contradicts the patch description.

Please bear with me.

The reason of this patchset is to provide PVH Dom0 with a sane initial
MTRR state, not to allow a PVH Dom0 to set the host MTRR state
directly.

So the fact that the underlying hardware doesn't have support for
fixed MTRR ranges shouldn't affect Xen's capability to provide such
feature to Dom0.

I see no reason to allow Dom0 to directly control the host MTRR
values. A PVH Dom0 has it's own physical memory map and can set
whatever cache attributes it wishes without affecting the host MTRR
types.

Thanks, Roger.

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

Re: [Xen-devel] Draft NVDIMM proposal

[George Dunlap]

> On May 15, 2018, at 1:26 PM, Jan Beulich  wrote:
> 
 On 15.05.18 at 12:12,  wrote:
>>> On May 15, 2018, at 11:05 AM, Roger Pau Monne  wrote:
>>> On Fri, May 11, 2018 at 09:33:10AM -0700, Dan Williams wrote:
 [ adding linux-nvdimm ]
 
 Great write up! Some comments below...
 
 On Wed, May 9, 2018 at 10:35 AM, George Dunlap  
 wrote:
>> To use a namespace, an operating system needs at a minimum two pieces
>> of information: The UUID and/or Name of the namespace, and the SPA
>> range where that namespace is mapped; and ideally also the Type and
>> Abstraction Type to know how to interpret the data inside.
 
 Not necessarily, no. Linux supports "label-less" mode where it exposes
 the raw capacity of a region in 1:1 mapped namespace without a label.
 This is how Linux supports "legacy" NVDIMMs that do not support
 labels.
>>> 
>>> In that case, how does Linux know which area of the NVDIMM it should
>>> use to store the page structures?
>> 
>> The answer to that is right here:
>> 
>> `fsdax` and `devdax` mode are both designed to make it possible for
>> user processes to have direct mapping of NVRAM.  As such, both are
>> only suitable for PMEM namespaces (?).  Both also need to have kernel
>> page structures allocated for each page of NVRAM; this amounts to 64
>> bytes for every 4k of NVRAM.  Memory for these page structures can
>> either be allocated out of normal "system" memory, or inside the PMEM
>> namespace itself.
>> 
>> In both cases, an "info block", very similar to the BTT info block, is
>> written to the beginning of the namespace when created.  This info
>> block specifies whether the page structures come from system memory or
>> from the namespace itself.  If from the namespace itself, it contains
>> information about what parts of the namespace have been set aside for
>> Linux to use for this purpose.
>> 
>> That is, each fsdax / devdax namespace has a superblock that, in part, 
>> defines what parts are used for Linux and what parts are used for data.  Or 
>> to put it a different way: Linux decides which parts of a namespace to use 
>> for page structures, and writes it down in the metadata starting in the 
>> first 
>> page of the namespace.
> 
> And that metadata layout is agreed upon between all OS vendors?
> 
>> Linux has also defined "Type GUIDs" for these two types of namespace
>> to be stored in the namespace label, although these are not yet in the
>> ACPI spec.
 
 They never will be. One of the motivations for GUIDs is that an OS can
 define private ones without needing to go back and standardize them.
 Only GUIDs that are needed to inter-OS / pre-OS compatibility would
 need to be defined in ACPI, and there is no expectation that other
 OSes understand Linux's format for reserving page structure space.
>>> 
>>> Maybe it would be helpful to somehow mark those areas as
>>> "non-persistent" storage, so that other OSes know they can use this
>>> space for temporary data that doesn't need to survive across reboots?
>> 
>> In theory there’s no reason another OS couldn’t learn Linux’s format, 
>> discover where the blocks were, and use those blocks for its own purposes 
>> while Linux wasn’t running.
> 
> This looks to imply "no" to my question above, in which case I wonder how
> we would use (part of) the space when the "other" owner is e.g. Windows.

So in classic DOS partition tables, you have partition types; and various 
operating systems just sort of “claimed” numbers for themselves (e.g., NTFS, 
Linux Swap, ).  

But the DOS partition table number space is actually quite small.  So in 
namespaces, you have a similar concept, except that it’s called a “type GUID”, 
and it’s massively long — long enough anyone who wants to make a new type can 
simply generate one randomly and be pretty confident that nobody else is using 
that one.

So if the labels contain a TGUID you understand, you use it, just like you 
would a partition that you understand.  If it contains GUIDs you don’t 
understand, you’d better leave it alone.

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

Re: [Xen-devel] [PATCH][next] drm/xen-front: fix spelling mistake: "conector" -> "connector"

[Oleksandr Andrushchenko]

On 05/15/2018 11:54 AM, Colin King wrote:

From: Colin Ian King 

Trivial fix to spelling mistake in DRM_INFO message.

Signed-off-by: Colin Ian King 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 

Will apply to drm-misc-next

---
  drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 0e486cb1c10c..3725de4c4da8 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -623,7 +623,7 @@ static int displback_initwait(struct xen_drm_front_info 
*front_info)
if (ret < 0)
return ret;
  
-	DRM_INFO("Have %d conector(s)\n", cfg->num_connectors);

+   DRM_INFO("Have %d connector(s)\n", cfg->num_connectors);
/* Create event channels for all connectors and publish */
ret = xen_drm_front_evtchnl_create_all(front_info);
if (ret < 0)



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

[Xen-devel] [linux-4.14 test] 122727: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 test-arm64-arm64-examine  5 host-install   broken REGR. vs. 122368
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 122368
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 122368

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
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-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-amd64-amd64-xl-qemuu-win7-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-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-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-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-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:
 linuxfc72a4171174dd6b7ddefe5eeaa12cec9a162704
baseline version:
 linux64138f0adb25ca8f34baa57af33260b05efe2874

Last test of basis   122368  2018-04-23 14:20:43 Z   21 days
Failing since122533  2018-04-30 11:11:33 Z   14 days8 attempts
Testing same since   122691  2018-05-10 21:26:50 Z4 days2 attempts


1585 people 

[Xen-devel] [PATCH v4 02/10] xen/arm: Ignore write to GICD_ISACTIVERn registers (vgic-v2)

[Mirela Simonovic]

Guests attempt to write into these registers on resume (for example Linux).
Without this patch a data abort exception will be raised to the guest.
This patch handles the write access by ignoring it, but only if the value
to be written is zero. This should be fine because reading these registers
is already handled as 'read as zero'.

Signed-off-by: Mirela Simonovic 
Reviewed-by: Julien Grall 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v2:
- Write should be ignored only if the value to be written is zero
 (in v1 the write was ignored regardless of the value)

Changes in v3:
- Print warning only if the value to be written is not zero

Changes in v4:
- Added reviewed-by Julien
---
 xen/arch/arm/vgic-v2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 646d1f3d12..f6c11f1e41 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -485,6 +485,8 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 
 case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
 if ( dabt.size != DABT_WORD ) goto bad_width;
+if ( r == 0 )
+goto write_ignore_32;
 printk(XENLOG_G_ERR
"%pv: vGICD: unhandled word write %#"PRIregister" to 
ISACTIVER%d\n",
v, r, gicd_reg - GICD_ISACTIVER);
-- 
2.13.0


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

[Xen-devel] [PATCH v4 00/10] xen/arm64: Suspend preconditions and CPU hotplug fixes

[Mirela Simonovic]

This patch set contains fixes that are required as precondition for suspend to
RAM support, including the CPU hotplug which is required to suspend non-boot
CPUs.
The first two patches in this series:
1) xen/arm64: Added handling of the trapped access to OSLSR register
2) xen/arm: Ignore write to GICD_ISACTIVERn registers (vgic-v2)
are required to avoid Dom0 crashes when Dom0 performs its own suspend. This
patch set does not include the implementation of virtual PSCI system suspend
call that would allow guests to finalize their suspend procedures. This will
be submitted in the following series.

Remaining of the patches are related to enabling CPU hotplug for non-boot
CPUs is resume scenario. CPU hotplug of non-boot CPUs will be used for suspend
to RAM support for ARM. In suspend procedure, the hot-unplug of non-boot CPUs
will be triggered with disable_nonboot_cpus(), while the hotplug is triggered
with enable_nonboot_cpus(). Using these calls, the physical non-boot CPUs could
be powered down/up on suspend/resume, respectively, if the underlying firmware
allows so. Calls to enable/disable_nonboot_cpus() functions currently do not
exist in Xen ARM code. This will be added with the suspend to RAM support for
ARM.

When non-boot pCPUs are hot-unplugged their interrupts are migrated to the boot
pCPU. This series also includes a fix that would restore the interrupts affinity
once non-boot pCPUs are hotplugged. Here only SPIs used by guests are covered.
Migration of Xen internal SPIs is not covered. According to my understanding
Xen internal SPIs are routed to the boot CPU which initializes the respective
devices. Therefore, there is no need to migrate Xen internal SPIs.

The code is tested on Xilinx Zynq UltraScale+ MPSoC/ZCU102 board (includes
physical power down/up of non-boot CPUs). The testing requires additional
patches for issuing system suspend. These patches and instructions for testing
will be submitted later, when we get closer to the final version of the series.

---
Changes in v2:
-Rename cover-letter title and emphasize that 2 patches from this series are not
specific to CPU hotplug (my initial fault, splitting it now could be confusing)
-Fix cover-letter explanations
-Address all the issues and comments as discussed on mailing list for v1
-Add 3 patches to ensure that suspend/resume does not cause any memory leaks.
All the memory allocated when a CPU was hotplugged is now freed when the CPU is
hot-unplugged.
-Remove from the v1 series the patch which incorrectly dealt with an issue:
[PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly
One solution to the issue addressed by the patch above is to add rcu_barrier()
prior to calling enable_nonboot_cpus() during the suspend. This is how it is
done in x86 suspend implementation. Until the discussion here
https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg01199.html
doesn't conclude differently, I need to assume that adding rcu_barrier() prior
to calling enable_nonboot_cpus() as it is done for x86 is the right way to go.
Therefore, the fix to the issue will be part of the suspend to RAM series.

Changes in v3:
-Add acked-by where needed
-Fix CPU_OFF PSCI implementation (physical interface)
-Use notifiers to implement freeing memory and releasing interrupts on CPU
hotplug
-Use notifier to trigger setup of virtual paging for non-boot CPUs on CPU
hotplug
-Add enabling errata workarounds on CPU hotplug, also based on a notifier
-Remove patch:
[PATCH v2 10/10] xen/arm: Call check_local_cpu_errata for secondary CPU only on 
boot

Changes in v4:
-Add acked-by/reviewed-by where needed
-Cleanup: use smp_processor_id() instead of get_processor_id(), fixed
 indentation, add includes alphabetically, add newline before return, etc.
-Disable timers prior to releasing timer interrupts
-Initialize cpu_smpboot notifier at presmp_init rather than init phase
-In the last patch of the series errata notifier now returns an error

---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: George Dunlap 
CC: Dario Faggioli 
---

Mirela Simonovic (10):
  xen/arm64: Added handling of the trapped access to OSLSR register
  xen/arm: Ignore write to GICD_ISACTIVERn registers (vgic-v2)
  xen/arm: Implement CPU_OFF PSCI call (physical interface)
  xen/arm: Remove __initdata and __init to enable CPU hotplug
  xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume
  xen/common: Restore IRQ affinity when hotplugging a pCPU
  xen/arm: Release maintenance interrupt when CPU is hot-unplugged
  xen/arm: Disable timers and release their interrupts on CPU hot-unplug
  xen/arm: Free memory allocated for sibling/core maps on CPU hot-unplug
  xen/arm: Enable errata for secondary CPU on hotplug after the boot

 xen/arch/arm/arm64/smpboot.c |  2 +-
 xen/arch/arm/arm64/vsysreg.c |  3 ++-
 xen/arch/arm/cpuerrata.c | 49 +
 

[Xen-devel] [PATCH v4 09/10] xen/arm: Free memory allocated for sibling/core maps on CPU hot-unplug

[Mirela Simonovic]

The memory allocated in setup_cpu_sibling_map() when a CPU is hotplugged
has to be freed when the CPU is hot-unplugged. This is done in
remove_cpu_sibling_map() and called when the CPU dies. The call to
remove_cpu_sibling_map() is made from a notifier callback when
CPU_DEAD event is received.

Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v3:
-Use notifier to trigger remove_cpu_sibling_map() when the CPU dies.

Changes in v4:
-Initialize cpu_smpboot notifier at presmp_init rather than init phase
 to cover the case where a secondary CPU dies beforehand the initcall
-Added newline before the return in cpu_smpboot_notifier_init()
-Fix indentation in cpu_smpboot_callback() definition
---
 xen/arch/arm/smpboot.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index ad1f6b751b..cf3a4ce659 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -89,6 +89,12 @@ static void setup_cpu_sibling_map(int cpu)
 cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
 }
 
+static void remove_cpu_sibling_map(int cpu)
+{
+free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
+free_cpumask_var(per_cpu(cpu_core_mask, cpu));
+}
+
 void __init
 smp_clear_cpu_maps (void)
 {
@@ -499,6 +505,36 @@ void __cpu_die(unsigned int cpu)
 smp_mb();
 }
 
+static int cpu_smpboot_callback(struct notifier_block *nfb,
+unsigned long action,
+void *hcpu)
+{
+unsigned int cpu = (unsigned long)hcpu;
+
+switch ( action )
+{
+case CPU_DEAD:
+remove_cpu_sibling_map(cpu);
+break;
+default:
+break;
+}
+
+return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_smpboot_nfb = {
+.notifier_call = cpu_smpboot_callback,
+};
+
+static int __init cpu_smpboot_notifier_init(void)
+{
+register_cpu_notifier(_smpboot_nfb);
+
+return 0;
+}
+presmp_initcall(cpu_smpboot_notifier_init);
+
 /*
  * Local variables:
  * mode: C
-- 
2.13.0


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

[Xen-devel] [PATCH v4 03/10] xen/arm: Implement CPU_OFF PSCI call (physical interface)

[Mirela Simonovic]

During the system suspend to RAM non-boot CPUs will be hotplugged.
This will be triggered via disable_nonboot_cpus() call. When
hotplugged the CPU will end up in an infinite wfi loop in stop_cpu().
This patch adds PSCI CPU_OFF call to the EL3 with the aim to get powered
down the calling CPU during the suspend. The CPU_OFF call will be made
only if the PSCI version is higher than v0.1 (Note that the CPU_OFF
function is mandatory since PSCI v0.2).
If PSCI CPU_OFF call to the EL3 succeeds it will not return. Otherwise,
when the PSCI CPU_OFF call returns we'll raise panic, because the
calling CPU couldn't be enabled afterwards (stays in WFI loop forever).
Note that if the PSCI version is higher than v0.1 the CPU_OFF will be
called regardless of the system state. This is done because scenarios
other than suspend may benefit from powering off the CPU.

Signed-off-by: Mirela Simonovic 
Acked-by: Julien Grall 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v2:
-Issue PSCI CPU_OFF only if the system is suspending
-If PSCI CPU_OFF call fails (unlikely to ever happen) raise panic
-Fixed commit message

Changes in v3:
-Check for PSCI version prior to calling CPU_OFF
-Don't check for system state - invoke CPU_OFF in all system states
-Don't check if returned error is not zero because it's always not
 zero if CPU_OFF SMC returns
-Fixed commit message

Changes in v4:
-Use smp_processor_id() instead of get_processor_id()
-Fixed indentation
-Added acked-by Julien
---
 xen/arch/arm/psci.c| 13 +
 xen/arch/arm/smpboot.c |  2 ++
 xen/include/asm-arm/psci.h |  1 +
 3 files changed, 16 insertions(+)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 94b616df9b..3cf5ecf0f3 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -46,6 +46,19 @@ int call_psci_cpu_on(int cpu)
 return call_smc(psci_cpu_on_nr, cpu_logical_map(cpu), 
__pa(init_secondary), 0);
 }
 
+void call_psci_cpu_off(void)
+{
+if ( psci_ver > PSCI_VERSION(0, 1) )
+{
+int errno;
+
+/* If successfull the PSCI cpu_off call doesn't return */
+errno = call_smc(PSCI_0_2_FN32_CPU_OFF, 0, 0, 0);
+panic("PSCI cpu off failed for CPU%d err=%d\n", smp_processor_id(),
+  errno);
+}
+}
+
 void call_psci_system_off(void)
 {
 if ( psci_ver > PSCI_VERSION(0, 1) )
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index b2116f0d2d..8b1e274bf3 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -395,6 +395,8 @@ void stop_cpu(void)
 /* Make sure the write happens before we sleep forever */
 dsb(sy);
 isb();
+call_psci_cpu_off();
+
 while ( 1 )
 wfi();
 }
diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
index 9ac820e94a..832f77afff 100644
--- a/xen/include/asm-arm/psci.h
+++ b/xen/include/asm-arm/psci.h
@@ -20,6 +20,7 @@ extern uint32_t psci_ver;
 
 int psci_init(void);
 int call_psci_cpu_on(int cpu);
+void call_psci_cpu_off(void);
 void call_psci_system_off(void);
 void call_psci_system_reset(void);
 
-- 
2.13.0


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

[Xen-devel] [PATCH v4 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged

[Mirela Simonovic]

When a CPU is hot-unplugged the maintenance interrupt has to be
released in order to free the memory that was allocated when the CPU
was hotplugged and interrupt requested. The interrupt was requested
using request_irq() which is called from start_secondary->
init_maintenance_interrupt. With this patch the interrupt will be
released when the CPU_DYING event is received by the callback which
is added in gic.c.

Signed-off-by: Mirela Simonovic 
Acked-by: Julien Grall 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v3:
-Add notifier in order to trigger releasing of the  maintenance
 interrupt when the CPU is dying.

Changes in v4:
-Add includes alphabetically
-Added newline before the return in cpu_gic_notifier_init()
-Fix indentation in cpu_gic_callback() definition
-Added acked-by Julien
---
 xen/arch/arm/gic.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 653a815127..5474030386 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -462,6 +464,35 @@ int gic_iomem_deny_access(const struct domain *d)
 return gic_hw_ops->iomem_deny_access(d);
 }
 
+static int cpu_gic_callback(struct notifier_block *nfb,
+unsigned long action,
+void *hcpu)
+{
+switch ( action )
+{
+case CPU_DYING:
+/* This is reverting the work done in init_maintenance_interrupt */
+release_irq(gic_hw_ops->info->maintenance_irq, NULL);
+break;
+default:
+break;
+}
+
+return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_gic_nfb = {
+.notifier_call = cpu_gic_callback,
+};
+
+static int __init cpu_gic_notifier_init(void)
+{
+register_cpu_notifier(_gic_nfb);
+
+return 0;
+}
+__initcall(cpu_gic_notifier_init);
+
 /*
  * Local variables:
  * mode: C
-- 
2.13.0


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

[Xen-devel] [distros-debian-snapshot test] 74718: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-daily-netboot-pvgrub 11 guest-start fail blocked in 74691
 test-amd64-amd64-amd64-daily-netboot-pvgrub 11 guest-start fail blocked in 
74691
 test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail like 74691
 test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
74691
 test-amd64-i386-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
74691
 test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail like 
74691
 test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like 
74691
 test-armhf-armhf-armhf-daily-netboot-pygrub 10 debian-di-install fail like 
74691
 test-amd64-i386-i386-current-netinst-pygrub 10 debian-di-install fail like 
74691
 test-amd64-amd64-i386-current-netinst-pygrub 10 debian-di-install fail like 
74691
 test-amd64-i386-amd64-current-netinst-pygrub 10 debian-di-install fail like 
74691

baseline version:
 flight   74691

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   pass
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   pass
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v1 for 4.7] x86/cpuid: fix raw FEATURESET_7d0 reporting

[Jan Beulich]

>>> On 15.05.18 at 10:37,  wrote:
> Commit 62b1879693e0 ("x86: further CPUID handling adjustments") added
> FEATURESET_7d0 reporting but forgot to update calculate_raw_featureset()
> function. As result, the value reported by xen-cpuid contains 0.
> 
> Fix that by properly filling raw_featureset[FEATURESET_7d0].
> 
> Signed-off-by: Sergey Dyasli 

Thanks, technically
Acked-by: Jan Beulich 

> ---
> I see that at least 4.8 also contains this bug, so other releases also
> need checking.

The commit in question being only on the two branches, I think no other one
would need the change.

I'm certainly going to apply this to 4.8; I'm uncertain about 4.7 though, if 
it's
really only xen-cpuid output which is now wrong. I wasn't really planning on
putting there any further non-security changes (severe regression fixes for
earlier security patches perhaps being the only possible exception). Otoh
osstest continues to be unhappy with the branch (albeit that's mostly
environmental issues iirc, i.e. "broken" rather than "failed" tests), so us
being able to push out 4.7.6 continues to be delayed.

Jan



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

Re: [Xen-devel] [PATCH 3/5] hvm/mtrr: copy hardware state for Dom0

[Jan Beulich]

>>> On 15.05.18 at 11:16,  wrote:
> On Tue, May 15, 2018 at 02:48:16AM -0600, Jan Beulich wrote:
>> >>> On 15.05.18 at 10:35,  wrote:
>> > On Tue, May 15, 2018 at 01:52:43AM -0600, Jan Beulich wrote:
>> >> >>> On 14.05.18 at 18:33,  wrote:
>> >> > On Mon, May 14, 2018 at 08:26:30AM -0600, Jan Beulich wrote:
>> >> >> >>> On 10.05.18 at 19:15,  wrote:
>> >> >> > Copy the state found on the hardware when creating a PVH Dom0. Since
>> >> >> > the memory map provided to a PVH Dom0 is based on the native one 
>> >> >> > using
>> >> >> > the same set of MTRR ranges should provide Dom0 with a sane MTRR 
>> >> >> > state
>> >> >> > without having to manually build it in Xen.
>> >> >> > 
>> >> >> > Signed-off-by: Roger Pau Monné 
>> >> >> > ---
>> >> >> > Cc: Jan Beulich 
>> >> >> > Cc: Andrew Cooper 
>> >> >> > ---
>> >> >> >  xen/arch/x86/hvm/mtrr.c | 23 +++
>> >> >> >  1 file changed, 23 insertions(+)
>> >> >> > 
>> >> >> > diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
>> >> >> > index 95a3deabea..1cb000388a 100644
>> >> >> > --- a/xen/arch/x86/hvm/mtrr.c
>> >> >> > +++ b/xen/arch/x86/hvm/mtrr.c
>> >> >> > @@ -176,6 +176,29 @@ int hvm_vcpu_cacheattr_init(struct vcpu *v)
>> >> >> >  ((uint64_t)PAT_TYPE_UC_MINUS << 48) |   /* PAT6: UC- */
>> >> >> >  ((uint64_t)PAT_TYPE_UNCACHABLE << 56);  /* PAT7: UC */
>> >> >> >  
>> >> >> > +if ( is_hardware_domain(v->domain) )
>> >> >> > +{
>> >> >> > +/* Copy values from the host. */
>> >> >> > +struct domain *d = v->domain;
>> >> >> > +unsigned int i;
>> >> >> > +
>> >> >> > +if ( mtrr_state.have_fixed )
>> >> >> > +for ( i = 0; i < NUM_FIXED_MSR; i++ )
>> >> >> > +mtrr_fix_range_msr_set(d, m, i,
>> >> >> > +  ((uint64_t 
>> >> >> > *)mtrr_state.fixed_ranges)[i]);
>> >> >> 
>> >> >> The presence/absence of fixed range MTRRs needs to be reflected in the
>> >> >> capabilities MSR. Strictly speaking in their absence MSR access 
>> >> >> attempts to
>> >> >> the fixed range MSRs should also cause #GP, as should any attempt to
>> >> >> enable them in defType.
>> >> > 
>> >> > My intention was to always provide the fixed range MTRR capability,
>> >> > regardless of whether the underlying hardware has it or not. Then of
>> >> > course fixed ranges won't be enabled by default in the deftype MSR if
>> >> > the underlying hardware also hasn't got them enabled.
>> >> 
>> >> What would the result be of the OS writing to any of these MSRs, or
>> >> setting the respective enable bit?
>> > 
>> > Likely the cache attributes for the guest will change if it sets some
>> > fixed ranges and enables the FE bit. But I'm not sure why is that a
>> > problem.
>> 
>> "The guest" being Dom0 here, don't forget. I simply don't see how you
>> would properly mimic the behavior without there actually being fixed
>> range MTRRs. Plus it contradicts the patch description.
> 
> Please bear with me.
> 
> The reason of this patchset is to provide PVH Dom0 with a sane initial
> MTRR state, not to allow a PVH Dom0 to set the host MTRR state
> directly.
> 
> So the fact that the underlying hardware doesn't have support for
> fixed MTRR ranges shouldn't affect Xen's capability to provide such
> feature to Dom0.
> 
> I see no reason to allow Dom0 to directly control the host MTRR
> values. A PVH Dom0 has it's own physical memory map and can set
> whatever cache attributes it wishes without affecting the host MTRR
> types.

Oh, right, I've been confused by the mix of copying of host state and
and leaving untouched of virtual capabilities. I'm sorry for the noise.

Jan


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

Re: [Xen-devel] [PATCH 4/5] libxc/pvh: set default MTRR type to write-back

[Jan Beulich]

>>> On 15.05.18 at 13:43,  wrote:
> On Thu, May 10, 2018 at 06:15:04PM +0100, Roger Pau Monne wrote:
>> @@ -1014,6 +1034,30 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>>  if ( dom->start_info_seg.pfn )
>>  bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;
>>  
>> +/* Set the MTRR. */
>> +bsp_ctx.mtrr_d.typecode = HVM_SAVE_CODE(MTRR);
>> +bsp_ctx.mtrr_d.instance = 0;
>> +bsp_ctx.mtrr_d.length = HVM_SAVE_LENGTH(MTRR);
>> +
>> +mtrr_record = hvm_get_save_record(full_ctx, HVM_SAVE_CODE(MTRR), 0);
>> +if ( !mtrr_record )
>> +{
>> +xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
>> + "%s: unable to get MTRR save record", __func__);
>> +goto out;
>> +}
>> +
>> +memcpy(_ctx.mtrr, mtrr_record, sizeof(bsp_ctx.mtrr));
>> +
>> +/* TODO: maybe this should be a firmware option instead? */
>> +if ( !dom->device_model )
>> +/*
>> + * Enable MTRR, set default type to WB.
>> + * TODO: add MMIO areas as UC when passthrough is supported.
>> + */
>> +bsp_ctx.mtrr.msr_mtrr_def_type = MTRR_TYPE_WRBACK |
>> + MTRR_DEF_TYPE_ENABLE;
>> +
> 
> Hrm... I'm not entirely happy with this in toolstack code but there
> doesn't seem to be a better way to do this at the moment, considering
> hypervisor doesn't distinguish HVM and PVH guests.
> 
> Anyway, the code looks correct to me. I would rather see something in
> hypervisor to deal with this, but I won't object to this either.

But doing it in the hypervisor would be a layering violation imo: The
hypervisor should set MTRR state to power-on / reset defaults, which
it does. It's firmware which is supposed to adapt their values to actual
system characteristics (RAM and MMIO ranges), and libxc has to play
the role of firmware here short of there being any in the guest itself.

Jan



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

Re: [Xen-devel] [PATCH 4/5] libxc/pvh: set default MTRR type to write-back

[Wei Liu]

On Thu, May 10, 2018 at 06:15:04PM +0100, Roger Pau Monne wrote:
> And enable MTRR. This allows to provide a sane initial MTRR state for
> PVH DomUs. This will have to be expanded when pci-passthrough support
> is added to PVH guests, so that MMIO regions of devices are set as
> UC.
> 
> Note that initial MTRR setup is done by hvmloader for HVM guests,
> that's not used by PVH guests.
> 
> Signed-off-by: Roger Pau Monné 
> 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  tools/libxc/xc_dom_x86.c | 44 
>  1 file changed, 44 insertions(+)
> 
> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
> index e33a28847d..d28ff4d7e9 100644
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -53,6 +53,9 @@
>  #define X86_CR0_PE 0x01
>  #define X86_CR0_ET 0x10
>  
> +#define MTRR_TYPE_WRBACK 6
> +#define MTRR_DEF_TYPE_ENABLE (1u << 11)
> +
>  #define SPECIALPAGE_PAGING   0
>  #define SPECIALPAGE_ACCESS   1
>  #define SPECIALPAGE_SHARING  2
> @@ -931,6 +934,20 @@ static int vcpu_x86_64(struct xc_dom_image *dom)
>  return rc;
>  }
>  
> +const static void *hvm_get_save_record(const void *ctx, unsigned int type,
> +   unsigned int instance)
> +{
> +const struct hvm_save_descriptor *header;
> +
> +for ( header = ctx;
> +  header->typecode != HVM_SAVE_CODE(END);
> +  ctx += sizeof(*header) + header->length, header = ctx )
> +if ( header->typecode == type && header->instance == instance )
> +return ctx + sizeof(*header);
> +
> +return NULL;
> +}
> +
>  static int vcpu_hvm(struct xc_dom_image *dom)
>  {
>  struct {
> @@ -938,9 +955,12 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>  HVM_SAVE_TYPE(HEADER) header;
>  struct hvm_save_descriptor cpu_d;
>  HVM_SAVE_TYPE(CPU) cpu;
> +struct hvm_save_descriptor mtrr_d;
> +HVM_SAVE_TYPE(MTRR) mtrr;
>  struct hvm_save_descriptor end_d;
>  HVM_SAVE_TYPE(END) end;
>  } bsp_ctx;
> +const HVM_SAVE_TYPE(MTRR) *mtrr_record;
>  uint8_t *full_ctx = NULL;
>  int rc;
>  
> @@ -1014,6 +1034,30 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>  if ( dom->start_info_seg.pfn )
>  bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;
>  
> +/* Set the MTRR. */
> +bsp_ctx.mtrr_d.typecode = HVM_SAVE_CODE(MTRR);
> +bsp_ctx.mtrr_d.instance = 0;
> +bsp_ctx.mtrr_d.length = HVM_SAVE_LENGTH(MTRR);
> +
> +mtrr_record = hvm_get_save_record(full_ctx, HVM_SAVE_CODE(MTRR), 0);
> +if ( !mtrr_record )
> +{
> +xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
> + "%s: unable to get MTRR save record", __func__);
> +goto out;
> +}
> +
> +memcpy(_ctx.mtrr, mtrr_record, sizeof(bsp_ctx.mtrr));
> +
> +/* TODO: maybe this should be a firmware option instead? */
> +if ( !dom->device_model )
> +/*
> + * Enable MTRR, set default type to WB.
> + * TODO: add MMIO areas as UC when passthrough is supported.
> + */
> +bsp_ctx.mtrr.msr_mtrr_def_type = MTRR_TYPE_WRBACK |
> + MTRR_DEF_TYPE_ENABLE;
> +

Hrm... I'm not entirely happy with this in toolstack code but there
doesn't seem to be a better way to do this at the moment, considering
hypervisor doesn't distinguish HVM and PVH guests.

Anyway, the code looks correct to me. I would rather see something in
hypervisor to deal with this, but I won't object to this either.

Wei.

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

Re: [Xen-devel] 4.11.0 RC1 panic

[Jan Beulich]

>>> On 01.05.18 at 22:22,  wrote:
> On Mon, Apr 30, 2018 at 07:31:28AM -0600, Jan Beulich wrote:
>> >>> On 25.04.18 at 16:42,  wrote:
>> > On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
>> >> > Without line numbers associated with at least the top stack trace entry
>> >> > I can only guess what it might be - could you give the patch below a 
>> >> > try?
>> >> > (This may not be the final patch, as I'm afraid there may be some race
>> >> > here, but I'd have to work this out later.)
>> >> 
>> >> Yes, this works. thanks !
>> >> I'll now put this version on the NetBSD testbed I'm running.
>> >> This should put some pressure on it.
>> > 
>> > Running NetBSD tests in several guests I got:
>> > (XEN) 
>> > (XEN) 
>> > (XEN) Panic on CPU 1:
>> > (XEN) Assertion 'oc > 0' failed at mm.c:628
>> > (XEN) 
>> > (see attached file for complete report).
>> 
>> So in combination with your later reply I'm confused: Are you observing
>> this with 64-bit guests as well (your later reply appears to hint towards
>> 64-bit-ness), or (as the stack trace suggests) only 32-bit ones? Knowing
>> this may already narrow areas where to look.
> 
> I've seen it a server where, I think, only 32bits domUs are running.
> But the dom0 is a 64bits NetBSD anyway.

Right; Dom0 bitness is of no interest. I've been going through numerous
possibly racing combinations of code paths, without being able to spot
anything yet. I'm afraid I'm not in the position to try to set up the full
environment you're observing the problem in. It would therefore really
help if you could
- debug this yourself, or
- reduce the test environment (ideally to a simple [XTF?] test), or
- at least narrow the conditions, or
- at the very least summarize the relevant actions NetBSD takes in
  terms of page table management, to hopefully reduce the sets of
  code paths potentially involved (for example, across a larger set of
  crashes knowing whether UNPIN is always involved would be
  helpful; I've been blindly assuming it would be short of having
  further data)
(besides a more reliable confirmation - or otherwise - that this indeed
is an issue with 32-bit guests only).

While I think I have ruled out the TLB flush time stamp setting still
happening too early / wrongly in certain cases, there's a small
debugging patch that I would hope could help prove this one or the
other way (see below).

Btw: You've said earlier that there wouldn't be a domain number in
the panic message. However,

(XEN) RFLAGS: 00010246   CONTEXT: hypervisor (d14v3)

has it (at the end: domain 14, vCPU 3). Just in case this helps
identifying further useful pieces of information.

Jan

--- unstable.orig/xen/arch/x86/mm.c
+++ unstable/xen/arch/x86/mm.c
@@ -578,7 +578,11 @@ static inline void set_tlbflush_timestam
  */
 if ( !(page->count_info & PGC_page_table) ||
  !shadow_mode_enabled(page_get_owner(page)) )
+{
+/* NB: This depends on WRAP_MASK in flushtlb.c to be <= 0x. */
+ASSERT(!page->linear_pt_count);
 page_set_tlbflush_timestamp(page);
+}
 }
 
 const char __section(".bss.page_aligned.const") __aligned(PAGE_SIZE)



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

Re: [Xen-devel] Draft NVDIMM proposal

[Jan Beulich]

>>> On 15.05.18 at 12:12,  wrote:
>> On May 15, 2018, at 11:05 AM, Roger Pau Monne  wrote:
>> On Fri, May 11, 2018 at 09:33:10AM -0700, Dan Williams wrote:
>>> [ adding linux-nvdimm ]
>>> 
>>> Great write up! Some comments below...
>>> 
>>> On Wed, May 9, 2018 at 10:35 AM, George Dunlap  
>>> wrote:
> To use a namespace, an operating system needs at a minimum two pieces
> of information: The UUID and/or Name of the namespace, and the SPA
> range where that namespace is mapped; and ideally also the Type and
> Abstraction Type to know how to interpret the data inside.
>>> 
>>> Not necessarily, no. Linux supports "label-less" mode where it exposes
>>> the raw capacity of a region in 1:1 mapped namespace without a label.
>>> This is how Linux supports "legacy" NVDIMMs that do not support
>>> labels.
>> 
>> In that case, how does Linux know which area of the NVDIMM it should
>> use to store the page structures?
> 
> The answer to that is right here:
> 
> `fsdax` and `devdax` mode are both designed to make it possible for
> user processes to have direct mapping of NVRAM.  As such, both are
> only suitable for PMEM namespaces (?).  Both also need to have kernel
> page structures allocated for each page of NVRAM; this amounts to 64
> bytes for every 4k of NVRAM.  Memory for these page structures can
> either be allocated out of normal "system" memory, or inside the PMEM
> namespace itself.
> 
> In both cases, an "info block", very similar to the BTT info block, is
> written to the beginning of the namespace when created.  This info
> block specifies whether the page structures come from system memory or
> from the namespace itself.  If from the namespace itself, it contains
> information about what parts of the namespace have been set aside for
> Linux to use for this purpose.
> 
> That is, each fsdax / devdax namespace has a superblock that, in part, 
> defines what parts are used for Linux and what parts are used for data.  Or 
> to put it a different way: Linux decides which parts of a namespace to use 
> for page structures, and writes it down in the metadata starting in the first 
> page of the namespace.

And that metadata layout is agreed upon between all OS vendors?

> Linux has also defined "Type GUIDs" for these two types of namespace
> to be stored in the namespace label, although these are not yet in the
> ACPI spec.
>>> 
>>> They never will be. One of the motivations for GUIDs is that an OS can
>>> define private ones without needing to go back and standardize them.
>>> Only GUIDs that are needed to inter-OS / pre-OS compatibility would
>>> need to be defined in ACPI, and there is no expectation that other
>>> OSes understand Linux's format for reserving page structure space.
>> 
>> Maybe it would be helpful to somehow mark those areas as
>> "non-persistent" storage, so that other OSes know they can use this
>> space for temporary data that doesn't need to survive across reboots?
> 
> In theory there’s no reason another OS couldn’t learn Linux’s format, 
> discover where the blocks were, and use those blocks for its own purposes 
> while Linux wasn’t running.

This looks to imply "no" to my question above, in which case I wonder how
we would use (part of) the space when the "other" owner is e.g. Windows.

Jan


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

Re: [Xen-devel] [PATCH v2 3/3] xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages

[Anthony PERARD]

On Tue, May 15, 2018 at 04:45:25PM +0100, Paul Durrant wrote:
> > > diff --git a/include/hw/xen/xen_common.h
> > b/include/hw/xen/xen_common.h
> > > index 5f1402b494..d925751040 100644
> > > --- a/include/hw/xen/xen_common.h
> > > +++ b/include/hw/xen/xen_common.h
> > > @@ -119,6 +119,20 @@ static inline int
> > xendevicemodel_pin_memory_cacheattr(
> > >  return xc_domain_pin_memory_cacheattr(xen_xc, domid, start, end,
> > type);
> > >  }
> > >
> > > +typedef void xenforeignmemory_resource_handle;
> > > +
> > > +#define XENMEM_resource_ioreq_server_frame_bufioreq 0
> > > +#define XENMEM_resource_ioreq_server_frame_ioreq(n) (1 + (n))
> > > +
> > > +static inline xenforeignmemory_resource_handle
> > *xenforeignmemory_map_resource(
> > > +xenforeignmemory_handle *fmem, domid_t domid, unsigned int type,
> > > +unsigned int id, unsigned long frame, unsigned long nr_frames,
> > > +void **paddr, int prot, int flags)
> > > +{
> > > +errno = EOPNOTSUPP;
> > 
> > I think ENOSYS would be better. EOPNOTSUPP seems to be for sockets.
> > 
> 
> No, EOPNOTSUPP is more general than that and is convention for unimplemented 
> API operations elsewhere. ENOSYS is supposed to strictly mean 'system call 
> not implemented' but we use it for hypercalls in Xen, leading to occasional 
> fun with Linux checkpatch.pl.

In man errno, I have:
ENOTSUP Operation not supported (POSIX.1-2001)
EOPNOTSUPP  Operation not supported on socket (POSIX.1-2001).
ENOSYS  Function not implemented (POSIX.1-2001).

But I guess any of these would work.

-- 
Anthony PERARD

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

[Xen-devel] [PATCH] scripts/add_maintainers.pl: New script

[Ian Jackson]

From: Lars Kurth 

This provides a much better workflow when using git format-patch and
git send-email, with get_maintainer.pl.

The tool covers step 2 of the following workflow

  Step 1: git format-patch ... -o  ...
  Step 2: ./scripts/add_maintainers.pl -d 
  This overwrites  *.patch files in 
  Step 3: git send-email -to xen-devel@lists.xenproject.org /*.patchxm

I manually tested all options and the most common combinations
on Mac.

Changes since v1:
- Added RAB (indicated by Juergen on IRC that this is OK)
- Remove trailing whitespaces
- Renamed --prefix to --reroll-count
- Cleaned up short options -v, ... to be in line with git
- Added --tags|-t option to add AB, RAB and RB emails to CC list
- Added --insert|-i mode to allow for people adding CCs to commit message
  instead of the e-mail header (the header is the default)
- Moved common code into functions
- Added logic, such that the tool only insert's To: and Cc: statements
  which were not there before, allowing for running the tool multiple times
  on the same 

Changes since v2:
- Deleted --version and related infrastructure
- Added subroutine prototypes
- Removed AT and @lists declaration and used \@ in literals
- Changed usage message and options based on feedback
- Improved error handling
- Removed occurances of index() and replaced with regex
- Removed non-perl idioms
- Moved uniq statements to normalize and added info on what normalize does
- Read L: tags from MAINTAINERS file instead of using heuristic
- Fixed issues related to metacharacters in getmaintainers()
- Allow multiple -a | --arg values (because of this renamed --args)
- Identify tags via regex
- CC's from tags are only inserted in the mail header, never the body
- That is unless the new option --tagscc is used
- Added policy processing which includes reworking insert()
- Replaced -i|--insert with -p|--inspatch and -c|--inscover now using policies
- Added new policies to cover for all user requests
- Rewrote help message to center around usage of policies
- Reordered some code (e.g. help string first to make code more easily readable)

Changes since v3:
- Made help message clearer
- Replaced PROCESSING POLICY with LOCATION
- Renamed --inspatch (top|ccbody|cc---|none) | -p (top|ccbody|cc---|none)
  to --patchcc (header|commit|comment|none) | -p (header|commit|comment|none)
- Renamed --inscover (top|ccend|none) | -c (top|ccend|none)
  to --covercc (header|end|none) | -c (header|end|none)
- Renamed variables and functions in the code to match the options
- Changed $patch_prefix processing
- Changed search expression for identifying cover letters
- Renamed $readmailinglists to $getmailinglists_done
- Use array form of open
- More file error handling (using IO::Handle)
- Fixed buggy AND in if statement
- Removed check whether getmaintainers exists for future proofing
- Add logic to work out --reroll-count

Changes since v4:
- Strip some trailing whitespace from the code
- writefile() now uses the .tmp-and-rename pattern to avoid data loss
- Provide --get-maintainers= option to specify replacement for
  get_maintainers.pl.  This is useful for Ian's usecase, since it
  allows --get-maintainers=true, to avoid adding any MAINTAINERS-based
  info anywhere while still adding other CCs (eg from -t) everywhere.
- Refactor normalize() somewhat so that it uses only %seen, and
  does not any longer modify its argument arrays.
- De-dupe case-insensitively (by making normalize use lc).

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 
Signed-off-by: Lars Kurth 
Release-acked-by: Juergen Gross 
Signed-off-by: Ian Jackson 
---
 scripts/add_maintainers.pl | 548 +
 1 file changed, 548 insertions(+)
 create mode 100755 scripts/add_maintainers.pl

diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
new file mode 100755
index 000..0f4a4cf
--- /dev/null
+++ b/scripts/add_maintainers.pl
@@ -0,0 +1,548 @@
+#!/usr/bin/perl -w
+# (c) 2018, Lars Kurth 
+#
+# Add maintainers to patches generated with git format-patch
+#
+# Usage: perl scripts/add_maintainers.pl [OPTIONS] -patchdir 
+#
+# Prerequisites: Execute
+#git format-patch ... -o  ...
+#
+#./scripts/get_maintainer.pl is present in the tree
+#
+# Licensed under the terms of the GNU GPL License version 2
+
+use strict;
+
+use Getopt::Long qw(:config no_auto_abbrev);
+use File::Basename;
+use List::MoreUtils qw(uniq);
+use IO::Handle;
+
+sub getmaintainers ($$$);
+sub gettagsfrompatch ($$$;$);
+sub normalize ($$);
+sub 

Re: [Xen-devel] Draft NVDIMM proposal

[Dan Williams]

On Tue, May 15, 2018 at 5:26 AM, Jan Beulich  wrote:
 On 15.05.18 at 12:12,  wrote:
[..]
>> That is, each fsdax / devdax namespace has a superblock that, in part,
>> defines what parts are used for Linux and what parts are used for data.  Or
>> to put it a different way: Linux decides which parts of a namespace to use
>> for page structures, and writes it down in the metadata starting in the first
>> page of the namespace.
>
> And that metadata layout is agreed upon between all OS vendors?

The only agreed upon metadata layouts across all OS vendors are the
ones that are specified in UEFI. We typically only need inter-OS and
UEFI compatibility for booting and other pre-OS accesses. For Linux
"raw" and "sector" mode namespaces defined by namespace labels are
inter-OS compatible while "fsdax", "devdax", and so called
"label-less" configurations are not.

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

[Xen-devel] [PATCH RFC] Supporting more than 4 emulated NICs

[Charles Arnold]

Some time ago this bug was written up,

https://bugs.xenproject.org/xen/bug/46
"qemu-upstream: limitation on 4 emulated NICs prevents guest from starting
unless PV override is used."

While there were some proposed patches and discussion in the bug and on the
mailing list back in 2014/2015 to address this issue it hasn't seen much
movement since then.

The last proposed patch in the bug by Stefano Stabellini is below with some
small adjustments I've made.

What is the status of this patch? Does it break migration?


libxl: account for romfile memory

Account for memory needed for emulated network card rom files.
Assume 256K for each romfile.

Reviewed-by: Charles Arnold 
Signed-off-by: Stefano Stabellini 

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index f0fd5fd..56a0575 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -471,7 +471,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 return ERROR_FAIL;
 }
 
-if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + size) < 0) {
+if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + size
+   + libxl__get_rom_memory_kb(gc, domid, d_config)) < 0) {
 LOGE(ERROR, "Couldn't set max memory");
 return ERROR_FAIL;
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c582894..ec99fc0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -102,8 +102,9 @@
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
 #define LIBXL_MAXMEM_CONSTANT 1024
+#define LIBXL_ROMSIZE_KB 256
 #define LIBXL_PV_EXTRA_MEMORY 1024
-#define LIBXL_HVM_EXTRA_MEMORY 2048
+#define LIBXL_HVM_EXTRA_MEMORY (LIBXL_MAXMEM_CONSTANT + 1024)
 #define LIBXL_MIN_DOM0_MEM (128*1024)
 #define LIBXL_INVALID_GFN (~(uint64_t)0)
 #define LIBXL_VGA_HOLE_SIZE 0x20
@@ -1200,6 +1201,13 @@ _hidden char * libxl__domain_pvcontrol_read(libxl__gc 
*gc,
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
   uint32_t domid, const char *cmd);
 
+/* Returns the amount of extra mem required to allocate roms or an libxl
+ * error code on error.
+ * The *d_config parameter is optional.
+ */
+_hidden int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid,
+ libxl_domain_config *d_config);
+
 /* from xl_device */
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);
diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
index e551e09..b6f9440 100644
--- a/tools/libxl/libxl_mem.c
+++ b/tools/libxl/libxl_mem.c
@@ -17,6 +17,30 @@
 #include "libxl_internal.h"
 #include "libxl_arch.h"
 
+int libxl__get_rom_memory_kb(libxl__gc *gc, uint32_t domid, 
libxl_domain_config *d_config)
+{
+int i, count_rom, rc;
+libxl_domain_config local_d_config;
+
+if (d_config == NULL) {
+libxl_domain_config_init(_d_config);
+rc = libxl__get_domain_configuration(gc, domid, _d_config);
+if (rc < 0)
+return rc;
+d_config = _d_config;
+}
+
+if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV)
+return 0;
+
+for (i = 0, count_rom = 0; i < d_config->num_nics; i++) {
+if (d_config->nics[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU)
+count_rom++;
+}
+
+return count_rom*LIBXL_ROMSIZE_KB;
+}
+
 /*
  * Set the maximum memory size of the domain in the hypervisor. There is no
  * change of the current memory size involved. The specified memory size can
@@ -74,11 +98,13 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, 
uint64_t max_memkb)
 goto out;
 }
 
-rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + size);
+rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + size
+ + libxl__get_rom_memory_kb(gc, domid, NULL));
 if (rc != 0) {
 LOGED(ERROR, domid,
-  "xc_domain_setmaxmem domid=%d memkb=%"PRIu64" failed ""rc=%d\n",
-  domid, max_memkb + size, rc);
+  "xc_domain_setmaxmem domid=%d memkb=%"PRIu64" failed rc=%d\n",
+  domid, max_memkb + size +
+  libxl__get_rom_memory_kb(gc, domid, NULL), rc);
 goto out;
 }
 
@@ -286,11 +312,12 @@ retry_transaction:
 
 if (enforce) {
 memorykb = new_target_memkb + videoram;
-r = xc_domain_setmaxmem(ctx->xch, domid, memorykb + size);
+r = xc_domain_setmaxmem(ctx->xch, domid, memorykb + size
++ libxl__get_rom_memory_kb(gc, domid, NULL));
 if (r != 0) {
 LOGED(ERROR, domid,
   "xc_domain_setmaxmem memkb=%"PRIu64" failed ""rc=%d\n",
-  memorykb + size,
+  memorykb + size + libxl__get_rom_memory_kb(gc, domid, NULL),
   r);
  

Re: [Xen-devel] [PATCH for-4.11 v4 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[Ian Jackson]

Lars Kurth writes ("[PATCH for-4.11 v4 1/1] Add new add_maintainers.pl script 
to optimise the workflow when using git format-patch with get_maintainer.pl"):
> The tool covers step 2 of the following workflow

Thanks.  Sorry to spot this only now, but

> +sub writefile ($$) {
> +my ($content, $file) = @_;
> +my $fh;
> +open($fh, ">", $file)
> + or die "Could not open file '$file' $!";
> +print $fh $content or die $!;
> +close $fh or die $!;
> +}

this will lose data if your disk is full.

You want:

  sub writefile ($$) {
  my ($content, $file) = @_;
  my $fh;
  open($fh, ">", "$file.tmp")
   or die "Could not open file '$file.tmp' $!";
  print $fh $content or die $!;
  close $fh or die $!;
  ranem "$file.tmp", $file or die "Could not rename '$file' into place $!";
  }

(NB: untested.)

Aside from that,

Acked-by: Ian Jackson 

Do you want me to pick up my suggested change and test it ?

Ian.

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

Re: [Xen-devel] [PATCH v1 for 4.7] x86/cpuid: fix raw FEATURESET_7d0 reporting

[Andrew Cooper]

On 15/05/18 10:04, Jan Beulich wrote:
 On 15.05.18 at 10:37,  wrote:
>> Commit 62b1879693e0 ("x86: further CPUID handling adjustments") added
>> FEATURESET_7d0 reporting but forgot to update calculate_raw_featureset()
>> function. As result, the value reported by xen-cpuid contains 0.
>>
>> Fix that by properly filling raw_featureset[FEATURESET_7d0].
>>
>> Signed-off-by: Sergey Dyasli 
> Thanks, technically
> Acked-by: Jan Beulich 
>
>> ---
>> I see that at least 4.8 also contains this bug, so other releases also
>> need checking.
> The commit in question being only on the two branches, I think no other one
> would need the change.
>
> I'm certainly going to apply this to 4.8; I'm uncertain about 4.7 though 
> 

The entirety of that changeset is broken in feature levelling scenarios,
which is a consequence of missing this hunk which Sergey identified.

The result is that, when trying to level STIBP/IBPB out of guests view,
the CPUID bits remain visible, but attempts to use the MSR bits will fail.

I'm rewriting the change from scratch.

~Andrew

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

Re: [Xen-devel] [Qemu-devel] [PATCH v2 3/3] xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages

[Eric Blake]

On 05/15/2018 11:16 AM, Anthony PERARD wrote:


+errno = EOPNOTSUPP;


I think ENOSYS would be better. EOPNOTSUPP seems to be for sockets.



No, EOPNOTSUPP is more general than that and is convention for unimplemented 
API operations elsewhere. ENOSYS is supposed to strictly mean 'system call not 
implemented' but we use it for hypercalls in Xen, leading to occasional fun 
with Linux checkpatch.pl.


In man errno, I have:
ENOTSUP Operation not supported (POSIX.1-2001)
EOPNOTSUPP  Operation not supported on socket (POSIX.1-2001).


POSIX allows (and Linux exploits) ENOTSUP and EOPNOTSUPP to be synonyms 
for the same error value.  I somewhat prefer the ENOTSUP spelling; and 
it's probably a bit nicer between the two when porting to platforms 
where the two spellings are not synonyms.



ENOSYS  Function not implemented (POSIX.1-2001).

But I guess any of these would work.



--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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

Re: [Xen-devel] Draft NVDIMM proposal

[Dan Williams]

On Tue, May 15, 2018 at 7:19 AM, George Dunlap  wrote:
> On 05/11/2018 05:33 PM, Dan Williams wrote:
>> [ adding linux-nvdimm ]
>>
>> Great write up! Some comments below...
>
> Thanks for the quick response!
>
> It seems I still have some fundamental misconceptions about what's going
> on, so I'd better start with that. :-)
>
> Here's the part that I'm having a hard time getting.
>
> If actual data on the NVDIMMs is a noun, and the act of writing is a
> verb, then the SPA and interleave sets are adverbs: they define *how*
> the write happens.  When the processor says, "Write to address X", the
> memory controller converts address X into a  address> tuple to actually write the data.
>
> So, who decides what this SPA range and interleave set is?  Can the
> operating system change these interleave sets and mappings, or change
> data from PMEM to BLK, and is so, how?

The interleave-set to SPA range association and delineation of
capacity between PMEM and BLK access modes is current out-of-scope for
ACPI. The BIOS reports the configuration to the OS via the NFIT, but
the configuration is currently written by vendor specific tooling.
Longer term it would be great for this mechanism to become
standardized and available to the OS, but for now it requires platform
specific tooling to change the DIMM interleave configuration.

> If you read through section 13.19 of the UEFI manual, it seems to imply
> that this is determined by the label area -- that each DIMM has a
> separate label area describing regions local to that DIMM; and that if
> you have 4 DIMMs you'll have 4 label areas, and each label area will
> have a label describing the DPA region on that DIMM which corresponds to
> the interleave set.  And somehow someone sets up the interleave sets and
> SPA based on what's written there.
>
> Which would mean that an operating system could change how the
> interleave sets work by rewriting the various labels on the DIMMs; for
> instance, changing a single 4-way set spanning the entirety of 4 DIMMs,
> to one 4-way set spanning half of 4 DIMMs, and 2 2-way sets spanning
> half of 2 DIMMs each.

If a DIMM supports both the PMEM and BLK mechanisms for accessing the
same DPA, then the label breaks the disambiguation and tells the OS to
enforce one access mechanism per DPA at a time. Otherwise the OS has
no ability to affect the interleave-set configuration, it's all
initialized by platform BIOS/firmware before the OS boots.

>
> But then you say:
>
>> Unlike NVMe an NVDIMM itself has no concept of namespaces. Some DIMMs
>> provide a "label area" which is an out-of-band non-volatile memory
>> area where the OS can store whatever it likes. The UEFI 2.7
>> specification defines a data format for the definition of namespaces
>> on top of persistent memory ranges advertised to the OS via the ACPI
>> NFIT structure.
>
> OK, so that sounds like no, that's that what happens.  So where do the
> SPA range and interleave sets come from?
>
> Random guess: The BIOS / firmware makes it up.  Either it's hard-coded,
> or there's some menu in the BIOS you can use to change things around;
> but once it hits the operating system, that's it -- the mapping of SPA
> range onto interleave sets onto DIMMs is, from the operating system's
> point of view, fixed.

Correct.

> And so (here's another guess) -- when you're talking about namespaces
> and label areas, you're talking about namespaces stored *within a
> pre-existing SPA range*.  You use the same format as described in the
> UEFI spec, but ignore all the stuff about interleave sets and whatever,
> and use system physical addresses relative to the SPA range rather than
> DPAs.

Well, we don't ignore it because we need to validate in the driver
that the interleave set configuration matches a checksum that we
generated when the namespace was first instantiated on the interleave
set. However, you are right, for accesses at run time all we care
about is the SPA for PMEM accesses.

>
> Is that right?
>
> But then there's things like this:
>
>> There is no obligation for an NVDIMM to provide a label area, and as
>> far as I know all NVDIMMs on the market today do not provide a label
>> area.
> [snip]
>> Linux supports "label-less" mode where it exposes
>> the raw capacity of a region in 1:1 mapped namespace without a label.
>> This is how Linux supports "legacy" NVDIMMs that do not support
>> labels.
>
> So are "all NVDIMMs on the market today" then classed as "legacy"
> NVDIMMs because they don't support labels?  And if labels are simply the
> NVDIMM equivalent of a partition table, then what does it mena to
> "support" or "not support" labels?

Yes, the term "legacy" has been thrown around for NVDIMMs that do not
support labels. The way this support is determined is whether the
platform publishes the _LSI, _LSR, and _LSW methods in ACPI (see:
6.5.10 NVDIMM Label Methods in ACPI 6.2a). I.e. each DIMM is
represented by an ACPI device object, and we query those 

Re: [Xen-devel] [PATCH v2 3/3] xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages

[Paul Durrant]

> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 15 May 2018 17:17
> To: Paul Durrant 
> Cc: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org; Stefano
> Stabellini 
> Subject: Re: [PATCH v2 3/3] xen-hvm: try to use
> xenforeignmemory_map_resource() to map ioreq pages
> 
> On Tue, May 15, 2018 at 04:45:25PM +0100, Paul Durrant wrote:
> > > > diff --git a/include/hw/xen/xen_common.h
> > > b/include/hw/xen/xen_common.h
> > > > index 5f1402b494..d925751040 100644
> > > > --- a/include/hw/xen/xen_common.h
> > > > +++ b/include/hw/xen/xen_common.h
> > > > @@ -119,6 +119,20 @@ static inline int
> > > xendevicemodel_pin_memory_cacheattr(
> > > >  return xc_domain_pin_memory_cacheattr(xen_xc, domid, start,
> end,
> > > type);
> > > >  }
> > > >
> > > > +typedef void xenforeignmemory_resource_handle;
> > > > +
> > > > +#define XENMEM_resource_ioreq_server_frame_bufioreq 0
> > > > +#define XENMEM_resource_ioreq_server_frame_ioreq(n) (1 + (n))
> > > > +
> > > > +static inline xenforeignmemory_resource_handle
> > > *xenforeignmemory_map_resource(
> > > > +xenforeignmemory_handle *fmem, domid_t domid, unsigned int
> type,
> > > > +unsigned int id, unsigned long frame, unsigned long nr_frames,
> > > > +void **paddr, int prot, int flags)
> > > > +{
> > > > +errno = EOPNOTSUPP;
> > >
> > > I think ENOSYS would be better. EOPNOTSUPP seems to be for sockets.
> > >
> >
> > No, EOPNOTSUPP is more general than that and is convention for
> unimplemented API operations elsewhere. ENOSYS is supposed to strictly
> mean 'system call not implemented' but we use it for hypercalls in Xen,
> leading to occasional fun with Linux checkpatch.pl.
> 
> In man errno, I have:
> ENOTSUP Operation not supported (POSIX.1-2001)
> EOPNOTSUPP  Operation not supported on socket (POSIX.1-2001).
> ENOSYS  Function not implemented (POSIX.1-2001).
> 
> But I guess any of these would work.

My reference is the non-Linux definitions in tools/libs/foreignmemory/private.h 
in the Xen tree. The one for xenforeignmemory_map_resource() is as follows:

static inline int osdep_xenforeignmemory_map_resource(
xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres)
{
errno = EOPNOTSUPP;
return -1;
}

So I'll stick with EOPNOTSUPP.

Cheers,

  Paul

> 
> --
> Anthony PERARD

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

[Xen-devel] [PATCH v3 1/3] xen-hvm: create separate function for ioreq server initialization

[Paul Durrant]

The code is sufficiently substantial that it improves code readability
to put it in a new function called by xen_hvm_init() rather than having
it inline.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefano Stabellini 
---
 hw/i386/xen/xen-hvm.c | 76 +++
 1 file changed, 46 insertions(+), 30 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index caa563be3d..6ffa3c22cc 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -95,7 +95,8 @@ typedef struct XenIOState {
 CPUState **cpu_by_vcpu_id;
 /* the evtchn port for polling the notification, */
 evtchn_port_t *ioreq_local_port;
-/* evtchn local port for buffered io */
+/* evtchn remote and local ports for buffered io */
+evtchn_port_t bufioreq_remote_port;
 evtchn_port_t bufioreq_local_port;
 /* the evtchn fd for polling */
 xenevtchn_handle *xce_handle;
@@ -1236,12 +1237,52 @@ static void xen_wakeup_notifier(Notifier *notifier, 
void *data)
 xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 0);
 }
 
-void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory)
+static int xen_map_ioreq_server(XenIOState *state)
 {
-int i, rc;
 xen_pfn_t ioreq_pfn;
 xen_pfn_t bufioreq_pfn;
 evtchn_port_t bufioreq_evtchn;
+int rc;
+
+rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
+   _pfn, _pfn,
+   _evtchn);
+if (rc < 0) {
+error_report("failed to get ioreq server info: error %d handle=%p",
+ errno, xen_xc);
+return rc;
+}
+
+DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
+DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
+DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
+
+state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
+  PROT_READ | PROT_WRITE,
+  1, _pfn, NULL);
+if (state->shared_page == NULL) {
+error_report("map shared IO page returned error %d handle=%p",
+ errno, xen_xc);
+return -1;
+}
+
+state->buffered_io_page = xenforeignmemory_map(xen_fmem, xen_domid,
+   PROT_READ | PROT_WRITE,
+   1, _pfn, NULL);
+if (state->buffered_io_page == NULL) {
+error_report("map buffered IO page returned error %d", errno);
+return -1;
+}
+
+state->bufioreq_remote_port = bufioreq_evtchn;
+
+return 0;
+}
+
+void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory)
+{
+int i, rc;
+xen_pfn_t ioreq_pfn;
 XenIOState *state;
 
 state = g_malloc0(sizeof (XenIOState));
@@ -1269,25 +1310,8 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 state->wakeup.notify = xen_wakeup_notifier;
 qemu_register_wakeup_notifier(>wakeup);
 
-rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
-   _pfn, _pfn,
-   _evtchn);
+rc = xen_map_ioreq_server(state);
 if (rc < 0) {
-error_report("failed to get ioreq server info: error %d handle=%p",
- errno, xen_xc);
-goto err;
-}
-
-DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
-DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
-DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
-
-state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
-  PROT_READ|PROT_WRITE,
-  1, _pfn, NULL);
-if (state->shared_page == NULL) {
-error_report("map shared IO page returned error %d handle=%p",
- errno, xen_xc);
 goto err;
 }
 
@@ -1308,14 +1332,6 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 goto err;
 }
 
-state->buffered_io_page = xenforeignmemory_map(xen_fmem, xen_domid,
-   PROT_READ|PROT_WRITE,
-   1, _pfn, NULL);
-if (state->buffered_io_page == NULL) {
-error_report("map buffered IO page returned error %d", errno);
-goto err;
-}
-
 /* Note: cpus is empty at this point in init */
 state->cpu_by_vcpu_id = g_malloc0(max_cpus * sizeof(CPUState *));
 
@@ -1340,7 +1356,7 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 }
 
 rc = xenevtchn_bind_interdomain(state->xce_handle, xen_domid,
-bufioreq_evtchn);
+state->bufioreq_remote_port);
 if (rc == -1) {
 error_report("buffered evtchn bind 

[Xen-devel] [PATCH v3 3/3] xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages

[Paul Durrant]

Xen 4.11 has a new API to directly map guest resources. Among the resources
that can be mapped using this API are ioreq pages.

This patch modifies QEMU to attempt to use the new API should it exist,
falling back to the previous mechanism if it is unavailable.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 

v3:
 - Addressed comments from Anthony
 - Verified build against Xen 4.10
---
 configure   |  5 
 hw/i386/xen/trace-events|  1 +
 hw/i386/xen/xen-hvm.c   | 66 ++---
 include/hw/xen/xen_common.h | 16 +++
 4 files changed, 73 insertions(+), 15 deletions(-)

diff --git a/configure b/configure
index 59f91ab3f9..d03094f905 100755
--- a/configure
+++ b/configure
@@ -2231,12 +2231,17 @@ EOF
 #undef XC_WANT_COMPAT_DEVICEMODEL_API
 #define __XEN_TOOLS__
 #include 
+#include 
 int main(void) {
   xendevicemodel_handle *xd;
+  xenforeignmemory_handle *xfmem;
 
   xd = xendevicemodel_open(0, 0);
   xendevicemodel_pin_memory_cacheattr(xd, 0, 0, 0, 0);
 
+  xfmem = xenforeignmemory_open(0, 0);
+  xenforeignmemory_map_resource(xfmem, 0, 0, 0, 0, 0, NULL, 0, 0);
+
   return 0;
 }
 EOF
diff --git a/hw/i386/xen/trace-events b/hw/i386/xen/trace-events
index 8dab7bcfe0..38616b698f 100644
--- a/hw/i386/xen/trace-events
+++ b/hw/i386/xen/trace-events
@@ -15,6 +15,7 @@ cpu_ioreq_pio(void *req, uint32_t dir, uint32_t df, uint32_t 
data_is_ptr, uint64
 cpu_ioreq_pio_read_reg(void *req, uint64_t data, uint64_t addr, uint32_t size) 
"I/O=%p pio read reg data=0x%"PRIx64" port=0x%"PRIx64" size=%d"
 cpu_ioreq_pio_write_reg(void *req, uint64_t data, uint64_t addr, uint32_t 
size) "I/O=%p pio write reg data=0x%"PRIx64" port=0x%"PRIx64" size=%d"
 cpu_ioreq_move(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr, 
uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p copy 
dir=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
+xen_map_resource_ioreq(uint32_t id, void *addr) "id: %u addr: %p"
 
 # xen-mapcache.c
 xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 6ffa3c22cc..ff2a99cbb3 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1239,13 +1239,39 @@ static void xen_wakeup_notifier(Notifier *notifier, 
void *data)
 
 static int xen_map_ioreq_server(XenIOState *state)
 {
+void *addr = NULL;
+xenforeignmemory_resource_handle *fres;
 xen_pfn_t ioreq_pfn;
 xen_pfn_t bufioreq_pfn;
 evtchn_port_t bufioreq_evtchn;
 int rc;
 
+/*
+ * Attempt to map using the resource API and fall back to normal
+ * foreign mapping if this is not supported.
+ */
+QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_bufioreq != 0);
+QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_ioreq(0) != 1);
+fres = xenforeignmemory_map_resource(xen_fmem, xen_domid,
+ XENMEM_resource_ioreq_server,
+ state->ioservid, 0, 2,
+ ,
+ PROT_READ | PROT_WRITE, 0);
+if (fres != NULL) {
+trace_xen_map_resource_ioreq(state->ioservid, addr);
+state->buffered_io_page = addr;
+state->shared_page = addr + TARGET_PAGE_SIZE;
+} else if (errno != EOPNOTSUPP) {
+error_report("failed to map ioreq server resources: error %d 
handle=%p",
+ errno, xen_xc);
+return -1;
+}
+
 rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
-   _pfn, _pfn,
+   (state->shared_page == NULL) ?
+   _pfn : NULL,
+   (state->buffered_io_page == NULL) ?
+   _pfn : NULL,
_evtchn);
 if (rc < 0) {
 error_report("failed to get ioreq server info: error %d handle=%p",
@@ -1253,27 +1279,37 @@ static int xen_map_ioreq_server(XenIOState *state)
 return rc;
 }
 
-DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
-DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
-DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
-
-state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
-  PROT_READ | PROT_WRITE,
-  1, _pfn, NULL);
 if (state->shared_page == NULL) {
-error_report("map shared IO page returned error %d handle=%p",
- errno, xen_xc);
-return -1;
+DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
+
+state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
+  PROT_READ | PROT_WRITE,
+

[Xen-devel] [PATCH v3 0/3] xen-hvm: use new resource mapping API

[Paul Durrant]

This series modifies QEMU to use the new guest resource mapping API
(available in Xen 4.11+) to map ioreq pages.

v2:
 - Add a patch to checkpatch to avoid misparsing of Xen stable API handles

Paul Durrant (3):
  xen-hvm: create separate function for ioreq server initialization
  checkpatch: generalize xen handle matching in the list of types
  xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages

 configure   |   5 ++
 hw/i386/xen/trace-events|   1 +
 hw/i386/xen/xen-hvm.c   | 112 
 include/hw/xen/xen_common.h |  16 +++
 scripts/checkpatch.pl   |   2 +-
 5 files changed, 105 insertions(+), 31 deletions(-)
---
Cc: Anthony Perard 
Cc: Daniel P. Berrange 
Cc: Eric Blake 
Cc: Paolo Bonzini 
Cc: Stefano Stabellini 

-- 
2.11.0


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

[Xen-devel] [PATCH v3 2/3] checkpatch: generalize xen handle matching in the list of types

[Paul Durrant]

All the xen stable APIs define handle types of the form:

xen_handle

and some define additional handle types of the form:

xen__handle

Examples of these are xenforeignmemory_handle and
xenforeignmemory_resource_handle.

Both of these types will be misparsed by checkpatch if they appear as the
first token in a line since, as types defined by an external library, they
do not conform to the QEMU CODING_STYLE, which suggests CamelCase.

A previous patch (5ac067a24a8) added xendevicemodel_handle to the list
of types. This patch changes that to xen\w+_handle such that it will
match all Xen stable API handles of the forms detailed above.

Signed-off-by: Paul Durrant 
Reviewed-by: Eric Blake 
---
Cc: Paolo Bonzini 
Cc: Daniel P. Berrange 

v3:
 - Adjusted commit comment slightly as suggested by Eric

v2:
 - New in this version
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index cb1b652388..e3d8c2cdfc 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -271,7 +271,7 @@ our @typeList = (
qr{hwaddr},
 # external libraries
qr{xml${Ident}},
-   qr{xendevicemodel_handle},
+   qr{xen\w+_handle},
# Glib definitions
qr{gchar},
qr{gshort},
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v5] scripts/add_maintainers.pl: New script

[Lars Kurth]

Acked-by: Lars Kurth 
Although it should probably mention --get-maintainers in the help message
Lars

On 15/05/2018, 18:12, "Ian Jackson"  wrote:

(Fixed the Subject line.)

Ian Jackson writes ("[PATCH] scripts/add_maintainers.pl: New script"):
> Changes since v4:
> - Strip some trailing whitespace from the code
> - writefile() now uses the .tmp-and-rename pattern to avoid data loss
> - Provide --get-maintainers= option to specify replacement for
>   get_maintainers.pl.  This is useful for Ian's usecase, since it
>   allows --get-maintainers=true, to avoid adding any MAINTAINERS-based
>   info anywhere while still adding other CCs (eg from -t) everywhere.
> - Refactor normalize() somewhat so that it uses only %seen, and
>   does not any longer modify its argument arrays.
> - De-dupe case-insensitively (by making normalize use lc).

Here's the diff for my changes.

diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
index b4134e9..0f4a4cf 100755
--- a/scripts/add_maintainers.pl
+++ b/scripts/add_maintainers.pl
@@ -223,6 +223,7 @@ if (!GetOptions(
 't|tags'   => \$tags,
 'tagscc'   => \$tagscc,
 'a|arg=s'  => \@get_maintainer_args,
+'get-maintainers=s' => \$get_maintainer,
 'verbose'  => \$verbose,
 'h|help'   => \$help,
 )) {
@@ -345,7 +346,7 @@ if ($has_cover_letter) {
 my @ccpatch;# Cc: entries in *.patch
 
 print "Processing: ".basename($cover_letter_file)."\n";
-
+
 # Read all lines with CC & TO from the patch file such that subsequent
 # calls don't lead to duplication
 gettagsfrompatch($cover_letter_file, \@headerpatch, \@ccpatch);
@@ -467,21 +468,20 @@ sub hastag ($$) {
 }
 
 sub normalize ($$) {
-# This function is used to normalize lists of tags or CC / TO lists
-# - It removes duplicates in the input arrays
-# - It ensures that elements in the second list are not in the first
 my ($ra, $rb) = @_;
+# This function is used to normalize lists of tags or CC / TO lists
+# It returns a list of the unique elements
+# in @$ra, excluding any which are in @$rb.
+# Comparisons are case-insensitive.
 my @aonly = ();
 my %seen;
 my $item;
 
-@$ra = uniq @$ra;
-@$rb = uniq @$rb;
 foreach $item (@$rb) {
-$seen{$item} = 1;
+$seen{lc($item)} = 1;
 }
 foreach $item (@$ra) {
-unless ($seen{$item}) {
+unless ($seen{lc($item)}++) {
 # it's not in %seen, so add to @aonly
 push @aonly, $item;
 }
@@ -506,10 +506,11 @@ sub readfile ($) {
 sub writefile ($$) {
 my ($content, $file) = @_;
 my $fh;
-open($fh, ">", $file)
- or die "Could not open file '$file' $!";
+open($fh, ">", "$file.tmp")
+ or die "Could not open file '$file.tmp' $!";
 print $fh $content or die $!;
 close $fh or die $!;
+rename "$file.tmp", $file or die "Could not rename '$file' into place 
$!";
 }
 
 sub insert () {


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  bd9f5f7c6668227fa539eccf78fb17637ddd
baseline version:
 xen  29fc0493d8eabdd63f5bbff9e3069253053addca

Last test of basis   122809  2018-05-14 12:00:23 Z1 days
Testing same since   122848  2018-05-15 16:00:36 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Lars Kurth 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   29fc0493d8..bd9f5f7c66  bd9f5f7c6668227fa539eccf78fb17637ddd -> smoke

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

[Xen-devel] [PATCH for-4.7/4.8] x86: Fix "x86: further CPUID handling adjustments"

[Andrew Cooper]

c/s f9616884e (a backport of c/s 0d703a701 "x86/feature: Definitions for
Indirect Branch Controls") missed a CPUID adjustment when calculating the raw
featureset.  This impacts host administrator diagnostics.

Signed-off-by: Sergey Dyasli 

c/s 62b187969 "x86: further CPUID handling adjustments" make some adjustments.
However, it breaks levelling of guests, making it impossible for the toolstack
to hide STIBP or IBPB from guests on hardware with up-to-date microcode.

Also, I don't see any link between the change and the commit message.  With
the microcode installed, STIBP and IBPB are already visible to dom0.

The only required adjustment is to force STIBP == IBRSB, which must be done
after applying the pv_featureset[] mask to the toolstack's choice of value.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/cpuid.c   | 2 +-
 xen/arch/x86/hvm/hvm.c | 8 +---
 xen/arch/x86/traps.c   | 8 +---
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 451952c..fffcecd 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -113,7 +113,7 @@ static void __init calculate_raw_featureset(void)
 cpuid_count(0x7, 0, ,
 _featureset[FEATURESET_7b0],
 _featureset[FEATURESET_7c0],
-);
+_featureset[FEATURESET_7d0]);
 if ( max >= 0xd )
 cpuid_count(0xd, 1,
 _featureset[FEATURESET_Da1],
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ff1c6fa..0a1d4a9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3496,10 +3496,13 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
  special_features[FEATURESET_7b0]);
 
 *ecx &= hvm_featureset[FEATURESET_7c0];
-
-*edx |= cpufeat_mask(X86_FEATURE_STIBP);
 *edx &= hvm_featureset[FEATURESET_7d0];
 
+/* Force STIBP equal to IBRSB */
+*edx &= ~cpufeat_mask(X86_FEATURE_STIBP);
+if ( *edx & cpufeat_mask(X86_FEATURE_IBRSB) )
+*edx |= cpufeat_mask(X86_FEATURE_STIBP);
+
 /* Don't expose HAP-only features to non-hap guests. */
 if ( !hap_enabled(d) )
 {
@@ -3657,7 +3660,6 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 hvm_cpuid(0x8001, NULL, NULL, NULL, &_edx);
 *eax |= (_edx & cpufeat_mask(X86_FEATURE_LM) ? vaddr_bits : 32) << 8;
 
-*ebx |= cpufeat_mask(X86_FEATURE_IBPB);
 *ebx &= hvm_featureset[FEATURESET_e8b];
 break;
 }
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 0f34b21..da26749 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1088,10 +1088,13 @@ void pv_cpuid(struct cpu_user_regs *regs)
   special_features[FEATURESET_7b0]);
 
 c &= pv_featureset[FEATURESET_7c0];
-
-d |= cpufeat_mask(X86_FEATURE_STIBP);
 d &= pv_featureset[FEATURESET_7d0];
 
+/* Force STIBP equal to IBRSB */
+d &= ~cpufeat_mask(X86_FEATURE_STIBP);
+if ( d & cpufeat_mask(X86_FEATURE_IBRSB) )
+d |= cpufeat_mask(X86_FEATURE_STIBP);
+
 if ( !is_pvh_domain(currd) )
 {
 /*
@@ -1188,7 +1191,6 @@ void pv_cpuid(struct cpu_user_regs *regs)
 
 case 0x8008:
 a = paddr_bits | (vaddr_bits << 8);
-b |= cpufeat_mask(X86_FEATURE_IBPB);
 b &= pv_featureset[FEATURESET_e8b];
 break;
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH for-4.11 0/3] Support matrix: add missing caveat footnotes

[Lars Kurth]

On 15/05/2018, 16:23, "Lars Kurth"  wrote:

This seems to address the issue
Lars

On 15/05/2018, 16:06, "Ian Jackson"  wrote:

Juergen Gross writes ("Re: [PATCH for-4.11 0/3] Support matrix: add 
missing caveat footnotes"):
> For the series:
> Release-acked-by: Juergen Gross 

Thanks.

FYI, example output is here:

 https://xenbits.xen.org/people/iwj/2018/support-matrix-example-E/t.html

Acked-by: Lars Kurth  

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

Re: [Xen-devel] [PATCH v2 3/3] xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages

[Paul Durrant]

> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 15 May 2018 16:38
> To: Paul Durrant 
> Cc: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org; Stefano
> Stabellini 
> Subject: Re: [PATCH v2 3/3] xen-hvm: try to use
> xenforeignmemory_map_resource() to map ioreq pages
> 
> On Thu, May 10, 2018 at 10:15:18AM +0100, Paul Durrant wrote:
> > --- a/hw/i386/xen/xen-hvm.c
> > +++ b/hw/i386/xen/xen-hvm.c
> > @@ -1239,13 +1239,41 @@ static void xen_wakeup_notifier(Notifier
> *notifier, void *data)
> >
> >  static int xen_map_ioreq_server(XenIOState *state)
> >  {
> > +void *addr = NULL;
> > +xenforeignmemory_resource_handle *fres;
> >  xen_pfn_t ioreq_pfn;
> >  xen_pfn_t bufioreq_pfn;
> >  evtchn_port_t bufioreq_evtchn;
> >  int rc;
> >
> > +/*
> > + * Attempt to map using the resource API and fall back to normal
> > + * foreign mapping if this is not supported.
> > + */
> > +
> QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_bufioreq
> != 0);
> > +
> QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_ioreq(0)
> != 1);
> > +fres = xenforeignmemory_map_resource(xen_fmem, xen_domid,
> > + XENMEM_resource_ioreq_server,
> 
> XENMEM_resource_ioreq_server undeclared with Xen 4.10

Yes, I missed that from my compat definitions. Will add.

> 
> > + state->ioservid, 0, 2,
> > + ,
> > + PROT_READ | PROT_WRITE, 0);
> > +if (fres != NULL) {
> > +trace_xen_map_resource_ioreq(state->ioservid, addr);
> > +state->buffered_io_page = addr;
> > +state->shared_page = addr + TARGET_PAGE_SIZE;
> > +} else {
> > +error_report("failed to map ioreq server resources: error %d
> handle=%p",
> > + errno, xen_xc);
> 
> Maybe printing the error message only when
> xenforeignmemory_map_resource
> fails, would be better? i.e. after checking errno value.
> 

Yes, that be better. I'll move it lower.

> > +if (errno != EOPNOTSUPP) {
> > +return -1;
> > +}
> > +}
> > +
> >  rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
> > -   _pfn, _pfn,
> > +   (state->shared_page == NULL) ?
> > +   _pfn : NULL,
> > +   (state->buffered_io_page == NULL) ?
> > +   _pfn : NULL,
> > _evtchn);
> >  if (rc < 0) {
> >  error_report("failed to get ioreq server info: error %d handle=%p",
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 5f1402b494..d925751040 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -119,6 +119,20 @@ static inline int
> xendevicemodel_pin_memory_cacheattr(
> >  return xc_domain_pin_memory_cacheattr(xen_xc, domid, start, end,
> type);
> >  }
> >
> > +typedef void xenforeignmemory_resource_handle;
> > +
> > +#define XENMEM_resource_ioreq_server_frame_bufioreq 0
> > +#define XENMEM_resource_ioreq_server_frame_ioreq(n) (1 + (n))
> > +
> > +static inline xenforeignmemory_resource_handle
> *xenforeignmemory_map_resource(
> > +xenforeignmemory_handle *fmem, domid_t domid, unsigned int type,
> > +unsigned int id, unsigned long frame, unsigned long nr_frames,
> > +void **paddr, int prot, int flags)
> > +{
> > +errno = EOPNOTSUPP;
> 
> I think ENOSYS would be better. EOPNOTSUPP seems to be for sockets.
> 

No, EOPNOTSUPP is more general than that and is convention for unimplemented 
API operations elsewhere. ENOSYS is supposed to strictly mean 'system call not 
implemented' but we use it for hypercalls in Xen, leading to occasional fun 
with Linux checkpatch.pl.

> 
> > +return -1;
> 
> Should this return NULL instead?  That doesn't build on Xen 4.10 and earlier.
> 

Indeed it should. Not sure how I missed that.

> > +}
> > +
> >  #endif /* CONFIG_XEN_CTRL_INTERFACE_VERSION < 41100 */
> >
> >  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
> 
> Thanks,

Thanks. V3 coming soon.

  Paul

> 
> --
> Anthony PERARD

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

Re: [Xen-devel] [PATCH v5] scripts/add_maintainers.pl: New script

[Ian Jackson]

(Fixed the Subject line.)

Ian Jackson writes ("[PATCH] scripts/add_maintainers.pl: New script"):
> Changes since v4:
> - Strip some trailing whitespace from the code
> - writefile() now uses the .tmp-and-rename pattern to avoid data loss
> - Provide --get-maintainers= option to specify replacement for
>   get_maintainers.pl.  This is useful for Ian's usecase, since it
>   allows --get-maintainers=true, to avoid adding any MAINTAINERS-based
>   info anywhere while still adding other CCs (eg from -t) everywhere.
> - Refactor normalize() somewhat so that it uses only %seen, and
>   does not any longer modify its argument arrays.
> - De-dupe case-insensitively (by making normalize use lc).

Here's the diff for my changes.

diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
index b4134e9..0f4a4cf 100755
--- a/scripts/add_maintainers.pl
+++ b/scripts/add_maintainers.pl
@@ -223,6 +223,7 @@ if (!GetOptions(
 't|tags'   => \$tags,
 'tagscc'   => \$tagscc,
 'a|arg=s'  => \@get_maintainer_args,
+'get-maintainers=s' => \$get_maintainer,
 'verbose'  => \$verbose,
 'h|help'   => \$help,
 )) {
@@ -345,7 +346,7 @@ if ($has_cover_letter) {
 my @ccpatch;# Cc: entries in *.patch
 
 print "Processing: ".basename($cover_letter_file)."\n";
-
+
 # Read all lines with CC & TO from the patch file such that subsequent
 # calls don't lead to duplication
 gettagsfrompatch($cover_letter_file, \@headerpatch, \@ccpatch);
@@ -467,21 +468,20 @@ sub hastag ($$) {
 }
 
 sub normalize ($$) {
-# This function is used to normalize lists of tags or CC / TO lists
-# - It removes duplicates in the input arrays
-# - It ensures that elements in the second list are not in the first
 my ($ra, $rb) = @_;
+# This function is used to normalize lists of tags or CC / TO lists
+# It returns a list of the unique elements
+# in @$ra, excluding any which are in @$rb.
+# Comparisons are case-insensitive.
 my @aonly = ();
 my %seen;
 my $item;
 
-@$ra = uniq @$ra;
-@$rb = uniq @$rb;
 foreach $item (@$rb) {
-$seen{$item} = 1;
+$seen{lc($item)} = 1;
 }
 foreach $item (@$ra) {
-unless ($seen{$item}) {
+unless ($seen{lc($item)}++) {
 # it's not in %seen, so add to @aonly
 push @aonly, $item;
 }
@@ -506,10 +506,11 @@ sub readfile ($) {
 sub writefile ($$) {
 my ($content, $file) = @_;
 my $fh;
-open($fh, ">", $file)
- or die "Could not open file '$file' $!";
+open($fh, ">", "$file.tmp")
+ or die "Could not open file '$file.tmp' $!";
 print $fh $content or die $!;
 close $fh or die $!;
+rename "$file.tmp", $file or die "Could not rename '$file' into place $!";
 }
 
 sub insert () {

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

[Xen-devel] [qemu-mainline test] 122734: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-libvirt-xsm broken
 test-arm64-arm64-xl-xsm  broken
 test-arm64-arm64-xl-xsm   4 host-install(4)broken REGR. vs. 122357
 test-arm64-arm64-libvirt-xsm  4 host-install(4)broken REGR. vs. 122357

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122357
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122357
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122357
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122357
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122357
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122357
 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-i386-xl-pvshim12 guest-start  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-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 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-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:
 qemuuc74e62ee3e2dc2955e07d004c71badecb68a84eb
baseline version:
 qemuu27e757e29cc79f3f104d2a84d17cdb3b4c11c8ff

Last test of basis   122357  2018-04-23 11:07:12 Z   22 days
Failing since122394  2018-04-24 16:40:23 Z   20 days   12 attempts
Testing same since   122734  2018-05-13 09:08:21 Z2 days1 attempts


People who touched revisions under test:
  Aaron Lindsay 
  Alex Bennée 
  Alexey Perevalov 
  Anthony PERARD 
  BALATON Zoltan 
  Bandan Das 
  Bastian Koppelmann 
  Bharat Bhushan 
  Bharata B Rao 
  Christian Borntraeger 
  Christophe Lyon 
  Claudio Imbrenda 

[Xen-devel] [PATCH for-next 5/5] tools: provide --with-system-ipxe

[Wei Liu]

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 config/Tools.mk.in|  1 +
 tools/config.h.in |  3 +++
 tools/configure   | 53 +++
 tools/configure.ac| 18 
 tools/libxl/libxl_paths.c |  6 +-
 5 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 4cc9f29090..0964f6f9e9 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -50,6 +50,7 @@ FLASK_POLICY:= @xsmpolicy@
 CONFIG_OVMF := @ovmf@
 CONFIG_ROMBIOS  := @rombios@
 CONFIG_SEABIOS  := @seabios@
+CONFIG_IPXE := @ipxe@
 CONFIG_QEMU_TRAD:= @qemu_traditional@
 CONFIG_QEMU_XEN := @qemu_xen@
 CONFIG_BLKTAP2  := @blktap2@
diff --git a/tools/config.h.in b/tools/config.h.in
index c66a78c9b3..5987f087b8 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -96,6 +96,9 @@
 /* libutil header file name */
 #undef INCLUDE_LIBUTIL_H
 
+/* IPXE path */
+#undef IPXE_PATH
+
 /* OVMF path */
 #undef OVMF_PATH
 
diff --git a/tools/configure b/tools/configure
index f282e9f5b3..16960a425b 100755
--- a/tools/configure
+++ b/tools/configure
@@ -703,6 +703,7 @@ AS86
 qemu_traditional
 blktap2
 LINUX_BACKEND_MODULES
+ipxe
 seabios
 ovmf
 xsmpolicy
@@ -805,6 +806,7 @@ enable_ocamltools
 enable_xsmpolicy
 enable_ovmf
 enable_seabios
+enable_ipxe
 with_linux_backend_modules
 enable_blktap2
 enable_qemu_traditional
@@ -812,6 +814,7 @@ enable_rombios
 with_system_qemu
 with_system_seabios
 with_system_ovmf
+with_system_ipxe
 with_extra_qemuu_configure_args
 with_xenstored
 enable_systemd
@@ -1488,6 +1491,7 @@ Optional Features:
   --disable-xsmpolicy Disable XSM policy compilation (default is ENABLED)
   --enable-ovmf   Enable OVMF (default is DISABLED)
   --disable-seabios   Disable SeaBIOS (default is ENABLED)
+  --disable-ipxe  Disable IPXE (default is ENABLED)
   --enable-blktap2Enable blktap2, (DEFAULT is off)
   --enable-qemu-traditional
   Enable qemu traditional device model, (DEFAULT is on
@@ -1527,6 +1531,9 @@ Optional Packages:
   --with-system-ovmf[=PATH]
   Use system supplied OVMF PATH instead of building
   and installing our own version
+  --with-system-ipxe[=PATH]
+  Use system supplied IPXE PATH instead of building
+  and installing our own version
   --with-extra-qemuu-configure-args[="--ARG1 ..."]
   List of additional configure options for upstream
   qemu
@@ -4184,6 +4191,29 @@ seabios=$ax_cv_seabios
 
 
 
+# Check whether --enable-ipxe was given.
+if test "${enable_ipxe+set}" = set; then :
+  enableval=$enable_ipxe;
+fi
+
+
+if test "x$enable_ipxe" = "xno"; then :
+
+ax_cv_ipxe="n"
+
+elif test "x$enable_ipxe" = "xyes"; then :
+
+ax_cv_ipxe="y"
+
+elif test -z $ax_cv_ipxe; then :
+
+ax_cv_ipxe="y"
+
+fi
+ipxe=$ax_cv_ipxe
+
+
+
 
 # Check whether --with-linux-backend-modules was given.
 if test "${with_linux_backend_modules+set}" = set; then :
@@ -4573,6 +4603,29 @@ _ACEOF
 fi
 
 
+# Check whether --with-system-ipxe was given.
+if test "${with_system_ipxe+set}" = set; then :
+  withval=$with_system_ipxe;
+# Disable compilation of IPXE.
+ipxe=n
+case $withval in
+no) ipxe_path= ;;
+*)  ipxe_path=$withval ;;
+esac
+
+fi
+
+if test "x$ipxe" = "xy" -o -n "$ipxe_path" ; then :
+
+
+cat >>confdefs.h <<_ACEOF
+#define IPXE_PATH "${ipxe_path:-$XENFIRMWAREDIR/ipxe.bin}"
+_ACEOF
+
+
+fi
+
+
 # Check whether --with-extra-qemuu-configure-args was given.
 if test "${with_extra_qemuu_configure_args+set}" = set; then :
   withval=$with_extra_qemuu_configure_args;
diff --git a/tools/configure.ac b/tools/configure.ac
index 0826af8cbc..8e4b173d6f 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -84,6 +84,7 @@ AX_ARG_DEFAULT_ENABLE([ocamltools], [Disable Ocaml tools])
 AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
 AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
 AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS])
+AX_ARG_DEFAULT_ENABLE([ipxe], [Disable IPXE])
 
 AC_ARG_WITH([linux-backend-modules],
 AS_HELP_STRING([--with-linux-backend-modules="mod1 mod2"],
@@ -241,6 +242,23 @@ AS_IF([test "x$ovmf" = "xy" -o -n "$ovmf_path" ], [
[OVMF path])
 ])
 
+AC_ARG_WITH([system-ipxe],
+AS_HELP_STRING([--with-system-ipxe@<:@=PATH@:>@],
+   [Use system supplied IPXE PATH instead of building and installing
+our own version]),[
+# Disable compilation of IPXE.
+ipxe=n
+case $withval in
+no) ipxe_path= ;;
+*)  ipxe_path=$withval ;;
+esac
+],[])
+AS_IF([test "x$ipxe" = "xy" -o -n "$ipxe_path" ], [
+AC_DEFINE_UNQUOTED([IPXE_PATH],
+   ["${ipxe_path:-$XENFIRMWAREDIR/ipxe.bin}"],
+ 

[Xen-devel] [PATCH for-next 0/5] Load ipxe from a standalone file

[Wei Liu]

Seeing yet another bug report regarding ipxe today, I would rather have this
done than having to continuously cherry-pick ipxe commits.

I have written these patches from scratch to my liking.

Only very light testing is done. I will do a bit more testing when I have time.

Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Anoob Soman 
Cc: Doug Goldstein 

Wei Liu (5):
  Tools.mk.in: drop unused variables
  ipxe: produce a single binary from its build
  libxc: allow HVM guest to have modules
  tools: load IPXE from standalone file
  tools: provide --with-system-ipxe

 config/Tools.mk.in   |  3 +-
 tools/config.h.in|  3 ++
 tools/configure  | 53 
 tools/configure.ac   | 18 
 tools/firmware/Makefile  |  6 
 tools/firmware/etherboot/Makefile|  6 +++-
 tools/firmware/hvmloader/Makefile|  9 +-
 tools/firmware/hvmloader/hvmloader.c |  8 +-
 tools/firmware/hvmloader/rombios.c   | 23 +++-
 tools/libxc/xc_dom_x86.c | 32 --
 tools/libxl/libxl_dom.c  | 10 +++
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_paths.c|  9 ++
 13 files changed, 148 insertions(+), 33 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH for-next 4/5] tools: load IPXE from standalone file

[Wei Liu]

Do not embed IPXE into Rombios anymore. Instead, it is loaded by the
toolstack from a file as a separate module.

Ability to let user specify an IPXE blob will come later.

No user visible change.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/firmware/Makefile  |  6 ++
 tools/firmware/hvmloader/Makefile|  9 +
 tools/firmware/hvmloader/hvmloader.c |  8 +++-
 tools/firmware/hvmloader/rombios.c   | 23 ---
 tools/libxl/libxl_dom.c  | 10 ++
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_paths.c|  5 +
 7 files changed, 46 insertions(+), 16 deletions(-)

diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 5a7cf7766d..0bef579637 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -55,6 +55,9 @@ endif
 ifeq ($(CONFIG_OVMF),y)
$(INSTALL_DATA) ovmf-dir/ovmf.bin $(INST_DIR)/ovmf.bin
 endif
+ifeq ($(CONFIG_IPXE),y)
+   $(INSTALL_DATA) etherboot/ipxe/src/bin/ipxe.bin $(INST_DIR)/ipxe.bin
+endif
 ifeq ($(CONFIG_PV_SHIM),y)
$(INSTALL_DATA) xen-dir/xen-shim $(INST_DIR)/xen-shim
$(INSTALL_DATA) xen-dir/xen-shim-syms $(DEBG_DIR)/xen-shim-syms
@@ -69,6 +72,9 @@ endif
 ifeq ($(CONFIG_OVMF),y)
rm -f $(INST_DIR)/ovmf.bin
 endif
+ifeq ($(CONFIG_IPXE),y)
+   rm -r $(INST_DIR)/ipxe.bin
+endif
 ifeq ($(CONFIG_PV_SHIM),y)
rm -f $(INST_DIR)/xen-shim
rm -f $(DEBG_DIR)/xen-shim-syms
diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 16255ebddd..496ac72b77 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -51,7 +51,6 @@ CIRRUSVGA_ROM := 
../vgabios/VGABIOS-lgpl-latest.cirrus.debug.bin
 else
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
 endif
-ETHERBOOT_ROM := ../etherboot/ipxe/src/bin/ipxe.bin
 endif
 
 ROMS := 
@@ -60,7 +59,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
 OBJS += optionroms.o 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
-ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROM)
+ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM)
 endif
 
 .PHONY: all
@@ -105,12 +104,6 @@ ifneq ($(CIRRUSVGA_ROM),)
sh ../../misc/mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
echo "#endif" >> $@.new
 endif
-ifneq ($(ETHERBOOT_ROM),)
-   echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
-   sh ../../misc/mkhex etherboot $(ETHERBOOT_ROM) >> $@.new
-   echo "#endif" >> $@.new
-endif
-
mv $@.new $@
 
 .PHONY: clean
diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index f603f68ded..f546cfb3ab 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -368,7 +368,13 @@ int main(void)
 #ifdef ENABLE_ROMBIOS
 else if ( bios == _config )
 {
-bios->bios_load(bios, NULL, 0);
+const struct hvm_modlist_entry *ipxe;
+uint32_t paddr = 0;
+
+ipxe = get_module_entry(hvm_start_info, "ipxe");
+if ( ipxe )
+paddr = ipxe->paddr;
+bios->bios_load(bios, (void*)paddr, 0 /* unused */);
 }
 #endif
 else
diff --git a/tools/firmware/hvmloader/rombios.c 
b/tools/firmware/hvmloader/rombios.c
index c736fd9dea..8c44839ce3 100644
--- a/tools/firmware/hvmloader/rombios.c
+++ b/tools/firmware/hvmloader/rombios.c
@@ -63,6 +63,8 @@ static void rombios_setup_bios_info(void)
 memset(info, 0, sizeof(*info));
 }
 
+static void *ipxe_module_addr;
+
 static void rombios_load_roms(void)
 {
 int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
@@ -95,13 +97,17 @@ static void rombios_load_roms(void)
 etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
 if ( etherboot_phys_addr < OPTIONROM_PHYSICAL_ADDRESS )
 etherboot_phys_addr = OPTIONROM_PHYSICAL_ADDRESS;
-etherboot_sz = scan_etherboot_nic(OPTIONROM_PHYSICAL_END,
-  etherboot_phys_addr,
-  etherboot);
 
-option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
-option_rom_sz = pci_load_option_roms(OPTIONROM_PHYSICAL_END,
- option_rom_phys_addr);
+if ( ipxe_module_addr )
+{
+etherboot_sz = scan_etherboot_nic(OPTIONROM_PHYSICAL_END,
+  etherboot_phys_addr,
+  ipxe_module_addr);
+
+option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
+option_rom_sz = pci_load_option_roms(OPTIONROM_PHYSICAL_END,
+ option_rom_phys_addr);
+}
 
 printf("Option ROMs:\n");
 if ( vgabios_sz )
@@ -119,7 +125,7 @@ static void rombios_load_roms(void)
 }
 
 

[Xen-devel] [PATCH for-next 2/5] ipxe: produce a single binary from its build

[Wei Liu]

And switch hvmloader/Makefile to use that binary. This will help later
when we change hvmloader to pick a user provided binary.

No functional change.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/firmware/etherboot/Makefile | 6 +-
 tools/firmware/hvmloader/Makefile | 8 
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/etherboot/Makefile 
b/tools/firmware/etherboot/Makefile
index e33458d2fe..37896ed4fc 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -18,11 +18,15 @@ D=ipxe
 T=ipxe.tar.gz
 
 ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
+ROM = $D/src/bin/ipxe.bin
 
 .NOTPARALLEL:
 
 .PHONY: all
-all: $(ROMS)
+all: $(ROM)
+
+$(ROM): $(ROMS)
+   cat $^ > $@
 
 %.rom: $D/src/arch/i386/Makefile
$(MAKE) -C $D/src bin/$(*F).rom
diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index a5b4c32c1a..16255ebddd 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -51,7 +51,7 @@ CIRRUSVGA_ROM := 
../vgabios/VGABIOS-lgpl-latest.cirrus.debug.bin
 else
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
 endif
-ETHERBOOT_ROMS := $(addprefix ../etherboot/ipxe/src/bin/, $(addsuffix .rom, 
$(ETHERBOOT_NICS)))
+ETHERBOOT_ROM := ../etherboot/ipxe/src/bin/ipxe.bin
 endif
 
 ROMS := 
@@ -60,7 +60,7 @@ ifeq ($(CONFIG_ROMBIOS),y)
 OBJS += optionroms.o 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
-ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
+ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROM)
 endif
 
 .PHONY: all
@@ -105,9 +105,9 @@ ifneq ($(CIRRUSVGA_ROM),)
sh ../../misc/mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
echo "#endif" >> $@.new
 endif
-ifneq ($(ETHERBOOT_ROMS),)
+ifneq ($(ETHERBOOT_ROM),)
echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
-   sh ../../misc/mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new
+   sh ../../misc/mkhex etherboot $(ETHERBOOT_ROM) >> $@.new
echo "#endif" >> $@.new
 endif
 
-- 
2.11.0


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

[Xen-devel] [PATCH for-next 3/5] libxc: allow HVM guest to have modules

[Wei Liu]

Lift the loading code out of PVH specific branch. Take the chance to
make the debug message more useful.

IPXE will be loaded as a module of Rombios.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/libxc/xc_dom_x86.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index e33a28847d..ed4973a997 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -1698,20 +1698,6 @@ static int bootlate_hvm(struct xc_dom_image *dom)
 ((uintptr_t)cmdline - (uintptr_t)start_info);
 }
 
-for ( i = 0; i < dom->num_modules; i++ )
-{
-struct xc_hvm_firmware_module mod;
-
-DOMPRINTF("Adding module %u", i);
-mod.guest_addr_out =
-dom->modules[i].seg.vstart - dom->parms.virt_base;
-mod.length =
-dom->modules[i].seg.vend - dom->modules[i].seg.vstart;
-
-add_module_to_list(dom, , dom->modules[i].cmdline,
-   modlist, start_info);
-}
-
 /* ACPI module 0 is the RSDP */
 start_info->rsdp_paddr = dom->acpi_modules[0].guest_addr_out ? : 0;
 }
@@ -1721,6 +1707,24 @@ static int bootlate_hvm(struct xc_dom_image *dom)
modlist, start_info);
 }
 
+for ( i = 0; i < dom->num_modules; i++ )
+{
+struct xc_hvm_firmware_module mod;
+uint64_t base = dom->parms.virt_base != UNSET_ADDR ?
+dom->parms.virt_base : 0;
+
+mod.guest_addr_out =
+dom->modules[i].seg.vstart - base;
+mod.length =
+dom->modules[i].seg.vend - dom->modules[i].seg.vstart;
+
+DOMPRINTF("Adding module %u guest_addr %"PRIx64" len %u",
+  i, mod.guest_addr_out, mod.length);
+
+add_module_to_list(dom, , dom->modules[i].cmdline,
+   modlist, start_info);
+}
+
 if ( start_info->nr_modules )
 {
 start_info->modlist_paddr = (dom->start_info_seg.pfn << PAGE_SHIFT) +
-- 
2.11.0


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

Re: [Xen-devel] Draft NVDIMM proposal

[Andrew Cooper]

On 15/05/18 19:06, Dan Williams wrote:
> On Tue, May 15, 2018 at 7:19 AM, George Dunlap  
> wrote:
>> On 05/11/2018 05:33 PM, Dan Williams wrote:
>>
>> This is all pretty foundational.  Xen can read static ACPI tables, but
>> it can't do AML.  So to do a proper design for Xen, we need to know:
> Oooh, ok, no AML in Xen...
>
>> 1. If Xen can find out, without Linux's help, what namespaces exist and
>> if there is one it can use for its own purposes
> Yeah, no, not without calling AML methods.

One particularly thorny issue with Xen's architecture is the ownership
of the ACPI OSPM, and the fact that there can only be one in the
system.  Dom0 has to be the OSPM in practice, as we don't want to port
most of the Linux drivers and infrastructure in the hypervisor.

If we knew a priori that certain AML methods had no side effects, then
we could in principle execute them from the hypervisor, but this is an
undecideable problem in general.  As a result, everything involving AML
requires dom0 to decipher the information and passing it to Xen at boot.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.11 00/10] x86: Improvements and fixes to Spectre handling

[Juergen Gross]

On 11/05/18 12:38, Andrew Cooper wrote:
> In hindsight, the end result of the Spectre mitigations aren't as great as I'd
> hoped, and have several inefficiencies.  Also, the `bti=` command line option
> isn't as flexible as intended.
> 
> This series does four things:
> 
>   1) Some internal cleanup, for clarity and to help the other features
>   2) Introduce `spec-ctrl=no-pv` mode.  XenServer's performance measurements
>  see a 10% net/disk performance improvement in some production scenarios.
>   3) Introduce the ability to use IBPB-only mode for guests.  This was
>  discussed by Amazon during the Spectre work, but I don't have any
>  performance numbers to hand.
>   4) Avoid imposing IBRS mode while dom0 is booting.  This was reported by
>  Oracle on the list, and speeds up boot time on some servers by 50s.
> 
> I know this series is rather late for 4.11, but seeing as I've managed to
> complete it before 4.12 opens, it should be considered at this point, as all
> of the Spectre code is new in 4.11.
> 
> Andrew Cooper (10):
>   x86/spec_ctrl: Read MSR_ARCH_CAPABILITIES only once
>   x86/spec_ctrl: Express Xen's choice of MSR_SPEC_CTRL value as a variable
>   x86/spec_ctrl: Merge bti_ist_info and use_shadow_spec_ctrl into 
> spec_ctrl_flags
>   x86/spec_ctrl: Fold the XEN_IBRS_{SET,CLEAR} ALTERNATIVES together
>   x86/spec_ctrl: Rename bits of infrastructure to avoid NATIVE and VMEXIT
>   x86/spec_ctrl: Split X86_FEATURE_SC_MSR into PV and HVM variants
>   x86/spec_ctrl: Explicitly set Xen's default MSR_SPEC_CTRL value
>   x86/cpuid: Improvements to guest policies for speculative sidechannel 
> features
>   x86/spec_ctrl: Introduce a new `spec-ctrl=` command line argument to 
> replace `bti=`
>   x86/spec_ctrl: Elide MSR_SPEC_CTRL handling in idle context when possible
> 
>  docs/misc/xen-command-line.markdown |  49 +++
>  xen/arch/x86/acpi/power.c   |   4 +-
>  xen/arch/x86/cpuid.c|  60 +
>  xen/arch/x86/hvm/svm/entry.S|   4 +-
>  xen/arch/x86/hvm/vmx/entry.S|   4 +-
>  xen/arch/x86/setup.c|   7 +
>  xen/arch/x86/smpboot.c  |   8 ++
>  xen/arch/x86/spec_ctrl.c| 258 
> 
>  xen/arch/x86/x86_64/asm-offsets.c   |   4 +-
>  xen/arch/x86/x86_64/compat/entry.S  |   2 +-
>  xen/arch/x86/x86_64/entry.S |   2 +-
>  xen/include/asm-x86/cpufeatures.h   |   9 +-
>  xen/include/asm-x86/current.h   |   4 +-
>  xen/include/asm-x86/spec_ctrl.h |  20 +--
>  xen/include/asm-x86/spec_ctrl_asm.h | 131 +-
>  15 files changed, 396 insertions(+), 170 deletions(-)
> 

For the series:

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH 06/10] x86/spec_ctrl: Split X86_FEATURE_SC_MSR into PV and HVM variants

[Andrew Cooper]

On 14/05/18 16:27, Jan Beulich wrote:
 On 11.05.18 at 12:38,  wrote:
>> --- a/xen/arch/x86/spec_ctrl.c
>> +++ b/xen/arch/x86/spec_ctrl.c
>> @@ -128,7 +128,8 @@ static void __init print_details(enum ind_thunk thunk, 
>> uint64_t caps)
>> thunk == THUNK_RETPOLINE ? "RETPOLINE" :
>> thunk == THUNK_LFENCE? "LFENCE" :
>> thunk == THUNK_JMP   ? "JMP" : "?",
>> -   boot_cpu_has(X86_FEATURE_SC_MSR) ?
>> +   (boot_cpu_has(X86_FEATURE_SC_MSR_PV) ||
>> +boot_cpu_has(X86_FEATURE_SC_MSR_HVM)) ?
>> default_xen_spec_ctrl & SPEC_CTRL_IBRS? " IBRS+" :
>> " IBRS-"  : "",
>> opt_ibpb  ? " IBPB"   : "",
>> @@ -367,7 +368,8 @@ void __init init_speculation_mitigations(void)
>>   * need the IBRS entry/exit logic to virtualise IBRS support for
>>   * guests.
>>   */
>> -setup_force_cpu_cap(X86_FEATURE_SC_MSR);
>> +setup_force_cpu_cap(X86_FEATURE_SC_MSR_PV);
>> +setup_force_cpu_cap(X86_FEATURE_SC_MSR_HVM);
> Besides these sort of open coding alternative_io_2() (you'd really want an
> output-less variant here, I agree) these are slightly bending the rules of
> when/how to use multiple alternatives: The above ends up correct only
> because of both replacements being identical.

Actually, by reordering patch 10 ahead of this patch, we never get to
needing the ALTERNATIVE_2()'s in the first place, and lose any concerns
with bending the rules along the series.

~Andrew

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm  broken
 build-armhf-xsm   4 host-install(4)broken REGR. vs. 118324
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324
 test-armhf-armhf-xl-multivcpu 10 debian-install  fail REGR. vs. 118324
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-libvirt 10 debian-install   fail REGR. vs. 118324

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 10 debian-install   fail REGR. vs. 118324

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

version targeted for testing:
 linuxccda3c4b7f66aeb3c531352bb40d59501c59
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z  110 days
Failing since118362  2018-01-26 16:56:17 Z  109 days   84 attempts
Testing same since   122743  2018-05-13 13:45:07 Z2 days1 attempts


3473 people touched revisions under test,
not listing them all

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  b953322c5772dbc537421f9e2f97026a1c2fcb2e
baseline version:
 xen  bd9f5f7c6668227fa539eccf78fb17637ddd

Last test of basis   122848  2018-05-15 16:00:36 Z0 days
Testing same since   122852  2018-05-15 18:00:46 Z0 days1 attempts


People who touched revisions under test:
  Konrad Rzeszutek Wilk 
  Oleksandr Andrushchenko 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   bd9f5f7c66..b953322c57  b953322c5772dbc537421f9e2f97026a1c2fcb2e -> smoke

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

[Xen-devel] [PATCH for-next 1/5] Tools.mk.in: drop unused variables

[Wei Liu]

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 config/Tools.mk.in | 2 --
 1 file changed, 2 deletions(-)

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 2d6c440324..4cc9f29090 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -20,8 +20,6 @@ BCC := @BCC@
 IASL:= @IASL@
 AWK := @AWK@
 FETCHER := @FETCHER@
-SEABIOS_PATH:= @seabios_path@
-OVMF_PATH   := @ovmf_path@
 
 # Extra folder for libs/includes
 PREPEND_INCLUDES:= @PREPEND_INCLUDES@
-- 
2.11.0


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

Re: [Xen-devel] [PATCH] Revert xen: dont fiddle with event channel masking in suspend/resume

[Anchal Agarwal]

O Fri, Apr 20, 2018 at 07:43:31AM +0200, Juergen Gross wrote:
> On 20/04/18 01:04, Anchal Agarwal wrote:
> > 
> > Hello,
> > 
> > This patch reverts commit e91b2b1194335ca83d8a40fa4e0efd480bf2babe.
> > evtchn are supposed to be masked during resume by irq subsytem 
> > however, they are not. This causes special interrupts like PV 
> > spinlock to cause kernel BUG() as it expects the IRQ to be 
> > masked. This causes instances that are live migrated successfully 
> > to crash after few minutes.
> > 
> > Live Migration uses suspend resume and when xen_irq_resume is invoked, 
> > I saw event channels are not masked. Hence, I reverted this
> > commit to make LM work. Feelings? Recommendations? Things I missed?
> 
> The commit you are reverting was meant to repair suspend/resume handling
> for Xen. Instead of just reverting it the correct thing to do would be
> to find the reason why some event channels are not being masked and
> address that issue.
> 
> See https://lists.xen.org/archives/html/xen-devel/2017-07/msg00898.html
> 
> 
> Juergen
>

Hi Juergen,
The discussion you pointed out suggests to set a flag 
IRQCHIP_MASK_ON_SUSPEND(by tglx@) 
on device irq_chip for non-wakeup interrupts or even a generic flag as 
suggested by you 
on device irq_chip however, in this case I am experiencing issues with spinlock 
ipi handling 
and according to the xen code IPIs are not supposed to be masked during suspend 
resume. 
Hence, even if I set this flag on xen's per_cpu irq_chip, the flag 
IRQF_NO_SUSPEND is being 
set on binding ipi to irq handler in spinlock init code (xen_init_lock_cpu 
->bind_ipi_to_irqhandler)
and dummy handler assigned is throwing out BUG() if it's called at all. Once 
this flag is
set suspend_device_irq will not disable the irq and hence event channel is not 
masked.
Now on xen_irq_resume, during restore_cpu_ipis-> xen_irq_info_ipi_setup, in 
case of 
2 level ABI event channel handling (The issue is on xen 4.2), the port setup is 
a no-op 
however, while using fifo event channel it starts the setup with all event 
channels masked.
Hence if I revert the patch and mask everything in the beginning of 
xen_irq_resume, I don't see the issue.
To avoid this issue I can think of two things:
1. Revert the patch as mentioned before
2. Not to call BUG() in dummy_handler in spinlock code. Rather use 
xen_reschedule_interrupt and not 
the dummy_handler as was changed in commit d5de8841355a4. Moreover, it's not 
very much clear 
from the commit message why it was changed in the first place.

Any thoughts/suggestions?

Thanks,
Anchal
> > 
> > One such stack:
> >  [ cut here ]
> >  kernel BUG at arch/x86/xen/spinlock.c:75!
> >  CPU: 0 PID: 675 Comm: kauditd Not tainted 4.14.20-48.30.amzn2.x86_64 #1
> >  Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006
> >  task: 880205eedac0 task.stack: c9e4c000
> >  RIP: 0010:dummy_handler+0x0/0x10
> >  RSP: 0018:880207203eb8 EFLAGS: 00010046
> >  RAX: 81027f10 RBX: 880206ce1b00 RCX: 0035
> >  RDX: 81a81560 RSI:  RDI: 0035
> >  RBP: 0035 R08: 880206800248 R09: 880206d03600
> >  R10:  R11: 0040 R12: 
> >  R13: 880207203f04 R14:  R15: 
> >  FS:  () GS:88020720() 
> >  knlGS:
> >  CS:  0010 DS:  ES:  CR0: 80050033
> >  CR2: 561cc8dbd2d0 CR3: 01e0a001 CR4: 001606f0
> >  Call Trace:
> >   
> >   __handle_irq_event_percpu+0x40/0x190
> >   handle_irq_event_percpu+0x30/0x70
> >   handle_percpu_irq+0x37/0x50
> >   generic_handle_irq+0x24/0x30
> >   evtchn_2l_handle_events+0x162/0x280
> >   __xen_evtchn_do_upcall+0x42/0x80
> >   xen_evtchn_do_upcall+0x27/0x40
> >   xen_hvm_callback_vector+0x98/0xa0
> >   
> >  RIP: 0010:finish_task_switch+0x7b/0x200
> >  RSP: 0018:c9e4fe08 EFLAGS: 0246 ORIG_RAX: ff0c
> >  RAX: 0001 RBX: 880205eedac0 RCX: 
> >  RDX:  RSI:  RDI: 8802072211c0
> >  RBP: c9e4fe30 R08: 00387606 R09: 
> >  R10:  R11: 0040 R12: 8802072211c0
> >  R13: 81e12480 R14: 880202e54c00 R15: 
> >   ? finish_task_switch+0x74/0x200
> >   __schedule+0x29c/0x8a0
> >   ? __wake_up_common_lock+0x89/0xc0
> >   ? kauditd_send_multicast_skb+0x90/0x90
> >   schedule+0x28/0x80
> >   kauditd_thread+0x177/0x220
> >   ? finish_wait+0x80/0x80
> >   ? auditd_reset+0x90/0x90
> >   kthread+0x11a/0x130
> >   ? kthread_create_on_node+0x70/0x70
> >   ? call_usermodehelper_exec_async+0x12a/0x160
> >   ret_from_fork+0x35/0x40
> >   RIP: dummy_handler+0x0/0x10 RSP: 880207203eb8
> > 
> > Signed-off-by: Anchal Agarwal 
> > Signed-off-by: Eduardo Valentin 
> > Reviewed-by: Frank van der Linden 

Re: [Xen-devel] [PATCH v2 3/3] xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages

[Anthony PERARD]

On Thu, May 10, 2018 at 10:15:18AM +0100, Paul Durrant wrote:
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c
> @@ -1239,13 +1239,41 @@ static void xen_wakeup_notifier(Notifier *notifier, 
> void *data)
>  
>  static int xen_map_ioreq_server(XenIOState *state)
>  {
> +void *addr = NULL;
> +xenforeignmemory_resource_handle *fres;
>  xen_pfn_t ioreq_pfn;
>  xen_pfn_t bufioreq_pfn;
>  evtchn_port_t bufioreq_evtchn;
>  int rc;
>  
> +/*
> + * Attempt to map using the resource API and fall back to normal
> + * foreign mapping if this is not supported.
> + */
> +QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_bufioreq != 0);
> +QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_ioreq(0) != 1);
> +fres = xenforeignmemory_map_resource(xen_fmem, xen_domid,
> + XENMEM_resource_ioreq_server,

XENMEM_resource_ioreq_server undeclared with Xen 4.10

> + state->ioservid, 0, 2,
> + ,
> + PROT_READ | PROT_WRITE, 0);
> +if (fres != NULL) {
> +trace_xen_map_resource_ioreq(state->ioservid, addr);
> +state->buffered_io_page = addr;
> +state->shared_page = addr + TARGET_PAGE_SIZE;
> +} else {
> +error_report("failed to map ioreq server resources: error %d 
> handle=%p",
> + errno, xen_xc);

Maybe printing the error message only when xenforeignmemory_map_resource
fails, would be better? i.e. after checking errno value.

> +if (errno != EOPNOTSUPP) {
> +return -1;
> +}
> +}
> +
>  rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
> -   _pfn, _pfn,
> +   (state->shared_page == NULL) ?
> +   _pfn : NULL,
> +   (state->buffered_io_page == NULL) ?
> +   _pfn : NULL,
> _evtchn);
>  if (rc < 0) {
>  error_report("failed to get ioreq server info: error %d handle=%p",
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 5f1402b494..d925751040 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -119,6 +119,20 @@ static inline int xendevicemodel_pin_memory_cacheattr(
>  return xc_domain_pin_memory_cacheattr(xen_xc, domid, start, end, type);
>  }
>  
> +typedef void xenforeignmemory_resource_handle;
> +
> +#define XENMEM_resource_ioreq_server_frame_bufioreq 0
> +#define XENMEM_resource_ioreq_server_frame_ioreq(n) (1 + (n))
> +
> +static inline xenforeignmemory_resource_handle 
> *xenforeignmemory_map_resource(
> +xenforeignmemory_handle *fmem, domid_t domid, unsigned int type,
> +unsigned int id, unsigned long frame, unsigned long nr_frames,
> +void **paddr, int prot, int flags)
> +{
> +errno = EOPNOTSUPP;

I think ENOSYS would be better. EOPNOTSUPP seems to be for sockets.


> +return -1;

Should this return NULL instead?  That doesn't build on Xen 4.10 and earlier.

> +}
> +
>  #endif /* CONFIG_XEN_CTRL_INTERFACE_VERSION < 41100 */
>  
>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH for-4.11 v4 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[Lars Kurth]

On 15/05/2018, 16:35, "Ian Jackson"  wrote:

Lars Kurth writes ("[PATCH for-4.11 v4 1/1] Add new add_maintainers.pl 
script to optimise the workflow when using git format-patch with 
get_maintainer.pl"):
> The tool covers step 2 of the following workflow

Thanks.  Sorry to spot this only now, but

> +sub writefile ($$) {
> +my ($content, $file) = @_;
> +my $fh;
> +open($fh, ">", $file)
> + or die "Could not open file '$file' $!";
> +print $fh $content or die $!;
> +close $fh or die $!;
> +}

this will lose data if your disk is full.

You want:

  sub writefile ($$) {
  my ($content, $file) = @_;
  my $fh;
  open($fh, ">", "$file.tmp")
   or die "Could not open file '$file.tmp' $!";
  print $fh $content or die $!;
  close $fh or die $!;
  ranem "$file.tmp", $file or die "Could not rename '$file' into place 
$!";
  }

(NB: untested.)

Aside from that,

Acked-by: Ian Jackson 

Do you want me to pick up my suggested change and test it ?

If you could do this, yes please
Lars


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

[Xen-devel] [PATCH v6] scripts/add_maintainers.pl: New script

[Ian Jackson]

From: Lars Kurth 

This provides a much better workflow when using git format-patch and
git send-email, with get_maintainer.pl.

The tool covers step 2 of the following workflow

  Step 1: git format-patch ... -o  ...
  Step 2: ./scripts/add_maintainers.pl -d 
  This overwrites  *.patch files in 
  Step 3: git send-email -to xen-devel@lists.xenproject.org /*.patchxm

I manually tested all options and the most common combinations
on Mac.

Changes since v1:
- Added RAB (indicated by Juergen on IRC that this is OK)
- Remove trailing whitespaces
- Renamed --prefix to --reroll-count
- Cleaned up short options -v, ... to be in line with git
- Added --tags|-t option to add AB, RAB and RB emails to CC list
- Added --insert|-i mode to allow for people adding CCs to commit message
  instead of the e-mail header (the header is the default)
- Moved common code into functions
- Added logic, such that the tool only insert's To: and Cc: statements
  which were not there before, allowing for running the tool multiple times
  on the same 

Changes since v2:
- Deleted --version and related infrastructure
- Added subroutine prototypes
- Removed AT and @lists declaration and used \@ in literals
- Changed usage message and options based on feedback
- Improved error handling
- Removed occurances of index() and replaced with regex
- Removed non-perl idioms
- Moved uniq statements to normalize and added info on what normalize does
- Read L: tags from MAINTAINERS file instead of using heuristic
- Fixed issues related to metacharacters in getmaintainers()
- Allow multiple -a | --arg values (because of this renamed --args)
- Identify tags via regex
- CC's from tags are only inserted in the mail header, never the body
- That is unless the new option --tagscc is used
- Added policy processing which includes reworking insert()
- Replaced -i|--insert with -p|--inspatch and -c|--inscover now using policies
- Added new policies to cover for all user requests
- Rewrote help message to center around usage of policies
- Reordered some code (e.g. help string first to make code more easily readable)

Changes since v3:
- Made help message clearer
- Replaced PROCESSING POLICY with LOCATION
- Renamed --inspatch (top|ccbody|cc---|none) | -p (top|ccbody|cc---|none)
  to --patchcc (header|commit|comment|none) | -p (header|commit|comment|none)
- Renamed --inscover (top|ccend|none) | -c (top|ccend|none)
  to --covercc (header|end|none) | -c (header|end|none)
- Renamed variables and functions in the code to match the options
- Changed $patch_prefix processing
- Changed search expression for identifying cover letters
- Renamed $readmailinglists to $getmailinglists_done
- Use array form of open
- More file error handling (using IO::Handle)
- Fixed buggy AND in if statement
- Removed check whether getmaintainers exists for future proofing
- Add logic to work out --reroll-count

Changes since v4:
- Strip some trailing whitespace from the code
- writefile() now uses the .tmp-and-rename pattern to avoid data loss
- Provide --get-maintainers= option to specify replacement for
  get_maintainers.pl.  This is useful for Ian's usecase, since it
  allows --get-maintainers=true, to avoid adding any MAINTAINERS-based
  info anywhere while still adding other CCs (eg from -t) everywhere.
- Refactor normalize() somewhat so that it uses only %seen, and
  does not any longer modify its argument arrays.
- De-dupe case-insensitively (by making normalize use lc).

Changes since v5:
- Add mention of --get-maintainers, and its best use case, to --help
  output.  (Move $get_maintainer up so that it can be used here.)

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 
Signed-off-by: Lars Kurth 
Release-acked-by: Juergen Gross 
Signed-off-by: Ian Jackson 
Acked-by: Lars Kurth 
---
 scripts/add_maintainers.pl | 555 +
 1 file changed, 555 insertions(+)
 create mode 100755 scripts/add_maintainers.pl

diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
new file mode 100755
index 000..99e4724
--- /dev/null
+++ b/scripts/add_maintainers.pl
@@ -0,0 +1,555 @@
+#!/usr/bin/perl -w
+# (c) 2018, Lars Kurth 
+#
+# Add maintainers to patches generated with git format-patch
+#
+# Usage: perl scripts/add_maintainers.pl [OPTIONS] -patchdir 
+#
+# Prerequisites: Execute
+#git format-patch ... -o  ...
+#
+#./scripts/get_maintainer.pl is present in the tree
+#
+# Licensed under the terms of the GNU GPL License version 2
+
+use strict;
+

Re: [Xen-devel] [PATCH v5] scripts/add_maintainers.pl: New script

[Ian Jackson]

Lars Kurth writes ("Re: [PATCH v5] scripts/add_maintainers.pl: New script"):
> Acked-by: Lars Kurth 
> Although it should probably mention --get-maintainers in the help message

Good point.

Ian.

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

[Xen-devel] Ping: Re: [PATCH] x86: correct vCPU dirty CPU handling

[Jan Beulich]

>>> On 26.04.18 at 12:52,  wrote:
 On 26.04.18 at 11:51,  wrote:
>> On 26/04/18 10:41, Jan Beulich wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -1202,11 +1202,23 @@ void put_page_from_l1e(l1_pgentry_t l1e,
>>>   unlikely(((page->u.inuse.type_info & PGT_count_mask) != 0)) &&
>>>   (l1e_owner == pg_owner) )
>>>  {
>>> +cpumask_t *mask = this_cpu(scratch_cpumask);
>>> +
>>> +cpumask_clear(mask);
>>> +
>>>  for_each_vcpu ( pg_owner, v )
>>>  {
>>> -if ( pv_destroy_ldt(v) )
>>> -flush_tlb_mask(cpumask_of(v->dirty_cpu));
>>> +unsigned int cpu;
>>> +
>>> +if ( !pv_destroy_ldt(v) )
>>> +continue;
>>> +cpu = read_atomic(>dirty_cpu);
>>> +if ( is_vcpu_dirty_cpu(cpu) )
>>> +__cpumask_set_cpu(cpu, mask);
>>>  }
>>> +
>>> +if ( !cpumask_empty(mask) )
>>> +flush_tlb_mask(mask);
>> 
>> Thinking about this, what is wrong with:
>> 
>> bool flush;
>> 
>> for_each_vcpu ( pg_owner, v )
>> if ( pv_destroy_ldt(v) )
>> flush = true;
>> 
>> if ( flush )
>>flush_tlb_mask(pg_owner->dirty_cpumask);
>> 
>> This is far less complicated cpumask handling.  As the loop may be long,
>> it avoids flushing pcpus which have subsequently switched away from
>> pg_owner context.  It also avoids all playing with v->dirty_cpu.
> 
> That would look to be correct, but I'm not sure it would be an improvement:
> While it may avoid flushing some CPUs, it may then do extra flushes on
> others (which another vCPU of the domain has been switched to). Plus it
> would flush even those CPUs where pv_destroy_ldt() has returned false,
> as long as the function returned true at least once.

Ping?

> If I was to go that route, I'd at least extend to latching
> pg_owner->dirty_cpumask before the loop into scratch_cpumask, ANDing
> in pg_owner->dirty_cpumask after the loop to restrict to those CPUs which
> may have remained active over the entire time the loop takes. But even
> then I would still be afraid of flushing far more CPUs than actually needed.

I don't think anymore that this would be correct, so please ignore this
part.

Thanks, Jan



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

Re: [Xen-devel] [PATCH 5/5] docs/pvh: document initial MTRR state

[Wei Liu]

On Tue, May 15, 2018 at 01:51:03AM -0600, Jan Beulich wrote:
> >>> On 14.05.18 at 18:18,  wrote:
> > On Mon, May 14, 2018 at 10:13:47AM -0600, Jan Beulich wrote:
> >> >>> On 14.05.18 at 18:03,  wrote:
> >> > On Thu, May 10, 2018 at 06:15:05PM +0100, Roger Pau Monne wrote:
> >> >> --- a/docs/misc/pvh.markdown
> >> >> +++ b/docs/misc/pvh.markdown
> >> >> @@ -92,3 +92,18 @@ event channels. Delivery of those interrupts can be 
> >> >> configured in the same way
> >> >>  as HVM guests, check xen/include/public/hvm/params.h and
> >> >>  xen/include/public/hvm/hvm\_op.h for more information about available 
> >> >> delivery
> >> >>  methods.
> >> >> +
> >> >> +## MTRR ##
> >> >> +
> >> >> +### Unprivileged guests ###
> >> >> +
> >> >> +PVH guests are booted with the default MTRR type set to write-back and 
> >> >> MTRR
> >> >> +enabled. This allows DomUs to start with a sane MTRR state. Note that 
> >> >> this will
> >> >> +have to be revisited when pci-passthrough is added to PVH in order to 
> >> >> set MMIO
> >> >> +regions as UC.
> >> > 
> >> > My reading is "revisited" implies the default type will change. In fact
> >> > it shouldn't. We should clarify: for ram it will remain WB, for MMIO
> >> > holes it will be UC.
> >> 
> >> Why would changing the default late be a problem? A firmware update on
> >> bare hardware might also have such an effect. The default type read from
> >> the MSR must not change across the lifetime of a VM, but imo may change
> >> across reboots of it.
> >> 
> > 
> > Then setting a default here doesn't really help OS developers because
> > they will always need to write code to set the correct type -- not that
> > this is a big issue, but as I understand it the point here is to avoid
> > that.
> 
> Hmm, my understanding of the purpose of the series was that it aims at
> establishing some sane (i.e. reasonable for an OS to expect) state, instead
> of a firm "this will always be this way" one. Furthermore OSes generally
> shouldn't find a need to fiddle with MTRRs, provided firmware has done a
> proper job setting them up.

AIUI this series is the result of discussion of  [PATCH v2 1/3] xen/pvh:
enable and set default MTRR type.

It appears because the default is not sane, other pieces of software
(hvmloader, ovmf, now PVH kernel) have to set it again and again and
again.

Fundamentally I don't think we disagree with each other. If we go with
Roger's suggestion in the other sub-thread, we can ensure sane types for
RAM and MMIO and avoid debating here at all.

Wei.

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

Re: [Xen-devel] [PATCH 5/5] docs/pvh: document initial MTRR state

[Roger Pau Monné]

On Tue, May 15, 2018 at 01:51:03AM -0600, Jan Beulich wrote:
> >>> On 14.05.18 at 18:18,  wrote:
> > On Mon, May 14, 2018 at 10:13:47AM -0600, Jan Beulich wrote:
> >> >>> On 14.05.18 at 18:03,  wrote:
> >> > On Thu, May 10, 2018 at 06:15:05PM +0100, Roger Pau Monne wrote:
> >> >> --- a/docs/misc/pvh.markdown
> >> >> +++ b/docs/misc/pvh.markdown
> >> >> @@ -92,3 +92,18 @@ event channels. Delivery of those interrupts can be 
> >> >> configured in the same way
> >> >>  as HVM guests, check xen/include/public/hvm/params.h and
> >> >>  xen/include/public/hvm/hvm\_op.h for more information about available 
> >> >> delivery
> >> >>  methods.
> >> >> +
> >> >> +## MTRR ##
> >> >> +
> >> >> +### Unprivileged guests ###
> >> >> +
> >> >> +PVH guests are booted with the default MTRR type set to write-back and 
> >> >> MTRR
> >> >> +enabled. This allows DomUs to start with a sane MTRR state. Note that 
> >> >> this will
> >> >> +have to be revisited when pci-passthrough is added to PVH in order to 
> >> >> set MMIO
> >> >> +regions as UC.
> >> > 
> >> > My reading is "revisited" implies the default type will change. In fact
> >> > it shouldn't. We should clarify: for ram it will remain WB, for MMIO
> >> > holes it will be UC.
> >> 
> >> Why would changing the default late be a problem? A firmware update on
> >> bare hardware might also have such an effect. The default type read from
> >> the MSR must not change across the lifetime of a VM, but imo may change
> >> across reboots of it.
> >> 
> > 
> > Then setting a default here doesn't really help OS developers because
> > they will always need to write code to set the correct type -- not that
> > this is a big issue, but as I understand it the point here is to avoid
> > that.
> 
> Hmm, my understanding of the purpose of the series was that it aims at
> establishing some sane (i.e. reasonable for an OS to expect) state, instead
> of a firm "this will always be this way" one. Furthermore OSes generally
> shouldn't find a need to fiddle with MTRRs, provided firmware has done a
> proper job setting them up.

Indeed that's the purpose. Most OSes don't really care about the
details of the MTRR setup, and they just expect RAM regions to be set
to WB and MMIO holes to UC AFAICT.

I don't think Xen has to provide any guarantee about the details of
the MTRR state, apart from stating that RAM will be WB and MMIO UC.

I can leave the text as-is, or add the paragraph suggested in another
email to clarify if the current writing is prone to misunderstanding.

Roger.

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

Re: [Xen-devel] [PATCH 3/5] hvm/mtrr: copy hardware state for Dom0

[Roger Pau Monné]

On Tue, May 15, 2018 at 01:52:43AM -0600, Jan Beulich wrote:
> >>> On 14.05.18 at 18:33,  wrote:
> > On Mon, May 14, 2018 at 08:26:30AM -0600, Jan Beulich wrote:
> >> >>> On 10.05.18 at 19:15,  wrote:
> >> > Copy the state found on the hardware when creating a PVH Dom0. Since
> >> > the memory map provided to a PVH Dom0 is based on the native one using
> >> > the same set of MTRR ranges should provide Dom0 with a sane MTRR state
> >> > without having to manually build it in Xen.
> >> > 
> >> > Signed-off-by: Roger Pau Monné 
> >> > ---
> >> > Cc: Jan Beulich 
> >> > Cc: Andrew Cooper 
> >> > ---
> >> >  xen/arch/x86/hvm/mtrr.c | 23 +++
> >> >  1 file changed, 23 insertions(+)
> >> > 
> >> > diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
> >> > index 95a3deabea..1cb000388a 100644
> >> > --- a/xen/arch/x86/hvm/mtrr.c
> >> > +++ b/xen/arch/x86/hvm/mtrr.c
> >> > @@ -176,6 +176,29 @@ int hvm_vcpu_cacheattr_init(struct vcpu *v)
> >> >  ((uint64_t)PAT_TYPE_UC_MINUS << 48) |   /* PAT6: UC- */
> >> >  ((uint64_t)PAT_TYPE_UNCACHABLE << 56);  /* PAT7: UC */
> >> >  
> >> > +if ( is_hardware_domain(v->domain) )
> >> > +{
> >> > +/* Copy values from the host. */
> >> > +struct domain *d = v->domain;
> >> > +unsigned int i;
> >> > +
> >> > +if ( mtrr_state.have_fixed )
> >> > +for ( i = 0; i < NUM_FIXED_MSR; i++ )
> >> > +mtrr_fix_range_msr_set(d, m, i,
> >> > +  ((uint64_t 
> >> > *)mtrr_state.fixed_ranges)[i]);
> >> 
> >> The presence/absence of fixed range MTRRs needs to be reflected in the
> >> capabilities MSR. Strictly speaking in their absence MSR access attempts to
> >> the fixed range MSRs should also cause #GP, as should any attempt to
> >> enable them in defType.
> > 
> > My intention was to always provide the fixed range MTRR capability,
> > regardless of whether the underlying hardware has it or not. Then of
> > course fixed ranges won't be enabled by default in the deftype MSR if
> > the underlying hardware also hasn't got them enabled.
> 
> What would the result be of the OS writing to any of these MSRs, or
> setting the respective enable bit?

Likely the cache attributes for the guest will change if it sets some
fixed ranges and enables the FE bit. But I'm not sure why is that a
problem.

If a guest plays with the MTRR ranges it must know what it's doing
anyway, and the fact that the underlying hardware has fixed range
support or not doesn't affect the changes that the guest might be
trying to perform to it's virtual MTRR registers/state.

Likewise the guest could change the variable ranges and mess up with
the types, but that's just going to affect the guest cache attributes,
not the host (Xen) ones.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 2/4] libxc: Provide access to internal handles

[Wei Liu]

On Mon, May 14, 2018 at 06:08:57PM +0100, Ian Jackson wrote:
> In order to support auditing of qemu depriv, my audit tool wants to
> know the fd of a privcmd handle on which it can easily make
> hypercalls.  xencall provides such a handle, but has no cooked
> facilities for making hypercalls.  So I open a libxc handle.  That
> means I need to get the privcmd fd out of the libxc handle.
> 
> ISTM that it is best to do this by providing an interface to get the
> underlying library handles for a libxc handle.  This kind of interface
> is quite common elsewhere and has not caused problems.
> 
> libxc is not a stable API so the downside risk of providing this
> access is not significant.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH v1 for 4.7] x86/cpuid: fix raw FEATURESET_7d0 reporting

[Sergey Dyasli]

Commit 62b1879693e0 ("x86: further CPUID handling adjustments") added
FEATURESET_7d0 reporting but forgot to update calculate_raw_featureset()
function. As result, the value reported by xen-cpuid contains 0.

Fix that by properly filling raw_featureset[FEATURESET_7d0].

Signed-off-by: Sergey Dyasli 
---
I see that at least 4.8 also contains this bug, so other releases also
need checking.

CC: Jan Beulich 
CC: Andrew Cooper 
---
 xen/arch/x86/cpuid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 451952cabe..fffcecd878 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -113,7 +113,7 @@ static void __init calculate_raw_featureset(void)
 cpuid_count(0x7, 0, ,
 _featureset[FEATURESET_7b0],
 _featureset[FEATURESET_7c0],
-);
+_featureset[FEATURESET_7d0]);
 if ( max >= 0xd )
 cpuid_count(0xd, 1,
 _featureset[FEATURESET_Da1],
-- 
2.17.0


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