[Xen-devel] [PATCH 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

[Andrew Cooper]

PoD is supposed to be entirely transparent to guest, but this interface has
been left exposed for a long time.

The use of PoD requires careful co-ordination by the toolstack with the
XENMEM_{get,set}_pod_target hypercalls, and xenstore ballooning target.  The
best a guest can do without toolstack cooperation crash.

Furthermore, there are combinations of features (e.g. c/s c63868ff "libxl:
disallow PCI device assignment for HVM guest when PoD is enabled") which a
toolstack might wish to explicitly prohibit (in this case, because the two
simply don't function in combination).  In such cases, the guest mustn't be
able to subvert the configuration chosen by the toolstack.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: George Dunlap 
---
 xen/common/memory.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 1ead35c..ccb9207 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -903,7 +903,16 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 
 if ( op == XENMEM_populate_physmap
  && (reservation.mem_flags & XENMEMF_populate_on_demand) )
+{
+/* Disallow populating PoD pages on oneself. */
+if ( d == curr_d )
+{
+rcu_unlock_domain(d);
+return start_extent;
+}
+
 args.memflags |= MEMF_populate_on_demand;
+}
 
 if ( xsm_memory_adjust_reservation(XSM_TARGET, curr_d, d) )
 {
-- 
2.1.4


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

[Xen-devel] [PATCH 1/2] xen/memop: Latch current->domain in a local variable

[Andrew Cooper]

It is more efficient.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: George Dunlap 
---
 xen/common/memory.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 812334b..1ead35c 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -864,7 +864,7 @@ static long xatp_permission_check(struct domain *d, 
unsigned int space)
 
 long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
-struct domain *d;
+struct domain *d, *curr_d = current->domain;
 long rc;
 struct xen_memory_reservation reservation;
 struct memop_args args;
@@ -905,7 +905,7 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
  && (reservation.mem_flags & XENMEMF_populate_on_demand) )
 args.memflags |= MEMF_populate_on_demand;
 
-if ( xsm_memory_adjust_reservation(XSM_TARGET, current->domain, d) )
+if ( xsm_memory_adjust_reservation(XSM_TARGET, curr_d, d) )
 {
 rcu_unlock_domain(d);
 return start_extent;
@@ -962,7 +962,7 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( d == NULL )
 return -ESRCH;
 
-rc = xsm_memory_stat_reservation(XSM_TARGET, current->domain, d);
+rc = xsm_memory_stat_reservation(XSM_TARGET, curr_d, d);
 if ( rc )
 {
 rcu_unlock_domain(d);
@@ -1086,7 +1086,7 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( d == NULL )
 return -ESRCH;
 
-rc = xsm_remove_from_physmap(XSM_TARGET, current->domain, d);
+rc = xsm_remove_from_physmap(XSM_TARGET, curr_d, d);
 if ( rc )
 {
 rcu_unlock_domain(d);
-- 
2.1.4


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

Re: [Xen-devel] unable start xen in hikey

[Julien Grall]

Hello,

On 18/08/16 22:44, Kamenee Arumugam wrote:

Please avoid to top-post on the mailing list.


Yes, I did try "make dtbs" too, but no difference and it doesn't
generate .dtb file. here is the cmd I used:

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image  dtbs


The hikey device tree will only built if you have CONFIG_ARCH_HISI 
enabled in your .config. Can you check if it is the case?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/2] xen: credit1: fix a race when picking initial pCPU for a vCPU

[Dario Faggioli]

On Fri, 2016-08-19 at 13:23 +0100, George Dunlap wrote:
> On 18/08/16 11:00, Dario Faggioli wrote:
> > @@ -248,6 +245,33 @@ __runq_elem(struct list_head *elem)
> >  return list_entry(elem, struct csched_vcpu, runq_elem);
> >  }
> >  
> > +/* Is the first element of cpu's runq (if any) cpu's idle vcpu? */
> > +static inline bool_t is_runq_idle(unsigned int cpu)
> > +{
> > +/*
> > + * If we are on cpu, and we are peeking at our own runq while
> > cpu itself
> > + * is not idle, that's fine even if we don't hold the runq
> > lock. In fact,
> > + * the fact that there is a (non idle!) vcpu running means
> > that at least
> > + * the idle vcpu is in the runq. And since only cpu itself
> > (via work
> > + * stealing) can add stuff to the runq, and no other cpu will
> > ever steal
> > + * our idle vcpu, that maks the runq manipulations done below
> > safe, even
> > + * without locks.
> Thanks for investigating this and figuring out why the lockless
> access
> hasn't caused a problem before.  But relying on this behavior going
> forward doesn't really seem like a great idea if we can avoid it.
> 
I totally agree.

> We can't grab the pcpu scheduler lock in csched_tick(), or in the
> whole
> of csched_vcpu_acct() because we grab the private lock in
> __csched_vcpu_acct_start() (and that violates the locking
> order).  But
> is there a reason we can't grab the pcpu lock just around the call to
> _csched_cpu_pick?
> 
The first version of this patch, here in my stgit patchqueue, looked
exactly like that. ISTR I even tested it, and it works.

Then I thought that, since in this case it's all about making an
ASSERT() happy, it may be a good thing to avoid introducing more
contention. Also, I see your point on robustness/reliability. My view
is that locking on this path (if not on Credit1 in general) is already
so bad, that I don't think it's possible to make it any worse (and
hence wans't feeling guilty about taking going the way I did). :-)

*BUT* I don't have a too strong opinion, and if you prefer 'take lock'
approach, I'm fine with that.

I'll send v3.

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



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

Re: [Xen-devel] unable start xen in hikey

[Julien Grall]

Hello,

On 18/08/16 22:11, Kamenee Arumugam wrote:

I am using linux kernel from 96 boards repo:
 https://github.com/96boards/linux.git
 and I compile using this command
as below:

make Image -j24 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts


What is your .config? Have you enabled the related option for XEN?

Below a list of Xen specific options I have enabled in my kernel:

CONFIG_XEN_DOM0=y
CONFIG_XEN=y
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_GRANT_DEV_ALLOC=y
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PRIVCMD=y
CONFIG_XEN_EFI=y
CONFIG_XEN_AUTO_XLATE=y

Regards,

--
Julien Grall

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

Re: [Xen-devel] unable start xen in hikey

[Julien Grall]

Hello,

On 18/08/16 16:50, Chenxiao Zhao wrote:

Please avoid top-posting on the mailing list.


It seems that you are using a dtb file that is not compatible with XEN
hypervisor on hikey. I strongly suggest you compile the kernel from
source in 96boards's repository. When you compile the kernel it will
compile the dtb from dts as well.


It would be good to have the wiki page [1] updated in this case.

Regards,

[1] https://wiki.xenproject.org/wiki/HiKey

--
Julien Grall

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

[Xen-devel] [PATCH v2] x86/PV: don't wrongly hide/expose CPUID.OSXSAVE from/to user mode

[Jan Beulich]

User mode code generally cannot be expected to invoke the PV-enabled
CPUID Xen supports, and prior to the CPUID levelling changes for 4.7
(as well as even nowadays on levelling incapable hardware) such CPUID
invocations actually saw the host CR4.OSXSAVE value, whereas prior to
this patch
- on Intel guest user mode always saw the flag clear,
- on AMD guest user mode saw the flag set even when the guest kernel
  didn't enable use of XSAVE/XRSTOR.
Fold in the guest view of CR4.OSXSAVE when setting the levelling MSRs,
just like we do in other CPUID handling.

To make guest CR4 changes immediately visible via CPUID, also invoke
ctxt_switch_levelling() from the CR4 write path.

Signed-off-by: Jan Beulich 
---
v2: Invert operation on AMD (from OR-ing in to AND-ing out), adjust
title, and extend description.

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -206,17 +206,30 @@ static void __init noinline probe_maskin
 static void amd_ctxt_switch_levelling(const struct domain *nextd)
 {
struct cpuidmasks *these_masks = _cpu(cpuidmasks);
-   const struct cpuidmasks *masks =
-   (nextd && is_pv_domain(nextd) && 
nextd->arch.pv_domain.cpuidmasks)
-   ? nextd->arch.pv_domain.cpuidmasks : _defaults;
+   const struct cpuidmasks *masks = NULL;
+   unsigned long cr4;
+   uint64_t val__1cd = 0, val_e1cd = 0, val__7ab0 = 0, val__6c = 0;
+
+   if (nextd && is_pv_domain(nextd) && !is_idle_domain(nextd)) {
+   cr4 = current->arch.pv_vcpu.ctrlreg[4];
+   masks = nextd->arch.pv_domain.cpuidmasks;
+   } else
+   cr4 = read_cr4();
+
+   if (!(cr4 & X86_CR4_OSXSAVE))
+   val__1cd |= (uint64_t)cpufeat_mask(X86_FEATURE_OSXSAVE) << 32;
+
+   if (!masks)
+   masks = _defaults;
 
 #define LAZY(cap, msr, field)  \
({  \
-   if (unlikely(these_masks->field != masks->field) && \
+   val_##field = ~val_##field & masks->field;  
\
+   if (unlikely(these_masks->field != val_##field) &&  \
((levelling_caps & cap) == cap))\
{   \
-   wrmsr_amd(msr, masks->field);   \
-   these_masks->field = masks->field;  \
+   wrmsr_amd(msr, val_##field);\
+   these_masks->field = val_##field;   \
}   \
})
 
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -154,7 +154,9 @@ static void __init probe_masking_msrs(vo
 static void intel_ctxt_switch_levelling(const struct domain *nextd)
 {
struct cpuidmasks *these_masks = _cpu(cpuidmasks);
-   const struct cpuidmasks *masks;
+   const struct cpuidmasks *masks = NULL;
+   unsigned long cr4;
+   uint64_t val__1cd = 0, val_e1cd = 0, val_Da1 = 0;
 
if (cpu_has_cpuid_faulting) {
/*
@@ -178,16 +180,27 @@ static void intel_ctxt_switch_levelling(
return;
}
 
-   masks = (nextd && is_pv_domain(nextd) && 
nextd->arch.pv_domain.cpuidmasks)
-   ? nextd->arch.pv_domain.cpuidmasks : _defaults;
+   if (nextd && is_pv_domain(nextd) && !is_idle_domain(nextd)) {
+   cr4 = current->arch.pv_vcpu.ctrlreg[4];
+   masks = nextd->arch.pv_domain.cpuidmasks;
+   } else
+   cr4 = read_cr4();
+
+   /* OSXSAVE cleared by pv_featureset.  Fast-forward CR4 back in. */
+   if (cr4 & X86_CR4_OSXSAVE)
+   val__1cd |= cpufeat_mask(X86_FEATURE_OSXSAVE);
+
+   if (!masks)
+   masks = _defaults;
 
 #define LAZY(msr, field)   \
({  \
-   if (unlikely(these_masks->field != masks->field) && \
+   val_##field |= masks->field;\
+   if (unlikely(these_masks->field != val_##field) &&  \
(msr))  \
{   \
-   wrmsrl((msr), masks->field);\
-   these_masks->field = masks->field;  \
+   wrmsrl((msr), val_##field); \
+   these_masks->field = val_##field;   \
}   \
})
 
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2733,6 +2733,7 @@ static int emulate_privileged_op(struct
 case 4: /* Write CR4 */
 

[Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Euler)]

>From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
From: Quan Xu 
Date: Fri, 19 Aug 2016 20:40:31 +0800
Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest
with high payload (with 2vCPU, captured from xentrace, in high payload, the
count of IPI interrupt increases rapidly between these vCPUs).

If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
are both pending (index of bit set in VIRR), unfortunately, the IPI intrrupt
is high priority than periodic timer interrupt. Xen updates IPI interrupt bit
set in VIRR to guest interrupt status (RVI) as a high priority and apicv
(Virtual-Interrupt Delivery) delivers IPI interrupt within VMX non-root
operation without a VM exit. Within VMX non-root operation, if periodic timer
interrupt index of bit is set in VIRR and highest, the apicv delivers periodic
timer interrupt within VMX non-root operation as well.

But in current code, if Xen doesn't update periodic timer interrupt bit set
in VIRR to guest interrupt status (RVI) directly, Xen is not aware of this
case to decrease the count (pending_intr_nr) of pending periodic timer 
interrupt,
then Xen will deliver a periodic timer interrupt again. The guest receives more
periodic timer interrupt.

If the periodic timer interrut is delivered and not the highest priority, make
Xen be aware of this case to decrease the count of pending periodic timer
interrupt.

Signed-off-by: Yifei Jiang 
Signed-off-by: Rongguang He 
Signed-off-by: Quan Xu 
---
Why RFC:
1. I am not quite sure for other cases, such as nested case.
2. Within VMX non-root operation, an Asynchronous Enclave Exit (including 
external
   interrupts, non-maskable interrupt system-management interrrupts, exceptions
   and VM exit) may occur before delivery of a periodic timer interrupt, the 
periodic
   timer interrupt may be lost when a coming periodic timer interrupt is 
delivered.
   Actually, and so current code is.
---
 xen/arch/x86/hvm/vmx/intr.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index 8fca08c..d3a034e 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -334,7 +334,21 @@ void vmx_intr_assist(void)
 __vmwrite(EOI_EXIT_BITMAP(i), v->arch.hvm_vmx.eoi_exit_bitmap[i]);
 }

-pt_intr_post(v, intack);
+   /*
+* If the periodic timer interrut is delivered and not the highest 
priority,
+* make Xen be aware of this case to decrease the count of pending 
periodic
+* timer interrupt.
+*/
+if ( pt_vector != -1 && intack.vector > pt_vector )
+{
+struct hvm_intack pt_intack;
+
+pt_intack.vector = pt_vector;
+pt_intack.source = hvm_intsrc_lapic;
+pt_intr_post(v, pt_intack);
+}
+else
+pt_intr_post(v, intack);
 }
 else
 {
--
1.7.12.4


0001-x86-apicv-fix-RTC-periodic-timer-and-apicv-issue.patch
Description: 0001-x86-apicv-fix-RTC-periodic-timer-and-apicv-issue.patch
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/3] x86/EFI: don't accept 64-bit base relocations on page tables

[Jan Beulich]

>>> On 19.08.16 at 14:39,  wrote:
> On 19/08/16 08:52, Jan Beulich wrote:
>> Page tables get pre-populated with physical addresses which, due to
>> living inside the Xen image, will never exceed 32 bits in width. That
>> in turn results in the tool generating the relocations to produce
>> 32-bit relocations for them instead of the 64-bit ones needed for
>> relocating virtual addresses. Hence instead of special casing page
>> tables in the processing of 64-bit relocations, let's be more rigid
>> and refuse them (as being indicative of something else having gone
>> wrong in the build process).
>>
>> Signed-off-by: Jan Beulich 
> 
> Is it an ABI requirement to use the minimal available relocation?  It is
> certainly suboptimal to use a 64bit relocation when a 32bit one would
> do, but I wouldn't bet that it is unconditional avoided by all toolchains.

What ABI? The tool in question is one of our own making. And the
way relocations get generated it's hard to tell those that have to
be 32-bit (in early boot code and trampoline code) from those that
may as well be 64-bit ones (in page tables).

> It is currently the case that Xen needs to live below 4GB physical, so
> from that point of view a 64bit relocation will not be required in the
> pagetables.

And even if Xen didn't itself have this requirement, the EFI loader
would always put us below 4Gb.

Jan


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

Re: [Xen-devel] [PATCH v2 2/2] xen: credit1: no need to check for is_idle_vcpu() in csched_vcpu_acct()

[George Dunlap]

On 18/08/16 11:00, Dario Faggioli wrote:
> In fact, csched_vcpu_acct() is called by csched_tick()
> _only_ on non idle vcpus already.
> 
> There's even an ASSERT() already in place at the top
> of it which, by checking that svc->sdom is not NULL,
> guarantees that the function is not being called on
> the idle domain.
> 
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 


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

Re: [Xen-devel] [PATCH 3/3] x86/EFI: don't accept 64-bit base relocations on page tables

[Andrew Cooper]

On 19/08/16 08:52, Jan Beulich wrote:
> Page tables get pre-populated with physical addresses which, due to
> living inside the Xen image, will never exceed 32 bits in width. That
> in turn results in the tool generating the relocations to produce
> 32-bit relocations for them instead of the 64-bit ones needed for
> relocating virtual addresses. Hence instead of special casing page
> tables in the processing of 64-bit relocations, let's be more rigid
> and refuse them (as being indicative of something else having gone
> wrong in the build process).
>
> Signed-off-by: Jan Beulich 

Is it an ABI requirement to use the minimal available relocation?  It is
certainly suboptimal to use a 64bit relocation when a 32bit one would
do, but I wouldn't bet that it is unconditional avoided by all toolchains.

It is currently the case that Xen needs to live below 4GB physical, so
from that point of view a 64bit relocation will not be required in the
pagetables.

~Andrew

>
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -81,12 +81,9 @@ static void __init efi_arch_relocate_ima
>  }
>  break;
>  case PE_BASE_RELOC_DIR64:
> -if ( delta )
> -{
> -*(u64 *)addr += delta;
> -if ( in_page_tables(addr) )
> -*(intpte_t *)addr += xen_phys_start;
> -}
> +if ( in_page_tables(addr) )
> +blexit(L"Unexpected relocation type");
> +*(u64 *)addr += delta;
>  break;
>  default:
>  blexit(L"Unsupported relocation type");
>
>
>
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v2 1/2] xen: credit1: fix a race when picking initial pCPU for a vCPU

[George Dunlap]

On 18/08/16 11:00, Dario Faggioli wrote:
> In the Credit1 hunk of 9f358ddd69463 ("xen: Have
> schedulers revise initial placement") csched_cpu_pick()
> is called without taking the runqueue lock of the
> (temporary) pCPU that the vCPU has been assigned to
> (e.g., in XEN_DOMCTL_max_vcpus).
> 
> However, although 'hidden' in the IS_RUNQ_IDLE() macro,
> that function does access the runq (for doing load
> balancing calculations). Two scenarios are possible:
>  1) we are on cpu X, and IS_RUNQ_IDLE() peeks at cpu's
> X own runq;
>  2) we are on cpu X, but IS_RUNQ_IDLE() peeks at some
> other cpu's runq.
> 
> Scenario 2) absolutely requies that the appropriate
> runq lock is taken. Scenario 1) works even without
> taking the cpu's own runq lock, and this is important
> for the case when _csched_pick_cpu() is called from
> csched_vcpu_acct() which in turn is called by
> csched_tick().


> 
> Races have been observed and reported (by both XenServer
> own testing and OSSTest [1]), in the form of
> IS_RUNQ_IDLE() falling over LIST_POISON, because we're
> not currently holding the proper lock, in
> csched_vcpu_insert(), when scenario 1) occurs.
> 
> Since this is all very tricky, in addition to fix things,
> add both an ASSERT() and a comment in IS_RUNQ_IDLE() (which
> is also becoming static inline instead of macro).
> 
> [1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg02144.html
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Andrew Cooper 
> Cc: Jan Beulich 
> ---
> Changes from v1:
>  - macro IS_RUNQ_IDLE() to static inline is_runq_idle(), as suggested
>during review;
>  - add an ASSERT() and a comment, as suggested during review;
>  - take into account what's described in the changelog as "scenario 1)",
>which wasn't being considered in v1.
> ---
>  xen/common/sched_credit.c |   38 +-
>  1 file changed, 33 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index 220ff0d..daace81 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -84,9 +84,6 @@
>  #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
>  #define CSCHED_DOM(_dom)((struct csched_dom *) (_dom)->sched_priv)
>  #define RUNQ(_cpu)  (&(CSCHED_PCPU(_cpu)->runq))
> -/* Is the first element of _cpu's runq its idle vcpu? */
> -#define IS_RUNQ_IDLE(_cpu)  (list_empty(RUNQ(_cpu)) || \
> - 
> is_idle_vcpu(__runq_elem(RUNQ(_cpu)->next)->vcpu))
>  
>  
>  /*
> @@ -248,6 +245,33 @@ __runq_elem(struct list_head *elem)
>  return list_entry(elem, struct csched_vcpu, runq_elem);
>  }
>  
> +/* Is the first element of cpu's runq (if any) cpu's idle vcpu? */
> +static inline bool_t is_runq_idle(unsigned int cpu)
> +{
> +/*
> + * If we are on cpu, and we are peeking at our own runq while cpu itself
> + * is not idle, that's fine even if we don't hold the runq lock. In fact,
> + * the fact that there is a (non idle!) vcpu running means that at least
> + * the idle vcpu is in the runq. And since only cpu itself (via work
> + * stealing) can add stuff to the runq, and no other cpu will ever steal
> + * our idle vcpu, that maks the runq manipulations done below safe, even
> + * without locks.

Thanks for investigating this and figuring out why the lockless access
hasn't caused a problem before.  But relying on this behavior going
forward doesn't really seem like a great idea if we can avoid it.

We can't grab the pcpu scheduler lock in csched_tick(), or in the whole
of csched_vcpu_acct() because we grab the private lock in
__csched_vcpu_acct_start() (and that violates the locking order).  But
is there a reason we can't grab the pcpu lock just around the call to
_csched_cpu_pick?

If not, we would then need to put a comment in the runq struct listing
the restrictions on access: namely, that nothing can be inserted from
other pcpus; and ideally a wrapper for all list modification operations
to ASSERT() that we're on the right pcpu.

 -George


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

Re: [Xen-devel] [PATCH 2/3] x86/EFI: be cautious about being handed control with CR4.PGE enabled

[Andrew Cooper]

On 19/08/16 08:51, Jan Beulich wrote:
> To effect proper TLB flushing in that case we should clear CR4.PGE
> before loading the new page tables.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64: head: Fill image size

[Peng Fan]

Hi Julien,

On Thu, Aug 18, 2016 at 05:02:01PM +0100, Julien Grall wrote:
>Hello Peng,
>
>On 16/08/16 03:58, Peng Fan wrote:
>>When booting xen from U-Boot, U-Boot will use the image size
>>info. Because this information is lacked in XEN image,U-Boot
>>assume the image size is 16MB to memmove, which will cost lots
>>time on simulation platform.
>
>The patch looks good to me, however I would prefer if you update all the
>header rather than updating only the field you care.
>
>You can give a look to commit a2c1d73b94ed49f5fac12e95052d7b140783f800
>"arm64: Update the Image header" in Linux for more details.

Thanks for comments. Will do this in V2.

Thanks,
Peng.

>
>Regards,
>
>>
>>Signed-off-by: Peng Fan 
>>Cc: Stefano Stabellini 
>>Cc: Julien Grall 
>>---
>> xen/arch/arm/arm64/head.S | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
>>index 91e2817..9fade07 100644
>>--- a/xen/arch/arm/arm64/head.S
>>+++ b/xen/arch/arm/arm64/head.S
>>@@ -115,7 +115,7 @@ efi_head:
>> add x13, x18, #0x16
>> b   real_start   /* branch to kernel start */
>> .quad   0/* Image load offset from start of RAM 
>> */
>>-.quad   0/* reserved */
>>+.quad   _end - start /* Effective size of Image, 
>>little-endian */
>> .quad   0/* reserved */
>> .quad   0/* reserved */
>> .quad   0/* reserved */
>>
>
>-- 
>Julien Grall

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

Re: [Xen-devel] [PATCH 2/2] hvmloader: cast to 64bit before multiplication in get_module_entry

[Jan Beulich]

>>> On 19.08.16 at 12:09,  wrote:
> On 19/08/16 09:31, Jan Beulich wrote:
> On 19.08.16 at 10:06,  wrote:
>>> --- a/tools/firmware/hvmloader/hvmloader.c
>>> +++ b/tools/firmware/hvmloader/hvmloader.c
>>> @@ -272,8 +272,8 @@ const struct hvm_modlist_entry *get_module_entry(
>>>  
>>>  if ( !modlist ||
>>>   info->modlist_paddr > UINTPTR_MAX ||
>>> - (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1)
>>> -> UINTPTR_MAX )
>>> + (info->modlist_paddr +
>>> +  (uint64_t)info->nr_modules * sizeof(*modlist) - 1) > UINTPTR_MAX 
>>> )
>>>  return NULL;
>> This can be had without resorting to 64-bit multiplication, by bounds
>> checking
>>
>>  (UINTPTR_MAX - (uintptr_t)info->modlist_paddr) / sizeof(*modlist)
>>
>> instead. While we would certainly hope that compilers don't resort
>> to a libgcc helper for 64-bit multiplication, I think we'd better avoid
>> that risk altogether.
> 
> In this case, using libgcc would cause a link error because of
> -fno-builtin, so I don't think it is too bad.

And it's this link error which I want to avoid.

Jan


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

Re: [Xen-devel] [PATCH 1/2] hvmloader: correctly copy signature to info structures

[Jan Beulich]

>>> On 19.08.16 at 11:42,  wrote:
> On 19/08/16 09:25, Jan Beulich wrote:
> On 19.08.16 at 10:06,  wrote:
>>> --- a/tools/firmware/hvmloader/ovmf.c
>>> +++ b/tools/firmware/hvmloader/ovmf.c
>>> @@ -67,10 +67,11 @@ struct ovmf_info {
>>>  static void ovmf_setup_bios_info(void)
>>>  {
>>>  struct ovmf_info *info = (void *)OVMF_INFO_PHYSICAL_ADDRESS;
>>> +const char sig[] = "XenHVMOVMF";
>>>  
>>>  memset(info, 0, sizeof(*info));
>>>  
>>> -memcpy(info->signature, "XenHVMOVMF", sizeof(info->signature));
>>> +memcpy(info->signature, sig, sizeof(sig));
>>>  info->length = sizeof(*info);
>>>  }
>> I think using strncpy() would be more natural in cases like this,
>> as it would at once make clear that the destination can't be
>> overrun no matter how large the string literal.
> 
> How about structure assignment?
> 
> *info = (struct ovmf_info) { .signature = "XenHVMOVMF", .length =
> sizeof(*info) }
> 
> which also subsumed the memset()?

Fine with me, albeit maybe a little uglier to read.

Jan


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

Re: [Xen-devel] [PATCH 1/3] x86/EFI: don't apply relocations to l{2, 3}_bootmap

[Andrew Cooper]

On 19/08/16 08:50, Jan Beulich wrote:
> Other than claimed in commit 2ce5963727's ("x86: construct the
> {l2,l3}_bootmap at compile time") the initialization of the two page
> tables doesn't take care of everything without furher adjustment: The
> compile time initialization obviously requires base relocations, and
> those get processed after efi_arch_memory_setup(). Hence without
> additional care the correctly initialized values may then get wrongly
> "adjusted" again. Except the two table from being subject to base
> relocation.

Do you mean Exempt? "Except the two tables" doesn't parse.

>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -47,11 +47,23 @@ static void __init efi_arch_relocate_ima
>  
>  for ( base_relocs = __base_relocs_start; base_relocs < 
> __base_relocs_end; )
>  {
> -unsigned int i, n;
> +unsigned int i = 0, n;
>  
>  n = (base_relocs->size - sizeof(*base_relocs)) /
>  sizeof(*base_relocs->entries);
> -for ( i = 0; i < n; ++i )
> +
> +/*
> + * Relevant l{2,3}_bootmap entries get initialized explicitly in
> + * efi_arch_memory_setup(), so we must not apply relocations there.
> + * l2_identmap's first slot, otoh, should be handled normally, as

And l3 surely?

Reviewed-by: Andrew Cooper 

> + * efi_arch_memory_setup() won't touch it (xen_phys_start should
> + * never be zero).
> + */
> +if ( xen_phys_start + base_relocs->rva == (unsigned long)l3_bootmap 
> ||
> + xen_phys_start + base_relocs->rva == (unsigned long)l2_bootmap )
> +i = n;
> +
> +for ( ; i < n; ++i )
>  {
>  unsigned long addr = xen_phys_start + base_relocs->rva +
>   (base_relocs->entries[i] & 0xfff);
>
>
>


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

[Xen-devel] [PATCH v3] xen: support enabling SMEP/SMAP for HVM only

[He Chen]

SMEP/SMAP is a security feature to prevent kernel executing/accessing
user address involuntarily, any such behavior will lead to a page fault.

SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
A 32-bit PV guest will suffer unknown SMEP/SMAP page fault when guest
kernel attempt to access user address although SMEP/SMAP is close for
PV guests already.

This patch is going to support enabling SMEP/SMAP for HVM but disabling
them for Xen hypervisor. Users can choose whether opening them for Xen,
especially when they are going to run 32-bit PV guests.

Signed-off-by: He Chen 

---
Changes in v3:
* Fix boot options.
* Fix CR4 & mmu_cr4_features operations.
* Disable SMEP/SMAP for Dom0.
* Commit message refinement.

Changes in v2:
* Allow "hvm" as a value to "smep" and "smap" command line options.
* Clear SMEP/SMAP CPUID bits for pv guests if they are set to hvm only.
* Refine docs.
* Rewrite commit message.
---
 docs/misc/xen-command-line.markdown |  2 ++
 xen/arch/x86/setup.c| 61 -
 xen/arch/x86/traps.c|  7 +
 xen/include/asm-x86/setup.h |  6 
 4 files changed, 68 insertions(+), 8 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 3a250cb..b15f3e7 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1433,6 +1433,7 @@ Set the serial transmit buffer size.
 > Default: `true`
 
 Flag to enable Supervisor Mode Execution Protection
+Use `smep=hvm` to enable SMEP for HVM guests only.
 
 ### smap
 > `= `
@@ -1440,6 +1441,7 @@ Flag to enable Supervisor Mode Execution Protection
 > Default: `true`
 
 Flag to enable Supervisor Mode Access Prevention
+Use `smap=hvm` to enable SMAP for HVM guests only.
 
 ### snb\_igd\_quirk
 > `=  | cap | `
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 217c775..a428558 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -62,12 +62,12 @@ static unsigned int __initdata max_cpus;
 integer_param("maxcpus", max_cpus);
 
 /* smep: Enable/disable Supervisor Mode Execution Protection (default on). */
-static bool_t __initdata opt_smep = 1;
-boolean_param("smep", opt_smep);
+static void parse_smep_param(char *s);
+custom_param("smep", parse_smep_param);
 
 /* smap: Enable/disable Supervisor Mode Access Prevention (default on). */
-static bool_t __initdata opt_smap = 1;
-boolean_param("smap", opt_smap);
+static void parse_smap_param(char *s);
+custom_param("smap", parse_smap_param);
 
 unsigned long __read_mostly cr4_pv32_mask;
 
@@ -111,6 +111,40 @@ struct cpuinfo_x86 __read_mostly boot_cpu_data = { 0, 0, 
0, 0, -1 };
 
 unsigned long __read_mostly mmu_cr4_features = XEN_MINIMAL_CR4;
 
+int opt_smep = 1;
+static void __init parse_smep_param(char *s)
+{
+if ( !strcmp(s, "hvm") )
+{
+opt_smep = SMEP_HVM_ONLY;
+}
+else if ( !parse_bool(s) )
+{
+opt_smep = 0;
+}
+else if ( parse_bool(s) && opt_smep != SMEP_HVM_ONLY )
+{
+opt_smep = 1;
+}
+}
+
+int opt_smap = 1;
+static void __init parse_smap_param(char *s)
+{
+if ( !strcmp(s, "hvm") )
+{
+opt_smap = SMAP_HVM_ONLY;
+}
+else if ( !parse_bool(s) )
+{
+opt_smap = 0;
+}
+else if ( parse_bool(s) && opt_smap != SMAP_HVM_ONLY )
+{
+opt_smap = 1;
+}
+}
+
 bool_t __read_mostly acpi_disabled;
 bool_t __initdata acpi_force;
 static char __initdata acpi_param[10] = "";
@@ -1403,12 +1437,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
 if ( !opt_smep )
 setup_clear_cpu_cap(X86_FEATURE_SMEP);
-if ( cpu_has_smep )
+if ( cpu_has_smep && opt_smep != SMEP_HVM_ONLY )
 set_in_cr4(X86_CR4_SMEP);
 
 if ( !opt_smap )
 setup_clear_cpu_cap(X86_FEATURE_SMAP);
-if ( cpu_has_smap )
+if ( cpu_has_smap && opt_smap != SMAP_HVM_ONLY )
 set_in_cr4(X86_CR4_SMAP);
 
 cr4_pv32_mask = mmu_cr4_features & XEN_CR4_PV32_BITS;
@@ -1430,8 +1464,19 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
 arch_init_memory();
 
+/*
+ * Temporarily clear SMAP in internal feature bitmap to avoid
+ * patching unnecessary SMAP instructions when SMAP is disabled in
+ * Xen hypervisor.
+ */
+if ( opt_smap == SMAP_HVM_ONLY )
+__clear_bit(X86_FEATURE_SMAP, boot_cpu_data.x86_capability);
+
 alternative_instructions();
 
+if ( opt_smap == SMAP_HVM_ONLY )
+__set_bit(X86_FEATURE_SMAP, boot_cpu_data.x86_capability);
+
 local_irq_enable();
 
 pt_pci_init();
@@ -1550,7 +1595,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * This saves a large number of corner cases interactions with
  * copy_from_user().
  */
-if ( cpu_has_smap )
+if ( cpu_has_smap && opt_smap != SMAP_HVM_ONLY )
 {
 cr4_pv32_mask &= ~X86_CR4_SMAP;
 write_cr4(read_cr4() & ~X86_CR4_SMAP);

Re: [Xen-devel] [PATCH] x86: don't needlessly globalize page table labels

[Andrew Cooper]

On 19/08/16 08:53, Jan Beulich wrote:
> Neither l1_identmap[] nor l3_identmap[] get referenced from outside
> their defining source file; the latter didn't even have an extern
> declaration for use from C sources.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 14/19] efi: build xen.gz with EFI code

[Daniel Kiper]

On Fri, Aug 19, 2016 at 03:24:15AM -0600, Jan Beulich wrote:
> >>> On 06.08.16 at 01:04,  wrote:
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -1248,6 +1248,9 @@ void __init efi_init_memory(void)
> >  } *extra, *extra_head = NULL;
> >  #endif
> >
> > +if ( !efi_enabled(EFI_BOOT) )
> > +return;
> > +
> >  printk(XENLOG_INFO "EFI memory map:%s\n",
> > map_bs ? " (mapping BootServices)" : "");
> >  for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
>
> Remind me please - in your new model, what memory map does
> Xen consume? The raw EFI one, or the one presented by grub?

The former one. GRUB does not provide memory maps on EFI platforms
if image (in our case Xen) requested access to boot services.
They would be bogus.

> In the latter case the above would need to use EFI_LOADER
> afaict; in the former case feel free to add my ack here.

OK, thanks!

Daniel

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

Re: [Xen-devel] [PATCH 2/2] hvmloader: cast to 64bit before multiplication in get_module_entry

[Andrew Cooper]

On 19/08/16 09:31, Jan Beulich wrote:
 On 19.08.16 at 10:06,  wrote:
>> Coverity complains:
>>
>> overflow_before_widen: Potentially overflowing expression
>> info->nr_modules * 32U with type unsigned int (32 bits, unsigned) is
>> evaluated using 32-bit arithmetic, and then used in a context that
>> expects an expression of type uint64_t (64 bits, unsigned).
> To me this is Coverity splitting hair, to be honest.

A very large number of security holes are because of this precise
programming mistake.

Coverity is doing its job correctly;  it is up to a human to decide
whether we care or not.

>
>> --- a/tools/firmware/hvmloader/hvmloader.c
>> +++ b/tools/firmware/hvmloader/hvmloader.c
>> @@ -272,8 +272,8 @@ const struct hvm_modlist_entry *get_module_entry(
>>  
>>  if ( !modlist ||
>>   info->modlist_paddr > UINTPTR_MAX ||
>> - (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1)
>> -> UINTPTR_MAX )
>> + (info->modlist_paddr +
>> +  (uint64_t)info->nr_modules * sizeof(*modlist) - 1) > UINTPTR_MAX )
>>  return NULL;
> This can be had without resorting to 64-bit multiplication, by bounds
> checking
>
>  (UINTPTR_MAX - (uintptr_t)info->modlist_paddr) / sizeof(*modlist)
>
> instead. While we would certainly hope that compilers don't resort
> to a libgcc helper for 64-bit multiplication, I think we'd better avoid
> that risk altogether.

In this case, using libgcc would cause a link error because of
-fno-builtin, so I don't think it is too bad.  I would be surprised if
we didn't have other 64bit multiplication in hvmloader.

~Andrew

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 35dc964bf1eab3f0725389811d2316b1331d6cee
baseline version:
 ovmf 6d732bbbc2b0463f367ceca381cb1861d52cf735

Last test of basis   100554  2016-08-19 05:14:51 Z0 days
Testing same since   100556  2016-08-19 07:43:58 Z0 days1 attempts


People who touched revisions under test:
  Jeff Fan 
  Jiewen Yao 
  Yonghong Zhu 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=35dc964bf1eab3f0725389811d2316b1331d6cee
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
35dc964bf1eab3f0725389811d2316b1331d6cee
+ branch=ovmf
+ revision=35dc964bf1eab3f0725389811d2316b1331d6cee
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x35dc964bf1eab3f0725389811d2316b1331d6cee = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault

[Kevin.Mayer]

Hi

I took another look at Xen and a new crashdump.
The last successful __vmwrite should be in 
static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
[...]
__vmwrite(SECONDARY_VM_EXEC_CONTROL,
  v->arch.hvm_vmx.secondary_exec_control);
[...]
After this the altp2m_vcpu_destroy wakes up the vcpu and is then finished.

In nestedhvm_vcpu_destroy (nvmx_vcpu_destroy) the vmcs can overwritten (but is 
not reached in our case as far as I can see):
if ( nvcpu->nv_n1vmcx )
v->arch.hvm_vmx.vmcs = nvcpu->nv_n1vmcx;

In conclusion:
When destroying a domain the altp2m_vcpu_destroy(v); path seems to mess up the 
vmcs which ( only ) sometimes leads to a failed __vmwrite in vmx_fpu_leave.
That is as far as I can get with my understanding of the Xen code.

Do you guys have any additional ideas what I could test / analyse?

> -Ursprüngliche Nachricht-
> Von: Jan Beulich [mailto:jbeul...@suse.com]
> Gesendet: Montag, 8. August 2016 12:29
> An: Mayer, Kevin 
> Cc: andrew.coop...@citrix.com; xen-devel@lists.xen.org
> Betreff: Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault
> 
> >>> On 08.08.16 at 11:48,  wrote:
> > vmx_vmenter_helper is not part of the call stack. The address is
> > simply the location of the ud2 to which the __vmwrite(HOST_CR0,
> > v->arch.hvm_vmx.host_cr0); In static void vmx_fpu_leave(struct vcpu
> > *v) jumps.
> > There are two vmwrites in vmx_vcpu_update_eptp (called by
> > altp2m_vcpu_destroy):
> > __vmwrite(EPT_POINTER, ept_get_eptp(ept)); __vmwrite(EPTP_INDEX,
> > vcpu_altp2m(v).p2midx);
> >
> > And four in vmx_vcpu_update_vmfunc_ve (also called by
> > altp2m_vcpu_destroy) __vmwrite(VM_FUNCTION_CONTROL,
> > VMX_VMFUNC_EPTP_SWITCHING); __vmwrite(EPTP_LIST_ADDR,
> > virt_to_maddr(d->arch.altp2m_eptp));
> > __vmwrite(VIRT_EXCEPTION_INFO, mfn_x(mfn) << PAGE_SHIFT);
> > __vmwrite(SECONDARY_VM_EXEC_CONTROL,
> > v->arch.hvm_vmx.secondary_exec_control);
> >
> > After the altp2m-part hvm_vcpu_destroy also calls
> > nestedhvm_vcpu_destroy(v), but this code path is executed
> > unconditionally so I assume that the error lies somewhere in the
> altp2m_vcpu_destroy(v).
> >
> > What exactly are the vmx_vmcs_enter / exit required for? I often see
> > the vmx_vmcs_enter; __vmwrite; vmx_vmcs_exit combination. Need the
> > __vmwrites be guarded by an enter / exit ( which Is not the case in
> > the static void vmx_fpu_leave(struct vcpu *v) )?
> 
> On code paths where the correct VMCS may not be the current one it is
> necessary to frame vmread / vmwrite accordingly.
> 
> > Is it possible that the
> > altp2m_vcpu_destroy->vmx_vcpu_update_eptp->vmx_vmcs_exit-
> >vmx_clear_vm
> > cs invalidates the vmcs for the current vcpu?
> 
> I certainly can't exclude this possibility.
> 
> Jan

Virus checked by G Data MailSecurity
Version: AVA 25.7943 dated 19.08.2016
Virus news: www.antiviruslab.com

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

Re: [Xen-devel] [PATCH 1/2] hvmloader: correctly copy signature to info structures

[Andrew Cooper]

On 19/08/16 09:25, Jan Beulich wrote:
 On 19.08.16 at 10:06,  wrote:
>> --- a/tools/firmware/hvmloader/ovmf.c
>> +++ b/tools/firmware/hvmloader/ovmf.c
>> @@ -67,10 +67,11 @@ struct ovmf_info {
>>  static void ovmf_setup_bios_info(void)
>>  {
>>  struct ovmf_info *info = (void *)OVMF_INFO_PHYSICAL_ADDRESS;
>> +const char sig[] = "XenHVMOVMF";
>>  
>>  memset(info, 0, sizeof(*info));
>>  
>> -memcpy(info->signature, "XenHVMOVMF", sizeof(info->signature));
>> +memcpy(info->signature, sig, sizeof(sig));
>>  info->length = sizeof(*info);
>>  }
> I think using strncpy() would be more natural in cases like this,
> as it would at once make clear that the destination can't be
> overrun no matter how large the string literal.

How about structure assignment?

*info = (struct ovmf_info) { .signature = "XenHVMOVMF", .length =
sizeof(*info) }

which also subsumed the memset()?

~Andrew

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

Re: [Xen-devel] [PATCH v3 5/9] livepatch: Move code from prepare_payload to own routine

[Ross Lagerwall]

On 08/14/2016 10:52 PM, Konrad Rzeszutek Wilk wrote:

Specifically the code that is looking up f->old_addr - which
can be in its own routine instead of having it part of prepare_payload.

No functional change.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Ross Lagerwall 

v3: First submission.
---
 xen/common/livepatch.c | 43 ++-
 1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 28a400f..cbfeac1 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -232,6 +232,29 @@ static const char *livepatch_symbols_lookup(unsigned long 
addr,
 return n;
 }

+static int lookup_symbol(struct livepatch_func *f, struct livepatch_elf *elf)
+{
+if ( f->old_addr )
+return 0;
+
+/* Lookup function's old address if not already resolved. */


This comment needs to move further up for it to be correct, since at 
this point we know that it is not yet resolved. How about putting it at 
the top of the function?



+f->old_addr = (void *)symbols_lookup_by_name(f->name);
+if ( !f->old_addr )
+{
+f->old_addr = (void *)livepatch_symbols_lookup_by_name(f->name);
+if ( !f->old_addr )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Could not resolve old address of 
%s\n",
+elf->name, f->name);
+return -ENOENT;
+}
+}
+dprintk(XENLOG_DEBUG, LIVEPATCH "%s: Resolved old address %s => %p\n",
+elf->name, f->name, f->old_addr);
+
+return 0;
+}
+
 static struct payload *find_payload(const char *name)
 {
 struct payload *data, *found = NULL;
@@ -510,23 +533,9 @@ static int prepare_payload(struct payload *payload,
 if ( rc )
 return rc;

-/* Lookup function's old address if not already resolved. */
-if ( !f->old_addr )
-{
-f->old_addr = (void *)symbols_lookup_by_name(f->name);
-if ( !f->old_addr )
-{
-f->old_addr = (void 
*)livepatch_symbols_lookup_by_name(f->name);
-if ( !f->old_addr )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Could not resolve old 
address of %s\n",
-elf->name, f->name);
-return -ENOENT;
-}
-}
-dprintk(XENLOG_DEBUG, LIVEPATCH "%s: Resolved old address %s => 
%p\n",
-elf->name, f->name, f->old_addr);
-}
+rc = lookup_symbol(f, elf);
+if ( rc )
+return rc;


Can you give the function a less generic name? E.g. resolve_old_address

--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v3 2/9] livepatch: Deal with payloads without any .text

[Ross Lagerwall]

On 08/14/2016 10:52 PM, Konrad Rzeszutek Wilk wrote:

It is possible. Especially if the only thing they do is
NOP functions - in which case there is only .livepatch.funcs
sections.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Jan Beulich 
Cc: Andrew Cooper 



Reviewed-by: Ross Lagerwall 

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

Re: [Xen-devel] [PATCH v3 3/9] version/livepatch: Move xen_build_id_check to version.h

[Ross Lagerwall]

On 08/14/2016 10:52 PM, Konrad Rzeszutek Wilk wrote:

It makes more sense for it to be there. However that
means the version.h has now a dependency on 
as the Elf_Note is a macro.

The elfstructs.h has a dependency on types.h as well so
we need that. We cannot put that #include 
in elfstructs.h as that file is used by tools and they
do not have such file.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Ross Lagerwall 
Cc: Jan Beulich 
Cc: Andrew Cooper 



Reviewed-by: Ross Lagerwall 

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

Re: [Xen-devel] [PATCH v4 14/19] efi: build xen.gz with EFI code

[Jan Beulich]

>>> On 06.08.16 at 01:04,  wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1248,6 +1248,9 @@ void __init efi_init_memory(void)
>  } *extra, *extra_head = NULL;
>  #endif
>  
> +if ( !efi_enabled(EFI_BOOT) )
> +return;
> +
>  printk(XENLOG_INFO "EFI memory map:%s\n",
> map_bs ? " (mapping BootServices)" : "");
>  for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )

