Re: [Xen-devel] [PATCH v2 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization.

[Xu, Quan]

On March 09, 2016 1:19pm,  wrote:
> > From: Quan Xu
> > Sent: Wednesday, March 09, 2016 11:08 AM
> > When iommu_setup() is called in __start_xen(), interrupts have already
> > been enabled, and nothing disables (without reenabling) them again in
> > the path that leads to calling set_iommu_interrupt_handler(). There's
> > therefore no risk of them being disabled and needing remaining so, and
> > hence no need for
> 
> no risk of them being 'enabled' since no one disables them again?
> 

Yes,

> > saving and restoring the flags. This means that, even if interrupt
> > would need to be disabled when taking pcidevs_lock, spin_lock_irq()
> > and spin_unlock_irq() could be used.
> 
> I didn't see how this explanation relates to below change. You are changing
> from spin_lock_irqsave to spin_lock. But here you explains the reason to
> spin_lock_irq...
> 
Yes, you are right. I think I'd better remove or add a '()' for:

   "This means that, even if interrupt
would need to be disabled when taking pcidevs_lock, spin_lock_irq()
and spin_unlock_irq() could be used."

> >
> > Inside set_iommu_interrupt_handler(), pcidevs_lock serializes calls to
> > pci_get_pdev(), which does not require interrupts to be disabled
> > during its execution. In fact, pcidevs_lock is always (except for this
> > case) taken without disabling interrupts, and disabling them in this
> > case would make the BUG_ON() in check_lock() trigger, if it wasn't for
> > the fact that spinlock debugging checks are still disabled, during
> > initialization, when iommu_setup() (which then end up calling
> > set_iommu_interrupt_handler()) is called.
> 
> The key problem is that we need consistent lock usage in all places (either 
> all in
> IRQ-safe or all in IRQ-unsafe), regardless of whether check_lock is activated 
> or
> not (which is just a debug method to help identify such inconsistency 
> problem).


IMO, this is not the key problem,  __Wait for Dario's / Jan's opinions__.


> I think it should be clear enough to state that pci_get_pdev doesn't require
> holding lock with interrupt disabled (so we should use spin_lock in this AMD
> case), and add the fact that when this function is invoked the interrupt is 
> indeed
> enabled.
> 
> 
> >
> > In order to fix this, we can use just plain spin_lock() and
> > spin_unlock(), instead of spin_lock_irqsave() and spin_unlock_irqrestore().
> 
> What about revise like below?
> --
> 
> pcidevs_lock should be held with interrupt enabled.

I am not sure for this point.


> However there remains an
> exception in AMD IOMMU code, where the lock is acquired with interrupt
> disabled. This inconsistency can lead to deadlock.
> 
> The fix is straightforward to use spin_lock instead. Also interrupt has been
> enabled when this function is invoked, so we're sure consistency around
> pcidevs_lock can be guaranteed after this fix.

I really appreciate you send out a revised one, but I think it is not only for 
consistency.
 __Wait for Dario's / Jan's opinions__.

To be honest, to me, __my_changlog_ is complicated.


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

Re: [Xen-devel] [PATCH v2 2/2] IOMMU/spinlock: Make the pcidevs_lock a recursive one

[Xu, Quan]

On March 09, 2016 1:21pm,  wrote:
> > From: Xu, Quan
> > Sent: Wednesday, March 09, 2016 11:08 AM
> >
> > Signed-off-by: Quan Xu 
> > CC: Keir Fraser 
> > CC: Jan Beulich 
> > CC: Andrew Cooper 
> > CC: Suravee Suthikulpanit 
> > CC: Feng Wu 
> > CC: Kevin Tian 
> > CC: Dario Faggioli 
> 
> Acked-by: Kevin Tian  for VT-d part.

Kevin, thanks!!
Quan

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

Re: [Xen-devel] Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Wednesday, March 9, 2016 1:06 AM
> To: Jan Beulich ; George Dunlap
> ; Wu, Feng 
> Cc: Andrew Cooper ; Dario Faggioli
> ; Tian, Kevin ; xen-
> de...@lists.xen.org; Konrad Rzeszutek Wilk ; Keir
> Fraser 
> Subject: Re: [Xen-devel] Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt
> core logic handling
> 
> On 08/03/16 15:42, Jan Beulich wrote:
>  On 08.03.16 at 15:42,  wrote:
> >> On Tue, Mar 8, 2016 at 1:10 PM, Wu, Feng  wrote:
>  -Original Message-
>  From: George Dunlap [mailto:george.dun...@citrix.com]
> >> [snip]
>  It seems like there are a couple of ways we could approach this:
> 
>  1. Try to optimize the reverse look-up code so that it's not a linear
>  linked list (getting rid of the theoretical fear)
> >>>
> >>> Good point.
> >>>
> 
>  2. Try to test engineered situations where we expect this to be a
>  problem, to see how big of a problem it is (proving the theory to be
>  accurate or inaccurate in this case)
> >>>
> >>> Maybe we can run a SMP guest with all the vcpus pinned to a dedicated
> >>> pCPU, we can run some benchmark in the guest with VT-d PI and without
> >>> VT-d PI, then see the performance difference between these two sceanrios.
> >>
> >> This would give us an idea what the worst-case scenario would be.
> >
> > How would a single VM ever give us an idea about the worst
> > case? Something getting close to worst case is a ton of single
> > vCPU guests all temporarily pinned to one and the same pCPU
> > (could be multi-vCPU ones, but the more vCPU-s the more
> > artificial this pinning would become) right before they go into
> > blocked state (i.e. through one of the two callers of
> > arch_vcpu_block()), the pinning removed while blocked, and
> > then all getting woken at once.
> 
> Why would removing the pinning be important?
> 
> And I guess it's actually the case that it doesn't need all VMs to
> actually be *receiving* interrupts; it just requires them to be
> *capable* of receiving interrupts, for there to be a long chain all
> blocked on the same physical cpu.
> 
> >
> >>  But
> >> pinning all vcpus to a single pcpu isn't really a sensible use case we
> >> want to support -- if you have to do something stupid to get a
> >> performance regression, then I as far as I'm concerned it's not a
> >> problem.
> >>
> >> Or to put it a different way: If we pin 10 vcpus to a single pcpu and
> >> then pound them all with posted interrupts, and there is *no*
> >> significant performance regression, then that will conclusively prove
> >> that the theoretical performance regression is of no concern, and we
> >> can enable PI by default.
> >
> > The point isn't the pinning. The point is what pCPU they're on when
> > going to sleep. And that could involve quite a few more than just
> > 10 vCPU-s, provided they all sleep long enough.
> >
> > And the "theoretical performance regression is of no concern" is
> > also not a proper way of looking at it, I would say: Even if such
> > a situation would happen extremely rarely, if it can happen at all,
> > it would still be a security issue.
> 
> What I'm trying to get at is -- exactly what situation?  What actually
> constitutes a problematic interrupt latency / interrupt processing
> workload, how many vcpus must be sleeping on the same pcpu to actually
> risk triggering that latency / workload, and how feasible is it that
> such a situation would arise in a reasonable scenario?
> 
> If 200us is too long, and it only takes 3 sleeping vcpus to get there,
> then yes, there is a genuine problem we need to try to address before we
> turn it on by default.  If we say that up to 500us is tolerable, and it
> takes 100 sleeping vcpus to reach that latency, then this is something I
> don't really think we need to worry about.
> 
> "I think something bad may happen" is a really difficult to work with.
> "I want to make sure that even a high number of blocked cpus won't cause
> the interrupt latency to exceed 500us; and I want it to be basically
> impossible for the interrupt latency to exceed 5ms under any
> circumstances" is a concrete target someone can either demonstrate that
> they meet, or aim for when trying to improve the situation.
> 
> Feng: It should be pretty easy for you to:

George, thanks a lot for you to pointing the possible way to move forward.

> * Implement a modified version of Xen where
>  - *All* vcpus get put on the waitqueue

So this means, all the vcpus are blocked, and hence waiting in the
blocking list, right?

>  - Measure how long it took to run the loop in pi_wakeup_interrupt
> * Have one VM receiving posted interrupts on a regular basis.
> * Slowly increase 

Re: [Xen-devel] [PATCH v2 2/2] IOMMU/spinlock: Make the pcidevs_lock a recursive one

[Tian, Kevin]

> From: Xu, Quan
> Sent: Wednesday, March 09, 2016 11:08 AM
> 
> Signed-off-by: Quan Xu 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Suravee Suthikulpanit 
> CC: Feng Wu 
> CC: Kevin Tian 
> CC: Dario Faggioli 

Acked-by: Kevin Tian  for VT-d part.

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

Re: [Xen-devel] [PATCH v2 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization.

[Tian, Kevin]

> From: Quan Xu
> Sent: Wednesday, March 09, 2016 11:08 AM

Hi, Quan, sorry that I still didn't quite get below description.

> 
> When iommu_setup() is called in __start_xen(), interrupts have
> already been enabled, and nothing disables (without reenabling)
> them again in the path that leads to calling
> set_iommu_interrupt_handler(). There's therefore no risk of them
> being disabled and needing remaining so, and hence no need for

no risk of them being 'enabled' since no one disables them again?

> saving and restoring the flags. This means that, even if interrupt
> would need to be disabled when taking pcidevs_lock, spin_lock_irq()
> and spin_unlock_irq() could be used.

I didn't see how this explanation relates to below change. You are
changing from spin_lock_irqsave to spin_lock. But here you explains
the reason to spin_lock_irq...

> 
> Inside set_iommu_interrupt_handler(), pcidevs_lock serializes calls
> to pci_get_pdev(), which does not require interrupts to be disabled
> during its execution. In fact, pcidevs_lock is always (except for
> this case) taken without disabling interrupts, and disabling them in
> this case would make the BUG_ON() in check_lock() trigger, if it
> wasn't for the fact that spinlock debugging checks are still
> disabled, during initialization, when iommu_setup() (which then end
> up calling set_iommu_interrupt_handler()) is called.

The key problem is that we need consistent lock usage in all places 
(either all in IRQ-safe or all in IRQ-unsafe), regardless of whether 
check_lock is activated or not (which is just a debug method to help
identify such inconsistency problem). I think it should be clear 
enough to state that pci_get_pdev doesn't require holding lock with
interrupt disabled (so we should use spin_lock in this AMD case),
and add the fact that when this function is invoked the interrupt
is indeed enabled.


> 
> In order to fix this, we can use just plain spin_lock() and spin_unlock(),
> instead of spin_lock_irqsave() and spin_unlock_irqrestore().

What about revise like below?
--

pcidevs_lock should be held with interrupt enabled. However there
remains an exception in AMD IOMMU code, where the lock is
acquired with interrupt disabled. This inconsistency can lead to 
deadlock. 

The fix is straightforward to use spin_lock instead. Also interrupt
has been enabled when this function is invoked, so we're sure
consistency around pcidevs_lock can be guaranteed after this fix.
--

> 
> Signed-off-by: Quan Xu 
> Reviewed-by: Dario Faggioli 
> CC: Suravee Suthikulpanit 
> CC: Dario Faggioli 
> CC: Jan Beulich 
> ---
>  xen/drivers/passthrough/amd/iommu_init.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/amd/iommu_init.c
> b/xen/drivers/passthrough/amd/iommu_init.c
> index d90a2d2..a400497 100644
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -778,7 +778,6 @@ static bool_t __init set_iommu_interrupt_handler(struct
> amd_iommu *iommu)
>  {
>  int irq, ret;
>  hw_irq_controller *handler;
> -unsigned long flags;
>  u16 control;
> 
>  irq = create_irq(NUMA_NO_NODE);
> @@ -788,10 +787,10 @@ static bool_t __init set_iommu_interrupt_handler(struct
> amd_iommu *iommu)
>  return 0;
>  }
> 
> -spin_lock_irqsave(_lock, flags);
> +spin_lock(_lock);
>  iommu->msi.dev = pci_get_pdev(iommu->seg, PCI_BUS(iommu->bdf),
>PCI_DEVFN2(iommu->bdf));
> -spin_unlock_irqrestore(_lock, flags);
> +spin_unlock(_lock);
>  if ( !iommu->msi.dev )
>  {
>  AMD_IOMMU_DEBUG("IOMMU: no pdev for %04x:%02x:%02x.%u\n",
> --
> 1.9.1
> 
> 
> ___
> 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] Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Wednesday, March 9, 2016 2:39 AM
> To: Jan Beulich ; George Dunlap
> ; Wu, Feng 
> Cc: Andrew Cooper ; Dario Faggioli
> ; Tian, Kevin ; xen-
> de...@lists.xen.org; Konrad Rzeszutek Wilk ; Keir
> Fraser 
> Subject: Re: [Xen-devel] Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt
> core logic handling
> 
> On 08/03/16 17:26, Jan Beulich wrote:
>  On 08.03.16 at 18:05,  wrote:
> >> On 08/03/16 15:42, Jan Beulich wrote:
> >> On 08.03.16 at 15:42,  wrote:
>  On Tue, Mar 8, 2016 at 1:10 PM, Wu, Feng  wrote:
> >> -Original Message-
> >> From: George Dunlap [mailto:george.dun...@citrix.com]
> >>
> >> 2. Try to test engineered situations where we expect this to be a
> >> problem, to see how big of a problem it is (proving the theory to be
> >> accurate or inaccurate in this case)
> >
> > Maybe we can run a SMP guest with all the vcpus pinned to a dedicated
> > pCPU, we can run some benchmark in the guest with VT-d PI and without
> > VT-d PI, then see the performance difference between these two
> sceanrios.
> 
>  This would give us an idea what the worst-case scenario would be.
> >>>
> >>> How would a single VM ever give us an idea about the worst
> >>> case? Something getting close to worst case is a ton of single
> >>> vCPU guests all temporarily pinned to one and the same pCPU
> >>> (could be multi-vCPU ones, but the more vCPU-s the more
> >>> artificial this pinning would become) right before they go into
> >>> blocked state (i.e. through one of the two callers of
> >>> arch_vcpu_block()), the pinning removed while blocked, and
> >>> then all getting woken at once.
> >>
> >> Why would removing the pinning be important?
> >
> > It's not important by itself, other than to avoid all vCPU-s then
> > waking up on the one pCPU.
> >
> >> And I guess it's actually the case that it doesn't need all VMs to
> >> actually be *receiving* interrupts; it just requires them to be
> >> *capable* of receiving interrupts, for there to be a long chain all
> >> blocked on the same physical cpu.
> >
> > Yes.
> >
>   But
>  pinning all vcpus to a single pcpu isn't really a sensible use case we
>  want to support -- if you have to do something stupid to get a
>  performance regression, then I as far as I'm concerned it's not a
>  problem.
> 
>  Or to put it a different way: If we pin 10 vcpus to a single pcpu and
>  then pound them all with posted interrupts, and there is *no*
>  significant performance regression, then that will conclusively prove
>  that the theoretical performance regression is of no concern, and we
>  can enable PI by default.
> >>>
> >>> The point isn't the pinning. The point is what pCPU they're on when
> >>> going to sleep. And that could involve quite a few more than just
> >>> 10 vCPU-s, provided they all sleep long enough.
> >>>
> >>> And the "theoretical performance regression is of no concern" is
> >>> also not a proper way of looking at it, I would say: Even if such
> >>> a situation would happen extremely rarely, if it can happen at all,
> >>> it would still be a security issue.
> >>
> >> What I'm trying to get at is -- exactly what situation?  What actually
> >> constitutes a problematic interrupt latency / interrupt processing
> >> workload, how many vcpus must be sleeping on the same pcpu to actually
> >> risk triggering that latency / workload, and how feasible is it that
> >> such a situation would arise in a reasonable scenario?
> >>
> >> If 200us is too long, and it only takes 3 sleeping vcpus to get there,
> >> then yes, there is a genuine problem we need to try to address before we
> >> turn it on by default.  If we say that up to 500us is tolerable, and it
> >> takes 100 sleeping vcpus to reach that latency, then this is something I
> >> don't really think we need to worry about.
> >>
> >> "I think something bad may happen" is a really difficult to work with.
> >
> > I understand that, but coming up with proper numbers here isn't
> > easy. Fact is - it cannot be excluded that on a system with
> > hundreds of pCPU-s and thousands or vCPU-s, that all vCPU-s
> > would at some point pile up on one pCPU's list.
> 
> So it's already the case that when a vcpu is woken, it is inserted into
> the runqueue by priority order, both for credit1 and credit2; and this
> is an insertion sort, so the amount of time it takes to do the insert is
> expected to be the time it takes to traverse half of the list.  This
> isn't an exact analog, because in that case it's the number of
> *runnable* vcpus, not the number of *blocked* vcpus; but it demonstrates
> 

Re: [Xen-devel] [PATCH v7]xen: sched: convert RTDS from time to event driven model

[Meng Xu]

Hi Tianyang,

Thank you very much for this version of patch. It is in a really good
state, IMHO, although it does have a suspiciuous logic error inside,
which can be corrected easily.

I didn't mark out all repeated style issues. I think you can correct
all of the style issues, such as the spaces in the code, in the next
version.

Hi Dario,
Could you help check if my two concerns in the comments below make sense?
One is small, about if we should use () to make the code clearer.
The other is about the logic in the replenishment handler.


On Fri, Mar 4, 2016 at 8:39 PM, Tianyang Chen  wrote:
> Budget replenishment and enforcement are separated by adding
> a replenishment timer, which fires at the next most imminent
> release time of all runnable vcpus.
>
> A replenishment queue has been added to keep track of all replenishment
> events.
>
> The following functions have major changes to manage the replenishment
> events and timer.
>
> repl_handler(): It is a timer handler which is re-programmed
> to fire at the nearest vcpu deadline to replenish vcpus.
>
> rt_schedule(): picks the highest runnable vcpu based on cpu
> affinity and ret.time will be passed to schedule(). If an idle
> vcpu is picked, -1 is returned to avoid busy-waiting. repl_update()
> has been removed.
>
> rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of
> picking one from the run queue.
>
> rt_context_saved(): when context switching is finished, the
> preempted vcpu will be put back into the run queue and it tickles.
>
> Simplified funtional graph:
>
> schedule.c SCHEDULE_SOFTIRQ:
> rt_schedule():
> [spin_lock]
> burn_budget(scurr)
> snext = runq_pick()
> [spin_unlock]
>
> sched_rt.c TIMER_SOFTIRQ
> replenishment_timer_handler()
> [spin_lock]
>  {
> replenish(i)
> runq_tickle(i)
> }>
> program_timer()
> [spin_lock]
>
> Signed-off-by: Tianyang Chen 
> Signed-off-by: Meng Xu 
> Signed-off-by: Dagaen Golomb 
>
> ---
> changes since v6:
> Removed unnecessary vcpu_on_q() checks for runq_insert()
> Renamed replenishment queue related functions without
> underscores
> New replq_reinsert() function for rt_vcpu_wake()
>
> changes since v5:
> Removed unnecessary vcpu_on_replq() checks
> deadline_queue_insert() returns a flag to indicate if it's
> needed to re-program the timer
> Removed unnecessary timer checks
> Added helper functions to remove vcpus from queues
> coding style
>
> Changes since v4:
> removed unnecessary replenishment queue checks in vcpu_wake()
> extended replq_remove() to all cases in vcpu_sleep()
> used _deadline_queue_insert() helper function for both queues
> _replq_insert() and _replq_remove() program timer internally
>
> Changes since v3:
> removed running queue.
> added repl queue to keep track of repl events.
> timer is now per scheduler.
> timer is init on a valid cpu in a cpupool.
> ---
>  xen/common/sched_rt.c |  381 
> +
>  1 file changed, 286 insertions(+), 95 deletions(-)
>
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index bfed2e2..06803be 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -87,7 +88,7 @@
>  #define RTDS_DEFAULT_BUDGET (MICROSECS(4000))
>
>  #define UPDATE_LIMIT_SHIFT  10
> -#define MAX_SCHEDULE(MILLISECS(1))
> +
>  /*
>   * Flags
>   */
> @@ -142,6 +143,9 @@ static cpumask_var_t *_cpumask_scratch;
>   */
>  static unsigned int nr_rt_ops;
>
> +/* handler for the replenishment timer */
> +static void repl_handler(void *data);
> +
>  /*
>   * Systme-wide private data, include global RunQueue/DepletedQ
>   * Global lock is referenced by schedule_data.schedule_lock from all
> @@ -152,7 +156,9 @@ struct rt_private {
>  struct list_head sdom;  /* list of availalbe domains, used for dump 
> */
>  struct list_head runq;  /* ordered list of runnable vcpus */
>  struct list_head depletedq; /* unordered list of depleted vcpus */
> +struct list_head replq; /* ordered list of vcpus that need 
> replenishment */
>  cpumask_t tickled;  /* cpus been tickled */
> +struct timer *repl_timer;   /* replenishment timer */
>  };
>
>  /*
> @@ -160,6 +166,7 @@ struct rt_private {
>   */
>  struct rt_vcpu {
>  struct list_head q_elem;/* on the runq/depletedq list */
> +struct list_head replq_elem;/* on the repl event list */
>
>  /* Up-pointers */
>  struct rt_dom *sdom;
> @@ -213,8 +220,14 @@ static inline struct list_head *rt_depletedq(const 
> struct scheduler *ops)
>  return _priv(ops)->depletedq;
>  }
>
> +static inline struct list_head 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl  17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-amd64-pair23 guest-stop/src_host   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-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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

version targeted for testing:
 linuxe2857b8f11a289ed2b61d18d0665e05c1053c446
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  243 days
Failing since 59348  2015-07-10 04:24:05 Z  242 days  171 attempts
Testing same since85725  2016-03-08 12:50:52 Z0 days1 attempts


4174 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm 

[Xen-devel] [PATCH v2 2/2] IOMMU/spinlock: Make the pcidevs_lock a recursive one

[Quan Xu]

Signed-off-by: Quan Xu 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Suravee Suthikulpanit 
CC: Feng Wu 
CC: Kevin Tian 
CC: Dario Faggioli 
---
 xen/arch/x86/domctl.c   |  8 +--
 xen/arch/x86/hvm/vmsi.c |  4 +-
 xen/arch/x86/irq.c  |  8 +--
 xen/arch/x86/msi.c  | 16 ++---
 xen/arch/x86/pci.c  |  4 +-
 xen/arch/x86/physdev.c  | 16 ++---
 xen/common/sysctl.c |  4 +-
 xen/drivers/passthrough/amd/iommu_init.c|  8 +--
 xen/drivers/passthrough/amd/iommu_map.c |  2 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  4 +-
 xen/drivers/passthrough/pci.c   | 96 +
 xen/drivers/passthrough/vtd/intremap.c  |  2 +-
 xen/drivers/passthrough/vtd/iommu.c | 14 ++---
 xen/drivers/video/vga.c |  4 +-
 xen/include/xen/pci.h   |  5 +-
 15 files changed, 109 insertions(+), 86 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 55aecdc..b34a295 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -472,9 +472,9 @@ long arch_do_domctl(
 ret = -ESRCH;
 if ( iommu_enabled )
 {
-spin_lock(_lock);
+pcidevs_lock();
 ret = pt_irq_create_bind(d, bind);
-spin_unlock(_lock);
+pcidevs_unlock();
 }
 if ( ret < 0 )
 printk(XENLOG_G_ERR "pt_irq_create_bind failed (%ld) for dom%d\n",
@@ -497,9 +497,9 @@ long arch_do_domctl(
 
 if ( iommu_enabled )
 {
-spin_lock(_lock);
+pcidevs_lock();
 ret = pt_irq_destroy_bind(d, bind);
-spin_unlock(_lock);
+pcidevs_unlock();
 }
 if ( ret < 0 )
 printk(XENLOG_G_ERR "pt_irq_destroy_bind failed (%ld) for dom%d\n",
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 499151e..b41aba5 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -388,7 +388,7 @@ int msixtbl_pt_register(struct domain *d, struct pirq 
*pirq, uint64_t gtable)
 struct msixtbl_entry *entry, *new_entry;
 int r = -EINVAL;
 
-ASSERT(spin_is_locked(_lock));
+ASSERT(pcidevs_is_locked());
 ASSERT(spin_is_locked(>event_lock));
 
 if ( !has_vlapic(d) )
@@ -446,7 +446,7 @@ void msixtbl_pt_unregister(struct domain *d, struct pirq 
*pirq)
 struct pci_dev *pdev;
 struct msixtbl_entry *entry;
 
-ASSERT(spin_is_locked(_lock));
+ASSERT(pcidevs_is_locked());
 ASSERT(spin_is_locked(>event_lock));
 
 if ( !has_vlapic(d) )
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 1228568..78e4263 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1960,7 +1960,7 @@ int map_domain_pirq(
 struct pci_dev *pdev;
 unsigned int nr = 0;
 
-ASSERT(spin_is_locked(_lock));
+ASSERT(pcidevs_is_locked());
 
 ret = -ENODEV;
 if ( !cpu_has_apic )
@@ -2105,7 +2105,7 @@ int unmap_domain_pirq(struct domain *d, int pirq)
 if ( (pirq < 0) || (pirq >= d->nr_pirqs) )
 return -EINVAL;
 
-ASSERT(spin_is_locked(_lock));
+ASSERT(pcidevs_is_locked());
 ASSERT(spin_is_locked(>event_lock));
 
 info = pirq_info(d, pirq);
@@ -2231,7 +2231,7 @@ void free_domain_pirqs(struct domain *d)
 {
 int i;
 
-spin_lock(_lock);
+pcidevs_lock();
 spin_lock(>event_lock);
 
 for ( i = 0; i < d->nr_pirqs; i++ )
@@ -2239,7 +2239,7 @@ void free_domain_pirqs(struct domain *d)
 unmap_domain_pirq(d, i);
 
 spin_unlock(>event_lock);
-spin_unlock(_lock);
+pcidevs_unlock();
 }
 
 static void dump_irqs(unsigned char key)
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 5a481f6..a6018a2 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -694,7 +694,7 @@ static int msi_capability_init(struct pci_dev *dev,
 u8 slot = PCI_SLOT(dev->devfn);
 u8 func = PCI_FUNC(dev->devfn);
 
-ASSERT(spin_is_locked(_lock));
+ASSERT(pcidevs_is_locked());
 pos = pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);
 if ( !pos )
 return -ENODEV;
@@ -852,7 +852,7 @@ static int msix_capability_init(struct pci_dev *dev,
 u8 func = PCI_FUNC(dev->devfn);
 bool_t maskall = msix->host_maskall;
 
-ASSERT(spin_is_locked(_lock));
+ASSERT(pcidevs_is_locked());
 
 control = pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos));
 /*
@@ -1042,7 +1042,7 @@ static int __pci_enable_msi(struct msi_info *msi, struct 
msi_desc **desc)
 struct pci_dev *pdev;
 struct msi_desc *old_desc;
 
-ASSERT(spin_is_locked(_lock));
+ASSERT(pcidevs_is_locked());
 pdev = 

[Xen-devel] [PATCH v2 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization.

[Quan Xu]

When iommu_setup() is called in __start_xen(), interrupts have
already been enabled, and nothing disables (without reenabling)
them again in the path that leads to calling
set_iommu_interrupt_handler(). There's therefore no risk of them
being disabled and needing remaining so, and hence no need for
saving and restoring the flags. This means that, even if interrupt
would need to be disabled when taking pcidevs_lock, spin_lock_irq()
and spin_unlock_irq() could be used.

Inside set_iommu_interrupt_handler(), pcidevs_lock serializes calls
to pci_get_pdev(), which does not require interrupts to be disabled
during its execution. In fact, pcidevs_lock is always (except for
this case) taken without disabling interrupts, and disabling them in
this case would make the BUG_ON() in check_lock() trigger, if it
wasn't for the fact that spinlock debugging checks are still
disabled, during initialization, when iommu_setup() (which then end
up calling set_iommu_interrupt_handler()) is called.

In order to fix this, we can use just plain spin_lock() and spin_unlock(),
instead of spin_lock_irqsave() and spin_unlock_irqrestore().

Signed-off-by: Quan Xu 
Reviewed-by: Dario Faggioli 
CC: Suravee Suthikulpanit 
CC: Dario Faggioli 
CC: Jan Beulich 
---
 xen/drivers/passthrough/amd/iommu_init.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_init.c 
b/xen/drivers/passthrough/amd/iommu_init.c
index d90a2d2..a400497 100644
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -778,7 +778,6 @@ static bool_t __init set_iommu_interrupt_handler(struct 
amd_iommu *iommu)
 {
 int irq, ret;
 hw_irq_controller *handler;
-unsigned long flags;
 u16 control;
 
 irq = create_irq(NUMA_NO_NODE);
@@ -788,10 +787,10 @@ static bool_t __init set_iommu_interrupt_handler(struct 
amd_iommu *iommu)
 return 0;
 }
 
-spin_lock_irqsave(_lock, flags);
+spin_lock(_lock);
 iommu->msi.dev = pci_get_pdev(iommu->seg, PCI_BUS(iommu->bdf),
   PCI_DEVFN2(iommu->bdf));
-spin_unlock_irqrestore(_lock, flags);
+spin_unlock(_lock);
 if ( !iommu->msi.dev )
 {
 AMD_IOMMU_DEBUG("IOMMU: no pdev for %04x:%02x:%02x.%u\n",
-- 
1.9.1


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

[Xen-devel] [PATCH v2 0/2] Make the pcidevs_lock a recursive one

[Quan Xu]

This patch set makes the pcidevs_lock a recursive one. It is a prereq
patch set for Patch:'VT-d Device-TLB flush issue', as the pcidevs_lock
may be recursively held for hiding the ATS device, when VT-d Device-TLB
flush timed out.

In detail:
1. Fix a bug found in AMD IOMMU initialization.

  When iommu_setup() is called in __start_xen(), interrupts have
  already been enabled, and nothing disables (without reenabling)
  them again in the path that leads to calling
  set_iommu_interrupt_handler(). There's therefore no risk of them
  being disabled and needing remaining so, and hence no need for
  saving and restoring the flags. This means that, even if interrupt
  would need to be disabled when taking pcidevs_lock, spin_lock_irq()
  and spin_unlock_irq() could be used.

  Inside set_iommu_interrupt_handler(), pcidevs_lock serializes calls
  to pci_get_pdev(), which does not require interrupts to be disabled
  during its execution. In fact, pcidevs_lock is always (except for
  this case) taken without disabling interrupts, and disabling them in
  this case would make the BUG_ON() in check_lock() trigger, if it
  wasn't for the fact that spinlock debugging checks are still
  disabled, during initialization, when iommu_setup() (which then end
  up calling set_iommu_interrupt_handler()) is called.

  In order to fix this, we can use just plain spin_lock() and spin_unlock(),
  instead of spin_lock_irqsave() and spin_unlock_irqrestore().

2.  Make the pcidevs_lock a recursive one.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Suravee Suthikulpanit 
CC: Feng Wu 
CC: Kevin Tian 
CC: Dario Faggioli 

--Changes in v2:
 * Enhance patch1/2 changelog.
 * Rebase against 1bd52e1fd66c4.


Quan Xu (2):
  IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization.
  IOMMU/spinlock: Make the pcidevs_lock a recursive one

 xen/arch/x86/domctl.c   |  8 +--
 xen/arch/x86/hvm/vmsi.c |  4 +-
 xen/arch/x86/irq.c  |  8 +--
 xen/arch/x86/msi.c  | 16 ++---
 xen/arch/x86/pci.c  |  4 +-
 xen/arch/x86/physdev.c  | 16 ++---
 xen/common/sysctl.c |  4 +-
 xen/drivers/passthrough/amd/iommu_init.c|  9 ++-
 xen/drivers/passthrough/amd/iommu_map.c |  2 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  4 +-
 xen/drivers/passthrough/pci.c   | 96 +
 xen/drivers/passthrough/vtd/intremap.c  |  2 +-
 xen/drivers/passthrough/vtd/iommu.c | 14 ++---
 xen/drivers/video/vga.c |  4 +-
 xen/include/xen/pci.h   |  5 +-
 15 files changed, 109 insertions(+), 87 deletions(-)

-- 
1.9.1


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

Re: [Xen-devel] XSM permissive by default.

[Doug Goldstein]

On 3/8/16 7:51 PM, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> I was wondering if it we should change the default flask_bootparam
> option from permissive to disabled?
> 
> The reason being is that I was startled to see that my xSplice
> code was able to patch the hypervisor from within an PV guest!
> 
> Further testing showed that I could do 'xl debug-keys R' from
> within the guests. This being possible with released 4.6 if I have
> XSM enabled.
> 
> All of this is due to the fact that I had forgotten to load the policy,
> but Xen just told me:
> 
> Flask:  Access controls disabled until policy is loaded.
> 
> which is an understatement. I somehow had expected that if no
> policy was loaded it would revert to the dummy one which has the
> same permission as the non-XSM build. Ha! What a surprise..

That's certainly been my assumption as well.

> 
> Now that the XSM is enabled via config it becomes much more
> easy to enable it..
> 
> Or perhaps change the code to flask so that if there are any
> errors loading the policy it uses the dummy one?
> 

To me that's what that error message from flask meant so I think that's
the most sane default. Being in a worse state than if you had built
without it.

Machon, Something to consider for the Yocto builds as well.

-- 
Doug Goldstein



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

[Xen-devel] [PATCH V17 5/6] domcreate: support pvusb in configuration file

[Chunyan Liu]

Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.

One could specify usb controllers and usb devices in config file
like this:
usbctrl=['version=2,ports=4', 'version=1, ports=4', ]
usbdev=['hostbus=2, hostaddr=1, controller=0,port=1', ]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
Acked-by: Ian Jackson 
---
 docs/man/xl.cfg.pod.5|  84 +
 tools/libxl/libxl_create.c   |  73 +++--
 tools/libxl/libxl_device.c   |   4 ++
 tools/libxl/libxl_internal.h |   8 
 tools/libxl/xl_cmdimpl.c | 107 ++-
 5 files changed, 272 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 56b1117..b156caa 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -722,6 +722,90 @@ Note this may be overridden by rdm_policy option in PCI 
device configuration.
 
 =back
 
+=item 

[Xen-devel] [PATCH V17 6/6] xl: add pvusb commands

[Chunyan Liu]

Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
usbdev-attach and usbdev-detach.

To attach a usb device to guest through pvusb, one could follow
following example:

 #xl usbctrl-attach test_vm version=1 ports=8

 #xl usb-list test_vm
 will show the usb controllers and port usage under the domain.

 #xl usbdev-attach test_vm hostbus=1 hostaddr=2
 will find the first usable controller:port, and attach usb
 device whose busnum is 1 and devnum is 6.
 One could also specify which  and which .

 #xl usbdev-detach test_vm 0 1
 will detach USB device under controller 0 port 1.

 #xl usbctrl-detach test_vm dev_id
 will destroy the controller with specified dev_id. Dev_id
 can be traced in usb-list info.

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
---
 docs/man/xl.pod.1 |  37 +
 tools/libxl/xl.h  |   5 ++
 tools/libxl/xl_cmdimpl.c  | 190 ++
 tools/libxl/xl_cmdtable.c |  25 ++
 4 files changed, 257 insertions(+)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 4279c7c..dc6213e 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1345,6 +1345,43 @@ List pass-through pci devices for a domain.
 
 =back
 
+=head1 USB PASS-THROUGH
+
+=over 4
+
+=item B I I
+
+Create a new USB controller in the domain specified by I,
+I describes the device to attach, using form

[Xen-devel] [PATCH V17 0/6] xen pvusb toolstack work

[Chunyan Liu]

This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.

In V16 4/6:
+out:
+path = GCSPRINTF(USBBACK_INFO_PATH "/%s", usbdev_encode);
+rc = libxl__xs_rm_checked(gc, XBT_NULL, path);
This 'rc' should be removed.
+return rc;

Previously corrected it and sent as [RESEND][PATCH V16], to avoid
confusing, just make a new version. Patch content is the same as
[RESEND][PATCH V16].

V16:
http://lists.xen.org/archives/html/xen-devel/2016-03/msg00517.html

V15:
http://lists.xen.org/archives/html/xen-devel/2016-03/msg00040.html

V14:
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02745.html

V13:
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02125.html

V12:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg02697.html

V11:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01626.html

V10:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01172.html

V9:
http://lists.xen.org/archives/html/xen-devel/2015-11/msg02744.html

V8:
http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html

V7:
http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html

V6:
http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html

V5:
http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html

V4:
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html

Related Discussion Threads:
http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html
http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html

  <<< pvusb work introduction >>>

1. Overview

There are two general methods for passing through individual host
devices to a guest. The first is via an emulated USB device
controller; the second is PVUSB.

Additionally, there are two ways to add USB devices to a guest: via
the config file at domain creation time, and via hot-plug while the VM
is running.

* Emulated USB

In emulated USB, the device model (qemu) presents an emulated USB
controller to the guest. The device model process then grabs control
of the device from domain 0 and and passes the USB commands between
the guest OS and the host USB device.

This method is only available to HVM domains, and is not available for
domains running with device model stubdomains.

* PVUSB

PVUSB uses a paravirtialized front-end/back-end interface, similar to
the traditional Xen PV network and disk protocols. In order to use
PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or
your USB driver domain).

2. Specifying a host USB device

QEMU qmp commands allows USB devices to be specified either by their
bus address (in the form bus.device) or their device tag (in the form
vendorid:deviceid).

Each way of specifying has its advantages:

Specifying by device tag will always get the same device,
regardless of where the device ends up in the USB bus topology.
However, if there are two identical devices, it will not allow you to
specify which one.

Specifying by bus address will always allow you to choose a
specific device, even if you have duplicates. However, the bus address
may change depending on which port you plugged the device into, and
possibly also after a reboot.

To avoid duplication of vendorid:deviceid, we'll use bus address to
specify host USB device in xl toolstack.

You can use lsusb to list the USB devices on the system:

Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0
Hub
Bus 003 Device 002: ID f617:0905
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0
Hub
Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra
Fast Media Reader
Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse

To pass through the Logitec mouse, for instance, you could specify
1.6 (remove leading zeroes).

Note: USB hubs can not be assigned to guest.

3. PVUSB toolstack

* Specify USB device in xl config file

You can just specify usb devices, like:
usbdev=['hostbus=1, hostaddr=6']

Then it will create a USB controller automatically and attach the USB
device to the first available USB controller:port.

or, you can explicitly specify usb controllers and usb devices, like:
usbctrl=['verison=1, ports=4', 'version=2, ports=8', ]
usbdev=['hostbus=1, hostaddr=6, controller=0, port=1']

Then it will create two USB controllers as you specified.
And if controller and port are specified in usb config, then it will
attach the USB device to that controller:port. About the controller
and port value:
Each USB controller has a index (or called devid) based on 0. The 1st
controller has index 0, the 2nd controller has index 1, ...
Under controller, each port has a port number based on 1. In above
configuration, the 1st controller will have port 1,2,3,4.

* Hot-Plug USB device

To attach a USB device, you should first create a USB controller.
e.g.
xl 

[Xen-devel] [PATCH V17 3/6] refactor DEFINE_DEVICE_REMOVE to fit for more device types

[Chunyan Liu]

For some device type, device removal operation needs to be
handled specially, like usbctrl, it needs to remove all usb
devices under it first, then remove usbctrl. Extend
DEFINE_DEVICE_REMOVE to support generic and custom way
For those need to be handled specially, call
DEFINE_DEVICE_REMOVE_CUSTOM, it requires user defined
libxl__initiate_device_##type##_remove. Otherwise, just
call DEFINE_DEVICE_REMOVE as before.

Signed-off-by: George Dunlap 
Signed-off-by: Chunyan Liu 
Reviewed-by: George Dunlap 
---
 tools/libxl/libxl.c  | 18 +-
 tools/libxl/libxl_device.c   | 10 +-
 tools/libxl/libxl_internal.h |  4 ++--
 3 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2ac9c0f..2ab5ad3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3134,7 +3134,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc 
*egc,
 aodev->dev = device;
 aodev->callback = local_device_detach_cb;
 aodev->force = 0;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 return;
 }
 
@@ -4103,7 +4103,7 @@ out:
  * libxl_device_vfb_remove
  * libxl_device_vfb_destroy
  */
-#define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\
+#define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\
 int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
 uint32_t domid, libxl_device_##type *type,  \
 const libxl_asyncop_how *ao_how)\
@@ -4123,13 +4123,19 @@ out:
 aodev->dev = device;\
 aodev->callback = device_addrm_aocomplete;  \
 aodev->force = f;   \
-libxl__initiate_device_remove(egc, aodev);  \
+libxl__initiate_device_##remtype##_remove(egc, aodev);  \
 \
 out:\
-if (rc) return AO_CREATE_FAIL(rc);\
+if (rc) return AO_CREATE_FAIL(rc);  \
 return AO_INPROGRESS;   \
 }
 
+#define DEFINE_DEVICE_REMOVE(type, removedestroy, f) \
+DEFINE_DEVICE_REMOVE_EXT(type, generic, removedestroy, f)
+
+#define DEFINE_DEVICE_REMOVE_CUSTOM(type, removedestroy, f)  \
+DEFINE_DEVICE_REMOVE_EXT(type, type, removedestroy, f)
+
 /* Define all remove/destroy functions and undef the macro */
 
 /* disk */
@@ -4158,6 +4164,8 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
  * 2. dynamically add/remove qemu chardevs via qmp messages. */
 
 #undef DEFINE_DEVICE_REMOVE
+#undef DEFINE_DEVICE_REMOVE_CUSTOM
+#undef DEFINE_DEVICE_REMOVE_EXT
 
 
/**/
 
@@ -4362,7 +4370,7 @@ static int remove_device(libxl__egc *egc, libxl__ao *ao,
 aodev->dev = dev;
 aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
 aodev->callback = device_complete;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 break;
 case LIBXL__DEVICE_KIND_QDISK:
 if (--dguest->num_qdisks == 0) {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 8bb5e93..a356e2a 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -676,7 +676,7 @@ void libxl__devices_destroy(libxl__egc *egc, 
libxl__devices_remove_state *drs)
 aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
 aodev->dev = dev;
 aodev->force = drs->force;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 }
 }
 }
@@ -775,8 +775,8 @@ out:
 return;
 }
 
-void libxl__initiate_device_remove(libxl__egc *egc,
-   libxl__ao_device *aodev)
+void libxl__initiate_device_generic_remove(libxl__egc *egc,
+   libxl__ao_device *aodev)
 {
 STATE_AO_GC(aodev->ao);
 xs_transaction_t t = 0;
@@ -806,7 +806,7 @@ void libxl__initiate_device_remove(libxl__egc *egc,
 (info.paused || info.dying || info.shutdown)) {
 /*
  * TODO: 4.2 Bodge due to QEMU, see comment on top of
- * libxl__initiate_device_remove in libxl_internal.h
+ * libxl__initiate_device_generic_remove in libxl_internal.h
  */
 rc = libxl__ev_time_register_rel(ao, >timeout,
  device_qemu_timeout,
@@ -942,7 +942,7 @@ static void 

[Xen-devel] [PATCH V17 1/6] libxl: export some functions for pvusb use

[Chunyan Liu]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: Wei Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl.c  | 5 ++---
 tools/libxl/libxl_internal.h | 3 +++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 833fd40..2ac9c0f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1966,7 +1966,7 @@ out:
 }
 
 /* common function to get next device id */
-static int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
+int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
 {
 char *dompath, **l;
 unsigned int nb;
@@ -1985,8 +1985,7 @@ static int libxl__device_nextid(libxl__gc *gc, uint32_t 
domid, char *device)
 return nextid;
 }
 
-static int libxl__resolve_domid(libxl__gc *gc, const char *name,
-uint32_t *domid)
+int libxl__resolve_domid(libxl__gc *gc, const char *name, uint32_t *domid)
 {
 if (!name)
 return 0;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index cb9790b..9c8519a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1180,6 +1180,9 @@ _hidden int libxl__init_console_from_channel(libxl__gc 
*gc,
  libxl__device_console *console,
  int dev_num,
  libxl_device_channel *channel);
+_hidden int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device);
+_hidden int libxl__resolve_domid(libxl__gc *gc, const char *name,
+ uint32_t *domid);
 
 /*
  * For each aggregate type which can be used as an input we provide:
-- 
2.1.4


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

[Xen-devel] [PATCH V17 2/6] libxl_utils: add internal function to read sysfs file contents

[Chunyan Liu]

Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.

Signed-off-by: Chunyan Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_internal.h |  4 +++
 tools/libxl/libxl_utils.c| 74 
 2 files changed, 78 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9c8519a..429ea32 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4078,6 +4078,10 @@ void libxl__bitmap_copy_best_effort(libxl__gc *gc, 
libxl_bitmap *dptr,
 
 int libxl__count_physical_sockets(libxl__gc *gc, int *sockets);
 
+_hidden int libxl__read_sysfs_file_contents(libxl__gc *gc,
+const char *filename,
+void **data_r,
+int *datalen_r);
 
 #define LIBXL_QEMU_USER_PREFIX "xen-qemuuser"
 #define LIBXL_QEMU_USER_BASE   LIBXL_QEMU_USER_PREFIX"-domid"
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 672d3f8..b0cb9e1 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -396,6 +396,80 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char 
*filename,
 return e;
 }
 
+int libxl__read_sysfs_file_contents(libxl__gc *gc, const char *filename,
+void **data_r, int *datalen_r)
+{
+FILE *f = 0;
+uint8_t *data = 0;
+int datalen = 0;
+int e;
+struct stat stab;
+ssize_t rs;
+
+f = fopen(filename, "r");
+if (!f) {
+if (errno == ENOENT) return ENOENT;
+LOGE(ERROR, "failed to open %s", filename);
+goto xe;
+}
+
+if (fstat(fileno(f), )) {
+LOGE(ERROR, "failed to fstat %s", filename);
+goto xe;
+}
+
+if (!S_ISREG(stab.st_mode)) {
+LOGE(ERROR, "%s is not a plain file", filename);
+errno = ENOTTY;
+goto xe;
+}
+
+if (stab.st_size > INT_MAX) {
+LOG(ERROR, "file %s is far too large", filename);
+errno = EFBIG;
+goto xe;
+}
+
+datalen = stab.st_size;
+
+if (stab.st_size && data_r) {
+data = libxl__malloc(gc, datalen);
+
+/* For sysfs file, datalen is always PAGE_SIZE. 'read'
+ * will return the number of bytes of the actual content,
+ * rs <= datalen is expected.
+ */
+rs = fread(data, 1, datalen, f);
+if (rs < datalen) {
+if (ferror(f)) {
+LOGE(ERROR, "failed to read %s", filename);
+goto xe;
+}
+
+datalen = rs;
+data = libxl__realloc(gc, data, datalen);
+}
+}
+
+if (fclose(f)) {
+f = 0;
+LOGE(ERROR, "failed to close %s", filename);
+goto xe;
+}
+
+if (data_r) *data_r = data;
+if (datalen_r) *datalen_r = datalen;
+
+return 0;
+
+ xe:
+e = errno;
+assert(e != ENOENT);
+if (f) fclose(f);
+return e;
+}
+
+
 #define READ_WRITE_EXACTLY(rw, zero_is_eof, constdata)\
   \
   int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, \
-- 
2.1.4


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

[Xen-devel] [PATCH V17 4/6] libxl: add pvusb API

[Chunyan Liu]

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

Signed-off-by: Simon Cao 
Signed-off-by: George Dunlap 
Signed-off-by: Chunyan Liu 
Reviewed-by: George Dunlap 
---
 tools/libxl/Makefile |3 +-
 tools/libxl/libxl.c  |   18 +
 tools/libxl/libxl.h  |   77 ++
 tools/libxl/libxl_device.c   |5 +-
 tools/libxl/libxl_internal.h |   18 +
 tools/libxl/libxl_osdeps.h   |   13 +
 tools/libxl/libxl_pvusb.c| 1620 ++
 tools/libxl/libxl_types.idl  |   46 +
 tools/libxl/libxl_types_internal.idl |1 +
 tools/libxl/libxl_utils.c|   18 +
 tools/libxl/libxl_utils.h|5 +
 11 files changed, 1822 insertions(+), 2 deletions(-)
 create mode 100644 tools/libxl/libxl_pvusb.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 789a12e..8fa7b87 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -105,7 +105,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_stream_read.o libxl_stream_write.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
-   libxl_dom_suspend.o libxl_dom_save.o $(LIBXL_OBJS-y)
+   libxl_dom_suspend.o libxl_dom_save.o libxl_pvusb.o \
+$(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2ab5ad3..1e68688 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4102,6 +4102,8 @@ out:
  * libxl_device_vkb_destroy
  * libxl_device_vfb_remove
  * libxl_device_vfb_destroy
+ * libxl_device_usbctrl_remove
+ * libxl_device_usbctrl_destroy
  */
 #define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\
 int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
@@ -4159,6 +4161,10 @@ DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
 DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
 
+/* usbctrl */
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, remove, 0)
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, destroy, 1)
+
 /* channel/console hotunplug is not implemented. There are 2 possibilities:
  * 1. add support for secondary consoles to xenconsoled
  * 2. dynamically add/remove qemu chardevs via qmp messages. */
@@ -4174,6 +4180,8 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
  * libxl_device_disk_add
  * libxl_device_nic_add
  * libxl_device_vtpm_add
+ * libxl_device_usbctrl_add
+ * libxl_device_usbdev_add
  */
 
 #define DEFINE_DEVICE_ADD(type) \
@@ -4205,6 +4213,12 @@ DEFINE_DEVICE_ADD(nic)
 /* vtpm */
 DEFINE_DEVICE_ADD(vtpm)
 
+/* usbctrl */
+DEFINE_DEVICE_ADD(usbctrl)
+
+/* usb */
+DEFINE_DEVICE_ADD(usbdev)
+
 #undef DEFINE_DEVICE_ADD
 
 
/**/
@@ -6750,6 +6764,10 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, 
uint32_t domid,
 
 MERGE(pci, pcidevs, COMPARE_PCI, {});
 
+MERGE(usbctrl, usbctrls, COMPARE_USBCTRL, {});
+
+MERGE(usbdev, usbdevs, COMPARE_USB, {});
+
 /* Take care of removable device. We maintain invariant in the
  * insert / remove operation so that:
  * 1. if xenstore is "empty" while JSON is not, the result
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0859383..5cc3ce3 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -123,6 +123,12 @@
 #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
 
 /*
+ * LIBXL_HAVE_PVUSB indicates functions for plugging in USB devices
+ * through pvusb -- both hotplug and at domain creation time..
+ */
+#define LIBXL_HAVE_PVUSB 1
+
+/*
  * LIBXL_HAVE_BUILDINFO_HVM_VENDOR_DEVICE indicates that the
  * libxl_vendor_device field is present in the hvm sections of
  * libxl_domain_build_info. This field tells libxl which
@@ -1536,6 +1542,77 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, 
libxl_device_disk *disk,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
 
+/*
+ * USB
+ *
+ * For each device removed or added, one of these protocols is available:
+ * - PV (i.e., PVUSB)
+ * - DEVICEMODEL (i.e, qemu)
+ *
+ * PV is available for either PV or HVM domains.  DEVICEMODEL is only
+ * available for HVM domains.  The caller can additionally specify
+ * "AUTO", in which case the library will try to determine the best
+ * protocol automatically.
+ *
+ * At the moment, the only protocol implemented is PV.
+ *
+ * One can add/remove USB controllers to/from guest, and attach/detach USB
+ * devices 

Re: [Xen-devel] [PATCH v11 20/27] Support colo mode for qemu disk

[Konrad Rzeszutek Wilk]

> Furthermore, I think coming up with a story for PV-aware guests (PVHVM,
> PV and PVH) is also non-trivial. For one the disk replication logic is

Pls keep in mind that PV guests can use QEMU qdisk if they wish.

This is more of 'phy' vs 'file' question.
> not implemented in PV block backend,  we're not sure how feasible to
> replicate thing in QEMU into kernel, but we're quite sure it is not
> going to be trivial technically and politically. The uncertainty is too

.. and I think doing it in the kernel is not a good idea. With PVH
coming as the initial domain - we will now have solved the @$@#@@
syscall bounce to hypervisor slowpath - which means that any libaio
operations QEMU does on a file - which ends up going to the kernel
with a syscall - will happen without incuring a huge context switch!

In other words the speed difference between qdisk and xen-blkback
will now be just the syscall + aio code + fs overhead.

With proper batching this can be made faster*.

*: I am ignoring the other issues such as grant unmap in PVH guests
and qdisk being quite spartan in features compared to xen-blkback.

> big to come up with a clear idea what it would look like.

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

[Xen-devel] XSM permissive by default.

[Konrad Rzeszutek Wilk]

Hey,

I was wondering if it we should change the default flask_bootparam
option from permissive to disabled?

The reason being is that I was startled to see that my xSplice
code was able to patch the hypervisor from within an PV guest!

Further testing showed that I could do 'xl debug-keys R' from
within the guests. This being possible with released 4.6 if I have
XSM enabled.

All of this is due to the fact that I had forgotten to load the policy,
but Xen just told me:

Flask:  Access controls disabled until policy is loaded.

which is an understatement. I somehow had expected that if no
policy was loaded it would revert to the dummy one which has the
same permission as the non-XSM build. Ha! What a surprise..

Now that the XSM is enabled via config it becomes much more
easy to enable it..

Or perhaps change the code to flask so that if there are any
errors loading the policy it uses the dummy one?

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

Re: [Xen-devel] [RESEND][PATCH V16 0/6] xen pvusb toolstack work

[Chun Yan Liu]

>>> On 3/8/2016 at 07:33 PM, in message <56deb899.7080...@citrix.com>, George
Dunlap  wrote: 
> On 08/03/16 01:37, Chunyan Liu wrote: 
> > This patch series is to add pvusb toolstack work, supporting hot add|remove 
> > USB device to|from guest and specify USB device in domain configuration  
> file. 
> >  
> > RESEND to remove a incorrect rc in 4/6: 
> > +out: 
> > +path = GCSPRINTF(USBBACK_INFO_PATH "/%s", usbdev_encode); 
> > +rc = libxl__xs_rm_checked(gc, XBT_NULL, path); 
> > 'rc' should be removed here. 
> > +return rc; 
> >  
> > Sorry for trouble you. 
>  
> Hey Chunyan, 
>  
> If you make any change at all to the patch series, you should increase 
> the revision number.  Otherwise, the person who ultimately commits it is 
> likely to think that the original version and the resend are the same, 
> and accidentally commit the original (incorrect) version.  (For 
> instance, they may already like me have downloaded the original patch 
> series and imported it into git.) 
>  
> The best thing to do in this situation would have been to reply to your 
> own patch, saying "And this 'rc' should be removed.  I'll spin another 
> version." 
>  
> I took a brief look at the diff between v14 and v15v1 yesterday, and it 
> looks good.  IanJ is away this week, and I'm sure he'll want to take a 
> look at it before Ack-ing it next week.  So would you mind sending a 
> v16, and I'll review it by the end of the week? 

Got it. Will post the RESEND series with a new version number.

>  
> Thanks, 
>  -George 
>  
> >  
> > Changes to V15: 
> > * address George's comments (patch 4/6) 
> >  
> > V15: 
> > http://lists.xen.org/archives/html/xen-devel/2016-03/msg00040.html 
> >  
> > V14: 
> > http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02745.html 
> >  
> > V13: 
> > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02125.html 
> >  
> > V12: 
> > http://lists.xen.org/archives/html/xen-devel/2015-12/msg02697.html 
> >  
> > V11: 
> > http://lists.xen.org/archives/html/xen-devel/2015-12/msg01626.html 
> >  
> > V10: 
> > http://lists.xen.org/archives/html/xen-devel/2015-12/msg01172.html 
> >  
> > V9: 
> > http://lists.xen.org/archives/html/xen-devel/2015-11/msg02744.html 
> >  
> > V8: 
> > http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html 
> >  
> > V7: 
> > http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html 
> >  
> > V6: 
> > http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html 
> >  
> > V5: 
> > http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html 
> >  
> > V4: 
> > http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html 
> >  
> > Related Discussion Threads: 
> > http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html 
> > http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html 
> >  
> >   <<< pvusb work introduction >>> 
> >  
> > 1. Overview 
> >  
> > There are two general methods for passing through individual host 
> > devices to a guest. The first is via an emulated USB device 
> > controller; the second is PVUSB. 
> >  
> > Additionally, there are two ways to add USB devices to a guest: via 
> > the config file at domain creation time, and via hot-plug while the VM 
> > is running. 
> >  
> > * Emulated USB 
> >  
> > In emulated USB, the device model (qemu) presents an emulated USB 
> > controller to the guest. The device model process then grabs control 
> > of the device from domain 0 and and passes the USB commands between 
> > the guest OS and the host USB device. 
> >  
> > This method is only available to HVM domains, and is not available for 
> > domains running with device model stubdomains. 
> >  
> > * PVUSB 
> >  
> > PVUSB uses a paravirtialized front-end/back-end interface, similar to 
> > the traditional Xen PV network and disk protocols. In order to use 
> > PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or 
> > your USB driver domain). 
> >  
> > 2. Specifying a host USB device 
> >  
> > QEMU qmp commands allows USB devices to be specified either by their 
> > bus address (in the form bus.device) or their device tag (in the form 
> > vendorid:deviceid). 
> >  
> > Each way of specifying has its advantages: 
> >  
> > Specifying by device tag will always get the same device, 
> > regardless of where the device ends up in the USB bus topology. 
> > However, if there are two identical devices, it will not allow you to 
> > specify which one. 
> >  
> > Specifying by bus address will always allow you to choose a 
> > specific device, even if you have duplicates. However, the bus address 
> > may change depending on which port you plugged the device into, and 
> > possibly also after a reboot. 
> >  
> > To avoid duplication of vendorid:deviceid, we'll use bus address to 
> > specify host USB device in xl toolstack. 
> >  
> > You can use lsusb to list the USB devices on the system: 

[Xen-devel] [ovmf test] 85701: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf 43ca17532bd7292eee5ad979e26b19ddd0d3e55a
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   91 days
Failing since 65593  2015-12-08 23:44:51 Z   91 days   96 attempts
Testing same since85701  2016-03-08 07:16:01 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Haojian Zhuang 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  Jordan Justen 
  Karyne Mayer 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leif Lindholm 
  Liming Gao 
  Mark Rutland 
  Marvin Haeuser 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Ni, Ruiyu 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Qin Long 
  Qiu Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Tian, Feng 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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



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

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

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

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


Not pushing.

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

Re: [Xen-devel] [PATCH v6 for Xen 4.7 3/4] libxl: enable per-VCPU parameter settings for RTDS scheduler

[Chong Li]

On Tue, Mar 8, 2016 at 1:12 PM, Wei Liu  wrote:
> On Sun, Mar 06, 2016 at 11:55:57AM -0600, Chong Li wrote:
> [...]
>>  tools/libxl/libxl.c | 326 
>> 
>>  tools/libxl/libxl.h |  37 +
>>  tools/libxl/libxl_types.idl |  14 ++
>>  3 files changed, 354 insertions(+), 23 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index bd3aac8..4532e86 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -5770,6 +5770,207 @@ static int sched_credit2_domain_set(libxl__gc *gc, 
>> uint32_t domid,
>>  return 0;
>>  }
>>
>> +static int sched_rtds_validate_params(libxl__gc *gc, int period,
>> +int budget, uint32_t *sdom_period,
>> +uint32_t *sdom_budget)
>
>
> This is a strange pattern. It does more than what it's name suggests.
>
> It seems this function just returns the vanilla values in period and
> budget. It can be simplified by removing sdom_period and sdom_budget all
> together. Do you agree?

Yes.

>> +
>> +/* Get the RTDS scheduling parameters of vcpu(s) */
>> +static int sched_rtds_vcpu_get(libxl__gc *gc, uint32_t domid,
>> +   libxl_vcpu_sched_params *scinfo)
>> +{
>> +uint32_t num_vcpus;
>> +int i, r, rc;
>> +xc_dominfo_t info;
>> +struct xen_domctl_schedparam_vcpu *vcpus;
>> +
>> +r = xc_domain_getinfo(CTX->xch, domid, 1, );
>> +if (r < 0) {
>> +LOGE(ERROR, "getting domain info");
>> +rc = ERROR_FAIL;
>> +goto out;
>> +}
>> +
>> +num_vcpus = scinfo->num_vcpus ? scinfo->num_vcpus :
>> +info.max_vcpu_id + 1;
>> +
>> +GCNEW_ARRAY(vcpus, num_vcpus);
>> +
>> +if (scinfo->num_vcpus > 0) {
>> +for (i = 0; i < num_vcpus; i++) {
>> +if (scinfo->vcpus[i].vcpuid < 0 ||
>> +scinfo->vcpus[i].vcpuid > info.max_vcpu_id) {
>> +LOG(ERROR, "VCPU index is out of range, "
>> +   "valid values are within range from 0 to %d",
>> +   info.max_vcpu_id);
>> +rc = ERROR_INVAL;
>> +goto out;
>> +}
>> +vcpus[i].vcpuid = scinfo->vcpus[i].vcpuid;
>> +}
>> +} else
>> +for (i = 0; i < num_vcpus; i++)
>> +vcpus[i].vcpuid = i;
>> +
>> +r = xc_sched_rtds_vcpu_get(CTX->xch, domid, vcpus, num_vcpus);
>> +if (r != 0) {
>> +LOGE(ERROR, "getting vcpu sched rtds");
>> +rc = ERROR_FAIL;
>> +goto out;
>> +}
>> +scinfo->sched = LIBXL_SCHEDULER_RTDS;
>> +if (scinfo->num_vcpus == 0) {
>> +scinfo->num_vcpus = num_vcpus;
>> +scinfo->vcpus = libxl__calloc(NOGC, num_vcpus,
>> +sizeof(libxl_sched_params));
>> +}
>> +for(i = 0; i < num_vcpus; i++) {
>> +scinfo->vcpus[i].period = vcpus[i].s.rtds.period;
>> +scinfo->vcpus[i].budget = vcpus[i].s.rtds.budget;
>> +scinfo->vcpus[i].vcpuid = vcpus[i].vcpuid;
>> +}
>> +return r;
>
> Just set rc = 0 here?

Ok.

>
>> +out:
>> +return rc;
>> +}
>> +
>> +/* Set the RTDS scheduling parameters of vcpu(s) */
>> +static int sched_rtds_vcpus_params_set(libxl__gc *gc, uint32_t domid,
>> +   const libxl_vcpu_sched_params *scinfo)
>> +{
>> +int r, rc;
>> +int i;
>> +uint16_t max_vcpuid;
>> +xc_dominfo_t info;
>> +struct xen_domctl_schedparam_vcpu *vcpus;
>> +uint32_t num_vcpus;
>> +
>> +r = xc_domain_getinfo(CTX->xch, domid, 1, );
>> +if (r < 0) {
>> +LOGE(ERROR, "getting domain info");
>> +rc = ERROR_FAIL;
>> +goto out;
>> +}
>> +max_vcpuid = info.max_vcpu_id;
>> +
>> +if (scinfo->num_vcpus > 0) {
>> +num_vcpus = scinfo->num_vcpus;
>> +GCNEW_ARRAY(vcpus, num_vcpus);
>> +for (i = 0; i < num_vcpus; i++) {
>> +if (scinfo->vcpus[i].vcpuid < 0 ||
>> +scinfo->vcpus[i].vcpuid > max_vcpuid) {
>> +LOG(ERROR, "VCPU index is out of range, "
>> +   "valid values are within range from 0 to %d",
>> +   max_vcpuid);
>> +rc = ERROR_INVAL;
>> +goto out;
>> +}
>> +vcpus[i].vcpuid = scinfo->vcpus[i].vcpuid;
>> +
>
> I would suggest you use a separate loop to validate the input, otherwise
> you risk getting input partial success.

What do you mean by "partial success"?
Do you suggest to validate the entire input first, and then create &&
set the vcpus array?

>
>> +rc = sched_rtds_validate_params(gc,
>> +scinfo->vcpus[i].period, scinfo->vcpus[i].budget,
>> +[i].s.rtds.period, [i].s.rtds.budget);
>> +if (rc) {
>> +rc = ERROR_INVAL;
>> +goto out;
>> + 

[Xen-devel] [xen-unstable baseline-only test] 44233: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 44225
 test-amd64-amd64-xl  19 guest-start/debian.repeat fail REGR. vs. 44225

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 44225
 build-amd64-rumpuserxen   6 xen-buildfail   like 44225
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeatfail   like 44225
 test-amd64-amd64-xl-xsm  19 guest-start/debian.repeatfail   like 44225
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44225
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44225

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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 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-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-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-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail 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-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  0aa1330aac92fd75f185c9b354396014178fe95d
baseline version:
 xen  1bd52e1fd66c47af690124d74d11ccb271c96f6b

Last test of basis44225  2016-03-06 05:52:35 Z2 days
Testing same since44233  2016-03-08 14:49:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  Doug Goldstein 
  George Dunlap 
  Jan Beulich 
  Konrad Rzeszutek Wilk 

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  

Re: [Xen-devel] Patching error while setting up COLO

[Yu-An(Victor) Chen]

Sorry for the duplicated email Congyang, I forgot to replied all:

Hi Congyang,

Thank you for the hint, after building xen, your script works for qemu-xen!

so now I am trying to set up the secondary node with the script provided by
Changlong in his first reply:
---
rm -f /var/log/xen/*
rm -f /var/lib/xen/userdata-d.*
service xencommons start
modprobe xt_SECCOLO


*active_disk=/mnt/ramfs/active_disk.imghidden_disk=/mnt/ramfs/hidden_disk.imglocal_img=/root/xie/suse-64hvm.img*
tmp_disk_size=`./qemu-colo/qemu-img info $local_img |grep 'virtual size'
|awk  '{print $3}'`
rm -rf /mnt/ramfs/*
umount /mnt/ramfs/
rm -rf /mnt/ramfs/
mkdir /mnt/ramfs
function create_image()
{
/root/xie/xen/tools/qemu-xen-dir/qemu-img create -f qcow2 $1
$tmp_disk_size
}
function prepare_temp_images()
{
grep -q "^none /mnt/ramfs ramfs" /proc/mounts
if [[ $? -ne 0 ]]; then
mount -t ramfs none /mnt/ramfs/ -o size=2G
fi

if [[ ! -e $active_disk ]]; then
create_image $active_disk
fi

if [[ ! -e $hidden_disk ]]; then
create_image $hidden_disk
fi
}
---

I have question about for the codes below:



*active_disk=/mnt/ramfs/active_disk.imghidden_disk=/mnt/ramfs/hidden_disk.imglocal_img=/root/xie/suse-64hvm.img*

Do I have to create my own image and put the img in that location? if so
what kind of img specifically?

because when I look into /mnt/ramfs, it is an empty directory.

Thank you!

On Sun, Mar 6, 2016 at 5:12 PM, Wen Congyang  wrote:

> On 03/05/2016 09:51 AM, Yu-An(Victor) Chen wrote:
> > Hi Congyang,
> >
> > Thanks for your reply,
> >
> > even with your script, and I modify the "path_to_xen_source" to point
> where my xen directory is. I still got this error.
> >
> > ERROR: User requested feature xen
> >configure was not able to find it.
> >Install xen devel
> >
> > What do you think what I am missing? Thank you!
>
> Do you build xen before?
>
> Thanks
> Wen Congyang
>
> >
> > Victor
> >
> >
> >
> > On Thu, Mar 3, 2016 at 6:15 PM, Wen Congyang  > wrote:
> >
> > On 03/04/2016 10:01 AM, Yu-An(Victor) Chen wrote:
> > > Hi,
> > >
> > > So I git clone
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wencongyang_qemu-2Dxen.git=CwICaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=4j1T2HKL4uKodf62b4Tz1XtOvX81uAqCqfOcD90CRAY=s0fo5ej8_vZ1PmOkDCuyIroS5Zi_KpDSHI8jqodSmrg=
> > >
> > > but i only see branch "con-xen-v2" instead of " colo-xen-v2" so I
> assume I use just use con-xen-v2.
> > >
> > > But then the following step:
> > >
> > > in both ~/qemu-colo and ~/qemu-xen
> > >
> > > ./configure --enable-xen --target-list=x86_64-softmmu
> --extra-cflags="-I$path_to_xen_source/tools/include
> -I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore"
> --extra-ldflags="-L$path_to_xen_source/tools/libxc
> -L$path_to_xen_source/tools/xenstore"
> >
> >
> > This command line is out of dated. The following is my building
> scripts:
> > #! /bin/bash
> >
> > path_to_xen_source=/work/src/xen
> > #./configure --enable-xen --target-list=i386-softmmu \
> > #--extra-cflags="-I$path_to_xen_source/tools/include
> -I$path_to_xen_source/tools/libxc/include
> -I$path_to_xen_source/tools/xenstore/include" \
> > #--extra-ldflags="-L$path_to_xen_source/tools/libxc
> -L$path_to_xen_source/tools/xenstore"
> >
> > extra_cflags=""
> > extra_cflags+=" -DXC_WANT_COMPAT_EVTCHN_API=1"
> > extra_cflags+=" -DXC_WANT_COMPAT_GNTTAB_API=1"
> > extra_cflags+=" -DXC_WANT_COMPAT_MAP_FOREIGN_API=1"
> > extra_cflags+=" -I$path_to_xen_source/tools/include"
> > extra_cflags+=" -I$path_to_xen_source/tools/libs/toollog/include"
> > extra_cflags+=" -I$path_to_xen_source/tools/libs/evtchn/include"
> > extra_cflags+=" -I$path_to_xen_source/tools/libs/gnttab/include"
> > extra_cflags+="
> -I$path_to_xen_source/tools/libs/foreignmemory/include"
> > extra_cflags+=" -I$path_to_xen_source/tools/libxc/include"
> > extra_cflags+=" -I$path_to_xen_source/tools/xenstore/include"
> > extra_cflags+=" -I$path_to_xen_source/tools/xenstore/compat/include"
> > extra_cflags+=" "
> >
> > extra_ldflags=""
> > extra_ldflags+=" -L$path_to_xen_source/tools/libxc"
> > extra_ldflags+=" -L$path_to_xen_source/tools/xenstore"
> > extra_ldflags+=" -L$path_to_xen_source/tools/libs/evtchn"
> > extra_ldflags+=" -L$path_to_xen_source/tools/libs/gnttab"
> > extra_ldflags+=" -L$path_to_xen_source/tools/libs/foreignmemory"
> > extra_ldflags+="
> -Wl,-rpath-link=$path_to_xen_source/tools/libs/toollog"
> > extra_ldflags+="
> 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 85573

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 85573
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 85573
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 85573

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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 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-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 qemuu97556fe80e4f7252300b3498b3477fb4295153a3
baseline version:
 qemuu1464ad45cd6cdeb0b5c1a54d3d3791396e47e52f

Last test of basis85573  2016-03-06 12:47:14 Z2 days
Testing same since85694  2016-03-08 05:48:11 Z0 days1 attempts


People who touched revisions under test:
  Alex Pyrgiotis 
  Fam Zheng 
  Hervé Poussineau 
  Laszlo Ersek 
  Paolo Bonzini 
  Peter Maydell 
  Pranith Kumar 
  Thomas Huth 
  Wei Yang 
  xiaoqiang zhao 

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

Re: [Xen-devel] [PATCH v6 for Xen 4.7 4/4] xl: enable per-VCPU parameter settings for RTDS scheduler

[Chong Li]

On Tue, Mar 8, 2016 at 1:12 PM, Wei Liu  wrote:
> On Sun, Mar 06, 2016 at 11:55:58AM -0600, Chong Li wrote:
> [...]
>> @@ -6222,77 +6359,166 @@ int main_sched_rtds(int argc, char **argv)
>>  {
>>  const char *dom = NULL;
>>  const char *cpupool = NULL;
>> -int period = 0; /* period is in microsecond */
>> -int budget = 0; /* budget is in microsecond */
>> +int *vcpus = (int *)xmalloc(sizeof(int)); /* IDs of VCPUs that change */
>> +int *periods = (int *)xmalloc(sizeof(int)); /* period is in microsecond 
>> */
>> +int *budgets = (int *)xmalloc(sizeof(int)); /* budget is in microsecond 
>> */
>> +int v_size = 1; /* size of vcpus array */
>> +int p_size = 1; /* size of periods array */
>> +int b_size = 1; /* size of budgets array */
>> +int v_index = 0; /* index in vcpus array */
>> +int p_index =0; /* index in periods array */
>> +int b_index =0; /* index for in budgets array */
>>  bool opt_p = false;
>>  bool opt_b = false;
>> -int opt, rc;
>> +bool opt_v = false;
>> +bool opt_all = false; /* output per-dom parameters */
>> +int opt, i;
>> +int rc = 0;
>>  static struct option opts[] = {
>>  {"domain", 1, 0, 'd'},
>>  {"period", 1, 0, 'p'},
>>  {"budget", 1, 0, 'b'},
>> +{"vcpuid",1, 0, 'v'},
>>  {"cpupool", 1, 0, 'c'},
>>  COMMON_LONG_OPTS
>>  };
>>
>> -SWITCH_FOREACH_OPT(opt, "d:p:b:c:", opts, "sched-rtds", 0) {
>> +SWITCH_FOREACH_OPT(opt, "d:p:b:v:c", opts, "sched-rtds", 0) {
>>  case 'd':
>>  dom = optarg;
>>  break;
>>  case 'p':
>> -period = strtol(optarg, NULL, 10);
>> +if (p_index >= p_size) { /* periods array is full */
>> +p_size *= 2;
>> +periods = xrealloc(periods, p_size);
>> +}
>> +periods[p_index++] = strtol(optarg, NULL, 10);
>>  opt_p = 1;
>>  break;
>>  case 'b':
>> -budget = strtol(optarg, NULL, 10);
>> +if (b_index >= b_size) { /* budgets array is full */
>> +b_size *= 2;
>> +budgets = xrealloc(budgets, b_size);
>> +}
>> +budgets[b_index++] = strtol(optarg, NULL, 10);
>>  opt_b = 1;
>>  break;
>> +case 'v':
>> +if (!strcmp(optarg, "all")) { /* get or set all vcpus of a domain */
>> +opt_all = 1;
>> +break;
>> +}
>> +if (v_index >= v_size) { /* vcpus array is full */
>> +v_size *= 2;
>> +vcpus = xrealloc(vcpus, v_size);
>> +}
>> +vcpus[v_index++] = strtol(optarg, NULL, 10);
>> +opt_v = 1;
>> +break;
>
> I'm still not quite sure why this is written like this. What's the
> expected syntax of this command? The hunk to patch xl manpage is very
> terse...

We have three arrays here, vcpus[], periods[] and budgets[]. If the xl
command is like (more examples at cover letter):

xl sched-rtds -d vm1 -v 3 -p 500 -b 200 -v 1 -p 600 -b 300 (set the
scheduling parameters of two vcpus of vm1)

then, the three arrays would be like:

vcpus: [3, 1]
periods: [500, 600]
budgets: [200, 300]

What makes this code complicated is the size of these three arrays
grows along with the
reading of OPTS. At the beginning, all three arrays have the size for
only one int. When
one array becomes full, we double its size.

Chong



-- 
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis

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

Re: [Xen-devel] Xentrace on Xilinx ARM

[Ben Sanda]

George,

>FWIW, on my "to-do" list for xenalyze for years has been to have the xentrace
>process query something (either Xen or Linux) to find the hz rate, and then
>write that at the beginning of the xentrace file, so that xenalyze could just
>pick that up and use it.  Since you're doing some work on xentrace / xenalyze
>anyway, you might think about adding that to your "to-do" list -- it doesn't
>seem conceptually like it would be that hard.

Since I'm in the code base anyway right now I'll give it a look. I was wondering
about that for the xenalyze hertz parameter. I had assumed initially xentrace
embedded the value somehow already. Is there any documentation as to the binary
format xentrace outputs? Or is it best just to look at the code and figure it
out? I guess the main thing would be providing a common interface for both ARM
and x86 but the common trace.c has a get frequency function that's implemented
by both so we should be able to query it and shove in the data.

>The other thing that might be useful is information about the architecture
>you're running on -- right now it assumes intel, and will crash tracing a file
>generated on an AMD box unless you specify --svm-mode.  Adding a trace record
>that indicates "Intel / AMD / ARM" would also make things a lot easier.

I didn't run into any issue with xenalyze analyzing the ARM generated trace file
(I didn't give it any special flag). What does --svm-mode modify? The endedness?
I can look quick into that as well.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 83004
 build-armhf   3 host-install(3) broken REGR. vs. 83004
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 83004
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 83004
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 83004

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  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-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-amd64-libvirt 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-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass

version targeted for testing:
 xen  404e83e055cb419efccbcb0c5c89476307a9ae46
baseline version:
 xen  ccc7adf9cff5d5f93720afcc1d0f7227d50feab2

Last test of basis83004  2016-02-18 14:47:44 Z   19 days
Testing same since84923  2016-03-01 13:41:07 Z7 days8 attempts


People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 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-amd64fail
 test-amd64-i386-xl-qemut-debianhvm-amd64 fail
 test-amd64-amd64-xl-qemuu-debianhvm-amd64fail
 test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 fail  

Re: [Xen-devel] [libvirt] [PATCH V2 1/4] conf: add 'state' attribute to feature

[Jim Fehlig]

Joao Martins wrote:
> 
> On 03/01/2016 04:00 AM, Jim Fehlig wrote:
>> Most hypervisors use Hardware Assisted Paging by default and don't
>> require specifying the feature in domain conf. But some hypervisors
>> support disabling HAP on a per-domain basis. To enable HAP by default
>> yet provide a knob to disable it, extend the  feature with a
>> 'state=on|off' attribute, similar to  and  features.
>>
>> In the absence of , the hypervisor default (on) is used. 
>> without the state attribute would be the same as  for
>> backwards compatibility. And of course  disables hap.
>>
>> Signed-off-by: Jim Fehlig 
>> ---
>>  docs/formatdomain.html.in | 6 --
>>  docs/schemas/domaincommon.rng | 6 +-
>>  src/conf/domain_conf.c| 4 ++--
>>  3 files changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
>> index 5016772..c06bcf3 100644
>> --- a/docs/formatdomain.html.in
>> +++ b/docs/formatdomain.html.in
>> @@ -1494,8 +1494,10 @@
>>Interrupt) for the guest.
>>
>>hap
>> -  Enable use of Hardware Assisted Paging if available in
>> -the hardware.
>> +  Depending on the state attribute (values 
>> on,
>> +off) enable or disable use of Hardware Assisted Paging.
>> +The default is on if the hypervisor detects 
>> availability
>> +of Hardware Assisted Paging.
>>
>>viridian
>>Enable Viridian hypervisor extensions for paravirtualizing
>> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
>> index 67af93a..dd6e93a 100644
>> --- a/docs/schemas/domaincommon.rng
>> +++ b/docs/schemas/domaincommon.rng
>> @@ -4108,7 +4108,11 @@
>>
>>
>>  
>> -  
>> +  
>> +
>> +  
>> +
>> +  
> Perhaps  would be better (see chunk below) ? That 
> one
> appears to be a reference of what you are adding above, and it's the same as
> pvspinlock. Though some other elements don't appear to use this, not sure why.

Ah, thanks for catching that. 'featurestate' is definitely the better choice 
here.

> 
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index 89d3a6b..141122c 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -4132,9 +4132,7 @@
>
>  
>
> -
> -  
> -
> +
>
>  
>
> 
> Other that,
> 
> Reviewed-by: Joao Martins 

Thanks. I've squashed in your diff, but should probably wait for any additional
comments before pushing this series.

Regards,
Jim

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

Re: [Xen-devel] [PATCH v6 for Xen 4.7 2/4] libxc: enable per-VCPU parameter settings for RTDS scheduler

[Wei Liu]

On Tue, Mar 08, 2016 at 01:32:58PM -0600, Chong Li wrote:
> On Tue, Mar 8, 2016 at 1:09 PM, Wei Liu  wrote:
> > On Sun, Mar 06, 2016 at 11:55:56AM -0600, Chong Li wrote:
> >> Add xc_sched_rtds_vcpu_get/set functions to interact with
> >> Xen to get/set a domain's per-VCPU parameters.
> >>
> >> Signed-off-by: Chong Li 
> >> Signed-off-by: Meng Xu 
> >> Signed-off-by: Sisu Xi 
> >>
> >> ---
> >> Changes on PATCH v5:
> >> 1) In xc_sched_rtds_vcpu_get/set, re-issueing the hypercall
> >> if it is preempted.
> >>
> >> Changes on PATCH v4:
> >> 1) Minor modifications on the function parameters.
> >>
> >> Changes on PATCH v2:
> >> 1) Minor modifications due to the change of struct xen_domctl_scheduler_op.
> >>
> >> CC: 
> >> CC: 
> >> CC: 
> >> CC: 
> >> CC: 
> >> CC: 
> >> ---
> >>  tools/libxc/include/xenctrl.h | 16 +++---
> >>  tools/libxc/xc_rt.c   | 68 
> >> +++
> >>  2 files changed, 80 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> >> index 01a6dda..9462271 100644
> >> --- a/tools/libxc/include/xenctrl.h
> >> +++ b/tools/libxc/include/xenctrl.h
> >> @@ -888,11 +888,19 @@ int xc_sched_credit2_domain_get(xc_interface *xch,
> >> struct xen_domctl_sched_credit2 *sdom);
> >>
> >>  int xc_sched_rtds_domain_set(xc_interface *xch,
> >> -uint32_t domid,
> >> -struct xen_domctl_sched_rtds *sdom);
> >> +   uint32_t domid,
> >> +   struct xen_domctl_sched_rtds *sdom);
> >>  int xc_sched_rtds_domain_get(xc_interface *xch,
> >> -uint32_t domid,
> >> -struct xen_domctl_sched_rtds *sdom);
> >> +   uint32_t domid,
> >> +   struct xen_domctl_sched_rtds *sdom);
> >
> > Please don't mix fixing indentation with new functionality. Besides, the
> > new indentation looks wrong.
> >
> >> +int xc_sched_rtds_vcpu_set(xc_interface *xch,
> >> +   uint32_t domid,
> >> +   struct xen_domctl_schedparam_vcpu *vcpus,
> >> +   uint32_t num_vcpus);
> >> +int xc_sched_rtds_vcpu_get(xc_interface *xch,
> >> +   uint32_t domid,
> >> +   struct xen_domctl_schedparam_vcpu *vcpus,
> >> +   uint32_t num_vcpus);
> >>
> >
> > Indentation also looks wrong. Maybe you used tab? Please use spaces
> > instead.
> >
> I'm not using tab. This is just what I'm confused with. The
> indentation for these
> four *rtds* functions is the same as the two *credit2* functions
> above. I can not
> find the indentation rules for function calls with many / long parameters.
> 


Use white space and stay aligned with previous line wherever you can.
So:

int xc_sched_rtds_vcpu_get(xc_interface *xch,
   uint32_t domid,
   struct xen_domctl_schedparam_vcpu *vcpus,
   uint32_t num_vcpus);

I know there is inconsistency in the code base. I'm sorry it makes you
feel confused.

Wei.

> Chong
> 
> -- 
> Chong Li
> Department of Computer Science and Engineering
> Washington University in St.louis

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

Re: [Xen-devel] [PATCH v6 for Xen 4.7 2/4] libxc: enable per-VCPU parameter settings for RTDS scheduler

[Chong Li]

On Tue, Mar 8, 2016 at 1:09 PM, Wei Liu  wrote:
> On Sun, Mar 06, 2016 at 11:55:56AM -0600, Chong Li wrote:
>> Add xc_sched_rtds_vcpu_get/set functions to interact with
>> Xen to get/set a domain's per-VCPU parameters.
>>
>> Signed-off-by: Chong Li 
>> Signed-off-by: Meng Xu 
>> Signed-off-by: Sisu Xi 
>>
>> ---
>> Changes on PATCH v5:
>> 1) In xc_sched_rtds_vcpu_get/set, re-issueing the hypercall
>> if it is preempted.
>>
>> Changes on PATCH v4:
>> 1) Minor modifications on the function parameters.
>>
>> Changes on PATCH v2:
>> 1) Minor modifications due to the change of struct xen_domctl_scheduler_op.
>>
>> CC: 
>> CC: 
>> CC: 
>> CC: 
>> CC: 
>> CC: 
>> ---
>>  tools/libxc/include/xenctrl.h | 16 +++---
>>  tools/libxc/xc_rt.c   | 68 
>> +++
>>  2 files changed, 80 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 01a6dda..9462271 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -888,11 +888,19 @@ int xc_sched_credit2_domain_get(xc_interface *xch,
>> struct xen_domctl_sched_credit2 *sdom);
>>
>>  int xc_sched_rtds_domain_set(xc_interface *xch,
>> -uint32_t domid,
>> -struct xen_domctl_sched_rtds *sdom);
>> +   uint32_t domid,
>> +   struct xen_domctl_sched_rtds *sdom);
>>  int xc_sched_rtds_domain_get(xc_interface *xch,
>> -uint32_t domid,
>> -struct xen_domctl_sched_rtds *sdom);
>> +   uint32_t domid,
>> +   struct xen_domctl_sched_rtds *sdom);
>
> Please don't mix fixing indentation with new functionality. Besides, the
> new indentation looks wrong.
>
>> +int xc_sched_rtds_vcpu_set(xc_interface *xch,
>> +   uint32_t domid,
>> +   struct xen_domctl_schedparam_vcpu *vcpus,
>> +   uint32_t num_vcpus);
>> +int xc_sched_rtds_vcpu_get(xc_interface *xch,
>> +   uint32_t domid,
>> +   struct xen_domctl_schedparam_vcpu *vcpus,
>> +   uint32_t num_vcpus);
>>
>
> Indentation also looks wrong. Maybe you used tab? Please use spaces
> instead.
>
I'm not using tab. This is just what I'm confused with. The
indentation for these
four *rtds* functions is the same as the two *credit2* functions
above. I can not
find the indentation rules for function calls with many / long parameters.

