Re: [Xen-devel] [PATCH] xen: arm: perfc: count individual SGIs and PPIs

[Ian Campbell]

On Mon, 2015-11-09 at 07:11 -0700, Jan Beulich wrote:
> > > > On 09.11.15 at 15:01,  wrote:
> > SPIs are too numerous and not indivcidually as interesting.
> > 
> > Make the exists #IPIS counter x86 specific.
> 
> I'd recommend not to - even if ARM doesn't want to use it, it's still a
> pretty generic thing.

ARM calls these "SGIs" (Software Generated Is), but I suppose I don't mind
keeping the #IPIS around and generic though.

Ian.

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

Re: [Xen-devel] [PATCH] xen: arm: perfc: count individual SGIs and PPIs

[Jan Beulich]

>>> On 09.11.15 at 15:24,  wrote:
> On 09/11/15 14:20, Ian Campbell wrote:
>> On Mon, 2015-11-09 at 07:11 -0700, Jan Beulich wrote:
>> On 09.11.15 at 15:01,  wrote:
 SPIs are too numerous and not indivcidually as interesting.

 Make the exists #IPIS counter x86 specific.
>>>
>>> I'd recommend not to - even if ARM doesn't want to use it, it's still a
>>> pretty generic thing.
>> 
>> ARM calls these "SGIs" (Software Generated Is), but I suppose I don't mind
>> keeping the #IPIS around and generic though.
> 
> With this patch the only usage of #IPIS is in arch/x86. It will confuse
> the user because #IPIs will always be 0 on ARM.

There are quite a few counters which will (perhaps under some
conditions) remain to be zero.

> So I don't see any point to keep the definition common.

I think "IPI" is a generic enough concept (and afaia not one
introduced through x86, not even just its name) to allow for
possible future ports to use this.

Jan


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

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

[Boris Ostrovsky]

On 11/09/2015 09:53 AM, Dario Faggioli wrote:

On Mon, 2015-11-09 at 14:00 +, Ian Campbell wrote:

Signed-off-by: Ian Campbell 


Reviewed-by: Dario Faggioli 

And, while we're here, I've been thinking since a while to try
implementing an xl interface for these counters... How bad of an idea
is that?

Is something like that possible already via Boris' PMU work?


VPMU only covers CPU's hardware counters and this patch deals with 
software events in the hypervisor.


As far as xl accessibility --- doesn't xenperf already read them out?


-boris

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

Re: [Xen-devel] [PATCH] x86/P2M: consolidate handling of types not requiring a valid MFN

[Andrew Cooper]

On 09/11/15 14:52, Jan Beulich wrote:
> As noted regarding the mixture of checks in p2m_pt_set_entry(),
> introduce an new P2M type group allowing to be used everywhere we

"a new P2M"

> just care about accepting operations with either a valid MFN or a type
> permitting to be used without (valid) MFN.
>
> Note that p2m_mmio_dm is not included in P2M_NO_MFN_TYPES, as for the
> intended purpose that one ought to be treated similar to p2m_invalid
> (perhaps the two should ultimately get folded anyway).

I seem to recall that p2m_invalid is still required to make the default
ioreq server infrastructure work with older qemu's

We really should see about cleaning the two up however.

>
> Signed-off-by: Jan Beulich 

You probably also want to note that PoD superpages are now INVALID_MFN
rather than _mfn(0), but code wise,

Reviewed-by: Andrew Cooper 

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

[Xen-devel] RFC: PV vfb's and the handling of global vnc options

[George Dunlap]

So I had a user report that he couldn't get the vnclisten option to
work.  It turns out he was using a PV guest, and had the following in
his config file:

vfb=[ 'type=vnc' ]
vnclisten='0.0.0.0'

After digging around in the code, it turns out that the following is
accepted for PV guests:

vnc=1
vnclisten='0.0.0.0'

...on the condition that there be *no* vfb option.  If you set the vfb
option, then the top-level vnc entries are completely ignored.

The following also works (as one might expect):

vfb=[ 'type=vnc,vnclisten=0.0.0.0' ]

The man page is a bit unclear here; it says:

If "Emulated VGA Graphics Device" options are used in a PV guest
configuration, xl will pick up vnc, vnclisten, vncpasswd, vncdisplay,
vncunused, sdl, opengl and keymap to construct paravirtual framebuffer
device for the guest.

I see two options:

1. Make vfb take defaults from the top-level vnc options

2. Clarify the man page to make it clear that top-level vnc options
will only have an effect if no vfb is specified.

I'm of two minds which one is best.  At the moment I'm leaning towards
#2, possibly adding a warning if it finds both vfb and toplevel vnc
options, saying that it's ignoring the second.

Any opinions?

 -George

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

Re: [Xen-devel] [PATCH] xen: arm: perfc: count individual SGIs and PPIs

[Julien Grall]

Hi,

On 09/11/15 14:20, Ian Campbell wrote:
> On Mon, 2015-11-09 at 07:11 -0700, Jan Beulich wrote:
> On 09.11.15 at 15:01,  wrote:
>>> SPIs are too numerous and not indivcidually as interesting.
>>>
>>> Make the exists #IPIS counter x86 specific.
>>
>> I'd recommend not to - even if ARM doesn't want to use it, it's still a
>> pretty generic thing.
> 
> ARM calls these "SGIs" (Software Generated Is), but I suppose I don't mind
> keeping the #IPIS around and generic though.

With this patch the only usage of #IPIS is in arch/x86. It will confuse
the user because #IPIs will always be 0 on ARM.

So I don't see any point to keep the definition common.

Regards,

-- 
Julien Grall

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

[Xen-devel] [PATCH v2] x86/PoD: tighten conditions for checking super page

[Jan Beulich]

Since calling the function isn't cheap, try to avoid the call when we
know up front it won't help; see the code comment for details on those
conditions.

Signed-off-by: Jan Beulich 
---
v2: Adjust conditions and body of the if() to make them easier
understandable, without altering behavior (requested by George).

--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -528,7 +528,6 @@ p2m_pod_decrease_reservation(struct doma
 if ( unlikely(d->is_dying) )
 goto out_unlock;
 
-recount:
 pod = nonpod = ram = 0;
 
 /* Figure out if we need to steal some freed memory for our cache */
@@ -568,15 +567,20 @@ recount:
 goto out_entry_check;
 }
 
-/* Try to grab entire superpages if possible.  Since the common case is 
for drivers
- * to pass back singleton pages, see if we can take the whole page back 
and mark the
- * rest PoD. */
-if ( steal_for_cache
- && p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES-1)))
+/*
+ * Try to grab entire superpages if possible.  Since the common case is for
+ * drivers to pass back singleton pages, see if we can take the whole page
+ * back and mark the rest PoD.
+ * No need to do this though if
+ * - order >= SUPERPAGE_ORDER (the loop below will take care of this)
+ * - not all of the pages were RAM (now knowing order < SUPERPAGE_ORDER)
+ */
+if ( steal_for_cache && order < SUPERPAGE_ORDER && ram == (1 << order) &&
+ p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES - 1)) )
 {
-/* Since order may be arbitrary, we may have taken more or less
- * than we were actually asked to; so just re-count from scratch */
-goto recount;
+pod = 1 << order;
+ram = nonpod = 0;
+ASSERT(steal_for_cache == (p2m->pod.entry_count > p2m->pod.count));
 }
 
 /* Process as long as:



x86/PoD: tighten conditions for checking super page

Since calling the function isn't cheap, try to avoid the call when we
know up front it won't help; see the code comment for details on those
conditions.

Signed-off-by: Jan Beulich 
---
v2: Adjust conditions and body of the if() to make them easier
understandable, without altering behavior (requested by George).

--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -528,7 +528,6 @@ p2m_pod_decrease_reservation(struct doma
 if ( unlikely(d->is_dying) )
 goto out_unlock;
 
-recount:
 pod = nonpod = ram = 0;
 
 /* Figure out if we need to steal some freed memory for our cache */
@@ -568,15 +567,20 @@ recount:
 goto out_entry_check;
 }
 
-/* Try to grab entire superpages if possible.  Since the common case is 
for drivers
- * to pass back singleton pages, see if we can take the whole page back 
and mark the
- * rest PoD. */
-if ( steal_for_cache
- && p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES-1)))
+/*
+ * Try to grab entire superpages if possible.  Since the common case is for
+ * drivers to pass back singleton pages, see if we can take the whole page
+ * back and mark the rest PoD.
+ * No need to do this though if
+ * - order >= SUPERPAGE_ORDER (the loop below will take care of this)
+ * - not all of the pages were RAM (now knowing order < SUPERPAGE_ORDER)
+ */
+if ( steal_for_cache && order < SUPERPAGE_ORDER && ram == (1 << order) &&
+ p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES - 1)) )
 {
-/* Since order may be arbitrary, we may have taken more or less
- * than we were actually asked to; so just re-count from scratch */
-goto recount;
+pod = 1 << order;
+ram = nonpod = 0;
+ASSERT(steal_for_cache == (p2m->pod.entry_count > p2m->pod.count));
 }
 
 /* Process as long as:
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock

[Stefano Stabellini]

On Fri, 6 Nov 2015, Arnd Bergmann wrote:
> > > > ---
> > > > +static void xen_read_wallclock(struct timespec *ts)
> > > > +{
> > > > +   u32 version;
> > > > +   u64 delta;
> > > > +   struct timespec now;
> > > > +   struct shared_info *s = HYPERVISOR_shared_info;
> > > > +   struct pvclock_wall_clock *wall_clock = &(s->wc);
> > > 
> > > pvclock_wall_clock has a 'u32 sec', so that suffers from
> > > a potential overflow. We should try to avoid introducing that
> > > on ARM, and instead have a 64-bit seconds based version,
> > > or alternatively a 64-bit nanoseconds version (with no
> > > extra seconds) that is also sufficient.
> > 
> > Unfortunately this a preexisting ABI which is common with other existing
> > architectures (see arch/x86/kernel/pvclock.c:pvclock_read_wallclock). I
> > cannot just change it.
> 
> Maybe we need a "struct pvclock_wall_clock_v2"?
> 
> In theory, 'u32 sec' takes us all the way until 2106, which is significantly
> longer away than the signed overflow in 2038, but it would still be nice
> to not introduce this limitation on ARM in the first place.
> 
> I'm not quite sure about how the split between pvclock_wall_clock and
> the delta works. Normally I'd expect that pvclock_wall_clock is the wallclock
> time as it was at boot, while delta is the number of expired nanoseconds
> since boot. However it is unclear why the latter has a longer range
> (539 years starting at boot, rather than 126 years starting in 1970).

Actually we already have a sec overflow field in struct shared_info on
the hypervisor side, called wc_sec_hi. I just need to make use of it in
Linux. See:

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=xen/include/public/xen.h;hb=HEAD

Thanks for raising my attention to the problem,

Stefano

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

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

[Jan Beulich]

>>> On 09.11.15 at 15:00,  wrote:
> Signed-off-by: Ian Campbell 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 3/3] xen/arm: set the system time in Xen via the XENPF_settime hypercall

[Stefano Stabellini]

On Thu, 5 Nov 2015, Arnd Bergmann wrote:
> On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote:
> > If Linux is running as dom0, call XENPF_settime to update the system
> > time in Xen on pvclock_gtod notifications.
> > 
> > Signed-off-by: Stefano Stabellini 
> > Signed-off-by: Ian Campbell 
> > ---
> >  arch/arm/xen/enlighten.c |   52 
> > +-
> >  1 file changed, 51 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index b6aea9c..0176db0 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -28,6 +28,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -123,6 +124,50 @@ static void xen_read_wallclock(struct timespec *ts)
> > set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
> >  }
> >  
> > +static int xen_pvclock_gtod_notify(struct notifier_block *nb,
> > +  unsigned long was_set, void *priv)
> > +{
> > +   /* Protected by the calling core code serialization */
> > +   static struct timespec next_sync;
> > +
> > +   struct xen_platform_op op;
> > +   struct timespec now;
> 
> Again, use timespec64

OK


> > +   now = __current_kernel_time();
> 
> We don't have __current_kernel_time64() yet, but it is trivial
> to add, just follow the example of
> current_kernel_time()/current_kernel_time64() and convert the
> existing __current_kernel_time() function into a static
> inline wrapper for the new __current_kernel_time64().

All right. I guess something like:

struct timespec64 __current_kernel_time64(void)
{
struct timekeeper *tk = _core.timekeeper;

return tk_xtime(tk);
}


> > +   /*
> > +* We only take the expensive HV call when the clock was set
> > +* or when the 11 minutes RTC synchronization time elapsed.
> > +*/
> > +   if (!was_set && timespec_compare(, _sync) < 0)
> > +   return NOTIFY_OK;
> > +
> > +   op.interface_version = XENPF_INTERFACE_VERSION;
> > +   op.cmd = XENPF_settime;
> > +   op.u.settime.secs = now.tv_sec;
> > +   op.u.settime.nsecs = now.tv_nsec;
> > +   op.u.settime.system_time = arch_timer_read_counter();
> > +   printk("GTOD: Setting to %ld.%ld at %lld\n",
> > +  (long)op.u.settime.secs,
> > +  (long)op.u.settime.nsecs,
> > +  (long long)op.u.settime.system_time);
> > +   (void)HYPERVISOR_dom0_op();
> 
> I guess we will also need a XENPF_settime64 interface, but at
> least we can get away with implementing only that one on ARM,
> while x86 will have to support both the 32-bit and 64-bit
> based variant.

We already have XENPF_settime64, I'll just use it instead.

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

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

[Dario Faggioli]

On Mon, 2015-11-09 at 14:00 +, Ian Campbell wrote:
> Signed-off-by: Ian Campbell 
>
Reviewed-by: Dario Faggioli 

And, while we're here, I've been thinking since a while to try
implementing an xl interface for these counters... How bad of an idea
is that?

Is something like that possible already via Boris' PMU work?

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
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xen: arm: perfc: count individual SGIs and PPIs

[Ian Campbell]

SPIs are too numerous and not indivcidually as interesting.

Make the exists #IPIS counter x86 specific.

Signed-off-by: Ian Campbell 
Cc: jbeul...@suse.com
---
 xen/arch/arm/gic.c   | 2 +-
 xen/arch/arm/irq.c   | 4 ++--
 xen/include/asm-arm/perfc_defn.h | 3 ++-
 xen/include/asm-x86/perfc_defn.h | 1 +
 xen/include/xen/perfc_defn.h | 1 -
 5 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1e1e5ba..b0b0999 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -609,7 +609,7 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi 
sgi)
 /* Lower the priority */
 struct irq_desc *desc = irq_to_desc(sgi);
 
-perfc_incr(ipis);
+perfc_incra(sgis, sgi);
 
 /* Lower the priority */
 gic_hw_ops->eoi_irq(desc);
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 1f38605..5031777 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -192,8 +192,8 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, 
int is_fiq)
 
 ASSERT(irq >= 16); /* SGIs do not come down this path */
 
-if (irq < 32)
-perfc_incr(ppis);
+if ( irq < 32 )
+perfc_incra(ppis, irq - 16);
 else
 perfc_incr(spis);
 
diff --git a/xen/include/asm-arm/perfc_defn.h b/xen/include/asm-arm/perfc_defn.h
index 69fabe7..3e21590 100644
--- a/xen/include/asm-arm/perfc_defn.h
+++ b/xen/include/asm-arm/perfc_defn.h
@@ -62,7 +62,8 @@ PERFCOUNTER(vtimer_phys_inject,   "vtimer: phys expired, 
injected")
 PERFCOUNTER(vtimer_phys_masked,   "vtimer: phys expired, masked")
 PERFCOUNTER(vtimer_virt_inject,   "vtimer: virt expired, injected")
 
-PERFCOUNTER(ppis, "#PPIs")
+PERFCOUNTER_ARRAY(sgis,   "#SGIs", 16)
+PERFCOUNTER_ARRAY(ppis,   "#PPIs", 16)
 PERFCOUNTER(spis, "#SPIs")
 PERFCOUNTER(guest_irqs,   "#GUEST-IRQS")
 
diff --git a/xen/include/asm-x86/perfc_defn.h b/xen/include/asm-x86/perfc_defn.h
index 9ef092e..c96a3f0 100644
--- a/xen/include/asm-x86/perfc_defn.h
+++ b/xen/include/asm-x86/perfc_defn.h
@@ -3,6 +3,7 @@
 /*#define __XEN_PERFC_DEFN_H__*/
 
 PERFCOUNTER_ARRAY(exceptions,   "exceptions", 32)
+PERFCOUNTER(ipis,   "#IPIs")
 
 #define VMX_PERF_EXIT_REASON_SIZE 56
 #define VMX_PERF_VECTOR_SIZE 0x20
diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
index 034c7d3..2b39fa9 100644
--- a/xen/include/xen/perfc_defn.h
+++ b/xen/include/xen/perfc_defn.h
@@ -10,7 +10,6 @@ PERFCOUNTER(calls_to_multicall, "calls to multicall")
 PERFCOUNTER(calls_from_multicall,   "calls from multicall")
 
 PERFCOUNTER(irqs,   "#interrupts")
-PERFCOUNTER(ipis,   "#IPIs")
 
 /* Generic scheduler counters (applicable to all schedulers) */
 PERFCOUNTER(sched_irq,  "sched: timer")
-- 
2.1.4


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

Re: [Xen-devel] [PATCHv1 3/3] x86/ept: defer the invalidation until the p2m lock is released

[Jan Beulich]

>>> On 06.11.15 at 18:37,  wrote:
> --- a/xen/arch/x86/mm/mm-locks.h
> +++ b/xen/arch/x86/mm/mm-locks.h
> @@ -263,14 +263,21 @@ declare_mm_lock(altp2mlist)
>   */
>  
>  declare_mm_rwlock(altp2m);
> -#define p2m_lock(p) \
> -{   \
> -if ( p2m_is_altp2m(p) ) \
> -mm_write_lock(altp2m, &(p)->lock);  \
> -else\
> -mm_write_lock(p2m, &(p)->lock); \
> -}
> -#define p2m_unlock(p) mm_write_unlock(&(p)->lock);
> +#define p2m_lock(p) \
> +do {\
> +if ( p2m_is_altp2m(p) ) \
> +mm_write_lock(altp2m, &(p)->lock);  \
> +else\
> +mm_write_lock(p2m, &(p)->lock); \
> +(p)->defer_flush++; \
> +} while (0)
> +#define p2m_unlock(p)   \
> +do {\
> +bool_t need_flush = --(p)->defer_flush == 0 && (p)->need_flush; \
> +mm_write_unlock(&(p)->lock);\
> +if (need_flush && (p)->flush)   \

Coding style. Also couldn't you imply (or ASSERT()) ->flush to be
non-NULL when need_flush is true?

> +(p)->flush(p);  \

The p2m lock guards EPT's synced_mask afaict, and hence dropping
the lock before calling ->flush() breaks things.

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -504,6 +504,26 @@ void p2m_free_ptp(struct p2m_domain *p2m, struct 
> page_info *pg)
>  return;
>  }
>  
> +DEFINE_PER_CPU(struct page_list_head, p2m_deferred_free_pages);

static

Jan


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

Re: [Xen-devel] [PATCH] xen: arm: perfc: count individual SGIs and PPIs

[Jan Beulich]

>>> On 09.11.15 at 15:01,  wrote:
> SPIs are too numerous and not indivcidually as interesting.
> 
> Make the exists #IPIS counter x86 specific.

I'd recommend not to - even if ARM doesn't want to use it, it's still a
pretty generic thing.

Jan


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

Re: [Xen-devel] [PATCH] x86/P2M: consolidate handling of types not requiring a valid MFN

[Jan Beulich]

>>> On 09.11.15 at 16:02,  wrote:
> On 09/11/15 14:52, Jan Beulich wrote:
>> As noted regarding the mixture of checks in p2m_pt_set_entry(),
>> introduce an new P2M type group allowing to be used everywhere we
> 
> "a new P2M"
> 
>> just care about accepting operations with either a valid MFN or a type
>> permitting to be used without (valid) MFN.
>>
>> Note that p2m_mmio_dm is not included in P2M_NO_MFN_TYPES, as for the
>> intended purpose that one ought to be treated similar to p2m_invalid
>> (perhaps the two should ultimately get folded anyway).
> 
> I seem to recall that p2m_invalid is still required to make the default
> ioreq server infrastructure work with older qemu's
> 
> We really should see about cleaning the two up however.
> 
>>
>> Signed-off-by: Jan Beulich 
> 
> You probably also want to note that PoD superpages are now INVALID_MFN
> rather than _mfn(0), but code wise,

Added a sentence.

> Reviewed-by: Andrew Cooper 

Thanks.

Jan


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

[Xen-devel] [PATCH] arm64: Add the missing license macro in fdt module

[fu . wei]

From: Fu Wei 

Signed-off-by: Fu Wei 
---
 grub-core/loader/arm64/fdt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/grub-core/loader/arm64/fdt.c b/grub-core/loader/arm64/fdt.c
index 5202c14..901bd7b 100644
--- a/grub-core/loader/arm64/fdt.c
+++ b/grub-core/loader/arm64/fdt.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 
+GRUB_MOD_LICENSE ("GPLv3+");
+
 static void *loaded_fdt;
 static void *fdt;
 
-- 
2.5.0


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

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

[George Dunlap]

On 09/11/15 14:00, Ian Campbell wrote:
> Signed-off-by: Ian Campbell 

Reviewed-by: George Dunlap 

> ---
>  xen/common/schedule.c| 1 +
>  xen/include/xen/perfc_defn.h | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 292e9a0..86d6cc0 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -896,6 +896,7 @@ long vcpu_yield(void)
>  struct vcpu * v=current;
>  spinlock_t *lock = vcpu_schedule_lock_irq(v);
>  
> +SCHED_STAT_CRANK(sched_yield);
>  SCHED_OP(VCPU2OP(v), yield, v);
>  vcpu_schedule_unlock_irq(lock, v);
>  
> diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
> index 76ee803..034c7d3 100644
> --- a/xen/include/xen/perfc_defn.h
> +++ b/xen/include/xen/perfc_defn.h
> @@ -16,6 +16,7 @@ PERFCOUNTER(ipis,   "#IPIs")
>  PERFCOUNTER(sched_irq,  "sched: timer")
>  PERFCOUNTER(sched_run,  "sched: runs through scheduler")
>  PERFCOUNTER(sched_ctx,  "sched: context switches")
> +PERFCOUNTER(sched_yield,"sched: vcpu yield")
>  PERFCOUNTER(schedule,   "sched: specific scheduler")
>  PERFCOUNTER(dom_init,   "sched: dom_init")
>  PERFCOUNTER(dom_destroy,"sched: dom_destroy")
> 


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

[Xen-devel] [PATCH] x86/P2M: consolidate handling of types not requiring a valid MFN

[Jan Beulich]

As noted regarding the mixture of checks in p2m_pt_set_entry(),
introduce an new P2M type group allowing to be used everywhere we
just care about accepting operations with either a valid MFN or a type
permitting to be used without (valid) MFN.

Note that p2m_mmio_dm is not included in P2M_NO_MFN_TYPES, as for the
intended purpose that one ought to be treated similar to p2m_invalid
(perhaps the two should ultimately get folded anyway).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -780,8 +780,7 @@ ept_set_entry(struct p2m_domain *p2m, un
 ept_entry = table + (gfn_remainder >> (i * EPT_TABLE_ORDER));
 }
 
-if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
- (p2mt == p2m_ram_paging_in) )
+if ( mfn_valid(mfn_x(mfn)) || p2m_allows_invalid_mfn(p2mt) )
 {
 int emt = epte_get_entry_emt(p2m->domain, gfn, mfn,
  i * EPT_TABLE_ORDER, , direct_mmio);
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -753,7 +753,7 @@ p2m_pod_zero_check_superpage(struct p2m_
 }
 
 /* Try to remove the page, restoring old mapping if it fails. */
-p2m_set_entry(p2m, gfn, _mfn(0), PAGE_ORDER_2M,
+p2m_set_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_2M,
   p2m_populate_on_demand, p2m->default_access);
 
 /* Make none of the MFNs are used elsewhere... for example, mapped
@@ -869,7 +869,7 @@ p2m_pod_zero_check(struct p2m_domain *p2
 }
 
 /* Try to remove the page, restoring old mapping if it fails. */
-p2m_set_entry(p2m, gfns[i], _mfn(0), PAGE_ORDER_4K,
+p2m_set_entry(p2m, gfns[i], _mfn(INVALID_MFN), PAGE_ORDER_4K,
   p2m_populate_on_demand, p2m->default_access);
 
 /* See if the page was successfully unmapped.  (Allow one refcount
@@ -1070,7 +1070,7 @@ p2m_pod_demand_populate(struct p2m_domai
  * NOTE: In a fine-grained p2m locking scenario this operation
  * may need to promote its locking from gfn->1g superpage
  */
-p2m_set_entry(p2m, gfn_aligned, _mfn(0), PAGE_ORDER_2M,
+p2m_set_entry(p2m, gfn_aligned, _mfn(INVALID_MFN), PAGE_ORDER_2M,
   p2m_populate_on_demand, p2m->default_access);
 return 0;
 }
@@ -1152,7 +1152,7 @@ remap_and_retry:
  * need promoting the gfn lock from gfn->2M superpage */
 gfn_aligned = (gfn>>order)<default_access);
 if ( tb_init_done )
 {
@@ -1210,8 +1210,8 @@ guest_physmap_mark_populate_on_demand(st
 }
 
 /* Now, actually do the two-way mapping */
-rc = p2m_set_entry(p2m, gfn, _mfn(0), order, p2m_populate_on_demand,
-   p2m->default_access);
+rc = p2m_set_entry(p2m, gfn, _mfn(INVALID_MFN), order,
+   p2m_populate_on_demand, p2m->default_access);
 if ( rc == 0 )
 {
 pod_lock(p2m);
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -571,7 +571,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m,
 }
 
 ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct);
-l3e_content = mfn_valid(mfn) 
+l3e_content = mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt)
 ? l3e_from_pfn(mfn_x(mfn),
p2m_type_to_flags(p2mt, mfn) | _PAGE_PSE)
 : l3e_empty();