Remind me please - in your new model, what memory map does
Xen consume? The raw EFI one, or the one presented by grub?
In the latter case the above would need to use EFI_LOADER
afaict; in the former case feel free to add my ack here.

Jan


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

Re: [Xen-devel] [PATCH v3 1/9] livepatch: Clear .bss when payload is reverted

[Jan Beulich]

>>> On 19.08.16 at 10:37,  wrote:
> On 08/15/2016 04:10 PM, Jan Beulich wrote:
> On 15.08.16 at 16:29,  wrote:
>>> On Mon, Aug 15, 2016 at 04:27:38AM -0600, Jan Beulich wrote:
>>> On 14.08.16 at 23:52,  wrote:
> @@ -1034,6 +1047,9 @@ static int revert_payload(struct payload *data)
>  list_del_rcu(>applied_list);
>  unregister_virtual_region(>region);
>
> +/* And clear the BSS for subsequent operation. */
> +memset(data->bss, 0, data->bss_size);

 Instead of doing it in two places, how about moving this into
 apply_payload()?
>>>
>>> I was thinking of it too, but then it occurred to me that between the
>>> 'check' -> 'apply' the BSS is left unitialized. And if we ever crash
>>> (right as somebody scheduled the livepatch) one could form the opinion
>>> that it is due to the .bss having garbage. Or more importantly - the
>>> hooks may not have run, but all its values looked like they have been
>>> initialized.
>>>
>>> And spend considerable amount of time debugging something which in reality
>>> is not a problem?
>>>
>>> Perhaps put it in multiple places :-)
>>
>> Well, you and Ross know. Afaic I'd always do things in just one
>> place if that's possible.
>>
> 
> Yes, I'd also prefer it in just a single place.
> 
> However, assuming that there is only a single BSS section is wrong. 
> Especially when compiling with -fdata-sections (as livepatch-build-tools 
> does), a payload can have multiple BSS sections.