Chong

-- 
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis

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

Re: [Xen-devel] [PATCH RFC 0/4] Allow qemu to provide emulated disks for devices with hotplug scripts

[Wei Liu]

On Wed, Mar 02, 2016 at 11:14:00AM +, George Dunlap wrote:
> Qemu in dom0 can only provide emulated disks when the qemu process has
> access to an image of the file.  At the moment, this only includes
> plain files or physical devices in dom0; it does not include anything
> to do with a hotplug script.
> 
> However, hotplug scripts run from dom0 generally do, as a necessary
> side effect of their activity, create a block device which could be
> passed to domain 0; this block device can be passed to a qemu device
> running in dom0 to provide emulated disk support.
> 
> This series allows qemu to gain access to that block device, giving it
> full parity with PV guests for all disks whose backend is in domain 0.
> 
> It also takes steps towards generalizing the "local attach"
> funcitonality which is used by pygrub to access non-local disks, so
> that in the future qemu can access emulated disks by attaching them to
> dom0.
> 
> RFC because I haven't tested it since forward-porting it.
> 

I haven't looked at this series, but I expect another posting on top of
Ian Jackson's hotplug script interface patch.

If you want me to look at this series, please let me know.

Wei.


> 
> George Dunlap (4):
>   libxl: Move check for local access to a funciton
>   libxl: Share logic for finding path between qemuu and pygrub
>   tools/hotplug: Add a "dummy" hotplug script for testing
>   libxl: Allow local access for block devices with hotplug scripts
> 
>  tools/hotplug/Linux/Makefile|   1 +
>  tools/hotplug/Linux/block-common.sh |   5 +-
>  tools/hotplug/Linux/block-dummy | 107 +
>  tools/libxl/libxl.c | 115 
> +---
>  tools/libxl/libxl_bootloader.c  |   1 +
>  tools/libxl/libxl_dm.c  |  66 ++---
>  tools/libxl/libxl_internal.h|  12 +++-
>  7 files changed, 262 insertions(+), 45 deletions(-)
>  create mode 100644 tools/hotplug/Linux/block-dummy
> 
> -- 
> 2.1.4
> 
> 
> ___
> 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] [linux-mingo-tip-master test] 85705: regressions - FAIL

