Re: [Xen-devel] [PATCH v2 1/2] x86/hvm: allow guest to use clflushopt and clwb

[Haozhong Zhang]

On 01/07/16 07:34, Jan Beulich wrote:
> >>> On 07.01.16 at 15:01,  wrote:
> > On 07/01/16 13:49, Jan Beulich wrote:
> > On 30.12.15 at 12:48,  wrote:
> >>> --- a/xen/arch/x86/hvm/hvm.c
> >>> +++ b/xen/arch/x86/hvm/hvm.c
> >>> @@ -4583,21 +4583,30 @@ void hvm_cpuid(unsigned int input, unsigned int 
> >>> *eax, 
> > unsigned int *ebx,
> >>>  *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);
> >>>  break;
> >>>  case 0x7:
> >>> -if ( (count == 0) && !cpu_has_smep )
> >>> -*ebx &= ~cpufeat_mask(X86_FEATURE_SMEP);
> >>> +if ( count == 0 )
> >>> +{
> >>> +if ( !cpu_has_smep )
> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_SMEP);
> >>> +
> >>> +if ( !cpu_has_smap )
> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_SMAP);
> >>> +
> >>> +/* Don't expose MPX to hvm when VMX support is not available 
> >>> */
> >>> +if ( !(vmx_vmexit_control & VM_EXIT_CLEAR_BNDCFGS) ||
> >>> + !(vmx_vmentry_control & VM_ENTRY_LOAD_BNDCFGS) )
> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_MPX);
> >>>  
> >>> -if ( (count == 0) && !cpu_has_smap )
> >>> -*ebx &= ~cpufeat_mask(X86_FEATURE_SMAP);
> >>> +/* Don't expose INVPCID to non-hap hvm. */
> >>> +if ( !hap_enabled(d) )
> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_INVPCID);
> >>>  
> >>> -/* Don't expose MPX to hvm when VMX support is not available */
> >>> -if ( (count == 0) &&
> >>> - (!(vmx_vmexit_control & VM_EXIT_CLEAR_BNDCFGS) ||
> >>> -  !(vmx_vmentry_control & VM_ENTRY_LOAD_BNDCFGS)) )
> >>> -*ebx &= ~cpufeat_mask(X86_FEATURE_MPX);
> >>> +if ( !cpu_has_clflushopt )
> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_CLFLUSHOPT);
> >>> +
> >>> +if ( !cpu_has_clwb )
> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_CLWB);
> >> I don't think we need this: Other than other things adjusted here,
> >> there's nothing disabling these two features when found available,
> >> and there are no extra conditions to consider. Otherwise, if we
> >> were to follow this route, quite a bit of code would need to be
> >> added to other case statements in this function. But that's all (I
> >> think) going to be taken care of by Andrew's CPUID leveling series.
> > 
> > My series does take care of all of this.
> > 
> > I would prefer that these two changes get taken as soon as they are
> > ready, so I can rebase.
> 
> If we don't need the change quoted above, your rebase will actually
> be easier to do.
> 
> Jan
>
I'll remove changes in hvm_cpuid() in the next version. Changes in
xen/include/asm-x86/cpufeature.h will be removed as well, because
there will be no use of them.

Haozhong

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

Re: [Xen-devel] [PATCH v2 1/2] x86/hvm: allow guest to use clflushopt and clwb

[Jan Beulich]

>>> On 08.01.16 at 09:27,  wrote:
> On 01/07/16 07:34, Jan Beulich wrote:
>> >>> On 07.01.16 at 15:01,  wrote:
>> > On 07/01/16 13:49, Jan Beulich wrote:
>> > On 30.12.15 at 12:48,  wrote:
>> >>> --- a/xen/arch/x86/hvm/hvm.c
>> >>> +++ b/xen/arch/x86/hvm/hvm.c
>> >>> @@ -4583,21 +4583,30 @@ void hvm_cpuid(unsigned int input, unsigned int 
>> >>> *eax, 
>> > unsigned int *ebx,
>> >>>  *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);
>> >>>  break;
>> >>>  case 0x7:
>> >>> -if ( (count == 0) && !cpu_has_smep )
>> >>> -*ebx &= ~cpufeat_mask(X86_FEATURE_SMEP);
>> >>> +if ( count == 0 )
>> >>> +{
>> >>> +if ( !cpu_has_smep )
>> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_SMEP);
>> >>> +
>> >>> +if ( !cpu_has_smap )
>> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_SMAP);
>> >>> +
>> >>> +/* Don't expose MPX to hvm when VMX support is not 
>> >>> available */
>> >>> +if ( !(vmx_vmexit_control & VM_EXIT_CLEAR_BNDCFGS) ||
>> >>> + !(vmx_vmentry_control & VM_ENTRY_LOAD_BNDCFGS) )
>> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_MPX);
>> >>>  
>> >>> -if ( (count == 0) && !cpu_has_smap )
>> >>> -*ebx &= ~cpufeat_mask(X86_FEATURE_SMAP);
>> >>> +/* Don't expose INVPCID to non-hap hvm. */
>> >>> +if ( !hap_enabled(d) )
>> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_INVPCID);
>> >>>  
>> >>> -/* Don't expose MPX to hvm when VMX support is not available */
>> >>> -if ( (count == 0) &&
>> >>> - (!(vmx_vmexit_control & VM_EXIT_CLEAR_BNDCFGS) ||
>> >>> -  !(vmx_vmentry_control & VM_ENTRY_LOAD_BNDCFGS)) )
>> >>> -*ebx &= ~cpufeat_mask(X86_FEATURE_MPX);
>> >>> +if ( !cpu_has_clflushopt )
>> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_CLFLUSHOPT);
>> >>> +
>> >>> +if ( !cpu_has_clwb )
>> >>> +*ebx &= ~cpufeat_mask(X86_FEATURE_CLWB);
>> >> I don't think we need this: Other than other things adjusted here,
>> >> there's nothing disabling these two features when found available,
>> >> and there are no extra conditions to consider. Otherwise, if we
>> >> were to follow this route, quite a bit of code would need to be
>> >> added to other case statements in this function. But that's all (I
>> >> think) going to be taken care of by Andrew's CPUID leveling series.
>> > 
>> > My series does take care of all of this.
>> > 
>> > I would prefer that these two changes get taken as soon as they are
>> > ready, so I can rebase.
>> 
>> If we don't need the change quoted above, your rebase will actually
>> be easier to do.
>>
> I'll remove changes in hvm_cpuid() in the next version. Changes in
> xen/include/asm-x86/cpufeature.h will be removed as well, because
> there will be no use of them.

Indeed - this should become a tools only patch.

Jan


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

Re: [Xen-devel] [PATCH] arch/x86: convert bigmem to Kconfig

[Jan Beulich]

>>> On 08.01.16 at 03:55,  wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -25,6 +25,18 @@ config ARCH_DEFCONFIG
>  
>  menu "Architecture Features"
>  
> +config BIGMEM
> + bool "big memory support"
> + default n
> + ---help---
> +   Allows Xen to support up to 123Tb of memory.
> +
> +   This requires growing struct page_info from 32 to 48 bytes as well
> +   as shrinking the always accessible direct mapped memory range from
> +   5Tb to 3.5Tb.

Fundamentally okay, but I think the numbers should be dropped
(as they could easily become stale, since they reflect in the first
case just current state and in the second really just an
implementation detail). No strict need to re-submit (can be fixed
up upon commit), but I'd like to have your consent since this is
going to be under your name.

Jan


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

Re: [Xen-devel] [PATCH v3 02/13] x86/time.c: Use correct guest TSC frequency in tsc_get_info()

[Jan Beulich]