Good point, and making it an even stronger argument to deal with
that in just one place.

Jan


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

Re: [Xen-devel] [PATCH v3 1/9] livepatch: Clear .bss when payload is reverted

[Ross Lagerwall]

On 08/15/2016 04:10 PM, Jan Beulich wrote:

On 15.08.16 at 16:29,  wrote:

On Mon, Aug 15, 2016 at 04:27:38AM -0600, Jan Beulich wrote:

On 14.08.16 at 23:52,  wrote:

@@ -1034,6 +1047,9 @@ static int revert_payload(struct payload *data)
 list_del_rcu(>applied_list);
 unregister_virtual_region(>region);

+/* And clear the BSS for subsequent operation. */
+memset(data->bss, 0, data->bss_size);


Instead of doing it in two places, how about moving this into
apply_payload()?


I was thinking of it too, but then it occurred to me that between the
'check' -> 'apply' the BSS is left unitialized. And if we ever crash
(right as somebody scheduled the livepatch) one could form the opinion
that it is due to the .bss having garbage. Or more importantly - the
hooks may not have run, but all its values looked like they have been
initialized.

And spend considerable amount of time debugging something which in reality
is not a problem?

Perhaps put it in multiple places :-)


Well, you and Ross know. Afaic I'd always do things in just one
place if that's possible.