@@ -607,8 +607,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m,
 p2m_get_iommu_flags(p2m_flags_to_type(l1e_get_flags(*p2m_entry)));
 old_mfn = l1e_get_pfn(*p2m_entry);
 
-if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct)
-|| p2m_is_paging(p2mt) )
+if ( mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt) )
 entry_content = p2m_l1e_from_pfn(mfn_x(mfn),
  p2m_type_to_flags(p2mt, mfn));
 else
@@ -644,7 +643,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m,
 }
 
 ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct);
-if ( mfn_valid(mfn) || p2m_is_pod(p2mt) )
+if ( mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt) )
 l2e_content = l2e_from_pfn(mfn_x(mfn),
p2m_type_to_flags(p2mt, mfn) |
_PAGE_PSE);
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -141,6 +141,11 @@ typedef unsigned int p2m_query_t;
 | p2m_to_mask(p2m_ram_logdirty) )
 #define P2M_SHARED_TYPES   (p2m_to_mask(p2m_ram_shared))
 
+/* Valid types not necessarily associated with a (valid) MFN. */
+#define P2M_INVALID_MFN_TYPES (P2M_POD_TYPES  \
+   | 

Re: [Xen-devel] [PATCH v8 09/21] xen/x86: set the vPMU interface based on the presence of a lapic

[Jan Beulich]

>>> On 06.11.15 at 17:05,  wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5143,6 +5143,7 @@ static hvm_hypercall_t *const 
> hvm_hypercall64_table[NR_hypercalls] = {
>  HYPERCALL(sysctl),
>  HYPERCALL(domctl),
>  HYPERCALL(tmem_op),
> +HYPERCALL(xenpmu_op),
>  [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
>  };
>  
> @@ -5164,6 +5165,7 @@ static hvm_hypercall_t *const 
> hvm_hypercall32_table[NR_hypercalls] = {
>  HYPERCALL(sysctl),
>  HYPERCALL(domctl),
>  HYPERCALL(tmem_op),
> +HYPERCALL(xenpmu_op),
>  [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
>  };

I don't think this should be done now; instead this should imo be an
effect of eventually folding the two tables. With this dropped
Acked-by: Jan Beulich .

Jan


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

[Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

[Ian Campbell]

Signed-off-by: Ian Campbell 
---
 xen/common/schedule.c| 1 +
 xen/include/xen/perfc_defn.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 292e9a0..86d6cc0 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -896,6 +896,7 @@ long vcpu_yield(void)
 struct vcpu * v=current;
 spinlock_t *lock = vcpu_schedule_lock_irq(v);
 
+SCHED_STAT_CRANK(sched_yield);
 SCHED_OP(VCPU2OP(v), yield, v);
 vcpu_schedule_unlock_irq(lock, v);
 
diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
index 76ee803..034c7d3 100644
--- a/xen/include/xen/perfc_defn.h
+++ b/xen/include/xen/perfc_defn.h
@@ -16,6 +16,7 @@ PERFCOUNTER(ipis,   "#IPIs")
 PERFCOUNTER(sched_irq,  "sched: timer")
 PERFCOUNTER(sched_run,  "sched: runs through scheduler")
 PERFCOUNTER(sched_ctx,  "sched: context switches")
+PERFCOUNTER(sched_yield,"sched: vcpu yield")
 PERFCOUNTER(schedule,   "sched: specific scheduler")
 PERFCOUNTER(dom_init,   "sched: dom_init")
 PERFCOUNTER(dom_destroy,"sched: dom_destroy")
-- 
2.1.4


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

Re: [Xen-devel] [BUG] Boot failures with mpt2sas / Intel RMS25JB080 module

[Sreekanth Reddy]

Hi Matthew,

Can you please try with mpt2sas driver's max_msix_vectors set to one.

~Sreekanth

On Fri, Nov 6, 2015 at 11:38 PM, Matthew Vernon  wrote:
> Hi,
>
> [These lists are in the MAINTAINERS file for mpt2sas; I hope this is
> the correct place to report this problem. Xen-devel CCd as this is
> failing on trying to boot Xen]
>
> When booting Xen, mpt2sas finds my Intel RMS25JB080, but fails to load
> it correctly.
>
> This is a Debian jessie (stable) system, kernel version
> 3.16.0-4-amd64, Xen version 4.4.1.
>
> Relevant snippet of log output of failed boot:
>
> [   64.095008] mpt2sas0: reply_post_free pool: pci_pool_alloc failed
> [   64.535255] mpt2sas0: failure at 
> /build/linux-xkTWug/linux-3.16.7-ckt11/drivers/scsi/mpt2sas/mpt2sas_scsih.c:8234/_scsih_probe()!
>
> ...it then fails to find any of my attached drives, so cannot boot,
> and I get dumped in the initramfs.
>
> Having googled a bit, I tried pci=realloc=off on the kernel
> command-line, as well as swiotlb=26422 ; neither of them changed the
> failure mode
>
> Booting bare-metal does work; relevant snippet of log output of
> successful (i.e. bare-metal) boot:
>
> [3.977037] mpt2sas0: diag reset: SUCCESS
> [4.178627] mpt2sas0: Allocated physical memory: size(17390 kB)
> [4.178630] mpt2sas0: Current Controller Queue Depth(7931), Max Controller 
> Queue Depth(8192)
> [4.178631] mpt2sas0: Scatter Gather Elements per IO(128)
> [4.409752] mpt2sas0: LSISAS2308: FWVersion(20.00.02.00), 
> ChipRevision(0x05), BiosVersion(07.39.00.00)
> [4.409755] mpt2sas0: Intel(R) Integrated RAID Module RMS25JB080
> [4.409756] mpt2sas0: Protocol=(Initiator), 
> Capabilities=(Raid,TLR,EEDP,Snapshot Buffer,Diag Trace Buffer,Task Set 
> Full,NCQ)
> [4.409846] mpt2sas0: sending port enable !!
> ...
> [5.941978] mpt2sas0: host_add: handle(0x0001), 
> sas_addr(0x5001e67c17ff5000), phys(8)
> [5.980601] device-mapper: uevent: version 1.0.3
> [5.980773] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: 
> dm-de...@redhat.com
> [   11.823480] mpt2sas0: port enable: SUCCESS
>
> (and then it finds the attached disks)
>
> Fuller outputs:
>
> i) bare-metal boot dmesg:
> http://www-uxsup.csx.cam.ac.uk/~mcv21/debug/bare_metal_dmesg
>
> ii) output from failed Xen boot (captured over a serial line with
> earlyprintk=xen and loglvl=all guest_loglvl=all):
> http://www-uxsup.csx.cam.ac.uk/~mcv21/debug/failedboot-output-2
>
> iii) kernel config (stock Debian):
> http://www-uxsup.csx.cam.ac.uk/~mcv21/debug/config-3.16.0-4-amd64
>
> iv) lspci -vvv output:
> http://www-uxsup.csx.cam.ac.uk/~mcv21/debug/lspcivvv
>
> Regards,
>
> Matthew

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

Re: [Xen-devel] Critique of the Xen Security Process

[Doug Goldstein]

On 11/6/15 11:22 AM, Joanna Rutkowska wrote:
> Hello,
> 
> Recently Xen has released the XSA-148 advisory [1] addressing a fatal bug in 
> the
> hypervisor. The bug has been lurking there for the last 7 years! We, the Qubes
> OS Project, have commented on this in our Security Bulletin #22 [2]. And far
> from enthusiastic commentary that was (FWIW, it was me who wrote this QSB, as
> evidenced in the commits log, in case some from the Xen community would like 
> to
> direct their rage towards a particular human being ;) Ian Jackson then wrote a
> response on the Xen blog [3]. I was then asked to share some more thoughts 
> about
> how I thought Xen could actually improve its security process [4]. So, I share
> some these below:
> 
> 1. First of all, I wish Xen was somehow more defensively coded. To provide 
> some
> examples:
> 
> a. In XSA-109 [5] there was a problem with the hypervisor dereferencing a NULL
> pointer. The problem was fixed by the Xen Security Team by applying a patch
> which (hopefully) made sure the execution path that lead to this NULL pointer
> dereferencing code was never taken. Back then I suggested (on the Xen
> pre-disclosure list) to make this patch more explicit though:
> 
>> On Wed, Jan 21, 2015 at 02:31:51PM +0100, Joanna Rutkowska wrote:
>> (...)
>>>
>>> Wouldn't it be prudent to also check if:
>>>
>>> (v->arch.paging.mode>{write_guest_entry,cmpxchg_guest_entry} != NULL)
>>>
>>> ... in the two affected functions, just before derefing these function
>>> pointers?
>>>
>>> Going even a step further: how about replacing all
>>> function-pointer-based calls with macros that first validates the
>>> pointer before derefing it? At least when the system doesn't have SMEP?
>>>
> 
> ...to which I got a reply from one of the Xen Security Team engineers that the
> above might perhaps be justified in debug builds only, followed by a standard:
> "feel free to contribute a patch".
> 
> b. The XSA-123 [6] was another critical security bug in Xen, this time 
> resulting
> from one of the hypervisor developer's fetish to use an absolutely confusing
> construct in order to save a few modest bytes in a structure which might have
> been allocated by the system maybe a few tens of times at best. Even more
> worrying was the way how Xen Security Team decided to fix the bug: again by
> modifying some condition in the code further up the execution path, with the
> hopes that this time they would ensure this puzzling construct would always be
> used properly. We wrote more about this in our QSB #18 [7].
> 
> c. Finally, the way how Xen fixed the recent XSA-148 looks also very reactive,
> IMHO. With a bug of this calibre, I would expect Xen to carefully review and
> augment all its PV memory virtualization code with additional checks 
> (ASSERTs),
> ensuring certain invariants are always satisfied. Such as e.g. that none of 
> the
> pages containing PDEs or PTEs are becoming writeable by the VM.
> 
> I can't help but have a feeling that some of the Xen developers seem to be
> overconfident in their belief they can fully understand all the possible
> execution paths in their code. Well, the XSAs quoted above are an indisputable
> prove that this is not quite always the case. Realizing that, each developer 
> by
> themselves, might be a great step towards a more secure hypervisor...
> 
> 2. Another security-related aspect of the Xen project is how it totally 
> ignores
> problems related to the build process security. Those who don't believe me
> should grep the sources for wget, which is now disguised as "FETCHER" shell
> variable... (so grep for "FETCHER" string)
> 
> I feel embarrassed that I need to explain, at the end of 2015, why the build
> process of any serious software project should not blindly download unsigned
> components (sources) from the Internet, especially if it is about to execute
> Makefiles from these components a moment later... Come on, guys!

I'll echo this sentiment as well. Most distro packagers will dislike
this and need to work around some of this behavior in their respective
distros. Project Raisin is aiming to help with this but it doesn't seem
to have a lot of community effort behind it and it too attempts to
install dependencies on my machine and wants to be run with sudo.


> 
> (Of course we have been forced to get around this gapping security whole in
> Qubes OS [8] ourselves, sadly with a method that is not well suited for
> upstreaming).
> 
> 3. Another thing is, of course: stop adding features to the core hypervisor. 
> We
> really need Xen to finally mature, stabilize, and for its development process 
> to
> be slowing down over time (just the bug fixes). We need a long-term-supported
> hypervisor, which doesn't change with subsonic speed. This would allow this 
> core
> code to be widely audited by many experts. If some users want features, these
> should perhaps be maintained as additional modules (no, I don't mean 
> dynamically
> loaded modules, just compile-time 

Re: [Xen-devel] Critique of the Xen Security Process

[chris]

+1... so many great points here that ive thought many times its almost as
if i could have written it

great post!

chris

On Fri, Nov 6, 2015 at 12:22 PM, Joanna Rutkowska <
joa...@invisiblethingslab.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> Recently Xen has released the XSA-148 advisory [1] addressing a fatal bug
> in the
> hypervisor. The bug has been lurking there for the last 7 years! We, the
> Qubes
> OS Project, have commented on this in our Security Bulletin #22 [2]. And
> far
> from enthusiastic commentary that was (FWIW, it was me who wrote this QSB,
> as
> evidenced in the commits log, in case some from the Xen community would
> like to
> direct their rage towards a particular human being ;) Ian Jackson then
> wrote a
> response on the Xen blog [3]. I was then asked to share some more thoughts
> about
> how I thought Xen could actually improve its security process [4]. So, I
> share
> some these below:
>
> 1. First of all, I wish Xen was somehow more defensively coded. To provide
> some
> examples:
>
> a. In XSA-109 [5] there was a problem with the hypervisor dereferencing a
> NULL
> pointer. The problem was fixed by the Xen Security Team by applying a patch
> which (hopefully) made sure the execution path that lead to this NULL
> pointer
> dereferencing code was never taken. Back then I suggested (on the Xen
> pre-disclosure list) to make this patch more explicit though:
>
> > On Wed, Jan 21, 2015 at 02:31:51PM +0100, Joanna Rutkowska wrote:
> > (...)
> >>
> >> Wouldn't it be prudent to also check if:
> >>
> >> (v->arch.paging.mode>{write_guest_entry,cmpxchg_guest_entry} != NULL)
> >>
> >> ... in the two affected functions, just before derefing these function
> >> pointers?
> >>
> >> Going even a step further: how about replacing all
> >> function-pointer-based calls with macros that first validates the
> >> pointer before derefing it? At least when the system doesn't have SMEP?
> >>
>
> ...to which I got a reply from one of the Xen Security Team engineers that
> the
> above might perhaps be justified in debug builds only, followed by a
> standard:
> "feel free to contribute a patch".
>
> b. The XSA-123 [6] was another critical security bug in Xen, this time
> resulting
> from one of the hypervisor developer's fetish to use an absolutely
> confusing
> construct in order to save a few modest bytes in a structure which might
> have
> been allocated by the system maybe a few tens of times at best. Even more
> worrying was the way how Xen Security Team decided to fix the bug: again by
> modifying some condition in the code further up the execution path, with
> the
> hopes that this time they would ensure this puzzling construct would
> always be
> used properly. We wrote more about this in our QSB #18 [7].
>
> c. Finally, the way how Xen fixed the recent XSA-148 looks also very
> reactive,
> IMHO. With a bug of this calibre, I would expect Xen to carefully review
> and
> augment all its PV memory virtualization code with additional checks
> (ASSERTs),
> ensuring certain invariants are always satisfied. Such as e.g. that none
> of the
> pages containing PDEs or PTEs are becoming writeable by the VM.
>
> I can't help but have a feeling that some of the Xen developers seem to be
> overconfident in their belief they can fully understand all the possible
> execution paths in their code. Well, the XSAs quoted above are an
> indisputable
> prove that this is not quite always the case. Realizing that, each
> developer by
> themselves, might be a great step towards a more secure hypervisor...
>
> 2. Another security-related aspect of the Xen project is how it totally
> ignores
> problems related to the build process security. Those who don't believe me
> should grep the sources for wget, which is now disguised as "FETCHER" shell
> variable... (so grep for "FETCHER" string)
>
> I feel embarrassed that I need to explain, at the end of 2015, why the
> build
> process of any serious software project should not blindly download
> unsigned
> components (sources) from the Internet, especially if it is about to
> execute
> Makefiles from these components a moment later... Come on, guys!
>
> (Of course we have been forced to get around this gapping security whole in
> Qubes OS [8] ourselves, sadly with a method that is not well suited for
> upstreaming).
>
> 3. Another thing is, of course: stop adding features to the core
> hypervisor. We
> really need Xen to finally mature, stabilize, and for its development
> process to
> be slowing down over time (just the bug fixes). We need a
> long-term-supported
> hypervisor, which doesn't change with subsonic speed. This would allow
> this core
> code to be widely audited by many experts. If some users want features,
> these
> should perhaps be maintained as additional modules (no, I don't mean
> dynamically
> loaded modules, just compile-time included), preferably in separate repos.
>
> Perhaps also to move all the non-hypervisor code, 

Re: [Xen-devel] Xen 4.7 Development Update

[Juergen Gross]

On 09.11.2015 17:15, Wei Liu wrote:

I accidentally deleted my old script, so I take the chance to change
the tracking email a bit. Now this email only tracks big items for
xen.git tree. Please reply for items you woulk like to see in 4.7 so
that people have an idea what is going on and prioritise accordingly.




= Projects =

== Toolstack ==

*  Libxc support for building large PV domains
   -  Juergen Gross


Could you make that "... for building and migrating ..." please?



*  PV USB passthrough
   -  Chunyan Liu

*  HVM USB passthrough
   -  George Dunlap


*  QEMU based pvUSB backend
   -  Juergen Gross


Juergen

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

[Xen-devel] [PATCH] arm64: Add the introduction of xen boot commands in docs/grub.texi

[fu . wei]

From: Fu Wei 

xen_hypervisor
xen_linux
xen_initrd
xen_xsm

Signed-off-by: Fu Wei 
---
 docs/grub.texi | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/docs/grub.texi b/docs/grub.texi
index db765a3..1df3db2 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3857,6 +3857,11 @@ you forget a command, you can run the command 
@command{help}
 @comment * vbeinfo:: List available video modes
 * verify_detached:: Verify detached digital signature
 * videoinfo::   List available video modes
+@comment * xen_*::  Xen boot commands
+* xen_hypervisor::  Load xen hypervisor binary
+* xen_linux::   Load dom0 kernel for xen hypervisor
+* xen_initrd::  Load dom0 initrd for dom0 kernel
+* xen_xsm:: Load xen security module for xen hypervisor
 @end menu
 
 
@@ -5120,6 +5125,39 @@ successfully.  If validation fails, it is set to a 
non-zero value.
 List available video modes. If resolution is given, show only matching modes.
 @end deffn
 
+@node xen_hypervisor
+@subsection xen_hypervisor
+
+@deffn Command xen_hypervisor file  [arguments] @dots{}
+Load a Xen hypervisor binary from @var{file}. The rest of the line is passed
+verbatim as the @dfn{kernel command-line}. Any other binaries must be
+reloaded after using this command.
+@end deffn
+
+@node xen_linux
+@subsection xen_linux
+
+@deffn Command xen_linux file [arguments]
+Load a dom0 kernel image for xen hypervisor at the booting process of xen.
+The rest of the line is passed verbatim as the module command line.
+@end deffn
+
+@node xen_initrd
+@subsection xen_initrd
+
+@deffn Command xen_initrd file
+Load a initrd image for dom0 kernel at the booting process of xen.
+@end deffn
+
+@node xen_xsm
+@subsection xen_xsm
+
+@deffn Command xen_xsm file
+Load a xen security module for xen hypervisor at the booting process of xen.
+See @uref{http://wiki.xen.org/wiki/XSM} for more detail.
+@end deffn
+
+
 @node Networking commands
 @section The list of networking commands
 
-- 
2.5.0


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  3 host-install(3) broken REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 59254
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)  broken REGR. vs. 59254
 test-amd64-amd64-xl-xsm   3 host-install(3) broken REGR. vs. 59254
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)  broken REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 21 guest-start/debian.repeat fail REGR. vs. 59254
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
59254
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 59254
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 59254
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qcow2 3 host-install(3)   broken baseline untested
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-raw6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline 
untested
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host   fail baseline untested
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host   fail baseline untested
 test-armhf-armhf-libvirt-qcow2  6 xen-boot  fail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 linuxce5c2d2c256a4c8b523036537cd6be2d6af8f69d
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  124 days
Failing since 59348  2015-07-10 04:24:05 Z  123 

Re: [Xen-devel] [PATCH v2] symbols.c: Avoid warn_unused_result build failure on fgets().

[Haozhong Zhang]

On 11/09/15 11:06, Riku Voipio wrote:
> In commit:
> 
> d37d63d symbols: prefix static symbols with their source file names
> 
> An unchecked fgets was added. This causes a compile error at least
> on ubuntu utopic:
> 
> symbols.c: In function 'read_symbol':
> symbols.c:181:3: error: ignoring return value of 'fgets', declared with
> attribute warn_unused_result [-Werror=unused-result]
>fgets(str, 500, in); /* discard rest of line */
>^
> 
> Paper over the warning by checking the return value in the if statement.
> 
> Cc: Jan Beulich 
> Signed-off-by: Riku Voipio 

Tested on Ubuntu 14.04.3 with GCC 4.8.4 and no 'warn_unused_result'
warnings any more.

Tested-by: Haozhong Zhang 

> ---
>  xen/tools/symbols.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/tools/symbols.c b/xen/tools/symbols.c
> index dbf6a1a..3b8fa39 100644
> --- a/xen/tools/symbols.c
> +++ b/xen/tools/symbols.c
> @@ -177,8 +177,8 @@ static int read_symbol(FILE *in, struct sym_entry *s)
>   rc = 0;
>  
>   skip_tail:
> - if (input_format == fmt_sysv)
> - fgets(str, 500, in); /* discard rest of line */
> + if ((input_format == fmt_sysv) && fgets(str, 500, in) == NULL)
> + return rc; /* discard rest of line and ignore errors */
>  
>   return rc;
>  }
> -- 
> 2.6.2
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 63340

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 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  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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

version targeted for testing:
 libvirt  edc88e2084ec94c5757b880d5fe7775e7533b5aa
baseline version:
 libvirt  3c7590e0a435d833895fc7b5be489e53e223ad95

Last test of basis63340  2015-10-28 04:19:47 Z   12 days
Failing since 63352  2015-10-29 04:20:29 Z   11 days   10 attempts
Testing same since63766  2015-11-07 18:27:27 Z2 days2 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Daniel Veillard 
  Jiri Denemark 
  John Ferlan 
  Laine Stump 
  Luyao Huang 
  Maxim Perevedentsev 
  Michal Privoznik 
  Michel Normand 
  Peter Krempa 
  Roman Bogorodskiy 

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  fail
 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 blocked 
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 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.

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

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

[Xen-devel] [PATCH] arm64: clean up a useless variable in xen_boot.c

[fu . wei]

From: Fu Wei 

This patch delete "file_name_index" variable and related comment.
They are for xen_module command which has been deleted.

Signed-off-by: Fu Wei 
---
 grub-core/loader/arm64/xen_boot.c | 19 +--
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/grub-core/loader/arm64/xen_boot.c 
b/grub-core/loader/arm64/xen_boot.c
index fc5bb0c..d1a2189 100644
--- a/grub-core/loader/arm64/xen_boot.c
+++ b/grub-core/loader/arm64/xen_boot.c
@@ -136,16 +136,10 @@ xen_boot_address_align (grub_addr_t start, grub_size_t 
align)
   return (align ? (ALIGN_UP (start, align)) : start);
 }
 
-/* Parse the option of xen_module command. For now, we support
-   (1) --type 
-   We also set up the type of module in this function.
-   If there are some "--type" options in the command line,
-   we make a custom compatible stream in this function. */
+/* set module type according to command name. */
 static grub_err_t