>>> On 04.01.16 at 18:48,  wrote:
> On 12/30/2015 10:03 PM, Haozhong Zhang wrote:
>> When the TSC mode of a HVM container is TSC_MODE_DEFAULT or
>> TSC_MODE_PVRDTSCP and no TSC emulation is used, the existing
>> tsc_get_info() uses the host TSC frequency (cpu_khz) as the guest TSC
>> frequency. However, tsc_set_info() may set the guest TSC frequency to a
>> value different than the host. In order to keep consistent to
>> tsc_set_info(), this patch makes tsc_get_info() use the value set by
>> tsc_set_info() as the guest TSC frequency.
>>
>> Signed-off-by: Haozhong Zhang 
>> ---
>> Changes in v3:
>>   (addressing Boris Ostrovsky's comments)
>>   * Use this_cpu(cpu_time).tsc_scale for both scaling and non-scaling cases.
>>
>>   xen/arch/x86/time.c | 9 ++---
>>   1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
>> index 0059b6a..d83f068 100644
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -1749,6 +1749,9 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
>> uint64_t *elapsed_nsec, uint32_t *gtsc_khz,
>> uint32_t *incarnation)
>>   {
>> +bool_t enable_tsc_scaling = has_hvm_container_domain(d) &&
>> +cpu_has_tsc_ratio;
>> +
> 
> Reviewed-by: Boris Ostrovsky 
> 
> although I still think that having !d->arch.vtsc would be better, even 
> if not strictly required.

Since Haozhong agreed, and for symmetry with patch 1 I'm going to
commit with this added, plus ...

>> @@ -1780,9 +1783,9 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
>>   else
>>   {
>>   tsc = rdtsc();
>> -*elapsed_nsec = scale_delta(tsc, >arch.vtsc_to_ns) -
>> +*elapsed_nsec = scale_delta(tsc, _cpu(cpu_time).tsc_scale) 
>> -
>>   d->arch.vtsc_offset;
>> -*gtsc_khz = 0; /* ignored by tsc_set_info */
>> +*gtsc_khz = enable_tsc_scaling ? d->arch.tsc_khz : 0;

... with the comment here retained.

Jan


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

Re: [Xen-devel] [PATCH v3 04/13] x86/time.c: Scale host TSC in pvclock properly

[Jan Beulich]

>>> On 31.12.15 at 04:03,  wrote:
> This patch makes the pvclock return the scaled host TSC and
> corresponding scaling parameters to HVM domains if guest TSC is not
> emulated and TSC scaling is enabled.
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Changes in v3:
>  (addressing Boris Ostrovsky's comments)
>  * No changes in fact. tsc_set_info() does not set d->arch.vtsc to 0
>if host_tsc_is_safe() is not satisfied, so it is safe to use
>d->arch.vtsc_to_ns here.
> 
>  xen/arch/x86/time.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> index d83f068..b31634a 100644
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -815,10 +815,18 @@ static void __update_vcpu_system_time(struct vcpu *v, 
> int force)
>  }
>  else
>  {
> -tsc_stamp = t->local_tsc_stamp;
> -
> -_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
> -_u.tsc_shift = (s8)t->tsc_scale.shift;
> +if ( has_hvm_container_domain(d) && cpu_has_tsc_ratio )

For symmetry with patches 1 and 2 I'd expect !d->arch.vtsc to be
added here too.

> +{
> +tsc_stamp= hvm_funcs.scale_tsc(v, 
> t->local_tsc_stamp);
> +_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
> +_u.tsc_shift = d->arch.vtsc_to_ns.shift;
> +}
> +else
> +{
> +tsc_stamp= t->local_tsc_stamp;
> +_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
> +_u.tsc_shift = (s8)t->tsc_scale.shift;

The case has been pointless anyway, and you don't add a similar
one in the if() branch - please delete it.

Jan


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

Re: [Xen-devel] [PATCH v3 05/13] svm: Remove redundant TSC scaling in svm_set_tsc_offset()

[Jan Beulich]

>>> On 31.12.15 at 04:03,  wrote:
> @@ -854,6 +841,7 @@ static void svm_set_tsc_offset(struct vcpu *v, u64 
> offset, u64 at_tsc)
>  n2_tsc_offset = vmcb_get_tsc_offset(n2vmcb) -
>  vmcb_get_tsc_offset(n1vmcb);
>  if ( svm->ns_tscratio != DEFAULT_TSC_RATIO ) {
> +uint64_t guest_tsc = hvm_get_guest_tsc_fixed(v, at_tsc);
>  n2_tsc_offset = svm_get_tsc_offset(guest_tsc,

Blank line between declaration(s) and statement(s) please.

Also please consider taking the opportunity to fix the preceding
line's coding style violation.

Jan




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

Re: [Xen-devel] [PATCH v3 03/13] x86/hvm: Scale host TSC when setting/getting guest TSC

[Jan Beulich]

>>> On 31.12.15 at 04:03,  wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -804,6 +804,16 @@ static uint64_t scale_tsc(uint64_t host_tsc, uint64_t 
> ratio)
>  return scaled_host_tsc;
>  }
>  
> +static uint64_t svm_scale_tsc(struct vcpu *v, uint64_t tsc)
> +{
> +struct domain *d = v->domain;
> +
> +if ( !cpu_has_tsc_ratio || d->arch.vtsc )

The left side of this check is redundant with those at both call sites.
It should either be removed altogether, or converted to an ASSERT().
Perhaps the right side should move into the callers too (as being
vendor independent), or if not at least the pointless local variable
should be eliminated.

Further I suppose this new hook really could/should have its
first argument const qualified (the hook isn't supposed to fiddle
with the vCPU).

Jan


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

Re: [Xen-devel] [OSSTEST PATCH 5/7] Database locking: Tcl: for errorCode, use pg_exec, not pg_execute

[Ian Campbell]

On Thu, 2016-01-07 at 19:38 +, Ian Jackson wrote:
> We would like to be able to retry db transactions.  To do this we need
> to know why they failed (if they did).
> 
> But pg_execute does not set errorCode.  (This is clearly a bug.)  And
> since it immediately discards a failed statement, any error
> information has been lost by the time pg_execute returns.
> 
> So, instead, use pg_exec, and manually mess about with fishing
> suitable information out of a failed statement handle, and generating
> an appropriate errorCode.
> 
> There are no current consumers of this errorCode: that will come in a
> moment.
> 
> A wrinkle is that as a result it is no longer possible to use
> db-execute on a SELECT statement nor db-execute-array on a non-SELECT
> statement.  This is because the 1. the `ok' status that we have to

Stray "the" before "1.".

> check for is different for statements which are commands and ones
> which return tupes and 2. we need to fish a different return value out

"tuples"

> of the statement handle (-cmdTuples vs -numTuples).  But all uses in
> the codebase are now fine for this distinction.

Does this imply that db-execute-array could be renamed db-execute-select,
or even just db-select?

> 
> Signed-off-by: Ian Jackson 
> ---
>  tcl/JobDB-Executive.tcl |   54
> ---
>  1 file changed, 51 insertions(+), 3 deletions(-)
> 
> diff --git a/tcl/JobDB-Executive.tcl b/tcl/JobDB-Executive.tcl
> index bbce6fc..ed9abbb 100644
> --- a/tcl/JobDB-Executive.tcl
> +++ b/tcl/JobDB-Executive.tcl
> @@ -121,13 +121,61 @@ proc db-execute-debug {stmt} {
>   puts stderr "EXECUTING >$stmt<"
>  }
>  }
> +
> +proc db--exec-check {shvar stmt expected_status body} {
> +# pg_execute does not set errorCode and it throws away the
> +# statement handle so we can't get the error out.  So
> +# use pg_exec, as wrapped up here.
> +
> +# db--exec-check executes stmt and checks that the status is
> +# `expected_status'.  If OK, executes body with $shvar set to the
> +# stmt handle.   Otherwise throws with errorCode
> +#   {OSSTEST-PSQL  }
> +
> +global errorInfo errorCode
> +upvar 1 $shvar sh
> +
> +set sh [pg_exec dbh $stmt]
> +
> +set rc [catch {
> + set status [pg_result $sh -status]
> + if {[string compare $status $expected_status]} {
> + set emsg [pg_result $sh -error]
> + set sqlstate [pg_result $sh -error sqlstate]
> + if {![string length $emsg]} {
> + set emsg "osstest expected status $expected_status got
> $status"
> + }
> + set context [pg_result $sh -error context]
> + error $emsg \
> + "while executing SQL\n$stmt\nin SQL
> context\n$context" \
> + [list OSSTEST-PSQL $status $sqlstate]
> + }
> + uplevel 1 $body
> +} emsg]
> +
> +set ei $errorInfo
> +set ec $errorCode
> +catch { pg_result $sh -clear }
> +
> +return -code $rc -errorinfo $ei -errorcode $ec $emsg
> +}
> +
>  proc db-execute {stmt} {
>  db-execute-debug $stmt
> -uplevel 1 [list pg_execute dbh $stmt]
> +db--exec-check sh $stmt PGRES_COMMAND_OK {
> + return [pg_result $sh -cmdTuples]
> +}
>  }
> -proc db-execute-array {arrayvar stmt args} {
> +proc db-execute-array {arrayvar stmt {body {}}} {
>  db-execute-debug $stmt
> -uplevel 1 [list pg_execute -array $arrayvar dbh $stmt] $args
> +db--exec-check sh $stmt PGRES_TUPLES_OK {
> + set nrows [pg_result $sh -numTuples]
> + for {set row 0} {$row < $nrows} {incr row} {
> + uplevel 1 [list pg_result $sh -tupleArray $row $arrayvar]
> + uplevel 1 $body
> + }
> + return $nrows
> +}
>  }
>  
>  proc lock-tables {tables} {

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

Re: [Xen-devel] [PATCH v3 02/13] x86/time.c: Use correct guest TSC frequency in tsc_get_info()

[Haozhong Zhang]

On 01/08/16 02:05, Jan Beulich wrote:
> >>> On 04.01.16 at 18:48,  wrote:
> > On 12/30/2015 10:03 PM, Haozhong Zhang wrote:
> >> When the TSC mode of a HVM container is TSC_MODE_DEFAULT or
> >> TSC_MODE_PVRDTSCP and no TSC emulation is used, the existing
> >> tsc_get_info() uses the host TSC frequency (cpu_khz) as the guest TSC
> >> frequency. However, tsc_set_info() may set the guest TSC frequency to a
> >> value different than the host. In order to keep consistent to
> >> tsc_set_info(), this patch makes tsc_get_info() use the value set by
> >> tsc_set_info() as the guest TSC frequency.
> >>
> >> Signed-off-by: Haozhong Zhang 
> >> ---
> >> Changes in v3:
> >>   (addressing Boris Ostrovsky's comments)
> >>   * Use this_cpu(cpu_time).tsc_scale for both scaling and non-scaling 
> >> cases.
> >>
> >>   xen/arch/x86/time.c | 9 ++---
> >>   1 file changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> >> index 0059b6a..d83f068 100644
> >> --- a/xen/arch/x86/time.c
> >> +++ b/xen/arch/x86/time.c
> >> @@ -1749,6 +1749,9 @@ void tsc_get_info(struct domain *d, uint32_t 
> >> *tsc_mode,
> >> uint64_t *elapsed_nsec, uint32_t *gtsc_khz,
> >> uint32_t *incarnation)
> >>   {
> >> +bool_t enable_tsc_scaling = has_hvm_container_domain(d) &&
> >> +cpu_has_tsc_ratio;
> >> +
> > 
> > Reviewed-by: Boris Ostrovsky 
> > 
> > although I still think that having !d->arch.vtsc would be better, even 
> > if not strictly required.
> 
> Since Haozhong agreed, and for symmetry with patch 1 I'm going to
> commit with this added, plus ...
> 
> >> @@ -1780,9 +1783,9 @@ void tsc_get_info(struct domain *d, uint32_t 
> >> *tsc_mode,
> >>   else
> >>   {
> >>   tsc = rdtsc();
> >> -*elapsed_nsec = scale_delta(tsc, >arch.vtsc_to_ns) -
> >> +*elapsed_nsec = scale_delta(tsc, 
> >> _cpu(cpu_time).tsc_scale) -
> >>   d->arch.vtsc_offset;
> >> -*gtsc_khz = 0; /* ignored by tsc_set_info */
> >> +*gtsc_khz = enable_tsc_scaling ? d->arch.tsc_khz : 0;
> 
> ... with the comment here retained.
>
And it's better to refine the comment like
/* ignored by tsc_set_info if TSC scaling disabled */

Haozhong

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

Re: [Xen-devel] [OSSTEST PATCH 3/7] Database locking: Tcl: Use db-execute

[Ian Campbell]

On Thu, 2016-01-07 at 19:38 +, Ian Jackson wrote:
> Replace open-coded uses of pg_execute dbh STMT with
> jobdb::db-execute-array STMT.

ITYM jobdb::db-execute?


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

Re: [Xen-devel] [PATCH v3 07/13] x86: Add functions for 64-bit integer arithmetic

[Jan Beulich]

>>> On 31.12.15 at 04:03,  wrote:
> --- /dev/null
> +++ b/xen/include/asm-x86/math64.h
> @@ -0,0 +1,105 @@
> +#ifndef __X86_MATH64
> +#define __X86_MATH64
> +
> +/*
> + * Functions defined in this file are derived from Linux kernel
> + * (include/linux/math64.h).
> + */

This is not true. At least mul64() doesn't exist in Linux (as of 4.4-rc8).

> +static inline void mul64(u64 *lo, u64 *hi, u64 a, u64 b)
> +{
> +typedef union {
> +u64 ll;
> +struct {
> +u32 low, high;
> +} l;
> +} LL;
> +LL rl, rm, rn, rh, a0, b0;
> +u64 c;
> +
> +a0.ll = a;
> +b0.ll = b;
> +
> +rl.ll = (u64)a0.l.low * b0.l.low;
> +rm.ll = (u64)a0.l.low * b0.l.high;
> +rn.ll = (u64)a0.l.high * b0.l.low;
> +rh.ll = (u64)a0.l.high * b0.l.high;
> +
> +c = (u64)rl.l.high + rm.l.low + rn.l.low;
> +rl.l.high = c;
> +c >>= 32;
> +c = c + rm.l.high + rn.l.high + rh.l.low;
> +rh.l.low = c;
> +rh.l.high += (u32)(c >> 32);
> +
> +*lo = rl.ll;
> +*hi = rh.ll;
> +}

For this one in particular, but likely also for the others: If this was
put in include/xen/math64.h I might buy it. As an x86-specific
implementation this could (and should) be done with a single asm()
statement using the MUL instruction (I didn't check whether gcc
also offers a built-in, which then could be used generically).

Jan


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

Re: [Xen-devel] [PATCH] tools: make flask utils build unconditional

[Doug Goldstein]

On 1/5/16 10:42 AM, Wei Liu wrote:
> On Tue, Jan 05, 2016 at 04:24:19PM +, Ian Campbell wrote:
>> On Tue, 2016-01-05 at 16:13 +, Wei Liu wrote:
>>> On Tue, Jan 05, 2016 at 03:36:21PM +, Ian Campbell wrote:
 On Tue, 2016-01-05 at 14:37 +, Ian Campbell wrote:
>
> which on the basis of this discussion I wasn't expecting. I didn't
> see this
> new file on i686 or ARM*.
>
> My baseline is from the last time I committed, which would be last
> year, so
> maybe something other than my current batch of patches has caused
> this.
>
> I'm going to drop this one for now and (hopefully) get the rest of
> the
> batch squared away. Afterwards I'll take another look (with a new
> baseline
> filelist), but if someone can explain it in the meantime that would
> be
> super.

 So with a fresh basline I still see:

 --- ../FILE_LIST.BASE.staging.x86_642016-01-05 14:50:32.0
 +
 +++ ../FILE_LIST.staging.x86_64 2016-01-05 15:11:15.0 +
 @@ -6,6 +6,7 @@
  dist/install/boot/xen-4.7-unstable.gz
  dist/install/boot/xen-4.gz
  dist/install/boot/xen.gz
 +dist/install/boot/xenpolicy-4.7-unstable
  dist/install/etc
  dist/install/etc/bash_completion.d
  dist/install/etc/bash_completion.d/xl.sh
 @@ -386,6 +387,12 @@
  dist/install/usr/local/lib/xen/libexec
  dist/install/usr/local/lib/xen/libexec/qemu-bridge-helper
  dist/install/usr/local/sbin
 +dist/install/usr/local/sbin/flask-get-bool
 +dist/install/usr/local/sbin/flask-getenforce
 +dist/install/usr/local/sbin/flask-label-pci
 +dist/install/usr/local/sbin/flask-loadpolicy
 +dist/install/usr/local/sbin/flask-set-bool
 +dist/install/usr/local/sbin/flask-setenforce
  dist/install/usr/local/sbin/gdbsx
  dist/install/usr/local/sbin/gtracestat
  dist/install/usr/local/sbin/gtraceview
 *** FILES DIFFER ***

 On i686 and ARM* I only see the (expected) second hunk.

 I think the i686 case is explainable by the lack of a hypervisor build
 there, but I'm unsure why ARM* and x86_64 should differ in this regard.

 config/Tools.mk is y only on x86_64, not on the others, which obviously
 explains things, but the question is why only on x86_64 (I presume this
 has
 always been the case and it was previously masked, but I've not
 checked).

 Ah, OK, I misread

 AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])

 as being default disable, actually the default is "enabled iff
 checkpolicy
 is installed" and it happens to be that it is only installed in my
 x86_64
 build env.

 So, in the end I think Wei was correct and this change will now, in
 some
 circumstances, end up installing a /boot/xenpolicy-*.

>>>
>>> I don't think it is related to this patch. I see an xenpoilcy file
>>> without this patch applied.
>>
>> With XSM disabled?
>>
>>>  As you said it only depends on availability
>>> of checkpolicy (part of generic SELinux utils, not the ones we build).
>>
>> But then why does this file only show up for me with this patch applied?
>>
>> You initially objected to this patch because you thought it would add this
>> file, but it seems like you have always had it. Is the answer just that you
>> only just found that you always had it?
>>
> 
> Hmm... After I make distclean, things changed.
> 
> So to be clear: without this patch applied, I don't have xenpolicy file
> even if checkpolicy is available. This patch does alter the behaviour
> somehow.
> 
> I'm in the middle of rebasing one patch series,  so I haven't looked
> into all the details.
> 
>>>
>>> That said, let me try to answer the following question.
>>>
 So the question is do we mind that?

>>>
>>> We might or might not. See below.
>>>
>>> I once submitted a patch to grub that look into /boot and generate XSM
>>> entries if there is policy file. The patch is not yet merged though.
>>>
>>> Since there is no way at the moment to tell if xen.gz has flask enabled,
>>> my not yet upstreamed patch only matches the version number of xen.gz and
>>> xenpolicy. Installing xenpolicy when xen.gz is not flaks-capable will
>>> make grub generate an XSM entry nonetheless, which makes no sense.
>>
>> Indeed.
>>
>>> Of course all the above is based on the theory that my grub patch is
>>> going to be upstreamed.
>>>
>>> Things have changed since I first submitted that patch. Doug's Kconfig
>>> work is good. With .config installed in suitable location we can make
>>> grub grep for flask information in config, hence avoiding generating
>>> wrong entries.  I think this is better solution as we don't need to use
>>> version number to match xen.gz and xenpolicy. If we go down this route
>>> we don't mind having random xenpolicy lying around in /boot.
>>
>>> We just need to reach an agreement on how to proceed. I 

[Xen-devel] [xen-unstable-smoke test] 77524: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 77507

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  ce95dc84e3a28716997be92e2ad85d3e70dbb73a
baseline version:
 xen  75904ac35f589b420d6d30415a64888b121d6484

Last test of basis77507  2016-01-08 10:02:58 Z0 days
Testing same since77524  2016-01-08 16:03:02 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Campbell 

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



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

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

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

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


Not pushing.


commit ce95dc84e3a28716997be92e2ad85d3e70dbb73a
Author: Andrew Cooper 
Date:   Fri Jan 8 14:38:03 2016 +

tools/libxc: Adjust error handling in map_p2m_list() to fix CentOS 7 build

The "goto err;" for malloc() error handling would cause the cleanup code
to use 'ptes' before it had been initialised, and causing a build
failure because of -Werror=maybe-uninitialised.

Use "goto err;" consistently for all error handling.

Signed-off-by: Andrew Cooper 
Reviewed-by: Juergen Gross 
Acked-by: Ian Campbell 
(qemu changes not included)

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

Re: [Xen-devel] [PATCH v3 1/3] xsm/xen_version: Add XSM for the xen_version hypercall (v6).

[Daniel De Graaf]

On 07/01/16 21:25, Konrad Rzeszutek Wilk wrote:

All of XENVER_* have now an XSM check.

The subop for XENVER_commandline is now a priviliged operation.
To not break guests we still return an string - but it is
just '\0'.

The rest: XENVER_[version|extraversion|capabilities|
parameters|get_features|page_size|guest_handle|changeset|
compile_info] behave as before - allowed by default for all guests.

This is with the XSM default (and non-default) policy and with
the dummy ones.

Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Daniel De Graaf 

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

[Xen-devel] [xen-unstable test] 77330: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 66879
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 66879

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm   3 host-install(3)  broken in 77209 pass in 77330
 test-armhf-armhf-xl-rtds  9 debian-install  fail pass in 77209

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 66879
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66879
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66879
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 66879

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 77209 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 77209 never pass
 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 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt  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-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-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-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-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail 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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass

version targeted for testing:
 xen  ce0fac22e7f367ba72ebd762331f8c9bdf1e2519
baseline version:
 xen  bf925a9f1254391749f569c1b8fc606036340488

Last test of basis66879  2015-12-21 21:25:56 Z   17 days
Failing since 67053  2015-12-23 06:54:21 Z   16 days5 attempts
Testing same since77209  2016-01-06 04:21:37 Z2 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Feng Wu 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Samuel Thibault 
  Wei Liu 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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

version targeted for testing:
 xen  f7347a282420a5edc74afb31e7c42c2765f24de5
baseline version:
 xen  75904ac35f589b420d6d30415a64888b121d6484

Last test of basis77507  2016-01-08 10:02:58 Z0 days
Failing since 77524  2016-01-08 16:03:02 Z0 days2 attempts
Testing same since77538  2016-01-08 19:08:39 Z0 days1 attempts


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

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [qemu-upstream-4.3-testing test] 77398: regressions - FAIL

[osstest service owner]

flight 77398 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77398/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 62112
 build-amd64   5 xen-build fail REGR. vs. 62112

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 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-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuu6e184363e64a0610c35ca231bfc73cea56eb02f3
baseline version:
 qemuub188780861662e8cf1847ec562799b32bb44f05e

Last test of basis62112  2015-09-18 04:07:28 Z  112 days
Testing same since66538  2015-12-18 16:12:07 Z   21 days   11 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 test-amd64-amd64-pairblocked 
 test-amd64-i386-pair blocked 
 test-amd64-amd64-pv  blocked 
 

[Xen-devel] [qemu-upstream-4.2-testing test] 77399: regressions - FAIL

[osstest service owner]

flight 77399 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77399/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 62044
 build-amd64   5 xen-build fail REGR. vs. 62044

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-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-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a

version targeted for testing:
 qemuu5081fc1c773d2a83ec7a867f030323b8b6956cd1
baseline version:
 qemuuc17e602ae64fb24405ebd256679ba9a6f5819086

Last test of basis62044  2015-09-15 15:06:42 Z  115 days
Testing same since66542  2015-12-18 16:37:10 Z   21 days   13 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked 
 test-amd64-i386-xend-qemuu-winxpsp3  blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   blocked 
 test-i386-i386-xl-qemuu-winxpsp3 blocked 



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

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

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

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


Not pushing.


commit 5081fc1c773d2a83ec7a867f030323b8b6956cd1
Author: Stefano Stabellini 
Date:   Fri Dec 18 15:45:14 2015 +

xenfb: avoid reading twice the same fields from the shared page

Reading twice the same field could give the guest an attack of
opportunity. In the case of event->type, gcc could compile the switch
statement into a jump table, effectively ending up reading the type
field multiple times.

This is part of XSA-155.

Signed-off-by: Stefano Stabellini 

commit 74fab2ef4c0ba42af477e9e445c9883cc45cf9e6
Author: Stefano Stabellini 
Date:   Fri Dec 18 15:44:58 2015 +

xen/blkif: Avoid double access to src->nr_segments

src is stored in shared memory and src->nr_segments is dereferenced
twice at the end of the function.  If a compiler decides to compile this
into two separate memory accesses then the size limitation could be
bypassed.

Fix it by removing the double 

[Xen-devel] [PATCH v4 1/5] build: Env var to enable expert config options

[Jonathan Creekmore]

Add an additional environment variable, defaulting to disabled,
that enables the CONFIG_EXPERT configuration option. The purpose
of the CONFIG_EXPERT configuration option is to make non-standard
Kconfig options visible during the configuration process. The
CONFIG_EXPERT option is not, itself, visible during the Kconfig
configuration process, so typical users will never see it nor
any of the non-standard configuration options.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Jonathan Creekmore 
Reviewed-by: Doug Goldstein 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 xen/Kconfig  | 4 
 xen/Makefile | 1 +
 2 files changed, 5 insertions(+)

diff --git a/xen/Kconfig b/xen/Kconfig
index ffe3f45..fa8b27c 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -22,3 +22,7 @@ config DEFCONFIG_LIST
string
option defconfig_list
default "$ARCH_DEFCONFIG"
+
+config EXPERT
+   string
+   option env="XEN_CONFIG_EXPERT"
diff --git a/xen/Makefile b/xen/Makefile
index 9023863..4950afb 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -11,6 +11,7 @@ export XEN_DOMAIN ?= $(shell ([ -x /bin/dnsdomainname ] 
&& /bin/dnsdomainname) |
 export XEN_BUILD_DATE  ?= $(shell LC_ALL=C date)
 export XEN_BUILD_TIME  ?= $(shell LC_ALL=C date +%T)
 export XEN_BUILD_HOST  ?= $(shell hostname)
+export XEN_CONFIG_EXPERT ?= n
 
 export BASEDIR := $(CURDIR)
 export XEN_ROOT := $(BASEDIR)/..
-- 
2.6.4


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

[Xen-devel] [PATCH v4 2/5] build: Hook the schedulers into Kconfig

[Jonathan Creekmore]

Allow the schedulers to be independently enabled or disabled at
compile-time. To match existing behavior, all four schedulers are
compiled in by default, although the Credit2, RTDS, and ARINC653 are
marked EXPERIMENTAL to match their not currently supported status.

CC: George Dunlap 
CC: Dario Faggioli 
Signed-off-by: Jonathan Creekmore 
Reviewed-by: Doug Goldstein 

---
Changed since v2:

  * Hid the scheduler menu behind the EXPERT option
  * Provide static inlines for credit functions that are assumed to be
always available
  * Provide an absolute default of the credit scheduler if the
scheduler menu is not visible

Changed since v1:

  * Marked credit2 as EXPERIMENTAL
  * Removed confusing language from the commit message
  * Alphabetize the schedulers
---
 xen/common/Kconfig  | 67 +
 xen/common/Makefile |  8 +++---
 xen/common/schedule.c   | 12 +++--
 xen/include/xen/sched.h |  5 
 4 files changed, 86 insertions(+), 6 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 046e257..db7411b 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -51,4 +51,71 @@ config KEXEC
 
  If unsure, say Y.
 
+# Enable schedulers
+menu "Schedulers"
+   visible if EXPERT = "y"
+
+config SCHED_CREDIT
+   bool "Credit scheduler support"
+   default y
+   ---help---
+ The traditional credit scheduler is a general purpose scheduler.
+
+ If unsure, say Y.
+
+config SCHED_CREDIT2
+   bool "Credit2 scheduler support (EXPERIMENTAL)"
+   default y
+   ---help---
+ The credit2 scheduler is a general purpose scheduler that is
+ optimized for lower latency and higher VM density.
+
+ If unsure, say Y.
+
+config SCHED_RTDS
+   bool "RTDS scheduler support (EXPERIMENTAL)"
+   default y
+   ---help---
+ The RTDS scheduler is a soft and firm real-time scheduler for
+ multicore, targeted for embedded, automotive, graphics and gaming
+ in the cloud, and general low-latency workloads.
+
+ If unsure, say N.
+
+config SCHED_ARINC653
+   bool "ARINC653 scheduler support (EXPERIMENTAL)"
+   default y
+   ---help---
+ The ARINC653 scheduler is a hard real-time scheduler for single
+ cores, targeted for avionics, drones, and medical devices.
+
+ If unsure, say N.
+
+choice
+   prompt "Default Scheduler?"
+   default SCHED_CREDIT_DEFAULT if SCHED_CREDIT
+   default SCHED_CREDIT2_DEFAULT if SCHED_CREDIT2
+   default SCHED_RTDS_DEFAULT if SCHED_RTDS
+   default SCHED_ARINC653_DEFAULT if SCHED_ARINC653
+
+   config SCHED_CREDIT_DEFAULT
+   bool "Credit Scheduler" if SCHED_CREDIT
+   config SCHED_CREDIT2_DEFAULT
+   bool "Credit2 Scheduler" if SCHED_CREDIT2
+   config SCHED_RTDS_DEFAULT
+   bool "RT Scheduler" if SCHED_RTDS
+   config SCHED_ARINC653_DEFAULT
+   bool "ARINC653 Scheduler" if SCHED_ARINC653
+endchoice
+
+config SCHED_DEFAULT
+   string
+   default "credit" if SCHED_CREDIT_DEFAULT
+   default "credit2" if SCHED_CREDIT2_DEFAULT
+   default "rtds" if SCHED_RTDS_DEFAULT
+   default "arinc653" if SCHED_ARINC653_DEFAULT
+   default "credit"
+
+endmenu
+
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 8ab15ba..29a5916 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -30,10 +30,10 @@ obj-y += rangeset.o
 obj-y += radix-tree.o
 obj-y += rbtree.o
 obj-y += rcupdate.o
-obj-y += sched_credit.o
-obj-y += sched_credit2.o
-obj-y += sched_arinc653.o
-obj-y += sched_rt.o
+obj-$(CONFIG_SCHED_ARINC653) += sched_arinc653.o
+obj-$(CONFIG_SCHED_CREDIT) += sched_credit.o
+obj-$(CONFIG_SCHED_CREDIT2) += sched_credit2.o
+obj-$(CONFIG_SCHED_RTDS) += sched_rt.o
 obj-y += schedule.o
 obj-y += shutdown.o
 obj-y += softirq.o
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index d121896..2f98a48 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -38,8 +38,8 @@
 #include 
 #include 
 
-/* opt_sched: scheduler - default to credit */
-static char __initdata opt_sched[10] = "credit";
+/* opt_sched: scheduler - default to configured value */
+static char __initdata opt_sched[10] = CONFIG_SCHED_DEFAULT;
 string_param("sched", opt_sched);
 
 /* if sched_smt_power_savings is set,
@@ -65,10 +65,18 @@ DEFINE_PER_CPU(struct schedule_data, schedule_data);
 DEFINE_PER_CPU(struct scheduler *, scheduler);
 
 static const struct scheduler *schedulers[] = {
+#ifdef CONFIG_SCHED_CREDIT
 _credit_def,
+#endif
+#ifdef CONFIG_SCHED_CREDIT2
 _credit2_def,
+#endif
+#ifdef CONFIG_SCHED_ARINC653
 _arinc653_def,
+#endif
+#ifdef CONFIG_SCHED_RTDS
 _rtds_def,
+#endif
 };
 
 static struct scheduler __read_mostly ops;
diff --git a/xen/include/xen/sched.h 

[Xen-devel] [PATCH v4 4/5] sched: Register the schedulers into the list

[Jonathan Creekmore]

Adds a simple macro to place a pointer to a scheduler into an array
section at compile time. Also, goes ahead and generates the array
entries with each of the schedulers.

CC: George Dunlap 
CC: Dario Faggioli 
CC: Josh Whitehead 
CC: Robert VanVossen 
Signed-off-by: Jonathan Creekmore 
Acked-by: Dario Faggioli 
Reviewed-by: Andrew Cooper 
Reviewed-by: Doug Goldstein 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 xen/common/sched_arinc653.c | 2 ++
 xen/common/sched_credit.c   | 2 ++
 xen/common/sched_credit2.c  | 2 ++
 xen/common/sched_rt.c   | 2 ++
 xen/include/xen/sched-if.h  | 2 ++
 5 files changed, 10 insertions(+)

diff --git a/xen/common/sched_arinc653.c b/xen/common/sched_arinc653.c
index dbe02ed..3b59514 100644
--- a/xen/common/sched_arinc653.c
+++ b/xen/common/sched_arinc653.c
@@ -767,6 +767,8 @@ const struct scheduler sched_arinc653_def = {
 .tick_resume= NULL,
 };
 
+REGISTER_SCHEDULER(sched_arinc653_def);
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 0dce790..e586248 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -2027,3 +2027,5 @@ const struct scheduler sched_credit_def = {
 .tick_suspend   = csched_tick_suspend,
 .tick_resume= csched_tick_resume,
 };
+
+REGISTER_SCHEDULER(sched_credit_def);
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 3c49ffa..38b02d0 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2228,3 +2228,5 @@ const struct scheduler sched_credit2_def = {
 .alloc_domdata  = csched2_alloc_domdata,
 .free_domdata   = csched2_free_domdata,
 };
+
+REGISTER_SCHEDULER(sched_credit2_def);
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 3f1d047..7640cd0 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -1199,3 +1199,5 @@ const struct scheduler sched_rtds_def = {
 .wake   = rt_vcpu_wake,
 .context_saved  = rt_context_saved,
 };
+
+REGISTER_SCHEDULER(sched_rtds_def);
diff --git a/xen/include/xen/sched-if.h b/xen/include/xen/sched-if.h
index 493d43f..9c6e0f5 100644
--- a/xen/include/xen/sched-if.h
+++ b/xen/include/xen/sched-if.h
@@ -170,6 +170,8 @@ extern const struct scheduler sched_credit2_def;
 extern const struct scheduler sched_arinc653_def;
 extern const struct scheduler sched_rtds_def;
 
+#define REGISTER_SCHEDULER(x) static const struct scheduler *x##_entry \
+  __used_section(".data.schedulers") = 
 
 struct cpupool
 {
-- 
2.6.4


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

[Xen-devel] [PATCH v4 0/5] Allow schedulers to be selectable through Kconfig

[Jonathan Creekmore]

Add machinery to allow the schedulers to be individually selectable
through the Kconfig interface. The first patch in the series sets up
the CONFIG_EXPERT Kconfig variable that is only enabled by passing an
environment variable to the build. The second patch in the series sets up
the Kconfig options for the schedulers and places the appropriate CONFIG_
options around the scheduler list. The third, fourth, and fifth patches
rework the scheduler list from being manually curated into a model
where just compiling any schedulers into the hypervisor causes the
scheduler list to be built up.

---
Changed since v3:
 * Add defensive check for schedulers in the linker

Changed since v2:
 * Added a predecessor patch that introduces a environment
   variable for the build to enable expert configuration options
   (1/5)
 * Hide the scheduler menu behind the expert option (2/5)
 * Provide static inlines for credit functions that are assumed to be
   present if it is compiled out (2/5)
 * Provide an absolute default of the credit scheduler if the 
   scheduler menu is not visible (2/5)

Changed since v1:
 * Marked credit2 as EXPERIMENTAL
 * Removed confusing language from the commit message
 * Alphabetize the schedulers
 * rename the __start and __end symbols to better match
   the rest of the file
 * Simplify the calculation of the number of schedulers
 * Make the scheduler ops structures static to their files

Jonathan Creekmore (5):
  build: Env var to enable expert config options
  build: Hook the schedulers into Kconfig
  build: Alloc space for sched list in the link file
  sched: Register the schedulers into the list
  sched: Use the auto-generated list of schedulers

 xen/Kconfig |  4 +++
 xen/Makefile|  1 +
 xen/arch/arm/xen.lds.S  |  5 
 xen/arch/x86/xen.lds.S  |  5 
 xen/common/Kconfig  | 67 +
 xen/common/Makefile |  8 +++---
 xen/common/sched_arinc653.c |  4 ++-
 xen/common/sched_credit.c   |  4 ++-
 xen/common/sched_credit2.c  |  4 ++-
 xen/common/sched_rt.c   |  4 ++-
 xen/common/schedule.c   | 20 ++
 xen/include/xen/sched-if.h  |  7 ++---
 xen/include/xen/sched.h |  5 
 13 files changed, 114 insertions(+), 24 deletions(-)

-- 
2.6.4


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

[Xen-devel] [PATCH v4 5/5] sched: Use the auto-generated list of schedulers

[Jonathan Creekmore]

Instead of having a manually-curated list of schedulers, use the array
that was auto-generated simply by compiling in the scheduler files as
the sole source of truth of the available schedulers.

CC: George Dunlap 
CC: Dario Faggioli 
Signed-off-by: Jonathan Creekmore 
Acked-by: Dario Faggioli 
Reviewed-by: Andrew Cooper 
Reviewed-by: Doug Goldstein 

---
Changed since v1:
  * Simplify the calculation of the number of schedulers
  * Make the scheduler ops structures static to their files
---
 xen/common/sched_arinc653.c |  2 +-
 xen/common/sched_credit.c   |  2 +-
 xen/common/sched_credit2.c  |  2 +-
 xen/common/sched_rt.c   |  2 +-
 xen/common/schedule.c   | 24 +++-
 xen/include/xen/sched-if.h  |  5 -
 6 files changed, 11 insertions(+), 26 deletions(-)

diff --git a/xen/common/sched_arinc653.c b/xen/common/sched_arinc653.c
index 3b59514..0606988 100644
--- a/xen/common/sched_arinc653.c
+++ b/xen/common/sched_arinc653.c
@@ -724,7 +724,7 @@ a653sched_adjust_global(const struct scheduler *ops,
  * callback functions.
  * The symbol must be visible to the rest of Xen at link time.
  */
-const struct scheduler sched_arinc653_def = {
+static const struct scheduler sched_arinc653_def = {
 .name   = "ARINC 653 Scheduler",
 .opt_name   = "arinc653",
 .sched_id   = XEN_SCHEDULER_ARINC653,
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index e586248..028e41b 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1991,7 +1991,7 @@ static void csched_tick_resume(const struct scheduler 
*ops, unsigned int cpu)
 
 static struct csched_private _csched_priv;
 
-const struct scheduler sched_credit_def = {
+static const struct scheduler sched_credit_def = {
 .name   = "SMP Credit Scheduler",
 .opt_name   = "credit",
 .sched_id   = XEN_SCHEDULER_CREDIT,
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 38b02d0..78220a7 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2194,7 +2194,7 @@ csched2_deinit(const struct scheduler *ops)
 
 static struct csched2_private _csched2_priv;
 
-const struct scheduler sched_credit2_def = {
+static const struct scheduler sched_credit2_def = {
 .name   = "SMP Credit Scheduler rev2",
 .opt_name   = "credit2",
 .sched_id   = XEN_SCHEDULER_CREDIT2,
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 7640cd0..2e5430f 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -1170,7 +1170,7 @@ rt_dom_cntl(
 
 static struct rt_private _rt_priv;
 
-const struct scheduler sched_rtds_def = {
+static const struct scheduler sched_rtds_def = {
 .name   = "SMP RTDS Scheduler",
 .opt_name   = "rtds",
 .sched_id   = XEN_SCHEDULER_RTDS,
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 2f98a48..91e53c1 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -64,20 +64,10 @@ static void poll_timer_fn(void *data);
 DEFINE_PER_CPU(struct schedule_data, schedule_data);
 DEFINE_PER_CPU(struct scheduler *, scheduler);
 
-static const struct scheduler *schedulers[] = {
-#ifdef CONFIG_SCHED_CREDIT
-_credit_def,
-#endif
-#ifdef CONFIG_SCHED_CREDIT2
-_credit2_def,
-#endif
-#ifdef CONFIG_SCHED_ARINC653
-_arinc653_def,
-#endif
-#ifdef CONFIG_SCHED_RTDS
-_rtds_def,
-#endif
-};
+extern const struct scheduler *__start_schedulers_array[], 
*__end_schedulers_array[];
+extern const size_t schedulers_array_size;
+#define NUM_SCHEDULERS (__end_schedulers_array - __start_schedulers_array)
+static const struct scheduler **schedulers = __start_schedulers_array;
 
 static struct scheduler __read_mostly ops;
 
@@ -1468,7 +1458,7 @@ void __init scheduler_init(void)
 
 open_softirq(SCHEDULE_SOFTIRQ, schedule);
 
-for ( i = 0; i < ARRAY_SIZE(schedulers); i++ )
+for ( i = 0; i < NUM_SCHEDULERS; i++)
 {
 if ( schedulers[i]->global_init && schedulers[i]->global_init() < 0 )
 schedulers[i] = NULL;
@@ -1479,7 +1469,7 @@ void __init scheduler_init(void)
 if ( !ops.name )
 {
 printk("Could not find scheduler: %s\n", opt_sched);
-for ( i = 0; i < ARRAY_SIZE(schedulers); i++ )
+for ( i = 0; i < NUM_SCHEDULERS; i++ )
 if ( schedulers[i] )
 {
 ops = *schedulers[i];
@@ -1599,7 +1589,7 @@ struct scheduler *scheduler_alloc(unsigned int sched_id, 
int *perr)
 int i;
 struct scheduler *sched;
 
-for ( i = 0; i < ARRAY_SIZE(schedulers); i++ )
+for ( i = 0; i < NUM_SCHEDULERS; i++ )
 if ( schedulers[i] && schedulers[i]->sched_id == sched_id )
 goto found;
 *perr = -ENOENT;
diff --git a/xen/include/xen/sched-if.h b/xen/include/xen/sched-if.h
index 

[Xen-devel] [PATCH v4 3/5] build: Alloc space for sched list in the link file

[Jonathan Creekmore]

Creates a section to contain scheduler entry pointers that are gathered
together into an array. This will allow, in a follow-on patch, scheduler
entries to be automatically gathered together into the array for
automatic parsing.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Jonathan Creekmore 
Reviewed-by: Doug Goldstein 

---
Changed since v3:
  * Add defensive check for schedulers in the linker

Changed since v1:
  * rename the __start and __end symbols to better match
the rest of the file
---
 xen/arch/arm/xen.lds.S | 5 +
 xen/arch/x86/xen.lds.S | 5 +
 2 files changed, 10 insertions(+)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 0488f37..2492def 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -57,6 +57,10 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
*(.data.page_aligned)
*(.data)
+   . = ALIGN(8);
+   __start_schedulers_array = .;
+   *(.data.schedulers)
+   __end_schedulers_array = .;
*(.data.rel)
*(.data.rel.*)
CONSTRUCTORS
@@ -193,3 +197,4 @@ SECTIONS
  * code running on the boot time identity map cannot cross a section boundary.
  */
 ASSERT( _end_boot - start <= PAGE_SIZE, "Boot code is larger than 4K")
+ASSERT((__end_schedulers_array - __start_schedulers_array) > 0, "no schedulers 
compiled in")
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index e18e08f..63f89af 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -80,6 +80,10 @@ SECTIONS
__stop___pre_ex_table = .;
 
*(.data.read_mostly)
+   . = ALIGN(8);
+   __start_schedulers_array = .;
+   *(.data.schedulers)
+   __end_schedulers_array = .;
*(.data.rel.ro)
*(.data.rel.ro.*)
   } :text
@@ -226,3 +230,4 @@ ASSERT(kexec_reloc_size - kexec_reloc <= PAGE_SIZE, 
"kexec_reloc is too large")
 #endif
 
 ASSERT((cpu0_stack & (STACK_SIZE - 1)) == 0, "cpu0_stack misaligned")
+ASSERT((__end_schedulers_array - __start_schedulers_array) > 0, "no schedulers 
compiled in")
-- 
2.6.4


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

Re: [Xen-devel] Missing libvirt+libxl functionality (Was: Re: [Xen-users] Programmatic administration of Xen machines)

[Jim Fehlig]

On 01/08/2016 05:46 AM, Ian Campbell wrote:
> On Thu, 2016-01-07 at 22:54 -0700, Jim Fehlig wrote:
 I had even more trouble, e.g. I wasn't able to use non-standard block
 scripts (neither via /etc/xen/scripts/block-XXX nor via a script
 parameter) which are mandatory for me.
>>> Looking at the code it seems like this is still missing.
>>>
>>> Copying the devel list and maintainer in case I've either missed something
>>> or there is a reason for this (other than "still on the TODO list", which I
>>> expect is most likely).
>> It is on a TODO list, but I'm not sure how to solve it :-/. Unlike the
>> libxl_device_disk struct, the corresponding libvirt struct does not support a
>> 'script' field, and I doubt it ever will. Repeated attempts to add a 
>> element to the  config have been rejected. The libvirt community prefers
>> all config needed to setup disks be provided in the XML, not left to a magic
>> script doing unknown things behind libvirtd's back.
> That's an understandable position for them to take, I think.
>
> If someone does use the libvirt's XML based mechanisms to configure things
> then does the libxl backend correctly plumb them through?

No, not at this time. At least not the interesting ones like nbd, iscsi, rbd
(and to some extent npiv).

>  I suppose
> something in libvirt either produces a blk device (which can be trivially
> converted to a suitable libxl disk phy thing) or a reference to some image
> file (perhaps less trivially convertable but doable, most of the time?).

That would be one approach. The other would be to pass the info to libxl. In
some use cases, it is desired/needed in libxl anyhow. I was recently
experimenting with qemu's integrated librados support, which provides native
access to block devices on ceph clusters. I hacked xl/libxl to support an 'rbd'
qdisk, adding server, port, etc. to xl.cfg and libxl_device_disk. The info was
needed when invoking qemu. nbd and iscsi qdisks could be similarly supported.
IMO, it would be unfortunate to reimplement qdisk features in the libvirt libxl
driver. Note that for many of these disk types, the libvirt qemu driver passes
the config along to qemu.

>
> If the libvirt XML stuff works then I don't see any pressing need to plumb
> Xen scripts through to libvirt if the libvirt maintainers do not want to
> support that abstract concept. If folks want functionality which would only
> be available via scripts then they should be encouraged to implement that
> functionality generically in libvirt in a way which is acceptable to the
> maintainers.

Right. That's exactly what has happened over the years as libvirt has gained
support for nbd, rbd, iscsi, and npiv disk devices.

>
> I appreciate that this might mean that some xl style cfg files cannot be
> laundered through domxml-from-native to create a working xml config, but I
> think that's a natural consequence of having two separate projects with
> somewhat non-overlapping featuresets and design goals.

Agreed, but we can strive to minimize that.

>
> I see domxml-from-native as more of a convenience for configurations which
> fall into the union of xl and libvirt's featuresets. I suppose if someone
> was feeling adventurous then they could try and have domxml-from-native
> spot some uses of well known block scripts and convert to the equivalent
> libvirt XML e.g. spot block-iscsi and convert that into equivalent libvirt
> XML objects (assuming libvirt supports iscsi, I didn't look).

Yes, that would be possible.  E.g. something like the following xl -> domxml
conversion

  disk = [ 'iscsi:iqn.2013-07.com.example:iscsi-nopool/2,xvda,w' ]

  


  


  

But as mentioned above, I think there is some benefit in supporting some of
these disk types in libxl, and hence xl.cfg. I owe the list an RFC mail about
this topic and hope to post something in the next week or two - unless the idea
is immediately discouraged :-).

Regards,
Jim


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

[Xen-devel] [qemu-upstream-4.6-testing test] 77379: regressions - FAIL

[osstest service owner]

flight 77379 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77379/

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. 63071
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 63071

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  9 debian-installfail REGR. vs. 63071
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 63071
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 63071

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  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-amd64-amd64-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-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 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-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu9e304f572ac98265f5e7433b6490077962acda97
baseline version:
 qemuu980dfcf5b8d8161871f81d1987b2f8ea5d7d4db9

Last test of basis63071  2015-10-19 15:10:58 Z   81 days
Testing same since66535  2015-12-18 15:50:42 Z   21 days9 attempts


People who touched revisions under test:
  Stefano Stabellini 

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  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 

[Xen-devel] [ovmf bisection] complete test-amd64-i386-xl-qemuu-ovmf-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid guest-start/debianhvm.repeat

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  ovmf https://github.com/tianocore/edk2.git
  Bug introduced:  b0fa5d29d08e61fd7f2178aa3b455e41374b36c4
  Bug not present: fa25cf38d988778ef3237e17fc93c1fa0c9e9f8a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/77418/


  commit b0fa5d29d08e61fd7f2178aa3b455e41374b36c4
  Author: Michael Kinney 
  Date:   Tue Dec 8 05:24:18 2015 +
  
  UefiCpuPkg/MtrrLib: Reduce hardware init when program variable MTRRs
  
  When MtrrSetMemoryAttribute() programs variable MTRRs, it may 
disable/enable
  cache and disable/enable MTRRs several times. This updating tries to do
  operation in local variable and does the hardware initialization one time 
only.
  
  Cc: Feng Tian 
  Cc: Michael Kinney 
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Michael Kinney 
  Signed-off-by: Jeff Fan 
  Reviewed-by: Feng Tian 
  
  git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19158 
6f19259b-4bc3-4df7-8a09-765794883524


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/test-amd64-i386-xl-qemuu-ovmf-amd64.guest-start--debianhvm.repeat.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/ovmf/test-amd64-i386-xl-qemuu-ovmf-amd64.guest-start--debianhvm.repeat
 --summary-out=tmp/77418.bisection-summary --basis-template=65543 
--blessings=real,real-bisect ovmf test-amd64-i386-xl-qemuu-ovmf-amd64 
guest-start/debianhvm.repeat
Searching for failure / basis pass:
 77229 fail [host=rimava1] / 66401 [host=huxelrebe0] 65677 [host=huxelrebe1] 
65624 [host=baroque0] 65593 [host=italia1] 65543 [host=pinot1] 65468 
[host=fiano0] 65386 [host=fiano1] 65359 [host=nocera1] 65336 [host=italia0] 
65319 ok.
Failure / basis pass flights: 77229 / 65319
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 5d7b0fcc26d66db767a477574effc764022c19ac 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c2a892d7c8a78143006bb7fdc95fb18f7e2fc685 
a82794b1d5a6da06062a333b1db404e2448345dd 
f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 
bf925a9f1254391749f569c1b8fc606036340488
Basis pass 769b79eb206ad5b0249a08665fefb913c3d1998e 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
dcb2e4bb61931e2dee1739bb76aba315002f0a82 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
3fb401edbd8e9741c611bfddf6a2032ca91f55ed 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#769b79eb206ad5b0249a08665fefb913c3d1998e-5d7b0fcc26d66db767a477574effc764022c19ac
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
https://github.com/tianocore/edk2.git#dcb2e4bb61931e2dee1739bb76aba315002f0a82-c2a892d7c8a78143006bb7fdc95fb18f7e2fc685
 
git://xenbits.xen.org/qemu-xen-traditional.git#bc00cad75d8bcc3ba696992bec219c21db8406aa-a82794b1d5a6da06062a333b1db404e2448345dd
 
git://xenbits.xen.org/qemu-xen.git#3fb401edbd8e9741c611bfddf6a2032ca91f55ed-f165e581d9a6f7cf81aa7496d3eee1e31212c8ad
 
git://xenbits.xen.org/xen.git#713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1-bf925a9f1254391749f569c1b8fc606036340488
>From git://cache:9419/https://github.com/tianocore/edk2
   1d3fa1b..2e26862  master -> origin/master
   1d3fa1b..2e26862  svn/trunk  -> origin/svn/trunk
Loaded 18730 nodes in revision graph
Searching for test results:
 76937 fail irrelevant
 65319 pass 769b79eb206ad5b0249a08665fefb913c3d1998e 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
dcb2e4bb61931e2dee1739bb76aba315002f0a82 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
3fb401edbd8e9741c611bfddf6a2032ca91f55ed 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 65336 [host=italia0]
 65359 [host=nocera1]
 65485 []
 65386 [host=fiano1]
 65468 [host=fiano0]
 65489 []
 65509 []
 65493 []
 65506 []
 65519 []
 65536 []
 65593 [host=italia1]
 65543 [host=pinot1]
 65677 [host=huxelrebe1]
 65624 [host=baroque0]
 66401 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 65543

version targeted for testing:
 ovmf 1d3fa1bd3817b6cdcfdf9fb502768f791c5a7c5a
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   31 days
Failing since 65593  2015-12-08 23:44:51 Z   31 days   17 attempts
Testing same since77403  2016-01-07 16:34:29 Z1 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Andrew Fish 
  Ard Biesheuvel 
  Cecil Sheng 
  Chao Zhang 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  Jim Dailey 
  Jordan Justen 
  Larry Hauch 
  Laszlo Ersek 
  Leekha Shaveta 
  Liming Gao 
  Mark Rutland 
  Michael Kinney 
  Paulo Alcantara 
  Qin Long 
  Qiu Shumin 
  Ruiyu Ni 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 

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 4365 lines long.)

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

[Xen-devel] [PATCH 1/2] build: introduce CONFIG_NR_CPUS in Kconfig

[Doug Goldstein]

Introduce an option where the user can modifiy the maximum number of
supported physical CPUs.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
---
This patch can probably be squashed together with the next one but I
broke it out with the hope that someone can check the wording on the
option and also double check the range.
---
 xen/arch/Kconfig | 8 
 xen/arch/arm/Kconfig | 2 ++
 xen/arch/x86/Kconfig | 2 ++
 3 files changed, 12 insertions(+)
 create mode 100644 xen/arch/Kconfig

diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig
new file mode 100644
index 000..791d577
--- /dev/null
+++ b/xen/arch/Kconfig
@@ -0,0 +1,8 @@
+
+config NR_CPUS
+   int "Maximum number of CPUs"
+   range 1 4095
+   default "256" if X86
+   default "128" if ARM
+   ---help---
+ Specifies the maximum number of CPUs which Xen will support.
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 2cab17b..60e923c 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -31,6 +31,8 @@ config ARCH_DEFCONFIG
 
 menu "Architecture Features"
 
+source "arch/Kconfig"
+
 # Select HAS_GICV3 if GICv3 is supported
 config HAS_GICV3
bool
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7d2ed96..e1c03bb 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -25,6 +25,8 @@ config ARCH_DEFCONFIG
 
 menu "Architecture Features"
 
+source "arch/Kconfig"
+
 endmenu
 
 source "common/Kconfig"
-- 
2.4.10


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

[Xen-devel] [PATCH XEN v3 2/2] x86/hvm: add support for pcommit instruction

[Haozhong Zhang]

Pass PCOMMIT CPU feature into HVM domain. Currently, we do not intercept
pcommit instruction for L1 guest, and allow L1 to intercept pcommit
instruction for L2 guest.

The specification of pcommit instruction can be found in
https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf

Reviewed-by: Andrew Cooper 
Acked-by: Kevin Tian 
Acked-by: Wei Liu  for tools bits
Signed-off-by: Haozhong Zhang 
---
 tools/libxc/xc_cpufeature.h|  1 +
 tools/libxc/xc_cpuid_x86.c |  1 +
 xen/arch/x86/hvm/hvm.c | 31 +++
 xen/arch/x86/hvm/vmx/vmcs.c|  9 -
 xen/arch/x86/hvm/vmx/vmx.c |  1 +
 xen/arch/x86/hvm/vmx/vvmx.c|  3 +++
 xen/include/asm-x86/cpufeature.h   |  1 +
 xen/include/asm-x86/hvm/vmx/vmcs.h |  4 +++-
 xen/include/asm-x86/hvm/vmx/vmx.h  |  1 +
 9 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/tools/libxc/xc_cpufeature.h b/tools/libxc/xc_cpufeature.h
index 5288ac6..ee53679 100644
--- a/tools/libxc/xc_cpufeature.h
+++ b/tools/libxc/xc_cpufeature.h
@@ -140,6 +140,7 @@
 #define X86_FEATURE_RDSEED  18 /* RDSEED instruction */
 #define X86_FEATURE_ADX 19 /* ADCX, ADOX instructions */
 #define X86_FEATURE_SMAP20 /* Supervisor Mode Access Protection */
+#define X86_FEATURE_PCOMMIT 22 /* PCOMMIT instruction */
 #define X86_FEATURE_CLFLUSHOPT  23 /* CLFLUSHOPT instruction */
 #define X86_FEATURE_CLWB24 /* CLWB instruction */
 
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index fecfd6c..c142595 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -427,6 +427,7 @@ static void xc_cpuid_hvm_policy(xc_interface *xch,
 bitmaskof(X86_FEATURE_ADX)  |
 bitmaskof(X86_FEATURE_SMAP) |
 bitmaskof(X86_FEATURE_FSGSBASE) |
+bitmaskof(X86_FEATURE_PCOMMIT) |
 bitmaskof(X86_FEATURE_CLWB) |
 bitmaskof(X86_FEATURE_CLFLUSHOPT));
 } else
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 21470ec..787b7de 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4583,21 +4583,28 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);
 break;
 case 0x7:
-if ( (count == 0) && !cpu_has_smep )
-*ebx &= ~cpufeat_mask(X86_FEATURE_SMEP);
+if ( count == 0 )
+{
+if ( !cpu_has_smep )
+*ebx &= ~cpufeat_mask(X86_FEATURE_SMEP);
+
+if ( !cpu_has_smap )
+*ebx &= ~cpufeat_mask(X86_FEATURE_SMAP);
 
-if ( (count == 0) && !cpu_has_smap )
-*ebx &= ~cpufeat_mask(X86_FEATURE_SMAP);
+/* Don't expose MPX to hvm when VMX support is not available */
+if ( !(vmx_vmexit_control & VM_EXIT_CLEAR_BNDCFGS) ||
+ !(vmx_vmentry_control & VM_ENTRY_LOAD_BNDCFGS) )
+*ebx &= ~cpufeat_mask(X86_FEATURE_MPX);
 
-/* Don't expose MPX to hvm when VMX support is not available */
-if ( (count == 0) &&
- (!(vmx_vmexit_control & VM_EXIT_CLEAR_BNDCFGS) ||
-  !(vmx_vmentry_control & VM_ENTRY_LOAD_BNDCFGS)) )
-*ebx &= ~cpufeat_mask(X86_FEATURE_MPX);
+/* Don't expose INVPCID to non-hap hvm. */
+if ( !hap_enabled(d) )
+*ebx &= ~cpufeat_mask(X86_FEATURE_INVPCID);
+
+/* Don't expose PCOMMIT to hvm when VMX support is not available */
+if ( !cpu_has_vmx_pcommit )
+*ebx &= ~cpufeat_mask(X86_FEATURE_PCOMMIT);
+}
 
-/* Don't expose INVPCID to non-hap hvm. */
-if ( (count == 0) && !hap_enabled(d) )
-*ebx &= ~cpufeat_mask(X86_FEATURE_INVPCID);
 break;
 case 0xb:
 /* Fix the x2APIC identifier. */
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index edd4c8d..5bc3c74 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -242,7 +242,8 @@ static int vmx_init_vmcs_config(void)
SECONDARY_EXEC_ENABLE_INVPCID |
SECONDARY_EXEC_ENABLE_VM_FUNCTIONS |
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS |
-   SECONDARY_EXEC_XSAVES);
+   SECONDARY_EXEC_XSAVES |
+   SECONDARY_EXEC_PCOMMIT);
 rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap);
 if ( _vmx_misc_cap & VMX_MISC_VMWRITE_ALL )
 opt |= SECONDARY_EXEC_ENABLE_VMCS_SHADOWING;
@@ -1075,6 +1076,12 @@ static int construct_vmcs(struct vcpu *v)
 __vmwrite(PLE_WINDOW, ple_window);
 }
 
+/*
+ * We do not intercept pcommit for L1 guest and allow L1 hypervisor to
+ * intercept pcommit for L2 guest (see 

[Xen-devel] [PATCH XEN v3 1/2] x86/hvm: allow guest to use clflushopt and clwb

[Haozhong Zhang]

Pass CPU features CLFLUSHOPT and CLWB into HVM domain so that those two
instructions can be used by guest.

The specification of above two instructions can be found in
https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf

Reviewed-by: Andrew Cooper 
Reviewed-by: Kevin Tian 
Acked-by: Wei Liu  for tools bits
Signed-off-by: Haozhong Zhang 
---
 tools/libxc/xc_cpufeature.h | 3 ++-
 tools/libxc/xc_cpuid_x86.c  | 4 +++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_cpufeature.h b/tools/libxc/xc_cpufeature.h
index c3ddc80..5288ac6 100644
--- a/tools/libxc/xc_cpufeature.h
+++ b/tools/libxc/xc_cpufeature.h
@@ -140,6 +140,7 @@
 #define X86_FEATURE_RDSEED  18 /* RDSEED instruction */
 #define X86_FEATURE_ADX 19 /* ADCX, ADOX instructions */
 #define X86_FEATURE_SMAP20 /* Supervisor Mode Access Protection */
-
+#define X86_FEATURE_CLFLUSHOPT  23 /* CLFLUSHOPT instruction */
+#define X86_FEATURE_CLWB24 /* CLWB instruction */
 
 #endif /* __LIBXC_CPUFEATURE_H */
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 8882c01..fecfd6c 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -426,7 +426,9 @@ static void xc_cpuid_hvm_policy(xc_interface *xch,
 bitmaskof(X86_FEATURE_RDSEED)  |
 bitmaskof(X86_FEATURE_ADX)  |
 bitmaskof(X86_FEATURE_SMAP) |
-bitmaskof(X86_FEATURE_FSGSBASE));
+bitmaskof(X86_FEATURE_FSGSBASE) |
+bitmaskof(X86_FEATURE_CLWB) |
+bitmaskof(X86_FEATURE_CLFLUSHOPT));
 } else
 regs[1] = 0;
 regs[0] = regs[2] = regs[3] = 0;
-- 
2.4.8


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

[Xen-devel] [PATCH XEN v3 0/2] add support for vNVDIMM - Part 1: enable instructions

[Haozhong Zhang]

I split the previous patch series "[PATCH 0/4] add support for vNVDIMM"
into two parts. This is the first part that enables clflushopt/clwb/pcommit
instructions for HVM guests.

Changes in v3:
 * Remove unnecessary hypervisor code for clflushopt and clwb in patch 1.
 * Move the code refactoring in hvm_cpuid() to patch 2.
 * Replace checking host cpuid by checking VMX capabilities for pcommit.
 * Add a tag 'XEN' in the title to address Ian Campbell's comment in
   the corresponding QEMU patch series.

Changes in v2:
 * Refactor modifications in hvm_cpuid() per Andrew Cooper's comments.

Haozhong Zhang (2):
  x86/hvm: allow guest to use clflushopt and clwb
  x86/hvm: add support for pcommit instruction

 tools/libxc/xc_cpufeature.h|  4 +++-
 tools/libxc/xc_cpuid_x86.c |  5 -
 xen/arch/x86/hvm/hvm.c | 31 +++
 xen/arch/x86/hvm/vmx/vmcs.c|  9 -
 xen/arch/x86/hvm/vmx/vmx.c |  1 +
 xen/arch/x86/hvm/vmx/vvmx.c|  3 +++
 xen/include/asm-x86/cpufeature.h   |  1 +
 xen/include/asm-x86/hvm/vmx/vmcs.h |  4 +++-
 xen/include/asm-x86/hvm/vmx/vmx.h  |  1 +
 9 files changed, 43 insertions(+), 16 deletions(-)

-- 
2.4.8


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

[Xen-devel] [linux-mingo-tip-master test] 77311: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail 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-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linuxfc4e8fa9f80e0f099838f3a9997019de36d9a4ba
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  148 days
Failing since 60712  2015-08-15 18:33:48 Z  145 days   96 attempts
Testing same since77311  2016-01-07 04:21:07 Z1 days1 attempts

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
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 pass
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-rumpuserxen-i386 fail
 

Re: [Xen-devel] [Qemu-devel] [PATCH v3 11/11] igd: move igd-passthrough-isa-bridge creation to machine init

[Stefano Stabellini]

On Thu, 7 Jan 2016, Gerd Hoffmann wrote:
> On Do, 2016-01-07 at 13:10 +, Stefano Stabellini wrote:
> > CC'ing the Xen x86 maintainers
> > 
> > On Thu, 7 Jan 2016, Gerd Hoffmann wrote:
> > >   Hi,
> > > 
> > > > One thing I don't like about this is that it is going to skip the checks
> > > > done in xen_pt_initfn.
> > > 
> > > Hmm?  Those checks are still done when you assign a igd ...
> > 
> > Their failure doesn't affect the creation of the bridge.
> 
> Doesn't their failure makes qemu throw a fatal error and exit?
> So the guest isn't going to run either way?

No, it doesn't. QEMU doesn't even print an error message.


> > > > For example it is going to create the isa bridge,
> > > > even if there is going to be an error loading the vga bios or if the
> > > > device specified is not even an Intel graphic card.
> > > 
> > > Creating the special igd-isa-bridge is no longer tied to actually
> > > assigning a igd, but to the igd-passthru=on machine option being present
> > > (and machine type being 'pc').
> > 
> > and machine type 'xenfv', unless I am mistaken?
> 
> Yes, xenfv too (uses i440fx too and thus is a 'pc' derivate).

Good


> > > xen_pt_initfn checks that igd-passthru=on is set in case it finds a igd
> > > device is assigned, that will make sure the igd-isa-bridge is present.
> > > 
> > > But, yes, you can create a igd-isa-bridge now even when not assigning a
> > > igd device, either by specifying igd-passthru=on or using -device.  I
> > > fail to see why this is a problem though, care to explain?
> > 
> > It is going to change the PCI layout of any virtual machines with a
> > config file containing
> > 
> > gfx_passthru="igd"
> > 
> > and no pci config line. A Xen 4.7 user could add gfx_passthru="igd" to
> > all her VM config files, because actually it does nothing unless an
> > Intel graphic card is assigned to the VM.
> 
> No.  It changes the host bridge even when not passing through a igd,
> because that is linked to igd-passthru=on only.
>
> So making both host bridge tweak and isa bridge tweak triggered by
> igd-passthru=on brings more consistency to the whole thing.

That is true. Given that the only qemu-xen codebase with igd support is
4.7 and 4.7 hasn't been released yet, I am OK with changing the guest
visible PCI layout. I might ask for your help in backporting the patches
;-)


> > > Also note that moving this to machine init nicely handles the fact that
> > > the igd-isa-bridge is needed on 'pc' only, not on 'q35'.  If you don't
> > > want create the igd-isa-bridge in machine init, what is your alternative
> > > suggestion to handle this?
> > 
> > Maybe we could retain the check whether an Intel graphic card has been
> > assigned? 
> 
> Should be possible, but is not that easy due to initialization order
> issues.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
59254
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   5 xen-install   fail REGR. vs. 59254
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 59254
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline 
untested
 test-amd64-i386-xl-raw6 xen-bootfail baseline untested
 test-armhf-armhf-libvirt-qcow2  6 xen-boot  fail baseline untested
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-amd64-amd64-qemuu-nested-amd  9 debian-hvm-install fail baseline untested
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host   fail baseline untested
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host   fail baseline untested
 test-amd64-amd64-libvirt-vhd  9 debian-di-install   fail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 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-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass

version targeted for testing:
 linuxb06f3a168cdcd80026276898fd1fee443ef25743
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  183 days
Failing since 59348  2015-07-10 04:24:05 Z  182 days  117 attempts
Testing same since77360  2016-01-07 11:59:09 Z1 days1 attempts


3440 people touched revisions under test,
not listing them all

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

[Xen-devel] [PATCH 2/2] build: convert NR_CPUS to Kconfig

[Doug Goldstein]

This converts the usage of NR_CPUS / MAX_PHYS_CPUS to Kconfig as
CONFIG_NR_CPUS. This should be mostly mechanical except for removing the
old MAX_PHYS_CPUS environment variable.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Andrew Cooper 
CC: Liu Jinsong 
CC: George Dunlap 
CC: Dario Faggioli 
Signed-off-by: Doug Goldstein 
---
 xen/Rules.mk  |  3 ---
 xen/arch/arm/arm64/smpboot.c  |  4 ++--
 xen/arch/arm/percpu.c |  4 ++--
 xen/arch/arm/smpboot.c| 14 +--
 xen/arch/x86/acpi/boot.c  |  4 ++--
 xen/arch/x86/acpi/cpu_idle.c  |  2 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c   |  2 +-
 xen/arch/x86/mpparse.c| 10 
 xen/arch/x86/nmi.c|  2 +-
 xen/arch/x86/numa.c   |  4 ++--
 xen/arch/x86/oprofile/nmi_int.c   |  4 ++--
 xen/arch/x86/percpu.c |  4 ++--
 xen/arch/x86/smpboot.c| 10 
 xen/arch/x86/traps.c  |  2 +-
 xen/arch/x86/xen.lds.S|  2 +-
 xen/common/core_parking.c |  6 ++---
 xen/common/cpu.c  |  8 +++
 xen/common/domain.c   |  2 +-
 xen/common/efi/runtime.c  |  4 ++--
 xen/common/gdbstub.c  |  2 +-
 xen/common/rcupdate.c |  2 +-
 xen/common/sched_credit2.c|  4 ++--
 xen/common/softirq.c  |  2 +-
 xen/common/spinlock.c |  2 +-
 xen/common/stop_machine.c |  4 ++--
 xen/common/trace.c|  4 ++--
 xen/drivers/cpufreq/utility.c |  2 +-
 xen/include/acpi/cpufreq/cpufreq.h|  2 +-
 xen/include/acpi/cpufreq/processor_perf.h |  2 +-
 xen/include/asm-arm/config.h  |  6 -
 xen/include/asm-arm/percpu.h  |  2 +-
 xen/include/asm-x86/acpi.h|  4 ++--
 xen/include/asm-x86/config.h  |  6 -
 xen/include/asm-x86/mpspec_def.h  |  2 +-
 xen/include/asm-x86/numa.h|  2 +-
 xen/include/asm-x86/percpu.h  |  2 +-
 xen/include/xen/cpumask.h | 40 +++
 xen/include/xen/sched.h   |  2 +-
 xen/include/xen/smp.h |  2 +-
 xen/include/xen/stop_machine.h|  2 +-
 40 files changed, 86 insertions(+), 101 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index f7ddc69..b5f1041 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -61,9 +61,6 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
-ifneq ($(max_phys_cpus),)
-CFLAGS-y+= -DMAX_PHYS_CPUS=$(max_phys_cpus)
-endif
 ifneq ($(max_phys_irqs),)
 CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs)
 endif
diff --git a/xen/arch/arm/arm64/smpboot.c b/xen/arch/arm/arm64/smpboot.c
index 62e6abb..e63888e 100644
--- a/xen/arch/arm/arm64/smpboot.c
+++ b/xen/arch/arm/arm64/smpboot.c
@@ -12,8 +12,8 @@ struct smp_enable_ops {
 int (*prepare_cpu)(int);
 };
 
-static paddr_t cpu_release_addr[NR_CPUS];
-static struct smp_enable_ops smp_enable_ops[NR_CPUS];
+static paddr_t cpu_release_addr[CONFIG_NR_CPUS];
+static struct smp_enable_ops smp_enable_ops[CONFIG_NR_CPUS];
 
 static int __init smp_spin_table_cpu_up(int cpu)
 {
diff --git a/xen/arch/arm/percpu.c b/xen/arch/arm/percpu.c
index e545024..0d5bb63 100644
--- a/xen/arch/arm/percpu.c
+++ b/xen/arch/arm/percpu.c
@@ -5,14 +5,14 @@
 #include 
 #include 
 
-unsigned long __per_cpu_offset[NR_CPUS];
+unsigned long __per_cpu_offset[CONFIG_NR_CPUS];
 #define INVALID_PERCPU_AREA (-(long)__per_cpu_start)
 #define PERCPU_ORDER (get_order_from_bytes(__per_cpu_data_end-__per_cpu_start))
 
 void __init percpu_init_areas(void)
 {
 unsigned int cpu;
-for ( cpu = 1; cpu < NR_CPUS; cpu++ )
+for ( cpu = 1; cpu < CONFIG_NR_CPUS; cpu++ )
 __per_cpu_offset[cpu] = INVALID_PERCPU_AREA;
 }
 
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 00b2b2a..1eae7f5 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -36,10 +36,10 @@ cpumask_t cpu_online_map;
 cpumask_t cpu_present_map;
 cpumask_t cpu_possible_map;
 
-struct cpuinfo_arm cpu_data[NR_CPUS];
+struct cpuinfo_arm cpu_data[CONFIG_NR_CPUS];
 
 /* CPU logical map: map xen cpuid to an MPIDR */
-u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
+u32 __cpu_logical_map[CONFIG_NR_CPUS] = { [0 ... CONFIG_NR_CPUS-1] = 
MPIDR_INVALID };
 
 /* Fake one node for now. See also 

Re: [Xen-devel] [libvirt] [PATCH V2 0/3] Xen: Support vif outging bandwidth QoS

[Jim Fehlig]

On 01/08/2016 09:45 AM, Michal Privoznik wrote:
> On 05.01.2016 02:08, Jim Fehlig wrote:
>> Happy New Year!
>>
>> This small series adds support for specifying vif outgoing rate limits
>> in Xen. The first patch adds support for converting rate limits between
>> sexpr config and domXML. The second patch does the same for xl/xm config.
>> The third patch adds outgoing rate limiting to the libxl driver.
>>
>> V1 here
>>
>> https://www.redhat.com/archives/libvir-list/2015-December/msg00899.html
>>
>> In V2 I've extended support to include the sexpr config format
>>
>> Jim Fehlig (3):
>>   xenconfig: support vif bandwidth in sexpr parser and formatter
>>   xenconfig: support vif bandwidth in xm and xl parser and formatter
>>   libxl: support vif outgoing bandwidth QoS
>>
>>  src/libvirt_xenconfig.syms  |  1 +
>>  src/libxl/libxl_conf.c  | 39 +
>>  src/xenconfig/xen_common.c  | 30 ++
>>  src/xenconfig/xen_sxpr.c| 74 
>> +
>>  src/xenconfig/xen_sxpr.h|  2 +
>>  tests/sexpr2xmldata/sexpr2xml-vif-rate.sexpr| 11 
>>  tests/sexpr2xmldata/sexpr2xml-vif-rate.xml  | 51 +
>>  tests/sexpr2xmltest.c   |  2 +
>>  tests/xlconfigdata/test-vif-rate.cfg| 26 +
>>  tests/xlconfigdata/test-vif-rate.xml| 57 +++
>>  tests/xlconfigtest.c|  1 +
>>  tests/xml2sexprdata/xml2sexpr-fv-net-rate.sexpr | 10 
>>  tests/xml2sexprdata/xml2sexpr-fv-net-rate.xml   | 34 
>>  tests/xml2sexprtest.c   |  1 +
>>  14 files changed, 339 insertions(+)
>>  create mode 100644 tests/sexpr2xmldata/sexpr2xml-vif-rate.sexpr
>>  create mode 100644 tests/sexpr2xmldata/sexpr2xml-vif-rate.xml
>>  create mode 100644 tests/xlconfigdata/test-vif-rate.cfg
>>  create mode 100644 tests/xlconfigdata/test-vif-rate.xml
>>  create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-rate.sexpr
>>  create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-rate.xml
>>
> ACK series.

Thanks a lot for helping review Xen patches! :-) Pushed now.

Regards,
Jim


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

Re: [Xen-devel] [PATCH v3 2/5] remus: resume immediately if libxl__xc_domain_save_done() completes

[Andrew Cooper]

On 08/01/16 06:38, Wen Congyang wrote:
> For example: if the secondary host is down, and we fail to send the data to
> the secondary host. xc_domain_save() returns 0. So in the function
> libxl__xc_domain_save_done(), rc is 0(the helper program exits normally),
> and retval is 0(it is xc_domain_save()'s return value). In such case, we
> just need to complete the stream.
>
> Signed-off-by: Wen Congyang 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 3/3] checkpatch: add virt barriers

[Michael S. Tsirkin]

On Mon, Jan 04, 2016 at 02:11:37PM -0800, Joe Perches wrote:
> On Mon, 2016-01-04 at 23:07 +0200, Michael S. Tsirkin wrote:
> > On Mon, Jan 04, 2016 at 08:47:53AM -0800, Joe Perches wrote:
> > > On Mon, 2016-01-04 at 13:37 +0200, Michael S. Tsirkin wrote:
> > > > Add virt_ barriers to list of barriers to check for
> > > > presence of a comment.
> > > 
> > > Are these virt_ barriers used anywhere?
> > > 
> > > I see some virtio_ barrier like uses.
> > 
> > They will be :) They are added and used by patchset
> > arch: barrier cleanup + barriers for virt
> > 
> > See
> > http://article.gmane.org/gmane.linux.kernel.virtualization/26555
> 
> Ah, OK, thanks.
> 
> Are the virtio_ barriers going away?
> If not, maybe those should be added too.

I don't mind. I'll queue a patch like that.


-- 
MST

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

Re: [Xen-devel] [OSSTEST PATCH 0/7] Better database handling in Tcl

[Ian Campbell]

On Thu, 2016-01-07 at 19:38 +, Ian Jackson wrote:
> This series arranges for the owner daemon to be able to tolerate
> database restarts, and is generally much more careful about database
> errors in Tcl.

I had a trivial comment on #3's commit message, assuming that rather than
the code is wrong, Ack.

I spotted a few typos in #5's commit message too. I asked about renaming
db-execute-array db-{execute-,}select, but either way Ack.

I'm not going to claim I really understood all the Tcl (especially towards
the end of the series), but you've tested it, which is good enough I think.

IOW, all Acked-by: Ian Campbell 
(with small caveats on #3 and #5)

Ian.

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

Re: [Xen-devel] [PATCH v3 08/13] x86/hvm: Setup TSC scaling ratio

[Jan Beulich]

>>> On 31.12.15 at 04:03,  wrote:
> @@ -301,6 +302,42 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
>  return 1;
>  }
>  
> +bool_t hvm_validate_tsc_scaling_ratio(uint32_t gtsc_khz)
> +{
> +u64 ratio;
> +
> +if ( !hvm_funcs.tsc_scaling_supported )
> +return FALSE;

We use 0 and 1, not FALSE and TRUE (except in ACPI and EFI code).

> +ratio = mul_u64_u32_div(1ULL << hvm_funcs.tsc_scaling_ratio_frac_bits,
> +gtsc_khz, cpu_khz);
> +
> +return (!ratio || ratio > hvm_funcs.max_tsc_scaling_ratio) ? FALSE : 
> TRUE;

There no point in using a conditional expression here.

> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -226,6 +226,9 @@ struct hvm_function_table {
>  int (*altp2m_vcpu_emulate_vmfunc)(struct cpu_user_regs *regs);
>  
>  uint64_t (*scale_tsc)(struct vcpu *v, uint64_t tsc);
> +
> +/* Architecture function to setup TSC scaling ratio */
> +void (*setup_tsc_scaling)(struct vcpu *v);

SVM doesn't use this hook, and VMX gets to use it only later. I.e.
everything related to it is dead code right now, and would therefore
better go into the VMX (I suppose) patch actually making use of it.

Jan


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

Re: [Xen-devel] [PATCH v4.1] libxc: Defer initialization of start_page for HVM guests

[Ian Campbell]

On Thu, 2016-01-07 at 17:11 -0500, Boris Ostrovsky wrote:
> With commit 8c45adec18e0 ("libxc: create unmapped initrd in domain
> builder if supported") location of ramdisk may not be available to
> HVMlite guests by the time alloc_magic_pages_hvm() is invoked if the
> guest supports unmapped initrd.
> 
> So let's move ramdisk info initialization (along with a few other
> operations that are not directly related to allocating magic/special
> pages) from alloc_magic_pages_hvm() to bootlate_hvm().

The "few other operations" are just the hvm_info init for standard HVM by
this iteration?

> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -71,6 +71,7 @@ struct xc_dom_image {
>  
>  /* arguments and parameters */
>  char *cmdline;
> +size_t cmdline_size;

Perhaps /* Including NULL and padding/alignment */ ?

(That's the sort of thing I don't mind doing on commit if there is
agreement and no other changes required)

> @@ -1095,8 +1044,8 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>  /* Set the IP. */
>  bsp_ctx.cpu.rip = dom->parms.phys_entry;
>  
> -if ( dom->start_info_pfn )
> -bsp_ctx.cpu.rbx = dom->start_info_pfn << PAGE_SHIFT;
> +if ( dom->start_info_seg.pfn )
> +bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;

Just to check: dom->start_info_pfn is unused/nil in the regular-hvm case,
correct (i.e. this code is dm-list specific both before and after)?

> +else
> +{
> +void *hvm_info_page;
> +
> +if ( (hvm_info_page = xc_map_foreign_range(
> +  xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
> +  HVM_INFO_PFN)) == NULL )
> +return -1;
> +build_hvm_info(hvm_info_page, dom);
> +munmap(hvm_info_page, PAGE_SIZE);
> +}

Did you test regular HVM guests after this movement?

Ian.


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

Re: [Xen-devel] [PATCH v4.2] libxc: Defer initialization of start_page for HVM guests

[Ian Campbell]

On Thu, 2016-01-07 at 17:19 -0500, Boris Ostrovsky wrote:
> v4:
>  * See the last two paragraphs from commit message above
> 
> v4.1:
>  * Inverted testing of start_info_size in bootlate_hvm().
> 
> v4.2
>  *  Actually do what I said I'd do in 4.1

I was so proud of myself for spotting 4.1 just before I reviewed 4, I
didn't think to look for a 4.2 ;-)

Ian.

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

[Xen-devel] [xen-4.4-testing test] 77307: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-prev  5 xen-build fail REGR. vs. 66458
 build-i386-prev   5 xen-build fail REGR. vs. 66458
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 66458
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 66458
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 66458
 test-amd64-i386-xl-qemut-debianhvm-amd64 14 guest-saverestore.2 fail REGR. vs. 
66458

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail  like 66458

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail 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-xend-qemut-winxpsp3 20 leak-check/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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-amd64-libvirt-vhd 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:
 xen  e003d429d8c63523df40663b4586c572ce796659
baseline version:
 xen  d0b73c9bf21f9199401a36eeda7ba0a4412aad6d

Last test of basis66458  2015-12-17 09:42:47 Z   22 days
Failing since 66520  2015-12-18 10:37:08 Z   20 days   10 attempts
Testing same since77307  2016-01-07 03:41:39 Z1 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  Ed Swierk 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev fail
 build-i386-prev  fail
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen  

[Xen-devel] [PATCH v6] x86/VPMU: implement ipc and arch filter flags

[Brendan Gregg]

This introduces a way to have a restricted VPMU, by specifying one of two
predefined groups of PMCs to make available. For secure environments, this
allows the VPMU to be used without needing to enable all PMCs.

Signed-off-by: Brendan Gregg 
Reviewed-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
---
Changes in v6:
* addressing review comments from Jan:
* code style changes
* updated sysfs PMU interface flag check

Changes in v5:
* addressing review comments from Kevin:
* simplified BTS DS_AREA filter
* improvements to comments, incl. matching Intel SDM descriptions

Changes in v4:
* changed table reference in comments, suggested by Dietmar

Changes in v3:
* addressing review comments from Boris:
* ensure final flag is validated
* code tidy

Changes in v2:
* feature flags can now be combined (eg, "vpmu=ipc,bts")
* addressing review comments from Boris:
* restrict DS_AREA and PEBS_ENABLE access when filters are in use
* better variable types
* include MSR_IA32_CMT_EVTSEL_UE_MASK flag
---
 docs/misc/xen-command-line.markdown | 15 +-
 xen/arch/x86/cpu/vpmu.c | 55 +
 xen/arch/x86/cpu/vpmu_intel.c   | 44 +
 xen/include/asm-x86/msr-index.h |  1 +
 xen/include/public/pmu.h| 14 --
 5 files changed, 114 insertions(+), 15 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 467dc8f..5ed0730 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1476,7 +1476,7 @@ Use Virtual Processor ID support if available.  This 
prevents the need for TLB
 flushes on VM entry and exit, increasing performance.
 
 ### vpmu
-> `= ( bts )`
+> `= (  | { bts | ipc | arch [, ...] } )`
 
 > Default: `off`
 
@@ -1492,6 +1492,19 @@ wrong behaviour (see handle\_pmc\_quirk()).
 If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
 feature is switched on on Intel processors supporting this feature.
 
+vpmu=ipc enables performance monitoring, but restricts the counters to the
+most minimum set possible: instructions, cycles, and reference cycles. These
+can be used to calculate instructions per cycle (IPC).
+
+vpmu=arch enables performance monitoring, but restricts the counters to the
+pre-defined architectural events only. These are exposed by cpuid, and listed
+in the Pre-Defined Architectural Performance Events table from the Intel 64
+and IA-32 Architectures Software Developer's Manual, Volume 3B, System
+Programming Guide, Part 2.
+
+If a boolean is not used, combinations of flags are allowed, comma separated.
+For example, vpmu=arch,bts.
+
 Note that if **watchdog** option is also specified vpmu will be turned off.
 
 *Warning:*
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 4856e98..5ca1db5 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -43,34 +43,59 @@ CHECK_pmu_data;
 CHECK_pmu_params;
 
 /*
- * "vpmu" : vpmu generally enabled
- * "vpmu=off" : vpmu generally disabled
- * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
+ * "vpmu" : vpmu generally enabled (all counters)
+ * "vpmu=off"  : vpmu generally disabled
+ * "vpmu=bts"  : vpmu enabled and Intel BTS feature switched on.
+ * "vpmu=ipc"  : vpmu enabled for IPC counters only (most restrictive)
+ * "vpmu=arch" : vpmu enabled for predef arch counters only (restrictive)
+ * flag combinations are allowed, eg, "vpmu=ipc,bts".
  */
 static unsigned int __read_mostly opt_vpmu_enabled;
 unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
 unsigned int __read_mostly vpmu_features = 0;
-static void parse_vpmu_param(char *s);
-custom_param("vpmu", parse_vpmu_param);
+static void parse_vpmu_params(char *s);
+custom_param("vpmu", parse_vpmu_params);
 
 static DEFINE_SPINLOCK(vpmu_lock);
 static unsigned vpmu_count;
 
 static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
 
-static void __init parse_vpmu_param(char *s)
+static int parse_vpmu_param(char *s, unsigned int len)
 {
+if ( !*s || !len )
+return 0;
+if ( !strncmp(s, "bts", len) )
+vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
+else if ( !strncmp(s, "ipc", len) )
+vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
+else if ( !strncmp(s, "arch", len) )
+vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
+else
+return 1;
+return 0;
+}
+
+static void __init parse_vpmu_params(char *s)
+{
+char *sep, *p = s;
+
 switch ( parse_bool(s) )
 {
 case 0:
 break;
 default:
-if ( !strcmp(s, "bts") )
-vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
-else if ( *s )
+while (1)
 {
-printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
-break;
+sep = strchr(p, ',');
+if ( sep == NULL )
+sep = strchr(p, 0);
+if ( 

Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Stefano Stabellini]

Since you are at it, could you please let me know how well igd
passthrough works without this bugfix:

http://marc.info/?l=qemu-devel=145172165010604

which is about to land in QEMU.  I guess it doesn't work at all?

I am asking because I would like to know the level of support we need to
provide to igd passthrough with the latest QEMU release (2.5).


On Thu, 7 Jan 2016, Hao, Xudong wrote:
> Sure. I'll test it soon.
> 
> Thanks,
> -Xudong
> 
> > -Original Message-
> > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> > Sent: Wednesday, January 6, 2016 8:18 PM
> > To: Lars Kurth 
> > Cc: Stefano Stabellini ; Hao, Xudong
> > ; Lars Kurth ; Cao jin
> > ; xen-de...@lists.xensource.com; Stefano 
> > Stabellini
> > ; qemu-de...@nongnu.org; Michael S. Tsirkin
> > 
> > Subject: Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to 
> > realize()
> > 
> > Hello Xudong,
> > 
> > please test this patch:
> > 
> > http://marc.info/?l=qemu-devel=145137863501079
> > 
> > with an intel graphic card assigned to a Xen guest. If everything still 
> > works as
> > expected, please reply with your Tested-by.
> > 
> > Thanks,
> > 
> > Stefano
> > 
> > On Wed, 6 Jan 2016, Lars Kurth wrote:
> > > Hi folks,
> > > let me introduce you to Xudong from Intel, who is willing to help out.
> > > Best Regards
> > > Lars
> > >
> > > > On 4 Jan 2016, at 15:41, Stefano Stabellini 
> > > > 
> > wrote:
> > > >
> > > > On Mon, 4 Jan 2016, Lars Kurth wrote:
> > > >> On 04/01/2016 14:47, "Stefano Stabellini"
> > > >>  wrote:
> > > >>
> > > >>> Unfortunately I don't have a setup to test this either. Maybe Lars
> > > >>> can find out who should be involved on the Intel side on this.
> > > >>
> > > >> I can certainly help to this and get back to you. What exactly are
> > > >> we asking Intel to do?
> > > >> It is not clear to me from this email thread
> > > >
> > > > Tiejun Chen, the author of the Intel graphic card passthrough
> > > > patches for QEMU, seems to have left the company. It would be nice
> > > > if somebody else tested this patch with an intel graphic card
> > > > assigned to a guest VM.
> > > >
> > > > ___
> > > > 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] [qemu-upstream-4.2-testing test] 77180: regressions - FAIL

[Ian Jackson]

Ian Campbell writes ("Re: [qemu-upstream-4.2-testing test] 77180: regressions - 
FAIL"):
> So our choices WRT these fixes in qemu-xen.git#staging-4.2, given they have
> already been pushed, are:
> 
>4. Force push.

We (Ian C, Stefano and myself) had a conversation in which we decided
that this was probably the best option.  But we will wait for the
other qemuu trees to pass their push gates so only 4.2 is outstanding,
to avoid force pushing any other problems.

Ian.

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

[Xen-devel] [PATCH v2] tools/libxc: Adjust error handling in map_p2m_list() to fix CentOS 7 build

[Andrew Cooper]

The "goto err;" for malloc() error handling would cause the cleanup code
to use 'ptes' before it had been initialised, and causing a build
failure because of -Werror=maybe-uninitialised.

Use "goto err;" consistently for all error handling.

Signed-off-by: Andrew Cooper 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: Juergen Gross 
---
 tools/libxc/xc_sr_save_x86_pv.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libxc/xc_sr_save_x86_pv.c b/tools/libxc/xc_sr_save_x86_pv.c
index 4deb58f..4a29460 100644
--- a/tools/libxc/xc_sr_save_x86_pv.c
+++ b/tools/libxc/xc_sr_save_x86_pv.c
@@ -316,8 +316,8 @@ static int map_p2m_list(struct xc_sr_context *ctx, uint64_t 
p2m_cr3)
 xc_interface *xch = ctx->xch;
 xen_vaddr_t p2m_vaddr, p2m_end, mask, off;
 xen_pfn_t p2m_mfn, mfn, saved_mfn, max_pfn;
-uint64_t *ptes;
-xen_pfn_t *mfns;
+uint64_t *ptes = NULL;
+xen_pfn_t *mfns = NULL;
 unsigned fpp, n_pages, level, shift, idx_start, idx_end, idx, saved_idx;
 int rc = -1;
 
@@ -327,7 +327,7 @@ static int map_p2m_list(struct xc_sr_context *ctx, uint64_t 
p2m_cr3)
 {
 ERROR("Bad p2m_cr3 value %#" PRIx64, p2m_cr3);
 errno = ERANGE;
-return -1;
+goto err;
 }
 
 get_p2m_generation(ctx);
@@ -350,7 +350,7 @@ static int map_p2m_list(struct xc_sr_context *ctx, uint64_t 
p2m_cr3)
 ERROR("Bad virtual p2m address range %#" PRIx64 "-%#" PRIx64,
   p2m_vaddr, p2m_end);
 errno = ERANGE;
-return -1;
+goto err;
 }
 }
 else
@@ -363,7 +363,7 @@ static int map_p2m_list(struct xc_sr_context *ctx, uint64_t 
p2m_cr3)
 ERROR("Bad virtual p2m address range %#" PRIx64 "-%#" PRIx64,
   p2m_vaddr, p2m_end);
 errno = ERANGE;
-return -1;
+goto err;
 }
 }
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 25/28] libxl: emuids: Perhaps change dm xs control path

[Ian Campbell]

On Fri, 2016-01-08 at 14:45 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 25/28] libxl: emuids: Perhaps change dm
> xs control path"):
> > On Fri, 2016-01-08 at 14:12 +, Ian Jackson wrote:
> > >   * In xenstore we record which qemus a domain has.  This is
> > > necessary
> > >   * for correct teardown.  And, we also record whether the xenstore
> > >   * paths are unified, as discussed above, so that subsequent libxl
> > >   * operations can do the right thing.  This is what the EMUID_SPLIT
> > >   * flag is for.
> > 
> > EMUID_SPLIT actually records the inverse (i.e. that they are split,
> > rather
> > than unified as the previous text is discussing).
> > 
> > I knew what you meant though, and clarifying it could well make it less
> > obvious I suspect.
> 
> Yes.  I could explain the reason for the sense of the flag, which is
> to get the default right, but that seems obvious.
> 
> How about:
> 
> > >   * In xenstore we record which qemus a domain has.  This is
> > >   * necessary for correct teardown.  And, we also record whether
> > >   * the xenstore paths are split or unified, as discussed above,
>    
> > >   * so that subsequent libxl operations can do the right
> > >   * thing.  This is what the EMUID_SPLIT flag is for.
> 
> ?

Looks good, thanks.

Ian.


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

Re: [Xen-devel] [PATCH XEN v3 0/2] add support for vNVDIMM - Part 1: enable instructions

[Haozhong Zhang]

On 01/08/16 04:50, Jan Beulich wrote:
> >>> On 08.01.16 at 11:46,  wrote:
> > I split the previous patch series "[PATCH 0/4] add support for vNVDIMM"
> > into two parts. This is the first part that enables clflushopt/clwb/pcommit
> > instructions for HVM guests.
> > 
> > Changes in v3:
> >  * Remove unnecessary hypervisor code for clflushopt and clwb in patch 1.
> 
> Which should have led to a Cc list reduction.
>

I'll take care in the next time.

> >  * Move the code refactoring in hvm_cpuid() to patch 2.
> >  * Replace checking host cpuid by checking VMX capabilities for pcommit.
> 
> Replace?
>

Yes, akin to how MPX is checked in hvm_cpuid(). Or do you mean it's
better to check host cpuid as well?

Haozhong

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

[Xen-devel] [PATCH v3 11/15] xenstore: add init-xenstore-domain parameter to specify cmdline

[Juergen Gross]

Add a parameter to init-xenstore-domain for support of arbitrary
parameters for the xenstore domain.

Signed-off-by: Juergen Gross 
Acked-by: Ian Campbell 
Acked-by: Daniel De Graaf 
---
 tools/helpers/init-xenstore-domain.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index ecced04..238007b 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -17,6 +17,7 @@ static uint32_t domid = ~0;
 static char *kernel;
 static char *ramdisk;
 static char *flask;
+static char *param;
 static int memory;
 
 static struct option options[] = {
@@ -24,6 +25,7 @@ static struct option options[] = {
 { "memory", 1, NULL, 'm' },
 { "flask", 1, NULL, 'f' },
 { "ramdisk", 1, NULL, 'r' },
+{ "param", 1, NULL, 'p' },
 { NULL, 0, NULL, 0 }
 };
 
@@ -39,7 +41,8 @@ static void usage(void)
 "  --kernel  kernel file of the xenstore domain, mandatory\n"
 "  --memory  size of the domain in MB, mandatory\n"
 "  --flask   optional flask label of the domain\n"
-"  --ramdiskoptional ramdisk file for the domain\n");
+"  --ramdiskoptional ramdisk file for the domain\n"
+"  --param   optional additional parameters for the 
domain\n");
 }
 
 static int build(xc_interface *xch)
@@ -103,7 +106,11 @@ static int build(xc_interface *xch)
 fprintf(stderr, "Xenbus setup ioctl failed\n");
 goto err;
 }
-snprintf(cmdline, 512, "--event %d --internal-db", rv);
+
+if ( param )
+snprintf(cmdline, 512, "--event %d --internal-db %s", rv, param);
+else
+snprintf(cmdline, 512, "--event %d --internal-db", rv);
 
 dom = xc_dom_allocate(xch, cmdline, NULL);
 rv = xc_dom_kernel_file(dom, kernel);
@@ -233,6 +240,9 @@ int main(int argc, char** argv)
 case 'r':
 ramdisk = optarg;
 break;
+case 'p':
+param = optarg;
+break;
 default:
 usage();
 return 2;
-- 
2.6.2


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

Re: [Xen-devel] [PATCH v3 05/13] svm: Remove redundant TSC scaling in svm_set_tsc_offset()

[Haozhong Zhang]

On 01/08/16 02:22, Jan Beulich wrote:
> >>> On 31.12.15 at 04:03,  wrote:
> > @@ -854,6 +841,7 @@ static void svm_set_tsc_offset(struct vcpu *v, u64 
> > offset, u64 at_tsc)
> >  n2_tsc_offset = vmcb_get_tsc_offset(n2vmcb) -
> >  vmcb_get_tsc_offset(n1vmcb);
> >  if ( svm->ns_tscratio != DEFAULT_TSC_RATIO ) {
> > +uint64_t guest_tsc = hvm_get_guest_tsc_fixed(v, at_tsc);
> >  n2_tsc_offset = svm_get_tsc_offset(guest_tsc,
> 
> Blank line between declaration(s) and statement(s) please.
> 
> Also please consider taking the opportunity to fix the preceding
> line's coding style violation.
> 
> Jan

OK, both will be fixed in the next version.

Haozhong

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

Re: [Xen-devel] [PATCH v3 04/13] x86/time.c: Scale host TSC in pvclock properly

[Haozhong Zhang]

On 01/08/16 06:43, Jan Beulich wrote:
> >>> On 08.01.16 at 14:22,  wrote:
> > On 01/08/16 02:20, Jan Beulich wrote:
> >> >>> On 31.12.15 at 04:03,  wrote:
> >> > --- a/xen/arch/x86/time.c
> >> > +++ b/xen/arch/x86/time.c
> >> > @@ -815,10 +815,18 @@ static void __update_vcpu_system_time(struct vcpu 
> >> > *v, int force)
> >> >  }
> >> >  else
> >> >  {
> >> > -tsc_stamp = t->local_tsc_stamp;
> >> > -
> >> > -_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
> >> > -_u.tsc_shift = (s8)t->tsc_scale.shift;
> >> > +if ( has_hvm_container_domain(d) && cpu_has_tsc_ratio )
> >> 
> >> For symmetry with patches 1 and 2 I'd expect !d->arch.vtsc to be
> >> added here too.
> > 
> > even though it's already in the !d->arch.vtsc branch? But I'm fine to
> > add it for symmetric.
> 
> Ah, no, I didn't realize (only looking at the patch) that it's in the
> else to a respective if(). No need to change it then.
> 
> >> > +{
> >> > +tsc_stamp= hvm_funcs.scale_tsc(v, 
> > t->local_tsc_stamp);
> >> > +_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
> >> > +_u.tsc_shift = d->arch.vtsc_to_ns.shift;
> >> > +}
> >> > +else
> >> > +{
> >> > +tsc_stamp= t->local_tsc_stamp;
> >> > +_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
> >> > +_u.tsc_shift = (s8)t->tsc_scale.shift;
> >> 
> >> The case has been pointless anyway, and you don't add a similar
> >> one in the if() branch - please delete it.
> > 
> > I don't understand why it's pointless. The inner if branch is to
> > ensure pvclock provides the scaled TSC information when TSC scaling is
> > used, and the inner else branch is to keep the existing behavior when
> > TSC scaling is not used. For the outer if branch, TSC scaling is never
> > used, so no change is needed.
> 
> Sorry, I see I typo-ed my reply. It was meant to start "The cast
> has been ..."
> 
OK, I'll remove it.

Haozhong

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

Re: [Xen-devel] [PATCH v3 01/15] xen: add xenstore domain flag to hypervisor

[Juergen Gross]

On 08/01/16 15:07, Jan Beulich wrote:
 On 08.01.16 at 14:08,  wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -318,6 +318,12 @@ struct domain *domain_create(domid_t domid, unsigned 
>> int domcr_flags,
>>  hardware_domain = d;
>>  }
>>  
>> +if ( domcr_flags & DOMCRF_xs_domain )
>> +{
>> +d->is_xenstore = 1;
>> +d->disable_migrate = 1;
>> +}
> 
> It only occurred to me now: Wouldn't it be worth denying the domain
> creation request if there already is a xenstore domain?

Hmm, the only cases where this would make sense would be:

- some bug in dom0 resulting in parallel calls of init-xenstore-domain
- an out-of-tree tool in dom0 (or another domain capable of creating
  domains) creating a domain with the xenstore flag set

I'm really not sure what would be best here. Should the hypervisor
really be responsible for this decision?

In case it is desired, I can modify the patch accordingly (the
modification would be trivial).


Juergen

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

Re: [Xen-devel] [PATCH v2] tools/libxc: Adjust error handling in map_p2m_list() to fix CentOS 7 build

[Juergen Gross]

On 08/01/16 15:38, Andrew Cooper wrote:
> The "goto err;" for malloc() error handling would cause the cleanup code
> to use 'ptes' before it had been initialised, and causing a build
> failure because of -Werror=maybe-uninitialised.
> 
> Use "goto err;" consistently for all error handling.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Juergen Gross 

> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Juergen Gross 
> ---
>  tools/libxc/xc_sr_save_x86_pv.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxc/xc_sr_save_x86_pv.c b/tools/libxc/xc_sr_save_x86_pv.c
> index 4deb58f..4a29460 100644
> --- a/tools/libxc/xc_sr_save_x86_pv.c
> +++ b/tools/libxc/xc_sr_save_x86_pv.c
> @@ -316,8 +316,8 @@ static int map_p2m_list(struct xc_sr_context *ctx, 
> uint64_t p2m_cr3)
>  xc_interface *xch = ctx->xch;
>  xen_vaddr_t p2m_vaddr, p2m_end, mask, off;
>  xen_pfn_t p2m_mfn, mfn, saved_mfn, max_pfn;
> -uint64_t *ptes;
> -xen_pfn_t *mfns;
> +uint64_t *ptes = NULL;
> +xen_pfn_t *mfns = NULL;
>  unsigned fpp, n_pages, level, shift, idx_start, idx_end, idx, saved_idx;
>  int rc = -1;
>  
> @@ -327,7 +327,7 @@ static int map_p2m_list(struct xc_sr_context *ctx, 
> uint64_t p2m_cr3)
>  {
>  ERROR("Bad p2m_cr3 value %#" PRIx64, p2m_cr3);
>  errno = ERANGE;
> -return -1;
> +goto err;
>  }
>  
>  get_p2m_generation(ctx);
> @@ -350,7 +350,7 @@ static int map_p2m_list(struct xc_sr_context *ctx, 
> uint64_t p2m_cr3)
>  ERROR("Bad virtual p2m address range %#" PRIx64 "-%#" PRIx64,
>p2m_vaddr, p2m_end);
>  errno = ERANGE;
> -return -1;
> +goto err;
>  }
>  }
>  else
> @@ -363,7 +363,7 @@ static int map_p2m_list(struct xc_sr_context *ctx, 
> uint64_t p2m_cr3)
>  ERROR("Bad virtual p2m address range %#" PRIx64 "-%#" PRIx64,
>p2m_vaddr, p2m_end);
>  errno = ERANGE;
> -return -1;
> +goto err;
>  }
>  }
>  
> 


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

Re: [Xen-devel] [PATCH XEN v3 0/2] add support for vNVDIMM - Part 1: enable instructions

[Jan Beulich]

>>> On 08.01.16 at 11:46,  wrote:
> I split the previous patch series "[PATCH 0/4] add support for vNVDIMM"
> into two parts. This is the first part that enables clflushopt/clwb/pcommit
> instructions for HVM guests.
> 
> Changes in v3:
>  * Remove unnecessary hypervisor code for clflushopt and clwb in patch 1.

Which should have led to a Cc list reduction.

>  * Move the code refactoring in hvm_cpuid() to patch 2.
>  * Replace checking host cpuid by checking VMX capabilities for pcommit.

Replace?

Jan


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

Re: [Xen-devel] [PATCH 21/28] libxl: dm user: Reject attempts to set user!=root with qemu trad

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 21/28] libxl: dm user: Reject attempts to set 
user!=root with qemu trad"):
> On Tue, 2015-12-22 at 18:44 +, Ian Jackson wrote:
> > Previously this option would be silently ignored, which is a potential
> > security problem (introduced in 84f2fd1b "run QEMU as non-root" in
> > xen-unstable only).
> > 
> > Signed-off-by: Ian Jackson 
> > CC: Stefano Stabellini 
> 
> Acked-by: Ian Campbell 
> (could/should go in now despite RFC-ness of the series as a whole, assuming
> it is as independent as it looks, we really don't want to forget this for
> 4.7 if the other 27 patches take longer to land)

Well, it moved easily to earlier in the series, so I have done that.
But there are other things wrong with 84f2fd1b which are sorted out
here, too.  I think if this series doesn't make 4.7 we may need to
revert 84f2fd1b, or at least consider other parts of this series to
cherry pick.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH 21/28] libxl: dm user: Reject attempts to set user!=root with qemu trad

[Ian Campbell]

On Fri, 2016-01-08 at 12:16 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 21/28] libxl: dm user: Reject attempts
> to set user!=root with qemu trad"):
> > On Tue, 2015-12-22 at 18:44 +, Ian Jackson wrote:
> > > Previously this option would be silently ignored, which is a
> > > potential
> > > security problem (introduced in 84f2fd1b "run QEMU as non-root" in
> > > xen-unstable only).
> > > 
> > > Signed-off-by: Ian Jackson 
> > > CC: Stefano Stabellini 
> > 
> > Acked-by: Ian Campbell 
> > (could/should go in now despite RFC-ness of the series as a whole,
> > assuming
> > it is as independent as it looks, we really don't want to forget this
> > for
> > 4.7 if the other 27 patches take longer to land)
> 
> Well, it moved easily to earlier in the series, so I have done that.
> But there are other things wrong with 84f2fd1b which are sorted out
> here, too.  I think if this series doesn't make 4.7 we may need to
> revert 84f2fd1b, or at least consider other parts of this series to
> cherry pick.

Makes sense, I assume you'll either propose that revert of a suitable list
of cherry-picks if/when the time comes.

Ian.

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

Re: [Xen-devel] [PATCH 25/28] libxl: emuids: Perhaps change dm xs control path

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 25/28] libxl: emuids: Perhaps change dm xs 
control path"):
> So, do I understand correctly that the states (combinations of bits) are:

No.

> Describing SPLIT as an "ID" is a bit odd (it's a kind of meta thing) but I
> suppose I can see why it is done this way. An alternative might be to have
> a separate bit for the PV|DM case together, maybe you discarded that
> possibility though?

Perhaps things will be clearer with this comment, which I've just
added to add in this patch:

 /*
  * This EMUID enum is used for several overlapping purposes.
  *
  * Each qemu process has an EMUID, which is either EMUID_PV or
  * EMUID_DM.
  *
  * Operations which talk to a qemu process need to know its emuid so
  * that they talk to the right one.  (Specifically, so that they find
  * the right place in xenstore.)  Likewise a qemu process needs to
  * be told its emuid for the same reason.
  *
  * However, qemut and older versions of qemuu do not support emuids.
  * In that case for an HVM domain, the same qemu process deals with
  * both roles.  In this situation the xenstore paths for PV backend
  * control do not include the emuid, and therefore we can talk to the
  * single qemu `via' `both' emuids.
  *
  * In xenstore we record which qemus a domain has.  This is necessary
  * for correct teardown.  And, we also record whether the xenstore
  * paths are unified, as discussed above, so that subsequent libxl
  * operations can do the right thing.  This is what the EMUID_SPLIT
  * flag is for.
  *
  * Overall, the following scenarios are possible:
  *
  * dm-emuidmaplibxl__device_model_xs_path
  * can be passed  control xs paths
  *  which emuids? contain what
  *to distinguish
  *
  *   0No QEMU processes   PV -
  *   PV   PV domain   PV -
  *   PV   HVM domain with stub dm PV; HVMstubdomid
  *  DMHVM domain, 1 QEMU  PV; HVM-
  *   PV|DM|SPLIT  HVM domain, 2 QEMUs privsep PV; HVMemuid
  *
  * The following scenarios would be handled correctly but are not set up
  * by current libxl code, and/or are implausible for other reasons:
  *
  *   0Stub dm onlyHVMstubdomid
  *   PV|SPLIT PV domain   PV emuid
  */

Ian.

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

Re: [Xen-devel] [PATCH v4.1] libxc: Defer initialization of start_page for HVM guests

[Boris Ostrovsky]

On 01/08/2016 04:56 AM, Ian Campbell wrote:

On Thu, 2016-01-07 at 17:11 -0500, Boris Ostrovsky wrote:

With commit 8c45adec18e0 ("libxc: create unmapped initrd in domain
builder if supported") location of ramdisk may not be available to
HVMlite guests by the time alloc_magic_pages_hvm() is invoked if the
guest supports unmapped initrd.

So let's move ramdisk info initialization (along with a few other
operations that are not directly related to allocating magic/special
pages) from alloc_magic_pages_hvm() to bootlate_hvm().

The "few other operations" are just the hvm_info init for standard HVM by
this iteration?


For HVM yes, but we also move command string initialization for HVMlite.




--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -71,6 +71,7 @@ struct xc_dom_image {
  
  /* arguments and parameters */

  char *cmdline;
+size_t cmdline_size;

Perhaps /* Including NULL and padding/alignment */ ?

(That's the sort of thing I don't mind doing on commit if there is
agreement and no other changes required)


Yes, please add this (unless you want to see v5, v5.1 and v5.2)




@@ -1095,8 +1044,8 @@ static int vcpu_hvm(struct xc_dom_image *dom)
  /* Set the IP. */
  bsp_ctx.cpu.rip = dom->parms.phys_entry;
  
-if ( dom->start_info_pfn )

-bsp_ctx.cpu.rbx = dom->start_info_pfn << PAGE_SHIFT;
+if ( dom->start_info_seg.pfn )
+bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;

Just to check: dom->start_info_pfn is unused/nil in the regular-hvm case,
correct (i.e. this code is dm-list specific both before and after)?


Yes, start_info_pfn is only used by PV(H) and since the structure is 
memset to zero during allocation the 'if' clause is only executed for 
HVMlite.





+else
+{
+void *hvm_info_page;
+
+if ( (hvm_info_page = xc_map_foreign_range(
+  xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
+  HVM_INFO_PFN)) == NULL )
+return -1;
+build_hvm_info(hvm_info_page, dom);
+munmap(hvm_info_page, PAGE_SIZE);
+}

Did you test regular HVM guests after this movement?


Yes, I did.

-boris

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

Re: [Xen-devel] [PATCH v3 01/15] xen: add xenstore domain flag to hypervisor

[Andrew Cooper]

On 08/01/16 14:22, Juergen Gross wrote:
> On 08/01/16 15:07, Jan Beulich wrote:
> On 08.01.16 at 14:08,  wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -318,6 +318,12 @@ struct domain *domain_create(domid_t domid, unsigned 
>>> int domcr_flags,
>>>  hardware_domain = d;
>>>  }
>>>  
>>> +if ( domcr_flags & DOMCRF_xs_domain )
>>> +{
>>> +d->is_xenstore = 1;
>>> +d->disable_migrate = 1;
>>> +}
>> It only occurred to me now: Wouldn't it be worth denying the domain
>> creation request if there already is a xenstore domain?
> Hmm, the only cases where this would make sense would be:
>
> - some bug in dom0 resulting in parallel calls of init-xenstore-domain
> - an out-of-tree tool in dom0 (or another domain capable of creating
>   domains) creating a domain with the xenstore flag set
>
> I'm really not sure what would be best here. Should the hypervisor
> really be responsible for this decision?
>
> In case it is desired, I can modify the patch accordingly (the
> modification would be trivial).

For now, it might be better to knobble it in Xen to weed out bugs.

However, given future plans for restartable or multiple xenstores, I
could easily see it becoming a valid option.

~Andrew

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

Re: [Xen-devel] [PATCH v4.2] libxc: Defer initialization of start_page for HVM guests

[Boris Ostrovsky]

On 01/08/2016 09:30 AM, Juergen Gross wrote:

On 08/01/16 15:19, Boris Ostrovsky wrote:

On 01/07/2016 11:57 PM, Juergen Gross wrote:

On 07/01/16 23:19, Boris Ostrovsky wrote:

With commit 8c45adec18e0 ("libxc: create unmapped initrd in domain
builder if supported") location of ramdisk may not be available to
HVMlite guests by the time alloc_magic_pages_hvm() is invoked if the
guest supports unmapped initrd.

So let's move ramdisk info initialization (along with a few other
operations that are not directly related to allocating magic/special
pages) from alloc_magic_pages_hvm() to bootlate_hvm().

Since we now split allocation and mapping of the start_info segment
let's stash it, along with cmdline length, in xc_dom_image so that we
can check whether we are mapping correctly-sized range.

We can also stop using xc_dom_image.start_info_pfn and leave it for
PV(H) guests only.

Signed-off-by: Boris Ostrovsky 
---
v4:
   * See the last two paragraphs from commit message above

v4.1:
   * Inverted testing of start_info_size in bootlate_hvm().

v4.2
   *  Actually do what I said I'd do in 4.1

   tools/libxc/include/xc_dom.h |2 +
   tools/libxc/xc_dom_x86.c |  140
+++--
   2 files changed, 80 insertions(+), 62 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 2460818..cac4698 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -71,6 +71,7 @@ struct xc_dom_image {
 /* arguments and parameters */
   char *cmdline;
+size_t cmdline_size;
   uint32_t f_requested[XENFEAT_NR_SUBMAPS];
 /* info from (elf) kernel image */
@@ -91,6 +92,7 @@ struct xc_dom_image {
   struct xc_dom_seg p2m_seg;
   struct xc_dom_seg pgtables_seg;
   struct xc_dom_seg devicetree_seg;
+struct xc_dom_seg start_info_seg; /* HVMlite only */

Instead of adding HVM specific members here, you could make use of
dom.arch_private and use just a local structure defined in xc_dom_x86.c.

I did consider this but since we already keep type-specific segments in
this structure (e.g. p2m_seg) decided to add an explicit segment for
HVMlite.

But p2m_seg is accessed from multiple sources, while cmdline_size and
start_info_seg would be local to xc_dom_x86.c

BTW: thanks for the hint - I'll have a look whether p2m_seg can't be
moved to arch_private...


Besides, I think to properly use it we'd need to add an arch hook and
IMHO it's not worth the trouble in this case.

Why would you need another arch hook? Just add the arch_private_size
member to struct xc_dom_arch and everything is set up for you. Look
how it is handled for the pv case in xc_dom_x86.c


So it is already hooked up, I didn't notice that we do register 
xc_hvm_32, even though arch_private_size is 0.


This would be a type-specific area though, not arch-specific as the name 
implies. So perhaps xc_dom_image_x86 should be modified to include 
type-specific structures (via a union).


-boris


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

Re: [Xen-devel] [PATCH RFC OSSTEST v1 02/12] target_var: Support fallback to all_(guest|host)_$vn

[Ian Jackson]

Ian Campbell writes ("[PATCH RFC OSSTEST v1 02/12] target_var: Support fallback 
to all_(guest|host)_$vn"):
> Having to set {ident}_foo for all idents used in a job (e.g host vs
> src_host+dst_host) in make-flight would be a little fiddly.

Acked-by: Ian Jackson 


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

Re: [Xen-devel] [Qemu-devel] [PATCH v3 11/11] igd: move igd-passthrough-isa-bridge creation to machine init

[Stefano Stabellini]

On Fri, 8 Jan 2016, Gerd Hoffmann wrote:
>   Hi,
> 
> > > That is true. Given that the only qemu-xen codebase with igd support is
> > > 4.7 and 4.7 hasn't been released yet, I am OK with changing the guest
> > > visible PCI layout. I might ask for your help in backporting the patches
> > > ;-)
> 
> What are the 4.7 release plans btw?

This is the last development update from the release manager:

http://marc.info/?l=qemu-devel=145172165010604

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

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

Re: [Xen-devel] [PATCH v3 08/13] x86/hvm: Setup TSC scaling ratio

[Haozhong Zhang]

On 01/08/16 07:04, Jan Beulich wrote:
> >>> On 08.01.16 at 14:55,  wrote:
> > On 01/08/16 02:44, Jan Beulich wrote:
> >> >>> On 31.12.15 at 04:03,  wrote:
> >> > +ratio = mul_u64_u32_div(1ULL << 
> >> > hvm_funcs.tsc_scaling_ratio_frac_bits,
> >> > +gtsc_khz, cpu_khz);
> >> > +
> >> > +return (!ratio || ratio > hvm_funcs.max_tsc_scaling_ratio) ? FALSE 
> >> > : TRUE;
> >>
> >> There no point in using a conditional expression here.
> > 
> > Ah, right, I'll  change it to
> >  return !!(ratio && ratio <= hvm_funcs.max_tsc_scaling_ratio);
> 
> Except that you don't need the !!() here either.
> 
> Jan
> 

Ah, yes.

Thanks,
Haozhong

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

Re: [Xen-devel] [PATCH XEN v3 0/2] add support for vNVDIMM - Part 1: enable instructions

[Jan Beulich]

>>> On 08.01.16 at 14:03,  wrote:
> On 01/08/16 04:50, Jan Beulich wrote:
>> >>> On 08.01.16 at 11:46,  wrote:
>> >  * Move the code refactoring in hvm_cpuid() to patch 2.
>> >  * Replace checking host cpuid by checking VMX capabilities for pcommit.
>> 
>> Replace?
> 
> Yes, akin to how MPX is checked in hvm_cpuid(). Or do you mean it's
> better to check host cpuid as well?

Ah, yes, you're right. Should be fine as is then.

Jan


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

Re: [Xen-devel] [PATCH v3 08/13] x86/hvm: Setup TSC scaling ratio

[Haozhong Zhang]

On 01/08/16 02:44, Jan Beulich wrote:
> >>> On 31.12.15 at 04:03,  wrote:
> > @@ -301,6 +302,42 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
> >  return 1;
> >  }
> >  
> > +bool_t hvm_validate_tsc_scaling_ratio(uint32_t gtsc_khz)
> > +{
> > +u64 ratio;
> > +
> > +if ( !hvm_funcs.tsc_scaling_supported )
> > +return FALSE;
> 
> We use 0 and 1, not FALSE and TRUE (except in ACPI and EFI code).
>

I'll change in the next version.

> > +ratio = mul_u64_u32_div(1ULL << hvm_funcs.tsc_scaling_ratio_frac_bits,
> > +gtsc_khz, cpu_khz);
> > +
> > +return (!ratio || ratio > hvm_funcs.max_tsc_scaling_ratio) ? FALSE : 
> > TRUE;
>
> There no point in using a conditional expression here.

Ah, right, I'll  change it to
 return !!(ratio && ratio <= hvm_funcs.max_tsc_scaling_ratio);
 
> 
> > --- a/xen/include/asm-x86/hvm/hvm.h
> > +++ b/xen/include/asm-x86/hvm/hvm.h
> > @@ -226,6 +226,9 @@ struct hvm_function_table {
> >  int (*altp2m_vcpu_emulate_vmfunc)(struct cpu_user_regs *regs);
> >  
> >  uint64_t (*scale_tsc)(struct vcpu *v, uint64_t tsc);
> > +
> > +/* Architecture function to setup TSC scaling ratio */
> > +void (*setup_tsc_scaling)(struct vcpu *v);
> 
> SVM doesn't use this hook, and VMX gets to use it only later. I.e.
> everything related to it is dead code right now, and would therefore
> better go into the VMX (I suppose) patch actually making use of it.
> 

Yes, it's used in later VMX patch. I'll move it that patch.

Haozhong

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

Re: [Xen-devel] [PATCH RFC OSSTEST v1 01/12] Debian: Abolish $suite and $xopts{Suite} from preseed_* interfaces.

[Ian Jackson]

Ian Campbell writes ("[PATCH RFC OSSTEST v1 01/12] Debian: Abolish $suite and 
$xopts{Suite} from preseed_* interfaces."):
> Generating a preseed for a suite which does not match the ->{Suite} of
> the underlying guest or host object does not seem useful, so remove
> this option and use ->{Suite} instead.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [Qemu-devel] [PATCH v3 11/11] igd: move igd-passthrough-isa-bridge creation to machine init

[Gerd Hoffmann]

  Hi,

> > That is true. Given that the only qemu-xen codebase with igd support is
> > 4.7 and 4.7 hasn't been released yet, I am OK with changing the guest
> > visible PCI layout. I might ask for your help in backporting the patches
> > ;-)

What are the 4.7 release plans btw?

> One thing that I forgot to consider is that QEMU 2.5 has been released
> with igd passthrough too and Xen 4.6 + QEMU 2.5 is a combination we
> should support.
> 
> However QEMU 2.5 has a serious bug
> (http://marc.info/?l=qemu-devel=145172165010604) which probably
> prevents igd passthrough from working at all.

Stumbled over that one too, so my series has a (different) fix for it as
well.

> I asked Xudong to investigate.  I am thinking that if the feature
> works in 2.5, we need to support it, therefore we cannot break
> migration by changing the PCI layout.

I'd expect it is broken (at least for older guests).  In case 2.5 works
fine as-is we should be able to ditch
TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE altogether b/c it is a no-op in
2.5 because of the bug.

But lets wait for the test results ...

> Otherwise if the feature doesn't work, we could take the liberty to
> make the change.  Do you agree?

Yes.

cheers,
  Gerd


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

Re: [Xen-devel] Missing libvirt+libxl functionality (Was: Re: [Xen-users] Programmatic administration of Xen machines)

[Ian Campbell]

On Thu, 2016-01-07 at 22:54 -0700, Jim Fehlig wrote:
> > > I had even more trouble, e.g. I wasn't able to use non-standard block
> > > scripts (neither via /etc/xen/scripts/block-XXX nor via a script
> > > parameter) which are mandatory for me.
> > Looking at the code it seems like this is still missing.
> > 
> > Copying the devel list and maintainer in case I've either missed something
> > or there is a reason for this (other than "still on the TODO list", which I
> > expect is most likely).
> 
> It is on a TODO list, but I'm not sure how to solve it :-/. Unlike the
> libxl_device_disk struct, the corresponding libvirt struct does not support a
> 'script' field, and I doubt it ever will. Repeated attempts to add a 
> element to the  config have been rejected. The libvirt community prefers
> all config needed to setup disks be provided in the XML, not left to a magic
> script doing unknown things behind libvirtd's back.

That's an understandable position for them to take, I think.

If someone does use the libvirt's XML based mechanisms to configure things
then does the libxl backend correctly plumb them through? I suppose
something in libvirt either produces a blk device (which can be trivially
converted to a suitable libxl disk phy thing) or a reference to some image
file (perhaps less trivially convertable but doable, most of the time?).

If the libvirt XML stuff works then I don't see any pressing need to plumb
Xen scripts through to libvirt if the libvirt maintainers do not want to
support that abstract concept. If folks want functionality which would only
be available via scripts then they should be encouraged to implement that
functionality generically in libvirt in a way which is acceptable to the
maintainers.

I appreciate that this might mean that some xl style cfg files cannot be
laundered through domxml-from-native to create a working xml config, but I
think that's a natural consequence of having two separate projects with
somewhat non-overlapping featuresets and design goals.

I see domxml-from-native as more of a convenience for configurations which
fall into the union of xl and libvirt's featuresets. I suppose if someone
was feeling adventurous then they could try and have domxml-from-native
spot some uses of well known block scripts and convert to the equivalent
libvirt XML e.g. spot block-iscsi and convert that into equivalent libvirt
XML objects (assuming libvirt supports iscsi, I didn't look).

Ian.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 77211

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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  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-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 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-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

version targeted for testing:
 libvirt  6343018faca842b0c4c1805f9d2345f6e20fda60
baseline version:
 libvirt  44b4a4f6d778227644e98c3894c57559d317eb3c

Last test of basis77211  2016-01-06 04:23:33 Z2 days
Testing same since77324  2016-01-07 07:20:19 Z1 days1 attempts


People who touched revisions under test:
  Olaf Hering 
  Wido den Hollander 

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 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


Pushing revision :

+ branch=libvirt
+ revision=6343018faca842b0c4c1805f9d2345f6e20fda60
+ . ./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 

[Xen-devel] [PATCH RFC OSSTEST v1 06/12] ts-host-install: Support DiVersion coming from runvars

[Ian Campbell]

To do so initialise $ho->{DiVersion} in select host and use it in
ts-host-install.

Signed-off-by: Ian Campbell 
---
 Osstest/TestSupport.pm | 1 +
 ts-host-install| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 3923b18..7ea4f19 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -862,6 +862,7 @@ sub selecthost ($) {
 };
 if (defined $job) {
$ho->{Suite} = target_var($ho, "suite") // $c{DebianSuite};
+   $ho->{DiVersion} = target_var($ho, "diversion") // $c{TftpDiVersion};
 }
 
 #- handle hosts which are themselves guests (nested) -
diff --git a/ts-host-install b/ts-host-install
index eb740fa..ecf5f0b 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -157,7 +157,7 @@ END
 sub setup_pxeboot_firstboot($) {
 my ($ps_url) = @_;
 
-my $d_i= 
$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.$c{TftpDiVersion}.'-'.$ho->{Suite};
+my $d_i= 
$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.$ho->{DiVersion}.'-'.$ho->{Suite};
 
 my @dicmdline= qw(vga=normal);
 push @dicmdline, di_installcmdline_core($ho, $ps_url, %xopts);
-- 
2.6.1


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

Re: [Xen-devel] [PATCH 28/28] libxl: xsrestrict QEMU

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 28/28] libxl: xsrestrict QEMU"):
> On Tue, 2015-12-22 at 18:45 +, Ian Jackson wrote:
> > If QEMU supports xsrestrict, pass xsrestrict=on to it (by default).
> > 
> > XXX We need to do this only if xenstored supports it, and AFAICT there
> > is not a particularly easy way to test this.  Should we open a new
> > test xenstore connection to query this information ?  We could do this
> > once per libxl ctx.
> 
> Is this because the support is in oxenstored ^ cxenstored?

Yes.

> Otherwise I would argue that the toolstack should expect the xenstored to
> be at least as new as it is.

True.

> > * libxl__xs_directory on /physmap
> >   This is safe.
> 
> Potentially very many entries and hence a big return array? Are the guest
> quotas sufficient to not worry about this?

Yes, the quota has to deal with that anyway (since the directory is in
core in xenstored, anyway).

> Perhaps we should add a code comment to each of these places noting that
> the values are guest controlled, since it is a bit more unexpected in this
> case than e.g. frontend dirs.

This is a good idea.

> > +Information about an HVM domain's physical memory map.  This is
> > +written as well as read by device models which may run at the same
> > +privilege level of the guest domain.  When the device model ruus with
> 
> "runs"

Fixed, thanks.

Ian.

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

Re: [Xen-devel] [PATCH 25/28] libxl: emuids: Perhaps change dm xs control path

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 25/28] libxl: emuids: Perhaps change dm xs 
control path"):
> On Fri, 2016-01-08 at 14:12 +, Ian Jackson wrote:
> >   * In xenstore we record which qemus a domain has.  This is necessary
> >   * for correct teardown.  And, we also record whether the xenstore
> >   * paths are unified, as discussed above, so that subsequent libxl
> >   * operations can do the right thing.  This is what the EMUID_SPLIT
> >   * flag is for.
> 
> EMUID_SPLIT actually records the inverse (i.e. that they are split, rather
> than unified as the previous text is discussing).
> 
> I knew what you meant though, and clarifying it could well make it less
> obvious I suspect.

Yes.  I could explain the reason for the sense of the flag, which is
to get the default right, but that seems obvious.

How about:

> >   * In xenstore we record which qemus a domain has.  This is
> >   * necessary for correct teardown.  And, we also record whether
> >   * the xenstore paths are split or unified, as discussed above,
   
> >   * so that subsequent libxl operations can do the right
> >   * thing.  This is what the EMUID_SPLIT flag is for.

?

Ian.

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

Re: [Xen-devel] [PATCH 26/28] libxl: spawns two QEMUs for HVM guests

[Ian Campbell]

On Fri, 2016-01-08 at 14:35 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 26/28] libxl: spawns two QEMUs for HVM
> guests"):
> > On Tue, 2015-12-22 at 18:45 +, Ian Jackson wrote:
> > > @@ -440,6 +442,15 @@ static int
> > > domcreate_setdefault_dm_user(libxl__gc
> > > *gc,
> > > +if (!libxl__dm_supported(gc, dm,
> > > libxl__dm_support_check__emulator_id)) {
> > > +/* we don't want to run the pv backends as non-root because
> > > + * device hotplug will no longer work. */
> > > +LOG(WARN,
> > > + "Device model does not support split PV backends, running it as
> > > root");
> > > +user = "root";
> > > +goto found;
> > > +}
> > 
> > Should this be a fatal error, unless b_info->device_model_user ==
> > "root"?
> 
> This is in the code which sets the default value if the configuration
> didn't specify one.

Oh yes, sorry for the noise.

> 
> Ian.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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

version targeted for testing:
 xen  75904ac35f589b420d6d30415a64888b121d6484
baseline version:
 xen  18eed42622b698e99f2950c293ae969ccaffe9ef

Last test of basis77413  2016-01-07 18:01:49 Z0 days
Testing same since77507  2016-01-08 10:02:58 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Doug Goldstein 
  Haozhong Zhang 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [xen-4.3-testing test] 77314: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-prev  5 xen-build fail REGR. vs. 65650
 build-i386-prev   5 xen-build fail REGR. vs. 65650

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3 17 guest-start/win.repeat fail blocked in 
65650
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 65650

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

version targeted for testing:
 xen  a64bfae49ae845ba4cb8cb6923fa08c41439872a
baseline version:
 xen  54dd84062d4e0f0298508826fc06990415da431e

Last test of basis65650  2015-12-10 03:50:48 Z   29 days
Failing since 66463  2015-12-17 13:41:33 Z   21 days   10 attempts
Testing same since77314  2016-01-07 05:16:29 Z1 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Stefano Stabellini 

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

Re: [Xen-devel] [PATCH] arch/x86: convert bigmem to Kconfig

[Doug Goldstein]

On 1/8/16 2:50 AM, Jan Beulich wrote:
 On 08.01.16 at 03:55,  wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -25,6 +25,18 @@ config ARCH_DEFCONFIG
>>  
>>  menu "Architecture Features"
>>  
>> +config BIGMEM
>> +bool "big memory support"
>> +default n
>> +---help---
>> +  Allows Xen to support up to 123Tb of memory.
>> +
>> +  This requires growing struct page_info from 32 to 48 bytes as well
>> +  as shrinking the always accessible direct mapped memory range from
>> +  5Tb to 3.5Tb.
> 
> Fundamentally okay, but I think the numbers should be dropped
> (as they could easily become stale, since they reflect in the first
> case just current state and in the second really just an
> implementation detail). No strict need to re-submit (can be fixed
> up upon commit), but I'd like to have your consent since this is
> going to be under your name.
> 
> Jan
> 

Yes that's fine. I just copied the original commit message that added
big mem support. I'm actually hoping that more people do what you're
proposing and provide better detailed messages when they understand how
that code works. So thank you!

-- 
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 v4.2] libxc: Defer initialization of start_page for HVM guests

[Boris Ostrovsky]

On 01/07/2016 11:57 PM, Juergen Gross wrote:

On 07/01/16 23:19, Boris Ostrovsky wrote:

With commit 8c45adec18e0 ("libxc: create unmapped initrd in domain
builder if supported") location of ramdisk may not be available to
HVMlite guests by the time alloc_magic_pages_hvm() is invoked if the
guest supports unmapped initrd.

So let's move ramdisk info initialization (along with a few other
operations that are not directly related to allocating magic/special
pages) from alloc_magic_pages_hvm() to bootlate_hvm().

Since we now split allocation and mapping of the start_info segment
let's stash it, along with cmdline length, in xc_dom_image so that we
can check whether we are mapping correctly-sized range.

We can also stop using xc_dom_image.start_info_pfn and leave it for
PV(H) guests only.

Signed-off-by: Boris Ostrovsky 
---
v4:
  * See the last two paragraphs from commit message above

v4.1:
  * Inverted testing of start_info_size in bootlate_hvm().

v4.2
  *  Actually do what I said I'd do in 4.1

  tools/libxc/include/xc_dom.h |2 +
  tools/libxc/xc_dom_x86.c |  140 +++--
  2 files changed, 80 insertions(+), 62 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 2460818..cac4698 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -71,6 +71,7 @@ struct xc_dom_image {
  
  /* arguments and parameters */

  char *cmdline;
+size_t cmdline_size;
  uint32_t f_requested[XENFEAT_NR_SUBMAPS];
  
  /* info from (elf) kernel image */

@@ -91,6 +92,7 @@ struct xc_dom_image {
  struct xc_dom_seg p2m_seg;
  struct xc_dom_seg pgtables_seg;
  struct xc_dom_seg devicetree_seg;
+struct xc_dom_seg start_info_seg; /* HVMlite only */

Instead of adding HVM specific members here, you could make use of
dom.arch_private and use just a local structure defined in xc_dom_x86.c.


I did consider this but since we already keep type-specific segments in 
this structure (e.g. p2m_seg) decided to add an explicit segment for 
HVMlite.


Besides, I think to properly use it we'd need to add an arch hook and 
IMHO it's not worth the trouble in this case.


-boris


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

Re: [Xen-devel] [PATCH v4.2] libxc: Defer initialization of start_page for HVM guests

[Ian Campbell]

On Fri, 2016-01-08 at 09:19 -0500, Boris Ostrovsky wrote:
> index 2460818..cac4698 100644
> > > --- a/tools/libxc/include/xc_dom.h
> > > +++ b/tools/libxc/include/xc_dom.h
> > > @@ -71,6 +71,7 @@ struct xc_dom_image {
> > >   
> > >   /* arguments and parameters */
> > >   char *cmdline;
> > > +size_t cmdline_size;
> > >   uint32_t f_requested[XENFEAT_NR_SUBMAPS];
> > >   
> > >   /* info from (elf) kernel image */
> > > @@ -91,6 +92,7 @@ struct xc_dom_image {
> > >   struct xc_dom_seg p2m_seg;
> > >   struct xc_dom_seg pgtables_seg;
> > >   struct xc_dom_seg devicetree_seg;
> > > +struct xc_dom_seg start_info_seg; /* HVMlite only */
> > Instead of adding HVM specific members here, you could make use of
> > dom.arch_private and use just a local structure defined in
> > xc_dom_x86.c.
> 
> I did consider this but since we already keep type-specific segments in 
> this structure (e.g. p2m_seg) decided to add an explicit segment for 
> HVMlite.
> 
> Besides, I think to properly use it we'd need to add an arch hook and 
> IMHO it's not worth the trouble in this case.

Agreed, it is at best a potential future cleanup.

Ian.

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

Re: [Xen-devel] [Qemu-devel] [PATCH v3 11/11] igd: move igd-passthrough-isa-bridge creation to machine init

[Stefano Stabellini]

On Fri, 8 Jan 2016, Stefano Stabellini wrote:
> > > > xen_pt_initfn checks that igd-passthru=on is set in case it finds a igd
> > > > device is assigned, that will make sure the igd-isa-bridge is present.
> > > > 
> > > > But, yes, you can create a igd-isa-bridge now even when not assigning a
> > > > igd device, either by specifying igd-passthru=on or using -device.  I
> > > > fail to see why this is a problem though, care to explain?
> > > 
> > > It is going to change the PCI layout of any virtual machines with a
> > > config file containing
> > > 
> > > gfx_passthru="igd"
> > > 
> > > and no pci config line. A Xen 4.7 user could add gfx_passthru="igd" to
> > > all her VM config files, because actually it does nothing unless an
> > > Intel graphic card is assigned to the VM.
> > 
> > No.  It changes the host bridge even when not passing through a igd,
> > because that is linked to igd-passthru=on only.
> >
> > So making both host bridge tweak and isa bridge tweak triggered by
> > igd-passthru=on brings more consistency to the whole thing.
> 
> That is true. Given that the only qemu-xen codebase with igd support is
> 4.7 and 4.7 hasn't been released yet, I am OK with changing the guest
> visible PCI layout. I might ask for your help in backporting the patches
> ;-)

One thing that I forgot to consider is that QEMU 2.5 has been released
with igd passthrough too and Xen 4.6 + QEMU 2.5 is a combination we
should support.

However QEMU 2.5 has a serious bug
(http://marc.info/?l=qemu-devel=145172165010604) which probably
prevents igd passthrough from working at all. I asked Xudong to
investigate. I am thinking that if the feature works in 2.5, we need to
support it, therefore we cannot break migration by changing the PCI
layout.  Otherwise if the feature doesn't work, we could take the
liberty to make the change.  Do you agree?

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

Re: [Xen-devel] [PATCH 03/28] libxl: Provide libxl__dm_support_*

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 03/28] libxl: Provide libxl__dm_support_*"):
> On Tue, 2015-12-22 at 18:44 +, Ian Jackson wrote:
> > This allows code elsewhere in libxl to find out what options a device
> > model executable supports.  This is done by searching the usage
> > message for fixed strings.
> 
> Has anyone (ever, not necessarily a Xen person nor in this context)
> approached upstream QEMU about a machine readable output of some sort?

Not as far as I'm aware.  Stefano, could you perhaps put out some
feelers ?

Ian.

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

[Xen-devel] [PATCH v3 08/15] xenstore: add error messages to init-xenstore-domain

[Juergen Gross]

Additional add some diagnostic messages to the program to have an idea
why it failed.

Signed-off-by: Juergen Gross 
Acked-by: Ian Campbell 
Acked-by: Daniel De Graaf 
---
 tools/helpers/init-xenstore-domain.c | 66 ++--
 1 file changed, 64 insertions(+), 2 deletions(-)

diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index a9c5821..124f29c 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static uint32_t domid = ~0;
 
@@ -25,69 +26,120 @@ static int build(xc_interface *xch, int argc, char** argv)
 
 xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
 if ( xs_fd == -1 )
+{
+fprintf(stderr, "Could not open /dev/xen/xenbus_backend\n");
 return -1;
+}
 
 rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), );
 if ( rv )
+{
+fprintf(stderr, "xc_flask_context_to_sid failed\n");
 goto err;
+}
 rv = xc_domain_create(xch, ssid, handle, 0, , NULL);
 if ( rv )
+{
+fprintf(stderr, "xc_domain_create failed\n");
 goto err;
+}
 rv = xc_domain_max_vcpus(xch, domid, 1);
 if ( rv )
+{
+fprintf(stderr, "xc_domain_max_vcpus failed\n");
 goto err;
+}
 rv = xc_domain_setmaxmem(xch, domid, limit_kb);
 if ( rv )
+{
+fprintf(stderr, "xc_domain_setmaxmem failed\n");
 goto err;
+}
 rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
 if ( rv )
+{
+fprintf(stderr, "xc_domain_set_memmap_limit failed\n");
 goto err;
+}
 
 rv = ioctl(xs_fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
 if ( rv < 0 )
+{
+fprintf(stderr, "Xenbus setup ioctl failed\n");
 goto err;
+}
 snprintf(cmdline, 512, "--event %d --internal-db", rv);
 
 dom = xc_dom_allocate(xch, cmdline, NULL);
 rv = xc_dom_kernel_file(dom, argv[1]);
 if ( rv )
+{
+fprintf(stderr, "xc_dom_kernel_file failed\n");
 goto err;
+}
 
 if ( argc > 4 )
 {
 rv = xc_dom_ramdisk_file(dom, argv[4]);
 if ( rv )
+{
+fprintf(stderr, "xc_dom_ramdisk_file failed\n");
 goto err;
+}
 }
 
 rv = xc_dom_boot_xen_init(dom, xch, domid);
 if ( rv )
+{
+fprintf(stderr, "xc_dom_boot_xen_init failed\n");
 goto err;
+}
 rv = xc_dom_parse_image(dom);
 if ( rv )
+{
+fprintf(stderr, "xc_dom_parse_image failed\n");
 goto err;
+}
 rv = xc_dom_mem_init(dom, maxmem);
 if ( rv )
+{
+fprintf(stderr, "xc_dom_mem_init failed\n");
 goto err;
+}
 rv = xc_dom_boot_mem_init(dom);
 if ( rv )
+{
+fprintf(stderr, "xc_dom_boot_mem_init failed\n");
 goto err;
+}
 rv = xc_dom_build_image(dom);
 if ( rv )
+{
+fprintf(stderr, "xc_dom_build_image failed\n");
 goto err;
+}
 rv = xc_dom_boot_image(dom);
 if ( rv )
+{
+fprintf(stderr, "xc_dom_boot_image failed\n");
 goto err;
+}
 
 xc_dom_release(dom);
 dom = NULL;
 
 rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
 if ( rv )
+{
+fprintf(stderr, "xc_domain_set_virq_handler failed\n");
 goto err;
+}
 rv = xc_domain_unpause(xch, domid);
 if ( rv )
+{
+fprintf(stderr, "xc_domain_unpause failed\n");
 goto err;
+}
 
 return 0;
 
@@ -109,14 +161,18 @@ int main(int argc, char** argv)
 
 if ( argc < 4 || argc > 5 )
 {
-printf("Use: %s
[]\n",
-   argv[0]);
+fprintf(stderr,
+"Use: %s
[]\n",
+argv[0]);
 return 2;
 }
 
 xch = xc_interface_open(NULL, NULL, 0);
 if ( !xch )
+{
+fprintf(stderr, "xc_interface_open() failed\n");
 return 1;
+}
 
 rv = build(xch, argc, argv);
 
@@ -132,12 +188,18 @@ int main(int argc, char** argv)
 
 fd = creat("/var/run/xenstored.pid", 0666);
 if ( fd < 0 )
+{
+fprintf(stderr, "Creating /var/run/xenstored.pid failed\n");
 return 3;
+}
 rv = snprintf(buf, 16, "domid:%d\n", domid);
 rv = write(fd, buf, rv);
 close(fd);
 if ( rv < 0 )
+{
+fprintf(stderr, "Writing domid to /var/run/xenstored.pid failed\n");
 return 3;
+}
 
 return 0;
 }
-- 
2.6.2


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

[Xen-devel] [PATCH v3 15/15] docs: document xenstore domain xenstore paths

[Juergen Gross]

Add the xenstore domain specific xenstore paths to
docs/misc/xenstore-paths.markdown

Signed-off-by: Juergen Gross 
---
 docs/misc/xenstore-paths.markdown | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/docs/misc/xenstore-paths.markdown 
b/docs/misc/xenstore-paths.markdown
index 197bb0f..4712e3a 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -509,6 +509,16 @@ The device model version for a domain.
 
 ifb device used by Remus to buffer network output from the associated vif.
 
+### xenstored specific paths
+
+The /tool/xenstored namespace is created by the xenstore daemon or domain
+for the toolstack to obtain e.g. the domain id of a xenstore domain.
+
+ /tool/xenstored/domid = INTEGER [n,INTERNAL]
+
+Domain Id of the xenstroe domain in case xenstore is provided via a
+domain instead of a daemon in dom0.
+
 [BLKIF]: 
http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,blkif.h.html
 [FBIF]: 
http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,fbif.h.html
 [HVMPARAMS]: 
http://xenbits.xen.org/docs/unstable/hypercall/include,public,hvm,params.h.html
-- 
2.6.2


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

[Xen-devel] [PATCH v3 12/15] tools: split up xen-init-dom0.c

[Juergen Gross]

Split up tools/helpers/xen-init-dom0.c in order to prepare reusing
generation of the json configuration by init-xenstore-domain.c.

Signed-off-by: Juergen Gross 
Acked-by: Ian Campbell 
---
 tools/helpers/Makefile|  2 +-
 tools/helpers/init-dom-json.c | 59 ++
 tools/helpers/init-dom-json.h | 18 +++
 tools/helpers/xen-init-dom0.c | 73 ++-
 4 files changed, 88 insertions(+), 64 deletions(-)
 create mode 100644 tools/helpers/init-dom-json.c
 create mode 100644 tools/helpers/init-dom-json.h

diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
index 826e0ed..0325ba2 100644
--- a/tools/helpers/Makefile
+++ b/tools/helpers/Makefile
@@ -10,7 +10,7 @@ ifeq ($(CONFIG_Linux),y)
 PROGS += init-xenstore-domain
 endif
 
-XEN_INIT_DOM0_OBJS = xen-init-dom0.o
+XEN_INIT_DOM0_OBJS = xen-init-dom0.o init-dom-json.o
 $(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
 $(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxenstore)
 $(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxenlight)
diff --git a/tools/helpers/init-dom-json.c b/tools/helpers/init-dom-json.c
new file mode 100644
index 000..91b1fdf
--- /dev/null
+++ b/tools/helpers/init-dom-json.c
@@ -0,0 +1,59 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+int gen_stub_json_config(uint32_t domid)
+{
+int rc = 1;
+xentoollog_logger_stdiostream *logger;
+libxl_ctx *ctx;
+libxl_domain_config dom_config;
+char *json = NULL;
+
+logger = xtl_createlogger_stdiostream(stderr, XTL_ERROR, 0);
+if (!logger)
+return 1;
+
+if (libxl_ctx_alloc(, LIBXL_VERSION, 0,
+(xentoollog_logger *)logger)) {
+fprintf(stderr, "cannot init libxl context\n");
+goto outlog;
+}
+
+libxl_domain_config_init(_config);
+
+/* Generate stub JSON config. */
+dom_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
+libxl_domain_build_info_init_type(_config.b_info,
+  LIBXL_DOMAIN_TYPE_PV);
+
+json = libxl_domain_config_to_json(ctx, _config);
+/* libxl-json format requires the string ends with '\0'. Code
+ * snippet taken from libxl.
+ */
+rc = libxl_userdata_store(ctx, domid, "libxl-json",
+  (const uint8_t *)json,
+  strlen(json) + 1 /* include '\0' */);
+if (rc)
+fprintf(stderr, "cannot store stub json config for domain %u\n", 
domid);
+
+libxl_domain_config_dispose(_config);
+free(json);
+libxl_ctx_free(ctx);
+outlog:
+xtl_logger_destroy((xentoollog_logger *)logger);
+return rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/helpers/init-dom-json.h b/tools/helpers/init-dom-json.h
new file mode 100644
index 000..58c85df
--- /dev/null
+++ b/tools/helpers/init-dom-json.h
@@ -0,0 +1,18 @@
+#ifndef __INIT_DOM_JSON_H
+#define __INIT_DOM_JSON_H
+
+/*
+ * Generate a stub JSON config for a domain with the given domid.
+ */
+int gen_stub_json_config(uint32_t domid);
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/helpers/xen-init-dom0.c b/tools/helpers/xen-init-dom0.c
index 2f7aa7c..9ab8468 100644
--- a/tools/helpers/xen-init-dom0.c
+++ b/tools/helpers/xen-init-dom0.c
@@ -1,65 +1,26 @@
-#include 
 #include 
 #include 
 #include 
 #include 
 
-#include 
 #include 
-#include 
+
+#include "init-dom-json.h"
 
 #define DOMNAME_PATH   "/local/domain/0/name"
 #define DOMID_PATH "/local/domain/0/domid"
 
-static libxl_ctx *ctx;
-static xentoollog_logger_stdiostream *logger;
-static struct xs_handle *xsh;
-
-static void ctx_alloc(void)
+int main(int argc, char **argv)
 {
-if (libxl_ctx_alloc(, LIBXL_VERSION, 0,
-(xentoollog_logger *)logger)) {
-fprintf(stderr, "cannot init libxl context\n");
-exit(1);
-}
+int rc;
+struct xs_handle *xsh;
+char *domname_string = NULL, *domid_string = NULL;
+
 xsh = xs_open(0);
 if (!xsh) {
 fprintf(stderr, "cannot open xenstore connection\n");
 exit(1);
 }
-}
-
-static void ctx_free(void)
-{
-if (ctx) {
-libxl_ctx_free(ctx);
-ctx = NULL;
-}
-if (logger) {
-xtl_logger_destroy((xentoollog_logger *)logger);
-logger = NULL;
-}
-if (xsh) {
-xs_close(xsh);
-xsh = NULL;
-}
-}
-
-int main(int argc, char **argv)
-{
-int rc;
-libxl_domain_config dom0_config;
-char *domname_string = NULL, *domid_string = NULL;
-char *json = NULL;;
-
-logger = xtl_createlogger_stdiostream(stderr, XTL_ERROR, 0);
-if (!logger) exit(1);
-
-atexit(ctx_free);
-
-ctx_alloc();
-
-libxl_domain_config_init(_config);
 
 /* Sanity 

[Xen-devel] [PATCH v3 01/15] xen: add xenstore domain flag to hypervisor

[Juergen Gross]

In order to be able to have full support of a xenstore domain in Xen
add a "Xenstore-domain" flag to the hypervisor. This flag must be
specified at domain creation time and is returned by
XEN_DOMCTL_getdomaininfo.

It will allow the domain to retrieve domain information by issuing the
XEN_DOMCTL_getdomaininfo itself in order to be able to check for
domains having been destroyed. At the same time this flag will inhibit
the domain to be migrated, as this wouldn't be a very wise thing to do.

In case of a later support of a rebootable Dom0 this flag will allow to
recognize a xenstore domain already being present to connect to.

Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
Cc: Andrew Cooper 
Cc: David Vrabel 

Signed-off-by: Juergen Gross 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 
---
V3: changed comment as requested by Ian Campbell
---
 xen/common/domain.c |  6 ++
 xen/common/domctl.c | 14 +-
 xen/include/public/domctl.h |  6 ++
 xen/include/xen/sched.h |  5 +
 xen/include/xsm/dummy.h |  6 ++
 xen/include/xsm/xsm.h   |  1 +
 6 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1017efb..2979c1b 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -318,6 +318,12 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
 hardware_domain = d;
 }
 
+if ( domcr_flags & DOMCRF_xs_domain )
+{
+d->is_xenstore = 1;
+d->disable_migrate = 1;
+}
+
 rangeset_domain_initialise(d);
 init_status |= INIT_rangeset;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 1fab587..dc1ea06 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -183,10 +183,11 @@ void getdomaininfo(struct domain *d, struct 
xen_domctl_getdomaininfo *info)
 info->cpu_time = cpu_time;
 
 info->flags = (info->nr_online_vcpus ? flags : 0) |
-((d->is_dying == DOMDYING_dead) ? XEN_DOMINF_dying: 0) |
-(d->is_shut_down? XEN_DOMINF_shutdown : 0) |
-(d->controller_pause_count > 0  ? XEN_DOMINF_paused   : 0) |
-(d->debugger_attached   ? XEN_DOMINF_debugged : 0) |
+((d->is_dying == DOMDYING_dead) ? XEN_DOMINF_dying : 0) |
+(d->is_shut_down? XEN_DOMINF_shutdown  : 0) |
+(d->controller_pause_count > 0  ? XEN_DOMINF_paused: 0) |
+(d->debugger_attached   ? XEN_DOMINF_debugged  : 0) |
+(d->is_xenstore ? XEN_DOMINF_xs_domain : 0) |
 d->shutdown_code << XEN_DOMINF_shutdownshift;
 
 switch ( d->guest_type )
@@ -551,7 +552,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
| XEN_DOMCTL_CDF_pvh_guest
| XEN_DOMCTL_CDF_hap
| XEN_DOMCTL_CDF_s3_integrity
-   | XEN_DOMCTL_CDF_oos_off)) )
+   | XEN_DOMCTL_CDF_oos_off
+   | XEN_DOMCTL_CDF_xs_domain)) )
 break;
 
 dom = op->domain;
@@ -593,6 +595,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 domcr_flags |= DOMCRF_s3_integrity;
 if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
 domcr_flags |= DOMCRF_oos_off;
+if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_xs_domain )
+domcr_flags |= DOMCRF_xs_domain;
 
 d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref,
   >u.createdomain.config);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 7a56b3f..2d8076c 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -63,6 +63,9 @@ struct xen_domctl_createdomain {
  /* Is this a PVH guest (as opposed to an HVM or PV guest)? */
 #define _XEN_DOMCTL_CDF_pvh_guest 4
 #define XEN_DOMCTL_CDF_pvh_guest  (1U<<_XEN_DOMCTL_CDF_pvh_guest)
+ /* Is this a xenstore domain? */
+#define _XEN_DOMCTL_CDF_xs_domain 5
+#define XEN_DOMCTL_CDF_xs_domain  (1U<<_XEN_DOMCTL_CDF_xs_domain)
 uint32_t flags;
 struct xen_arch_domainconfig config;
 };
@@ -97,6 +100,9 @@ struct xen_domctl_getdomaininfo {
 /* domain is PVH */
 #define _XEN_DOMINF_pvh_guest 7
 #define XEN_DOMINF_pvh_guest  (1U<<_XEN_DOMINF_pvh_guest)
+/* domain is a xenstore domain */
+#define _XEN_DOMINF_xs_domain 8
+#define XEN_DOMINF_xs_domain  (1U<<_XEN_DOMINF_xs_domain)
  /* XEN_DOMINF_shutdown guest-supplied code.  */
 #define XEN_DOMINF_shutdownmask 255
 #define XEN_DOMINF_shutdownshift 16
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index e1428f7..82b6dd1 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -374,6 +374,8 @@ struct domain
 bool_t   auto_node_affinity;
 /* Is this guest fully 

[Xen-devel] [PATCH v3 06/15] libxl: move xen-init-dom0 to tools/helpers

[Juergen Gross]

Move xen-init-dom0 from tools/libxl to tools/helpers, as it is just a
helper program.

Signed-off-by: Juergen Gross 
---
V3: adjust .gitignore as requested by Ian Campbell
use libxentoollog instead of libxc as requested by Ian Campbell
---
 .gitignore   |  2 +-
 tools/helpers/Makefile   | 10 ++
 tools/{libxl => helpers}/xen-init-dom0.c |  2 +-
 tools/libxl/Makefile | 14 +++---
 4 files changed, 15 insertions(+), 13 deletions(-)
 rename tools/{libxl => helpers}/xen-init-dom0.c (99%)

diff --git a/.gitignore b/.gitignore
index ec1cde3..f70d88f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -133,6 +133,7 @@ tools/flask/utils/flask-setenforce
 tools/flask/utils/flask-set-bool
 tools/flask/utils/flask-label-pci
 tools/helpers/init-xenstore-domain
+tools/helpers/xen-init-dom0
 tools/hotplug/common/hotplugpath.sh
 tools/hotplug/FreeBSD/rc.d/xencommons
 tools/hotplug/FreeBSD/rc.d/xendriverdomain
@@ -300,7 +301,6 @@ tools/libxl/*.pyc
 tools/libxl/libxl-save-helper
 tools/libxl/test_timedereg
 tools/libxl/test_fdderegrace
-tools/libxl/xen-init-dom0
 tools/blktap2/control/tap-ctl
 tools/firmware/etherboot/eb-roms.h
 tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
index 52347fd..826e0ed 100644
--- a/tools/helpers/Makefile
+++ b/tools/helpers/Makefile
@@ -5,10 +5,16 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+PROGS += xen-init-dom0
 ifeq ($(CONFIG_Linux),y)
 PROGS += init-xenstore-domain
 endif
 
+XEN_INIT_DOM0_OBJS = xen-init-dom0.o
+$(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
+$(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxenstore)
+$(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxenlight)
+
 INIT_XENSTORE_DOMAIN_OBJS = init-xenstore-domain.o
 $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenguest)
 $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
@@ -17,12 +23,16 @@ $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += 
$(CFLAGS_libxenstore)
 .PHONY: all
 all: $(PROGS)
 
+xen-init-dom0: $(XEN_INIT_DOM0_OBJS)
+   $(CC) $(LDFLAGS) -o $@ $(XEN_INIT_DOM0_OBJS) $(LDLIBS_libxentoollog) 
$(LDLIBS_libxenstore) $(LDLIBS_libxenlight) $(APPEND_LDFLAGS)
+
 init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS)
$(CC) $(LDFLAGS) -o $@ $(INIT_XENSTORE_DOMAIN_OBJS) 
$(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) 
$(APPEND_LDFLAGS)
 
 .PHONY: install
 install: all
$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+   $(INSTALL_PROG) xen-init-dom0 $(DESTDIR)$(LIBEXEC_BIN)
 ifeq ($(CONFIG_Linux),y)
$(INSTALL_PROG) init-xenstore-domain $(DESTDIR)$(LIBEXEC_BIN)
 endif
diff --git a/tools/libxl/xen-init-dom0.c b/tools/helpers/xen-init-dom0.c
similarity index 99%
rename from tools/libxl/xen-init-dom0.c
rename to tools/helpers/xen-init-dom0.c
index 7925d64..2f7aa7c 100644
--- a/tools/libxl/xen-init-dom0.c
+++ b/tools/helpers/xen-init-dom0.c
@@ -4,7 +4,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 2abae0c..b0cb9e4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -143,7 +143,7 @@ LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
-CLIENTS = xl testidl libxl-save-helper xen-init-dom0
+CLIENTS = xl testidl libxl-save-helper
 
 CFLAGS_XL += $(CFLAGS_libxenlight)
 CFLAGS_XL += -Wshadow
@@ -154,10 +154,6 @@ $(XL_OBJS) $(TEST_PROG_OBJS) _libxl.api-for-check: \
 $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
 
-XEN_INIT_DOM0_OBJS = xen-init-dom0.o
-$(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
-$(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxenstore)
-
 SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
 $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
 
@@ -174,7 +170,7 @@ all: $(CLIENTS) $(TEST_PROGS) $(PKG_CONFIG) \
$(AUTOSRCS) $(AUTOINCS)
 
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS) \
-   $(LIBXL_TEST_OBJS) $(TEST_PROG_OBJS) $(XEN_INIT_DOM0_OBJS): \
+   $(LIBXL_TEST_OBJS) $(TEST_PROG_OBJS): \
$(AUTOINCS) libxl.api-ok
 
 %.c %.h:: %.y
@@ -215,7 +211,7 @@ libxl_internal_json.h: _libxl_types_internal_json.h
 xl.h: _paths.h
 
 $(LIBXL_OBJS) $(LIBXL_TEST_OBJS) $(LIBXLU_OBJS) \
-   $(XL_OBJS) $(TEST_PROG_OBJS) $(SAVE_HELPER_OBJS) $(XEN_INIT_DOM0_OBJS): 
libxl.h
+   $(XL_OBJS) $(TEST_PROG_OBJS) $(SAVE_HELPER_OBJS): libxl.h
 $(LIBXL_OBJS) $(LIBXL_TEST_OBJS): libxl_internal.h
 
 _libxl_type%.h _libxl_type%_json.h _libxl_type%_private.h _libxl_type%.c: 
libxl_type%.idl gentypes.py idl.py
@@ -256,9 +252,6 @@ libxlutil.a: $(LIBXLU_OBJS)
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) 

[Xen-devel] [PATCH v3 03/15] libxl: provide a flag in dominfo to avoid stopping it

[Juergen Gross]

Add a "never_stop" flag to dominfo as indicator for the toolstack that
this domain is to be kept running. For now it is being set for xenstore
domain, but there might be other domains in the future.

Signed-off-by: Juergen Gross 
---
V3: flag in dominfo instead function to get xenstore domid as requested
by Ian Campbell
---
 tools/libxl/libxl.c | 11 ++-
 tools/libxl/libxl.h |  9 +
 tools/libxl/libxl_types.idl |  1 +
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9207621..d2d03e4 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -623,11 +623,12 @@ static void xcinfo2xlinfo(libxl_ctx *ctx,
>ssid_label, ) < 0)
 xlinfo->ssid_label = NULL;
 
-xlinfo->dying= !!(xcinfo->flags_DOMINF_dying);
-xlinfo->shutdown = !!(xcinfo->flags_DOMINF_shutdown);
-xlinfo->paused   = !!(xcinfo->flags_DOMINF_paused);
-xlinfo->blocked  = !!(xcinfo->flags_DOMINF_blocked);
-xlinfo->running  = !!(xcinfo->flags_DOMINF_running);
+xlinfo->dying  = !!(xcinfo->flags_DOMINF_dying);
+xlinfo->shutdown   = !!(xcinfo->flags_DOMINF_shutdown);
+xlinfo->paused = !!(xcinfo->flags_DOMINF_paused);
+xlinfo->blocked= !!(xcinfo->flags_DOMINF_blocked);
+xlinfo->running= !!(xcinfo->flags_DOMINF_running);
+xlinfo->never_stop = !!(xcinfo->flags_DOMINF_xs_domain);
 
 if (xlinfo->shutdown)
 xlinfo->shutdown_reason = (xcinfo->flags>>XEN_DOMINF_shutdownshift) & 
XEN_DOMINF_shutdownmask;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 05606a7..7114491 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -560,6 +560,15 @@ typedef struct libxl__ctx libxl_ctx;
 #define LIBXL_HAVE_DOMINFO_OUTSTANDING_MEMKB 1
 
 /*
+ * LIBXL_HAVE_DOMINFO_NEVER_STOP
+ *
+ * If this is defined, libxl_dominfo will contain a flag called never_stop
+ * indicating that the specific domain should never be stopped by the
+ * toolstack.
+ */
+#define LIBXL_HAVE_DOMINFO_NEVER_STOP 1
+
+/*
  * LIBXL_HAVE_QXL
  *
  * If defined, then the libxl_vga_interface_type will contain another value:
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 9658356..9ad7eba 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -295,6 +295,7 @@ libxl_dominfo = Struct("dominfo",[
 ("paused",  bool),
 ("shutdown",bool),
 ("dying",   bool),
+("never_stop",  bool),
 
 # Valid iff ->shutdown is true.
 #
-- 
2.6.2


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

[Xen-devel] [PATCH v3 00/15] xenstore: make it easier to run xenstore in a domain

[Juergen Gross]

Xen supports to run xenstore in a dedicated domain. It is, however, a
setup which isn't easy to configure. Today flask is required for full
functionality and the resulting xenstore domain is not configurable in
the same way as the xenstore daemon.

This patch series enables running a xenstore domain without flask. The
tool needed to start that domain is added to the installed binaries
and it is modified to pass arbitrary options to the xenstore domain.

I didn't include a configuration option for starting xenstore as an
own domain instead of the daemon, as this will require some major
tweaking of especially the systemd configuration files. Support for
this will be added later. The main issue is that running xenstore in
a domain requires the xenstore sockets not to be created. I don't
think this is possible with the current scheme of letting systemd
create those sockets.

Changes in V3:
- patch 1: changed comment as requested by Ian Campbell
- patch 2: changed name of flag from "xs_domain" to "xenstore" as requested
   by Ian Campbell
- patch 3: flag in dominfo instead function to get xenstore domid as requested
   by Ian Campbell
- patch 4: don't adapt coding style as requested by Ian Campbell
   adjust .gitignore
- new patch 5: adapt coding style of init-xenstore-domain.c
- patch 6 (was 5): adjust .gitignore as requested by Ian Campbell
   use libxentoollog instead of libxc as requested by Ian Campbell
- patch 10 (was 9): omit dom0 when checking for xenstore domain as suggested by
   Ian Campbell
   log an error in case of an error when obtaining domain info as
   requested by Ian Campbell
- patch 14 (was 13): xl shutdown modified to query the "never_stop" flag
   instead of the xenstore domain id as requested by Ian Campbell
   drop usage of xenstore-exists as requested by Ian Campbell
- new patch 15: add xenstore domain xenstroe paths to docs as requested by
   Ian Campbell

Changes in V2:
- add new patch 3 to get the xenstore domain id via libxl
- move init-xenstore-domain to new directory tools/helpers in patch 4
  (former patch 3) and modify it to use the standard tools coding style
- add new patch 5 moving xen-init-dom0 to tools/helpers
- split patch 6 (former patch 4) into 2 patches as requested by Ian Campbell
- correct parameter parsing in patch 8 (former patch 5)
- modified commit message of patch 9 (former patch 6) as requested by
  Ian Campbell
- add new patch 11 to split up xen-init-dom0
- modify patch 12 (former patch 8) to create json object and more xenstore
  entries, add error messages as requested by Ian Campbell
- drop former patch 9
- add new patch 13 to avoid stopping xenstore domain on dom0 shutdown

Juergen Gross (15):
  xen: add xenstore domain flag to hypervisor
  libxc: support new xenstore domain flag in libxc
  libxl: provide a flag in dominfo to avoid stopping it
  xenstore: move init-xenstore-domain to tools/helpers
  xenstore: adjust coding style of init-xenstore-domain.c
  libxl: move xen-init-dom0 to tools/helpers
  xenstore: destroy xenstore domain in case of error after creating it
  xenstore: add error messages to init-xenstore-domain
  xenstore: modify init-xenstore-domain parameter syntax
  xenstore: make use of the "xenstore domain" flag
  xenstore: add init-xenstore-domain parameter to specify cmdline
  tools: split up xen-init-dom0.c
  xenstore: write xenstore domain data to xenstore
  tools: don't stop xenstore domain when stopping dom0
  docs: document xenstore domain xenstore paths

 .gitignore|   4 +-
 docs/misc/xenstore-paths.markdown |  10 +
 tools/Makefile|   1 +
 tools/helpers/Makefile|  46 +
 tools/helpers/init-dom-json.c |  59 ++
 tools/helpers/init-dom-json.h |  18 ++
 tools/helpers/init-xenstore-domain.c  | 343 ++
 tools/helpers/xen-init-dom0.c |  67 +++
 tools/hotplug/Linux/xendomains.in |  15 ++
 tools/libxc/include/xenctrl.h |   2 +-
 tools/libxc/xc_domain.c   |   1 +
 tools/libxl/Makefile  |  14 +-
 tools/libxl/libxl.c   |  11 +-
 tools/libxl/libxl.h   |   9 +
 tools/libxl/libxl_types.idl   |   1 +
 tools/libxl/xen-init-dom0.c   | 120 
 tools/libxl/xl_cmdimpl.c  |   8 +-
 tools/xenstore/Makefile   |   9 -
 tools/xenstore/init-xenstore-domain.c | 119 
 xen/common/domain.c   |   6 +
 xen/common/domctl.c   |  14 +-
 xen/include/public/domctl.h   |   6 +
 xen/include/xen/sched.h   |   5 +
 xen/include/xsm/dummy.h   |   6 +
 xen/include/xsm/xsm.h |   1 +
 25 files changed, 620 insertions(+), 275 deletions(-)
 create mode 100644 tools/helpers/Makefile
 create mode 100644 tools/helpers/init-dom-json.c
 create mode 100644 

[Xen-devel] [PATCH v3 05/15] xenstore: adjust coding style of init-xenstore-domain.c

[Juergen Gross]

Adjust the coding style of init-xenstore-domain.c to the general Xen
coding style.

Signed-off-by: Juergen Gross 
---
 tools/helpers/init-xenstore-domain.c | 221 ---
 1 file changed, 126 insertions(+), 95 deletions(-)

diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index 297afe5..9c47af1 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -15,105 +15,136 @@ static uint32_t domid = -1;
 
 static int build(xc_interface *xch, int argc, char** argv)
 {
-   char cmdline[512];
-   uint32_t ssid;
-   xen_domain_handle_t handle = { 0 };
-   int rv, xs_fd;
-   struct xc_dom_image *dom = NULL;
-   int maxmem = atoi(argv[2]);
-   int limit_kb = (maxmem + 1)*1024;
-
-   xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
-   if (xs_fd == -1) return -1;
-
-   rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), );
-   if (rv) goto err;
-   rv = xc_domain_create(xch, ssid, handle, 0, , NULL);
-   if (rv) goto err;
-   rv = xc_domain_max_vcpus(xch, domid, 1);
-   if (rv) goto err;
-   rv = xc_domain_setmaxmem(xch, domid, limit_kb);
-   if (rv) goto err;
-   rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
-   if (rv) goto err;
-
-   rv = ioctl(xs_fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
-   if (rv < 0) goto err;
-   snprintf(cmdline, 512, "--event %d --internal-db", rv);
-
-   dom = xc_dom_allocate(xch, cmdline, NULL);
-   rv = xc_dom_kernel_file(dom, argv[1]);
-   if (rv) goto err;
-
-   if (argc > 4) {
-   rv = xc_dom_ramdisk_file(dom, argv[4]);
-   if (rv) goto err;
-   }
-
-   rv = xc_dom_boot_xen_init(dom, xch, domid);
-   if (rv) goto err;
-   rv = xc_dom_parse_image(dom);
-   if (rv) goto err;
-   rv = xc_dom_mem_init(dom, maxmem);
-   if (rv) goto err;
-   rv = xc_dom_boot_mem_init(dom);
-   if (rv) goto err;
-   rv = xc_dom_build_image(dom);
-   if (rv) goto err;
-   rv = xc_dom_boot_image(dom);
-   if (rv) goto err;
-
-   xc_dom_release(dom);
-   dom = NULL;
-
-   rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
-   if (rv) goto err;
-   rv = xc_domain_unpause(xch, domid);
-   if (rv) goto err;
-
-   return 0;
+char cmdline[512];
+uint32_t ssid;
+xen_domain_handle_t handle = { 0 };
+int rv, xs_fd;
+struct xc_dom_image *dom = NULL;
+int maxmem = atoi(argv[2]);
+int limit_kb = (maxmem + 1) * 1024;
+
+xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
+if ( xs_fd == -1 )
+return -1;
+
+rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), );
+if ( rv )
+goto err;
+rv = xc_domain_create(xch, ssid, handle, 0, , NULL);
+if ( rv )
+goto err;
+rv = xc_domain_max_vcpus(xch, domid, 1);
+if ( rv )
+goto err;
+rv = xc_domain_setmaxmem(xch, domid, limit_kb);
+if ( rv )
+goto err;
+rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
+if ( rv )
+goto err;
+
+rv = ioctl(xs_fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
+if ( rv < 0 )
+goto err;
+snprintf(cmdline, 512, "--event %d --internal-db", rv);
+
+dom = xc_dom_allocate(xch, cmdline, NULL);
+rv = xc_dom_kernel_file(dom, argv[1]);
+if ( rv )
+goto err;
+
+if ( argc > 4 )
+{
+rv = xc_dom_ramdisk_file(dom, argv[4]);
+if ( rv )
+goto err;
+}
+
+rv = xc_dom_boot_xen_init(dom, xch, domid);
+if ( rv )
+goto err;
+rv = xc_dom_parse_image(dom);
+if ( rv )
+goto err;
+rv = xc_dom_mem_init(dom, maxmem);
+if ( rv )
+goto err;
+rv = xc_dom_boot_mem_init(dom);
+if ( rv )
+goto err;
+rv = xc_dom_build_image(dom);
+if ( rv )
+goto err;
+rv = xc_dom_boot_image(dom);
+if ( rv )
+goto err;
+
+xc_dom_release(dom);
+dom = NULL;
+
+rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
+if ( rv )
+goto err;
+rv = xc_domain_unpause(xch, domid);
+if ( rv )
+goto err;
+
+return 0;
 
 err:
-   if (dom)
-   xc_dom_release(dom);
-   close(xs_fd);
-   return rv;
+if ( dom )
+xc_dom_release(dom);
+close(xs_fd);
+return rv;
 }
 
 int main(int argc, char** argv)
 {
-   xc_interface *xch;
-   struct xs_handle *xsh;
-   char buf[16];
-   int rv, fd;
-
-   if (argc < 4 || argc > 5) {
-   printf("Use: %s
[]\n", argv[0]);
-   return 2;
-   }
-
-   xch = xc_interface_open(NULL, NULL, 0);
-   if (!xch) return 1;
-
-   rv = build(xch, argc, argv);
-
-   xc_interface_close(xch);
-
-   if (rv) return 1;
-
-   xsh = xs_open(0);
-   rv = snprintf(buf, 16, "%d", domid);
-   xs_write(xsh, 

[Xen-devel] [PATCH v3 14/15] tools: don't stop xenstore domain when stopping dom0

[Juergen Gross]

When restarting or shutting down dom0 the xendomains script tries to
stop all other domains. Don't do this for the xenstore domain, as it
might survive a dom0 reboot in the future.

The same applies to xl shutdown --all. Here the xenstore domain is
flagged as "never stop".

Signed-off-by: Juergen Gross 
---
V3: xl shutdown modified to query the "never_stop" flag instead of
the xenstore domain id as requested by Ian Campbell
drop usage of xenstore-exists as requested by Ian Campbell
---
 tools/hotplug/Linux/xendomains.in | 15 +++
 tools/libxl/xl_cmdimpl.c  |  8 +---
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/tools/hotplug/Linux/xendomains.in 
b/tools/hotplug/Linux/xendomains.in
index dfe0b33..9f88649 100644
--- a/tools/hotplug/Linux/xendomains.in
+++ b/tools/hotplug/Linux/xendomains.in
@@ -196,6 +196,15 @@ rdnames()
 done
 }
 
+# get xenstore domain id (or 0 if no xenstore domain)
+get_xsdomid()
+{
+XS_DOMID=`${bindir}/xenstore-read /tool/xenstored/domid 2>/dev/null`
+if test $? -ne 0; then
+XS_DOMID=0
+fi
+}
+
 LIST_GREP='(domain\|(domid\|(name\|^{$\|"name":\|"domid":'
 parseln()
 {
@@ -216,12 +225,14 @@ parseln()
 
 is_running()
 {
+get_xsdomid
 rdname $1
 RC=1
 name=;id=
 while read LN; do
parseln "$LN" || continue
if test $id = 0; then continue; fi
+   if test $id = $XS_DOMID; then continue; fi
case $name in
($NM)
RC=0
@@ -302,10 +313,12 @@ start()
 
 all_zombies()
 {
+get_xsdomid
 name=;id=
 while read LN; do
parseln "$LN" || continue
if test $id = 0; then continue; fi
+   if test $id = $XS_DOMID; then continue; fi
if test "$state" != "-b---d" -a "$state" != "-d"; then
return 1;
fi
@@ -351,11 +364,13 @@ stop()
 if test "$XENDOMAINS_AUTO_ONLY" = "true"; then
rdnames
 fi
+get_xsdomid
 echo -n "Shutting down Xen domains:"
 name=;id=
 while read LN; do
parseln "$LN" || continue
if test $id = 0; then continue; fi
+   if test $id = $XS_DOMID; then continue; fi
echo -n " $name"
if test "$XENDOMAINS_AUTO_ONLY" = "true"; then
eval "
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f9933cb..29f9d19 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4856,15 +4856,17 @@ static int main_shutdown_or_reboot(int do_reboot, int 
argc, char **argv)
 if (wait_for_it)
 deathws = calloc(nb_domain, sizeof(*deathws));
 
+wait_for_it = 0;
 for (i = 0; i

[Xen-devel] [PATCH v3 02/15] libxc: support new xenstore domain flag in libxc

[Juergen Gross]

Support the xenstore domain flag for obtaining domain info.

Signed-off-by: Juergen Gross 
Acked-by: Ian Campbell 
---
V3: changed name of flag from "xs_domain" to "xenstore" as requested
by Ian Campbell
---
 tools/libxc/include/xenctrl.h | 2 +-
 tools/libxc/xc_domain.c   | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 01a6dda..079cad0 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -456,7 +456,7 @@ typedef struct xc_dominfo {
 uint32_t  ssidref;
 unsigned int  dying:1, crashed:1, shutdown:1,
   paused:1, blocked:1, running:1,
-  hvm:1, debugged:1, pvh:1;
+  hvm:1, debugged:1, pvh:1, xenstore:1;
 unsigned int  shutdown_reason; /* only meaningful if shutdown==1 */
 unsigned long nr_pages; /* current number, not maximum */
 unsigned long nr_outstanding_pages;
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 96506d5..99e0d48 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -374,6 +374,7 @@ int xc_domain_getinfo(xc_interface *xch,
 info->hvm  = !!(domctl.u.getdomaininfo.flags_DOMINF_hvm_guest);
 info->debugged = !!(domctl.u.getdomaininfo.flags_DOMINF_debugged);
 info->pvh  = !!(domctl.u.getdomaininfo.flags_DOMINF_pvh_guest);
+info->xenstore = !!(domctl.u.getdomaininfo.flags_DOMINF_xs_domain);
 
 info->shutdown_reason =
 (domctl.u.getdomaininfo.flags>>XEN_DOMINF_shutdownshift) &
-- 
2.6.2


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

[Xen-devel] [PATCH v3 13/15] xenstore: write xenstore domain data to xenstore

[Juergen Gross]

After starting the xenstore domain write the basic data (domid, name
and memory values) to the xenstore. This makes the domain appear
correctly in xl list. Create a stub json object in order to make e.g.
xl list -l happy.

Add a new option to init-xenstore-domain to be able to specify the
domain's name.

Signed-off-by: Juergen Gross 
Acked-by: Ian Campbell 
---
 tools/helpers/Makefile   |  6 +++--
 tools/helpers/init-xenstore-domain.c | 44 
 2 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
index 0325ba2..a05a368 100644
--- a/tools/helpers/Makefile
+++ b/tools/helpers/Makefile
@@ -15,10 +15,12 @@ $(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
 $(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxenstore)
 $(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
-INIT_XENSTORE_DOMAIN_OBJS = init-xenstore-domain.o
+INIT_XENSTORE_DOMAIN_OBJS = init-xenstore-domain.o init-dom-json.o
+$(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
 $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenguest)
 $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
 $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenstore)
+$(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
 .PHONY: all
 all: $(PROGS)
@@ -27,7 +29,7 @@ xen-init-dom0: $(XEN_INIT_DOM0_OBJS)
$(CC) $(LDFLAGS) -o $@ $(XEN_INIT_DOM0_OBJS) $(LDLIBS_libxentoollog) 
$(LDLIBS_libxenstore) $(LDLIBS_libxenlight) $(APPEND_LDFLAGS)
 
 init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS)
-   $(CC) $(LDFLAGS) -o $@ $(INIT_XENSTORE_DOMAIN_OBJS) 
$(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) 
$(APPEND_LDFLAGS)
+   $(CC) $(LDFLAGS) -o $@ $(INIT_XENSTORE_DOMAIN_OBJS) 
$(LDLIBS_libxentoollog) $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenguest) $(LDLIBS_libxenlight) $(APPEND_LDFLAGS)
 
 .PHONY: install
 install: all
diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index 238007b..5c5af2d 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -13,11 +13,14 @@
 #include 
 #include 
 
+#include "init-dom-json.h"
+
 static uint32_t domid = ~0;
 static char *kernel;
 static char *ramdisk;
 static char *flask;
 static char *param;
+static char *name = "Xenstore";
 static int memory;
 
 static struct option options[] = {
@@ -26,6 +29,7 @@ static struct option options[] = {
 { "flask", 1, NULL, 'f' },
 { "ramdisk", 1, NULL, 'r' },
 { "param", 1, NULL, 'p' },
+{ "name", 1, NULL, 'n' },
 { NULL, 0, NULL, 0 }
 };
 
@@ -42,7 +46,8 @@ static void usage(void)
 "  --memory  size of the domain in MB, mandatory\n"
 "  --flask   optional flask label of the domain\n"
 "  --ramdiskoptional ramdisk file for the domain\n"
-"  --param   optional additional parameters for the 
domain\n");
+"  --param   optional additional parameters for the domain\n"
+"  --name   name of the domain (default: Xenstore)\n");
 }
 
 static int build(xc_interface *xch)
@@ -216,6 +221,20 @@ static int check_domain(xc_interface *xch)
 return 0;
 }
 
+static void do_xs_write(struct xs_handle *xsh, char *path, char *val)
+{
+if ( !xs_write(xsh, XBT_NULL, path, val, strlen(val)) )
+fprintf(stderr, "writing %s to xenstore failed.\n", path);
+}
+
+static void do_xs_write_dom(struct xs_handle *xsh, char *path, char *val)
+{
+char full_path[64];
+
+snprintf(full_path, 64, "/local/domain/%d/%s", domid, path);
+do_xs_write(xsh, full_path, val);
+}
+
 int main(int argc, char** argv)
 {
 int opt;
@@ -243,6 +262,9 @@ int main(int argc, char** argv)
 case 'p':
 param = optarg;
 break;
+case 'n':
+name = optarg;
+break;
 default:
 usage();
 return 2;
@@ -274,10 +296,24 @@ int main(int argc, char** argv)
 if ( rv )
 return 1;
 
+rv = gen_stub_json_config(domid);
+if ( rv )
+return 3;
+
 xsh = xs_open(0);
-rv = snprintf(buf, 16, "%d", domid);
-xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
-xs_daemon_close(xsh);
+if ( !xsh )
+{
+fprintf(stderr, "xs_open() failed.\n");
+return 3;
+}
+snprintf(buf, 16, "%d", domid);
+do_xs_write(xsh, "/tool/xenstored/domid", buf);
+do_xs_write_dom(xsh, "domid", buf);
+do_xs_write_dom(xsh, "name", name);
+snprintf(buf, 16, "%d", memory * 1024);
+do_xs_write_dom(xsh, "memory/target", buf);
+do_xs_write_dom(xsh, "memory/static-max", buf);
+xs_close(xsh);
 
 fd = creat("/var/run/xenstored.pid", 0666);
 if ( fd < 0 )
-- 
2.6.2


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

[Xen-devel] [PATCH v3 09/15] xenstore: modify init-xenstore-domain parameter syntax

[Juergen Gross]

init-xenstore-domain takes only positional parameters today. Change
this to a more flexible parameter syntax allowing to specify additional
options or to omit some.

Today the supported usage is:

init-xenstore-domain   
 []

Modify this to:

init-xenstore-domain --kernel 
 --memory 
 [--flask ]
 [--ramdisk ]

The flask label is made optional in order to support xenstore domains
without the need of a flask enabled hypervisor.

Signed-off-by: Juergen Gross 
Acked-by: Ian Campbell 
---
 tools/helpers/init-xenstore-domain.c | 87 +---
 1 file changed, 71 insertions(+), 16 deletions(-)

diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index 124f29c..ff9968f 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -13,16 +14,42 @@
 #include 
 
 static uint32_t domid = ~0;
+static char *kernel;
+static char *ramdisk;
+static char *flask;
+static int memory;
 
-static int build(xc_interface *xch, int argc, char** argv)
+static struct option options[] = {
+{ "kernel", 1, NULL, 'k' },
+{ "memory", 1, NULL, 'm' },
+{ "flask", 1, NULL, 'f' },
+{ "ramdisk", 1, NULL, 'r' },
+{ NULL, 0, NULL, 0 }
+};
+
+static void usage(void)
+{
+fprintf(stderr,
+"Usage:\n"
+"\n"
+"init-xenstore-domain \n"
+"\n"
+"where options may include:\n"
+"\n"
+"  --kernel  kernel file of the xenstore domain, mandatory\n"
+"  --memory  size of the domain in MB, mandatory\n"
+"  --flask   optional flask label of the domain\n"
+"  --ramdiskoptional ramdisk file for the domain\n");
+}
+
+static int build(xc_interface *xch)
 {
 char cmdline[512];
 uint32_t ssid;
 xen_domain_handle_t handle = { 0 };
 int rv, xs_fd;
 struct xc_dom_image *dom = NULL;
-int maxmem = atoi(argv[2]);
-int limit_kb = (maxmem + 1) * 1024;
+int limit_kb = (memory + 1) * 1024;
 
 xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
 if ( xs_fd == -1 )
@@ -31,11 +58,18 @@ static int build(xc_interface *xch, int argc, char** argv)
 return -1;
 }
 
-rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), );
-if ( rv )
+if ( flask )
 {
-fprintf(stderr, "xc_flask_context_to_sid failed\n");
-goto err;
+rv = xc_flask_context_to_sid(xch, flask, strlen(flask), );
+if ( rv )
+{
+fprintf(stderr, "xc_flask_context_to_sid failed\n");
+goto err;
+}
+}
+else
+{
+ssid = SECINITSID_DOMU;
 }
 rv = xc_domain_create(xch, ssid, handle, 0, , NULL);
 if ( rv )
@@ -71,16 +105,16 @@ static int build(xc_interface *xch, int argc, char** argv)
 snprintf(cmdline, 512, "--event %d --internal-db", rv);
 
 dom = xc_dom_allocate(xch, cmdline, NULL);
-rv = xc_dom_kernel_file(dom, argv[1]);
+rv = xc_dom_kernel_file(dom, kernel);
 if ( rv )
 {
 fprintf(stderr, "xc_dom_kernel_file failed\n");
 goto err;
 }
 
-if ( argc > 4 )
+if ( ramdisk )
 {
-rv = xc_dom_ramdisk_file(dom, argv[4]);
+rv = xc_dom_ramdisk_file(dom, ramdisk);
 if ( rv )
 {
 fprintf(stderr, "xc_dom_ramdisk_file failed\n");
@@ -100,7 +134,7 @@ static int build(xc_interface *xch, int argc, char** argv)
 fprintf(stderr, "xc_dom_parse_image failed\n");
 goto err;
 }
-rv = xc_dom_mem_init(dom, maxmem);
+rv = xc_dom_mem_init(dom, memory);
 if ( rv )
 {
 fprintf(stderr, "xc_dom_mem_init failed\n");
@@ -154,16 +188,37 @@ err:
 
 int main(int argc, char** argv)
 {
+int opt;
 xc_interface *xch;
 struct xs_handle *xsh;
 char buf[16];
 int rv, fd;
 
-if ( argc < 4 || argc > 5 )
+while ( (opt = getopt_long(argc, argv, "", options, NULL)) != -1 )
+{
+switch ( opt )
+{
+case 'k':
+kernel = optarg;
+break;
+case 'm':
+memory = strtol(optarg, NULL, 10);
+break;
+case 'f':
+flask = optarg;
+break;
+case 'r':
+ramdisk = optarg;
+break;
+default:
+usage();
+return 2;
+}
+}
+
+if ( optind != argc || !kernel || !memory )
 {
-fprintf(stderr,
-"Use: %s
[]\n",
-argv[0]);
+usage();
 return 2;
 }
 
@@ -174,7 +229,7 @@ int main(int argc, char** argv)
 return 1;
 }
 
-rv = build(xch, argc, argv);
+rv = build(xch);
 
 xc_interface_close(xch);
 
-- 
2.6.2


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

[Xen-devel] [PATCH v3 04/15] xenstore: move init-xenstore-domain to tools/helpers

[Juergen Gross]

The program init-xenstore-domain to start a xenstore domain instead
of the xenstored daemon is built, but not installed. Change that.

Move the program to a new tools subdirectory "helpers" to be able to
use libxl in a later patch. Otherwise a dependency loop will be
created.

Signed-off-by: Juergen Gross 
---
V3: don't adapt coding style as requested by Ian Campbell
adjust .gitignore
---
 .gitignore |  2 +-
 tools/Makefile |  1 +
 tools/helpers/Makefile | 34 ++
 tools/{xenstore => helpers}/init-xenstore-domain.c |  0
 tools/xenstore/Makefile|  9 --
 5 files changed, 36 insertions(+), 10 deletions(-)
 create mode 100644 tools/helpers/Makefile
 rename tools/{xenstore => helpers}/init-xenstore-domain.c (100%)

diff --git a/.gitignore b/.gitignore
index e0df903..ec1cde3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -132,6 +132,7 @@ tools/flask/utils/flask-loadpolicy
 tools/flask/utils/flask-setenforce
 tools/flask/utils/flask-set-bool
 tools/flask/utils/flask-label-pci
+tools/helpers/init-xenstore-domain
 tools/hotplug/common/hotplugpath.sh
 tools/hotplug/FreeBSD/rc.d/xencommons
 tools/hotplug/FreeBSD/rc.d/xendriverdomain
@@ -200,7 +201,6 @@ tools/xenmon/xenbaked
 tools/xenpaging/xenpaging
 tools/xenpmd/xenpmd
 tools/xenstat/xentop/xentop
-tools/xenstore/init-xenstore-domain
 tools/xenstore/xenstore
 tools/xenstore/xenstore-chmod
 tools/xenstore/xenstore-exists
diff --git a/tools/Makefile b/tools/Makefile
index 9f74ac7..124919b 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -30,6 +30,7 @@ endif
 
 SUBDIRS-y += xenpmd
 SUBDIRS-y += libxl
+SUBDIRS-y += helpers
 SUBDIRS-$(CONFIG_X86) += xenpaging
 SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
 SUBDIRS-$(CONFIG_X86) += debugger/kdd
diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
new file mode 100644
index 000..52347fd
--- /dev/null
+++ b/tools/helpers/Makefile
@@ -0,0 +1,34 @@
+#
+# tools/helpers/Makefile
+#
+
+XEN_ROOT = $(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+ifeq ($(CONFIG_Linux),y)
+PROGS += init-xenstore-domain
+endif
+
+INIT_XENSTORE_DOMAIN_OBJS = init-xenstore-domain.o
+$(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenguest)
+$(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
+$(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenstore)
+
+.PHONY: all
+all: $(PROGS)
+
+init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS)
+   $(CC) $(LDFLAGS) -o $@ $(INIT_XENSTORE_DOMAIN_OBJS) 
$(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) 
$(APPEND_LDFLAGS)
+
+.PHONY: install
+install: all
+   $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+ifeq ($(CONFIG_Linux),y)
+   $(INSTALL_PROG) init-xenstore-domain $(DESTDIR)$(LIBEXEC_BIN)
+endif
+
+.PHONY: clean
+clean:
+   $(RM) -f *.o $(PROGS) $(DEPS)
+
+distclean: clean
diff --git a/tools/xenstore/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
similarity index 100%
rename from tools/xenstore/init-xenstore-domain.c
rename to tools/helpers/init-xenstore-domain.c
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 1b4a494..404d4cb 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -46,10 +46,6 @@ ifeq ($(XENSTORE_XENSTORED),y)
 ALL_TARGETS += xs_tdb_dump xenstored
 endif
 
-ifeq ($(CONFIG_Linux),y)
-ALL_TARGETS += init-xenstore-domain
-endif
-
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1
 endif
@@ -72,11 +68,6 @@ xenstored_probes.o: xenstored_solaris.o
 CFLAGS += -DHAVE_DTRACE=1
 endif
 
-init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
-
-init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
-   $(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) 
$(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
-
 xenstored: $(XENSTORED_OBJS)
$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ 
$(APPEND_LDFLAGS)
 
-- 
2.6.2


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

[Xen-devel] [PATCH v3 07/15] xenstore: destroy xenstore domain in case of error after creating it

[Juergen Gross]

When creating a xenstore domain via init-xenstore-domain destroy it
in case of an error occurred after calling xc_domain_create().

Signed-off-by: Juergen Gross 
Acked-by: Daniel De Graaf 
---
 tools/helpers/init-xenstore-domain.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index 9c47af1..a9c5821 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 
-static uint32_t domid = -1;
+static uint32_t domid = ~0;
 
 static int build(xc_interface *xch, int argc, char** argv)
 {
@@ -94,6 +94,8 @@ static int build(xc_interface *xch, int argc, char** argv)
 err:
 if ( dom )
 xc_dom_release(dom);
+if ( domid != ~0 )
+xc_domain_destroy(xch, domid);
 close(xs_fd);
 return rv;
 }
-- 
2.6.2


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

[Xen-devel] [PATCH v3 10/15] xenstore: make use of the "xenstore domain" flag

[Juergen Gross]

Create the xenstore domain with the xenstore flag specified. This
enables us to test whether such a domain is already running before
we create it. As there ought to be only one xenstore in the system
we don't need to start another one.

Signed-off-by: Juergen Gross 
---
V3: omit dom0 when checking for xenstore domain as suggested by Ian
Campbell
log an error in case of an error when obtaining domain info as
requested by Ian Campbell
---
 tools/helpers/init-xenstore-domain.c | 32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index ff9968f..ecced04 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -71,7 +71,8 @@ static int build(xc_interface *xch)
 {
 ssid = SECINITSID_DOMU;
 }
-rv = xc_domain_create(xch, ssid, handle, 0, , NULL);
+rv = xc_domain_create(xch, ssid, handle, XEN_DOMCTL_CDF_xs_domain,
+  , NULL);
 if ( rv )
 {
 fprintf(stderr, "xc_domain_create failed\n");
@@ -186,6 +187,28 @@ err:
 return rv;
 }
 
+static int check_domain(xc_interface *xch)
+{
+xc_dominfo_t info;
+uint32_t dom;
+int ret;
+
+dom = 1;
+while ( (ret = xc_domain_getinfo(xch, dom, 1, )) == 1 )
+{
+if ( info.xenstore )
+return 1;
+dom = info.domid + 1;
+}
+if ( ret < 0 && errno != ESRCH )
+{
+fprintf(stderr, "xc_domain_getinfo failed\n");
+return ret;
+}
+
+return 0;
+}
+
 int main(int argc, char** argv)
 {
 int opt;
@@ -229,7 +252,12 @@ int main(int argc, char** argv)
 return 1;
 }
 
-rv = build(xch);
+rv = check_domain(xch);
+
+if ( !rv )
+rv = build(xch);
+else if ( rv > 0 )
+fprintf(stderr, "xenstore domain already present.\n");
 
 xc_interface_close(xch);
 
-- 
2.6.2


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

Re: [Xen-devel] [PATCH v3 04/13] x86/time.c: Scale host TSC in pvclock properly

[Jan Beulich]

>>> On 08.01.16 at 14:22,  wrote:
> On 01/08/16 02:20, Jan Beulich wrote:
>> >>> On 31.12.15 at 04:03,  wrote:
>> > --- a/xen/arch/x86/time.c
>> > +++ b/xen/arch/x86/time.c
>> > @@ -815,10 +815,18 @@ static void __update_vcpu_system_time(struct vcpu 
>> > *v, int force)
>> >  }
>> >  else
>> >  {
>> > -tsc_stamp = t->local_tsc_stamp;
>> > -
>> > -_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
>> > -_u.tsc_shift = (s8)t->tsc_scale.shift;
>> > +if ( has_hvm_container_domain(d) && cpu_has_tsc_ratio )
>> 
>> For symmetry with patches 1 and 2 I'd expect !d->arch.vtsc to be
>> added here too.
> 
> even though it's already in the !d->arch.vtsc branch? But I'm fine to
> add it for symmetric.

Ah, no, I didn't realize (only looking at the patch) that it's in the
else to a respective if(). No need to change it then.

>> > +{
>> > +tsc_stamp= hvm_funcs.scale_tsc(v, 
> t->local_tsc_stamp);
>> > +_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
>> > +_u.tsc_shift = d->arch.vtsc_to_ns.shift;
>> > +}
>> > +else
>> > +{
>> > +tsc_stamp= t->local_tsc_stamp;
>> > +_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
>> > +_u.tsc_shift = (s8)t->tsc_scale.shift;
>> 
>> The case has been pointless anyway, and you don't add a similar
>> one in the if() branch - please delete it.
> 
> I don't understand why it's pointless. The inner if branch is to
> ensure pvclock provides the scaled TSC information when TSC scaling is
> used, and the inner else branch is to keep the existing behavior when
> TSC scaling is not used. For the outer if branch, TSC scaling is never
> used, so no change is needed.

Sorry, I see I typo-ed my reply. It was meant to start "The cast
has been ..."

Jan


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

Re: [Xen-devel] [PATCH v3 07/13] x86: Add functions for 64-bit integer arithmetic

[Haozhong Zhang]

On 01/08/16 02:34, Jan Beulich wrote:
> >>> On 31.12.15 at 04:03,  wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-x86/math64.h
> > @@ -0,0 +1,105 @@
> > +#ifndef __X86_MATH64
> > +#define __X86_MATH64
> > +
> > +/*
> > + * Functions defined in this file are derived from Linux kernel
> > + * (include/linux/math64.h).
> > + */
> 
> This is not true. At least mul64() doesn't exist in Linux (as of 4.4-rc8).
>

My fault. I took them from my KVM patches and didn't notice they were
refactored a little when merging.

> > +static inline void mul64(u64 *lo, u64 *hi, u64 a, u64 b)
> > +{
> > +typedef union {
> > +u64 ll;
> > +struct {
> > +u32 low, high;
> > +} l;
> > +} LL;
> > +LL rl, rm, rn, rh, a0, b0;
> > +u64 c;
> > +
> > +a0.ll = a;
> > +b0.ll = b;
> > +
> > +rl.ll = (u64)a0.l.low * b0.l.low;
> > +rm.ll = (u64)a0.l.low * b0.l.high;
> > +rn.ll = (u64)a0.l.high * b0.l.low;
> > +rh.ll = (u64)a0.l.high * b0.l.high;
> > +
> > +c = (u64)rl.l.high + rm.l.low + rn.l.low;
> > +rl.l.high = c;
> > +c >>= 32;
> > +c = c + rm.l.high + rn.l.high + rh.l.low;
> > +rh.l.low = c;
> > +rh.l.high += (u32)(c >> 32);
> > +
> > +*lo = rl.ll;
> > +*hi = rh.ll;
> > +}
> 
> For this one in particular, but likely also for the others: If this was
> put in include/xen/math64.h I might buy it. As an x86-specific
> implementation this could (and should) be done with a single asm()
> statement using the MUL instruction (I didn't check whether gcc
> also offers a built-in, which then could be used generically).
>

gcc does provide a 128-bit integer type __int128. If my memory is
correct, it can be used for above mul64, but can not be compiled in
Xen if being used for division. Anyway, as above functions are
x86-specific so far, I'll reimplement them by assembly in the next
version.

Haozhong

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

Re: [Xen-devel] [PATCH v3 01/15] xen: add xenstore domain flag to hypervisor

[Jan Beulich]

>>> On 08.01.16 at 14:08,  wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -318,6 +318,12 @@ struct domain *domain_create(domid_t domid, unsigned int 
> domcr_flags,
>  hardware_domain = d;
>  }
>  
> +if ( domcr_flags & DOMCRF_xs_domain )
> +{
> +d->is_xenstore = 1;
> +d->disable_migrate = 1;
> +}

It only occurred to me now: Wouldn't it be worth denying the domain
creation request if there already is a xenstore domain?

Jan


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