[osstest service owner]

flight 85705 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85705/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 build-amd64-pvops 5 kernel-build  fail REGR. vs. 60684
 build-i386-pvops  5 kernel-build  fail REGR. vs. 60684

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-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 

Re: [Xen-devel] [PATCH v6 for Xen 4.7 4/4] xl: enable per-VCPU parameter settings for RTDS scheduler

[Wei Liu]

On Sun, Mar 06, 2016 at 11:55:58AM -0600, Chong Li wrote:
[...]
> @@ -6222,77 +6359,166 @@ int main_sched_rtds(int argc, char **argv)
>  {
>  const char *dom = NULL;
>  const char *cpupool = NULL;
> -int period = 0; /* period is in microsecond */
> -int budget = 0; /* budget is in microsecond */
> +int *vcpus = (int *)xmalloc(sizeof(int)); /* IDs of VCPUs that change */
> +int *periods = (int *)xmalloc(sizeof(int)); /* period is in microsecond 
> */
> +int *budgets = (int *)xmalloc(sizeof(int)); /* budget is in microsecond 
> */
> +int v_size = 1; /* size of vcpus array */
> +int p_size = 1; /* size of periods array */
> +int b_size = 1; /* size of budgets array */
> +int v_index = 0; /* index in vcpus array */
> +int p_index =0; /* index in periods array */
> +int b_index =0; /* index for in budgets array */
>  bool opt_p = false;
>  bool opt_b = false;
> -int opt, rc;
> +bool opt_v = false;
> +bool opt_all = false; /* output per-dom parameters */
> +int opt, i;
> +int rc = 0;
>  static struct option opts[] = {
>  {"domain", 1, 0, 'd'},
>  {"period", 1, 0, 'p'},
>  {"budget", 1, 0, 'b'},
> +{"vcpuid",1, 0, 'v'},
>  {"cpupool", 1, 0, 'c'},
>  COMMON_LONG_OPTS
>  };
>  
> -SWITCH_FOREACH_OPT(opt, "d:p:b:c:", opts, "sched-rtds", 0) {
> +SWITCH_FOREACH_OPT(opt, "d:p:b:v:c", opts, "sched-rtds", 0) {
>  case 'd':
>  dom = optarg;
>  break;
>  case 'p':
> -period = strtol(optarg, NULL, 10);
> +if (p_index >= p_size) { /* periods array is full */
> +p_size *= 2;
> +periods = xrealloc(periods, p_size);
> +}
> +periods[p_index++] = strtol(optarg, NULL, 10);
>  opt_p = 1;
>  break;
>  case 'b':
> -budget = strtol(optarg, NULL, 10);
> +if (b_index >= b_size) { /* budgets array is full */
> +b_size *= 2;
> +budgets = xrealloc(budgets, b_size);
> +}
> +budgets[b_index++] = strtol(optarg, NULL, 10);
>  opt_b = 1;
>  break;
> +case 'v':
> +if (!strcmp(optarg, "all")) { /* get or set all vcpus of a domain */
> +opt_all = 1;
> +break;
> +}
> +if (v_index >= v_size) { /* vcpus array is full */
> +v_size *= 2;
> +vcpus = xrealloc(vcpus, v_size);
> +}
> +vcpus[v_index++] = strtol(optarg, NULL, 10);
> +opt_v = 1;
> +break;

I'm still not quite sure why this is written like this. What's the
expected syntax of this command? The hunk to patch xl manpage is very
terse...

Wei.

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

[Xen-devel] [linux-4.1 test] 85682: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 66399
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 66399

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2   6 xen-boot   fail in 85641 pass in 85682
 test-armhf-armhf-xl-xsm  11 guest-startfail in 85641 pass in 85682
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 85641
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 85641

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 85641 like 66399
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 66399

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-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 85641 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 85641 never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-amd64-amd64-libvirt-xsm 12 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-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-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 linuxb9a9cfdbf7254f4a231cc8ddf685cc29d3a9c6e5
baseline version:
 linux07cc49f66973f49a391c91bf4b158fa0f2562ca8

Last test of basis66399  2015-12-15 18:20:39 Z   84 days
Failing since 78925  2016-01-24 13:50:39 Z   44 days   45 attempts
Testing same since85582  2016-03-06 13:53:34 Z2 days3 attempts


431 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH v6 for Xen 4.7 3/4] libxl: enable per-VCPU parameter settings for RTDS scheduler

[Wei Liu]

On Sun, Mar 06, 2016 at 11:55:57AM -0600, Chong Li wrote:
[...]
>  tools/libxl/libxl.c | 326 
> 
>  tools/libxl/libxl.h |  37 +
>  tools/libxl/libxl_types.idl |  14 ++
>  3 files changed, 354 insertions(+), 23 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index bd3aac8..4532e86 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5770,6 +5770,207 @@ static int sched_credit2_domain_set(libxl__gc *gc, 
> uint32_t domid,
>  return 0;
>  }
>  
> +static int sched_rtds_validate_params(libxl__gc *gc, int period,
> +int budget, uint32_t *sdom_period,
> +uint32_t *sdom_budget)

Indentation.

> +{
> +int rc = 0;
> +if (period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT) {
> +if (period < 1) {
> +LOG(ERROR, "VCPU period is out of range, "
> +   "valid values are larger than or equal to 1");
> +rc = ERROR_INVAL; /* error scheduling parameter */
> +goto out;
> +}
> +*sdom_period = period;
> +}
> +
> +if (budget != LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT) {
> +if (budget < 1) {
> +LOG(ERROR, "VCPU budget is not set or out of range, "
> +   "valid values are larger than or equal to 1");
> +rc = ERROR_INVAL;
> +goto out;
> +}
> +*sdom_budget = budget;
> +}
> +
> +if (*sdom_budget > *sdom_period) {
> +LOG(ERROR, "VCPU budget must be smaller than "
> +   "or equal to VCPU period");
> +rc = ERROR_INVAL;
> +}

This is a strange pattern. It does more than what it's name suggests.

It seems this function just returns the vanilla values in period and
budget. It can be simplified by removing sdom_period and sdom_budget all
together. Do you agree?

Then at callsites you set those values with two direct assignment:

   if (validate(period_value, budget_value) != 0) {
   error;
   }
   period = period_value;
   budget = budget_value;

> +out:
> +return rc;
> +}
> +
> +/* Get the RTDS scheduling parameters of vcpu(s) */
> +static int sched_rtds_vcpu_get(libxl__gc *gc, uint32_t domid,
> +   libxl_vcpu_sched_params *scinfo)
> +{
> +uint32_t num_vcpus;
> +int i, r, rc;
> +xc_dominfo_t info;
> +struct xen_domctl_schedparam_vcpu *vcpus;
> +
> +r = xc_domain_getinfo(CTX->xch, domid, 1, );
> +if (r < 0) {
> +LOGE(ERROR, "getting domain info");
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +
> +num_vcpus = scinfo->num_vcpus ? scinfo->num_vcpus :
> +info.max_vcpu_id + 1;
> +
> +GCNEW_ARRAY(vcpus, num_vcpus);
> +
> +if (scinfo->num_vcpus > 0) {
> +for (i = 0; i < num_vcpus; i++) {
> +if (scinfo->vcpus[i].vcpuid < 0 ||
> +scinfo->vcpus[i].vcpuid > info.max_vcpu_id) {
> +LOG(ERROR, "VCPU index is out of range, "
> +   "valid values are within range from 0 to %d",
> +   info.max_vcpu_id);
> +rc = ERROR_INVAL;
> +goto out;
> +}
> +vcpus[i].vcpuid = scinfo->vcpus[i].vcpuid;
> +}
> +} else
> +for (i = 0; i < num_vcpus; i++)
> +vcpus[i].vcpuid = i;
> +
> +r = xc_sched_rtds_vcpu_get(CTX->xch, domid, vcpus, num_vcpus);
> +if (r != 0) {
> +LOGE(ERROR, "getting vcpu sched rtds");
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +scinfo->sched = LIBXL_SCHEDULER_RTDS;
> +if (scinfo->num_vcpus == 0) {
> +scinfo->num_vcpus = num_vcpus;
> +scinfo->vcpus = libxl__calloc(NOGC, num_vcpus,
> +sizeof(libxl_sched_params));
> +}
> +for(i = 0; i < num_vcpus; i++) {
> +scinfo->vcpus[i].period = vcpus[i].s.rtds.period;
> +scinfo->vcpus[i].budget = vcpus[i].s.rtds.budget;
> +scinfo->vcpus[i].vcpuid = vcpus[i].vcpuid;
> +}
> +return r;

Just set rc = 0 here?

> +out:
> +return rc;
> +}
> +
> +/* Set the RTDS scheduling parameters of vcpu(s) */
> +static int sched_rtds_vcpus_params_set(libxl__gc *gc, uint32_t domid,
> +   const libxl_vcpu_sched_params *scinfo)

If this is indentation that you're not sure about. Just leave it like
this.

> +{
> +int r, rc;
> +int i;
> +uint16_t max_vcpuid;
> +xc_dominfo_t info;
> +struct xen_domctl_schedparam_vcpu *vcpus;
> +uint32_t num_vcpus;
> +
> +r = xc_domain_getinfo(CTX->xch, domid, 1, );
> +if (r < 0) {
> +LOGE(ERROR, "getting domain info");
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +max_vcpuid = info.max_vcpu_id;
> +
> +if (scinfo->num_vcpus > 0) {
> +num_vcpus = scinfo->num_vcpus;
> +

Re: [Xen-devel] [PATCH v6 for Xen 4.7 2/4] libxc: enable per-VCPU parameter settings for RTDS scheduler

[Wei Liu]

On Sun, Mar 06, 2016 at 11:55:56AM -0600, Chong Li wrote:
> Add xc_sched_rtds_vcpu_get/set functions to interact with
> Xen to get/set a domain's per-VCPU parameters.
> 
> Signed-off-by: Chong Li 
> Signed-off-by: Meng Xu 
> Signed-off-by: Sisu Xi 
> 
> ---
> Changes on PATCH v5:
> 1) In xc_sched_rtds_vcpu_get/set, re-issueing the hypercall
> if it is preempted.
> 
> Changes on PATCH v4:
> 1) Minor modifications on the function parameters.
> 
> Changes on PATCH v2:
> 1) Minor modifications due to the change of struct xen_domctl_scheduler_op.
> 
> CC: 
> CC: 
> CC: 
> CC: 
> CC: 
> CC: 
> ---
>  tools/libxc/include/xenctrl.h | 16 +++---
>  tools/libxc/xc_rt.c   | 68 
> +++
>  2 files changed, 80 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 01a6dda..9462271 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -888,11 +888,19 @@ int xc_sched_credit2_domain_get(xc_interface *xch,
> struct xen_domctl_sched_credit2 *sdom);
>  
>  int xc_sched_rtds_domain_set(xc_interface *xch,
> -uint32_t domid,
> -struct xen_domctl_sched_rtds *sdom);
> +   uint32_t domid,
> +   struct xen_domctl_sched_rtds *sdom);
>  int xc_sched_rtds_domain_get(xc_interface *xch,
> -uint32_t domid,
> -struct xen_domctl_sched_rtds *sdom);
> +   uint32_t domid,
> +   struct xen_domctl_sched_rtds *sdom);

Please don't mix fixing indentation with new functionality. Besides, the
new indentation looks wrong.

> +int xc_sched_rtds_vcpu_set(xc_interface *xch,
> +   uint32_t domid,
> +   struct xen_domctl_schedparam_vcpu *vcpus,
> +   uint32_t num_vcpus);
> +int xc_sched_rtds_vcpu_get(xc_interface *xch,
> +   uint32_t domid,
> +   struct xen_domctl_schedparam_vcpu *vcpus,
> +   uint32_t num_vcpus);
>  

Indentation also looks wrong. Maybe you used tab? Please use spaces
instead.

>  int
>  xc_sched_arinc653_schedule_set(
> diff --git a/tools/libxc/xc_rt.c b/tools/libxc/xc_rt.c
> index d59e5ce..4be9624 100644
> --- a/tools/libxc/xc_rt.c
> +++ b/tools/libxc/xc_rt.c
> @@ -62,3 +62,71 @@ int xc_sched_rtds_domain_get(xc_interface *xch,
>  
>  return rc;
>  }
> +

I only skim the rest but it looks sensible.

Wei.

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

Re: [Xen-devel] [PATCH v6 for Xen 4.7 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler

[Wei Liu]

On Sun, Mar 06, 2016 at 11:55:55AM -0600, Chong Li wrote:
[...]
> @@ -1163,6 +1173,96 @@ rt_dom_cntl(
>  }
>  spin_unlock_irqrestore(>lock, flags);
>  break;
> +case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
> +if ( guest_handle_is_null(op->u.v.vcpus) )
> +{
> +rc = -EINVAL;
> +break;
> +}
> +while ( index < op->u.v.nr_vcpus )
> +{
> +if ( copy_from_guest_offset(_sched,
> +  op->u.v.vcpus, index, 1) )

Indentation.

> +{
> +rc = -EFAULT;
> +break;
> +}
> +if ( local_sched.vcpuid >= d->max_vcpus ||
> +  d->vcpu[local_sched.vcpuid] == NULL )

Ditto.

> +{
> +rc = -EINVAL;
> +break;
> +}
> +
> +spin_lock_irqsave(>lock, flags);
> +svc = rt_vcpu(d->vcpu[local_sched.vcpuid]);
> +local_sched.s.rtds.budget = svc->budget / MICROSECS(1);
> +local_sched.s.rtds.period = svc->period / MICROSECS(1);
> +spin_unlock_irqrestore(>lock, flags);
> +
> +if ( __copy_to_guest_offset(op->u.v.vcpus, index,
> +_sched, 1) )

Here as well.

You might want to check your editor setting. I won't point out other
places that need fixing.

> +{
> +rc = -EFAULT;
> +break;
> +}
> +if ( (++index > 0x3f) && hypercall_preempt_check() )
> +break;
> +}
> +
> +if ( !rc && (op->u.v.nr_vcpus != index) )
> +op->u.v.nr_vcpus = index;
> +break;
> +case XEN_DOMCTL_SCHEDOP_putvcpuinfo:
> +if ( guest_handle_is_null(op->u.v.vcpus) )
> +{
> +rc = -EINVAL;
> +break;
> +}
> +while ( index < op->u.v.nr_vcpus )
> +{
> +if ( copy_from_guest_offset(_sched,
> +  op->u.v.vcpus, index, 1) )
> +{
> +rc = -EFAULT;
> +break;
> +}
> +if ( local_sched.vcpuid >= d->max_vcpus ||
> +  d->vcpu[local_sched.vcpuid] == NULL )
> +{
> +rc = -EINVAL;
> +break;
> +}
> +
> +period = MICROSECS(local_sched.s.rtds.period);
> +budget = MICROSECS(local_sched.s.rtds.budget);
> +if ( period > RTDS_MAX_PERIOD || budget < RTDS_MIN_BUDGET ||
> +  budget > period || period < RTDS_MIN_PERIOD )
> +{
> +rc = -EINVAL;
> +break;
> +}
> +
> +/*
> + * We accept period/budget less than 100 us, but will warn users 
> about
> + * the large scheduling overhead due to it
> + */
> +if ( period < MICROSECS(100) || budget < MICROSECS(100) )
> +printk("Warning: period or budget set to less than 100us.\n"
> +   "This may result in high scheduling overhead.\n");
> +

I'm not the maintainer, but I think having printk here is bad idea
because the toolstack can then DoS the hypervisor.


> +spin_lock_irqsave(>lock, flags);
> +svc = rt_vcpu(d->vcpu[local_sched.vcpuid]);
> +svc->period = period;
> +svc->budget = budget;
> +spin_unlock_irqrestore(>lock, flags);
> +

And this locking pattern seems sub-optimal. You might be able to move
the lock and unlock outside the while loop?

Note that I merely look at this snippet. I don't know that other
constraints you have, so take what I said with a grained of salt.

Wei.

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

[Xen-devel] [PATCH 6/9 v2] xl: Improve return and exit codes of list related functions.

[Harmandeep Kaur]

flush_stream(), list_domains(), list_vm(), main_list() and
main_vm_list() are fixed.

Signed-off-by: Harmandeep Kaur 
---
v2: No changes.
---
 tools/libxl/xl_cmdimpl.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 02aec34..4011c81 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -433,7 +433,7 @@ static void flush_stream(FILE *fh)
 
 if (ferror(fh) || fflush(fh)) {
 perror(fh_name);
-exit(-1);
+exit(EXIT_FAILURE);
 }
 }
 
@@ -3936,12 +3936,12 @@ static void list_domains(bool verbose, bool context, 
bool claim, bool numa,
 if (numa) {
 if (libxl_node_bitmap_alloc(ctx, , 0)) {
 fprintf(stderr, "libxl_node_bitmap_alloc_failed.\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 if (libxl_get_physinfo(ctx, ) != 0) {
 fprintf(stderr, "libxl_physinfo failed.\n");
 libxl_bitmap_dispose();
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 printf(" NODE Affinity");
@@ -4005,7 +4005,7 @@ static void list_vm(void)
 
 if (!info) {
 fprintf(stderr, "libxl_list_vm failed.\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 printf("UUID  IDname\n");
 for (i = 0; i < nb_vm; i++) {
@@ -4959,7 +4959,7 @@ int main_list(int argc, char **argv)
 info = libxl_list_domain(ctx, _domain);
 if (!info) {
 fprintf(stderr, "libxl_list_domain failed.\n");
-return 1;
+return EXIT_FAILURE;
 }
 info_free = info;
 } else if (optind == argc-1) {
@@ -4968,17 +4968,17 @@ int main_list(int argc, char **argv)
 if (rc == ERROR_DOMAIN_NOTFOUND) {
 fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
 argv[optind]);
-return -rc;
+return EXIT_FAILURE;
 }
 if (rc) {
 fprintf(stderr, "libxl_domain_info failed (code %d).\n", rc);
-return -rc;
+return EXIT_FAILURE;
 }
 info = _buf;
 nb_domain = 1;
 } else {
 help("list");
-return 2;
+return EXIT_FAILURE;
 }
 
 if (details)
@@ -4992,7 +4992,7 @@ int main_list(int argc, char **argv)
 
 libxl_dominfo_dispose(_buf);
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_vm_list(int argc, char **argv)
@@ -5004,7 +5004,7 @@ int main_vm_list(int argc, char **argv)
 }
 
 list_vm();
-return 0;
+return EXIT_SUCCESS;
 }
 
 static void string_realloc_append(char **accumulate, const char *more)
-- 
2.5.0


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

[Xen-devel] [PATCH 5/9 v2] xl: Improve return and exit codes of pause, destroy and shutdown related functions.

[Harmandeep Kaur]

destroy_domain(), wait_for_domain_deaths(), shutdown_domain(),
reboot_domain(), main_pause(), main_unpause(), main_destroy()
and main_shutdown_or_reboot() are fixed.

Signed-off-by: Harmandeep Kaur 
---
v2: No changes.
---
 tools/libxl/xl_cmdimpl.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5cedfe8..02aec34 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3705,10 +3705,10 @@ static void destroy_domain(uint32_t domid, int force)
 fprintf(stderr, "Not destroying domain 0; use -f to force.\n"
 "This can only be done when using a disaggregated "
 "hardware domain and toolstack.\n\n");
-exit(-1);
+exit(EXIT_FAILURE);
 }
 rc = libxl_domain_destroy(ctx, domid, 0);
-if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
+if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); 
exit(EXIT_FAILURE); }
 }
 
 static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr)
@@ -3720,7 +3720,7 @@ static void 
wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr)
 rc = libxl_event_wait(ctx, , LIBXL_EVENTMASK_ALL, 0,0);
 if (rc) {
 LOG("Failed to get event, quitting (rc=%d)", rc);
-exit(-1);
+exit(EXIT_FAILURE);
 }
 
 switch (event->type) {
@@ -3765,14 +3765,14 @@ static void shutdown_domain(uint32_t domid,
 }
 
 if (rc) {
-fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
+fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(EXIT_FAILURE);
 }
 
 if (deathw) {
 rc = libxl_evenable_domain_death(ctx, domid, for_user, deathw);
 if (rc) {
 fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
-exit(-1);
+exit(EXIT_FAILURE);
 }
 }
 }
@@ -3796,14 +3796,14 @@ static void reboot_domain(uint32_t domid, 
libxl_evgen_domain_death **deathw,
 }
 }
 if (rc) {
-fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1);
+fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(EXIT_FAILURE);
 }
 
 if (deathw) {
 rc = libxl_evenable_domain_death(ctx, domid, for_user, deathw);
 if (rc) {
 fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
-exit(-1);
+exit(EXIT_FAILURE);
 }
 }
 }