-set_module_type (grub_command_t cmd, struct xen_boot_binary *module, int 
*file_name_index)
+set_module_type (grub_command_t cmd, struct xen_boot_binary *module)
 {
-  *file_name_index = 0;
-
   if (!grub_strcmp (cmd->name, "xen_linux"))
 module->node_info.type = MODULE_IMAGE;
   else if (!grub_strcmp (cmd->name, "xen_initrd"))
@@ -440,7 +434,6 @@ grub_cmd_xen_module (grub_command_t cmd, int argc, char 
*argv[])
 {
 
   struct xen_boot_binary *module = NULL;
-  int file_name_index = 0;
   grub_file_t file = 0;
 
   if (!argc)
@@ -462,8 +455,7 @@ grub_cmd_xen_module (grub_command_t cmd, int argc, char 
*argv[])
 return grub_errno;
 
   /* process all the options and get module type */
-  if (set_module_type (cmd, module, _name_index) !=
-  GRUB_ERR_NONE)
+  if (set_module_type (cmd, module) != GRUB_ERR_NONE)
 goto fail;
   switch (module->node_info.type)
 {
@@ -491,12 +483,11 @@ grub_cmd_xen_module (grub_command_t cmd, int argc, char 
*argv[])
module->name, module->node_info.compat_string,
module->node_info.compat_string_size);
 
-  file = grub_file_open (argv[file_name_index]);
+  file = grub_file_open (argv[0]);
   if (!file)
 goto fail;
 
-  xen_boot_binary_load (module, file, argc - file_name_index,
-   argv + file_name_index);
+  xen_boot_binary_load (module, file, argc, argv);
   if (grub_errno == GRUB_ERR_NONE)
 grub_list_push (GRUB_AS_LIST_P (_head), GRUB_AS_LIST (module));
 
-- 
2.5.0


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

Re: [Xen-devel] [PATCH v2 2/3] XENVER_build_id: Provide ld-embedded build-ids

[Ross Lagerwall]

On 11/06/2015 07:36 PM, Konrad Rzeszutek Wilk wrote:

From: Martin Pohlack 

The mechanism to get this is via the XENVER_build_id and
we add a new subsequent sub-command to retrieve the
binary build-id. The hypercall allows an arbitrary
size (the buffer and len is provided to the hypervisor).

Note that one can also retrieve the value by 'readelf -h xen-syms'.

For EFI builds we re-use the same build-id that the xen-syms
was built with.

Note that there are no changes to the XSM files (dummy.c
and hooks.c) as the priviliged subops fall in the default case.

Since the new sub-ops provides the len parameter in the
arguments to the hypercall we have to modify libxc to allow
copying the arguments before the hypercall. We provide a
new macro that modifies the bounce structure to change
the direction.


snip

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d4e507a..17a4830 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -109,15 +109,19 @@ $(TARGET)-syms: prelink.o xen.lds 
$(BASEDIR)/common/symbols-dummy.o


The above invocation of ld also needs to pass "--build-id=sha1".
Otherwise, the first invocation of tools/symbols has 
__note_gnu_build_id_end == __note_gnu_build_id_start, which may cause 
the size of the symbol table to change later when there is actually a 
build id (presumably due to the way it is compressed?) ultimately 
resulting in incorrect values in the symbol table.



$(NM) -pa --format=sysv $(@D)/.$(@F).0 \
| $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
-   $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+   $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
| $(BASEDIR)/tools/symbols --sysv --sort --warn-dup 
>$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
-   $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+   $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
$(@D)/.$(@F).1.o -o $@
rm -f $(@D)/.$(@F).[0-9]*



--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH 3/3] xen/arm: set the system time in Xen via the XENPF_settime hypercall

[Arnd Bergmann]

On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote:
> On Thu, 5 Nov 2015, Arnd Bergmann wrote:
> > On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote:
> > > + now = __current_kernel_time();
> > 
> > We don't have __current_kernel_time64() yet, but it is trivial
> > to add, just follow the example of
> > current_kernel_time()/current_kernel_time64() and convert the
> > existing __current_kernel_time() function into a static
> > inline wrapper for the new __current_kernel_time64().
> 
> All right. I guess something like:
> 
> struct timespec64 __current_kernel_time64(void)
> {
>   struct timekeeper *tk = _core.timekeeper;
> 
>   return tk_xtime(tk);
> }

Yes, exactly.

Just to make sure that this is actually the correct interface
that you want to call:

__current_kernel_time{,64}() is the fastest interface we have
to get an approximation of the current time, while ignoring
all of the locking.

Is is possible that you instead want ktime_get_real_ts64(),
which gives you the time as precise as the kernel knows it,
but uses locking?

> > > + /*
> > > +  * We only take the expensive HV call when the clock was set
> > > +  * or when the 11 minutes RTC synchronization time elapsed.
> > > +  */
> > > + if (!was_set && timespec_compare(, _sync) < 0)
> > > + return NOTIFY_OK;
> > > +
> > > + op.interface_version = XENPF_INTERFACE_VERSION;
> > > + op.cmd = XENPF_settime;
> > > + op.u.settime.secs = now.tv_sec;
> > > + op.u.settime.nsecs = now.tv_nsec;
> > > + op.u.settime.system_time = arch_timer_read_counter();
> > > + printk("GTOD: Setting to %ld.%ld at %lld\n",
> > > +(long)op.u.settime.secs,
> > > +(long)op.u.settime.nsecs,
> > > +(long long)op.u.settime.system_time);
> > > + (void)HYPERVISOR_dom0_op();
> > 
> > I guess we will also need a XENPF_settime64 interface, but at
> > least we can get away with implementing only that one on ARM,
> > while x86 will have to support both the 32-bit and 64-bit
> > based variant.
> 
> We already have XENPF_settime64, I'll just use it instead.

Ok, great! Then we just need to find a volunteer who can
do the same thing on x86, with the fallback to XENPF_settime
that they need for older hosts.

Arnd

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

Re: [Xen-devel] [PATCH 3/3] xen/arm: set the system time in Xen via the XENPF_settime hypercall

[Stefano Stabellini]

On Mon, 9 Nov 2015, Stefano Stabellini wrote:
> On Mon, 9 Nov 2015, Arnd Bergmann wrote:
> > On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote:
> > > On Thu, 5 Nov 2015, Arnd Bergmann wrote:
> > > > On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote:
> > > > > + now = __current_kernel_time();
> > > > 
> > > > We don't have __current_kernel_time64() yet, but it is trivial
> > > > to add, just follow the example of
> > > > current_kernel_time()/current_kernel_time64() and convert the
> > > > existing __current_kernel_time() function into a static
> > > > inline wrapper for the new __current_kernel_time64().
> > > 
> > > All right. I guess something like:
> > > 
> > > struct timespec64 __current_kernel_time64(void)
> > > {
> > >   struct timekeeper *tk = _core.timekeeper;
> > > 
> > >   return tk_xtime(tk);
> > > }
> > 
> > Yes, exactly.
> > 
> > Just to make sure that this is actually the correct interface
> > that you want to call:
> > 
> > __current_kernel_time{,64}() is the fastest interface we have
> > to get an approximation of the current time, while ignoring
> > all of the locking.
> > 
> > Is is possible that you instead want ktime_get_real_ts64(),
> > which gives you the time as precise as the kernel knows it,
> > but uses locking?
> 
> I am not 100% sure. Can I call ktime_get_real_ts64 from a
> pvclock_gtod notifier_call function?

It doesn't look like it: we would be getting the tk_core seqcount twice.

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

Re: [Xen-devel] [PATCH 3/3] xen/arm: set the system time in Xen via the XENPF_settime hypercall

[Stefano Stabellini]

On Mon, 9 Nov 2015, Arnd Bergmann wrote:
> On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote:
> > On Thu, 5 Nov 2015, Arnd Bergmann wrote:
> > > On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote:
> > > > +   now = __current_kernel_time();
> > > 
> > > We don't have __current_kernel_time64() yet, but it is trivial
> > > to add, just follow the example of
> > > current_kernel_time()/current_kernel_time64() and convert the
> > > existing __current_kernel_time() function into a static
> > > inline wrapper for the new __current_kernel_time64().
> > 
> > All right. I guess something like:
> > 
> > struct timespec64 __current_kernel_time64(void)
> > {
> > struct timekeeper *tk = _core.timekeeper;
> > 
> > return tk_xtime(tk);
> > }
> 
> Yes, exactly.
> 
> Just to make sure that this is actually the correct interface
> that you want to call:
> 
> __current_kernel_time{,64}() is the fastest interface we have
> to get an approximation of the current time, while ignoring
> all of the locking.
> 
> Is is possible that you instead want ktime_get_real_ts64(),
> which gives you the time as precise as the kernel knows it,
> but uses locking?

I am not 100% sure. Can I call ktime_get_real_ts64 from a
pvclock_gtod notifier_call function?

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

Re: [Xen-devel] [RFC 00/29] Incomplete Kconfig conversion

[Doug Goldstein]

On 11/9/15 9:06 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 06, 2015 at 05:11:51PM +0100, Ian Campbell wrote:
>> On Tue, 2015-10-06 at 10:58 -0500, Doug Goldstein wrote:
>>> You stated this better than I did. My goal is not to necessarily make
>>> this like the Linux kernel where users toggle on different bits at a
>>> whim but more for developers and companies shipping Xen, basically those
>>> with specialized environments could use this to upstream more code and
>>> have it disabled by default.
>>
>> This last bit will need some care and consideration, since such options are
>> liable to lead to the sort of fragmentation I'm worried about i.e. people
>> thinking they can turn them on outside the specialized environments and be
>> supported in doing so. But I think we can deal with that after this initial
>> transition. It should dovetail quite nicely with the "feature lifecycle"
>> stuff being discussed elsewhere.
>>
>>> The current patchset only exposes KEXEC as a user facing option because
>>> its currently a user facing option in the source tree. I would not
>>> expand the list of user facing options past that. I consider adding more
>>> outside of the scope of this work and something that would happen after
>>> this series lands on a case by case basis.
>>>
>>> My ultimate goal with this initial work is to get all the developer
>>> knobs in one place because currently they are spread around as Makefile
>>> defines or defines in a header file and get a little bit of code
>>> comments around them.
>>
>> Great!
> 
> Sooo is there another patchset on its way? I was thinking to base
> some of the xSplice development on this, and also make tmem configurable
> as well.

Yes. Apologizes on the delay. I'll get on it today.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/6] relocator: Do not use memory region if its starta is smaller than size

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 21.07.2015 08:42, Andrei Borzenkov wrote:
> On Mon, Jul 20, 2015 at 5:35 PM, Daniel Kiper  wrote:
>> malloc_in_range() should not use memory region if its starta is smaller
>> than size. Otherwise target wraps around and points to region which is
>> usually not a RAM, e.g.:
>>
>> loader/multiboot.c:93: segment 0: paddr=0x80, memsz=0x3f80, 
>> vaddr=0x80
>> lib/relocator.c:1241: min_addr = 0x0, max_addr = 0x, target 
>> = 0x80
>> lib/relocator.c:434: trying to allocate in 0x80-0x 
>> aligned 0x1 size 0x3f80
>> lib/relocator.c:434: trying to allocate in 0x0-0x80 aligned 0x1 size 
>> 0x3f80
>> lib/relocator.c:434: trying to allocate in 0x0-0x aligned 
>> 0x1 size 0x3f80
>> lib/relocator.c:1188: allocated: 0xc07f+0x3f80
>> lib/relocator.c:1277: allocated 0xc07f/0x80
>>
>> Signed-off-by: Daniel Kiper 
>> ---
>>  grub-core/lib/relocator.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/grub-core/lib/relocator.c b/grub-core/lib/relocator.c
>> index f759c7f..4eee0c5 100644
>> --- a/grub-core/lib/relocator.c
>> +++ b/grub-core/lib/relocator.c
>> @@ -748,7 +748,7 @@ malloc_in_range (struct grub_relocator *rel,
>>   /* Found an usable address.  */
>>   goto found;
>>   }
>> -   if (isinsidebefore && !isinsideafter && !from_low_priv)
>> +   if (isinsidebefore && !isinsideafter && !from_low_priv && starta >= 
>> size)
> 
> That's too late, we need to check end of region on previous iteration.
> Consider region of 128 bytes, requested size 129 and alignment 256.
> Than starta still ends up high in memory.
> 
Agreed, we need a check earlier. It makes sense to split this block with
an if (from_low_priv) as both flows are completely separate and
splitting them will make it more readable
>>   {
>> target = starta - size;
>> if (target > end - size)
>> --
>> 1.7.10.4
>>
>>
>> ___
>> Grub-devel mailing list
>> grub-de...@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
> 




signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 2/2] arm: export platform_op XENPF_settime64

[sstabellini]

From: Stefano Stabellini 

Call update_domain_wallclock_time at domain initialization, specifically
in arch_set_info_guest for vcpu0, like we do on x86.
Set time_offset_seconds to the number of seconds between phisical boot
and domain initialization: it is going to be used to get/set the
wallclock time.
Add time_offset_seconds to system_time when before calling do_settime,
so that system_time actually accounts for all the time in nsec between
machine boot and when the wallclock was set.



Signed-off-by: Stefano Stabellini 
CC: dgde...@tycho.nsa.gov

---

Changes in v2:
- drop XENPF_settime32
- set time_offset_seconds
- modify xen/xsm/flask/hooks.c
---
 xen/arch/arm/Makefile |1 +
 xen/arch/arm/domain.c |9 ++
 xen/arch/arm/platform_hypercall.c |   62 +
 xen/arch/arm/traps.c  |1 +
 xen/arch/arm/vtimer.c |1 -
 xen/include/asm-arm/time.h|2 ++
 xen/include/xsm/dummy.h   |   12 +++
 xen/include/xsm/xsm.h |   13 
 xen/xsm/flask/hooks.c |2 +-
 9 files changed, 89 insertions(+), 14 deletions(-)
 create mode 100644 xen/arch/arm/platform_hypercall.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 1ef39f7..240aa29 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -23,6 +23,7 @@ obj-y += percpu.o
 obj-y += guestcopy.o
 obj-y += physdev.o
 obj-y += platform.o
+obj-y += platform_hypercall.o
 obj-y += setup.o
 obj-y += bootfdt.o
 obj-y += time.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index b2bfc7d..1f07a41 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -21,6 +21,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -742,6 +743,14 @@ int arch_set_info_guest(
 v->arch.ttbr1 = ctxt->ttbr1;
 v->arch.ttbcr = ctxt->ttbcr;
 
+if ( v->vcpu_id == 0 )
+{
+struct domain *d = v->domain;
+d->time_offset_seconds = ticks_to_ns(d->arch.virt_timer_base.offset - 
boot_count);
+do_div(d->time_offset_seconds, 10);
+update_domain_wallclock_time(d);
+}
+
 v->is_initialised = 1;
 
 if ( ctxt->flags & VGCF_online )
diff --git a/xen/arch/arm/platform_hypercall.c 
b/xen/arch/arm/platform_hypercall.c
new file mode 100644
index 000..cb8e575
--- /dev/null
+++ b/xen/arch/arm/platform_hypercall.c
@@ -0,0 +1,62 @@
+/**
+ * platform_hypercall.c
+ * 
+ * Hardware platform operations. Intended for use by domain-0 kernel.
+ * 
+ * Copyright (c) 2015, Citrix
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DEFINE_SPINLOCK(xenpf_lock);
+
+long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
+{
+long ret;
+struct xen_platform_op curop, *op = 
+struct domain *d;
+
+if ( copy_from_guest(op, u_xenpf_op, 1) )
+return -EFAULT;
+
+if ( op->interface_version != XENPF_INTERFACE_VERSION )
+return -EACCES;
+
+d = rcu_lock_current_domain();
+if ( d == NULL )
+return -ESRCH;
+
+ret = xsm_platform_op(XSM_PRIV, op->cmd);
+if ( ret )
+return ret;
+
+spin_lock(_lock);
+
+switch ( op->cmd )
+{
+case XENPF_settime64:
+if ( likely(!op->u.settime64.mbz) )
+do_settime(op->u.settime64.secs,
+   op->u.settime64.nsecs,
+   op->u.settime64.system_time + 
SECONDS(d->time_offset_seconds));
+else
+ret = -EINVAL;
+break;
+
+default:
+ret = -ENOSYS;
+break;
+}
+
+spin_unlock(_lock);
+rcu_unlock_domain(d);
+return ret;
+}
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9d2bd6a..c49bd3f 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1233,6 +1233,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
 HYPERCALL(hvm_op, 2),
 HYPERCALL(grant_table_op, 3),
 HYPERCALL(multicall, 2),
+HYPERCALL(platform_op, 1),
 HYPERCALL_ARM(vcpu_op, 3),
 };
 
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 1418092..95c2d6c 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 
-extern s_time_t ticks_to_ns(uint64_t ticks);
 extern uint64_t ns_to_ticks(s_time_t ns);
 
 /*
diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
index d755f36..23e5a28 100644
--- a/xen/include/asm-arm/time.h
+++ b/xen/include/asm-arm/time.h
@@ -37,6 +37,8 @@ extern void __cpuinit init_timer_interrupt(void);
 /* Counter value at boot time */
 extern uint64_t boot_count;
 
+extern s_time_t ticks_to_ns(uint64_t ticks);
+
 void preinit_xen_time(void);
 
 #endif /* __ARM_TIME_H__ */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 

[Xen-devel] [PATCH v2 1/2] xen: move wallclock functions from x86 to common

[sstabellini]

From: Stefano Stabellini 

Remove dummy arm implementation of wallclock_time.
Use shared_info() in common code rather than x86-ism to access it, when
possible.

Define the static variable wc_sec, and the local variale sec in
update_domain_wallclock_time, as uint64_t instead of unsigned long, to
avoid size issue on arm.
Take a uint64_t sec paramter in do_settime for the same reason.

Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com

---
Changes in v2:
- remove stray blank lines
- remove include 
- move version_update_* to include/xen/time.h
- introduce ifdef to fix build issue in common/time.c
- define wc_sec and sec as uint64_t
- pass u64 to do_settime
---
 xen/arch/arm/time.c|5 ---
 xen/arch/x86/time.c|   96 +---
 xen/common/time.c  |   96 +++-
 xen/include/xen/time.h |5 ++-
 4 files changed, 100 insertions(+), 102 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 5ded30c..6207615 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -280,11 +280,6 @@ void domain_set_time_offset(struct domain *d, int64_t 
time_offset_seconds)
 /* XXX update guest visible wallclock time */
 }
 
-struct tm wallclock_time(uint64_t *ns)
-{
-return (struct tm) { 0 };
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index bbb7e6c..0f16db5 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -47,9 +47,6 @@ string_param("clocksource", opt_clocksource);
 unsigned long __read_mostly cpu_khz;  /* CPU clock frequency in kHz. */
 DEFINE_SPINLOCK(rtc_lock);
 unsigned long pit0_ticks;
-static unsigned long wc_sec; /* UTC time at last 'time update'. */
-static unsigned int wc_nsec;
-static DEFINE_SPINLOCK(wc_lock);
 
 struct cpu_time {
 u64 local_tsc_stamp;
@@ -783,10 +780,6 @@ uint64_t tsc_ticks2ns(uint64_t ticks)
 return scale_delta(ticks, >tsc_scale);
 }
 
-/* Explicitly OR with 1 just in case version number gets out of sync. */
-#define version_update_begin(v) (((v)+1)|1)
-#define version_update_end(v)   ((v)+1)
-
 static void __update_vcpu_system_time(struct vcpu *v, int force)
 {
 struct cpu_time   *t;
@@ -900,37 +893,6 @@ void force_update_vcpu_system_time(struct vcpu *v)
 __update_vcpu_system_time(v, 1);
 }
 
-void update_domain_wallclock_time(struct domain *d)
-{
-uint32_t *wc_version;
-unsigned long sec;
-
-spin_lock(_lock);
-
-wc_version = _info(d, wc_version);
-*wc_version = version_update_begin(*wc_version);
-wmb();
-
-sec = wc_sec + d->time_offset_seconds;
-if ( likely(!has_32bit_shinfo(d)) )
-{
-d->shared_info->native.wc_sec= sec;
-d->shared_info->native.wc_nsec   = wc_nsec;
-d->shared_info->native.wc_sec_hi = sec >> 32;
-}
-else
-{
-d->shared_info->compat.wc_sec = sec;
-d->shared_info->compat.wc_nsec= wc_nsec;
-d->shared_info->compat.arch.wc_sec_hi = sec >> 32;
-}
-
-wmb();
-*wc_version = version_update_end(*wc_version);
-
-spin_unlock(_lock);
-}
-
 static void update_domain_rtc(void)
 {
 struct domain *d;
@@ -988,27 +950,6 @@ int cpu_frequency_change(u64 freq)
 return 0;
 }
 
-/* Set clock to  after 00:00:00 UTC, 1 January, 1970. */
-void do_settime(unsigned long secs, unsigned int nsecs, u64 system_time_base)
-{
-u64 x;
-u32 y;
-struct domain *d;
-
-x = SECONDS(secs) + nsecs - system_time_base;
-y = do_div(x, 10);
-
-spin_lock(_lock);
-wc_sec  = x;
-wc_nsec = y;
-spin_unlock(_lock);
-
-rcu_read_lock(_read_lock);
-for_each_domain ( d )
-update_domain_wallclock_time(d);
-rcu_read_unlock(_read_lock);
-}
-
 /* Per-CPU communication between rendezvous IRQ and softirq handler. */
 struct cpu_calibration {
 u64 local_tsc_stamp;
@@ -1608,25 +1549,6 @@ void send_timer_event(struct vcpu *v)
 send_guest_vcpu_virq(v, VIRQ_TIMER);
 }
 
-/* Return secs after 00:00:00 localtime, 1 January, 1970. */
-unsigned long get_localtime(struct domain *d)
-{
-return wc_sec + (wc_nsec + NOW()) / 10ULL 
-+ d->time_offset_seconds;
-}
-
-/* Return microsecs after 00:00:00 localtime, 1 January, 1970. */
-uint64_t get_localtime_us(struct domain *d)
-{
-return (SECONDS(wc_sec + d->time_offset_seconds) + wc_nsec + NOW())
-   / 1000UL;
-}
-
-unsigned long get_sec(void)
-{
-return wc_sec + (wc_nsec + NOW()) / 10ULL;
-}
-
 /* "cmos_utc_offset" is the difference between UTC time and CMOS time. */
 static long cmos_utc_offset; /* in seconds */
 
@@ -1635,7 +1557,7 @@ int time_suspend(void)
 if ( smp_processor_id() == 0 )
 {
 cmos_utc_offset = -get_cmos_time();
-cmos_utc_offset += (wc_sec + (wc_nsec + NOW()) / 10ULL);
+

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Ian Jackson]

Chunyan Liu writes ("[PATCH V8 3/7] libxl: add pvusb API"):
> Add pvusb APIs, including:
>  - attach/detach (create/destroy) virtual usb controller.
>  - attach/detach usb device
>  - list usb controller and usb devices
>  - some other helper functions

Thanks for this.


I have reviewed it in detail (not just the ao handling aspects) and
(I'm afraid) produced a large number of comments, relating to style,
error handling, etc., as well as ao handling.

Please let me know if anything I've said is unclear.  I've been rather
brief in my comments, rather than writing a paragraph for each one.
Thanks.


> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index dacfaae..a050e8b 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4218,11 +4218,54 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
...
> +/* Macro for defining device remove/destroy functions for usbctrl */
> +/* Following functions are defined:
> + * libxl_device_usbctrl_remove
> + * libxl_device_usbctrl_destroy
> + */
> +
> +#define DEFINE_DEVICE_REMOVE_EXT(type, removedestroy, f)\

As George has said, I would prefer to avoid committing this
duplication in-tree, even with a promise to de-duplicated it later.


> +void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t domid,
> +   libxl_device_usbctrl *usbctrl,
> +   libxl__ao_device *aodev)
> +{

Thanks for adjusting the error-handling patterns in these functions.
The new way is good, except that:

> +out:
> +aodev->rc = rc;
> +if (rc) aodev->callback(egc, aodev);

Here, rc is always set, and indeed the code would be wrong if it were
not.  So can you remove the conditional please ?  Ie:

  +   aodev->callback(egc, aodev);

The same goes for:

> +static int
> +libxl__device_usb_remove(libxl__gc *gc, uint32_t domid, libxl_device_usb 
> *usb);
...

> +/* Remove usb devices first */
> +rc  = libxl__device_usb_list_for_usbctrl(gc, domid, usbctrl_devid,
> + , );
 ^^
While you're fixing other things, you could remove one of these space.s

> +libxl_device_usbctrl *
> +libxl_device_usbctrl_list(libxl_ctx *ctx, uint32_t domid, int *num)
> +{
...
> +for (usbctrl = usbctrls; usbctrl < end;
> + usbctrl++, entry++, (*num)++) {

I think this would be clearer if there were a line break at the first
semicolon too.  Ie, I like
for (A; B; C) {
or
for (A;
 B;
 C) {

But I don't like very much
for (A; B;
 C) {
or
for (A;
 B; C) {

> +#define READ_SUBPATH(path, subpath) ({  \
> +rc = libxl__xs_read_checked(gc, XBT_NULL,   \
> +GCSPRINTF("%s/" subpath, path), \
> +);  \
> +if (rc) goto outerr;\
> +(char *)tmp;\
> +})

Thanks, I'm pleased with how you have done this.

> +be_path = READ_SUBPATH(fe_path, "backend");
> +usbctrl->backend_domid = atoi(READ_SUBPATH(fe_path, 
> "backend-id"));
> +usbctrl->version = atoi(READ_SUBPATH(be_path, "usb-ver"));
> +usbctrl->ports = atoi(READ_SUBPATH(be_path, "num-ports"));

However, I have a question:

Why do you use atoi here, but strtoul in libxl_device_usbctrl_getinfo ?

> +int libxl_device_usbctrl_getinfo(libxl_ctx *ctx, uint32_t domid,
> +libxl_device_usbctrl *usbctrl,
> +libxl_usbctrlinfo *usbctrlinfo)
> +{
...
> +tmp = READ_SUBPATH(fe_path, "backend-id");
> +usbctrlinfo->backend_id = tmp ? strtoul(tmp, NULL, 10) : -1;

There are ten copies of this pattern with tmp and strtoul.  I really
think this needs to be refactored somehow.  Can you please make a
macro which returns the return value from strtoul ?

> +static char *usb_busaddr_to_busid(libxl__gc *gc, int bus, int addr)
> +{
...
> +while ((de = readdir(dir))) {

You need to use readdir_r, I'm afraid.  Ordinary readdir is not
threadsafe.

> +}
> +
> +closedir(dir);

This assumes that all errors from readdir are EOF.  But that's not the
case.  Luckily readdir_r has more sensible error behaviour.  But you
do need to check separately for errors and EOF.

All in all this probably means that it would be clearer to write this
as:
 for (;;) {
 r = readdir_r etc.
 if (r) 
 if (!de) break;

There is at least one more call to readdir in this patch which also
needs to be fixed.

> +static int usb_busaddr_from_busid(libxl__gc *gc, const char *busid,
> +  uint8_t *bus, uint8_t *addr)
> +{
> +char *filename;
> +void *buf;
> +
> +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/busnum", busid);
> +if (!libxl__read_sysfs_file_contents(gc, filename, 

[Xen-devel] [PATCH v2 0/2] wallclock time on arm

[Stefano Stabellini]

Hi all,

this small series enables the wallclock time on arm and it consists
mostly in code movement from x86 to common.


Changes in v2:
- remove stray blank lines
- remove include 
- move version_update_* to include/xen/time.h
- introduce ifdef to fix build issue in common/time.c
- define wc_sec and sec as uint64_t
- pass u64 to do_settime
- drop XENPF_settime32
- set time_offset_seconds
- modify xen/xsm/flask/hooks.c


Stefano Stabellini (2):
  xen: move wallclock functions from x86 to common
  arm: export platform_op XENPF_settime64

 xen/arch/arm/Makefile |1 +
 xen/arch/arm/domain.c |9 
 xen/arch/arm/platform_hypercall.c |   62 
 xen/arch/arm/time.c   |5 --
 xen/arch/arm/traps.c  |1 +
 xen/arch/arm/vtimer.c |1 -
 xen/arch/x86/time.c   |   96 +
 xen/common/time.c |   96 -
 xen/include/asm-arm/time.h|2 +
 xen/include/xen/time.h|5 +-
 xen/include/xsm/dummy.h   |   12 ++---
 xen/include/xsm/xsm.h |   13 ++---
 xen/xsm/flask/hooks.c |2 +-
 13 files changed, 189 insertions(+), 116 deletions(-)
 create mode 100644 xen/arch/arm/platform_hypercall.c

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH v11 2/5] missing include asm/paravirt.h in cputime.c

[Peter Zijlstra]

On Thu, Nov 05, 2015 at 05:30:01PM +, Stefano Stabellini wrote:
> On Thu, 5 Nov 2015, Peter Zijlstra wrote:
> > How can this be missing? Things compile fine now, right?
> 
> Fair enough.
> 
> 
> > So please better explain why we do this change.
> 
> asm/paravirt.h is included by one of the other headers included in
> kernel/sched/cputime.c on x86, but not on other architecures. On arm and
> arm64, where I am about to introduce asm/paravirt.h and stolen time
> support, without #include  in cputime.c I would get:
> 
> kernel/sched/cputime.c: In function ‘steal_account_process_tick’:
> kernel/sched/cputime.c:260:24: error: ‘paravirt_steal_enabled’ undeclared 
> (first use in this function)
>   if (static_key_false(_steal_enabled)) {
> 
> A bit of digging on x86 (using gcc -E on cputime.c) tells me that
> asm/paravirt.h is coming from the following include chain:
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 


Fair enough; a slightly shorter version of that for a changelog will do
nicely.

Thanks!

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

Re: [Xen-devel] [PATCH v8 12/21] xen/x86: allow disabling the emulated PIT

[Jan Beulich]

>>> On 06.11.15 at 17:05,  wrote:
> Signed-off-by: Roger Pau Monné 
> Reported by: Boris Ostrovsky 

Acked-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH v2 1/6] gitignore: Ignore *.orig, *.rej and *.swp files

[Daniel Kiper]

On Mon, Nov 09, 2015 at 04:34:20PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> On 09.11.2015 16:29, Daniel Kiper wrote:
> > On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko 
> > wrote:
> >> Le 12 août 2015 11:04 AM, "Ian Campbell"  a écrit 
> >> :
> >>>
> >>>
> >>> (Having written the below I see too late that this is a grub patch not a
> >>> Xen one, a tag in the subject for such cross posted patches would be
> >> useful
> >>> please. Anyway, my opinion counts for very little in this context but I
> >>> leave it below since already I wrote it. I notice that xen.git#.gitignore
> >>> _does_ list *.rej, which I think is wrong...)
> >>>
> >>> On Mon, 2015-07-20 at 16:35 +0200, Daniel Kiper wrote:
>  Signed-off-by: Daniel Kiper 
> >>>
> >>> At least *.rej and perhaps *.orig are indicative of a failed patch
> >>> application, I think I want them to appear in "git status".
> >>>
> >>> By way of comparison Linux's .gitignore includes *.orig but not *.rej and
> >>> Qemu's includes neither.
> >>>
> >>> So nack to the addition of *.rej from me. I'm more or less ambivalent
> >> about
> >>> *.orig.
> >>>
> >> I have to agree. You should clean up *.rej *.orig after fixing conflicts
> >
> > Thanks for comment on this. Could you review rest of this patchset?
> > I am working on v3 and it will be nice to take your (and others if
> > possible) comments into it.
> >
> I will go through them today

Thanks a lot!

Daniel

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

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

[Dario Faggioli]

On Mon, 2015-11-09 at 15:23 +, Ian Campbell wrote:
> On Mon, 2015-11-09 at 16:14 +0100, Dario Faggioli wrote:
> >  
> > > As far as xl accessibility --- doesn't xenperf already read them
> > > out?
> > > 
> > Mmm... ISTR having tried without much luck, and having heard that
> > it
> > wasn't functional any longer, but maybe I'm confusing it with
> > something
> > else. I'll try again.
> 
> I happened to have an xterm with this in its scroll buffer from
> earlier:
> 
> root@marilith-n0:~# xenperf 
> invalid hypercalls  T= 0   0 
>  0  0  0
> trap: wfi   T= 85068   56068 
>  11762   8461   8777
> trap: wfe   T=  2811 614   
>  716964517
> trap: cp15 32-bit accessT= 4   1 
>  1  1  1
> trap: cp15 64-bit accessT= 0   0 
>  0  0  0
> trap: cp14 32-bit accessT= 0   0 
>  0  0  0
> trap: cp14 64-bit accessT= 0   0 
>  0  0  0
> trap: cp14 dbg access   T= 0   0 
>  0  0  0
> trap: cp access T= 0   0 
>  0  0  0
> trap: 32-bit smcT= 0   0 
>  0  0  0
> trap: 32-bit hvcT=  1291 510   
>  568161 52
> trap: guest instr abort T= 0   0 
>  0  0  0
> trap: guest data abort  T= 164466885  
>  4358   3431   1772
> trap: condition failed  T= 0   0 
>  0  0  0
> [...]
> 
> So I think it works.
> 
Ok, thanks for the confirmation, and sorry for the noise then.

> You need to build the hypervisor binary with perfc=y (and optionally
> perfc_arrays=y) or it doesn't do anything.
> 
Yeah, that I knew.

Thanks again 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
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

[Konrad Rzeszutek Wilk]

On Mon, Nov 09, 2015 at 04:47:20PM +0100, Dario Faggioli wrote:
> On Mon, 2015-11-09 at 15:23 +, Ian Campbell wrote:
> > On Mon, 2015-11-09 at 16:14 +0100, Dario Faggioli wrote:
> > >  
> > > > As far as xl accessibility --- doesn't xenperf already read them
> > > > out?
> > > > 
> > > Mmm... ISTR having tried without much luck, and having heard that
> > > it
> > > wasn't functional any longer, but maybe I'm confusing it with
> > > something
> > > else. I'll try again.
> > 
> > I happened to have an xterm with this in its scroll buffer from
> > earlier:
> > 
> > root@marilith-n0:~# xenperf 
> > invalid hypercalls  T= 0   0 
> >  0  0  0
> > trap: wfi   T= 85068   56068 
> >  11762   8461   8777
> > trap: wfe   T=  2811 614   
> >  716964517
> > trap: cp15 32-bit accessT= 4   1 
> >  1  1  1
> > trap: cp15 64-bit accessT= 0   0 
> >  0  0  0
> > trap: cp14 32-bit accessT= 0   0 
> >  0  0  0
> > trap: cp14 64-bit accessT= 0   0 
> >  0  0  0
> > trap: cp14 dbg access   T= 0   0 
> >  0  0  0
> > trap: cp access T= 0   0 
> >  0  0  0
> > trap: 32-bit smcT= 0   0 
> >  0  0  0
> > trap: 32-bit hvcT=  1291 510   
> >  568161 52
> > trap: guest instr abort T= 0   0 
> >  0  0  0
> > trap: guest data abort  T= 164466885  
> >  4358   3431   1772
> > trap: condition failed  T= 0   0 
> >  0  0  0
> > [...]
> > 
> > So I think it works.
> > 
> Ok, thanks for the confirmation, and sorry for the noise then.
> 
> > You need to build the hypervisor binary with perfc=y (and optionally
> > perfc_arrays=y) or it doesn't do anything.
> > 
> Yeah, that I knew.

And you need to apply an patch this patch for x86:

http://lists.xen.org/archives/html/xen-devel/2015-11/msg00633.html
since the lock_profile also adds tons of data in the 'struct spinlock'
making the 'struct domain' bigger than 4K (to 68K!).
> 
> Thanks again and Regards,
> Dario
> -- 
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)
> 



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


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

Re: [Xen-devel] [PATCH 00/13] tools: do cleanups related to libxc python bindings

[Juergen Gross]

On 10/23/2015 03:04 PM, Juergen Gross wrote:

This series is a combination of my previous patches:

"libxc: remove most of tools/libxc/xc_dom_compat_linux.c"
"tools: remove unused wrappers for python"

I have split it up as requested by Ian Campbell, thus it consists of
13 patches instead just of 2, but the functionality is roughly the
same. I have just kept more python bindings compared to the first
version, as there have been reports of some out of tree uses. Asking
for more such use case on xen-devel and xen-user didn't result in
requests for more interfaces to be kept, so I delete them.


There have been acks and critical responses regarding this series.

What should we do?

- drop them all
- apply the first two patches only to get rid of the extra interfaces
  to the domain builder as requested by Ian Campbell
- apply all of them


Juergen



Juergen Gross (13):
   libxc: remove most of tools/libxc/xc_dom_compat_linux.c
   libxc: remove xc_get_bit_size() from tools/libxc/xc_dom_compat_linux.c
   python: remove flask related libxc python bindings
   python: remove cpupool related libxc python bindings
   python: remove cpuid related libxc python bindings
   python: remove device related libxc python bindings
   python: remove scheduler related libxc python bindings
   python: remove unused memory related libxc python bindings
   python: remove domain handling related libxc python bindings
   python: remove vcpu related libxc python bindings
   python: remove hvm related libxc python bindings
   python: remove  permission related libxc python bindings
   python: remove unused other libxc python bindings

  tools/libxc/include/xc_dom.h  |5 +
  tools/libxc/include/xenguest.h|   52 -
  tools/libxc/xc_dom_compat_linux.c |  142 +-
  tools/libxl/libxl_internal.h  |1 +
  tools/python/xen/lowlevel/xc/xc.c | 2624 +++--
  5 files changed, 170 insertions(+), 2654 deletions(-)




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

Re: [Xen-devel] [PATCH v2 1/6] gitignore: Ignore *.orig, *.rej and *.swp files

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 09.11.2015 16:29, Daniel Kiper wrote:
> On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko wrote:
>> Le 12 août 2015 11:04 AM, "Ian Campbell"  a écrit :
>>>
>>>
>>> (Having written the below I see too late that this is a grub patch not a
>>> Xen one, a tag in the subject for such cross posted patches would be
>> useful
>>> please. Anyway, my opinion counts for very little in this context but I
>>> leave it below since already I wrote it. I notice that xen.git#.gitignore
>>> _does_ list *.rej, which I think is wrong...)
>>>
>>> On Mon, 2015-07-20 at 16:35 +0200, Daniel Kiper wrote:
 Signed-off-by: Daniel Kiper 
>>>
>>> At least *.rej and perhaps *.orig are indicative of a failed patch
>>> application, I think I want them to appear in "git status".
>>>
>>> By way of comparison Linux's .gitignore includes *.orig but not *.rej and
>>> Qemu's includes neither.
>>>
>>> So nack to the addition of *.rej from me. I'm more or less ambivalent
>> about
>>> *.orig.
>>>
>> I have to agree. You should clean up *.rej *.orig after fixing conflicts
> 
> Thanks for comment on this. Could you review rest of this patchset?
> I am working on v3 and it will be nice to take your (and others if
> possible) comments into it.
> 
I will go through them today
> Daniel
> 




signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity

[Julien Grall]

Hi,

Any comments on this new version?

Regards,

On 19/10/15 15:19, Julien Grall wrote:
> Hi all,
> 
> This is a follow-up on the previous discussion [1] related to guest using 64KB
> page granularity which doesn't boot when the backend isn't using indirect
> descriptor.
> 
> This has been successfully tested on ARM64 with both 64KB and 4KB page
> granularity guests and QEMU as the backend. Indeed QEMU doesn't support
> indirect descriptor.
> 
> This series is based on xentip/for-linus-4.4 which include the support for
> 64KB Linux guest.
> 
> For all the changes see in each patch.
> 
> Sincerely yours,
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg01659.html
> 
> Cc: Konrad Rzeszutek Wilk 
> Cc: "Roger Pau Monné" 
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> 
> Julien Grall (2):
>   block/xen-blkfront: Introduce blkif_ring_get_request
>   block/xen-blkfront: Handle non-indirect grant with 64KB pages
> 
>  drivers/block/xen-blkfront.c | 230 
> ++-
>  1 file changed, 203 insertions(+), 27 deletions(-)
> 


-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v2 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity

[Konrad Rzeszutek Wilk]

On Mon, Nov 09, 2015 at 03:51:48PM +, Julien Grall wrote:
> Hi,
> 
> Any comments on this new version?

I completly ignored thinking that the:

c004a6f block/xen-blkfront: Make it running on 64KB page granularity
4f503fb block/xen-blkfront: split get_grant in 2
a7a6df2 block/xen-blkfront: Store a page rather a pfn in the grant structure
3320466 block/xen-blkfront: Split blkif_queue_request in 2

were only needed. Sorry! Could you repost them please? And
CC bob@oracle.com please?

> 
> Regards,
> 
> On 19/10/15 15:19, Julien Grall wrote:
> > Hi all,
> > 
> > This is a follow-up on the previous discussion [1] related to guest using 
> > 64KB
> > page granularity which doesn't boot when the backend isn't using indirect
> > descriptor.
> > 
> > This has been successfully tested on ARM64 with both 64KB and 4KB page
> > granularity guests and QEMU as the backend. Indeed QEMU doesn't support
> > indirect descriptor.
> > 
> > This series is based on xentip/for-linus-4.4 which include the support for
> > 64KB Linux guest.
> > 
> > For all the changes see in each patch.
> > 
> > Sincerely yours,
> > 
> > [1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg01659.html
> > 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: "Roger Pau Monné" 
> > Cc: Boris Ostrovsky 
> > Cc: David Vrabel 
> > 
> > Julien Grall (2):
> >   block/xen-blkfront: Introduce blkif_ring_get_request
> >   block/xen-blkfront: Handle non-indirect grant with 64KB pages
> > 
> >  drivers/block/xen-blkfront.c | 230 
> > ++-
> >  1 file changed, 203 insertions(+), 27 deletions(-)
> > 
> 
> 
> -- 
> Julien Grall
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock

[Stefano Stabellini]

On Mon, 9 Nov 2015, Arnd Bergmann wrote:
> On Monday 09 November 2015 13:53:30 Stefano Stabellini wrote:
> > On Fri, 6 Nov 2015, Arnd Bergmann wrote:
> > > I'm not quite sure about how the split between pvclock_wall_clock and
> > > the delta works. Normally I'd expect that pvclock_wall_clock is the 
> > > wallclock
> > > time as it was at boot, while delta is the number of expired nanoseconds
> > > since boot. However it is unclear why the latter has a longer range
> > > (539 years starting at boot, rather than 126 years starting in 1970).
> > 
> > Actually we already have a sec overflow field in struct shared_info on
> > the hypervisor side, called wc_sec_hi. I just need to make use of it in
> > Linux. See:
> > 
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=xen/include/public/xen.h;hb=HEAD
> > 
> > Thanks for raising my attention to the problem,
> 
> Sounds good for Xen on ARM. This same interface is also used on
> KVM, right? Does the extension also work there?

It doesn't look like it (see arch/x86/kvm/x86.c:kvm_write_wall_clock).

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

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

[Ian Campbell]

On Mon, 2015-11-09 at 16:14 +0100, Dario Faggioli wrote:
> 
> > As far as xl accessibility --- doesn't xenperf already read them out?
> > 
> Mmm... ISTR having tried without much luck, and having heard that it
> wasn't functional any longer, but maybe I'm confusing it with something
> else. I'll try again.

I happened to have an xterm with this in its scroll buffer from earlier:

root@marilith-n0:~# xenperf 
invalid hypercalls  T= 0   0  0 
 0  0
trap: wfi   T= 85068   56068  11762   
8461   8777
trap: wfe   T=  2811 614716
964517
trap: cp15 32-bit accessT= 4   1  1 
 1  1
trap: cp15 64-bit accessT= 0   0  0 
 0  0
trap: cp14 32-bit accessT= 0   0  0 
 0  0
trap: cp14 64-bit accessT= 0   0  0 
 0  0
trap: cp14 dbg access   T= 0   0  0 
 0  0
trap: cp access T= 0   0  0 
 0  0
trap: 32-bit smcT= 0   0  0 
 0  0
trap: 32-bit hvcT=  1291 510568
161 52
trap: guest instr abort T= 0   0  0 
 0  0
trap: guest data abort  T= 164466885   4358   
3431   1772
trap: condition failed  T= 0   0  0 
 0  0
[...]

So I think it works.

You need to build the hypervisor binary with perfc=y (and optionally
perfc_arrays=y) or it doesn't do anything.

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

[Xen-devel] Xen 4.7 Development Update

[Wei Liu]

I accidentally deleted my old script, so I take the chance to change
the tracking email a bit. Now this email only tracks big items for
xen.git tree. Please reply for items you woulk like to see in 4.7 so
that people have an idea what is going on and prioritise accordingly.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release twice a
year. The upcoming 4.7 timeline are as followed:

* Last posting date: March 18, 2016
* Hard code freeze: April 1, 2016
* RC1: TBD
* Release: July 1, 2016

Note that we don't have freeze exception scheme anymore. All patches
that wish to go into 4.7 must be posted no later than the last posting
date. All patches posted after that date will be automatically queued
into next release.

RCs will be arranged immediately after freeze.

= Projects =

== Hypervisor == 

=== x86 === 

*  xSplice, hypervisor hot-patching
  -  Konrad Wilk

*  Porting Intel PState driver
  -  Wei Wang

*  HVM-nodm support
  -  Roger Pau Monne

*  Posted interrupt
  -  Wu, Feng

*  VMX TSC scaling support
  -  Haozhong Zhang

*  VT-d asynchronous flush issue
  -  Tian, Kevin

*  xsave/xrtors support
  -  Shuai Ruan

=== ARM === 

== Toolstack == 

*  Disentangle libxenctrl to stable libraries
  -  Ian Campbell

*  Libxc support for building large PV domains
  -  Juergen Gross

*  PV USB passthrough
  -  Chunyan Liu

*  HVM USB passthrough
  -  George Dunlap

*  Domain snapshot API
  -  Chunyan Liu

*  Fix hotplug script machinery and remove blktap
  -  George Dunlap

*  Basic xSplice tooling (see hypervisor item)
  -  Konrad Wilk

*  Run QEMU as non-root
  -  Stefano Stabellini

*  Load BIOS via toolstack
  -  Anthony Perard

*  COLO
  -  Yang Hongyang

== Documentation == 

*  Feature maturity lifecycle
  -  Lars Kurth

== Completed == 

*  Intel CDP support
  -  He Chen


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

Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock

[Arnd Bergmann]

On Monday 09 November 2015 13:53:30 Stefano Stabellini wrote:
> On Fri, 6 Nov 2015, Arnd Bergmann wrote:
> > I'm not quite sure about how the split between pvclock_wall_clock and
> > the delta works. Normally I'd expect that pvclock_wall_clock is the 
> > wallclock
> > time as it was at boot, while delta is the number of expired nanoseconds
> > since boot. However it is unclear why the latter has a longer range
> > (539 years starting at boot, rather than 126 years starting in 1970).
> 
> Actually we already have a sec overflow field in struct shared_info on
> the hypervisor side, called wc_sec_hi. I just need to make use of it in
> Linux. See:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=xen/include/public/xen.h;hb=HEAD
> 
> Thanks for raising my attention to the problem,

Sounds good for Xen on ARM. This same interface is also used on
KVM, right? Does the extension also work there?

Arnd

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

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

[Dario Faggioli]

On Mon, 2015-11-09 at 10:02 -0500, Boris Ostrovsky wrote:
> On 11/09/2015 09:53 AM, Dario Faggioli wrote:
> > On Mon, 2015-11-09 at 14:00 +, Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell 
> > > 
> > Reviewed-by: Dario Faggioli 
> > 
> > And, while we're here, I've been thinking since a while to try
> > implementing an xl interface for these counters... How bad of an
> > idea
> > is that?
> > 
> > Is something like that possible already via Boris' PMU work?
> 
> VPMU only covers CPU's hardware counters and this patch deals with 
> software events in the hypervisor.
> 
Right, I just wanted to be sure (I've planned to familiarize with that
work, but haven't got to doing it yet).

> As far as xl accessibility --- doesn't xenperf already read them out?
> 
Mmm... ISTR having tried without much luck, and having heard that it
wasn't functional any longer, but maybe I'm confusing it with something
else. I'll try again.

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7 Development Update

[Wei Liu]

On Mon, Nov 09, 2015 at 04:15:45PM +, Wei Liu wrote:
> I accidentally deleted my old script, so I take the chance to change
> the tracking email a bit. Now this email only tracks big items for
> xen.git tree. Please reply for items you woulk like to see in 4.7 so
> that people have an idea what is going on and prioritise accordingly.
> 
> = Timeline =
> 
> We now adopt a fixed cut-off date scheme. We will release twice a
> year. The upcoming 4.7 timeline are as followed:
> 
> * Last posting date: March 18, 2016
> * Hard code freeze: April 1, 2016
> * RC1: TBD
> * Release: July 1, 2016

There is a mistake. It should be June 3 2016. That's around 2 months
after freeze.

I will fix this.

Wei.

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

Re: [Xen-devel] [PATCH 2/2] arm: export platform_op XENPF_settime

[Stefano Stabellini]

On Thu, 5 Nov 2015, Julien Grall wrote:
> Hi Stefano,
> 
> You forgot to CC Daniel for the XSM part. Please use
> scripts/get_maintainers.pl to get the relevant maintainers.
> 
> On 05/11/15 16:57, Stefano Stabellini wrote:
> > Call update_domain_wallclock_time at domain initialization.
> 
> It's not really what you are doing in the code. You are calling
> update_domain_wallclock_time when the first vCPU is initialized.
> 
> Also some rationale to explain why this call should be done here would
> be good.
> 
> Finally, I'm a bit surprised that you only need to call
> update_domain_wallclock_time when the domain is created. x86 needs to
> call in various places.

It is also called automatically from do_settime. I don't think we need
any other arch-specific call sites.


> For instance we may want to call update_domain_wallclock_time in
> construct_dom0 before clearing the pause flags. This is because the
> wallclock may be out of sync as construction DOM0 takes some time.

That's not necessary: the wallclock in Xen is the number
of seconds since 1970 at the time the physical machine booted, plus the
domain specific offset, so it is not subject to quick incremental
changes, like a monotonic clock.


> > Signed-off-by: Stefano Stabellini 
> > Signed-off-by: Ian Campbell 
> > ---
> >  xen/arch/arm/Makefile |1 +
> >  xen/arch/arm/domain.c |3 ++
> >  xen/arch/arm/platform_hypercall.c |   62 
> > +
> >  xen/arch/arm/traps.c  |1 +
> >  xen/include/xsm/dummy.h   |   12 +++
> >  xen/include/xsm/xsm.h |   13 
> 
> You also have to fix xsm/flask/hooks.c.

Uhm.. OK


> >  6 files changed, 80 insertions(+), 12 deletions(-)
> >  create mode 100644 xen/arch/arm/platform_hypercall.c
> 
> [..]
> 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index b2bfc7d..ac9b1b3 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -742,6 +742,9 @@ int arch_set_info_guest(
> >  v->arch.ttbr1 = ctxt->ttbr1;
> >  v->arch.ttbcr = ctxt->ttbcr;
> >  
> > +if ( v->vcpu_id == 0 )
> > +update_domain_wallclock_time(v->domain);
> > +
> >  v->is_initialised = 1;
> >  
> >  if ( ctxt->flags & VGCF_online )
> > diff --git a/xen/arch/arm/platform_hypercall.c 
> > b/xen/arch/arm/platform_hypercall.c
> > new file mode 100644
> > index 000..f60d7b3
> > --- /dev/null
> > +++ b/xen/arch/arm/platform_hypercall.c
> > @@ -0,0 +1,62 @@
> > +/**
> > + * platform_hypercall.c
> > + * 
> > + * Hardware platform operations. Intended for use by domain-0 kernel.
> > + * 
> > + * Copyright (c) 2015, Citrix
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DEFINE_SPINLOCK(xenpf_lock);
> > +
> > +long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
> > +{
> 
> Would it make sense to introduce a common platform code which take care
> of common hypercall? See for instance do_domctl and arch_do_domctl.

In this case I don't think so. I don't see the other existing
platform_ops being used on arm.

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

[Xen-devel] [PATCH v5 5/6] xen/arm: vgic: Introduce helpers to extract/update/clear/set vGIC register ...

[Julien Grall]

and use them in the vGIC emulation.

The GIC registers may support different access sizes. Rather than open
coding the access for every registers, provide a set of helpers to access
them.

The caller will have to call vgic_regN_* where N is the size of the
emulated registers.

The new helpers supports any access size and expect the caller to
validate the access size supported by the emulated registers.

Finally, take the opportunity to fix the coding style in section we are
modifying.

Signed-off-by: Julien Grall 
Acked-by: Ian Campbell 

---
Ian, I update this patch to convert the emulation of GICD_CTLR in
vGICv3 to the new API. Although I've kept your ack because I think
it's not a major change. Let me know it's not fine.

Changes in v4:
- Convert GICD_CTLR in vGICv3 to the new API.

Changes in v3:
- Add Ian's acked-by

Changes in v2:
- Rename read/write helpers to extract/update
- Add a 's' to clearbit/setbit because we update multiple bits

Changes in v1:
- Make use of the new helpers in the vGICv2 code
- Drop vgic_byte_*
- Use unsigned long rather than uint64_t to optimize the code
on ARM. (~about 40% less instruction per helpers).
---
 xen/arch/arm/vgic-v2.c |  89 
 xen/arch/arm/vgic-v3.c | 125 +++--
 xen/include/asm-arm/vgic.h | 111 
 3 files changed, 243 insertions(+), 82 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 62159bf..c94f0f3 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -180,24 +180,31 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 case GICD_CTLR:
 if ( dabt.size != DABT_WORD ) goto bad_width;
 vgic_lock(v);
-*r = v->domain->arch.vgic.ctlr;
+*r = vgic_reg32_extract(v->domain->arch.vgic.ctlr, info);
 vgic_unlock(v);
 return 1;
 case GICD_TYPER:
+{
+uint32_t typer;
+
 if ( dabt.size != DABT_WORD ) goto bad_width;
 /* No secure world support for guests. */
 vgic_lock(v);
-*r = ( ((v->domain->max_vcpus - 1) << GICD_TYPE_CPUS_SHIFT) )
+typer = ((v->domain->max_vcpus - 1) << GICD_TYPE_CPUS_SHIFT)
 | DIV_ROUND_UP(v->domain->arch.vgic.nr_spis, 32);
 vgic_unlock(v);
+
+*r = vgic_reg32_extract(typer, info);
+
 return 1;
+}
 case GICD_IIDR:
 if ( dabt.size != DABT_WORD ) goto bad_width;
 /*
  * XXX Do we need a JEP106 manufacturer ID?
  * Just use the physical h/w value for now
  */
-*r = 0x043b;
+*r = vgic_reg32_extract(0x043b, info);
 return 1;
 
 /* Implementation defined -- read as zero */
@@ -213,7 +220,7 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 rank = vgic_rank_offset(v, 1, gicd_reg - GICD_ISENABLER, DABT_WORD);
 if ( rank == NULL) goto read_as_zero;
 vgic_lock_rank(v, rank, flags);
-*r = rank->ienable;
+*r = vgic_reg32_extract(rank->ienable, info);
 vgic_unlock_rank(v, rank, flags);
 return 1;
 
@@ -222,7 +229,7 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 rank = vgic_rank_offset(v, 1, gicd_reg - GICD_ICENABLER, DABT_WORD);
 if ( rank == NULL) goto read_as_zero;
 vgic_lock_rank(v, rank, flags);
-*r = rank->ienable;
+*r = vgic_reg32_extract(rank->ienable, info);
 vgic_unlock_rank(v, rank, flags);
 return 1;
 
@@ -237,37 +244,53 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 goto read_as_zero;
 
 case GICD_ITARGETSR ... GICD_ITARGETSRN:
+{
+uint32_t itargetsr;
+
 if ( dabt.size != DABT_BYTE && dabt.size != DABT_WORD ) goto bad_width;
 rank = vgic_rank_offset(v, 8, gicd_reg - GICD_ITARGETSR, DABT_WORD);
 if ( rank == NULL) goto read_as_zero;
 vgic_lock_rank(v, rank, flags);
-*r = vgic_fetch_itargetsr(rank, gicd_reg - GICD_ITARGETSR);
-if ( dabt.size == DABT_BYTE )
-*r = vgic_byte_read(*r, gicd_reg);
+itargetsr = vgic_fetch_itargetsr(rank, gicd_reg - GICD_ITARGETSR);
 vgic_unlock_rank(v, rank, flags);
+*r = vgic_reg32_extract(itargetsr, info);
+
 return 1;
+}
 
 case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+{
+uint32_t ipriorityr;
+
 if ( dabt.size != DABT_BYTE && dabt.size != DABT_WORD ) goto bad_width;
 rank = vgic_rank_offset(v, 8, gicd_reg - GICD_IPRIORITYR, DABT_WORD);
-if ( rank == NULL) goto read_as_zero;
+if ( rank == NULL ) goto read_as_zero;
 
 vgic_lock_rank(v, rank, flags);
-*r = rank->ipriorityr[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR,

[Xen-devel] [PATCH v5 6/6] xen/arm: vgic-v3: Support 32-bit access for 64-bit registers

[Julien Grall]

Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers
supports both 32-bit and 64-bits access.

All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access.

For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway,
emulating 32-bit access for them doesn't hurt. Note that we would need
some extra care when they will be implemented (for instance GICR_PROPBASER).

Signed-off-by: Julien Grall 
Acked-by: Ian Campbell 

---
This is technically fixing boot of FreeBSD ARM64 guest with GICv3.

AFAICT, Linux is not using 32-bit access in the GICv3 code expect
for the ITS (which we don't support yet).

So this patch is a good candidate for Xen 4.6.1. Although this patch is
heavily depend on previous patches. It may be possible to shuffle
and move the "opmitization" patches towards the end. I haven't yet
done that because I feel this series makes more sense in the current
order.

Also, I haven't move vgic_reg64_check_access in vgic.h because there
is no usage in this series outside of vgic-v3.c and the helpers is
GICv3 oriented.

Changes in v2:
- Add Ian's acked-by

Changes in v1:
- Support 32bit access on the most significant word of
GICR_TYPER
---
 xen/arch/arm/vgic-v3.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 54e0e39..230c7e6 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -157,6 +157,15 @@ static void vgic_store_irouter(struct domain *d, struct 
vgic_irq_rank *rank,
 rank->vcpu[offset] = new_vcpu->vcpu_id;
 }
 
+static inline bool vgic_reg64_check_access(struct hsr_dabt dabt)
+{
+/*
+ * 64 bits registers can be accessible using 32-bit and 64-bit unless
+ * stated otherwise (See 8.1.3 ARM IHI 0069A).
+ */
+return ( dabt.size == DABT_DOUBLE_WORD || dabt.size == DABT_WORD );
+}
+
 static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
  uint32_t gicr_reg,
  register_t *r)
@@ -173,10 +182,11 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 *r = vgic_reg32_extract(GICV3_GICR_IIDR_VAL, info);
 return 1;
 case GICR_TYPER:
+case GICR_TYPER + 4:
 {
 uint64_t typer, aff;
 
-if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
 /* TBD: Update processor id in [23:8] when ITS support is added */
 aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
@@ -262,7 +272,7 @@ bad_width:
 return 0;
 
 read_as_zero_64:
-if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
 *r = 0;
 return 1;
 
@@ -338,7 +348,7 @@ bad_width:
 return 0;
 
 write_ignore_64:
-if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
+if ( vgic_reg64_check_access(dabt) ) goto bad_width;
 return 1;
 
 write_ignore_32:
@@ -803,7 +813,7 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 {
 uint64_t irouter;
 
-if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
 rank = vgic_rank_offset(v, 64, gicd_reg - GICD_IROUTER,
 DABT_DOUBLE_WORD);
 if ( rank == NULL ) goto read_as_zero;
@@ -878,7 +888,7 @@ bad_width:
 return 0;
 
 read_as_zero_64:
-if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
+if ( vgic_reg64_check_access(dabt) ) goto bad_width;
 *r = 0;
 return 1;
 
@@ -971,7 +981,7 @@ static int vgic_v3_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 {
 uint64_t irouter;
 
-if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
 rank = vgic_rank_offset(v, 64, gicd_reg - GICD_IROUTER,
 DABT_DOUBLE_WORD);
 if ( rank == NULL ) goto write_ignore;
@@ -1030,7 +1040,7 @@ write_ignore_32:
 return 1;
 
 write_ignore_64:
-if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
+if ( vgic_reg64_check_access(dabt) ) goto bad_width;
 return 1;
 
 write_ignore:
-- 
2.1.4


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

[Xen-devel] [PATCH v5 4/6] xen/arm: vgic: Optimize the way to store the target vCPU in the rank

[Julien Grall]

Xen is currently directly storing the value of GICD_ITARGETSR register
(for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the
emulation of the registers access very simple but makes the code to get
the target vCPU for a given vIRQ more complex.

While the target vCPU of an vIRQ is retrieved every time an vIRQ is
injected to the guest, the access to the register occurs less often.

So the data structure should be optimized for the most common case
rather than the inverse.

This patch introduces the usage of an array to store the target vCPU for
every interrupt in the rank. This will make the code to get the target
very quick. The emulation code will now have to generate the GICD_ITARGETSR
and GICD_IROUTER register for read access and split it to store in a
convenient way.

With the new way to store the target vCPU, the structure vgic_irq_rank
is shrunk down from 320 bytes to 92 bytes. This is saving about 228
bytes of memory allocated separately per vCPU.

Note that with these changes, any read to those register will list only
the target vCPU used by Xen. As the spec is not clear whether this is a
valid choice or not, OSes which have a different interpretation of the
spec (i.e OSes which perform read-modify-write operations on these
registers) may not boot anymore on Xen. Although, I think this is fair
trade between memory usage in Xen (1KB less on a domain using 4 vCPUs
with no SPIs) and a strict interpretation of the spec (though all the
cases are not clearly defined).

Furthermore, the implementation of the callback get_target_vcpu is now
exactly the same. Consolidate the implementation in the common vGIC code
and drop the callback.

Finally take the opportunity to fix coding style and replace "irq" by
"virq" to make clear that we are dealing with virtual IRQ in section we
are modifying.

Signed-off-by: Julien Grall 

---
The real reason is I'd like to drop vgic_byte_* helpers in favor of more
generic access helpers. Although it would make the code to retrieve the
priority more complex. So reworking the code to get the target vCPU
was the best solution.

Changes in v5:
- NR_TARGET_PER_REG has been renamed to NR_TARGETS_PER_ITARGETSR
- NR_BIT_PER_TARGET has been renamed to NR_BITS_PER_TARGET
- Fix comments
- s/NR_BYTE_PER_IROUTER/NR_BYTES_PER_IROUTER/
- Remove the duplicate declaration of virq in vgic_store_itargetsr

Changes in v4:
- Move the behavior changes in 2 separate patches:
* patch #1: Handle correctly byte write in ITARGETSR
* patch #2: Don't ignore a write in ITARGETSR if one field is 0
- Update commit message

Changes in v3:
- Make clear in the commit message that we rely on a corner case
of the spec.
- Typoes

Changes in v2:
- Remove get_target_vcpu callback
- s/irq/virq/ to make clear we are using virtual IRQ
- Update the commit message
- Rename vgic_generate_* to vgic_fetch
- Improve code comment
- Move the introduction of vgic_rank_init in a separate patch
- Make use of rank->idx

Changes in v1:
- Patch added
---
 xen/arch/arm/vgic-v2.c |  86 +---
 xen/arch/arm/vgic-v3.c | 119 -
 xen/arch/arm/vgic.c|  45 -
 xen/include/asm-arm/vgic.h |  18 +++
 4 files changed, 137 insertions(+), 131 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index ad2ea0a..62159bf 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -61,8 +61,31 @@ void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t 
csize,
 #define NR_BITS_PER_TARGET  (32U / NR_TARGETS_PER_ITARGETSR)
 
 /*
- * Store an ITARGETSR register. This function only deals with ITARGETSR8
- * and onwards.
+ * Fetch an ITARGETSR register based on the offset from ITARGETSR0. Only
+ * one vCPU will be listed for a given vIRQ.
+ *
+ * Note the offset will be aligned to the appropriate boundary.
+ */
+static uint32_t vgic_fetch_itargetsr(struct vgic_irq_rank *rank,
+ unsigned int offset)
+{
+uint32_t reg = 0;
+unsigned int i;
+
+ASSERT(spin_is_locked(>lock));
+
+offset &= INTERRUPT_RANK_MASK;
+offset &= ~(NR_TARGETS_PER_ITARGETSR - 1);
+
+for ( i = 0; i < NR_TARGETS_PER_ITARGETSR; i++, offset++ )
+reg |= (1 << rank->vcpu[offset]) << (i * NR_BITS_PER_TARGET);
+
+return reg;
+}
+
+/*
+ * Store an ITARGETSR register in a convenient way and migrate the vIRQ
+ * if necessary. This function only deals with ITARGETSR8 and onwards.
  *
  * Note the offset will be aligned to the appropriate boundary.
  */
@@ -70,7 +93,6 @@ static void vgic_store_itargetsr(struct domain *d, struct 
vgic_irq_rank *rank,
  unsigned int offset, uint32_t itargetsr)
 {
 unsigned int i;
-

[Xen-devel] [PATCH v5 1/6] xen/arm: vgic-v2: Implement correctly ITARGETSR0 - ITARGETSR7 read-only

[Julien Grall]

Each ITARGETSR register are 4-byte wide and the offset is in byte.

The current implementation is computing the end of the range wrongly
resulting to emulate only ITARGETSR{0,1} read-only. The rest will be
treated as read-write.

As 8 registers should be read-only, the end of the range should be
ITARGETSR + (4 * 8) - 1.

For convenience introduce ITARGETSR7 and ITARGETSR8.

Signed-off-by: Julien Grall 

---
This would be a good candidate to backport. Without it a guest could
modify ITARGETSR{0-7} and redirect the interrupt to the wrong vCPU.

Spotted while testing to boot FreeBSD guest with this series.
FreeBSD is writing in ITARGETSR{0 - 7} and will therefore crash xen
due to the valid ASSERT in vgic_store_itargetsr.

Note that the emulation is not properly emulated the last register
of each range. I'm planning to fix it in a follow-up series.

Changes in v5:
- Patch added
---
 xen/arch/arm/vgic-v2.c| 4 ++--
 xen/include/asm-arm/gic.h | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index f7d784b..041291c 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -338,11 +338,11 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
v, r, gicd_reg - GICD_ICACTIVER);
 return 0;
 
-case GICD_ITARGETSR ... GICD_ITARGETSR + 7:
+case GICD_ITARGETSR ... GICD_ITARGETSR7:
 /* SGI/PPI target is read only */
 goto write_ignore_32;
 
-case GICD_ITARGETSR + 8 ... GICD_ITARGETSRN:
+case GICD_ITARGETSR8 ... GICD_ITARGETSRN:
 {
 /* unsigned long needed for find_next_bit */
 unsigned long target;
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 0116481..3064d1c 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -42,6 +42,8 @@
 #define GICD_IPRIORITYR (0x400)
 #define GICD_IPRIORITYRN (0x7F8)
 #define GICD_ITARGETSR  (0x800)
+#define GICD_ITARGETSR7 (0x81C)
+#define GICD_ITARGETSR8 (0x820)
 #define GICD_ITARGETSRN (0xBF8)
 #define GICD_ICFGR  (0xC00)
 #define GICD_ICFGRN (0xCFC)
-- 
2.1.4


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

[Xen-devel] [PATCH v5 0/6] xen/arm: vgic: Support 32-bit access for 64-bit register

[Julien Grall]

Hi all,

This series aims to fix the 32-bit access on 64-bit registers. Some guest
OS such as FreeBSD and Linux (ITS and recently 32-bit guest using GICv3)
use 32-bit access and will crash at boot time.

For all the changes see in each patch.

Sincerely yours,

Julien Grall (6):
  xen/arm: vgic-v2: Implement correctly ITARGETSR0 - ITARGETSR7
read-only
  xen/arm: vgic-v2: Handle correctly byte write in ITARGETSR
  xen/arm: vgic-v2: Don't ignore a write in ITARGETSR if one field is 0
  xen/arm: vgic: Optimize the way to store the target vCPU in the rank
  xen/arm: vgic: Introduce helpers to extract/update/clear/set vGIC
register ...
  xen/arm: vgic-v3: Support 32-bit access for 64-bit registers

 xen/arch/arm/vgic-v2.c | 282 +++--
 xen/arch/arm/vgic-v3.c | 264 ++
 xen/arch/arm/vgic.c|  45 ++--
 xen/include/asm-arm/gic.h  |   2 +
 xen/include/asm-arm/vgic.h | 129 +
 5 files changed, 480 insertions(+), 242 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH v5 3/6] xen/arm: vgic-v2: Don't ignore a write in ITARGETSR if one field is 0

[Julien Grall]

The current implementation ignores the whole write if one of the field is
0. Although, based on the spec (4.3.12 IHI 0048B.b), 0 is a valid value
when:
- The interrupt is not wired in the distributor. From the Xen
point of view, it means that the corresponding bit is not set in
d->arch.vgic.allocated_irqs.
- The user wants to disable the IRQ forwarding in the distributor.
I.e the IRQ stays pending in the distributor and never received by
the guest.

Implementing the later will require more work in Xen because we always
assume the interrupt is forwarded to a valid vCPU. So for now, ignore
any field where the value is 0.

The emulation of the write access of ITARGETSR has been reworked and
moved to a new function because it would have been difficult to
implement properly the behavior with the current code.

The new implementation is breaking the register in 4 distinct bytes. For
each byte, it will check the validity of the target list, find the new
target, migrate the interrupt and store the value if necessary.

In the new implementation there is nearly no distinction of the access
size to avoid having too many different path which is harder to test.

Signed-off-by: Julien Grall 

---
This change used to be embedded in "xen/arm: vgic: Optimize the way
to store the target vCPU in the rank". It has been moved out to
avoid having too much functional changes in a single patch.

I'm not sure if this patch should be backported to Xen 4.6. Without
it any guest writing 0 in one the field won't be able to migrate
other interrupts. Although, in all the use case I've seen, the guest
is read ITARGETSR first and write-back the value with the
corresponding byte changed.

Note that NR_BITS_PER_TARGET has been kept as a define because it
will be use in another function in the next patch and I wanted to
avoid having to duplicate const var = ...

Changes in v5:
- s/NR_TARGET_PER_REG/NR_TARGETS_PER_ITARGETSR/
- s/NR_BIT_PER_TARGET/NR_BITS_PER_TARGET/
- Compute NR_BITS_PER_TARGET based on NR_TARGETS_PER_ITARGETSR
- Typoes in the comments
- Compute the shift for itargetsr on every loop
- Use gprintk(XENLOG_WARNING,...)
- Clarify commit message

Changes in v4:
- Patch added
---
 xen/arch/arm/vgic-v2.c | 145 ++---
 1 file changed, 102 insertions(+), 43 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 486e497..ad2ea0a 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -57,6 +57,98 @@ void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t 
csize,
 vgic_v2_hw.aliased_offset = aliased_offset;
 }
 
+#define NR_TARGETS_PER_ITARGETSR4U
+#define NR_BITS_PER_TARGET  (32U / NR_TARGETS_PER_ITARGETSR)
+
+/*
+ * Store an ITARGETSR register. This function only deals with ITARGETSR8
+ * and onwards.
+ *
+ * Note the offset will be aligned to the appropriate boundary.
+ */
+static void vgic_store_itargetsr(struct domain *d, struct vgic_irq_rank *rank,
+ unsigned int offset, uint32_t itargetsr)
+{
+unsigned int i;
+unsigned int regidx = REG_RANK_INDEX(8, offset, DABT_WORD);
+unsigned int virq;
+
+ASSERT(spin_is_locked(>lock));
+
+/*
+ * The ITARGETSR0-7, used for SGIs/PPIs, are implemented RO in the
+ * emulation and should never call this function.
+ *
+ * They all live in the first rank.
+ */
+BUILD_BUG_ON(NR_INTERRUPT_PER_RANK != 32);
+ASSERT(rank->index >= 1);
+
+offset &= INTERRUPT_RANK_MASK;
+offset &= ~(NR_TARGETS_PER_ITARGETSR - 1);
+
+virq = rank->index * NR_INTERRUPT_PER_RANK + offset;
+
+for ( i = 0; i < NR_TARGETS_PER_ITARGETSR; i++, offset++, virq++ )
+{
+unsigned int new_target, old_target;
+uint8_t new_mask, old_mask;
+
+/*
+ * Don't need to mask as we rely on new_mask to fit for only one
+ * target.
+ */
+BUILD_BUG_ON((sizeof (new_mask) * 8) != NR_BITS_PER_TARGET);
+
+new_mask = itargetsr >> (i * NR_BITS_PER_TARGET);
+old_mask = vgic_byte_read(rank->v2.itargets[regidx], i);
+
+/*
+ * SPIs are using the 1-N model (see 1.4.3 in ARM IHI 0048B).
+ * While the interrupt could be set pending to all the vCPUs in
+ * target list, it's not guaranteed by the spec.
+ * For simplicity, always route the vIRQ to the first interrupt
+ * in the target list
+ */
+new_target = ffs(new_mask);
+old_target = ffs(old_mask);
+
+/* The current target should always be valid */
+ASSERT(old_target && (old_target <= d->max_vcpus));
+
+/*
+ * Ignore the write request for this interrupt if the new target
+ * is invalid.
+ * XXX: From the spec, if the target list is not valid, the
+ * interrupt should 

Re: [Xen-devel] RFC: PV vfb's and the handling of global vnc options

[Konrad Rzeszutek Wilk]

On Mon, Nov 09, 2015 at 03:03:17PM +, George Dunlap wrote:
> So I had a user report that he couldn't get the vnclisten option to
> work.  It turns out he was using a PV guest, and had the following in
> his config file:
> 
> vfb=[ 'type=vnc' ]
> vnclisten='0.0.0.0'
> 
> After digging around in the code, it turns out that the following is
> accepted for PV guests:
> 
> vnc=1
> vnclisten='0.0.0.0'
> 
> ...on the condition that there be *no* vfb option.  If you set the vfb
> option, then the top-level vnc entries are completely ignored.

Ha!
> 
> The following also works (as one might expect):
> 
> vfb=[ 'type=vnc,vnclisten=0.0.0.0' ]
> 
> The man page is a bit unclear here; it says:
> 
> If "Emulated VGA Graphics Device" options are used in a PV guest
> configuration, xl will pick up vnc, vnclisten, vncpasswd, vncdisplay,
> vncunused, sdl, opengl and keymap to construct paravirtual framebuffer
> device for the guest.
> 
> I see two options:
> 
> 1. Make vfb take defaults from the top-level vnc options

Keep in mind that for HVM guests we would want only the 'vnc' options
from the 'vfb'. That is because by default we boot with 'vga=cirrus'
and with both backends (VGA VNC and PV FB) the guest gets mighty
confused during bootup. That is - the initial 'text' console goes
to the PV FB and the KDM/GDM goes in the VGA VNC. But the 'PV FB'
is the first one and most tools except only one VNC backend.

> 
> 2. Clarify the man page to make it clear that top-level vnc options
> will only have an effect if no vfb is specified.

The manpage was probably constructed during the reign of Xend. In
which you could have both options (vfb= and vnc=) .. and Xend would
happily expose in Xenstore the pvfb keys with the old QEMU
(which would default to the VGA for HVM guests). Which meant that the
guest would spend 30 seconds trying to use the PVFB backend driver :-(

> 
> I'm of two minds which one is best.  At the moment I'm leaning towards
> #2, possibly adding a warning if it finds both vfb and toplevel vnc
> options, saying that it's ignoring the second.
> 
> Any opinions?

I like #1 as it would make it easy to use the old style Xend
configuration files doing the right thing.

With PVH and with 'qemu=none'..you would want the PVFB, if the
user used 'vnc' or 'vfb'.

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

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

Re: [Xen-devel] [PATCH v2 1/6] gitignore: Ignore *.orig, *.rej and *.swp files

[Daniel Kiper]

On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> Le 12 août 2015 11:04 AM, "Ian Campbell"  a écrit :
> >
> >
> > (Having written the below I see too late that this is a grub patch not a
> > Xen one, a tag in the subject for such cross posted patches would be
> useful
> > please. Anyway, my opinion counts for very little in this context but I
> > leave it below since already I wrote it. I notice that xen.git#.gitignore
> > _does_ list *.rej, which I think is wrong...)
> >
> > On Mon, 2015-07-20 at 16:35 +0200, Daniel Kiper wrote:
> > > Signed-off-by: Daniel Kiper 
> >
> > At least *.rej and perhaps *.orig are indicative of a failed patch
> > application, I think I want them to appear in "git status".
> >
> > By way of comparison Linux's .gitignore includes *.orig but not *.rej and
> > Qemu's includes neither.
> >
> > So nack to the addition of *.rej from me. I'm more or less ambivalent
> about
> > *.orig.
> >
> I have to agree. You should clean up *.rej *.orig after fixing conflicts

Thanks for comment on this. Could you review rest of this patchset?
I am working on v3 and it will be nice to take your (and others if
possible) comments into it.

Daniel

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

[Xen-devel] [PATCH v5 2/6] xen/arm: vgic-v2: Handle correctly byte write in ITARGETSR

[Julien Grall]

During a store, the byte is always in the low part of the register (i.e
[0:7]).

We are incorrectly masking the register by using a shift of the byte
offset in the ITARGETSR while the byte is alwasy in r[0:7]. This will
result in a target list equal to 0 which is ignored by the emulation.

Because of that the guest will only be able to modify the first byte in
each ITARGETSR.

Furthermore, the body of the loop is retrieving the old target list
using the index of the byte.

To avoid modifying too much the loop, shift the byte stored to the correct
offset.

Signed-off-by: Julien Grall 


This change used to be embedded in "xen/arm: vgic: Optimize the way
to store the target vCPU in the rank". It has been moved out to
avoid having too much functional changes in a single patch.

This patch is a good candidate to backport to Xen 4.6 and Xen 4.5.
Without it a guest won't be able migrate an IRQ from one vCPU to
another if it's using byte access to write in ITARGETSR.

Note that if we backport this patch alone, the resulting code in
earlier version of Xen will be complex to read. As the last patch
of this serie should also be backported, I'm planning to request
backport for the whole series.

Changes in v5:
- Update commit message based on Ian's suggestion

Changes in v4:
- Patch added
---
 xen/arch/arm/vgic-v2.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 041291c..486e497 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -353,11 +353,11 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 /* 8-bit vcpu mask for this domain */
 BUG_ON(v->domain->max_vcpus > 8);
 target = (1 << v->domain->max_vcpus) - 1;
-if ( dabt.size == 2 )
-target = target | (target << 8) | (target << 16) | (target << 24);
+target = target | (target << 8) | (target << 16) | (target << 24);
+if ( dabt.size == DABT_WORD )
+target &= r;
 else
-target = (target << (8 * (gicd_reg & 0x3)));
-target &= r;
+target &= (r << (8 * (gicd_reg & 0x3)));
 /* ignore zero writes */
 if ( !target )
 goto write_ignore;
@@ -381,7 +381,7 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 
 if ( new_target != old_target )
 {
-irq = gicd_reg - GICD_ITARGETSR + (i / 8);
+irq = (gicd_reg & ~0x3) - GICD_ITARGETSR + (i / 8);
 v_target = v->domain->vcpu[new_target];
 v_old = v->domain->vcpu[old_target];
 vgic_migrate_irq(v_old, v_target, irq);
@@ -393,7 +393,7 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
  DABT_WORD)] = target;
 else
 vgic_byte_write(>v2.itargets[REG_RANK_INDEX(8,
-  gicd_reg - GICD_ITARGETSR, DABT_WORD)], target, 
gicd_reg);
+  gicd_reg - GICD_ITARGETSR, DABT_WORD)], r, gicd_reg);
 vgic_unlock_rank(v, rank, flags);
 return 1;
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 1/6] gitignore: Ignore *.orig, *.rej and *.swp files

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 09.11.2015 16:39, Daniel Kiper wrote:
> On Mon, Nov 09, 2015 at 04:34:20PM +0100, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> On 09.11.2015 16:29, Daniel Kiper wrote:
>>> On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko 
>>> wrote:
 Le 12 août 2015 11:04 AM, "Ian Campbell"  a écrit 
 :
>
>
> (Having written the below I see too late that this is a grub patch not a
> Xen one, a tag in the subject for such cross posted patches would be
 useful
> please. Anyway, my opinion counts for very little in this context but I
> leave it below since already I wrote it. I notice that xen.git#.gitignore
> _does_ list *.rej, which I think is wrong...)
>
> On Mon, 2015-07-20 at 16:35 +0200, Daniel Kiper wrote:
>> Signed-off-by: Daniel Kiper 
>
> At least *.rej and perhaps *.orig are indicative of a failed patch
> application, I think I want them to appear in "git status".
>
> By way of comparison Linux's .gitignore includes *.orig but not *.rej and
> Qemu's includes neither.
>
> So nack to the addition of *.rej from me. I'm more or less ambivalent
 about
> *.orig.
>
 I have to agree. You should clean up *.rej *.orig after fixing conflicts
>>>
>>> Thanks for comment on this. Could you review rest of this patchset?
>>> I am working on v3 and it will be nice to take your (and others if
>>> possible) comments into it.
>>>
>> I will go through them today
> 
> Thanks a lot!
> 
All reviewed. Some of them already good but they have dependencies. Feel
free to either fix concerns with dependencies or rebase in a way to get
the good ones committed first in a meaningful way
> Daniel
> 




signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/3] xen/arm: set the system time in Xen via the XENPF_settime hypercall

[Arnd Bergmann]

On Monday 09 November 2015 17:42:50 Stefano Stabellini wrote:
> On Mon, 9 Nov 2015, Stefano Stabellini wrote:
> > On Mon, 9 Nov 2015, Arnd Bergmann wrote:
> > > On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote:
> > > 
> > > Just to make sure that this is actually the correct interface
> > > that you want to call:
> > > 
> > > __current_kernel_time{,64}() is the fastest interface we have
> > > to get an approximation of the current time, while ignoring
> > > all of the locking.
> > > 
> > > Is is possible that you instead want ktime_get_real_ts64(),
> > > which gives you the time as precise as the kernel knows it,
> > > but uses locking?
> > 
> > I am not 100% sure. Can I call ktime_get_real_ts64 from a
> > pvclock_gtod notifier_call function?
> 
> It doesn't look like it: we would be getting the tk_core seqcount twice.

Ok, I see. I'm still unsure what this is all good for, but at
least this call appears to be safe.

Arnd

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

Re: [Xen-devel] [PATCH v2 3/6] i386/relocator: Add grub_relocator64_efi relocator

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.07.2015 16:35, Daniel Kiper wrote:
> Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
> when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
> will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
> On the other hand processor mode, just before jumping into loaded image, will
> be set accordingly to Unified Extensible Firmware Interface Specification,
> Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
> loaded image will be able to use EFI boot services without any issues.
> 
> If idea is accepted I will prepare grub_relocator32_efi relocator too.
> 
> Signed-off-by: Daniel Kiper 
> ---
>  grub-core/Makefile.core.def  |1 +
>  grub-core/lib/i386/relocator.c   |   53 +++
>  grub-core/lib/i386/relocator64_efi.S |   77 
> ++
>  grub-core/loader/multiboot.c |   29 +++--
>  grub-core/loader/multiboot_mbi2.c|   19 +++--
>  include/grub/i386/multiboot.h|   11 +
>  include/grub/i386/relocator.h|   21 ++
>  include/multiboot2.h |9 
>  8 files changed, 213 insertions(+), 7 deletions(-)
>  create mode 100644 grub-core/lib/i386/relocator64_efi.S
> 
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index a6101de..d583549 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -1519,6 +1519,7 @@ module = {
>x86 = lib/i386/relocator_common_c.c;
>ieee1275 = lib/ieee1275/relocator.c;
>efi = lib/efi/relocator.c;
> +  x86_64_efi = lib/i386/relocator64_efi.S;
>mips = lib/mips/relocator_asm.S;
>mips = lib/mips/relocator.c;
>powerpc = lib/powerpc/relocator_asm.S;
> diff --git a/grub-core/lib/i386/relocator.c b/grub-core/lib/i386/relocator.c
> index 71dd4f0..459027e 100644
> --- a/grub-core/lib/i386/relocator.c
> +++ b/grub-core/lib/i386/relocator.c
> @@ -69,6 +69,19 @@ extern grub_uint64_t grub_relocator64_rsi;
>  extern grub_addr_t grub_relocator64_cr3;
>  extern struct grub_i386_idt grub_relocator16_idt;
>  
> +#ifdef GRUB_MACHINE_EFI
> +#ifdef __x86_64__
> +extern grub_uint8_t grub_relocator64_efi_start;
> +extern grub_uint8_t grub_relocator64_efi_end;
> +extern grub_uint64_t grub_relocator64_efi_rax;
> +extern grub_uint64_t grub_relocator64_efi_rbx;
> +extern grub_uint64_t grub_relocator64_efi_rcx;
> +extern grub_uint64_t grub_relocator64_efi_rdx;
> +extern grub_uint64_t grub_relocator64_efi_rip;
> +extern grub_uint64_t grub_relocator64_efi_rsi;
> +#endif
> +#endif
> +
>  #define RELOCATOR_SIZEOF(x)  (_relocator##x##_end - 
> _relocator##x##_start)
>  
>  grub_err_t
> @@ -214,3 +227,43 @@ grub_relocator64_boot (struct grub_relocator *rel,
>/* Not reached.  */
>return GRUB_ERR_NONE;
>  }
> +
> +#ifdef GRUB_MACHINE_EFI
> +#ifdef __x86_64__
> +grub_err_t
> +grub_relocator64_efi_boot (struct grub_relocator *rel,
> +struct grub_relocator64_efi_state state)
> +{
> +  grub_err_t err;
> +  void *relst;
> +  grub_relocator_chunk_t ch;
> +
> +  err = grub_relocator_alloc_chunk_align (rel, , 0,
> +   0x4000 - RELOCATOR_SIZEOF 
> (64_efi),
> +   RELOCATOR_SIZEOF (64_efi), 16,
> +   GRUB_RELOCATOR_PREFERENCE_NONE, 1);
> +  if (err)
> +return err;
> +
> +  grub_relocator64_efi_rax = state.rax;
> +  grub_relocator64_efi_rbx = state.rbx;
> +  grub_relocator64_efi_rcx = state.rcx;
> +  grub_relocator64_efi_rdx = state.rdx;
> +  grub_relocator64_efi_rip = state.rip;
> +  grub_relocator64_efi_rsi = state.rsi;
> +
> +  grub_memmove (get_virtual_current_address (ch), 
> _relocator64_efi_start,
> + RELOCATOR_SIZEOF (64_efi));
> +
> +  err = grub_relocator_prepare_relocs (rel, get_physical_target_address (ch),
> +, NULL);
> +  if (err)
> +return err;
> +
> +  ((void (*) (void)) relst) ();
> +
> +  /* Not reached.  */
> +  return GRUB_ERR_NONE;
> +}
> +#endif
> +#endif
> diff --git a/grub-core/lib/i386/relocator64_efi.S 
> b/grub-core/lib/i386/relocator64_efi.S
> new file mode 100644
> index 000..fcd1964
> --- /dev/null
> +++ b/grub-core/lib/i386/relocator64_efi.S
> @@ -0,0 +1,77 @@
> +/*
> + *  GRUB  --  GRand Unified Bootloader
> + *  Copyright (C) 2009,2010  Free Software Foundation, Inc.
> + *  Copyright (C) 2014,2015  Oracle Co.
> + *  Author: Daniel Kiper
> + *
> + *  GRUB is free software: you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation, either version 3 of the License, or
> + *  (at your option) any later version.
> + *
> + *  GRUB is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS 

Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock

[Arnd Bergmann]

On Monday 09 November 2015 17:14:24 Stefano Stabellini wrote:
> On Mon, 9 Nov 2015, Arnd Bergmann wrote:
> > On Monday 09 November 2015 13:53:30 Stefano Stabellini wrote:
> > > On Fri, 6 Nov 2015, Arnd Bergmann wrote:
> > > > I'm not quite sure about how the split between pvclock_wall_clock and
> > > > the delta works. Normally I'd expect that pvclock_wall_clock is the 
> > > > wallclock
> > > > time as it was at boot, while delta is the number of expired nanoseconds
> > > > since boot. However it is unclear why the latter has a longer range
> > > > (539 years starting at boot, rather than 126 years starting in 1970).
> > > 
> > > Actually we already have a sec overflow field in struct shared_info on
> > > the hypervisor side, called wc_sec_hi. I just need to make use of it in
> > > Linux. See:
> > > 
> > > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=xen/include/public/xen.h;hb=HEAD
> > > 
> > > Thanks for raising my attention to the problem,
> > 
> > Sounds good for Xen on ARM. This same interface is also used on
> > KVM, right? Does the extension also work there?
> 
> It doesn't look like it (see arch/x86/kvm/x86.c:kvm_write_wall_clock).

(adding Christoffer and Marc)

That kvm_set_msr_common() function appears to be very x86 specific though,
and I'm not sure what the ARM equivalent would be.

How does KVM get/set the system time today on ARM and ARM64? Is this
going to be done through a PSCI call based on pvclock_wall_clock in
the future?

Arnd

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

Re: [Xen-devel] [PATCH v2 5/6] multiboot2: Add support for relocatable images

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.07.2015 16:35, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper 
What is handling the actual relocation? Why doesn't this patch include
support for ELF relocations?
> ---
>  grub-core/loader/i386/multiboot_mbi.c |6 ++--
>  grub-core/loader/multiboot.c  |   12 +--
>  grub-core/loader/multiboot_elfxx.c|   28 +++
>  grub-core/loader/multiboot_mbi2.c |   63 
> +
>  include/grub/multiboot.h  |4 ++-
>  include/multiboot2.h  |   24 +
>  6 files changed, 118 insertions(+), 19 deletions(-)
> 
> diff --git a/grub-core/loader/i386/multiboot_mbi.c 
> b/grub-core/loader/i386/multiboot_mbi.c
> index 956d0e3..abdb98b 100644
> --- a/grub-core/loader/i386/multiboot_mbi.c
> +++ b/grub-core/loader/i386/multiboot_mbi.c
> @@ -72,7 +72,8 @@ load_kernel (grub_file_t file, const char *filename,
>grub_err_t err;
>if (grub_multiboot_quirks & GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
>  {
> -  err = grub_multiboot_load_elf (file, filename, buffer);
> +  err = grub_multiboot_load_elf (file, filename, buffer, 0, 0, 0, 0,
> +  GRUB_RELOCATOR_PREFERENCE_NONE, NULL, 0);
>if (err == GRUB_ERR_UNKNOWN_OS && (header->flags & 
> MULTIBOOT_AOUT_KLUDGE))
>   grub_errno = err = GRUB_ERR_NONE;
>  }
> @@ -118,7 +119,8 @@ load_kernel (grub_file_t file, const char *filename,
>return GRUB_ERR_NONE;
>  }
>  
> -  return grub_multiboot_load_elf (file, filename, buffer);
> +  return grub_multiboot_load_elf (file, filename, buffer, 0, 0, 0, 0,
> +   GRUB_RELOCATOR_PREFERENCE_NONE, NULL, 0);
>  }
>  
>  static struct multiboot_header *
> diff --git a/grub-core/loader/multiboot.c b/grub-core/loader/multiboot.c
> index ca7154f..1b1f7a9 100644
> --- a/grub-core/loader/multiboot.c
> +++ b/grub-core/loader/multiboot.c
> @@ -190,12 +190,18 @@ static grub_uint64_t highest_load;
>  /* Load ELF32 or ELF64.  */
>  grub_err_t
>  grub_multiboot_load_elf (grub_file_t file, const char *filename,
> -  void *buffer)
> +  void *buffer, int relocatable, grub_uint32_t min_addr,
> +  grub_uint32_t max_addr, grub_size_t align, 
> grub_uint32_t preference,
> +  grub_uint32_t *base_addr, int avoid_efi_boot_services)
>  {
>if (grub_multiboot_is_elf32 (buffer))
> -return grub_multiboot_load_elf32 (file, filename, buffer);
> +return grub_multiboot_load_elf32 (file, filename, buffer, relocatable,
> +   min_addr, max_addr, align, preference,
> +   base_addr, avoid_efi_boot_services);
>else if (grub_multiboot_is_elf64 (buffer))
> -return grub_multiboot_load_elf64 (file, filename, buffer);
> +return grub_multiboot_load_elf64 (file, filename, buffer, relocatable,
> +   min_addr, max_addr, align, preference,
> +   base_addr, avoid_efi_boot_services);
>  
>return grub_error (GRUB_ERR_UNKNOWN_OS, N_("invalid arch-dependent ELF 
> magic"));
>  }
> diff --git a/grub-core/loader/multiboot_elfxx.c 
> b/grub-core/loader/multiboot_elfxx.c
> index 6a220bd..4fce685 100644
> --- a/grub-core/loader/multiboot_elfxx.c
> +++ b/grub-core/loader/multiboot_elfxx.c
> @@ -51,7 +51,10 @@ CONCAT(grub_multiboot_is_elf, XX) (void *buffer)
>  }
>  
>  static grub_err_t
> -CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, const char *filename, 
> void *buffer)
> +CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, const char *filename,
> +  void *buffer, int relocatable, 
> grub_uint32_t min_addr,
> +  grub_uint32_t max_addr, grub_size_t align, 
> grub_uint32_t preference,
> +  grub_uint32_t *base_addr, int 
> avoid_efi_boot_services)
>  {
>Elf_Ehdr *ehdr = (Elf_Ehdr *) buffer;
>char *phdr_base;
> @@ -89,19 +92,30 @@ CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, 
> const char *filename, voi
> if (phdr(i)->p_paddr + phdr(i)->p_memsz > highest_load)
>   highest_load = phdr(i)->p_paddr + phdr(i)->p_memsz;
>  
> -   grub_dprintf ("multiboot_loader", "segment %d: paddr=0x%lx, 
> memsz=0x%lx, vaddr=0x%lx\n",
> - i, (long) phdr(i)->p_paddr, (long) phdr(i)->p_memsz, 
> (long) phdr(i)->p_vaddr);
> +   grub_dprintf ("multiboot_loader", "segment %d: paddr=0x%lx, 
> memsz=0x%lx, vaddr=0x%lx,"
> + "align=0x%lx, relocatable=%d, 
> avoid_efi_boot_services=%d\n", i,
> + (long) phdr(i)->p_paddr, (long) phdr(i)->p_memsz, 
> (long) phdr(i)->p_vaddr,
> + (long) align, relocatable, avoid_efi_boot_services);
>  
> {
>   grub_relocator_chunk_t ch;
> - err = grub_relocator_alloc_chunk_addr (grub_multiboot_relocator, 
> - 

Re: [Xen-devel] [qubes-devel] Re: Critique of the Xen Security Process

[Wojtek Porczyk]

On Mon, Nov 09, 2015 at 04:31:58PM +, Franz wrote:
> Perhaps a way out of this impasse is to put bounties on Xen security tasks
> identified by Joanna and properly advertise these bounties to Xen users.
> [snip]

This is fundamentaly wrong idea. Security isn't something you can
"apply" or put bounty on. It's a state of the mind, especcialy
developer's. Joanna wrote in her mail:

> > > I can't help but have a feeling that some of the Xen developers seem to be
> > > overconfident in their belief they can fully understand all the possible
> > > execution paths in their code. Well, the XSAs quoted above are an 
> > > indisputable
> > > prove that this is not quite always the case. Realizing that, each 
> > > developer by
> > > themselves, might be a great step towards a more secure hypervisor...

And that's why we can't just "submit a patch" to "contribute security".
There is something wrong with Xen as a whole project, but that something
isn't the code. There is a mindset to be fixed.

-- 
regards,_.-._
Wojtek Porczyk   .-^'   '^-.
Invisible Things Lab |'-.-^-.-'|
 |  |   |  |
 I do not fear computers,|  '-.-'  |
 I fear lack of them.'-._ :  ,-'
-- Isaac Asimov `^-^-_>


pgpG7ieNxA_Jo.pgp
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [qubes-devel] Re: Critique of the Xen Security Process

[Franz]

On Mon, Nov 9, 2015 at 12:11 PM, Jan Beulich  wrote:

> >>> On 06.11.15 at 18:22,  wrote:
> > 1. First of all, I wish Xen was somehow more defensively coded. To
> provide
> > some
> > examples:
> >
> > a. In XSA-109 [5] there was a problem with the hypervisor dereferencing a
> > NULL
> > pointer. The problem was fixed by the Xen Security Team by applying a
> patch
> > which (hopefully) made sure the execution path that lead to this NULL
> > pointer
> > dereferencing code was never taken. Back then I suggested (on the Xen
> > pre-disclosure list) to make this patch more explicit though:
> >
> >> On Wed, Jan 21, 2015 at 02:31:51PM +0100, Joanna Rutkowska wrote:
> >
> >> (...)
> >>>
> >>> Wouldn't it be prudent to also check if:
> >>>
> >>> (v->arch.paging.mode>{write_guest_entry,cmpxchg_guest_entry} != NULL)
> >>>
> >>> ... in the two affected functions, just before derefing these function
> >>> pointers?
> >>>
> >>> Going even a step further: how about replacing all
> >>> function-pointer-based calls with macros that first validates the
> >>> pointer before derefing it? At least when the system doesn't have SMEP?
> >>>
> > ...to which I got a reply from one of the Xen Security Team engineers
> that
> > the
> > above might perhaps be justified in debug builds only, followed by a
> > standard:
> > "feel free to contribute a patch".
>
> And you know what - I can only repeat this now. Indeed, the points
> you make are all quite reasonable from a technical perspective (and
> especially the code quality aspect is something that I also have been
> complaining _but also trying to do something_ about repeatedly), but
> the attitude behind the way you present them bothers me quite a lot:
> I get the impression that you (a) expect others to do work that you
> neither pay for, nor are at the slightest willing to help with and (b)
> de-value all our efforts during the last so many years to move the
> code base from a research project to a production usable one.
>
> Yes, the work item you mention above has been on our virtual,
> combined todo list, but with all the other work that needs to be done
> it seems like no-one actually found the time to actually carry this out.
> A good example that just pointing out issues is nice and easy, but
> actually finding time to do the work is quite a bit harder.
>
> > b. The XSA-123 [6] was another critical security bug in Xen, this time
> > resulting
> > from one of the hypervisor developer's fetish to use an absolutely
> confusing
> > construct in order to save a few modest bytes in a structure which might
> > have
> > been allocated by the system maybe a few tens of times at best. Even more
> > worrying was the way how Xen Security Team decided to fix the bug: again
> by
> > modifying some condition in the code further up the execution path, with
> the
> > hopes that this time they would ensure this puzzling construct would
> always
> > be
> > used properly. We wrote more about this in our QSB #18 [7].
>
> I suppose you already know what my response here would be?
>
> > c. Finally, the way how Xen fixed the recent XSA-148 looks also very
> reactive,
> > IMHO. With a bug of this calibre, I would expect Xen to carefully review
> and
> > augment all its PV memory virtualization code with additional checks
> (ASSERTs),
> > ensuring certain invariants are always satisfied. Such as e.g. that none
> of the
> > pages containing PDEs or PTEs are becoming writeable by the VM.
>
> Perhaps I'm overlooking something, but I cannot see what kinds of
> ASSERT()s could have helped avoid that problem. The only things I
> can see that would have helped here are
> - better thinking through of all cases by the original developer
> - better review before things going in
> - regular code audits
> None of which, according to what you write further down, you're
> willing to help with.
>
> > I can't help but have a feeling that some of the Xen developers seem to
> be
> > overconfident in their belief they can fully understand all the possible
> > execution paths in their code. Well, the XSAs quoted above are an
> > indisputable
> > prove that this is not quite always the case. Realizing that, each
> developer
> > by
> > themselves, might be a great step towards a more secure hypervisor...
>
> I think we need to find a reasonable balance here. Taking your
> statement to the extreme, we might end up with code having more
> ASSERT()s in it than anything else. Surely that can't be the goal,
> as this would severely hamper maintainability. It simply doesn't
> make sense for every function to mistrust its callers in all aspects.
>
> > 2. Another security-related aspect of the Xen project is how it totally
> > ignores
> > problems related to the build process security. Those who don't believe
> me
> > should grep the sources for wget, which is now disguised as "FETCHER"
> shell
> > variable... (so grep for "FETCHER" string)
> >
> > I feel embarrassed that I need 

[Xen-devel] [PATCH] efi: Fix booting failure with UEFI on ARM

[Shannon Zhao]

From: Shannon Zhao 

Commit 9fd08b4 (efi: split out efi_get_gop()) splits out the
codes getting the pointer to GOP as efi_get_gop(), but it doesn't
initialize the variable handles and gop to NULL like what the original
codes do. This will cause booting failure on ARM while printing below
logs:
Xen 4.7-unstable (c/s Tue Oct 13 14:40:28 2015 +0100 git:7a92036) EFI 
loader
Synchronous Exception at 0xFECB021C

Signed-off-by: Shannon Zhao 
---
 xen/common/efi/boot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 29ce66a..d233cef 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -636,8 +636,8 @@ static void __init efi_console_set_mode(void)
 static EFI_GRAPHICS_OUTPUT_PROTOCOL __init *efi_get_gop(void)
 {
 EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
-EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
-EFI_HANDLE *handles;
+EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
+EFI_HANDLE *handles = NULL;
 EFI_STATUS status;
 UINTN info_size, size = 0;
 static EFI_GUID __initdata gop_guid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
-- 
2.0.4



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

Re: [Xen-devel] [qubes-devel] Re: Critique of the Xen Security Process

[Radoslaw Szkodzinski]

As usual. Security, performance, convenience, price. Pick any mixture.

As is usual for most software, developer convenience trumps most other
considerations. I include ease of generating nice papers and jobs
under developer convenience.
Big players are much more concerned about performance, which saves
money on machines you need to buy. (Note the resources poured into
tmem, which is very iffy from security standpoint.)
Even if there was a sudden security drive for Xen, it's a huge and
probably fruitless task. Xen is not designed top down so you get no
nice overview to check main assumptions. This is also why Xen is
written in C and assembly, not in anything easier to use.

Likewise security-oriented microkernels such as seL4 push drivers to
"userspace" making it convenient for their developers, at the cost of
performance and security, since they are now Somebody Else's Problem.
Surprisingly, seL4 seems to be the only active and working
non-research project that happens to have security as main aim, and
they don't even implement many of features that are "required" for
modern secure design, say, IOMMU...
They want you to write your drivers as automated proofs instead.
Meaning cheap developers will not be able to even lift a finger in
writing those, since you need to learn Isabelle DSL and understand
what is required in order to write a working driver with a good API,
then also understand and model features of underlying hardware. This
requires good mathematical background, as in actual CS, not just
writing code.

What seL4 folks are actually doing (have done, even) is writing a
potent compiler between both C and theorem proving language, plus a
set of theorems describing assumptions made on underlying hardware and
security features. Very simple, just some 250k lines of theorems to
prove correctness of 7k lines of C code.

Good luck trying to port Qubes to their architecture. It's not
impossible, but it is quite a task. So many theorems to wade through
and understand, not to mention a whole new programming language.
You'd get to add well defined isolation primitives to their theorem
prover, then write a parallel proof to capDL kernel (ouch) or extend
capDL with such isolation features and requisite APIs.
Again, developer convenience suffers and have too high barrier of
entry, and you won't get any code written or it will get too expensive
in terms of time, skill and therefore money.

As to other attempts...
Python code? Forget about it, Python is thoroughly undefined behavior
with no truly defined memory model. :) Even C++11 is better there.

Rust? Rust mechanisms are undefined in terms of timing, which will
result in unbounded execution time (hangs) when actual hardware is
involved - there is no way to describe timing behavior of hardware in
it in such a way that these properties are verified at higher layers.
They attempt concurrency but the primitives are not bound to actual
real time and hardware. There is no library for bare metal
programming. Memory allocations are assumed to never fail - and many
other things as well. (Does this sound like some other "never fails"
software we're depending upon?)

Trying to write a secure kernel in an unsafe language is akin to
trying to bail a sinking ship with a spoon. It can theoretically be
done, just not in practice. And actual low-level and safe languages
are surprisingly rare.

Best regards,
R.

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

Re: [Xen-devel] [PATCH v9 00/17] Add VT-d Posted-Interrupts support

[Wu, Feng]

Thanks for your effort on this series and kindly ping..

Thanks,
Feng

> -Original Message-
> From: Wu, Feng
> Sent: Tuesday, November 3, 2015 4:43 PM
> To: xen-devel@lists.xen.org
> Cc: Wu, Feng 
> Subject: [PATCH v9 00/17] Add VT-d Posted-Interrupts support
> 
> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> With VT-d Posted-Interrupts enabled, external interrupts from
> direct-assigned devices can be delivered to guests without VMM
> intervention when guest is running in non-root mode.
> 
> You can find the VT-d Posted-Interrtups Spec. in the following URL:
> http://www.intel.com/content/www/us/en/intelligent-systems/intel-
> technology/vt-directed-io-spec.html
> 
> v9:
> - [PATCH v9 01/17] VT-d Posted-intterrupt (PI) design
> * Make the description more generic.
> 
> - [PATCH v9 02/17] Add cmpxchg16b support for x86-64
> * Make the *ptr operand an input and output.
> 
> - [PATCH v9 15/17] vmx: VT-d posted-interrupt core logic handling
> * Remove arch_vcpu_block_cancel() and arch_vcpu_wake_prepare().
> * Add vmx_pi_state_change() and call it before VM Entry.
> 
> Feng Wu (17):
>  r   VT-d Posted-intterrupt (PI) design
>  Add cmpxchg16b support for x86-64
>  ra  iommu: Add iommu_intpost to control VT-d Posted-Interrupts feature
>  r   vt-d: VT-d Posted-Interrupts feature detection
>  ra  vmx: Extend struct pi_desc to support VT-d Posted-Interrupts
>  r   vmx: Add some helper functions for Posted-Interrupts
>  ra  vmx: Initialize VT-d Posted-Interrupts Descriptor
>  r   vmx: Suppress posting interrupts when 'SN' is set
>  r   VT-d: Remove pointless casts
>   a  vt-d: Extend struct iremap_entry to support VT-d Posted-Interrupts
>  r   vt-d: Add API to update IRTE when VT-d PI is used
>   a  x86: move some APIC related macros to apicdef.h
>   a  Update IRTE according to guest interrupt config changes
>   a  vmx: Properly handle notification event when vCPU is running
>  vmx: VT-d posted-interrupt core logic handling
>  VT-d: Dump the posted format IRTE
>  ra  Add a command line parameter for VT-d posted-interrupts
> 
>  r = has been 'Reviewed-by'
>  a = has been 'Acked-by'
> 
>  docs/misc/vtd-pi.txt   | 329 
> +
>  docs/misc/xen-command-line.markdown|   9 +-
>  xen/arch/x86/hvm/hvm.c |   6 +
>  xen/arch/x86/hvm/vlapic.c  |   5 -
>  xen/arch/x86/hvm/vmx/vmcs.c|  24 +++
>  xen/arch/x86/hvm/vmx/vmx.c | 270 ++-
>  xen/common/schedule.c  |   7 +-
>  xen/drivers/passthrough/io.c   | 123 +++-
>  xen/drivers/passthrough/iommu.c|  16 +-
>  xen/drivers/passthrough/vtd/intremap.c | 212 -
>  xen/drivers/passthrough/vtd/iommu.c|  14 +-
>  xen/drivers/passthrough/vtd/iommu.h|  51 +++--
>  xen/drivers/passthrough/vtd/utils.c|  40 ++--
>  xen/include/asm-arm/domain.h   |   2 +
>  xen/include/asm-x86/apicdef.h  |   3 +
>  xen/include/asm-x86/domain.h   |   2 +
>  xen/include/asm-x86/hvm/hvm.h  |   2 +
>  xen/include/asm-x86/hvm/vmx/vmcs.h |  24 ++-
>  xen/include/asm-x86/hvm/vmx/vmx.h  |  27 +++
>  xen/include/asm-x86/iommu.h|   2 +
>  xen/include/asm-x86/x86_64/system.h|  33 
>  xen/include/xen/iommu.h|   2 +-
>  22 files changed, 1113 insertions(+), 90 deletions(-)
>  create mode 100644 docs/misc/vtd-pi.txt
> 
> --
> 2.1.0


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

[Xen-devel] [xen-unstable test] 63911: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3) broken REGR. vs. 63662
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail REGR. vs. 63662

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 
63758 pass in 63911
 test-amd64-amd64-rumpuserxen-amd64 3 host-install(3) broken in 63758 pass in 
63911
 test-amd64-i386-libvirt-xsm   3 host-install(3)  broken in 63758 pass in 63911
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 63758 pass in 63911
 test-amd64-amd64-xl-xsm   3 host-install(3)  broken in 63758 pass in 63911
 test-amd64-amd64-xl-multivcpu  3 host-install(3)  broken pass in 63758

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 63758 like 63715
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 63662
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 63715

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   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 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   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:
 xen  22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c
baseline version:
 xen  6f04de658574833688c3f9eab310e7834d56a9c0

Last test of basis63715  2015-11-06 13:03:17 Z3 days
Testing same since63758  2015-11-07 16:28:53 Z2 days2 attempts


People who touched revisions under test:
  Dario Faggioli 
  Jan Beulich 
  Paul Durrant 

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   

Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for domain hotplug features

[Jan Beulich]

>>> On 09.11.15 at 10:51,  wrote:
>>  -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 06 November 2015 18:08
>> To: Paul Durrant; xen-de...@lists.xenproject.org 
>> Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan Beulich
>> Subject: Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for
>> domain hotplug features
>> 
>> On 06/11/15 17:21, Paul Durrant wrote:
>> > Without some indication from an HVM domain it is not possible for a
>> > toolstack to know whether instantiation of a new vbd or vif should
>> > result in a new PV device of the appropriate type being instantiated
>> > in a guest. (In other words whether PV drivers are present and
>> > functioning).
>> >
>> > This patch document two paths which vif and vbd frontend drivers can
>> > use to advertise their ability to respond to new vif or vbd
>> > instantiations.
>> >
>> > Signed-off-by: Paul Durrant 
>> > Cc: Ian Campbell 
>> > Cc: Ian Jackson 
>> > Cc: Jan Beulich 
>> > Cc: Keir Fraser 
>> > Cc: Tim Deegan 
>> > ---
>> >  docs/misc/xenstore-paths.markdown | 12 
>> >  1 file changed, 12 insertions(+)
>> >
>> > diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-
>> paths.markdown
>> > index 7701632..9e98d6f 100644
>> > --- a/docs/misc/xenstore-paths.markdown
>> > +++ b/docs/misc/xenstore-paths.markdown
>> > @@ -387,6 +387,18 @@ A domain writable path. Available for arbitrary
>> domain use.
>> >  A domain may write version information for PV driver $NAME using
>> >  this path.
>> >
>> > + ~/feature/hotplug/vif = ("0"|"1") [w,HVM]
>> > +
>> > +An HVM domain can indicate to a toolstack that it is capable
>> > +of responding to instantiation of a new vif by bringing online a
>> > +new PV network device without the need for a reboot.
>> > +
>> > + ~/feature/hotplug/vbd = ("0"|"1") [w,HVM]
>> > +
>> > +An HVM domain can indicate to a toolstack that it is capable
>> > +of responding to instantiation of a new vbd by bringing online a
>> > +new PV block device without the need for a reboot.
>> 
>> These flags are not inherently restricted to HVM guests.  Therefore, I
>> would avoid specifying them as such.  (It is quite possible for a PV
>> guest not to be able to hotplug a vbd for example.)
> 
> I wasn't sure that was true. My belief was that all pure PV guests would 
> have frontends handling hot attach. I'm happy to drop the HVM tag in v2 
> though.

With intermediate steps between HVM and PVH planned to become
possible, I think not overly limiting the scope of such entries would
indeed desirable.

Jan


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

Re: [Xen-devel] 2016 Xen Dev Summit Location (input needed before next Thu)

[Dario Faggioli]

On Fri, 2015-11-06 at 12:48 +, Lars Kurth wrote:

> So we absolutely no easy option but to go for Toronto, unless 
> - We can find two smaller rooms on Tuesday Oct 4th, which I can
> investigate
> - Or to start the summit on the Sunday Oct 2nd and run it through
> Monday Oct 3rd, which I can investigate
> 
So, that would mean holding the event during a Sunday and a local
holiday... I don't think this is that good, for the event itself.

So, even if the above (Oct 2-3, Berlin), would make things a lot easier
for me to attend, I vote for Toronto, as it looks much much more likely
that the event would be successful in that case.

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
http://lists.xen.org/xen-devel

[Xen-devel] [distros-debian-sid test] 38262: regressions - FAIL

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-sid-netboot-pvgrub 10 guest-start  fail REGR. vs. 38239

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-sid-netboot-pygrub 13 guest-saverestore  fail like 38239
 test-amd64-i386-i386-sid-netboot-pvgrub 10 guest-start fail like 38239

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-sid-netboot-pygrub 11 migrate-support-check fail never 
pass
 test-armhf-armhf-armhf-sid-netboot-pygrub 12 saverestore-support-check fail 
never pass

baseline version:
 flight   38239

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubpass
 test-amd64-amd64-i386-sid-netboot-pygrub pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] Hackathon 2016 Location Preferences

[Dario Faggioli]

On Thu, 2015-11-05 at 15:21 +, Lars Kurth wrote:
> Hi all,
> 
> I wanted to do quick straw-poll regarding Hackathon Locations for
> next year. Before I do this though, I wanted to let you know that the
> 2016 Developer Summit will most likely be in Berlin in October (I am
> in the process of finalising space, budget and contract details which
> will need to be approved by the Advisory Board).
> 
> We do have two options for a Hackathon: China (either Shanghai,
> Hangzhou or Beijing - details TBC) and Cambridge, UK. We are still in
> the early planning phase and the budget for the Hackathon has not yet
> been approved. 
> 
So, considering that XS will likely not be in Europe any longer, I vote
Cambridge for the Hackathon.

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/4] docs: Document control features the can be advertised by guests...

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 November 2015 10:44
> To: Paul Durrant
> Cc: Ian Campbell; Ian Jackson; xen-de...@lists.xenproject.org; Keir
> (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH 1/4] docs: Document control features the can be
> advertised by guests...
> 
> >>> On 06.11.15 at 18:21,  wrote:
> > ...via xenstore.
> >
> > XenServer already makes use of ~/control/feature-suspend being written
> > to advertise guest capability of responding to 'suspend' when written to
> > ~/control/shutdown and, since they are derived from XenServer drivers,
> > the Xen Project Windows PV drivers attempt to write this value. The write
> > currently fails for libxl provisioned VMs because ~/control is read-only
> > to the guest (only ~/control/shutdown is writable, for ackowledgement
> > purposes).
> 
> If these can't be set by a guest with the current default toolstack
> anyway, what's the point of documenting them (the more without
> warning about that fact in the text being added)?
>

Because I want to add them to libxl.

  Paul

 
> Jan


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

Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for domain hotplug features

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 November 2015 10:50
> To: Andrew Cooper; Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Ian Campbell; Ian Jackson; Keir (Xen.org); Tim (Xen.org)
> Subject: RE: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for
> domain hotplug features
> 
> >>> On 09.11.15 at 10:51,  wrote:
> >>  -Original Message-
> >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> >> Sent: 06 November 2015 18:08
> >> To: Paul Durrant; xen-de...@lists.xenproject.org
> >> Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan Beulich
> >> Subject: Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for
> >> domain hotplug features
> >>
> >> On 06/11/15 17:21, Paul Durrant wrote:
> >> > Without some indication from an HVM domain it is not possible for a
> >> > toolstack to know whether instantiation of a new vbd or vif should
> >> > result in a new PV device of the appropriate type being instantiated
> >> > in a guest. (In other words whether PV drivers are present and
> >> > functioning).
> >> >
> >> > This patch document two paths which vif and vbd frontend drivers can
> >> > use to advertise their ability to respond to new vif or vbd
> >> > instantiations.
> >> >
> >> > Signed-off-by: Paul Durrant 
> >> > Cc: Ian Campbell 
> >> > Cc: Ian Jackson 
> >> > Cc: Jan Beulich 
> >> > Cc: Keir Fraser 
> >> > Cc: Tim Deegan 
> >> > ---
> >> >  docs/misc/xenstore-paths.markdown | 12 
> >> >  1 file changed, 12 insertions(+)
> >> >
> >> > diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-
> >> paths.markdown
> >> > index 7701632..9e98d6f 100644
> >> > --- a/docs/misc/xenstore-paths.markdown
> >> > +++ b/docs/misc/xenstore-paths.markdown
> >> > @@ -387,6 +387,18 @@ A domain writable path. Available for arbitrary
> >> domain use.
> >> >  A domain may write version information for PV driver $NAME using
> >> >  this path.
> >> >
> >> > + ~/feature/hotplug/vif = ("0"|"1") [w,HVM]
> >> > +
> >> > +An HVM domain can indicate to a toolstack that it is capable
> >> > +of responding to instantiation of a new vif by bringing online a
> >> > +new PV network device without the need for a reboot.
> >> > +
> >> > + ~/feature/hotplug/vbd = ("0"|"1") [w,HVM]
> >> > +
> >> > +An HVM domain can indicate to a toolstack that it is capable
> >> > +of responding to instantiation of a new vbd by bringing online a
> >> > +new PV block device without the need for a reboot.
> >>
> >> These flags are not inherently restricted to HVM guests.  Therefore, I
> >> would avoid specifying them as such.  (It is quite possible for a PV
> >> guest not to be able to hotplug a vbd for example.)
> >
> > I wasn't sure that was true. My belief was that all pure PV guests would
> > have frontends handling hot attach. I'm happy to drop the HVM tag in v2
> > though.
> 
> With intermediate steps between HVM and PVH planned to become
> possible, I think not overly limiting the scope of such entries would
> indeed desirable.
> 

Ok.

  Paul

> Jan


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

Re: [Xen-devel] [VOTE] Release cycle scheme

[Wei Liu]

On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote:
> >>> On 02.11.15 at 14:47,  wrote:
> > So I propose we use the following scheme:
> > 
> > - 6 months release cycle from unstable branch.
> >   - 4 months development.
> >   - 2 months freeze.
> >   - Eat into next cycle if doesn't release on time.
> > - Fixed cut-off date: the Fridays of the week in which the last day of
> >   March and September falls.
> > - No more freeze exception, but heads-up mails about freeze will be
> >   sent a few weeks before hand.
> > - Stable branch maintained for 18 months full support plus 18 months
> >   security support. No mixed maintainership for stable trees.
> 
> -1 overall (the different points would get different ratings
> individually)
> 

For the record, Jan and I had a conversation on IRC. This -1 was cast on
-2...+2 scale and he changed it to -0 (against but non-blocking) to fit
in our governance.

Wei.

> Jan
> 

-- 
Wei.

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

Re: [Xen-devel] [VOTE] Release cycle scheme

[Lars Kurth]

On 09/11/2015 11:04, "Wei Liu"  wrote:

>On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote:
>> >>> On 02.11.15 at 14:47,  wrote:
>> > So I propose we use the following scheme:
>> > 
>> > - 6 months release cycle from unstable branch.
>> >   - 4 months development.
>> >   - 2 months freeze.
>> >   - Eat into next cycle if doesn't release on time.
>> > - Fixed cut-off date: the Fridays of the week in which the last day of
>> >   March and September falls.
>> > - No more freeze exception, but heads-up mails about freeze will be
>> >   sent a few weeks before hand.
>> > - Stable branch maintained for 18 months full support plus 18 months
>> >   security support. No mixed maintainership for stable trees.
>> 
>> -1 overall (the different points would get different ratings
>> individually)
>> 
>
>For the record, Jan and I had a conversation on IRC. This -1 was cast on
>-2...+2 scale and he changed it to -0 (against but non-blocking) to fit
>in our governance.
>
>Wei.

It appears then, that we have a consensus and all stake-holders have
voted. I think in future, it may be good to paste snippets of clarifying
IRC conversation into the mail thread.

I was wondering, whether the dates you marked you proposed in "RFC: change
to 6 months release cycle" (see
http://markmail.org/message/hcp4wifaybk4vtkk#query:+page:1+mid:veqxur64wrwi
ni73+state:results for entire conversation) with release dates at the
beginning of June and December according to the new scheme hold (meaning
that the 4.7 release will follow a 6+2 month cycle or probably more along
the lines of 5.5+2.5), or whether maybe we gradually move to the new
scheme over two releases (4.7 and 4.8 to follow 5+2 and subsequently 4+2).
No strong opinion, just something I'd like to know.

We should probably also write a blog post and update/create information on
the wiki. Am willing to volunteer to put the latter together.

Regards
Lars


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

[Xen-devel] [linux-3.4 test] 63859: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 62277
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 62277
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 62277
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 62277
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 62277
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 62277
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 62277

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-amd64-pvgrub  3 host-install(3) broken in 63294 pass in 63859
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 63294 pass in 
63859
 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken in 63294 pass in 
63859
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 63310 pass in 
63859
 test-amd64-i386-xl-xsm3 host-install(3)  broken in 63310 pass in 63859
 test-amd64-amd64-xl-qcow2 3 host-install(3)  broken in 63310 pass in 63859
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 
63310 pass in 63859
 test-amd64-amd64-xl-credit2   3 host-install(3)  broken in 63324 pass in 63859
 test-amd64-i386-xl-raw3 host-install(3)  broken in 63324 pass in 63859
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken in 63324 
pass in 63859
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 63324 pass in 
63859
 test-amd64-amd64-libvirt-vhd  3 host-install(3)  broken in 63742 pass in 63859
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken in 63742 
pass in 63859
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3)   broken pass in 63703
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)broken pass in 63703
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
pass in 63742
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 63324 pass in 63859
 test-amd64-amd64-xl-rtds  6 xen-bootfail pass in 63228
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
63228
 test-amd64-amd64-i386-pvgrub  6 xen-bootfail pass in 63294
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail pass in 63294
 test-amd64-i386-pair 10 xen-boot/dst_host   fail pass in 63310
 test-amd64-i386-pair  9 xen-boot/src_host   fail pass in 63310
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host  fail pass in 63310
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host  fail pass in 63310
 test-amd64-amd64-amd64-pvgrub  6 xen-boot   fail pass in 63324
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot   fail pass in 63324
 test-amd64-amd64-xl-qcow2 6 xen-bootfail pass in 63338
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host   fail pass in 63374
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host   fail pass in 63374
 test-amd64-amd64-pair10 xen-boot/dst_host   fail pass in 63404
 test-amd64-amd64-pair 9 xen-boot/src_host   fail pass in 63404

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63228 blocked in 62277
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail in 63324 like 62277
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 63324 like 62277
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 63324 like 62277
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62277

Tests which did not succeed, but are not blocking:
 

Re: [Xen-devel] [PATCH RFC] domain: Compile with lock_profile=y enabled.

[Jan Beulich]

>>> On 06.11.15 at 20:39,  wrote:
> On Thu, Nov 05, 2015 at 10:12:26AM -0700, Jan Beulich wrote:
>> >>> On 02.11.15 at 18:12,  wrote:
>> > @@ -247,10 +248,12 @@ struct domain *alloc_domain_struct(void)
>> >   bits = _domain_struct_bits();
>> >  #endif
>> >  
>> > -BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>> 
>> Not unconditionally (i.e. at least non-debug builds should continue
>> to have this).
> 
> The profile=y does not mandate debug=y?
> 
> Meaning if we leave this for non-debug builds with lock_profile=y
> we will have an compile issue.

Good point, but still calling for this not to be done unconditionally
(even if not a true dependency, I don't expect production builds
to enable lock profiling).

>> > -d = alloc_xenheap_pages(0, MEMF_bits(bits));
>> > +d = alloc_xenheap_pages(order, MEMF_bits(bits));
>> >  if ( d != NULL )
>> > -clear_page(d);
>> > +{
>> > +for ( ; order >= 0; order-- )
>> > +clear_page((void *)d + PAGE_SIZE*order);
>> 
>> This loop works for orders 0 and 1, but not anything else (not
>> clearing all of the pages).
> 
> Right. This below should do it:

Yes, except that ...

> @@ -243,10 +244,18 @@ struct domain *alloc_domain_struct(void)
>   bits = _domain_struct_bits();
>  #endif
>  
> +
> +#ifndef LOCK_PROFILE
>  BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> -d = alloc_xenheap_pages(0, MEMF_bits(bits));
> +#endif
> +d = alloc_xenheap_pages(order, MEMF_bits(bits));
>  if ( d != NULL )
> -clear_page(d);
> +{
> +unsigned int sz;
> +
> +for ( sz = 0; sz < (1 << order) * PAGE_SIZE; sz += PAGE_SIZE )

... this wants to be simplified to PAGE_SIZE << order.

Jan


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

Re: [Xen-devel] [PATCH] symbols.c: Avoid warn_unused_result build failure on fgets().

[Riku Voipio]

Hi,

On 9 November 2015 at 10:10, Jan Beulich  wrote:
 On 09.11.15 at 06:03,  wrote:
>> On 11/04/15 07:04, Jan Beulich wrote:
>>> >>> On 04.11.15 at 12:39,  wrote:
>>> > In commit:
>>> >
>>> > d37d63d symbols: prefix static symbols with their source file names
>>> >
>>> > An unchecked fgets was added. This causes a compile error:
>>> >
>>> > symbols.c: In function 'read_symbol':
>>> > symbols.c:181:3: error: ignoring return value of 'fgets', declared with
>>> > attribute warn_unused_result [-Werror=unused-result]
>>> >fgets(str, 500, in); /* discard rest of line */
>>> >^
>>> >
>>> > Paper over the warning like in the other similar fgets-on-error-path
>>> > earlier in the same file.
>>>
>>> But the two cases are dissimilar - the original one skips a line the
>>> format of which is not recognized, while here you may be converting
>>> success into an error. (I did notice the comment on the earlier fgets(),
>>> but since so far I didn't get any compiler warning on any system I
>>> built this on, I assumed we'd be fine without the check, since if we
>>> need the check, then it will end up even more clumsy than the other
>>> one.)
>>>
>>
>> Hi Riku and Jan,
>>
>> Will there be any fix for this error? I got the same error when
>> compiling Xen (commit 6f04de6) by gcc 4.8.4 on Ubuntu 14.04.3. And
>> adding "(void)" ahead of fgets() in the existing code cannot eliminate
>> the error/warning message.

> I expect / welcome an (updated) patch.

Sorry, I missed this mail thread. I'll dive into fixing the patch asap.

Riku

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

[Xen-devel] questions about dirty bitmap

[高强]

Hi,alls

As we know,xen 4+ maintains a dirty bitmap. Snapshot or migration will
use this bitmap. When the guest domain changes the memory page， VMM can
capture it and set dirty bitmap to 1. I want to know the position in source
code of this operation. And how did this process be realized？

Thanks！
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2] symbols.c: Avoid warn_unused_result build failure on fgets().

[Riku Voipio]

In commit:

d37d63d symbols: prefix static symbols with their source file names

An unchecked fgets was added. This causes a compile error at least
on ubuntu utopic:

symbols.c: In function 'read_symbol':
symbols.c:181:3: error: ignoring return value of 'fgets', declared with
attribute warn_unused_result [-Werror=unused-result]
   fgets(str, 500, in); /* discard rest of line */
   ^

Paper over the warning by checking the return value in the if statement.

Cc: Jan Beulich 
Signed-off-by: Riku Voipio 
---
 xen/tools/symbols.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/tools/symbols.c b/xen/tools/symbols.c
index dbf6a1a..3b8fa39 100644
--- a/xen/tools/symbols.c
+++ b/xen/tools/symbols.c
@@ -177,8 +177,8 @@ static int read_symbol(FILE *in, struct sym_entry *s)
rc = 0;
 
  skip_tail:
-   if (input_format == fmt_sysv)
-   fgets(str, 500, in); /* discard rest of line */
+   if ((input_format == fmt_sysv) && fgets(str, 500, in) == NULL)
+   return rc; /* discard rest of line and ignore errors */
 
return rc;
 }
-- 
2.6.2


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

Re: [Xen-devel] [PATCH 1/4] docs: Document control features the can be advertised by guests...

[Jan Beulich]

>>> On 06.11.15 at 18:21,  wrote:
> ...via xenstore.
> 
> XenServer already makes use of ~/control/feature-suspend being written
> to advertise guest capability of responding to 'suspend' when written to
> ~/control/shutdown and, since they are derived from XenServer drivers,
> the Xen Project Windows PV drivers attempt to write this value. The write
> currently fails for libxl provisioned VMs because ~/control is read-only
> to the guest (only ~/control/shutdown is writable, for ackowledgement
> purposes).

If these can't be set by a guest with the current default toolstack
anyway, what's the point of documenting them (the more without
warning about that fact in the text being added)?

Jan


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

[Xen-devel] [linux-3.14 test] 63866: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 5 kernel-build  fail REGR. vs. 62648

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken in 63744 
pass in 63866
 test-amd64-i386-freebsd10-amd64 3 host-install(3) broken in 63744 pass in 63866
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 63744 pass in 
63866
 test-amd64-amd64-rumpuserxen-amd64 3 host-install(3) broken in 63744 pass in 
63866
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)broken pass in 63707
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3)   broken pass in 63707
 test-amd64-amd64-libvirt-xsm  3 host-install(3)   broken pass in 63744
 test-amd64-amd64-amd64-pvgrub  3 host-install(3)  broken pass in 63744
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 63744 pass 
in 63866
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail pass in 63707

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 63707 like 62648
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail in 63707 like 62648
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63707 like 62648
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62648

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail in 63744 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux07bd6f89f7ff56495c31505985af690c976374d6
baseline version:
 linux1230ae0e99e05ced8a945a1a2c5762ce5c6c97c9

Last test of basis62648  2015-10-03 22:43:24 Z   37 days
Failing since 63225  2015-10-22 22:20:24 Z   18 days   14 attempts
Testing same since63336  2015-10-27 17:53:49 Z   13 days   10 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Conole 
  Adam Radford 
  Adrian Hunter 
  Al Viro 
  Alex Deucher 
  Alexander Couzens 
  Alexey Klimov 
  Andreas Schwab 
  Andrew Morton 
  Andrey Vagin 
  Andy Lutomirski 
  Andy Shevchenko 
  Antoine Tenart 
  Antoine Ténart 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Dooks 
  Ben Hutchings 
  Ben Skeggs 
  Brian Norris 
  Charles Keepax 
  Chris Mason 
  Christoph Biedl 
  Christoph Hellwig 

[Xen-devel] Xen Security Advisory 156 (CVE-2015-5307, CVE-2015-8104) - x86: CPU lockup during exception delivery

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

  Xen Security Advisory CVE-2015-5307,CVE-2015-8104 / XSA-156
  version 2

  x86: CPU lockup during exception delivery

UPDATES IN VERSION 2


Minor title and text adjustment.

CVE-2015-8104 has been assigned for the problem with #DB.
(The #AC issue remains CVE-2015-5307.)

Public release.

ISSUE DESCRIPTION
=

When a benign exception occurs while delivering another benign
exception, it is architecturally specified that these would be
delivered sequentially. There are, however, cases where this results in
an infinite loop inside the CPU, which (in the virtualized case) can be
broken only by intercepting delivery of the respective exception.

Architecturally, at least some of these cases should also be
resolvable by an arriving NMI or external interrupt, but empirically
this has been determined to not be the case.

The cases affecting Xen are:

#AC (Alignment Check Exception, CVE-2015-5307): When a 32-bit guest
sets up the IDT entry corresponding to this exception to reference a
ring-3 handler, and when ring 3 code triggers the exception while
running with an unaligned stack pointer, delivering the exception will
re-encounter #AC, ending in an infinite loop.

#DB (Debug Exception, CVE-2015-8104): When a guest sets up a hardware
breakpoint covering a data structure involved in delivering #DB, upon
completion of the delivery of the first exception another #DB will
need to be delivered. The effects slightly differ depending on further
guest characteristics:

- - Guests running in 32-bit mode would be expected to sooner or later
  encounter another fault due to the stack pointer decreasing during
  each iteration of the loop. The most likely case would be #PF (Page
  Fault) due to running into unmapped virtual space. However, an
  infinite loop cannot be excluded (e.g. when the guest is running with
  paging disabled).

- - Guests running in long mode, but not using the IST (Interrupt Stack
  Table) feature for the IDT entry corresponding to #DB would behave
  similarly to guests running in 32-bit mode, just that the larger
  virtual address space allows for a much longer loop. The loop can't,
  however, be infinite, as eventually the stack pointer would move into
  non-canonical address space, causing #SS (Stack Fault) instead.

- - Guests running in long mode and using IST for the IDT entry
  corresponding to #DB would enter an infinite loop, as the stack
  pointer wouldn't change between #DB instances.

IMPACT
==

A malicious HVM guest administrator can cause a denial of service.
Specifically, prevent use of a physical CPU for a significant, perhaps
indefinite period.

If a host watchdog (Xen or dom0) is in use, this can lead to a
watchdog timeout and consequently a reboot of the host.  If another,
innocent, guest, is configured with a watchdog, this issue can lead to
a reboot of such a guest.

It is possible that a guest kernel might expose the #AC vulnerability
to malicious unprivileged guest users (by permitting #AC to be handled
in guest user mode).  However, we believe that almost all ordinary
operating system kernels do not permit this; we are not aware of any
exceptions.  (A guest kernel which exposed the #AC vulnerability to
guest userspace would be vulnerable when running on baremetal, without
Xen involved.)


VULNERABLE SYSTEMS
==

The vulnerability is exposed to any x86 HVM guest.

ARM is not vulnerable.  x86 PV VMs are not vulnerable.

All versions of Xen are affected.

x86 CPUs from all manufacturers are affected.

MITIGATION
==

Running only PV guests will avoid this issue.

Running only kernels which avoid exposing the #AC problem to userspace
(as discussed in Impact) will prevent untrusted guest users from
exploiting this issue.

With such good kernels, the vulnerability can be avoided altogether if
the guest kernel is controlled by the host rather than guest
administrator, provided that further steps are taken to prevent the
guest administrator from loading code into the kernel (e.g. by
disabling loadable modules etc) or from using other mechanisms which
allow them to run code at kernel privilege.  In Xen HVM, controlling
the guest's kernel would involve locking down the bootloader.


CREDITS
===

These issues were discovered by Ben Serebrin from Google and
Jan Beulich from SUSE.

RESOLUTION
==

To correctly support the intended uses of the relevant CPU features
would require architectural changes to the CPU specification, design
and implementation.  This is not practical as a security response.

Applying the appropriate attached patch works around the issue in
software.

xsa156.patchxen-unstable, Xen 4.6.x
xsa156-4.5.patchXen 4.5.x
xsa156-4.4.patchXen 4.4.x
xsa156-4.3.patchXen 4.3.x

$ sha256sum xsa156*.patch
ffc8153cdf4e69ff2feced6ea4988b594b5cb724e9909300209f9ae35fe0e618  
xsa156-4.3.patch

[Xen-devel] [linux-3.10 test] 63860: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   3 host-install(3) broken REGR. vs. 62642
 build-armhf-pvops 5 kernel-build  fail REGR. vs. 62642

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt  3 host-install(3)  broken in 63743 pass in 63860
 test-amd64-amd64-i386-pvgrub  3 host-install(3)  broken in 63743 pass in 63860
 test-amd64-i386-libvirt   3 host-install(3)  broken in 63743 pass in 63860
 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken in 63743 pass in 
63860
 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken in 63743 pass in 
63860
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)broken pass in 63706
 test-amd64-i386-xl-qemut-winxpsp3  3 host-install(3)  broken pass in 63743
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 63706 pass in 63860
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 63743 pass in 63860

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail blocked in 62642
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 63706 like 62642
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63706 like 62642
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62642

Tests which did not succeed, but are not blocking:
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linuxd17332ebfb5f2010ae5d3332a52df361f28ae4a8
baseline version:
 linuxf5552cd830e58c46dffae3617b3ce0c839771981

Last test of basis62642  2015-10-03 17:59:45 Z   37 days
Failing since 63224  2015-10-22 22:20:05 Z   18 days   14 attempts
Testing same since63332  2015-10-27 12:23:40 Z   13 days   10 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Conole 
  Adam Radford 
  Al Viro 
  Alexander Couzens 
  Alexey Klimov 
  Andi Kleen 
  Andreas Schwab 
  Andrew Morton 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Hutchings 
  Charles Keepax 
  Christoph Biedl 
  Christoph Hellwig 
  cov...@ccs.covici.com 
  Daniel Vetter 
  Daniel Vetter 
  Dave Kleikamp 
  David S. Miller 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  Ding Tianhong 
  dingtianhong 
  Dirk Mueller 
  Dirk Müller 
  Doug Ledford 
  Eric Dumazet 
  Eric W. Biederman 
  Geert Uytterhoeven 
  Greg Kroah-Hartman 
  Guenter Roeck 
  Guillaume Nault 
  H. Peter Anvin 
  Herbert Xu 
  Ian Abbott 
  Ilya Dryomov 
  Ingo Molnar 
  James Bottomley 
  James Chapman 
  James Hogan 
  Jan Kara 
  Jann Horn 
  Jarkko Nikula 
  Jeff Mahoney 

[Xen-devel] [xen-4.3-testing test] 63803: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs. 
63212

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv3 host-install(3)  broken in 63738 pass in 63803
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 63738 pass in 
63803
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 63700
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate.2 fail in 63700 
pass in 63803
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
63738
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-localmigrate/x10 fail pass 
in 63738

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail in 63738 like 63212

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-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-amd64-i386-migrupgrade 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass

version targeted for testing:
 xen  e875e0e5fcc5912f71422b53674a97e5c0ae77be
baseline version:
 xen  85ca813ec23c5a60680e4a13777dad530065902b

Last test of basis63212  2015-10-22 10:03:01 Z   18 days
Failing since 63360  2015-10-29 13:39:04 Z   10 days8 attempts
Testing same since63381  2015-10-30 18:44:54 Z9 days7 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64   

[Xen-devel] Mini-OS on ARM64

[Chen Baozi]

Hi all,

With plenty of ugly hacks, mini-os is now able to boot on my arm64 board:

(d37) - Mini-OS booting -
(d37) - Setup CPU -
(d37) - Setup booting pagetable -
(d37) - MMU on -
(d37) - Setup stack -
(d37) - Jumping to C entry -
(d37) Checking DTB at ffbff000...
(d37) map_console, phys = 0x3900
(d37) Console is on port 2
(d37) Console ring is at mfn ffbfffc0
(d37) MM: Init
(d37) _text: ffc0(VA)
(d37) _etext: ffc0f120(VA)
(d37) _erodata: ffc11000(VA)
(d37) _edata: ffc1c31c(VA)
(d37) stack start: ffc18000(VA)
(d37) _end: ffc25788(VA)
(d37) Found memory at 0x4000 (len 0x800)
(d37) Using pages 262182 to 294912 as free space for heap.
(d37) MM: Initialise page allocator for 
ffc26000(40026000)-ffc00800(4800)
(d37) MM: done
(d37) Found GIC: gicd_base = ffbfffa01000, gicc_base = ffbfffa02000
(d37) Initialising timer interface
(d37) Virtual Count register is 22aba5, freq = 5000 Hz
(d37) Initialising console ... done.
(d37) FDT suggests grant table base 3800
(d37) gnttab_table mapped at ffbff800.
(d37) Initialising scheduler
(d37) Thread "Idle": pointer: 0xffc2f070, stack: 0xffc3
(d37) Thread "xenstore": pointer: 0xffc2f0d0, stack: 0xffc4
(d37) xenbus initialised on irq 1 mfn 0x39001
(d37) Thread "shutdown": pointer: 0xffc2f130, stack: 0xffc5
(d37) Test main: start_info=ffc25298
(d37) Thread "xenbus_tester": pointer: 0xffc2f190, stack: 
0xffc6
(d37) Thread "periodic_thread": pointer: 0xffc2f1f0, stack: 
0xffc7
(d37) Thread "shutdown": pointer: 0xffc2f250, stack: 0xffc8

However, it is still at very early stage (means unfinished features, lots of
bugs and termporary hacks). There is still a lot of work needed before it can
be merged. So I just put the codes on the github in case anyone would like
to have a try. I'll continue to work on it until it can be sent as patches.

Any comment is welcome.

Some info you might need:

* Github url:
  https://github.com/baozich/mini-os
* Command that I use to build:
  CONFIG_TEST=y CONFIG_START_NETWORK=n CONFIG_BLKFRONT=n CONFIG_NETFRONT=n \
  CONFIG_FBFRONT=n CONFIG_KBDFRONT=n CONFIG_CONSFRONT=n CONFIG_XC=n \
  MINIOS_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make
* XL config:
  name = "mini-os"
  vcpus = 1
  memory = 128
  gic_version = "v2"
  kernel = "/path/to/mini-os.img"

Cheers,

Baozi.

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

Re: [Xen-devel] [PATCH 4/4] docs: Document xenstore paths for domain network address information

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 06 November 2015 18:17
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH 4/4] docs: Document xenstore paths for
> domain network address information
> 
> On 06/11/15 17:21, Paul Durrant wrote:
> > It is useful to be able to see the network addresses in use by a domain
> > for a particular vif in xenstore, for example so that ssh can be invoked
> > by a toolstack to log into the guest domain.
> >
> > This patch documents paths to allow a domain to advertise MAC (unicast
> > and multicast) and IP (versions 4 and 6) address information.
> >
> > Signed-off-by: Paul Durrant 
> > Cc: Ian Campbell 
> > Cc: Ian Jackson 
> > Cc: Jan Beulich 
> > Cc: Keir Fraser 
> > Cc: Tim Deegan 
> > ---
> >  docs/misc/xenstore-paths.markdown | 29
> +
> >  1 file changed, 29 insertions(+)
> >
> > diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-
> paths.markdown
> > index 9e98d6f..68d3dbf 100644
> > --- a/docs/misc/xenstore-paths.markdown
> > +++ b/docs/misc/xenstore-paths.markdown
> > @@ -39,6 +39,8 @@ before regexp expansion:
> >  * $UUID -- a UUID in the form ----
> >  * $NAME -- a string identifying an object within a domain. Typically
> >comprising only alphanumeric characters.
> > +* $INDEX -- an integer used as part of a path when listing a set of
> > +values. Typically these integers are contiguous.
> >
> >  VALUES are strings and can take the following forms:
> >
> > @@ -56,6 +58,13 @@ VALUES are strings and can take the following forms:
> >  * VERSION -- 2 or 3 integers, in decimal form separated by ".",
> >   specifying major version, minor version, and then
> >  (optionally) micro version.
> > +* MAC_ADDRESS -- 6 integers, in hexadecimal form, separated by ':',
> > + specifying an ethernet MAC address.
> > +* IPV4_ADDRESS -- 4 integers, in decimal form, separated by '.',
> > +  specifying an IP version 4 address.
> > +* IPV6_ADDRESS -- 8 integers, in hexadecimal form, separated by ':',
> > +  specifying an IP version 6 address. (There should
> > +  be strictly 8 integers i.e. '::' compression).
> 
> Given the "strictly", I presume you mean no "::" compression?

Yes, I missed the 'no'

> 
> But why enforce that restriction? "::" compression is unambiguous and
> typically makes the addresses rather more human readable.
> 

That's true but I didn't want to put the coding burden on the frontend. 
Defining it this way makes it a trivial printf into xenstore. Whatever picks 
the address up can do the compression afterwards before display. I suppose it 
would be better to allow compression but state that it's not required.

  Paul

> ~Andrew

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

Re: [Xen-devel] [PATCH] x86/PoD: tighten conditions for checking super page

[George Dunlap]

On Thu, Nov 5, 2015 at 4:43 PM, Jan Beulich  wrote:
 On 02.11.15 at 17:29,  wrote:
>> * steal_for_cache may now be wrong.  I realize that since now ram == 0
>> that all the subsequent "steal_for_cache" expressions will end up as
>> "false" anyway, but leaving invariants in an invalid state is sort of
>> asking for trouble.
>>
>> I'd prefer you just update steal_for_cache; but if not, at least leave a
>> comment there saying that it may be wrong and why it doesn't matter.
>
> I've just done the other things, but I don't think steal_for_cache
> can have changed at this point: p2m_pod_cache_add() increments
> p2m->pod.count by the same value by which
> p2m_pod_zero_check_superpage() bumps p2m->pod.entry_count
> right after having called p2m_pod_cache_add(). I could leave a
> comment of ASSERT() to that effect, unless I'm overlooking
> something.

Ah, yes of course.

 -George

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

Re: [Xen-devel] [PATCH] symbols.c: Avoid warn_unused_result build failure on fgets().

[Jan Beulich]

>>> On 09.11.15 at 06:03,  wrote:
> On 11/04/15 07:04, Jan Beulich wrote:
>> >>> On 04.11.15 at 12:39,  wrote:
>> > In commit:
>> > 
>> > d37d63d symbols: prefix static symbols with their source file names
>> > 
>> > An unchecked fgets was added. This causes a compile error:
>> > 
>> > symbols.c: In function 'read_symbol':
>> > symbols.c:181:3: error: ignoring return value of 'fgets', declared with
>> > attribute warn_unused_result [-Werror=unused-result]
>> >fgets(str, 500, in); /* discard rest of line */
>> >^
>> > 
>> > Paper over the warning like in the other similar fgets-on-error-path
>> > earlier in the same file.
>> 
>> But the two cases are dissimilar - the original one skips a line the
>> format of which is not recognized, while here you may be converting
>> success into an error. (I did notice the comment on the earlier fgets(),
>> but since so far I didn't get any compiler warning on any system I
>> built this on, I assumed we'd be fine without the check, since if we
>> need the check, then it will end up even more clumsy than the other
>> one.)
>>
> 
> Hi Riku and Jan,
> 
> Will there be any fix for this error? I got the same error when
> compiling Xen (commit 6f04de6) by gcc 4.8.4 on Ubuntu 14.04.3. And
> adding "(void)" ahead of fgets() in the existing code cannot eliminate
> the error/warning message.

I expect / welcome an (updated) patch.

Jan


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 3ec97ca490009ed5604ccd7f2653e5a9ecbf3474
baseline version:
 ovmf 3535213aaec279d84bae7da40a4b982ab9fdf89b

Last test of basis38260  2015-11-08 01:52:43 Z1 days
Testing same since38261  2015-11-09 06:21:06 Z0 days1 attempts


People who touched revisions under test:
  Daryl McDaniel 

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



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

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

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


Push not applicable.


commit 3ec97ca490009ed5604ccd7f2653e5a9ecbf3474
Author: Daryl McDaniel 
Date:   Sat Nov 7 19:43:57 2015 +

AppPkg/Applications/Python/Python-2.7.10: Initial Checkin part 5/5.

These files are candidates for modification during the port to EDK II.
The following files were copied, unchanged, from the Python 2.7.2 port.
  Ia32/pyconfig.h
  X64/pyconfig.h
  PyMod-2.7.10/Modules/config.c
  PyMod-2.7.10/Modules/edk2module.c
  Py2710ReadMe.txt// Copied from PythonReadMe.txt
  Python2710.inf  // Copied from PythonCore.inf

The remaining files were copied, unchanged, from the cPython 2.7.10 
distribution.
These files are unchanged and set the baseline for subsequent commits.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel 


git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18741 
6f19259b-4bc3-4df7-8a09-765794883524

commit 3257aa99321d745773a6bd1bd4ce7f6fafe74411
Author: Daryl McDaniel 
Date:   Sat Nov 7 19:33:58 2015 +

AppPkg/Applications/Python/Python-2.7.10: Initial Checkin part 4/5.

The Lib directory from the cPython 2.7.10 distribution.
These files are unchanged and set the baseline for subsequent commits.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel 


git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18740 
6f19259b-4bc3-4df7-8a09-765794883524

commit 53b2ba5790b57b3dcdfbb9fa5835a979d94908fa
Author: Daryl McDaniel 
Date:   Sat Nov 7 19:29:24 2015 +

AppPkg/Applications/Python/Python-2.7.10: Initial Checkin part 3/5.

The Objects directory from the cPython 2.7.10 distribution, along with the 
LICENSE and README files.  These files are unchanged and set the baseline for 
subsequent commits.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel 


git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18739 
6f19259b-4bc3-4df7-8a09-765794883524

commit 7eb75bccb5dacb658c63db1a9a980950c3d54d42
Author: Daryl McDaniel 
Date:   Sat Nov 7 19:25:02 2015 +

AppPkg/Applications/Python/Python-2.7.10: Initial Checkin part 2/5.

The Modules directory from the cPython 2.7.10 distribution.
These files are unchanged and set the baseline for subsequent commits.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel 


git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18738 
6f19259b-4bc3-4df7-8a09-765794883524

commit c8042e10763bca064df257547d04ae3dfcdfaf91
Author: Daryl McDaniel 
Date:   Sat Nov 7 19:19:19 2015 +

AppPkg/Applications/Python/Python-2.7.10: Initial Checkin part 1/5.

The Include, Parser, and Python directories from the cPython 2.7.10 
distribution.
These files are unchanged and set 

Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for domain hotplug features

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 06 November 2015 18:08
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for
> domain hotplug features
> 
> On 06/11/15 17:21, Paul Durrant wrote:
> > Without some indication from an HVM domain it is not possible for a
> > toolstack to know whether instantiation of a new vbd or vif should
> > result in a new PV device of the appropriate type being instantiated
> > in a guest. (In other words whether PV drivers are present and
> > functioning).
> >
> > This patch document two paths which vif and vbd frontend drivers can
> > use to advertise their ability to respond to new vif or vbd
> > instantiations.
> >
> > Signed-off-by: Paul Durrant 
> > Cc: Ian Campbell 
> > Cc: Ian Jackson 
> > Cc: Jan Beulich 
> > Cc: Keir Fraser 
> > Cc: Tim Deegan 
> > ---
> >  docs/misc/xenstore-paths.markdown | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-
> paths.markdown
> > index 7701632..9e98d6f 100644
> > --- a/docs/misc/xenstore-paths.markdown
> > +++ b/docs/misc/xenstore-paths.markdown
> > @@ -387,6 +387,18 @@ A domain writable path. Available for arbitrary
> domain use.
> >  A domain may write version information for PV driver $NAME using
> >  this path.
> >
> > + ~/feature/hotplug/vif = ("0"|"1") [w,HVM]
> > +
> > +An HVM domain can indicate to a toolstack that it is capable
> > +of responding to instantiation of a new vif by bringing online a
> > +new PV network device without the need for a reboot.
> > +
> > + ~/feature/hotplug/vbd = ("0"|"1") [w,HVM]
> > +
> > +An HVM domain can indicate to a toolstack that it is capable
> > +of responding to instantiation of a new vbd by bringing online a
> > +new PV block device without the need for a reboot.
> 
> These flags are not inherently restricted to HVM guests.  Therefore, I
> would avoid specifying them as such.  (It is quite possible for a PV
> guest not to be able to hotplug a vbd for example.)

I wasn't sure that was true. My belief was that all pure PV guests would have 
frontends handling hot attach. I'm happy to drop the HVM tag in v2 though.

  Paul

> 
> ~Andrew

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

Re: [Xen-devel] [VOTE] Release cycle scheme

[Wei Liu]

On Mon, Nov 09, 2015 at 11:24:59AM +, Lars Kurth wrote:
> 
> 
> On 09/11/2015 11:04, "Wei Liu"  wrote:
> 
> >On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote:
> >> >>> On 02.11.15 at 14:47,  wrote:
> >> > So I propose we use the following scheme:
> >> > 
> >> > - 6 months release cycle from unstable branch.
> >> >   - 4 months development.
> >> >   - 2 months freeze.
> >> >   - Eat into next cycle if doesn't release on time.
> >> > - Fixed cut-off date: the Fridays of the week in which the last day of
> >> >   March and September falls.
> >> > - No more freeze exception, but heads-up mails about freeze will be
> >> >   sent a few weeks before hand.
> >> > - Stable branch maintained for 18 months full support plus 18 months
> >> >   security support. No mixed maintainership for stable trees.
> >> 
> >> -1 overall (the different points would get different ratings
> >> individually)
> >> 
> >
> >For the record, Jan and I had a conversation on IRC. This -1 was cast on
> >-2...+2 scale and he changed it to -0 (against but non-blocking) to fit
> >in our governance.
> >
> >Wei.
> 
> It appears then, that we have a consensus and all stake-holders have
> voted. I think in future, it may be good to paste snippets of clarifying
> IRC conversation into the mail thread.
> 

That conversation was a bit long to paste in so I just stated the
conclusion.

> I was wondering, whether the dates you marked you proposed in "RFC: change
> to 6 months release cycle" (see
> http://markmail.org/message/hcp4wifaybk4vtkk#query:+page:1+mid:veqxur64wrwi
> ni73+state:results for entire conversation) with release dates at the
> beginning of June and December according to the new scheme hold (meaning
> that the 4.7 release will follow a 6+2 month cycle or probably more along
> the lines of 5.5+2.5), or whether maybe we gradually move to the new
> scheme over two releases (4.7 and 4.8 to follow 5+2 and subsequently 4+2).
> No strong opinion, just something I'd like to know.
> 

Most people agreed the fixed date arrangement is a good idea, so I would
go for end of March cut-off date.

> We should probably also write a blog post and update/create information on
> the wiki. Am willing to volunteer to put the latter together.
> 

As for blog post, I will try to come up with something after I finish my
email to xen-devel.

-- 
Wei.

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