Yes, I'd also prefer it in just a single place.

However, assuming that there is only a single BSS section is wrong. 
Especially when compiling with -fdata-sections (as livepatch-build-tools 
does), a payload can have multiple BSS sections.


--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH 2/2] hvmloader: cast to 64bit before multiplication in get_module_entry

[Jan Beulich]

>>> On 19.08.16 at 10:06,  wrote:
> Coverity complains:
> 
> overflow_before_widen: Potentially overflowing expression
> info->nr_modules * 32U with type unsigned int (32 bits, unsigned) is
> evaluated using 32-bit arithmetic, and then used in a context that
> expects an expression of type uint64_t (64 bits, unsigned).

To me this is Coverity splitting hair, to be honest.

> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -272,8 +272,8 @@ const struct hvm_modlist_entry *get_module_entry(
>  
>  if ( !modlist ||
>   info->modlist_paddr > UINTPTR_MAX ||
> - (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1)
> -> UINTPTR_MAX )
> + (info->modlist_paddr +
> +  (uint64_t)info->nr_modules * sizeof(*modlist) - 1) > UINTPTR_MAX )
>  return NULL;

This can be had without resorting to 64-bit multiplication, by bounds
checking

 (UINTPTR_MAX - (uintptr_t)info->modlist_paddr) / sizeof(*modlist)