@@ -4802,7 +4802,7 @@ int main_pause(int argc, char **argv)
 
 pause_domain(find_domain(argv[optind]));
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_unpause(int argc, char **argv)
@@ -4815,7 +4815,7 @@ int main_unpause(int argc, char **argv)
 
 unpause_domain(find_domain(argv[optind]));
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_destroy(int argc, char **argv)
@@ -4830,7 +4830,7 @@ int main_destroy(int argc, char **argv)
 }
 
 destroy_domain(find_domain(argv[optind]), force);
-return 0;
+return EXIT_SUCCESS;
 }
 
 static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv)
@@ -4862,7 +4862,7 @@ static int main_shutdown_or_reboot(int do_reboot, int 
argc, char **argv)
 
 if (!argv[optind] && !all) {
 fprintf(stderr, "You must specify -a or a domain id.\n\n");
-return opt;
+return EXIT_FAILURE;
 }
 
 if (all) {
@@ -4870,7 +4870,7 @@ static int main_shutdown_or_reboot(int do_reboot, int 
argc, char **argv)
 libxl_evgen_domain_death **deathws = NULL;
 if (!(dominfo = libxl_list_domain(ctx, _domain))) {
 fprintf(stderr, "libxl_list_domain failed.\n");
-return -1;
+return EXIT_FAILURE;
 }
 
 if (wait_for_it)
@@ -4901,7 +4901,7 @@ static int main_shutdown_or_reboot(int do_reboot, int 
argc, char **argv)
 }
 
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_shutdown(int argc, char **argv)
-- 
2.5.0


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

[Xen-devel] [PATCH 7/9 v2] xl: Improve return and exit codes of create, config_update and rename related functions.

[Harmandeep Kaur]

create_domain(), string_realloc_append(), main_create(),
main_config_update() and main_rename() are fixed.

Signed-off-by: Harmandeep Kaur 
---
v2: Add create_domain()
Remove main_sharing()
---
 tools/libxl/xl_cmdimpl.c | 54 
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 4011c81..f0b5efc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2684,7 +2684,7 @@ static uint32_t create_domain(struct domain_create 
*dom_info)
 
 int i;
 int need_daemon = daemonize;
-int ret, rc;
+int ret = 0, rc;
 libxl_evgen_domain_death *deathw = NULL;
 libxl_evgen_disk_eject **diskws = NULL; /* one per disk */
 void *config_data = 0;
@@ -2713,11 +2713,11 @@ static uint32_t create_domain(struct domain_create 
*dom_info)
 restore_fd = open(restore_file, O_RDONLY);
 if (restore_fd == -1) {
 fprintf(stderr, "Can't open restore file: %s\n", 
strerror(errno));
-return ERROR_INVAL;
+return -1;
 }
 restore_fd_to_close = restore_fd;
 rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
-if (rc) return rc;
+if (rc) return -1;
 }
 
 CHK_ERRNOVAL(libxl_read_exactly(
@@ -2726,11 +2726,11 @@ static uint32_t create_domain(struct domain_create 
*dom_info)
 if (memcmp(hdr.magic, savefileheader_magic, sizeof(hdr.magic))) {
 fprintf(stderr, "File has wrong magic number -"
 " corrupt or for a different tool?\n");
-return ERROR_INVAL;
+return -1;
 }
 if (hdr.byteorder != SAVEFILE_BYTEORDER_VALUE) {
 fprintf(stderr, "File has wrong byte order\n");
-return ERROR_INVAL;
+return -1;
 }
 fprintf(stderr, "Loading new save file %s"
 " (new xl fmt info"
@@ -2743,7 +2743,7 @@ static uint32_t create_domain(struct domain_create 
*dom_info)
 fprintf(stderr, "Savefile has mandatory flag(s) 0x%"PRIx32" "
 "which are not supported; need newer xl\n",
 badflags);
-return ERROR_INVAL;
+return -1;
 }
 if (hdr.optional_data_len) {
 optdata_begin = xmalloc(hdr.optional_data_len);
@@ -2757,7 +2757,7 @@ static uint32_t create_domain(struct domain_create 
*dom_info)
 #define WITH_OPTDATA(amt, body) \
 if (OPTDATA_LEFT < (amt)) { \
 fprintf(stderr, "Savefile truncated.\n");   \
-return ERROR_INVAL; \
+return -1;  \
 } else {\
 body;   \
 optdata_here += (amt);  \
@@ -2790,12 +2790,12 @@ static uint32_t create_domain(struct domain_create 
*dom_info)
 ret = libxl_read_file_contents(ctx, config_file,
_data, _len);
 if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
-   config_file, strerror(errno)); return 
ERROR_FAIL; }
+   config_file, strerror(errno)); return -1; }
 }
 if (!restoring && extra_config && strlen(extra_config)) {
 if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
 fprintf(stderr, "Failed to attach extra configuration\n");
-return ERROR_FAIL;
+return -1;
 }
 /* allocate space for the extra config plus two EOLs plus \0 */
 config_data = xrealloc(config_data, config_len
@@ -2809,7 +2809,7 @@ static uint32_t create_domain(struct domain_create 
*dom_info)
 if (!config_data) {
 fprintf(stderr, "Config file not specified and"
 " none in save file\n");
-return ERROR_INVAL;
+return -1;
 }
 config_source = "";
 config_in_json = !!(hdr.mandatory_flags & XL_MANDATORY_FLAG_JSON);
@@ -2848,7 +2848,7 @@ static uint32_t create_domain(struct domain_create 
*dom_info)
 if (!json) {
 fprintf(stderr,
 "Failed to convert domain configuration to JSON\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 fputs(json, cfg_print_fh);
 free(json);
@@ -2872,7 +2872,7 @@ start:
 ret = freemem(domid, _config.b_info);
 if (ret < 0) {
 fprintf(stderr, "failed to free memory for the domain\n");
-ret = ERROR_FAIL;
+ret = -1;
 goto error_out;
 }
 }
@@ 

[Xen-devel] [PATCH 9/9 v2] xl: Improve return and exit codes of domain id and name related functions.

[Harmandeep Kaur]

find_domain(), main_domid() and main_domname() are fixed.

Signed-off-by: Harmandeep Kaur 
---
v2: Add find_domain().
---
 tools/libxl/xl_cmdimpl.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 4b2ae68..883589b 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -172,7 +172,7 @@ static uint32_t find_domain(const char *p)
 rc = libxl_domain_qualifier_to_domid(ctx, p, );
 if (rc) {
 fprintf(stderr, "%s is an invalid domain identifier (rc=%d)\n", p, rc);
-exit(2);
+exit(EXIT_FAILURE);
 }
 common_domname = libxl_domid_to_name(ctx, domid);
 return domid;
@@ -6335,12 +6335,12 @@ int main_domid(int argc, char **argv)
 
 if (libxl_name_to_domid(ctx, domname, )) {
 fprintf(stderr, "Can't get domid of domain name '%s', maybe this 
domain does not exist.\n", domname);
-return 1;
+return EXIT_FAILURE;
 }
 
 printf("%d\n", domid);
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_domname(int argc, char **argv)
@@ -6358,19 +6358,19 @@ int main_domname(int argc, char **argv)
 if (domid == 0 && !strcmp(endptr, argv[optind])) {
 /*no digits at all*/
 fprintf(stderr, "Invalid domain id.\n\n");
-return 1;
+return EXIT_FAILURE;
 }
 
 domname = libxl_domid_to_name(ctx, domid);
 if (!domname) {
 fprintf(stderr, "Can't get domain name of domain id '%d', maybe this 
domain does not exist.\n", domid);
-return 1;
+return EXIT_FAILURE;
 }
 
 printf("%s\n", domname);
 free(domname);
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_rename(int argc, char **argv)
-- 
2.5.0


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

[Xen-devel] [PATCH 8/9 v2] xl : Improve return and exit codes debugging, special keys and triggering related functions.

[Harmandeep Kaur]

button_press(), main_trigger(), main_sysrq(), main_debug_keys()
and main_dmesg() are fixed.

Signed-off-by: Harmandeep Kaur 
---
v2: Add main_sysrq(), main_debug_keys(), main_dmesg()
Remove xvasprintf(), main_remus()
---
 tools/libxl/xl_cmdimpl.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f0b5efc..4b2ae68 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5231,7 +5231,7 @@ static void button_press(uint32_t domid, const char *b)
 trigger = LIBXL_TRIGGER_SLEEP;
 } else {
 fprintf(stderr, "%s is an invalid button identifier\n", b);
-exit(2);
+exit(EXIT_FAILURE);
 }
 
 libxl_send_trigger(ctx, domid, trigger, 0);
@@ -6413,7 +6413,7 @@ int main_trigger(int argc, char **argv)
 trigger_name = argv[optind++];
 if (libxl_trigger_from_string(trigger_name, )) {
 fprintf(stderr, "Invalid trigger \"%s\"\n", trigger_name);
-return -1;
+return EXIT_FAILURE;
 }
 
 if (argv[optind]) {
@@ -6425,7 +6425,7 @@ int main_trigger(int argc, char **argv)
 
 libxl_send_trigger(ctx, domid, trigger, vcpuid);
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 
@@ -6446,12 +6446,12 @@ int main_sysrq(int argc, char **argv)
 if (sysrq[1] != '\0') {
 fprintf(stderr, "Invalid sysrq.\n\n");
 help("sysrq");
-return 1;
+return EXIT_FAILURE;
 }
 
 libxl_send_sysrq(ctx, domid, sysrq[0]);
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_debug_keys(int argc, char **argv)
@@ -6467,10 +6467,10 @@ int main_debug_keys(int argc, char **argv)
 
 if (libxl_send_debug_keys(ctx, keys)) {
 fprintf(stderr, "cannot send debug keys: %s\n", keys);
-return 1;
+return EXIT_FAILURE;
 }
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_dmesg(int argc, char **argv)
@@ -6496,7 +6496,7 @@ int main_dmesg(int argc, char **argv)
 finish:
 if (cr)
 libxl_xen_console_read_finish(ctx, cr);
-return ret;
+return ret ? EXIT_FAILURE : EXIT_SUCCESS;
 }
 
 int main_top(int argc, char **argv)
-- 
2.5.0


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

[Xen-devel] [PATCH 0/9 v2] xl: convert exit codes related to domain subcommands to EXIT_[SUCCESS|FAILURE]

[Harmandeep Kaur]

*main_foo() is treated somewhat as a regular main(), it is changed to
return EXIT_SUCCESS or EXIT_FAILURE.

*Functions that are not main_foo(), are changed to do 'return 0' or
'return 1', and then 0/1 is taken care in the main_foo() functions
that calls them.

*Functions in xl_cmdimpl.c related to domain subcommands are fixed.

*Aim of this patch is to make exit codes consistent so that anything useful can 
be done with these exit codes.

*This series is a follow-up for the following series:
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02990.html

*Some discussions about this patch:
http://lists.xen.org/archives/html/xen-devel/2015-10/msg02497.html
http://lists.xen.org/archives/html/xen-devel/2015-10/msg02501.html
http://lists.xen.org/archives/html/xen-devel/2015-10/msg02509.html

*v1 of this patch:
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg03353.html
---


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

[Xen-devel] [PATCH 3/9 v2] xl: Improve return and exit codes of migrate related functions.

[Harmandeep Kaur]

Micros CHK_ERRNOVAL, CHK_SYSCALL, MUST are fixed.

xvasprintf(), save_domain_core_begin(), create_migration_child(),
migrate_read_fixedmessage(), migrate_do_preamble(), migrate_domain(),
migrate_receive(), main_migrate_receive() and main_migrate() in the
file xl_cmdimpl are fixed.

Signed-off-by: Harmandeep Kaur 
---
v2: Add CHK_SYSCALL, MUST micros.
Add xvasprintf().
---
 tools/libxl/xl_cmdimpl.c | 58 
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 690eb91..9ec3b2a 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -50,7 +50,7 @@
 else if (chk_errnoval > 0) {\
 fprintf(stderr,"xl: fatal error: %s:%d: %s: %s\n",  \
 __FILE__,__LINE__, strerror(chk_errnoval), #call);  \
-exit(-ERROR_FAIL);  \
+exit(EXIT_FAILURE); \
 }   \
 })
 
@@ -59,7 +59,7 @@
 if ((call) == -1) { \
 fprintf(stderr,"xl: fatal error: %s:%d: %s: %s\n",  \
 __FILE__,__LINE__, strerror(errno), #call); \
-exit(-ERROR_FAIL);  \
+exit(EXIT_FAILURE); \
 }   \
 })
 
@@ -68,7 +68,7 @@
 if (must_rc < 0) {  \
 fprintf(stderr,"xl: fatal error: %s:%d, rc=%d: %s\n",   \
 __FILE__,__LINE__, must_rc, #call); \
-exit(-must_rc); \
+exit(EXIT_FAILURE); \
 }   \
 })
 
@@ -374,7 +374,7 @@ static void xvasprintf(char **strp, const char *fmt, 
va_list ap)
 int r = vasprintf(strp, fmt, ap);
 if (r == -1) {
 perror("asprintf failed");
-exit(-ERROR_FAIL);
+exit(EXIT_FAILURE);
 }
 }
 
@@ -4045,7 +4045,7 @@ static void save_domain_core_begin(uint32_t domid,
   _v, config_len_r);
 if (rc) {
 fprintf(stderr, "unable to read overridden config file\n");
-exit(2);
+exit(EXIT_FAILURE);
 }
 parse_config_data(override_config_file, config_v, *config_len_r,
   _config);
@@ -4054,14 +4054,14 @@ static void save_domain_core_begin(uint32_t domid,
 rc = libxl_retrieve_domain_configuration(ctx, domid, _config);
 if (rc) {
 fprintf(stderr, "unable to retrieve domain configuration\n");
-exit(2);
+exit(EXIT_FAILURE);
 }
 }
 
 config_c = libxl_domain_config_to_json(ctx, _config);
 if (!config_c) {
 fprintf(stderr, "unable to convert config file to JSON\n");
-exit(2);
+exit(EXIT_FAILURE);
 }
 *config_data_r = (uint8_t *)config_c;
 *config_len_r = strlen(config_c) + 1; /* including trailing '\0' */
@@ -4175,7 +4175,7 @@ static pid_t create_migration_child(const char *rune, int 
*send_fd,
 close(recvpipe[0]); close(recvpipe[1]);
 execlp("sh","sh","-c",rune,(char*)0);
 perror("failed to exec sh");
-exit(-1);
+exit(EXIT_FAILURE);
 }
 
 close(sendpipe[0]);
@@ -4198,14 +4198,14 @@ static int migrate_read_fixedmessage(int fd, const void 
*msg, int msgsz,
 
 stream = rune ? "migration receiver stream" : "migration stream";
 rc = libxl_read_exactly(ctx, fd, buf, msgsz, stream, what);
-if (rc) return ERROR_FAIL;
+if (rc) return 1;
 
 if (memcmp(buf, msg, msgsz)) {
 fprintf(stderr, "%s contained unexpected data instead of %s\n",
 stream, what);
 if (rune)
 fprintf(stderr, "(command run was: %s )\n", rune);
-return ERROR_FAIL;
+return 1;
 }
 return 0;
 }
@@ -4281,7 +4281,7 @@ static void migrate_do_preamble(int send_fd, int recv_fd, 
pid_t child,
 
 if (send_fd < 0 || recv_fd < 0) {
 fprintf(stderr, "migrate_do_preamble: invalid file descriptors\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 rc = migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,
@@ -4290,7 +4290,7 @@ static void migrate_do_preamble(int send_fd, int recv_fd, 
pid_t child,
 if (rc) {
 close(send_fd);
 migration_child_report(recv_fd);
-exit(-rc);
+exit(EXIT_FAILURE);
 }
 
 save_domain_core_writeconfig(send_fd, "migration stream",
@@ -4315,7 +4315,7 @@ static void 

[Xen-devel] [PATCH 1/9 v2] xl: Improve return and exit codes of memory related functions.

[Harmandeep Kaur]

Return and exit codes of freemem(), set_memory_max(), main_memmax(),
set_memory_target(), main_memset() and main_sharing() in the file
xl_cmdimpl are fixed.

Add comment to explain return vaule of parse_mem_size_kb().

Signed-off-by: Harmandeep Kaur 
---
v2: Add comment to explain return vaule of parse_mem_size_kb().
Add freemem() and main_sharing().
Remove find_domain().
---
 tools/libxl/xl_cmdimpl.c | 40 ++--
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 990d3c9..088971e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2581,30 +2581,30 @@ static int freemem(uint32_t domid, 
libxl_domain_build_info *b_info)
 
 rc = libxl_domain_need_memory(ctx, b_info, _memkb);
 if (rc < 0)
-return rc;
+return -1;
 
 do {
 rc = libxl_get_free_memory(ctx, _memkb);
 if (rc < 0)
-return rc;
+return -1;
 
 if (free_memkb >= need_memkb)
 return 0;
 
 rc = libxl_set_memory_target(ctx, 0, free_memkb - need_memkb, 1, 0);
 if (rc < 0)
-return rc;
+return -1;
 
 /* wait until dom0 reaches its target, as long as we are making
  * progress */
 rc = libxl_wait_for_memory_target(ctx, 0, 10);
 if (rc < 0)
-return rc;
+return -1;
 
 retries--;
 } while (retries > 0);
 
-return ERROR_NOMEM;
+return -1;
 }
 
 static void autoconnect_console(libxl_ctx *ctx_ignored,
@@ -3133,6 +3133,10 @@ void help(const char *command)
 }
 }
 
+/*
+ * parse_mem_size_kb() returns -1 on failure, or the amount of memory,
+ * on success.
+ */
 static int64_t parse_mem_size_kb(const char *mem)
 {
 char *endptr;
@@ -3275,17 +3279,17 @@ static int def_getopt(int argc, char * const argv[],
 static int set_memory_max(uint32_t domid, const char *mem)
 {
 int64_t memorykb;
-int rc;
 
 memorykb = parse_mem_size_kb(mem);
 if (memorykb == -1) {
 fprintf(stderr, "invalid memory size: %s\n", mem);
-exit(3);
+exit(EXIT_FAILURE);
 }
 
-rc = libxl_domain_setmaxmem(ctx, domid, memorykb);
+if (libxl_domain_setmaxmem(ctx, domid, memorykb))
+   return 1;
 
-return rc;
+return 0;
 }
 
 int main_memmax(int argc, char **argv)
@@ -3305,10 +3309,10 @@ int main_memmax(int argc, char **argv)
 rc = set_memory_max(domid, mem);
 if (rc) {
 fprintf(stderr, "cannot set domid %d static max memory to : %s\n", 
domid, mem);
-return 1;
+return EXIT_FAILURE;
 }
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 static void set_memory_target(uint32_t domid, const char *mem)
@@ -3318,7 +3322,7 @@ static void set_memory_target(uint32_t domid, const char 
*mem)
 memorykb = parse_mem_size_kb(mem);
 if (memorykb == -1)  {
 fprintf(stderr, "invalid memory size: %s\n", mem);
-exit(3);
+exit(EXIT_FAILURE);
 }
 
 libxl_set_memory_target(ctx, domid, memorykb, 0, /* enforce */ 1);
@@ -3338,7 +3342,7 @@ int main_memset(int argc, char **argv)
 mem = argv[optind + 1];
 
 set_memory_target(domid, mem);
-return 0;
+return EXIT_SUCCESS;
 }
 
 static int cd_insert(uint32_t domid, const char *virtdev, char *phys)
@@ -5783,7 +5787,7 @@ int main_sharing(int argc, char **argv)
 info = libxl_list_domain(ctx, _domain);
 if (!info) {
 fprintf(stderr, "libxl_list_domain failed.\n");
-return 1;
+return EXIT_FAILURE;
 }
 info_free = info;
 } else if (optind == argc-1) {
@@ -5792,17 +5796,17 @@ int main_sharing(int argc, char **argv)
 if (rc == ERROR_DOMAIN_NOTFOUND) {
 fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
 argv[optind]);
-return -rc;
+return EXIT_FAILURE;
 }
 if (rc) {
 fprintf(stderr, "libxl_domain_info failed (code %d).\n", rc);
-return -rc;
+return EXIT_FAILURE;
 }
 info = _buf;
 nb_domain = 1;
 } else {
 help("sharing");
-return 2;
+return EXIT_FAILURE;
 }
 
 sharing(info, nb_domain);
@@ -5812,7 +5816,7 @@ int main_sharing(int argc, char **argv)
 else
 libxl_dominfo_dispose(info);
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 static int sched_domain_get(libxl_scheduler sched, int domid,
-- 
2.5.0


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

[Xen-devel] [PATCH 4/9 v2] xl: Improve return and exit codes of console, vnc and core dump related functions.

[Harmandeep Kaur]

autoconnect_vncviewer(), main_console(), main_vncviewer(),
core_dump_domain() and main_dump_core() in the file
xl_cmdimpl are fixed.

Signed-off-by: Harmandeep Kaur 
---
v2: Add autoconnect_vncviewer().
---
 tools/libxl/xl_cmdimpl.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9ec3b2a..5cedfe8 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -219,7 +219,7 @@ static void autoconnect_vncviewer(uint32_t domid, int 
autopass)
 
 sleep(1);
 vncviewer(domid, autopass);
-_exit(1);
+_exit(EXIT_FAILURE);
 }
 
 static int acquire_lock(void)
@@ -3430,7 +3430,7 @@ int main_console(int argc, char **argv)
 type = LIBXL_CONSOLE_TYPE_SERIAL;
 else {
 fprintf(stderr, "console type supported are: pv, serial\n");
-return 2;
+return EXIT_FAILURE;
 }
 break;
 case 'n':
@@ -3444,7 +3444,7 @@ int main_console(int argc, char **argv)
 else
 libxl_console_exec(ctx, domid, num, type);
 fprintf(stderr, "Unable to attach console\n");
-return 1;
+return EXIT_FAILURE;
 }
 
 int main_vncviewer(int argc, char **argv)
@@ -3466,8 +3466,8 @@ int main_vncviewer(int argc, char **argv)
 domid = find_domain(argv[optind]);
 
 if (vncviewer(domid, autopass))
-return 1;
-return 0;
+return EXIT_FAILURE;
+return EXIT_SUCCESS;
 }
 
 static void pcilist(uint32_t domid)
@@ -4022,7 +4022,7 @@ static void core_dump_domain(uint32_t domid, const char 
*filename)
 int rc;
 
 rc=libxl_domain_core_dump(ctx, domid, filename, NULL);
-if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
+if (rc) { fprintf(stderr,"core dump failed 
(rc=%d)\n",rc);exit(EXIT_FAILURE); }
 }
 
 #ifndef LIBXL_HAVE_NO_SUSPEND_RESUME
@@ -4789,7 +4789,7 @@ int main_dump_core(int argc, char **argv)
 }
 
 core_dump_domain(find_domain(argv[optind]), argv[optind + 1]);
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_pause(int argc, char **argv)
-- 
2.5.0


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

[Xen-devel] [PATCH 2/9 v2] xl: Improve return and exit codes of restore and save related functions.

[Harmandeep Kaur]

save_domain(), main_restore(), main_save() and main_remus() in the file
xl_cmdimpl are fixed.

Signed-off-by: Harmandeep Kaur 
---
v2: Add main_remus().
Remove create_domain().
---
 tools/libxl/xl_cmdimpl.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 088971e..690eb91 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4131,7 +4131,7 @@ static int save_domain(uint32_t domid, const char 
*filename, int checkpoint,
 fd = open(filename, O_WRONLY|O_CREAT|O_TRUNC, 0644);
 if (fd < 0) {
 fprintf(stderr, "Failed to open temp file %s for writing\n", filename);
-exit(2);
+exit(EXIT_FAILURE);
 }
 
 save_domain_core_writeconfig(fd, filename, config_data, config_len);
@@ -4151,7 +4151,7 @@ static int save_domain(uint32_t domid, const char 
*filename, int checkpoint,
 else
 libxl_domain_destroy(ctx, domid, 0);
 
-exit(rc < 0 ? 1 : 0);
+exit(rc < 0 ? EXIT_FAILURE : EXIT_SUCCESS);
 }
 
 static pid_t create_migration_child(const char *rune, int *send_fd,
@@ -4625,7 +4625,7 @@ int main_restore(int argc, char **argv)
 checkpoint_file = argv[optind + 1];
 } else {
 help("restore");
-return 2;
+return EXIT_FAILURE;
 }
 
 memset(_info, 0, sizeof(dom_info));
@@ -4642,9 +4642,9 @@ int main_restore(int argc, char **argv)
 
 rc = create_domain(_info);
 if (rc < 0)
-return -rc;
+return EXIT_FAILURE;
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_migrate_receive(int argc, char **argv)
@@ -4700,7 +4700,7 @@ int main_save(int argc, char **argv)
 
 if (argc-optind > 3) {
 help("save");
-return 2;
+return EXIT_FAILURE;
 }
 
 domid = find_domain(argv[optind]);
@@ -4709,7 +4709,7 @@ int main_save(int argc, char **argv)
 config_filename = argv[optind + 2];
 
 save_domain(domid, filename, checkpoint, leavepaused, config_filename);
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_migrate(int argc, char **argv)
@@ -8085,7 +8085,7 @@ int main_remus(int argc, char **argv)
 send_fd = open("/dev/null", O_RDWR, 0644);
 if (send_fd < 0) {
 perror("failed to open /dev/null");
-exit(-1);
+exit(EXIT_FAILURE);
 }
 } else {
 
@@ -8102,7 +8102,7 @@ int main_remus(int argc, char **argv)
 if (!config_len) {
 fprintf(stderr, "No config file stored for running domain and "
 "none supplied - cannot start remus.\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 child = create_migration_child(rune, _fd, _fd);
@@ -8123,7 +8123,7 @@ int main_remus(int argc, char **argv)
 if (libxl_domain_info(ctx, 0, domid)) {
 fprintf(stderr, "Remus: Primary domain has been destroyed.\n");
 close(send_fd);
-return 0;
+return EXIT_SUCCESS;
 }
 
 /* If we are here, it means remus setup/domain suspend/backup has
@@ -8138,7 +8138,7 @@ int main_remus(int argc, char **argv)
 }
 
 close(send_fd);
-return -ERROR_FAIL;
+return EXIT_FAILURE;
 }
 #endif
 
-- 
2.5.0


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

[Xen-devel] [libvirt test] 85689: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  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-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-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  eff43d9abac0e0df9779ee412b7aeaccea8f6e2a
baseline version:
 libvirt  f3c47aafa4743bc0ac75fa476cc40b8013cc529c

Last test of basis85412  2016-03-05 05:45:34 Z3 days
Testing same since85689  2016-03-08 04:21:47 Z0 days1 attempts


People who touched revisions under test:
  John Ferlan 
  Peter Krempa 
  Shanzhi Yu 
  Yuri Chornoivan 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=eff43d9abac0e0df9779ee412b7aeaccea8f6e2a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock 

Re: [Xen-devel] Xentrace on Xilinx ARM

[George Dunlap]

On 08/03/16 18:04, Ben Sanda wrote:
> All,
> 
> To update to the current situation. I have been able to get xentrace() and
> xenalyze working completely (at least as far as I can tell) on ARM.
> 
> For xentrace there were changes to the memory allocation routines to allow
> mapping of the Xen Heap by dom0, correcting the MFN->PFN translations, adding
> the trace buffer initialization to setup.c (init_trace_bufs), and correcting 
> the
> get_cycles() call to provide the system TSC. For the get_cycles() call I
> gathered that was supposed to return the raw tick count, not a translated
> ticks->real time timestamp. I then had to call xenalyze with the core 
> frequency
> defined so the timestamps made sence.

FWIW, on my "to-do" list for xenalyze for years has been to have the
xentrace process query something (either Xen or Linux) to find the hz
rate, and then write that at the beginning of the xentrace file, so that
xenalyze could just pick that up and use it.  Since you're doing some
work on xentrace / xenalyze anyway, you might think about adding that to
your "to-do" list -- it doesn't seem conceptually like it would be that
hard.

The other thing that might be useful is information about the
architecture you're running on -- right now it assumes intel, and will
crash tracing a file generated on an AMD box unless you specify
--svm-mode.  Adding a trace record that indicates "Intel / AMD / ARM"
would also make things a lot easier.

> I plan to push they changes in as a patch to the mainline if that seems
> reasonable to everyone.

Yes, please. :-)

 -George


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

[Xen-devel] [PATCHv1] CA-201372: x86: don't flush the whole cache when changing cachability

[David Vrabel]

Introduce the FLUSH_CACHE_BY_VA flag to flush_area_mask() and friends
to say that it is safe to use CLFLUSH (i.e., the virtual address is
still valid).

Use this when changing the cachability of the Xen direct mappings (in
response to the guest changing the cachability of its mappings). This
significantly improves performance by avoiding an expensive WBINVD.

This fixes a performance regression introduced by
c61a6f74f80eb36ed83a82f713db3143159b9009 (x86: enforce consistent
cachability of MMIO mappings), the fix for XSA-154.

e.g., A set_memory_wc() call in Linux:

before: 4097 us
after:47 us

Signed-off-by: David Vrabel 
---
 xen/arch/x86/flushtlb.c| 3 ++-
 xen/arch/x86/mm.c  | 2 +-
 xen/include/asm-x86/flushtlb.h | 3 +++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 582a1e2..b5aa989 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -140,7 +140,8 @@ unsigned int flush_area_local(const void *va, unsigned int 
flags)
 if ( order < (BITS_PER_LONG - PAGE_SHIFT) )
 sz = 1UL << (order + PAGE_SHIFT);
 
-if ( !(flags & (FLUSH_TLB|FLUSH_TLB_GLOBAL)) &&
+if ( (!(flags & (FLUSH_TLB|FLUSH_TLB_GLOBAL)) ||
+  flags & FLUSH_VA_VALID) &&
  c->x86_clflush_size && c->x86_cache_size && sz &&
  ((sz >> 10) < c->x86_cache_size) )
 {
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 36c4487..1981ca0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5641,7 +5641,7 @@ int map_pages_to_xen(
 flush_flags |= FLUSH_TLB_GLOBAL;   \
 if ( (flags & _PAGE_PRESENT) &&\
  (((o_) ^ flags) & PAGE_CACHE_ATTRS) ) \
-flush_flags |= FLUSH_CACHE;\
+flush_flags |= FLUSH_CACHE_BY_VA;  \
 } while (0)
 
 while ( nr_mfns != 0 )
diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index 4ea31c2..ae90a37 100644
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -85,6 +85,9 @@ void write_cr3(unsigned long cr3);
 #define FLUSH_TLB_GLOBAL 0x200
  /* Flush data caches */
 #define FLUSH_CACHE  0x400
+ /* VA for the flush has a valid mapping */
+#define FLUSH_VA_VALID   0x800
+#define FLUSH_CACHE_BY_VA (FLUSH_CACHE | FLUSH_VA_VALID)
 
 /* Flush local TLBs/caches. */
 unsigned int flush_area_local(const void *va, unsigned int flags);
-- 
2.1.4


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

Re: [Xen-devel] Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling

[George Dunlap]

On 08/03/16 17:26, Jan Beulich wrote:
 On 08.03.16 at 18:05,  wrote:
>> On 08/03/16 15:42, Jan Beulich wrote:
>> On 08.03.16 at 15:42,  wrote:
 On Tue, Mar 8, 2016 at 1:10 PM, Wu, Feng  wrote:
>> -Original Message-
>> From: George Dunlap [mailto:george.dun...@citrix.com]
>>
>> 2. Try to test engineered situations where we expect this to be a
>> problem, to see how big of a problem it is (proving the theory to be
>> accurate or inaccurate in this case)
>
> Maybe we can run a SMP guest with all the vcpus pinned to a dedicated
> pCPU, we can run some benchmark in the guest with VT-d PI and without
> VT-d PI, then see the performance difference between these two sceanrios.

 This would give us an idea what the worst-case scenario would be.
>>>
>>> How would a single VM ever give us an idea about the worst
>>> case? Something getting close to worst case is a ton of single
>>> vCPU guests all temporarily pinned to one and the same pCPU
>>> (could be multi-vCPU ones, but the more vCPU-s the more
>>> artificial this pinning would become) right before they go into
>>> blocked state (i.e. through one of the two callers of
>>> arch_vcpu_block()), the pinning removed while blocked, and
>>> then all getting woken at once.
>>
>> Why would removing the pinning be important?
> 
> It's not important by itself, other than to avoid all vCPU-s then
> waking up on the one pCPU.
> 
>> And I guess it's actually the case that it doesn't need all VMs to
>> actually be *receiving* interrupts; it just requires them to be
>> *capable* of receiving interrupts, for there to be a long chain all
>> blocked on the same physical cpu.
> 
> Yes.
> 
  But
 pinning all vcpus to a single pcpu isn't really a sensible use case we
 want to support -- if you have to do something stupid to get a
 performance regression, then I as far as I'm concerned it's not a
 problem.

 Or to put it a different way: If we pin 10 vcpus to a single pcpu and
 then pound them all with posted interrupts, and there is *no*
 significant performance regression, then that will conclusively prove
 that the theoretical performance regression is of no concern, and we
 can enable PI by default.
>>>
>>> The point isn't the pinning. The point is what pCPU they're on when
>>> going to sleep. And that could involve quite a few more than just
>>> 10 vCPU-s, provided they all sleep long enough.
>>>
>>> And the "theoretical performance regression is of no concern" is
>>> also not a proper way of looking at it, I would say: Even if such
>>> a situation would happen extremely rarely, if it can happen at all,
>>> it would still be a security issue.
>>
>> What I'm trying to get at is -- exactly what situation?  What actually
>> constitutes a problematic interrupt latency / interrupt processing
>> workload, how many vcpus must be sleeping on the same pcpu to actually
>> risk triggering that latency / workload, and how feasible is it that
>> such a situation would arise in a reasonable scenario?
>>
>> If 200us is too long, and it only takes 3 sleeping vcpus to get there,
>> then yes, there is a genuine problem we need to try to address before we
>> turn it on by default.  If we say that up to 500us is tolerable, and it
>> takes 100 sleeping vcpus to reach that latency, then this is something I
>> don't really think we need to worry about.
>>
>> "I think something bad may happen" is a really difficult to work with.
> 
> I understand that, but coming up with proper numbers here isn't
> easy. Fact is - it cannot be excluded that on a system with
> hundreds of pCPU-s and thousands or vCPU-s, that all vCPU-s
> would at some point pile up on one pCPU's list.

So it's already the case that when a vcpu is woken, it is inserted into
the runqueue by priority order, both for credit1 and credit2; and this
is an insertion sort, so the amount of time it takes to do the insert is
expected to be the time it takes to traverse half of the list.  This
isn't an exact analog, because in that case it's the number of
*runnable* vcpus, not the number of *blocked* vcpus; but it demonstrates
the point that 1) we already have code that assumes that walking a list
of vcpus per pcpu is a reasonably bounded thing 2) we have years of no
major performance problems reported to back that assumption up.

I guess the slight difference there is that it's already well-understood
that too many *active* vcpus will overload your system and slow things
down; in the case of the pi wake-ups, the problem is that too many
*inactive* vcpus will overload your system and slow things down.

Still -- I have a hard time constructing in my mind a scenario where
huge numbers of idle vcpus for some reason decide to congregate on a
single pcpu.

Suppose we had 1024 pcpus, and 1023 VMs each with 5 vcpus, of which 1
was spinning at 100% and the other 4 were 

Re: [Xen-devel] Xentrace on Xilinx ARM

[Andrew Cooper]

On 08/03/16 18:28, Paul Sujkov wrote:
> Hi Ben,
>
> looks like you've done everything I did. I'm far from my working
> laptop today, so I can post my work on this issue only tomorrow so you
> can look through the code, compare and estimate solutions.
>
> Regarding ARM build, I'm using xenalyze as both host tool (x86 build,
> e.g. for gnuplot scatterplot graphs) and target tool (ARM, for fast
> summary check); but since we're working with Xen 4.5, I'm building it
> outside Xen source tree with a custom Makefile.

xenalyse should be able to be run as a separate tool, and on a different
architecture.  All it does is annotate the binary trace file.

I don't think there is much change between what's now in-tree and what
was out of tree in the 4.5 timeframe.

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

Re: [Xen-devel] Xentrace on Xilinx ARM

[Paul Sujkov]

Hi Ben,

looks like you've done everything I did. I'm far from my working laptop
today, so I can post my work on this issue only tomorrow so you can look
through the code, compare and estimate solutions.

Regarding ARM build, I'm using xenalyze as both host tool (x86 build, e.g.
for gnuplot scatterplot graphs) and target tool (ARM, for fast summary
check); but since we're working with Xen 4.5, I'm building it outside Xen
source tree with a custom Makefile.

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

Re: [Xen-devel] Xentrace on Xilinx ARM

[Dario Faggioli]

On Tue, 2016-03-08 at 18:04 +, Ben Sanda wrote:
> All,
> 
> To update to the current situation. I have been able to get
> xentrace() and
> xenalyze working completely (at least as far as I can tell) on ARM.
> 
Great! :-)

> For xentrace there were changes to the memory allocation routines to
> allow
> mapping of the Xen Heap by dom0, correcting the MFN->PFN
> translations, adding
> the trace buffer initialization to setup.c (init_trace_bufs), and
> correcting the
> get_cycles() call to provide the system TSC. For the get_cycles()
> call I
> gathered that was supposed to return the raw tick count, not a
> translated
> ticks->real time timestamp. I then had to call xenalyze with the core
> frequency
> defined so the timestamps made sence.
> 
> Paul: Was there anything else you did I missed?
> 
Sorry, I can't really comment, as I know few about this part of the
tracing infra, and nothing about ARM.

I do encourage Paul to chime in, but, actually, that would probably be
even easier when we'll have the code posted.

So, you know as they say in Open Source, don't you: release early,
release often! :-)

> > It's not part of any Xen image. It's a command line tool to be
> > used, usually
> > but not necessarily, in dom0, build and installed together with the
> > other
> > tools... At least in my case, for x86 builds and installs. 
> For xenalyze I had to modify the makefile to build xenalyze on the
> ARM platform
> (it was specifically removed from the ARM build). Once that was
> corrected I
> could find and call it from dom0. 
>
Great again!

> It built only locally to Xen though (could
> only run from dom0), I could not use it from the native Linux
> development
> environment (I don't know if you're supposed to be able to? Or since
> I'm running
> ARM it built for ARM not x86 and thus could not be used natively).
> 
Yeah, well, if both dev and test environments are x86, I've done it a
couple of times, but I don't think its critical that we support that.

If architectures don't match, I actually think it is _the_right_thing_
that it does not work (as you say yourself)! :-)

> I plan to push they changes in as a patch to the mainline if that
> seems
> reasonable to everyone.
> 
Looking forward to it. :-)

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] Xentrace on Xilinx ARM

[Ben Sanda]

All,

To update to the current situation. I have been able to get xentrace() and
xenalyze working completely (at least as far as I can tell) on ARM.

For xentrace there were changes to the memory allocation routines to allow
mapping of the Xen Heap by dom0, correcting the MFN->PFN translations, adding
the trace buffer initialization to setup.c (init_trace_bufs), and correcting the
get_cycles() call to provide the system TSC. For the get_cycles() call I
gathered that was supposed to return the raw tick count, not a translated
ticks->real time timestamp. I then had to call xenalyze with the core frequency
defined so the timestamps made sence.