instead. While we would certainly hope that compilers don't resort
to a libgcc helper for 64-bit multiplication, I think we'd better avoid
that risk altogether.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail  like 100544
 build-i386-rumpuserxen6 xen-buildfail  like 100544
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100544
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100544
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100544
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100544
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100544
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100544

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass

version targeted for testing:
 xen  830f177d920bdb4fda4fcdcd3b8ac0928cb579fb
baseline version:
 xen  361db13b0380a3462f788d44076f42f6f155e719

Last test of basis   100544  2016-08-18 13:44:07 Z0 days
Testing same since   100551  2016-08-19 00:44:51 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  George Dunlap 
  Jan Beulich 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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

Re: [Xen-devel] [PATCH 1/2] hvmloader: correctly copy signature to info structures

[Jan Beulich]

>>> On 19.08.16 at 10:06,  wrote:
> --- a/tools/firmware/hvmloader/ovmf.c
> +++ b/tools/firmware/hvmloader/ovmf.c
> @@ -67,10 +67,11 @@ struct ovmf_info {
>  static void ovmf_setup_bios_info(void)
>  {
>  struct ovmf_info *info = (void *)OVMF_INFO_PHYSICAL_ADDRESS;
> +const char sig[] = "XenHVMOVMF";
>  
>  memset(info, 0, sizeof(*info));
>  
> -memcpy(info->signature, "XenHVMOVMF", sizeof(info->signature));
> +memcpy(info->signature, sig, sizeof(sig));
>  info->length = sizeof(*info);
>  }

I think using strncpy() would be more natural in cases like this,
as it would at once make clear that the destination can't be
overrun no matter how large the string literal.

Jan


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

[Xen-devel] [PATCH 1/2] hvmloader: correctly copy signature to info structures

[Wei Liu]

The original code used sizeof(info->signature) as the size parameter for
memcpy, which was wrong.

Fix that by calculating the correct size.

Signed-off-by: Wei Liu 
---
 tools/firmware/hvmloader/ovmf.c| 3 ++-
 tools/firmware/hvmloader/seabios.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index b4bcc93..a4ed661 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -67,10 +67,11 @@ struct ovmf_info {
 static void ovmf_setup_bios_info(void)
 {
 struct ovmf_info *info = (void *)OVMF_INFO_PHYSICAL_ADDRESS;
+const char sig[] = "XenHVMOVMF";
 
 memset(info, 0, sizeof(*info));
 
-memcpy(info->signature, "XenHVMOVMF", sizeof(info->signature));
+memcpy(info->signature, sig, sizeof(sig));
 info->length = sizeof(*info);
 }
 
diff --git a/tools/firmware/hvmloader/seabios.c 
b/tools/firmware/hvmloader/seabios.c
index 5c9a351..ca092cc 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -55,10 +55,11 @@ struct seabios_info {
 static void seabios_setup_bios_info(void)
 {
 struct seabios_info *info = (void *)BIOS_INFO_PHYSICAL_ADDRESS;
+const char sig[] = "XenHVMSeaBIOS";
 
 memset(info, 0, sizeof(*info));
 
-memcpy(info->signature, "XenHVMSeaBIOS", sizeof(info->signature));
+memcpy(info->signature, sig, sizeof(sig));
 info->length = sizeof(*info);
 
 info->tables = (uint32_t)scratch_alloc(MAX_TABLES*sizeof(uint32_t), 0);
-- 
2.1.4


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

[Xen-devel] [PATCH 0/2] hvmloader: fix two issues spotted by Coverity

[Wei Liu]

Wei Liu (2):
  hvmloader: correctly copy signature to info structures
  hvmloader: cast to 64bit before multiplication in get_module_entry

 tools/firmware/hvmloader/hvmloader.c | 4 ++--
 tools/firmware/hvmloader/ovmf.c  | 3 ++-
 tools/firmware/hvmloader/seabios.c   | 3 ++-
 3 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 2/2] hvmloader: cast to 64bit before multiplication in get_module_entry

[Wei Liu]

Coverity complains:

overflow_before_widen: Potentially overflowing expression
info->nr_modules * 32U with type unsigned int (32 bits, unsigned) is
evaluated using 32-bit arithmetic, and then used in a context that
expects an expression of type uint64_t (64 bits, unsigned).

The overflow is unlikely to happen in reality because we only expect a
few modules.

Fix that by casting the variable to 64bit before multiplication to
placate Coverity.

Signed-off-by: Wei Liu 
---
 tools/firmware/hvmloader/hvmloader.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 7b32d86..970222c 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -272,8 +272,8 @@ const struct hvm_modlist_entry *get_module_entry(
 
 if ( !modlist ||
  info->modlist_paddr > UINTPTR_MAX ||
- (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1)
-> UINTPTR_MAX )
+ (info->modlist_paddr +
+  (uint64_t)info->nr_modules * sizeof(*modlist) - 1) > UINTPTR_MAX )
 return NULL;
 
 for ( i = 0; i < info->nr_modules; i++ )
-- 
2.1.4


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

[Xen-devel] [PATCH] x86: don't needlessly globalize page table labels

[Jan Beulich]

Neither l1_identmap[] nor l3_identmap[] get referenced from outside
their defining source file; the latter didn't even have an extern
declaration for use from C sources.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -88,7 +88,7 @@ GLOBAL(__page_tables_start)
  * of physical memory. In any case the VGA hole should be mapped with type UC.
  * Uses 1x 4k page.
  */
-GLOBAL(l1_identmap)
+l1_identmap:
 pfn = 0
 .rept L1_PAGETABLE_ENTRIES
 /* VGA hole (0xa-0xc) should be mapped UC. */
@@ -143,7 +143,7 @@ l2_fixmap:
 .size l2_fixmap, . - l2_fixmap
 
 /* Identity map, covering the 4 l2_identmap tables.  Uses 1x 4k page. */
-GLOBAL(l3_identmap)
+l3_identmap:
 idx = 0
 .rept 4
 .quad sym_phys(l2_identmap) + (idx << PAGE_SHIFT) + __PAGE_HYPERVISOR
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -291,8 +291,7 @@ extern l2_pgentry_t l2_xenmap[L2_PAGETAB
 l2_bootmap[L2_PAGETABLE_ENTRIES];
 extern l3_pgentry_t l3_bootmap[L3_PAGETABLE_ENTRIES];
 extern l2_pgentry_t l2_identmap[4*L2_PAGETABLE_ENTRIES];
-extern l1_pgentry_t l1_identmap[L1_PAGETABLE_ENTRIES],
-l1_fixmap[L1_PAGETABLE_ENTRIES];
+extern l1_pgentry_t l1_fixmap[L1_PAGETABLE_ENTRIES];
 void paging_init(void);
 void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t);
 #endif /* !defined(__ASSEMBLY__) */



x86: don't needlessly globalize page table labels

Neither l1_identmap[] nor l3_identmap[] get referenced from outside
their defining source file; the latter didn't even have an extern
declaration for use from C sources.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -88,7 +88,7 @@ GLOBAL(__page_tables_start)
  * of physical memory. In any case the VGA hole should be mapped with type UC.
  * Uses 1x 4k page.
  */
-GLOBAL(l1_identmap)
+l1_identmap:
 pfn = 0
 .rept L1_PAGETABLE_ENTRIES
 /* VGA hole (0xa-0xc) should be mapped UC. */
@@ -143,7 +143,7 @@ l2_fixmap:
 .size l2_fixmap, . - l2_fixmap
 
 /* Identity map, covering the 4 l2_identmap tables.  Uses 1x 4k page. */
-GLOBAL(l3_identmap)
+l3_identmap:
 idx = 0
 .rept 4
 .quad sym_phys(l2_identmap) + (idx << PAGE_SHIFT) + __PAGE_HYPERVISOR
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -291,8 +291,7 @@ extern l2_pgentry_t l2_xenmap[L2_PAGETAB
 l2_bootmap[L2_PAGETABLE_ENTRIES];
 extern l3_pgentry_t l3_bootmap[L3_PAGETABLE_ENTRIES];
 extern l2_pgentry_t l2_identmap[4*L2_PAGETABLE_ENTRIES];
-extern l1_pgentry_t l1_identmap[L1_PAGETABLE_ENTRIES],
-l1_fixmap[L1_PAGETABLE_ENTRIES];
+extern l1_pgentry_t l1_fixmap[L1_PAGETABLE_ENTRIES];
 void paging_init(void);
 void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t);
 #endif /* !defined(__ASSEMBLY__) */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/3] x86/EFI: be cautious about being handed control with CR4.PGE enabled

[Jan Beulich]

To effect proper TLB flushing in that case we should clear CR4.PGE
before loading the new page tables.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -228,7 +228,7 @@ static void __init efi_arch_pre_exit_boo
 
 static void __init noreturn efi_arch_post_exit_boot(void)
 {
-u64 efer;
+u64 cr4 = XEN_MINIMAL_CR4 & ~X86_CR4_PGE, efer;
 
 efi_arch_relocate_image(__XEN_VIRT_START - xen_phys_start);
 memcpy((void *)trampoline_phys, trampoline_start, cfg.size);
@@ -244,6 +244,10 @@ static void __init noreturn efi_arch_pos
   X86_CR0_AM | X86_CR0_PG);
 asm volatile ( "mov%[cr4], %%cr4\n\t"
"mov%[cr3], %%cr3\n\t"
+#if XEN_MINIMAL_CR4 & X86_CR4_PGE
+   "or $"__stringify(X86_CR4_PGE)", %[cr4]\n\t"
+   "mov%[cr4], %%cr4\n\t"
+#endif
"movabs $__start_xen, %[rip]\n\t"
"lgdt   gdt_descr(%%rip)\n\t"
"movstack_start(%%rip), %%rsp\n\t"
@@ -255,9 +259,9 @@ static void __init noreturn efi_arch_pos
"movl   %[cs], 8(%%rsp)\n\t"
"mov%[rip], (%%rsp)\n\t"
"lretq  %[stkoff]-16"
-   : [rip] "=" (efer/* any dead 64-bit variable */)
+   : [rip] "=" (efer/* any dead 64-bit variable */),
+ [cr4] "+" (cr4)
: [cr3] "r" (idle_pg_table),
- [cr4] "r" (mmu_cr4_features),
  [cs] "ir" (__HYPERVISOR_CS),
  [ds] "r" (__HYPERVISOR_DS),
  [stkoff] "i" (STACK_SIZE - sizeof(struct cpu_info)),



x86/EFI: be cautious about being handed control with CR4.PGE enabled

To effect proper TLB flushing in that case we should clear CR4.PGE
before loading the new page tables.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -228,7 +228,7 @@ static void __init efi_arch_pre_exit_boo
 
 static void __init noreturn efi_arch_post_exit_boot(void)
 {
-u64 efer;
+u64 cr4 = XEN_MINIMAL_CR4 & ~X86_CR4_PGE, efer;
 
 efi_arch_relocate_image(__XEN_VIRT_START - xen_phys_start);
 memcpy((void *)trampoline_phys, trampoline_start, cfg.size);
@@ -244,6 +244,10 @@ static void __init noreturn efi_arch_pos
   X86_CR0_AM | X86_CR0_PG);
 asm volatile ( "mov%[cr4], %%cr4\n\t"
"mov%[cr3], %%cr3\n\t"
+#if XEN_MINIMAL_CR4 & X86_CR4_PGE
+   "or $"__stringify(X86_CR4_PGE)", %[cr4]\n\t"
+   "mov%[cr4], %%cr4\n\t"
+#endif
"movabs $__start_xen, %[rip]\n\t"
"lgdt   gdt_descr(%%rip)\n\t"
"movstack_start(%%rip), %%rsp\n\t"
@@ -255,9 +259,9 @@ static void __init noreturn efi_arch_pos
"movl   %[cs], 8(%%rsp)\n\t"
"mov%[rip], (%%rsp)\n\t"
"lretq  %[stkoff]-16"
-   : [rip] "=" (efer/* any dead 64-bit variable */)
+   : [rip] "=" (efer/* any dead 64-bit variable */),
+ [cr4] "+" (cr4)
: [cr3] "r" (idle_pg_table),
- [cr4] "r" (mmu_cr4_features),
  [cs] "ir" (__HYPERVISOR_CS),
  [ds] "r" (__HYPERVISOR_DS),
  [stkoff] "i" (STACK_SIZE - sizeof(struct cpu_info)),
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3/3] x86/EFI: don't accept 64-bit base relocations on page tables

[Jan Beulich]

Page tables get pre-populated with physical addresses which, due to
living inside the Xen image, will never exceed 32 bits in width. That
in turn results in the tool generating the relocations to produce
32-bit relocations for them instead of the 64-bit ones needed for
relocating virtual addresses. Hence instead of special casing page
tables in the processing of 64-bit relocations, let's be more rigid
and refuse them (as being indicative of something else having gone
wrong in the build process).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -81,12 +81,9 @@ static void __init efi_arch_relocate_ima
 }
 break;
 case PE_BASE_RELOC_DIR64:
-if ( delta )
-{
-*(u64 *)addr += delta;
-if ( in_page_tables(addr) )
-*(intpte_t *)addr += xen_phys_start;
-}
+if ( in_page_tables(addr) )
+blexit(L"Unexpected relocation type");
+*(u64 *)addr += delta;
 break;
 default:
 blexit(L"Unsupported relocation type");



x86/EFI: don't accept 64-bit base relocations on page tables

Page tables get pre-populated with physical addresses which, due to
living inside the Xen image, will never exceed 32 bits in width. That
in turn results in the tool generating the relocations to produce
32-bit relocations for them instead of the 64-bit ones needed for
relocating virtual addresses. Hence instead of special casing page
tables in the processing of 64-bit relocations, let's be more rigid
and refuse them (as being indicative of something else having gone
wrong in the build process).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -81,12 +81,9 @@ static void __init efi_arch_relocate_ima
 }
 break;
 case PE_BASE_RELOC_DIR64:
-if ( delta )
-{
-*(u64 *)addr += delta;
-if ( in_page_tables(addr) )
-*(intpte_t *)addr += xen_phys_start;
-}
+if ( in_page_tables(addr) )
+blexit(L"Unexpected relocation type");
+*(u64 *)addr += delta;
 break;
 default:
 blexit(L"Unsupported relocation type");
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/3] x86/EFI: don't apply relocations to l{2, 3}_bootmap

[Jan Beulich]

Other than claimed in commit 2ce5963727's ("x86: construct the
{l2,l3}_bootmap at compile time") the initialization of the two page
tables doesn't take care of everything without furher adjustment: The
compile time initialization obviously requires base relocations, and
those get processed after efi_arch_memory_setup(). Hence without
additional care the correctly initialized values may then get wrongly
"adjusted" again. Except the two table from being subject to base
relocation.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -47,11 +47,23 @@ static void __init efi_arch_relocate_ima
 
 for ( base_relocs = __base_relocs_start; base_relocs < __base_relocs_end; )
 {
-unsigned int i, n;
+unsigned int i = 0, n;
 
 n = (base_relocs->size - sizeof(*base_relocs)) /
 sizeof(*base_relocs->entries);
-for ( i = 0; i < n; ++i )
+
+/*
+ * Relevant l{2,3}_bootmap entries get initialized explicitly in
+ * efi_arch_memory_setup(), so we must not apply relocations there.
+ * l2_identmap's first slot, otoh, should be handled normally, as
+ * efi_arch_memory_setup() won't touch it (xen_phys_start should
+ * never be zero).
+ */
+if ( xen_phys_start + base_relocs->rva == (unsigned long)l3_bootmap ||
+ xen_phys_start + base_relocs->rva == (unsigned long)l2_bootmap )
+i = n;
+
+for ( ; i < n; ++i )
 {
 unsigned long addr = xen_phys_start + base_relocs->rva +
  (base_relocs->entries[i] & 0xfff);



x86/EFI: don't apply relocations to l{2,3}_bootmap

Other than claimed in commit 2ce5963727's ("x86: construct the
{l2,l3}_bootmap at compile time") the initialization of the two page
tables doesn't take care of everything without furher adjustment: The
compile time initialization obviously requires base relocations, and
those get processed after efi_arch_memory_setup(). Hence without
additional care the correctly initialized values may then get wrongly
"adjusted" again. Except the two table from being subject to base
relocation.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -47,11 +47,23 @@ static void __init efi_arch_relocate_ima
 
 for ( base_relocs = __base_relocs_start; base_relocs < __base_relocs_end; )
 {
-unsigned int i, n;
+unsigned int i = 0, n;
 
 n = (base_relocs->size - sizeof(*base_relocs)) /
 sizeof(*base_relocs->entries);
-for ( i = 0; i < n; ++i )
+
+/*
+ * Relevant l{2,3}_bootmap entries get initialized explicitly in
+ * efi_arch_memory_setup(), so we must not apply relocations there.
+ * l2_identmap's first slot, otoh, should be handled normally, as
+ * efi_arch_memory_setup() won't touch it (xen_phys_start should
+ * never be zero).
+ */
+if ( xen_phys_start + base_relocs->rva == (unsigned long)l3_bootmap ||
+ xen_phys_start + base_relocs->rva == (unsigned long)l2_bootmap )
+i = n;
+
+for ( ; i < n; ++i )
 {
 unsigned long addr = xen_phys_start + base_relocs->rva +
  (base_relocs->entries[i] & 0xfff);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv2] x86: Add a tboot Kconfig option

[Jan Beulich]

>>> On 19.08.16 at 02:04,  wrote:
> On 8/18/16 6:44 PM, Derek Straka wrote:
>> Allows for the conditional inclusion of tboot related functionality
>> via Kconfig
>> 
>> The default configuration for the new CONFIG_TBOOT option is 'y', so the
>> behavior out of the box remains unchanged.  The addition of the option 
> allows
>> advanced users to disable system behaviors associated with tboot at compile
>> time rather than relying on the run-time detection and configuration.
>> 
>> The CONFIG_CRYPTO option is 'n' by default and selected by the individual 
> users
>> that require the functionality.  Currently, the only user is tboot.
>> 
>> Signed-off-by: Derek Straka 
>> ---
> 
> Reviewed-by: Doug Goldstein 
> 
> 
>>  
>> +config CRYPTO
>> +bool
>> +default n
>> +
> 
> If a v3 happens (or the committer wants to change it) this can be
> "def_bool n".

This isn't just a "can be", nor should it become def_bool. Defaults
for select only options should be omitted altogether, so that when
a prompt gets added to them and nothing has previously selected
it, the user will be presented with a prompt instead of the already
recorded default of "no" getting used.

But yes, no v3 is needed, this line can easily be dropped while
committing.

Jan


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

[Xen-devel] [PATCH 0/3] x86/EFI: boot adjustments

[Jan Beulich]

1: don't apply relocations to l{2,3}_bootmap
2: be cautious about being handed control with CR4.PGE enabled
3: don't accept 64-bit base relocations on page tables

Signed-off-by: Jan Beulich 


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

[Xen-devel] [libvirt test] 100553: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  5 xen-install  fail REGR. vs. 100538

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass

version targeted for testing:
 libvirt  72abe564480b6a521eae46534406169b645ac8b3
baseline version:
 libvirt  41f5c2ca27762770a40187fe63459c10a74c79f9

Last test of basis   100538  2016-08-18 04:19:40 Z1 days
Testing same since   100553  2016-08-19 04:20:40 Z0 days1 attempts


People who touched revisions under test:
  Ján Tomko 
  Maxim Nestratov 
  Mikhail Feoktistov 
  Olga Krishtal 

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



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

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

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

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


Not pushing.


commit 72abe564480b6a521eae46534406169b645ac8b3
Author: Mikhail Feoktistov 
Date:   Thu Aug 18 07:43:09 2016 -0400

vz: add validation callbacks

This patch fixes a bug which occurs when we check a bus and unit number
for a new attached disk. We should do this check in ValidadionCallback,
not in PostParse callback. Because in PostParse we have not initialized
disk->info.addr.drive struct yet.
Move part of code from domainPostParseCallback to domainValidateCallback
and part from devicesPostParseCallback to 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 6d732bbbc2b0463f367ceca381cb1861d52cf735
baseline version:
 ovmf 00bcb5c27a5bb781099482c5763937334be91e76

Last test of basis   100552  2016-08-19 03:16:58 Z0 days
Testing same since   100554  2016-08-19 05:14:51 Z0 days1 attempts


People who touched revisions under test:
  Shi, Steven 
  Steven Shi 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=6d732bbbc2b0463f367ceca381cb1861d52cf735
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
6d732bbbc2b0463f367ceca381cb1861d52cf735
+ branch=ovmf
+ revision=6d732bbbc2b0463f367ceca381cb1861d52cf735
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x6d732bbbc2b0463f367ceca381cb1861d52cf735 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] [PATCH net-next] xen-netback: create a debugfs node for hash information

[David Miller]

From: Paul Durrant 
Date: Wed, 17 Aug 2016 16:13:29 +0100

> It is useful to be able to see the hash configuration when running tests.
> This patch adds a debugfs node for that purpose.
> 
> Signed-off-by: Paul Durrant 

Applied.

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