Paul: Was there anything else you did I missed?

>It's not part of any Xen image. It's a command line tool to be used, usually
>but not necessarily, in dom0, build and installed together with the other
>tools... At least in my case, for x86 builds and installs. 

For xenalyze I had to modify the makefile to build xenalyze on the ARM platform
(it was specifically removed from the ARM build). Once that was corrected I
could find and call it from dom0. It built only locally to Xen though (could
only run from dom0), I could not use it from the native Linux development
environment (I don't know if you're supposed to be able to? Or since I'm running
ARM it built for ARM not x86 and thus could not be used natively).

I plan to push they changes in as a patch to the mainline if that seems
reasonable to everyone.

Thanks,
Ben Sanda
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

[Dario Faggioli]

On Tue, 2016-03-08 at 14:05 +, George Dunlap wrote:
> On Tue, Mar 8, 2016 at 8:08 AM, Jan Beulich 
> wrote:
> > 
> > Right, and asking people myself to not follow bad examples when
> > adding new code, I did take all of your input to adjust the patch.
> > Just that in this case the set of bad examples is so large that in
> > a
> > similar case in the hypervisor I probably wouldn't have dared to
> > ask for a style correction.
> Well the approach of the libxl maintainers seems to have be, "Just
> make sure the new code adheres to the new style, and eventyally
> everything will be up-to-date".
>
Funnily enough, basing on my experience, libxl does not look that bad
to me, and every time I've been bitten by something like this, it was
in Xen rather than in libxl. :-D

Of course, although I've been active in both, I don't claim that my
experience is statistically significant... I guess it depends on what
specific areas of code one gets to work on.

Anyway, I personally don't think this affect in any way the point that
new code should comply as much as possible with coding style, existing
best practises, etc., and that is true for this patch, as well as for
all the times everyone of us may have been asked to do the same, either
in xen, tools, or anywhere...

In fact, especially if we decide to do this (which I'd be in favour of,
and up for helping):

> Given that the "new" style has been around for a while now, it
> probably would be good to set aside some time at the beginning of the
> next development cycle to fix things up
>
being strict about new code actually helps this, as it makes sure there
is less --rather than more-- code to fix during such a huge fixup
challenge! :-)

>  -- it is incredibly
> frustrating to carefully try to copy the surrounding style, only to
> be
> told to revise it.
> 
Yep, I fully agree.

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 2/2] xsm: move FLASK_AVC_STATS to Kconfig

[Daniel De Graaf]

On 03/08/2016 11:51 AM, Jan Beulich wrote:

On 08.03.16 at 17:22,  wrote:

On 03/08/2016 04:46 AM, Jan Beulich wrote:

On 07.03.16 at 19:42,  wrote:

Have Kconfig set CONFIG_FLASK_AVC_STATS and prefix all uses with CONFIG_
to use the Kconfig variable.


Same question here: What's the benefit of doing it this way?


This removes the stats tracking, which might (I have not tested) speed up
the security server by avoiding the __get_cpu_var call and increment.


No, I don not think the patch removes anything. The Kconfig option
doesn't have a prompt. But anyway, ...


Ah, I missed that: I saw the --help-- line and assumed it was the prompt.
Either way, this #define is a configuration-like knob that doesn't need to
be hard-coded in a header as it currently is.




The
corresponding SELinux knob is a Kconfig option in Linux.

Acked-by: Daniel De Graaf 


... if you're fine with it, we'll put it in (once the mechanical issues
got addressed).


--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH 1/4] x86/alternatives: correct near branch check

[Andrew Cooper]

On 07/03/16 16:21, Jan Beulich wrote:
 On 07.03.16 at 17:11,  wrote:
>> On 07/03/16 15:56, Jan Beulich wrote:
>> On 07.03.16 at 16:43,  wrote:
 On 04/03/16 11:27, Jan Beulich wrote:
> Make sure the near JMP/CALL check doesn't consume uninitialized
> data, not even in a benign way. And relax the length check at once.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -174,7 +174,7 @@ static void __init apply_alternatives(st
>  memcpy(insnbuf, replacement, a->replacementlen);
>  
>  /* 0xe8/0xe9 are relative branches; fix the offset. */
> -if ( (*insnbuf & 0xfe) == 0xe8 && a->replacementlen == 5 )
> +if ( a->replacementlen >= 5 && (*insnbuf & 0xfe) == 0xe8 )
>  *(s32 *)(insnbuf + 1) += replacement - instr;
>  
>  add_nops(insnbuf + a->replacementlen,
>
>
>
 Swapping the order is definitely a good thing.

 However, relaxing the length check seems less so.  `E8 rel32` or `E9
 rel32` encodings are strictly 5 bytes long.

 There are complications with the `67 E{8,9} rel16` encodings, but those
 are not catered for anyway, and the manual warns about undefined
 behaviour if used in long mode.

 What is your usecase for relaxing the check?  IMO, if it isn't exactly 5
 bytes long, there is some corruption somewhere and the relocation
 should't happen.
>>> The relaxation is solely because at least CALL could validly
>>> be followed by further instructions.
>> But without scanning the entire replacement buffer, there might be other
>> relocations needing to happen.
>>
>> That would require decoding the instructions, which is an extreme faff. 
>> It would be better to leave it currently as-is to effectively disallow
>> mixing a jmp/call replacement with other code, to avoid the subtle
>> failure of a second relocation not taking effect
> Well, such missing further fixup would be noticed immediately by
> someone trying (unless the patch code path never gets executed).
> Whereas a simply adjustment to register state would seem quite
> reasonable to follow a call. While right now the subsequent
> patches don't depend on this being >= or ==, I think it was wrong
> to be == from the beginning.
>
> Plus - there are endless other possibilities of instructions needing
> fixups (most notably such with RIP-relative memory operands),
> none of which are even remotely reasonable to deal with here.
> I.e. namely in the absence of a CALL/JMP the same issue would
> exist anyway, which is why I'm not overly concerned of those.
> All we want is a specific special case to be treated correctly.

Fair enough.  Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling

[Jan Beulich]

>>> On 08.03.16 at 18:05,  wrote:
> On 08/03/16 15:42, Jan Beulich wrote:
> On 08.03.16 at 15:42,  wrote:
>>> On Tue, Mar 8, 2016 at 1:10 PM, Wu, Feng  wrote:
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
>
> 2. Try to test engineered situations where we expect this to be a
> problem, to see how big of a problem it is (proving the theory to be
> accurate or inaccurate in this case)

 Maybe we can run a SMP guest with all the vcpus pinned to a dedicated
 pCPU, we can run some benchmark in the guest with VT-d PI and without
 VT-d PI, then see the performance difference between these two sceanrios.
>>>
>>> This would give us an idea what the worst-case scenario would be.
>> 
>> How would a single VM ever give us an idea about the worst
>> case? Something getting close to worst case is a ton of single
>> vCPU guests all temporarily pinned to one and the same pCPU
>> (could be multi-vCPU ones, but the more vCPU-s the more
>> artificial this pinning would become) right before they go into
>> blocked state (i.e. through one of the two callers of
>> arch_vcpu_block()), the pinning removed while blocked, and
>> then all getting woken at once.
> 
> Why would removing the pinning be important?

It's not important by itself, other than to avoid all vCPU-s then
waking up on the one pCPU.

> And I guess it's actually the case that it doesn't need all VMs to
> actually be *receiving* interrupts; it just requires them to be
> *capable* of receiving interrupts, for there to be a long chain all
> blocked on the same physical cpu.

Yes.

>>>  But
>>> pinning all vcpus to a single pcpu isn't really a sensible use case we
>>> want to support -- if you have to do something stupid to get a
>>> performance regression, then I as far as I'm concerned it's not a
>>> problem.
>>>
>>> Or to put it a different way: If we pin 10 vcpus to a single pcpu and
>>> then pound them all with posted interrupts, and there is *no*
>>> significant performance regression, then that will conclusively prove
>>> that the theoretical performance regression is of no concern, and we
>>> can enable PI by default.
>> 
>> The point isn't the pinning. The point is what pCPU they're on when
>> going to sleep. And that could involve quite a few more than just
>> 10 vCPU-s, provided they all sleep long enough.
>> 
>> And the "theoretical performance regression is of no concern" is
>> also not a proper way of looking at it, I would say: Even if such
>> a situation would happen extremely rarely, if it can happen at all,
>> it would still be a security issue.
> 
> What I'm trying to get at is -- exactly what situation?  What actually
> constitutes a problematic interrupt latency / interrupt processing
> workload, how many vcpus must be sleeping on the same pcpu to actually
> risk triggering that latency / workload, and how feasible is it that
> such a situation would arise in a reasonable scenario?
> 
> If 200us is too long, and it only takes 3 sleeping vcpus to get there,
> then yes, there is a genuine problem we need to try to address before we
> turn it on by default.  If we say that up to 500us is tolerable, and it
> takes 100 sleeping vcpus to reach that latency, then this is something I
> don't really think we need to worry about.
> 
> "I think something bad may happen" is a really difficult to work with.

I understand that, but coming up with proper numbers here isn't
easy. Fact is - it cannot be excluded that on a system with
hundreds of pCPU-s and thousands or vCPU-s, that all vCPU-s
would at some point pile up on one pCPU's list.

How many would be tolerable on a single list depends upon host
characteristics, so a fixed number won't do anyway. Hence I
think the better approach, instead of improving lookup, is to
distribute vCPU-s evenly across lists. Which in turn would likely
require those lists to no longer be tied to pCPU-s, an aspect I
had already suggested during review. As soon as distribution
would be reasonably even, the security concern would vanish:
Someone placing more vCPU-s on a host than that host can
handle is responsible for the consequences. Quite contrary to
someone placing more vCPU-s on a host than a single pCPU can
reasonably handle in an interrupt handler.

Jan

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

Re: [Xen-devel] [PATCH v11 20/27] Support colo mode for qemu disk

[Wei Liu]

On Mon, Mar 07, 2016 at 10:10:07AM +0800, Wen Congyang wrote:
> On 03/05/2016 04:30 AM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Mar 04, 2016 at 05:52:09PM +, Ian Jackson wrote:
> >> Changlong Xie writes ("[PATCH v11 20/27] Support colo mode for qemu disk"):
> >>> +Enable COLO HA for disk. For better understanding block replication on
> >>> +QEMU, please refer to:
> >>> +http://wiki.qemu.org/Features/BlockReplication
> >>
> >> Sorry, I missed this link on my first pass.  I still think that at the
> >> very least this needs something more user-facing (ie, how should one
> >> set this up).
> >>
> >> But, I'm kind of worried that qemu is the wrong place to be doing
> >> this.
> >>
> >> How can this be made to work with PV guests ?
> > 
> > QEMU can also serve PV guests (qdisk).
> > 
> > I think your question is more of - what about making this work with
> > PV block backend?
> 
> I don't know how to work with PV block backend. It is one reason that
> why we only support pure HVM now.
> For PV block backend, there is also other problem. For exampe resuming
> it in the secondary side is very slow, because we need to disconnect and
> reconnect.
> 

Supporting PV guest is certainly going to be non-trivial. And I don't
think we would ever ask you to actually implement that.

The point is to have a story that when other people want to implement
COLO for PV-aware guests (PVHVM, PV and PVH), they are not crippled by
existing interfaces.

Currently the disk spec seems to be designed exclusively for QEMU. This
is not very desirable, but at least it wouldn't stop people from either
reusing them or inventing new parameters.

Furthermore, I think coming up with a story for PV-aware guests (PVHVM,
PV and PVH) is also non-trivial. For one the disk replication logic is
not implemented in PV block backend,  we're not sure how feasible to
replicate thing in QEMU into kernel, but we're quite sure it is not
going to be trivial technically and politically. The uncertainty is too
big to come up with a clear idea what it would look like.

Wei.

> Thanks
> Wen Congyang
> 
> >>
> >> What if an HVM guest has PV-on-HVM drivers ?  In this case there might
> >> be two relevant qemus, one for the qdisk Xen PV block backend, and one
> >> for the emulated IDE.
> > 
> > In both cases QEMU would use the same underlaying API to actually write/read
> > out the blocks. That API would then use NBD, etc to replicate writes.
> > 
> > Maybe a little ASCII art?
> > 
> > qdisk  ide
> >   \/
> >\  /
> >block API
> > |
> >QCOW2
> > |
> >NBD
> > 
> > Or such?
> > 
> >>
> >> I don't understand how discrepant writes are detected.  Surely they
> >> might occur and should trigger a resynch ?
> >>
> >> Ian.
> > 
> > 
> > .
> > 
> 
> 
> 

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

Re: [Xen-devel] [PATCH v3 6/6] libxl: add force option for xl vcpu-pin

[Juergen Gross]

On 08/03/16 18:16, Dario Faggioli wrote:
> On Thu, 2016-03-03 at 17:48 +0100, Juergen Gross wrote:
>> In order to be able to undo a vcpu pin override in case of a kernel
>> driver error add a flag "-f" to the "xl vcpu-pin" command forcing the
>> hypervisor to undo the override.
>>
>> Cc: Ian Jackson 
>> Cc: Stefano Stabellini 
>> Cc: Wei Liu 
>> Signed-off-by: Juergen Gross 
>> ---
>>  tools/libxl/libxl.c   | 31 +--
>>  tools/libxl/libxl.h   |  4 
>>  tools/libxl/xl_cmdimpl.c  | 27 +++
>>  tools/libxl/xl_cmdtable.c |  3 ++-
>>
> Actually, there's something I always forget when reviewing xl stuff,
> which is that the xl manpage should be modified as well.

Yeah, I already thought of this, too.

Will add it.


Juergen

> 
> Sorry for (nearly) missing this! :-/
> 
> Regards,
> Dario
> 


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

Re: [Xen-devel] [PATCH v3 6/6] libxl: add force option for xl vcpu-pin

[Dario Faggioli]

On Thu, 2016-03-03 at 17:48 +0100, Juergen Gross wrote:
> In order to be able to undo a vcpu pin override in case of a kernel
> driver error add a flag "-f" to the "xl vcpu-pin" command forcing the
> hypervisor to undo the override.
> 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Wei Liu 
> Signed-off-by: Juergen Gross 
> ---
>  tools/libxl/libxl.c   | 31 +--
>  tools/libxl/libxl.h   |  4 
>  tools/libxl/xl_cmdimpl.c  | 27 +++
>  tools/libxl/xl_cmdtable.c |  3 ++-
>
Actually, there's something I always forget when reviewing xl stuff,
which is that the xl manpage should be modified as well.

Sorry for (nearly) missing this! :-/

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] [RESEND][PATCH V16 4/6] libxl: add pvusb API

[George Dunlap]

On 08/03/16 01:37, Chunyan Liu wrote:
> 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
> 
> Signed-off-by: Simon Cao 
> Signed-off-by: George Dunlap 
> Signed-off-by: Chunyan Liu 

Reviewed-by: George Dunlap 

Good work!

 -George

> ---
> Changes:
>   * Address George's comments
> 
>  tools/libxl/Makefile |3 +-
>  tools/libxl/libxl.c  |   18 +
>  tools/libxl/libxl.h  |   77 ++
>  tools/libxl/libxl_device.c   |5 +-
>  tools/libxl/libxl_internal.h |   18 +
>  tools/libxl/libxl_osdeps.h   |   13 +
>  tools/libxl/libxl_pvusb.c| 1620 
> ++
>  tools/libxl/libxl_types.idl  |   46 +
>  tools/libxl/libxl_types_internal.idl |1 +
>  tools/libxl/libxl_utils.c|   18 +
>  tools/libxl/libxl_utils.h|5 +
>  11 files changed, 1822 insertions(+), 2 deletions(-)
>  create mode 100644 tools/libxl/libxl_pvusb.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 789a12e..8fa7b87 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -105,7 +105,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o 
> libxl_dm.o libxl_pci.o \
>   libxl_stream_read.o libxl_stream_write.o \
>   libxl_save_callout.o _libxl_save_msgs_callout.o \
>   libxl_qmp.o libxl_event.o libxl_fork.o \
> - libxl_dom_suspend.o libxl_dom_save.o $(LIBXL_OBJS-y)
> + libxl_dom_suspend.o libxl_dom_save.o libxl_pvusb.o \
> +$(LIBXL_OBJS-y)
>  LIBXL_OBJS += libxl_genid.o
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
>  
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 2ab5ad3..1e68688 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4102,6 +4102,8 @@ out:
>   * libxl_device_vkb_destroy
>   * libxl_device_vfb_remove
>   * libxl_device_vfb_destroy
> + * libxl_device_usbctrl_remove
> + * libxl_device_usbctrl_destroy
>   */
>  #define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\
>  int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
> @@ -4159,6 +4161,10 @@ DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
>  DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
>  DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
>  
> +/* usbctrl */
> +DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, remove, 0)
> +DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, destroy, 1)
> +
>  /* channel/console hotunplug is not implemented. There are 2 possibilities:
>   * 1. add support for secondary consoles to xenconsoled
>   * 2. dynamically add/remove qemu chardevs via qmp messages. */
> @@ -4174,6 +4180,8 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
>   * libxl_device_disk_add
>   * libxl_device_nic_add
>   * libxl_device_vtpm_add
> + * libxl_device_usbctrl_add
> + * libxl_device_usbdev_add
>   */
>  
>  #define DEFINE_DEVICE_ADD(type) \
> @@ -4205,6 +4213,12 @@ DEFINE_DEVICE_ADD(nic)
>  /* vtpm */
>  DEFINE_DEVICE_ADD(vtpm)
>  
> +/* usbctrl */
> +DEFINE_DEVICE_ADD(usbctrl)
> +
> +/* usb */
> +DEFINE_DEVICE_ADD(usbdev)
> +
>  #undef DEFINE_DEVICE_ADD
>  
>  
> /**/
> @@ -6750,6 +6764,10 @@ int libxl_retrieve_domain_configuration(libxl_ctx 
> *ctx, uint32_t domid,
>  
>  MERGE(pci, pcidevs, COMPARE_PCI, {});
>  
> +MERGE(usbctrl, usbctrls, COMPARE_USBCTRL, {});
> +
> +MERGE(usbdev, usbdevs, COMPARE_USB, {});
> +
>  /* Take care of removable device. We maintain invariant in the
>   * insert / remove operation so that:
>   * 1. if xenstore is "empty" while JSON is not, the result
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 0859383..5cc3ce3 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -123,6 +123,12 @@
>  #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
>  
>  /*
> + * LIBXL_HAVE_PVUSB indicates functions for plugging in USB devices
> + * through pvusb -- both hotplug and at domain creation time..
> + */
> +#define LIBXL_HAVE_PVUSB 1
> +
> +/*
>   * LIBXL_HAVE_BUILDINFO_HVM_VENDOR_DEVICE indicates that the
>   * libxl_vendor_device field is present in the hvm sections of
>   * libxl_domain_build_info. This field tells libxl which
> @@ -1536,6 +1542,77 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, 
> libxl_device_disk *disk,
> const libxl_asyncop_how *ao_how)
> LIBXL_EXTERNAL_CALLERS_ONLY;
>  
> +/*
> + * USB
> + *
> + * For each device removed or added, one of these protocols is available:
> + * - PV (i.e., PVUSB)
> + * - DEVICEMODEL (i.e, qemu)
> + *
> + * PV is available for either 

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

[Andrei Borzenkov]

08.03.2016 19:37, Fu Wei пишет:
> Hi Andrei,
> 
> On 8 March 2016 at 14:54, Andrei Borzenkov  wrote:
>> 07.03.2016 11:22, Fu Wei пишет:
>>> Hi Andrei,
>>>
>>> On 28 February 2016 at 00:44, Fu Wei  wrote:
 Hi Andrei

 On 28 February 2016 at 01:26, Andrei Borzenkov  wrote:
> 26.02.2016 14:13, fu@linaro.org пишет:
>> From: Fu Wei 
>>
>> delete: xen_linux, xen_initrd, xen_xsm
>> add: xen_module
>>
>> This update bases on
>> commit 0edd750e50698854068358ea53528100a9192902
>> Author: Vladimir Serbinenko 
>> Date:   Fri Jan 22 10:18:47 2016 +0100
>>
>> xen_boot: Remove obsolete module type distinctions.
>>
>> Signed-off-by: Fu Wei 
>> ---
>>  docs/grub.texi | 33 ++---
>>  1 file changed, 10 insertions(+), 23 deletions(-)
>>
>> diff --git a/docs/grub.texi b/docs/grub.texi
>> index 82f6fa4..3fbdd99 100644
>> --- a/docs/grub.texi
>> +++ b/docs/grub.texi
>> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command 
>> @command{help}
>>  * 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
>> +* xen_module::  Load xen modules for xen hypervisor
>>  @end menu
>>
>>
>> @@ -5141,30 +5139,19 @@ 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
>> +@node xen_module
>> +@subsection xen_module
>>
>> -@deffn Command xen_linux file [arguments]
>> -Load a dom0 kernel image for xen hypervisor at the booting process of 
>> xen.
>> +@deffn Command xen_module [--nounzip] file [arguments]
>> +Load a module for xen hypervisor at the booting process of xen.
>>  The rest of the line is passed verbatim as the module command line.
>
> ==
>> +On i386,  the modules will be identified by Multiboot(2) protocol.
>> +On arm64, each module will be identified by the order in which the
>> +modules are added.
>
> I think it is better to skip it entirely. It is not really correct -
> neither multiboot protocol provides any module identification (Xen
> probes module types), nor is i386 using multiboot2, nor can all modules
> be probed, so order still matters. To avoid confusion I'd simply
> replaced the above three lines with
>
> Modules should be loaded in the following order:
>
>> +The 1st module: dom0 kernel image
>> +The 2nd module: dom0 ramdisk (optional)
>
> This covers both supported platforms without going into too deep
> details; if you and Vladimir are OK, I'll commit with this change.

 Thank you very much!
 Sorry I am not familiar with xen on i386, so maybe I misunderstand this.
 So please commit with your change, Thanks for your correction :-)
>>>
>>> I just fetched the mainline GRUB, i would like to know why this
>>> patchset haven't been applied?
>>> Anything I need to do(improve it or post a new patchset according to
>>> your suggestion) for this patchset?
>>>
>>
>> Sorry for delay. It is not really about your patchset, but we need some
>> decision about loading additional modules/lack of initrd on ARM. Until
>> then I'd rather avoid committing to any high-level configuration support
>> that will require even more backward compatible hacks later.
>>
>> As it stands now either Xen needs to support autodetection or we need to
>> revert to providing module type explicitly.
> 
> So speaking of loading additional modules/lack of initrd on ARM, I thinks that
> will (only) affect loading XSM.
> For this, I have discussed of that with Julien, I think :
> (1) the first module must be kernel
> (2) the second module must be initrd, if we have initrd
> (3) Start from the 2nd module, XEN will detect that if the module is a XSM by
> the XSM binary signature. if we get XSM as the second module, that
> means we have not initrd.
> 

If that's the plan, excellent. Vladimir, is it OK to commit then?

> please correct me if I misunderstand it
> 
> :-)
> 


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

Re: [Xen-devel] Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling

[George Dunlap]

On 08/03/16 15:42, Jan Beulich wrote:
 On 08.03.16 at 15:42,  wrote:
>> On Tue, Mar 8, 2016 at 1:10 PM, Wu, Feng  wrote:
 -Original Message-
 From: George Dunlap [mailto:george.dun...@citrix.com]
>> [snip]
 It seems like there are a couple of ways we could approach this:

 1. Try to optimize the reverse look-up code so that it's not a linear
 linked list (getting rid of the theoretical fear)
>>>
>>> Good point.
>>>

 2. Try to test engineered situations where we expect this to be a
 problem, to see how big of a problem it is (proving the theory to be
 accurate or inaccurate in this case)
>>>
>>> Maybe we can run a SMP guest with all the vcpus pinned to a dedicated
>>> pCPU, we can run some benchmark in the guest with VT-d PI and without
>>> VT-d PI, then see the performance difference between these two sceanrios.
>>
>> This would give us an idea what the worst-case scenario would be.
> 
> How would a single VM ever give us an idea about the worst
> case? Something getting close to worst case is a ton of single
> vCPU guests all temporarily pinned to one and the same pCPU
> (could be multi-vCPU ones, but the more vCPU-s the more
> artificial this pinning would become) right before they go into
> blocked state (i.e. through one of the two callers of
> arch_vcpu_block()), the pinning removed while blocked, and
> then all getting woken at once.

Why would removing the pinning be important?

And I guess it's actually the case that it doesn't need all VMs to
actually be *receiving* interrupts; it just requires them to be
*capable* of receiving interrupts, for there to be a long chain all
blocked on the same physical cpu.

> 
>>  But
>> pinning all vcpus to a single pcpu isn't really a sensible use case we
>> want to support -- if you have to do something stupid to get a
>> performance regression, then I as far as I'm concerned it's not a
>> problem.
>>
>> Or to put it a different way: If we pin 10 vcpus to a single pcpu and
>> then pound them all with posted interrupts, and there is *no*
>> significant performance regression, then that will conclusively prove
>> that the theoretical performance regression is of no concern, and we
>> can enable PI by default.
> 
> The point isn't the pinning. The point is what pCPU they're on when
> going to sleep. And that could involve quite a few more than just
> 10 vCPU-s, provided they all sleep long enough.
> 
> And the "theoretical performance regression is of no concern" is
> also not a proper way of looking at it, I would say: Even if such
> a situation would happen extremely rarely, if it can happen at all,
> it would still be a security issue.

What I'm trying to get at is -- exactly what situation?  What actually
constitutes a problematic interrupt latency / interrupt processing
workload, how many vcpus must be sleeping on the same pcpu to actually
risk triggering that latency / workload, and how feasible is it that
such a situation would arise in a reasonable scenario?

If 200us is too long, and it only takes 3 sleeping vcpus to get there,
then yes, there is a genuine problem we need to try to address before we
turn it on by default.  If we say that up to 500us is tolerable, and it
takes 100 sleeping vcpus to reach that latency, then this is something I
don't really think we need to worry about.

"I think something bad may happen" is a really difficult to work with.
"I want to make sure that even a high number of blocked cpus won't cause
the interrupt latency to exceed 500us; and I want it to be basically
impossible for the interrupt latency to exceed 5ms under any
circumstances" is a concrete target someone can either demonstrate that
they meet, or aim for when trying to improve the situation.

Feng: It should be pretty easy for you to:
* Implement a modified version of Xen where
 - *All* vcpus get put on the waitqueue
 - Measure how long it took to run the loop in pi_wakeup_interrupt
* Have one VM receiving posted interrupts on a regular basis.
* Slowly increase the number of vcpus blocked on a single cpu (e.g., by
creating more guests), stopping when you either reach 500us or 500
vcpus. :-)

To report the measurements, you could either create a Xen trace record
and use xentrace_format or xenalyze to plot the results; or you could
create some software performance counters for different "buckets" --
less than 100us, 100-200us, 200-300us, 300-400us, 400-500us, and more
than 500us.

Or you could printk the min / average / max every 5000 interrupts or so. :-)

To test, it seems like using a network benchmark with short packet
lengths should be able to trigger large numbers of interrupts; and it
also can let you know if / when there's a performance impact of adding
more vcpus.

Or alternately, you could try to come up with a quicker reverse-lookup
algorithm. :-)

 -George


___
Xen-devel mailing list
Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH 2/2] xsm: move FLASK_AVC_STATS to Kconfig

[Jan Beulich]

>>> On 08.03.16 at 17:22,  wrote:
> On 03/08/2016 04:46 AM, Jan Beulich wrote:
> On 07.03.16 at 19:42,  wrote:
>>> Have Kconfig set CONFIG_FLASK_AVC_STATS and prefix all uses with CONFIG_
>>> to use the Kconfig variable.
>>
>> Same question here: What's the benefit of doing it this way?
> 
> This removes the stats tracking, which might (I have not tested) speed up
> the security server by avoiding the __get_cpu_var call and increment.

No, I don not think the patch removes anything. The Kconfig option
doesn't have a prompt. But anyway, ...

> The
> corresponding SELinux knob is a Kconfig option in Linux.
> 
> Acked-by: Daniel De Graaf 

... if you're fine with it, we'll put it in (once the mechanical issues
got addressed).

Jan


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

Re: [Xen-devel] [PATCH 2/2] tools: detect appropriate debug optimization level

[Wei Liu]

On Tue, Mar 08, 2016 at 10:34:42AM -0600, Doug Goldstein wrote:
> On 3/8/16 9:38 AM, Wei Liu wrote:
> > On Mon, Mar 07, 2016 at 08:23:40PM -0600, Doug Goldstein wrote:
> >> The build should not use -O0 as that results in miscompilations. There
> > 
> > This needs some (concrete) references. Is that a known issue in gcc? If
> > so can you reference the bug number?
> 
> So its not really a bug in GCC but just the complete lack of
> optimizations in play. inlines aren't inlined. dead code elimination
> isn't run so things are much bigger. structures aren't padded the same way.
> 

Urgh...

> This came about from reading reports on the -devel and -user's ML that
> were solved by building Xen with debug=n. I was also striving to reduce
> the duplication of CFLAGS that are passed on the command line of builds.
> 

I agree this is a good idea.

> > 
> >> have been a few instances on the ML where users were told to switch
> >> from -O0 to -O1 or -O2 or to set debug=n and their issue went away. The
> >> preferred route should be to use -Og if its available, otherwise use
> >> -O1 which is the default. This change undoes the change from -O1 to -O0
> > 
> > gcc manual says -O0 is the default.
> 
> I wasn't clear about where the 'the default' came from. That's the
> default in the Xen tree (see: config/StdGNU.mk for example but every
> platform has -O1 set).
> 

OK. I thought you're talking about something in the manual.

> > 
> > Not that I disagree with this patch in general, but the commit message
> > seems a bit misleading.
> 
> I can rewrite it. I'd also be willing to change the patch to prefer -Og
> if its available and use -O0 if its not.
> 

No need to do it now because ...

> > 
> >> in 1166ecf781b1016eaa61f8d5ba4fb1fde9d599b6.
> >>
> > 
> > And I have no idea why -O1 confuses the debugger so I've CC'ed Euan for
> > more input.
> 
> -O1 can optimize things out when you look at them with gdb but -Og is
> suppose to do the right thing.
> 

.. I don't know much about gcc so I would like to wait for Ian to give
some input.

Wei.

> > 
> >> Signed-off-by: Doug Goldstein 
> >> ---
> >> CC: Ian Jackson 
> >> CC: Stefano Stabellini 
> >> CC: Wei Liu 
> >> ---
> >>  tools/Rules.mk | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/tools/Rules.mk b/tools/Rules.mk
> >> index 9ef0b47..ae6b01f 100644
> >> --- a/tools/Rules.mk
> >> +++ b/tools/Rules.mk
> >> @@ -137,7 +137,8 @@ SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) 
> >> -Wl,-rpath-link=$(XEN_LIBVCHAN)
> >>  
> >>  ifeq ($(debug),y)
> >>  # Disable optimizations and enable debugging information for macros
> >> -CFLAGS += -O0 -g3
> >> +$(call cc-option-add,CFLAGS,CC,-Og)
> >> +CFLAGS += -g3
> >>  # But allow an override to -O0 in case Python enforces 
> >> -D_FORTIFY_SOURCE=.
> >>  PY_CFLAGS += $(PY_NOOPT_CFLAGS)
> >>  endif
> >> -- 
> >> 2.4.10
> >>
> 
> 
> -- 
> Doug Goldstein
> 




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

Re: [Xen-devel] [PATCH v11 19/27] COLO: introduce new API to prepare/start/do/get_error/stop replication

[Wei Liu]

On Fri, Mar 04, 2016 at 05:26:44PM +, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v11 19/27] COLO: introduce new API to 
> prepare/start/do/get_error/stop replication"):
> > From: Wen Congyang 
> > 
> > We will use qemu block replication, and qemu provides some qmp commands
> > to prepare replication, start replication, get replication error, and
> > stop replication. Introduce new API to execute these qmp commands.
> 
> How will this work if in future we want to support HVM (or
> hvm-lite-ng) guests ?
> 

Just to clarify things: all the new functions in this patch are internal
to libxl. So they have no implication on how PVHv2 COLO is implemented
-- it probably won't be using all these functions anyway.

Wei.

> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index 5160939..8cb9f19 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -1771,6 +1771,26 @@ _hidden int
> > libxl__qmp_set_global_dirty_log(libxl__gc ...
> > +_hidden int libxl__qmp_nbd_server_add(libxl__gc *gc, int domid, const char 
> > *disk);
> 
> It's a tiny nit, but can I grumble about the long lines here ?  Less
> than ~70-75 characters is best.
> 
> Thanks,
> Ian.

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

Re: [Xen-devel] [PATCH v11 07/27] docs/libxl: Introduce CHECKPOINT_CONTEXT to support migration v2 colo streams

[Wei Liu]

On Fri, Mar 04, 2016 at 04:51:20PM +, Ian Jackson wrote:
[...]
> 
> > @@ -212,6 +214,11 @@ class VerifyLibxl(VerifyBase):
> >  if len(content) != 0:
> >  raise RecordError("Checkpoint end record with non-zero length")
> >  
> > +def verify_record_checkpoint_state(self, content):
> > +""" Checkpoint state """
> > +if len(content) == 0:
> > +raise RecordError("Checkpoint state record with zero length")
> > +
> 
> I'm not verify familiar with this area of the code, but I think that
> this should probably check that the control_id is as expected.  Can it
> know what the right sequencing is ?
> 

FWIW this script is not used in live system -- so it probably doesn't
have information on the control id and the sequence on a live system.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH v11 03/27] tools/libxl: Add back channel to allow migration target send data back

[Wei Liu]

On Fri, Mar 04, 2016 at 04:38:23PM +, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v11 03/27] tools/libxl: Add back channel to 
> allow migration target send data back"):
> > From: Wen Congyang 
> > 
> > In COLO mode, secondary needs to send the following data to primary:
> > 1. In libxl
> >Secondary sends the following CHECKPOINT_CONTEXT to primary:
> >CHECKPOINT_SVM_SUSPENDED, CHECKPOINT_SVM_READY and CHECKPOINT_SVM_RESUMED
> > 2. In libxc
> >Secondary sends the dirty pfn list to primary
> 
> The overall API approach here seems good to me.
> 
> But, my reading of the code is that this new fd is currently ignored.
> This is, AFAICT, intentional in the non-colo case, and we have no colo
> case yet.
> 
> So I think that this new parameter needs to be slightly better
> documented.  I suggest:
> 
>  * In this patch, add a comment next to it saying "always pass -1".
>  * In the patch were the fd actually starts to do something, change
> this comment to something more meaningful.
> 
> >  /*
> > + * LIBXL_HAVE_DOMAIN_CREATE_RESTORE_SEND_BACK_FD 1
> > + *
> > + * If this is defined, libxl_domain_create_restore()'s API has changed to
> > + * include a send_back_fd param which used for libxl migration back channel
> > + * during COLO.
> > + */
> > +#define LIBXL_HAVE_DOMAIN_CREATE_RESTORE_SEND_BACK_FD 1
> 
> I have a minor grammar quibble with this.  I would write:
> 
>   "If this is defined, libxl_domain_create_restore()'s API
>includes the send_back_fd param.  This is used only with
>COLO, for the libxl migration back channel; other callers
>should pass -1."
> 
> And, with this definition of the API, I think that the code should
> actually check that -1 is passed.  Personally I would be happy with
> the error case either failing assert() or returning ERROR_INVAL, but
> maybe other maintainers have a specific view.
> 

I have no preference on this issue. Either calling assert or
returning ERROR_INVAL is fine by me.

Wei.

> Ian.

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

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

[Fu Wei]

Hi Andrei,

On 8 March 2016 at 14:54, Andrei Borzenkov  wrote:
> 07.03.2016 11:22, Fu Wei пишет:
>> Hi Andrei,
>>
>> On 28 February 2016 at 00:44, Fu Wei  wrote:
>>> Hi Andrei
>>>
>>> On 28 February 2016 at 01:26, Andrei Borzenkov  wrote:
 26.02.2016 14:13, fu@linaro.org пишет:
> From: Fu Wei 
>
> delete: xen_linux, xen_initrd, xen_xsm
> add: xen_module
>
> This update bases on
> commit 0edd750e50698854068358ea53528100a9192902
> Author: Vladimir Serbinenko 
> Date:   Fri Jan 22 10:18:47 2016 +0100
>
> xen_boot: Remove obsolete module type distinctions.
>
> Signed-off-by: Fu Wei 
> ---
>  docs/grub.texi | 33 ++---
>  1 file changed, 10 insertions(+), 23 deletions(-)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 82f6fa4..3fbdd99 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command 
> @command{help}
>  * 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
> +* xen_module::  Load xen modules for xen hypervisor
>  @end menu
>
>
> @@ -5141,30 +5139,19 @@ 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
> +@node xen_module
> +@subsection xen_module
>
> -@deffn Command xen_linux file [arguments]
> -Load a dom0 kernel image for xen hypervisor at the booting process of 
> xen.
> +@deffn Command xen_module [--nounzip] file [arguments]
> +Load a module for xen hypervisor at the booting process of xen.
>  The rest of the line is passed verbatim as the module command line.

 ==
> +On i386,  the modules will be identified by Multiboot(2) protocol.
> +On arm64, each module will be identified by the order in which the
> +modules are added.

 I think it is better to skip it entirely. It is not really correct -
 neither multiboot protocol provides any module identification (Xen
 probes module types), nor is i386 using multiboot2, nor can all modules
 be probed, so order still matters. To avoid confusion I'd simply
 replaced the above three lines with

 Modules should be loaded in the following order:

> +The 1st module: dom0 kernel image
> +The 2nd module: dom0 ramdisk (optional)

 This covers both supported platforms without going into too deep
 details; if you and Vladimir are OK, I'll commit with this change.
>>>
>>> Thank you very much!
>>> Sorry I am not familiar with xen on i386, so maybe I misunderstand this.
>>> So please commit with your change, Thanks for your correction :-)
>>
>> I just fetched the mainline GRUB, i would like to know why this
>> patchset haven't been applied?
>> Anything I need to do(improve it or post a new patchset according to
>> your suggestion) for this patchset?
>>
>
> Sorry for delay. It is not really about your patchset, but we need some
> decision about loading additional modules/lack of initrd on ARM. Until
> then I'd rather avoid committing to any high-level configuration support
> that will require even more backward compatible hacks later.
>
> As it stands now either Xen needs to support autodetection or we need to
> revert to providing module type explicitly.

So speaking of loading additional modules/lack of initrd on ARM, I thinks that
will (only) affect loading XSM.
For this, I have discussed of that with Julien, I think :
(1) the first module must be kernel
(2) the second module must be initrd, if we have initrd
(3) Start from the 2nd module, XEN will detect that if the module is a XSM by
the XSM binary signature. if we get XSM as the second module, that
means we have not initrd.

please correct me if I misunderstand it

:-)

-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

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

Re: [Xen-devel] [libvirt] [PATCH V2 3/4] Xen drivers: show hap enabled by default in capabilities

[Joao Martins]

On 03/01/2016 04:00 AM, Jim Fehlig wrote:
> Hardware Assisted Paging is enabled by default in Xen. Change
> the capabilities output to reflect this.
> 
> Signed-off-by: Jim Fehlig 
> ---
>  src/libxl/libxl_conf.c   | 2 +-
>  src/xen/xen_hypervisor.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index 93c943b..6efd9b5 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -493,7 +493,7 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCapsPtr caps)
>  
>  if (virCapabilitiesAddGuestFeature(guest,
> "hap",
> -   0,
> +   1,
> 1) == NULL)
>  return -1;
>  }
> diff --git a/src/xen/xen_hypervisor.c b/src/xen/xen_hypervisor.c
> index c1834cb..fc9e1c6 100644
> --- a/src/xen/xen_hypervisor.c
> +++ b/src/xen/xen_hypervisor.c
> @@ -2206,7 +2206,7 @@ xenHypervisorBuildCapabilities(virConnectPtr conn, 
> virArch hostarch,
>  if ((hv_major == 3 && hv_minor >= 3) || (hv_major > 3))
>  if (virCapabilitiesAddGuestFeature(guest,
> "hap",
> -   false,
> +   true,
> true) == NULL)
>  goto no_memory;
>  
> 

For the libxl part,

Reviewed-by: Joao Martins 

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

Re: [Xen-devel] [libvirt] [PATCH V2 4/4] libxl: support enabling and disabling feature

[Joao Martins]

On 03/01/2016 04:00 AM, Jim Fehlig wrote:
> Until now, the libxl driver ignored any  setting in domain XML
> and deferred to libxl, which enables hap if not specified. While
> this is a good default, it prevents disabling hap if desired.
> 
> This change allows disabling hap with . hap is
> explicitly enabled with  or 

Re: [Xen-devel] [libvirt] [PATCH V2 2/4] xenconfig: change 'hap' setting to align with Xen behavior

[Joao Martins]

On 03/01/2016 04:00 AM, Jim Fehlig wrote:
> hap is enabled by default in xm and xl config and usually only
> specified when it is desirable to disable hap (hap = 0). Change
> the xm,xl <-> xml converter to behave similarly. I.e. only
> produce 'hap = 0' when  and vice versa.
> 
> Signed-off-by: Jim Fehlig 
> ---
>  src/xenconfig/xen_common.c | 14 ++---
>  .../test-disk-positional-parms-full.cfg|  1 -
>  .../test-disk-positional-parms-partial.cfg |  1 -
>  ...est-fullvirt-direct-kernel-boot-bogus-extra.cfg |  1 -
>  .../test-fullvirt-direct-kernel-boot-extra.cfg |  1 -
>  .../test-fullvirt-direct-kernel-boot.cfg   |  1 -
>  tests/xlconfigdata/test-fullvirt-multiusb.cfg  |  1 -
>  tests/xlconfigdata/test-fullvirt-nohap.cfg | 26 ++
>  tests/xlconfigdata/test-fullvirt-nohap.xml | 59 
> ++
>  tests/xlconfigdata/test-new-disk.cfg   |  1 -
>  tests/xlconfigdata/test-rbd-multihost-noauth.cfg   |  1 -
>  tests/xlconfigdata/test-spice-features.cfg |  1 -
>  tests/xlconfigdata/test-spice.cfg  |  1 -
>  tests/xlconfigdata/test-vif-rate.cfg   |  1 -
>  tests/xlconfigtest.c   |  1 +
>  tests/xmconfigdata/test-escape-paths.cfg   |  1 -
>  .../xmconfigdata/test-fullvirt-default-feature.cfg |  1 -
>  tests/xmconfigdata/test-fullvirt-force-hpet.cfg|  1 -
>  tests/xmconfigdata/test-fullvirt-force-nohpet.cfg  |  1 -
>  tests/xmconfigdata/test-fullvirt-localtime.cfg |  1 -
>  tests/xmconfigdata/test-fullvirt-net-netfront.cfg  |  1 -
>  tests/xmconfigdata/test-fullvirt-new-cdrom.cfg |  1 -
>  tests/xmconfigdata/test-fullvirt-nohap.cfg | 28 ++
>  tests/xmconfigdata/test-fullvirt-nohap.xml | 51 +++
>  tests/xmconfigdata/test-fullvirt-parallel-tcp.cfg  |  1 -
>  .../test-fullvirt-serial-dev-2-ports.cfg   |  1 -
>  .../test-fullvirt-serial-dev-2nd-port.cfg  |  1 -
>  tests/xmconfigdata/test-fullvirt-serial-file.cfg   |  1 -
>  tests/xmconfigdata/test-fullvirt-serial-null.cfg   |  1 -
>  tests/xmconfigdata/test-fullvirt-serial-pipe.cfg   |  1 -
>  tests/xmconfigdata/test-fullvirt-serial-pty.cfg|  1 -
>  tests/xmconfigdata/test-fullvirt-serial-stdio.cfg  |  1 -
>  .../test-fullvirt-serial-tcp-telnet.cfg|  1 -
>  tests/xmconfigdata/test-fullvirt-serial-tcp.cfg|  1 -
>  tests/xmconfigdata/test-fullvirt-serial-udp.cfg|  1 -
>  tests/xmconfigdata/test-fullvirt-serial-unix.cfg   |  1 -
>  tests/xmconfigdata/test-fullvirt-sound.cfg |  1 -
>  tests/xmconfigdata/test-fullvirt-usbmouse.cfg  |  1 -
>  tests/xmconfigdata/test-fullvirt-usbtablet.cfg |  1 -
>  tests/xmconfigdata/test-fullvirt-utc.cfg   |  1 -
>  tests/xmconfigdata/test-no-source-cdrom.cfg|  1 -
>  tests/xmconfigdata/test-pci-devs.cfg   |  1 -
>  tests/xmconfigtest.c   |  1 +
>  43 files changed, 173 insertions(+), 43 deletions(-)
> 
> diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
> index 828c8e9..4dcd484 100644
> --- a/src/xenconfig/xen_common.c
> +++ b/src/xenconfig/xen_common.c
> @@ -528,11 +528,11 @@ xenParseCPUFeatures(virConfPtr conf, virDomainDefPtr 
> def)
>  
>  else if (val)
>  def->features[VIR_DOMAIN_FEATURE_APIC] = VIR_TRISTATE_SWITCH_ON;
> -if (xenConfigGetBool(conf, "hap", , 0) < 0)
> +if (xenConfigGetBool(conf, "hap", , 1) < 0)
>  return -1;
>  
> -else if (val)
> -def->features[VIR_DOMAIN_FEATURE_HAP] = VIR_TRISTATE_SWITCH_ON;
> +else if (!val)
> +def->features[VIR_DOMAIN_FEATURE_HAP] = VIR_TRISTATE_SWITCH_OFF;
>  if (xenConfigGetBool(conf, "viridian", , 0) < 0)
>  return -1;
>  
> @@ -1572,10 +1572,10 @@ xenFormatCPUFeatures(virConfPtr conf, virDomainDefPtr 
> def)
>  VIR_TRISTATE_SWITCH_ON) ? 1 : 0) < 0)
>  return -1;
>  
> -if (xenConfigSetInt(conf, "hap",
> -(def->features[VIR_DOMAIN_FEATURE_HAP] ==
> - VIR_TRISTATE_SWITCH_ON) ? 1 : 0) < 0)
> -return -1;
> +if (def->features[VIR_DOMAIN_FEATURE_HAP] == 
> VIR_TRISTATE_SWITCH_OFF) {
> +if (xenConfigSetInt(conf, "hap", 0) < 0)
> +return -1;
> +}
>  
>  if (xenConfigSetInt(conf, "viridian",
>  (def->features[VIR_DOMAIN_FEATURE_VIRIDIAN] ==
> diff --git a/tests/xlconfigdata/test-disk-positional-parms-full.cfg 
> b/tests/xlconfigdata/test-disk-positional-parms-full.cfg
> index 026e451..c5bbb03 100644
> --- a/tests/xlconfigdata/test-disk-positional-parms-full.cfg
> +++ b/tests/xlconfigdata/test-disk-positional-parms-full.cfg
> @@ -6,7 +6,6 @@ vcpus = 1
>  pae = 1
>  acpi = 1
>  apic = 1
> -hap = 0
>  viridian = 0
>  rtc_timeoffset 

Re: [Xen-devel] [libvirt] [PATCH V2 1/4] conf: add 'state' attribute to feature

[Joao Martins]

On 03/01/2016 04:00 AM, Jim Fehlig wrote:
> Most hypervisors use Hardware Assisted Paging by default and don't
> require specifying the feature in domain conf. But some hypervisors
> support disabling HAP on a per-domain basis. To enable HAP by default
> yet provide a knob to disable it, extend the  feature with a
> 'state=on|off' attribute, similar to  and  features.
> 
> In the absence of , the hypervisor default (on) is used. 
> without the state attribute would be the same as  for
> backwards compatibility. And of course  disables hap.
> 
> Signed-off-by: Jim Fehlig 
> ---
>  docs/formatdomain.html.in | 6 --
>  docs/schemas/domaincommon.rng | 6 +-
>  src/conf/domain_conf.c| 4 ++--
>  3 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 5016772..c06bcf3 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -1494,8 +1494,10 @@
>Interrupt) for the guest.
>
>hap
> -  Enable use of Hardware Assisted Paging if available in
> -the hardware.
> +  Depending on the state attribute (values 
> on,
> +off) enable or disable use of Hardware Assisted Paging.
> +The default is on if the hypervisor detects availability
> +of Hardware Assisted Paging.
>
>viridian
>Enable Viridian hypervisor extensions for paravirtualizing
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index 67af93a..dd6e93a 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -4108,7 +4108,11 @@
>
>
>  
> -  
> +  
> +
> +  
> +
> +  
Perhaps  would be better (see chunk below) ? That one
appears to be a reference of what you are adding above, and it's the same as
pvspinlock. Though some other elements don't appear to use this, not sure why.

diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 89d3a6b..141122c 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -4132,9 +4132,7 @@
   
 
   
-
-  
-
+
   
 
   

Other that,

Reviewed-by: Joao Martins 

>  
>
>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 79758d4..714bbfc 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -15296,7 +15296,6 @@ virDomainDefParseXML(xmlDocPtr xml,
>  /* fallthrough */
>  case VIR_DOMAIN_FEATURE_ACPI:
>  case VIR_DOMAIN_FEATURE_PAE:
> -case VIR_DOMAIN_FEATURE_HAP:
>  case VIR_DOMAIN_FEATURE_VIRIDIAN:
>  case VIR_DOMAIN_FEATURE_PRIVNET:
>  case VIR_DOMAIN_FEATURE_HYPERV:
> @@ -15321,6 +15320,7 @@ virDomainDefParseXML(xmlDocPtr xml,
>  ctxt->node = node;
>  break;
>  
> +case VIR_DOMAIN_FEATURE_HAP:
>  case VIR_DOMAIN_FEATURE_PMU:
>  case VIR_DOMAIN_FEATURE_PVSPINLOCK:
>  case VIR_DOMAIN_FEATURE_VMPORT:
> @@ -22043,7 +22043,6 @@ virDomainDefFormatInternal(virDomainDefPtr def,
>  switch ((virDomainFeature) i) {
>  case VIR_DOMAIN_FEATURE_ACPI:
>  case VIR_DOMAIN_FEATURE_PAE:
> -case VIR_DOMAIN_FEATURE_HAP:
>  case VIR_DOMAIN_FEATURE_VIRIDIAN:
>  case VIR_DOMAIN_FEATURE_PRIVNET:
>  switch ((virTristateSwitch) def->features[i]) {
> @@ -22065,6 +22064,7 @@ virDomainDefFormatInternal(virDomainDefPtr def,
>  
>  break;
>  
> +case VIR_DOMAIN_FEATURE_HAP:
>  case VIR_DOMAIN_FEATURE_PMU:
>  case VIR_DOMAIN_FEATURE_PVSPINLOCK:
>  case VIR_DOMAIN_FEATURE_VMPORT:
> 

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

Re: [Xen-devel] [PATCH 2/2] tools: detect appropriate debug optimization level

[Doug Goldstein]

On 3/8/16 9:38 AM, Wei Liu wrote:
> On Mon, Mar 07, 2016 at 08:23:40PM -0600, Doug Goldstein wrote:
>> The build should not use -O0 as that results in miscompilations. There
> 
> This needs some (concrete) references. Is that a known issue in gcc? If
> so can you reference the bug number?

So its not really a bug in GCC but just the complete lack of
optimizations in play. inlines aren't inlined. dead code elimination
isn't run so things are much bigger. structures aren't padded the same way.

This came about from reading reports on the -devel and -user's ML that
were solved by building Xen with debug=n. I was also striving to reduce
the duplication of CFLAGS that are passed on the command line of builds.

> 
>> have been a few instances on the ML where users were told to switch
>> from -O0 to -O1 or -O2 or to set debug=n and their issue went away. The
>> preferred route should be to use -Og if its available, otherwise use
>> -O1 which is the default. This change undoes the change from -O1 to -O0
> 
> gcc manual says -O0 is the default.

I wasn't clear about where the 'the default' came from. That's the
default in the Xen tree (see: config/StdGNU.mk for example but every
platform has -O1 set).

> 
> Not that I disagree with this patch in general, but the commit message
> seems a bit misleading.

I can rewrite it. I'd also be willing to change the patch to prefer -Og
if its available and use -O0 if its not.

> 
>> in 1166ecf781b1016eaa61f8d5ba4fb1fde9d599b6.
>>
> 
> And I have no idea why -O1 confuses the debugger so I've CC'ed Euan for
> more input.

-O1 can optimize things out when you look at them with gdb but -Og is
suppose to do the right thing.

> 
>> Signed-off-by: Doug Goldstein 
>> ---
>> CC: Ian Jackson 
>> CC: Stefano Stabellini 
>> CC: Wei Liu 
>> ---
>>  tools/Rules.mk | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/Rules.mk b/tools/Rules.mk
>> index 9ef0b47..ae6b01f 100644
>> --- a/tools/Rules.mk
>> +++ b/tools/Rules.mk
>> @@ -137,7 +137,8 @@ SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) 
>> -Wl,-rpath-link=$(XEN_LIBVCHAN)
>>  
>>  ifeq ($(debug),y)
>>  # Disable optimizations and enable debugging information for macros
>> -CFLAGS += -O0 -g3
>> +$(call cc-option-add,CFLAGS,CC,-Og)
>> +CFLAGS += -g3
>>  # But allow an override to -O0 in case Python enforces 
>> -D_FORTIFY_SOURCE=.
>>  PY_CFLAGS += $(PY_NOOPT_CFLAGS)
>>  endif
>> -- 
>> 2.4.10
>>


-- 
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 3/3] xl: new "loglvl" command

[Wei Liu]

On Fri, Mar 04, 2016 at 09:48:16AM -0700, Jan Beulich wrote:
> This is pretty simplistic for now, but I'd rather have someone better
> friends with the tools improve it (if desired).
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5958,6 +5958,26 @@ int libxl_send_debug_keys(libxl_ctx *ctx
>  return 0;
>  }
>  
> +int libxl_log_level(libxl_ctx *ctx, bool set, bool guest,
> +int *lower_thresh, int *upper_thresh)
> +{
> +int ret;
> +GC_INIT(ctx);
> +if (set) {
> +ret = xc_set_log_level(ctx->xch, guest, *lower_thresh, 
> *upper_thresh);
> +} else {
> +ret = xc_get_log_level(ctx->xch, guest, lower_thresh, upper_thresh);
> +}
> +if ( ret < 0 ) {
> +LOGE(ERROR, "%s %slog level",
> + set ? "setting" : "getting", guest ? "guest " : "");
> +GC_FREE;
> +return ERROR_FAIL;
> +}
> +GC_FREE;
> +return 0;
> +}
> +

As Dario said, libxl tends to have getter and setter pair.

>  libxl_xen_console_reader *
>  libxl_xen_console_read_start(libxl_ctx *ctx, int clear)
>  {
[...]
>  
>  /*
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -6469,6 +6469,84 @@ int main_debug_keys(int argc, char **arg
>  return 0;
>  }
>  
> +static const struct {
> +int level;
> +char string[8];
> +} loglvls[] = {
> +{ 0, "none" },
> +{ 1, "error" },
> +{ 2, "warning" },
> +{ 3, "info" },
> +{ 4, "all" },
> +{ 4, "debug" },

The semantics of the numbers should go into libxl_types.idl. Maybe
something like

# Keep in sync with Xen log level.
libxl_xen_log_level = Enumeration (...);

Then in here

static const struct {
int level;
char string[8];
} loglvls[] = {
{ LIBXL_XEN_LOG_LEVEL_NONE, "none" },
{ ..., "error" },
{ ..., "warning" },
{ ..., "info" },
{ ..., "all" },
{ ..., "debug" },

Please also note that after the introduction of this API, Xen log level
will become part of the stable API and subject to some compatibility
constraints. Is this what you wanted?


> +};
> +
> +static int parse_loglvl(char **parg)
> +{
> +unsigned int i;
> +
> +for (i = 0; i < ARRAY_SIZE(loglvls); ++i) {
> +size_t l = strlen(loglvls[i].string);
> +
> +if (!strncmp(*parg, loglvls[i].string, l)) {
> +*parg += l;
> +return loglvls[i].level;
> +}
> +}
> +
> +return -1;
> +}
> +
> +static const char *format_loglvl(int loglvl)
> +{
> +unsigned int i;
> +
> +for (i = 0; i < ARRAY_SIZE(loglvls); ++i) {
> +if (loglvl == loglvls[i].level)
> +return loglvls[i].string;
> +}
> +
> +return "";
> +}
> +
> +int main_loglvl(int argc, char **argv)
> +{
> +static const struct option opts[] = {
> +{"guest", 0, 0, 'g'},
> +{"set", 0, 0, 's'},
> +COMMON_LONG_OPTS
> +};
> +int opt, lower_thresh = -1, upper_thresh = -1;
> +bool guest = false, set = false;
> +
> +SWITCH_FOREACH_OPT(opt, "gs:", opts, "loglvl", 0) {
> +case 'g':
> +guest = true;
> +break;
> +case 's':
> +if (*optarg != '/')
> +lower_thresh = parse_loglvl();
> +if (*optarg == '/') {
> +++optarg;
> +upper_thresh = parse_loglvl();
> +}
> +set = true;
> +break;
> +}
> +
> +if (libxl_log_level(ctx, set, guest, _thresh, _thresh)) {
> +fprintf(stderr, "cannot %s %s log level\n",
> +set ? "set" : "get", guest ? "guest" : "host");
> +return 1;
> +}
> +
> +if (!set)
> +printf("%s log levels: %s/%s\n", guest ? "guest" : "host",
> +   format_loglvl(lower_thresh), format_loglvl(upper_thresh));
> +
> +return 0;
> +}
> +

You also need to patch xl manpage.

Wei.

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

Re: [Xen-devel] [PATCH 1/2] xsm: move the XSM_MAGIC value to Kconfig

[Daniel De Graaf]

On 03/07/2016 01:42 PM, Doug Goldstein wrote:

Let Kconfig set the XSM_MAGIC value for us.

Signed-off-by: Doug Goldstein 


This is not the best place to define this constant: it doesn't
make sense for it to be user-configurable.  If you want to move it
out of config.h, I think the best solution is to define XSM_MAGIC
inside xsm/xsm.h depending on the value of CONFIG_FLASK.


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

Re: [Xen-devel] [PATCH 2/2] xsm: move FLASK_AVC_STATS to Kconfig

[Daniel De Graaf]

On 03/08/2016 04:46 AM, Jan Beulich wrote:

On 07.03.16 at 19:42,  wrote:

Have Kconfig set CONFIG_FLASK_AVC_STATS and prefix all uses with CONFIG_
to use the Kconfig variable.


Same question here: What's the benefit of doing it this way?


This removes the stats tracking, which might (I have not tested) speed up
the security server by avoiding the __get_cpu_var call and increment. The
corresponding SELinux knob is a Kconfig option in Linux.

Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 2/3] libxc: wrapper for log level sysctl

[Wei Liu]

On Fri, Mar 04, 2016 at 09:47:32AM -0700, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 
> 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 4/6] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case

[Juergen Gross]

On 08/03/16 14:16, Dario Faggioli wrote:
> On Thu, 2016-03-03 at 17:48 +0100, Juergen Gross wrote:
>> The hypervisor might return EBUSY when trying to remove a cpu from a
>> cpupool when a domain running in this cpupool has pinned a vcpu
>> temporarily. Do some retries in this case, perhaps the situation
>> cleans up.
>>
> I now I'm at high risk of being called nitpicker (or, more likely, much
> worse names), but I think that:
> 
>> --- a/tools/libxc/xc_cpupool.c
>> +++ b/tools/libxc/xc_cpupool.c
>> @@ -20,8 +20,11 @@
>>   */
>>  
>>  #include 
>> +#include 
>>  #include "xc_private.h"
>>  
>> +#define LIBXC_BUSY_RETRIES 5
>> +
> This name makes me think about something which wants to be more generic
> than  it is actually the case... Like some number of retries that libxc
> does in general, while it's only applicable to a very specific cpupool
> operation.
> 
> Just something like CPUPOOL_NUM_REMOVECPU_RETRIES (or, maybe, even
> without the CPUPOOL_ prefix, as we're already inside cpupool.c) would
> be more appropriate.
> 
> I'd also define it closer to xc_cpupool_removecpu() (but that is a lot
> about personal taste, I guess) and would add a brief comment
> (basically, a summary of what's in the changelog already), if only to
> save people having to go through `git blame'.
> 
>> @@ -141,13 +144,21 @@ int xc_cpupool_removecpu(xc_interface *xch,
>>   uint32_t poolid,
>>   int cpu)
>>  {
>> +unsigned retries;
>> +int err;
>>  DECLARE_SYSCTL;
>>  
>>  sysctl.cmd = XEN_SYSCTL_cpupool_op;
>>  sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_RMCPU;
>>  sysctl.u.cpupool_op.cpupool_id = poolid;
>>  sysctl.u.cpupool_op.cpu = (cpu < 0) ? XEN_SYSCTL_CPUPOOL_PAR_ANY
>> : cpu;
>> -return do_sysctl_save(xch, );
>> +for ( retries = 0; retries < LIBXC_BUSY_RETRIES; retries++ ) {
>> +err = do_sysctl_save(xch, );
>> +if ( err >= 0 || errno != EBUSY )
>> +break;
>> +sleep(1);
>> +}
>>
> Doing this the other way round (basically, exactly as the same thing is
> done in do_sysctl_save() already), reads, IMHO, more natural:
> 
>  for (...) {
>err = do_sysctl_save(..);
>if ( err < 0 && errno == EBUSY )
>  sleep(1);
>else
>  break;
>  }
> 
> But yeah, this really is nitpicking. :-)

Nevertheless I can do it. Need to respin anyway.


Juergen


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

Re: [Xen-devel] [PATCH v3 6/6] libxl: add force option for xl vcpu-pin

[Juergen Gross]

On 08/03/16 16:58, Wei Liu wrote:
> On Thu, Mar 03, 2016 at 05:48:50PM +0100, Juergen Gross wrote:
> [...]
>>  int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
>> unsigned int max_vcpus,
>> const libxl_bitmap *cpumap_hard,
>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>> index f9e3ef5..19ec076 100644
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -1715,6 +1715,10 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo 
>> *physinfo);
>>  int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>> const libxl_bitmap *cpumap_hard,
>> const libxl_bitmap *cpumap_soft);
>> +int libxl_set_vcpuaffinity_force(libxl_ctx *ctx, uint32_t domid,
>> + uint32_t vcpuid,
>> + const libxl_bitmap *cpumap_hard,
>> + const libxl_bitmap *cpumap_soft);
> 
> With the introduction of this new API you need to have a #define in
> libxl.h

Okay.


Juergen


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

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

[Wei Liu]

On Tue, Mar 08, 2016 at 02:05:01PM +, George Dunlap wrote:
> On Tue, Mar 8, 2016 at 8:08 AM, Jan Beulich  wrote:
>  On 07.03.16 at 19:07,  wrote:
> >> On Mon, 2016-03-07 at 04:46 -0700, Jan Beulich wrote:
> >>> > > > On 04.03.16 at 19:45,  wrote:
> >>> > On Fri, 2016-03-04 at 09:48 -0700, Jan Beulich wrote:
> >>
> >>> > > --- a/tools/libxl/libxl.c
> >>> > > +++ b/tools/libxl/libxl.c
> >>> > > @@ -5958,6 +5958,26 @@ int libxl_send_debug_keys(libxl_ctx *ctx
> >>> > >  return 0;
> >>> > >  }
> >>> > >
> >>> > > +int libxl_log_level(libxl_ctx *ctx, bool set, bool guest,
> >>> > > +int *lower_thresh, int *upper_thresh)
> >>> > > +{
> >>> > > +int ret;
> >>> > >
> >>> > As per libxl coding style, this wants to be 'r'.
> >>> This and everything else below look to be valid comments, but
> >>> it's rather frustrating that simply cloning an existing function (I
> >>> user the debug key ones as basis) doesn't give me valid code,
> >>> the more that I did scroll up and down a few pages to see
> >>> whether I just happened to pick a particularly bad example.
> >>>
> >> Hehe, but do you understand that, saying this, you're making it very
> >> likely that people will ask *you* to fix libxl_send_debug_keys() --and
> >> perhaps more tool side code? :-P :-P
> >
> > Except that it's not just that function - as said, I did scroll up and
> > down, without finding (style wise) better examples. And no, I'm
> > not going to put together patches to deal with style issues in the
> > tools.
> >
> >> No, jokes apart, I agree that inconsistency is a real bad thing... but
> >> it's an hard fight, and we do have examples spread all around the
> >> source code (both Xen and tools), AFAICT.
> >
> > Right, and asking people myself to not follow bad examples when
> > adding new code, I did take all of your input to adjust the patch.
> > Just that in this case the set of bad examples is so large that in a
> > similar case in the hypervisor I probably wouldn't have dared to
> > ask for a style correction.
> 
> Well the approach of the libxl maintainers seems to have be, "Just
> make sure the new code adheres to the new style, and eventyally
> everything will be up-to-date".  A few releases ago I submitted a
> patch where I added a new clause in the middle of a series of other
> very similar clauses, and I was asked to make the new clause follow
> the new style, but to leave the other clauses right next to it in the
> old style (to avoid unnecessary code churn, since it was during the
> development freeze).
> 
> Given that the "new" style has been around for a while now, it
> probably would be good to set aside some time at the beginning of the
> next development cycle to fix things up -- it is incredibly
> frustrating to carefully try to copy the surrounding style, only to be
> told to revise it.
> 

I did fix a few hundred instances of inconsistency at the beginning of
4.7 cycle. Spatch is helpful, but it is far from perfect.

What I'm afraid of is that fixing them would introduce too much noise
that renders file line annotation useless.

Wei.

>  -George

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

Re: [Xen-devel] [PATCH] xen: Restore p2m_access_t enum order to allow bitmask semantics

[Tamas K Lengyel]

On Tue, Mar 8, 2016 at 4:52 PM, Jan Beulich  wrote:

> >>> On 08.03.16 at 16:30,  wrote:
> > Nested hap code assumed implict bitmask semantics of the p2m_access_t
> > enum prior to C/S 4c63692d7c38c5ac414fe97f8ef37b66e05abe5c
> >
> > The change to the enum ordering broke this assumption and caused
> functional
> > problems for the nested hap code. As it may be error prone to audit and
> find
> > all other p2m_access users assuming bitmask semantics, instead restore
> the
> > previous enum order and make it explict that bitmask semantics are to be
> > preserved for the read, write and execute access types.
>
> Makes sense, but how certain are you that ...
>
> > --- a/xen/include/xen/p2m-common.h
> > +++ b/xen/include/xen/p2m-common.h
> > @@ -15,14 +15,15 @@
> >   * default.
> >   */
> >  typedef enum {
> > -p2m_access_rwx   = 0, /* The default access type when not used. */
>
> ... namely this has not meanwhile seen any implicit use somewhere?
>
> Tamas, the original commit talked about this as an optimization only.
> Can you confirm that there indeed was no other intention than the
> one claimed in that commit's description?
>

That's the only reason I recall as well, so from my perspective it's fine
to be reverted.

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

Re: [Xen-devel] [PATCH v3 5/6] libxl: print message how to recover from xl cpupool-cpu-remove errors

[Wei Liu]

On Thu, Mar 03, 2016 at 05:48:49PM +0100, Juergen Gross wrote:
> An error occurring when calling "xl cpupool-cpu-remove" might leave
> the system in a state where a cpu is neither completely free nor in
> a cpupool. This can easily be repaired by adding the cpu via
> "xl cpupool-cpu-add" to the cpupool where it was removed from before.
> Print a message telling this the user in case of an error.
> 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Wei Liu 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

> ---
>  tools/libxl/xl_cmdimpl.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 990d3c9..411473d 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -7716,8 +7716,10 @@ int main_cpupoolcpuremove(int argc, char **argv)
>  goto out;
>  }
>  
> -if (libxl_cpupool_cpuremove_cpumap(ctx, poolid, ))
> -fprintf(stderr, "some cpus may not have been removed from %s\n", 
> pool);
> +if (libxl_cpupool_cpuremove_cpumap(ctx, poolid, )) {
> +fprintf(stderr, "Some cpus may have not or only partially been 
> removed from '%s'.\n", pool);
> +fprintf(stderr, "If a cpu can't be added to another cpupool, add it 
> to '%s' again and retry.\n", pool);
> +}
>  
>  rc = EXIT_SUCCESS;
>  
> -- 
> 2.6.2
> 

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

Re: [Xen-devel] [PATCH v3 6/6] libxl: add force option for xl vcpu-pin

[Wei Liu]

On Thu, Mar 03, 2016 at 05:48:50PM +0100, Juergen Gross wrote:
[...]
>  int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> unsigned int max_vcpus,
> const libxl_bitmap *cpumap_hard,
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index f9e3ef5..19ec076 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1715,6 +1715,10 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo 
> *physinfo);
>  int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
> const libxl_bitmap *cpumap_hard,
> const libxl_bitmap *cpumap_soft);
> +int libxl_set_vcpuaffinity_force(libxl_ctx *ctx, uint32_t domid,
> + uint32_t vcpuid,
> + const libxl_bitmap *cpumap_hard,
> + const libxl_bitmap *cpumap_soft);

With the introduction of this new API you need to have a #define in
libxl.h

Wei.

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

Re: [Xen-devel] [PATCH v3 03/16] configure: #define SEABIOS_PATH and OVMF_PATH

[Wei Liu]

On Thu, Mar 03, 2016 at 05:03:00PM +, Anthony PERARD wrote:
> On Tue, Mar 01, 2016 at 11:51:36AM +, Wei Liu wrote:
> > On Thu, Feb 25, 2016 at 02:56:01PM +, Anthony PERARD wrote:
> > > Those paths are to be used by libxl, in order to load the firmware in
> > > memory. If a system path is not define, then this default to the Xen
> > > firmware directory.
> > > 
> > > Signed-off-by: Anthony PERARD 
> > > 
> > 
> > There is already --with-system-seabios and --with-system-ovmf that you
> > can use.
> 
> The path generated by --with-system-seabios is only for the benefit of the
> Makefiles. With this patch, I'm exporting the value to the .c files. And in
> the case where --with-system-* is not used, it provide a default path to
> where we are going to install the firmware we compiled.
> 

I see. SEABIOS_PATH and OVMF_PATH are already defined in Tools.mk.in.
This approach is fine then.

Wei.

> -- 
> Anthony PERARD

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

Re: [Xen-devel] [PATCH v3 06/16] libxl: Load guest ACPI table from file

[Wei Liu]

On Thu, Mar 03, 2016 at 05:12:07PM +, Anthony PERARD wrote:
> On Tue, Mar 01, 2016 at 11:51:43AM +, Wei Liu wrote:
> > On Thu, Feb 25, 2016 at 02:56:04PM +, Anthony PERARD wrote:
> > > A user can provide a different ACPI tables than the default one by using
> > > the existing "acpi_firmware" xl's config option or the field
> > > u.hvm.acpi_firmware.
> > > 
> > > libxl will check if the provided table is a DSDT or not.
> > > 
> > 
> > According to xl.cfg manpage, acpi_firmware= cann't be used to override
> > DSDT, so you seem to be changing the semantics of existing option.
> 
> Yes, that was an idea from Ian Campbell <1446634655.6461.48.ca...@citrix.com>
> I should at least change the manual.
> 
> Would it be OK to reuse this options? Or should I add a new option, maybe
> acpi_dsdt_override, or some other name?
> 

If repurposing the old option won't break existing guest then that's
fine, otherwise a new option is required.

Wei.

> -- 
> Anthony PERARD

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

Re: [Xen-devel] [PATCH] xen: Restore p2m_access_t enum order to allow bitmask semantics

[Jan Beulich]

>>> On 08.03.16 at 16:30,  wrote:
> Nested hap code assumed implict bitmask semantics of the p2m_access_t
> enum prior to C/S 4c63692d7c38c5ac414fe97f8ef37b66e05abe5c
> 
> The change to the enum ordering broke this assumption and caused functional
> problems for the nested hap code. As it may be error prone to audit and find
> all other p2m_access users assuming bitmask semantics, instead restore the
> previous enum order and make it explict that bitmask semantics are to be
> preserved for the read, write and execute access types.

Makes sense, but how certain are you that ...

> --- a/xen/include/xen/p2m-common.h
> +++ b/xen/include/xen/p2m-common.h
> @@ -15,14 +15,15 @@
>   * default.
>   */
>  typedef enum {
> -p2m_access_rwx   = 0, /* The default access type when not used. */

... namely this has not meanwhile seen any implicit use somewhere?

Tamas, the original commit talked about this as an optimization only.
Can you confirm that there indeed was no other intention than the
one claimed in that commit's description?

Jan


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

Re: [Xen-devel] Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling

[Jan Beulich]

>>> On 08.03.16 at 15:42,  wrote:
> On Tue, Mar 8, 2016 at 1:10 PM, Wu, Feng  wrote:
>>> -Original Message-
>>> From: George Dunlap [mailto:george.dun...@citrix.com]
> [snip]
>>> It seems like there are a couple of ways we could approach this:
>>>
>>> 1. Try to optimize the reverse look-up code so that it's not a linear
>>> linked list (getting rid of the theoretical fear)
>>
>> Good point.
>>
>>>
>>> 2. Try to test engineered situations where we expect this to be a
>>> problem, to see how big of a problem it is (proving the theory to be
>>> accurate or inaccurate in this case)
>>
>> Maybe we can run a SMP guest with all the vcpus pinned to a dedicated
>> pCPU, we can run some benchmark in the guest with VT-d PI and without
>> VT-d PI, then see the performance difference between these two sceanrios.
> 
> This would give us an idea what the worst-case scenario would be.

How would a single VM ever give us an idea about the worst
case? Something getting close to worst case is a ton of single
vCPU guests all temporarily pinned to one and the same pCPU
(could be multi-vCPU ones, but the more vCPU-s the more
artificial this pinning would become) right before they go into
blocked state (i.e. through one of the two callers of
arch_vcpu_block()), the pinning removed while blocked, and
then all getting woken at once.

>  But
> pinning all vcpus to a single pcpu isn't really a sensible use case we
> want to support -- if you have to do something stupid to get a
> performance regression, then I as far as I'm concerned it's not a
> problem.
> 
> Or to put it a different way: If we pin 10 vcpus to a single pcpu and
> then pound them all with posted interrupts, and there is *no*
> significant performance regression, then that will conclusively prove
> that the theoretical performance regression is of no concern, and we
> can enable PI by default.

The point isn't the pinning. The point is what pCPU they're on when
going to sleep. And that could involve quite a few more than just
10 vCPU-s, provided they all sleep long enough.

And the "theoretical performance regression is of no concern" is
also not a proper way of looking at it, I would say: Even if such
a situation would happen extremely rarely, if it can happen at all,
it would still be a security issue.

> On the other hand, if we pin 10 vcpus to a single pcpu, pound them all
> with posted interrupts, and then there *is* a significant performance
> regression, then it would still not convince me there is a real
> problem to be solved.  There is only actually a problem if the "long
> chain of vcpus" can happen in the course of a semi-realistic use-case.
> 
> Suppose we had a set of SRIOV NICs with 10-20 virtual functions total,
> assigned to 10-20 VMs, and those VMs in a cpupool confined to a single
> socket of about 4 cores; and then we do a really network-intensive
> benchmark. That's a *bit* far-fetched, but it's something that might
> conceivably happen in the real world without any deliberate stupidity.
> If there's no significant performance issues in that case, I would
> think we can say that posted interrupts are robust enough to be
> enabled by default.
> 
>>> 3. Turn the feature on by default as soon as the 4.8 window opens up,
>>> perhaps with some sort of a check that runs when in debug mode that
>>> looks for the condition we're afraid of happening and BUG()s.  If we run
>>> a full development cycle without anyone hitting the bug in testing, then
>>> we just leave the feature on.
>>
>> Maybe we can pre-define a max acceptable length of the list,  if it really
>> reach the number, print out a warning or something like that. However,
>> how to decide the max length is a problem. May need more thinking.
> 
> I think we want to measure the amount of time spent in the interrupt
> handler (or with interrupts disabled).  It doesn't matter if the list
> is 100 items long, if it can be handled in 500us.  On the other hand,
> if a list of 4 elements takes 20ms, there's a pretty massive problem.
> :-)

Spending on the order of 500us in an interrupt handler would
already seem pretty long to me, especially when the interrupt
may get raised at a high frequency. Even more so if, when in
that state, _each_ invocation of the interrupt handler would
take that long: With an (imo not unrealistic) interrupt rate of
1kHz we would spend half of the available CPU time in that
handler.

> I don't have a good idea what an unreasonably large number would be here -- 
> Jan?

Neither do I, unfortunately.

Jan

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

Re: [Xen-devel] [PATCH 2/2] tools: detect appropriate debug optimization level

[Wei Liu]

On Mon, Mar 07, 2016 at 08:23:40PM -0600, Doug Goldstein wrote:
> The build should not use -O0 as that results in miscompilations. There

This needs some (concrete) references. Is that a known issue in gcc? If
so can you reference the bug number?

> have been a few instances on the ML where users were told to switch
> from -O0 to -O1 or -O2 or to set debug=n and their issue went away. The
> preferred route should be to use -Og if its available, otherwise use
> -O1 which is the default. This change undoes the change from -O1 to -O0

gcc manual says -O0 is the default.

Not that I disagree with this patch in general, but the commit message
seems a bit misleading.

> in 1166ecf781b1016eaa61f8d5ba4fb1fde9d599b6.
> 

And I have no idea why -O1 confuses the debugger so I've CC'ed Euan for
more input.

> Signed-off-by: Doug Goldstein 
> ---
> CC: Ian Jackson 
> CC: Stefano Stabellini 
> CC: Wei Liu 
> ---
>  tools/Rules.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/Rules.mk b/tools/Rules.mk
> index 9ef0b47..ae6b01f 100644
> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -137,7 +137,8 @@ SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) 
> -Wl,-rpath-link=$(XEN_LIBVCHAN)
>  
>  ifeq ($(debug),y)
>  # Disable optimizations and enable debugging information for macros
> -CFLAGS += -O0 -g3
> +$(call cc-option-add,CFLAGS,CC,-Og)
> +CFLAGS += -g3
>  # But allow an override to -O0 in case Python enforces -D_FORTIFY_SOURCE=.
>  PY_CFLAGS += $(PY_NOOPT_CFLAGS)
>  endif
> -- 
> 2.4.10
> 

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

Re: [Xen-devel] [PATCH 1/2] libxl: ensure var is inited in libxl__domain_firmware

[Wei Liu]

On Mon, Mar 07, 2016 at 08:23:39PM -0600, Doug Goldstein wrote:
> Some versions of GCC complain that the 'firmware' variable can be used
> uninitialized. It looks like the switch inside of the else case is just
> confusing GCC.
> 
> Signed-off-by: Doug Goldstein 

Acked-by: Wei Liu 

> ---
> CC: Ian Jackson 
> CC: Stefano Stabellini 
> CC: Wei Liu 
> ---
>  tools/libxl/libxl_dom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 664adad..b825b98 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -867,7 +867,7 @@ static int libxl__domain_firmware(libxl__gc *gc,
>struct xc_dom_image *dom)
>  {
>  libxl_ctx *ctx = libxl__gc_owner(gc);
> -const char *firmware;
> +const char *firmware = NULL;
>  int e, rc;
>  int datalen = 0;
>  void *data;
> -- 
> 2.4.10
> 

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

Re: [Xen-devel] [PATCH] xen: Restore p2m_access_t enum order to allow bitmask semantics

[Andrew Cooper]

On 08/03/16 15:30, Malcolm Crossley wrote:
> Nested hap code assumed implict bitmask semantics of the p2m_access_t
> enum prior to C/S 4c63692d7c38c5ac414fe97f8ef37b66e05abe5c
>
> The change to the enum ordering broke this assumption and caused functional
> problems for the nested hap code. As it may be error prone to audit and find
> all other p2m_access users assuming bitmask semantics, instead restore the
> previous enum order and make it explict that bitmask semantics are to be
> preserved for the read, write and execute access types.
>
> Signed-off-by: Malcolm Crossley 

Reviewed-by: Andrew Cooper 

Specifically, the bug causes memory corruption in the L2 guest, because
the code out of context in nestedhvm_hap_nested_page_fault() incorrectly
calculates the permission bits for the nested p2m.

> ---
>  xen/arch/x86/mm/hap/nested_hap.c |  2 +-
>  xen/include/xen/p2m-common.h | 17 +
>  2 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/x86/mm/hap/nested_hap.c 
> b/xen/arch/x86/mm/hap/nested_hap.c
> index 0dbae13..9cee5a0 100644
> --- a/xen/arch/x86/mm/hap/nested_hap.c
> +++ b/xen/arch/x86/mm/hap/nested_hap.c
> @@ -263,7 +263,7 @@ nestedhvm_hap_nested_page_fault(struct vcpu *v, paddr_t 
> *L2_gpa,
>  
>  switch ( p2ma_10 )
>  {
> -case p2m_access_rwx ... p2m_access_n:
> +case p2m_access_n ... p2m_access_rwx:
>  break;
>  case p2m_access_rx2rw:
>  p2ma_10 = p2m_access_rx;
> diff --git a/xen/include/xen/p2m-common.h b/xen/include/xen/p2m-common.h
> index 8b70459..6374a5b 100644
> --- a/xen/include/xen/p2m-common.h
> +++ b/xen/include/xen/p2m-common.h
> @@ -15,14 +15,15 @@
>   * default.
>   */
>  typedef enum {
> -p2m_access_rwx   = 0, /* The default access type when not used. */
> -p2m_access_wx= 1,
> -p2m_access_rx= 2,
> -p2m_access_x = 3,
> -p2m_access_rw= 4,
> -p2m_access_w = 5,
> -p2m_access_r = 6,
> -p2m_access_n = 7, /* No access allowed. */
> +/* Code uses bottom three bits with bitmask semantics */
> +p2m_access_n = 0, /* No access allowed. */
> +p2m_access_r = 1 << 0,
> +p2m_access_w = 1 << 1,
> +p2m_access_x = 1 << 2,
> +p2m_access_rw= p2m_access_r | p2m_access_w,
> +p2m_access_rx= p2m_access_r | p2m_access_x,
> +p2m_access_wx= p2m_access_w | p2m_access_x,
> +p2m_access_rwx   = p2m_access_r | p2m_access_w | p2m_access_x,
>  
>  p2m_access_rx2rw = 8, /* Special: page goes from RX to RW on write */
>  p2m_access_n2rwx = 9, /* Special: page goes from N to RWX on access, *


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

[Xen-devel] [PATCH] xen: Restore p2m_access_t enum order to allow bitmask semantics

[Malcolm Crossley]

Nested hap code assumed implict bitmask semantics of the p2m_access_t
enum prior to C/S 4c63692d7c38c5ac414fe97f8ef37b66e05abe5c

The change to the enum ordering broke this assumption and caused functional
problems for the nested hap code. As it may be error prone to audit and find
all other p2m_access users assuming bitmask semantics, instead restore the
previous enum order and make it explict that bitmask semantics are to be
preserved for the read, write and execute access types.

Signed-off-by: Malcolm Crossley 
---
 xen/arch/x86/mm/hap/nested_hap.c |  2 +-
 xen/include/xen/p2m-common.h | 17 +
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index 0dbae13..9cee5a0 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -263,7 +263,7 @@ nestedhvm_hap_nested_page_fault(struct vcpu *v, paddr_t 
*L2_gpa,
 
 switch ( p2ma_10 )
 {
-case p2m_access_rwx ... p2m_access_n:
+case p2m_access_n ... p2m_access_rwx:
 break;
 case p2m_access_rx2rw:
 p2ma_10 = p2m_access_rx;
diff --git a/xen/include/xen/p2m-common.h b/xen/include/xen/p2m-common.h
index 8b70459..6374a5b 100644
--- a/xen/include/xen/p2m-common.h
+++ b/xen/include/xen/p2m-common.h
@@ -15,14 +15,15 @@
  * default.
  */
 typedef enum {
-p2m_access_rwx   = 0, /* The default access type when not used. */
-p2m_access_wx= 1,
-p2m_access_rx= 2,
-p2m_access_x = 3,
-p2m_access_rw= 4,
-p2m_access_w = 5,
-p2m_access_r = 6,
-p2m_access_n = 7, /* No access allowed. */
+/* Code uses bottom three bits with bitmask semantics */
+p2m_access_n = 0, /* No access allowed. */
+p2m_access_r = 1 << 0,
+p2m_access_w = 1 << 1,
+p2m_access_x = 1 << 2,
+p2m_access_rw= p2m_access_r | p2m_access_w,
+p2m_access_rx= p2m_access_r | p2m_access_x,
+p2m_access_wx= p2m_access_w | p2m_access_x,
+p2m_access_rwx   = p2m_access_r | p2m_access_w | p2m_access_x,
 
 p2m_access_rx2rw = 8, /* Special: page goes from RX to RW on write */
 p2m_access_n2rwx = 9, /* Special: page goes from N to RWX on access, *
-- 
1.7.12.4


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

[Xen-devel] I'm a beginner and want become a Xen tester.

[Jason Long]

Hello.
How can I test Xen and report bug? Can it need programming?

Tnx.

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

Re: [Xen-devel] test

[Doug Goldstein]

On 3/8/16 8:35 AM, Juergen Gross wrote:
> This is just a test of the mailman bounce mechanism: I want to be sure
> that I receive bounce messages (they have been filtered by SUSE's mail
> server).
> 
> Please don't accept, reject or discard this message. I'll do it myself.
> 
> In case it makes it to the list: please ignore. :-)
> 
> 
> Juergen

FWIW, I've been getting a lot of bounces from SUSE's mail servers in
general in the last 2 weeks.

-- 
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] Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling

[George Dunlap]

On Tue, Mar 8, 2016 at 1:10 PM, Wu, Feng  wrote:
>> -Original Message-
>> From: George Dunlap [mailto:george.dun...@citrix.com]
[snip]
>> It seems like there are a couple of ways we could approach this:
>>
>> 1. Try to optimize the reverse look-up code so that it's not a linear
>> linked list (getting rid of the theoretical fear)
>
> Good point.
>
>>
>> 2. Try to test engineered situations where we expect this to be a
>> problem, to see how big of a problem it is (proving the theory to be
>> accurate or inaccurate in this case)
>
> Maybe we can run a SMP guest with all the vcpus pinned to a dedicated
> pCPU, we can run some benchmark in the guest with VT-d PI and without
> VT-d PI, then see the performance difference between these two sceanrios.

This would give us an idea what the worst-case scenario would be.  But
pinning all vcpus to a single pcpu isn't really a sensible use case we
want to support -- if you have to do something stupid to get a
performance regression, then I as far as I'm concerned it's not a
problem.

Or to put it a different way: If we pin 10 vcpus to a single pcpu and
then pound them all with posted interrupts, and there is *no*
significant performance regression, then that will conclusively prove
that the theoretical performance regression is of no concern, and we
can enable PI by default.

On the other hand, if we pin 10 vcpus to a single pcpu, pound them all
with posted interrupts, and then there *is* a significant performance
regression, then it would still not convince me there is a real
problem to be solved.  There is only actually a problem if the "long
chain of vcpus" can happen in the course of a semi-realistic use-case.

Suppose we had a set of SRIOV NICs with 10-20 virtual functions total,
assigned to 10-20 VMs, and those VMs in a cpupool confined to a single
socket of about 4 cores; and then we do a really network-intensive
benchmark. That's a *bit* far-fetched, but it's something that might
conceivably happen in the real world without any deliberate stupidity.
If there's no significant performance issues in that case, I would
think we can say that posted interrupts are robust enough to be
enabled by default.

>> 3. Turn the feature on by default as soon as the 4.8 window opens up,
>> perhaps with some sort of a check that runs when in debug mode that
>> looks for the condition we're afraid of happening and BUG()s.  If we run
>> a full development cycle without anyone hitting the bug in testing, then
>> we just leave the feature on.
>
> Maybe we can pre-define a max acceptable length of the list,  if it really
> reach the number, print out a warning or something like that. However,
> how to decide the max length is a problem. May need more thinking.

I think we want to measure the amount of time spent in the interrupt
handler (or with interrupts disabled).  It doesn't matter if the list
is 100 items long, if it can be handled in 500us.  On the other hand,
if a list of 4 elements takes 20ms, there's a pretty massive problem.
:-)

I don't have a good idea what an unreasonably large number would be here -- Jan?

 -George

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