Zhang, Yang Z wrote on 2015-09-24:
> Liuqiming (John) wrote on 2015-09-24:
>>
>>
>> On 2015/9/24 11:25, Zhang, Yang Z wrote:
>> it completed, the following vmentry will pick up the pending interrupt.
>> If you send the ipi unconditionally, actually it is received by
>> hypervisor and the interrup
flight 62738 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62738/
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 13 guest-localmigrate
fail REGR. vs. 62318
Tests
Jan Beulich wrote on 2015-09-29:
> With x2APIC requiring iommu_supports_eim() to return true, we can
> adjust a few conditonals such that both it and
> platform_supports_x2apic() can be marked __init. For the latter as
> well as for platform_supports_intremap() also change the return types
> to boo
This run is configured for baseline tests only.
flight 38149 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38149/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 64df44b7e5d005598828c990500c2427bb131e8f
baseline version:
ovm
On Thu, Oct 08, 2015 at 11:23:56AM +0800, He Chen wrote:
> CDP extends CAT and provides the capacity to control L3 code & data
> cache. With CDP, one COS corresponds to two CMBs(code & data). cbm_type
> is added to distinguish different CBM operations. Besides, new domctl
> cmds are introdunced to
> +if ( (ecx & PSR_CAT_CDP_CAPABILITY) && (opt_psr & PSR_CDP) &&
> + cdp_socket_enable && !test_bit(socket, cdp_socket_enable) )
> +{
> +rdmsrl(MSR_IA32_PSR_L3_QOS_CFG, val);
> +wrmsrl(MSR_IA32_PSR_L3_QOS_CFG, val | (1 <<
> PSR_L3_QOS_CDP_ENABLE_
Jan Beulich wrote on 2015-09-28:
> GFN zero is a valid address, and hence may need invalidation done for
> it just like for any other GFN.
>
> Signed-off-by: Jan Beulich
Acked-by: Yang Zhang
> ---
> The comment right before the respective dmar_writeq() confuses me:
> What "first" TLB reg does
flight 62740 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62740/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 64df44b7e5d005598828c990500c2427bb131e8f
baseline version:
ovmf 86cce64da95783fbc990934e75901cfadd7
On 10/05/2015 10:55 PM, Roger Pau Monné wrote:
> El 05/09/15 a les 14.39, Bob Liu ha escrit:
>> Split per ring information to an new structure:xen_blkif_ring, so that one
>> vbd
>> device can associate with one or more rings/hardware queues.
>>
>> This patch is a preparation for supporting multi
flight 62733 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 7 host-ping-check-xen fail REGR. vs. 62711
test-armhf-armhf-xl-
On 09/10/2015 04:01, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 09, 2015 at 06:48:23PM +0200, Dario Faggioli wrote:
> > Hey,
> >
> > As far as my bisection goes, commit
> > 49388f11d512bb92706ce046643bfbb3c1d963c9 "x86/cpufreq: relocate the
> > driver register function" prevents me from hot unplugg
flight 62730 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62730/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-raw 3 host-install(3) broken REGR. vs. 627
On Fri, Oct 09, 2015 at 06:48:23PM +0200, Dario Faggioli wrote:
> Hey,
>
> As far as my bisection goes, commit
> 49388f11d512bb92706ce046643bfbb3c1d963c9 "x86/cpufreq: relocate the
> driver register function" prevents me from hot unplugging pCPUs.
>
> Xen does not crash or anything, but dom0 is s
flight 62727 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62727/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass
test-armhf-armhf-libvirt-raw 9 debian-di-i
On Fri, Oct 09, 2015 at 04:12:12PM +0100, Ian Campbell wrote:
> On Thu, 2015-10-08 at 17:23 +0200, Juergen Gross wrote:
> > The pv domain builder currently supports the additional flag
> > "superpages" to build a pv domain with 2MB pages. This feature isn't
> > being used by any component other tha
On 10/09/2015 12:51 PM, Haozhong Zhang wrote:
On Fri, Oct 09, 2015 at 12:31:53PM -0400, Boris Ostrovsky wrote:
On 10/09/2015 12:19 PM, Jan Beulich wrote:
On 09.10.15 at 18:09, wrote:
On 10/09/2015 11:11 AM, Jan Beulich wrote:
On 09.10.15 at 16:00, wrote:
On Fri, Oct 09, 2015 at 09:41:36AM
At 18:01 +0100 on 09 Oct (113710), Andrew Cooper wrote:
> to avoid console corruption.
>
> Signed-off-by: Andrew Cooper
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, Oct 9, 2015 at 7:26 AM, Andrew Cooper
wrote:
> On 08/10/15 21:57, Tamas K Lengyel wrote:
> > diff --git a/xen/arch/x86/mm/mem_sharing.c
> b/xen/arch/x86/mm/mem_sharing.c
> > index a95e105..4cdddb1 100644
> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @
Ian Jackson writes ("[OSSTEST PATCH] standalone-generate-dump-flight-runvars:
Handle ^C properly"):
> This is all mad.
...
> +# I _think_ that that any signal which arrives before the assignment
> +# to $SIG{} will definitely have caused our parent to vanish and us to
> +# be reparented to pid 1 b
Ian Campbell writes ("[PATCH OSSTEST v3] ap-fetch-*: Support
$AP_FETCH_PLACEHOLDERS envvar which outputs a placeholder"):
> And use this in standalone-generate-dump-flight-runvars. In general I
> don't think we are interested in the specific revision_* runvars when
> using this tool but when it ma
On Fri, Oct 9, 2015 at 1:51 AM, Jan Beulich wrote:
> >>> On 08.10.15 at 22:57, wrote:
> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @@ -1293,6 +1293,37 @@ int relinquish_shared_pages(struct domain *d)
> > return rc;
> > }
> >
> > +static int bulk_share
This is all mad.
Signed-off-by: Ian Jackson
---
standalone-generate-dump-flight-runvars | 24
1 file changed, 24 insertions(+)
diff --git a/standalone-generate-dump-flight-runvars
b/standalone-generate-dump-flight-runvars
index a1907b0..efedd5c 100755
--- a/standalon
to avoid console corruption.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 3759232..58f131c 10064
On Fri, 2015-10-09 at 14:05 +0100, Andrew Cooper wrote:
> On 08/10/15 21:39, Dario Faggioli wrote:
> > On Thu, 2015-10-08 at 16:20 +0100, Andrew Cooper wrote:
> > > On 08/10/15 15:58, George Dunlap wrote:
> > > > Generic scheduling code is called from interrupt contexts --
> > > > namely,
> > > >
On Fri, Oct 09, 2015 at 12:31:53PM -0400, Boris Ostrovsky wrote:
> On 10/09/2015 12:19 PM, Jan Beulich wrote:
> On 09.10.15 at 18:09, wrote:
> >>On 10/09/2015 11:11 AM, Jan Beulich wrote:
> >>On 09.10.15 at 16:00, wrote:
> On Fri, Oct 09, 2015 at 09:41:36AM -0400, Boris Ostrovsky wrot
Hey,
As far as my bisection goes, commit
49388f11d512bb92706ce046643bfbb3c1d963c9 "x86/cpufreq: relocate the
driver register function" prevents me from hot unplugging pCPUs.
Xen does not crash or anything, but dom0 is stalled. In fact, with
current staging, here's what I see:
root@Zhaman:~# echo
On 10/09/2015 12:39 PM, Haozhong Zhang wrote:
On Fri, Oct 09, 2015 at 11:37:06AM -0400, Boris Ostrovsky wrote:
On 10/09/2015 10:39 AM, Jan Beulich wrote:
On 09.10.15 at 15:41, wrote:
On 10/09/2015 02:51 AM, Jan Beulich wrote:
On 28.09.15 at 09:13, wrote:
When the TSC mode of a domain is TS
On Fri, Oct 09, 2015 at 11:37:06AM -0400, Boris Ostrovsky wrote:
> On 10/09/2015 10:39 AM, Jan Beulich wrote:
> On 09.10.15 at 15:41, wrote:
> >>On 10/09/2015 02:51 AM, Jan Beulich wrote:
> >>On 28.09.15 at 09:13, wrote:
> When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC e
On 10/09/2015 12:19 PM, Jan Beulich wrote:
On 09.10.15 at 18:09, wrote:
On 10/09/2015 11:11 AM, Jan Beulich wrote:
On 09.10.15 at 16:00, wrote:
On Fri, Oct 09, 2015 at 09:41:36AM -0400, Boris Ostrovsky wrote:
On 10/09/2015 02:51 AM, Jan Beulich wrote:
On 28.09.15 at 09:13, wrote:
When th
>>> On 09.10.15 at 18:09, wrote:
> On 10/09/2015 11:11 AM, Jan Beulich wrote:
> On 09.10.15 at 16:00, wrote:
>>> On Fri, Oct 09, 2015 at 09:41:36AM -0400, Boris Ostrovsky wrote:
On 10/09/2015 02:51 AM, Jan Beulich wrote:
On 28.09.15 at 09:13, wrote:
>> When the TSC mode of
And use this in standalone-generate-dump-flight-runvars. In general I
don't think we are interested in the specific revision_* runvars when
using this tool but when it matters this new behaviour can be avoided
by setting AP_FETCH_PLACEHOLDERS=n.
This is quicker even than using memoisation on the a
On Fri, 2015-10-09 at 17:06 +0100, Ian Jackson wrote:
>
[...]
Agree with that analysis, thanks.
> In any case, I have tried this several times both with and without
> eatmydata and it seems to work fine for me.
Me too, today.
> I may prepare a patch to make standalone-generate-dump-flight-runv
On 10/09/2015 11:11 AM, Jan Beulich wrote:
On 09.10.15 at 16:00, wrote:
On Fri, Oct 09, 2015 at 09:41:36AM -0400, Boris Ostrovsky wrote:
On 10/09/2015 02:51 AM, Jan Beulich wrote:
On 28.09.15 at 09:13, wrote:
When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
is used, th
Ian Campbell writes ("[RFC OSSTEST v2] ap-fetch-*: Support
$AP_FETCH_PLACEHOLDERS envvar which outputs a placeholder"):
> Still RFC because of these sqlite errors
>
> DBD::SQLite::db do failed: UNIQUE constraint failed: jobs.flight,
> jobs.job [for Statement "INSERT INTO jobs VALUES
flight 62726 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate.2 fail REGR. vs.
62552
test-amd64-i3
On 10/09/2015 10:43 AM, Jan Beulich wrote:
On 09.10.15 at 16:35, wrote:
On Fri, Oct 09, 2015 at 12:51:32AM -0600, Jan Beulich wrote:
On 28.09.15 at 09:13, wrote:
When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
is used, the existing tsc_get_info() calculates elapsed_nse
flight 38142 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38142/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-armhf-jessie-netboot-pygrub 9 debian-di-install fail REGR.
vs. 38116
flight 62728 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62728/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 60684
test-amd64
On 10/09/2015 10:39 AM, Jan Beulich wrote:
On 09.10.15 at 15:41, wrote:
On 10/09/2015 02:51 AM, Jan Beulich wrote:
On 28.09.15 at 09:13, wrote:
When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
is used, the existing tsc_get_info() calculates elapsed_nsec by scaling
the h
On 09/10/15 16:30, Ian Campbell wrote:
> Julien, will you add the new compat string in your next version?
I will do.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, 2015-10-09 at 16:17 +0100, Mark Rutland wrote:
> On Fri, Oct 09, 2015 at 04:08:17PM +0100, Ian Campbell wrote:
> > On Thu, 2015-10-08 at 19:45 +0100, Julien Grall wrote:
> > > From Xen point of view, PSCI v0.2 and PSCI v1.0 are very similar. All
> > > the PSCI calls used within Xen (PSCI_VE
Hi Ian,
On 09/10/15 16:08, Ian Campbell wrote:
> On Thu, 2015-10-08 at 19:45 +0100, Julien Grall wrote:
>> From Xen point of view, PSCI v0.2 and PSCI v1.0 are very similar. All
>> the PSCI calls used within Xen (PSCI_VERSION, CPU_ON, SYSTEM_OFF and
>> SYSTEM_RESET) behaves exactly the same.
>>
>>
>>> On 09.10.15 at 04:56, wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -108,12 +108,13 @@ $(TARGET)-syms: prelink.o xen.lds
> $(BASEDIR)/common/symbols-dummy.o
> $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
> $(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/t
On Fri, Oct 09, 2015 at 04:08:17PM +0100, Ian Campbell wrote:
> On Thu, 2015-10-08 at 19:45 +0100, Julien Grall wrote:
> > From Xen point of view, PSCI v0.2 and PSCI v1.0 are very similar. All
> > the PSCI calls used within Xen (PSCI_VERSION, CPU_ON, SYSTEM_OFF and
> > SYSTEM_RESET) behaves exactly
>>> On 09.10.15 at 15:25, wrote:
> On Fri, Oct 09, 2015 at 01:15:42PM +0100, Andrew Cooper wrote:
>> On 09/10/15 09:17, Jan Beulich wrote:
>> On 09.10.15 at 04:56, wrote:
>> >> However they also change the behavior of the existing hypercall
>> >> for XENVER_[compile_info|changeset|commandlin
In latest weeks building xen 4.6 with debug enable qemu trace was
missed, today building xen 4.6.0 I found the cause.
Even if debug ?= y in Config.mk, config/Tools.mk is not generate
correctly, have this line:
debug := @debug@
I not found the exact cause for doing the patch that f
On Thu, 2015-10-08 at 17:23 +0200, Juergen Gross wrote:
> The pv domain builder currently supports the additional flag
> "superpages" to build a pv domain with 2MB pages. This feature isn't
> being used by any component other than the python xc bindings.
>
> Remove the flag and it's support from t
>>> On 09.10.15 at 16:00, wrote:
> On Fri, Oct 09, 2015 at 09:41:36AM -0400, Boris Ostrovsky wrote:
>> On 10/09/2015 02:51 AM, Jan Beulich wrote:
>> On 28.09.15 at 09:13, wrote:
>> >>When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
>> >>is used, the existing tsc_get_info
On Thu, 2015-10-08 at 19:45 +0100, Julien Grall wrote:
> It will avoid to introduce a new XEN_PSCI_* define every time we support
> a new version of PSCI in Xen.
>
> Also fix the coding style in modified place.
>
> Signed-off-by: Julien Grall
Acked-by: Ian Campbell
__
On Thu, 2015-10-08 at 19:45 +0100, Julien Grall wrote:
> From Xen point of view, PSCI v0.2 and PSCI v1.0 are very similar. All
> the PSCI calls used within Xen (PSCI_VERSION, CPU_ON, SYSTEM_OFF and
> SYSTEM_RESET) behaves exactly the same.
>
> While there is no compatible string to represent PSCI
On Fri, 2015-10-09 at 08:38 -0600, Jan Beulich wrote:
> > > > On 09.10.15 at 14:46, wrote:
> > On Fri, 2015-10-09 at 13:29 +0100, Andrew Cooper wrote:
> > > On 09/10/15 09:25, Jan Beulich wrote:
> > > > > > > On 09.10.15 at 04:56, wrote:
> > > > > All existing commands ignore the parameter so thi
>>> On 09.10.15 at 16:35, wrote:
> On Fri, Oct 09, 2015 at 12:51:32AM -0600, Jan Beulich wrote:
>> >>> On 28.09.15 at 09:13, wrote:
>> > When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
>> > is used, the existing tsc_get_info() calculates elapsed_nsec by scaling
>> > the hos
On Fri, 2015-10-02 at 01:17 +0200, Dario Faggioli wrote:
> make-flight | 36 ++--
FWIW the make-flight side of this looks fine to me.
We discussed the save-restore allowances already.
___
Xen-devel mailing list
Xen-d
>>> On 09.10.15 at 15:41, wrote:
> On 10/09/2015 02:51 AM, Jan Beulich wrote:
> On 28.09.15 at 09:13, wrote:
>>> When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
>>> is used, the existing tsc_get_info() calculates elapsed_nsec by scaling
>>> the host TSC with a ratio bet
>>> On 09.10.15 at 14:46, wrote:
> On Fri, 2015-10-09 at 13:29 +0100, Andrew Cooper wrote:
>> On 09/10/15 09:25, Jan Beulich wrote:
>> > > > > On 09.10.15 at 04:56, wrote:
>> > > All existing commands ignore the parameter so this does
>> > > not break the ABI.
>> > Does it not? What about the deb
On Sat, 2015-10-03 at 02:39 +0200, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli
Acked-by: Ian Campbell
There's probably no need for this to wait for the rest.
> ---
> Cc: Ian Jackson
> Cc: Ian Campbell
> Cc: Juergen Gross
> ---
> Changes from v2:
> * new patch, the introduction of
On Fri, Oct 09, 2015 at 12:51:32AM -0600, Jan Beulich wrote:
> >>> On 28.09.15 at 09:13, wrote:
> > When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
> > is used, the existing tsc_get_info() calculates elapsed_nsec by scaling
> > the host TSC with a ratio between guest TSC rat
On Sat, 2015-10-03 at 02:39 +0200, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli
> ---
> Cc: Ian Jackson
> Cc: Ian Campbell
> Cc: Juergen Gross
This looks correct to me as it stands, but I think it will be impacted by
the changes relating to host flags for numbers of cpus etc.
> ---
>
>>> On 09.10.15 at 14:15, wrote:
> On 09/10/15 09:17, Jan Beulich wrote:
>> The more that the tool stack uses the two, and as we know
>> tool stacks or parts thereof can live in unprivileged domains.
>
> I would argue than a fully unprivileged toolstack domain has no need for
> any information fr
On Fri, Oct 09, 2015 at 09:41:36AM -0400, Boris Ostrovsky wrote:
> On 10/09/2015 02:51 AM, Jan Beulich wrote:
> On 28.09.15 at 09:13, wrote:
> >>When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
> >>is used, the existing tsc_get_info() calculates elapsed_nsec by scaling
>
On 10/09/2015 02:51 AM, Jan Beulich wrote:
On 28.09.15 at 09:13, wrote:
When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
is used, the existing tsc_get_info() calculates elapsed_nsec by scaling
the host TSC with a ratio between guest TSC rate and
nanoseconds. However, the r
On 09/10/15 05:42, Juergen Gross wrote:
>
>
> Andrew, which of those does your xen_bugtool use?
Currently just xc.domain_getinfo()
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, 2015-10-09 at 14:22 +0100, Ian Jackson wrote:
> > (is that worth mentioning? is it correct?)
>
> No. This reuse machinery does not consider the versions of anything -
> except, now, osstest itself. This is because the other trees'
> versions are supposed to be intercompatible.
Ah, I'm a
On 08/10/15 21:57, Tamas K Lengyel wrote:
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index a95e105..4cdddb1 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1293,6 +1293,37 @@ int relinquish_shared_pages(struct domain *d)
>
On Fri, Oct 09, 2015 at 01:15:42PM +0100, Andrew Cooper wrote:
> On 09/10/15 09:17, Jan Beulich wrote:
> On 09.10.15 at 04:56, wrote:
> >> However they also change the behavior of the existing hypercall
> >> for XENVER_[compile_info|changeset|commandline] and make them
> >> dom0 accessible. T
Ian Campbell writes ("Re: [OSSTEST PATCH 3/3] smoke tests: Consider osstest
revision when reusing builds"):
> Probably a bad idea, but I wonder: would comparing the hostflags required
> of the two build hosts take care of some of this?
>
> e.g. some random job I just pulled up:
>
> share-bui
And use this in standalone-generate-dump-flight-runvars. In general I
don't think we are interested in the specific revision_* runvars when
using this tool but it can be avoided using AP_FETCH_PLACEHOLDERS=n
when calling standalone-generate-dump-flight-runvars.
This is quicker even than using memo
On Thu, 2015-10-08 at 22:56 -0400, Konrad Rzeszutek Wilk wrote:
> If the hypervisor is built with we will display it.
I think there is a word missing in this sentence. Perhaps "it" after
"with", or better "a build_id" or "blah blah feature enabled".
> @@ -5295,8 +5298,21 @@ const libxl_version_in
On Fri, 2015-10-09 at 14:06 +0100, Ian Campbell wrote:
> On Fri, 2015-10-09 at 13:59 +0100, Andrew Cooper wrote:
> > On 09/10/15 03:56, Konrad Rzeszutek Wilk wrote:
> > > +rc = xc_version_len(ctx->xch, XENVER_build_id, &u.build_id,
> > > BUILD_ID_LEN);
> > > +if (rc > 0) {
> > > +un
On 09/10/15 14:06, Ian Campbell wrote:
> On Fri, 2015-10-09 at 13:59 +0100, Andrew Cooper wrote:
>> On 09/10/15 03:56, Konrad Rzeszutek Wilk wrote:
>>> +rc = xc_version_len(ctx->xch, XENVER_build_id, &u.build_id,
>>> BUILD_ID_LEN);
>>> +if (rc > 0) {
>>> +unsigned int i;
>>> +
>>> +
On Fri, 2015-10-09 at 13:59 +0100, Andrew Cooper wrote:
> On 09/10/15 03:56, Konrad Rzeszutek Wilk wrote:
> > +rc = xc_version_len(ctx->xch, XENVER_build_id, &u.build_id,
> > BUILD_ID_LEN);
> > +if (rc > 0) {
> > +unsigned int i;
> > +
> > +info->build_id = (char *)malloc((r
On 08/10/15 21:39, Dario Faggioli wrote:
> On Thu, 2015-10-08 at 16:20 +0100, Andrew Cooper wrote:
>> On 08/10/15 15:58, George Dunlap wrote:
>>> Generic scheduling code is called from interrupt contexts --
>>> namely,
>>> vcpu_wake()
>> There are a lot of codepaths, but I cant see one which is def
On 09/10/15 03:56, Konrad Rzeszutek Wilk wrote:
> +rc = xc_version_len(ctx->xch, XENVER_build_id, &u.build_id,
> BUILD_ID_LEN);
> +if (rc > 0) {
> +unsigned int i;
> +
> +info->build_id = (char *)malloc((rc * 2) + 1);
> +
> +for (i = 0; i < rc && (i + 1) * 2 < BUILD
On 09/10/15 13:46, Ian Campbell wrote:
> On Fri, 2015-10-09 at 13:29 +0100, Andrew Cooper wrote:
>> On 09/10/15 09:25, Jan Beulich wrote:
>> On 09.10.15 at 04:56, wrote:
All existing commands ignore the parameter so this does
not break the ABI.
>>> Does it not? What about the debug m
On 09/10/15 03:56, Konrad Rzeszutek Wilk wrote:
> @@ -367,6 +368,35 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg,
> if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
> return -EFAULT;
> return 0;
> +
> +case XENVER_build_id:
>
On Fri, Oct 02, 2015 at 10:48:54AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 16, 2015 at 05:01:11PM -0400, Konrad Rzeszutek Wilk wrote:
> >
> > *OK, what do you have?*
> >
> > They are located at a git tree:
> > git://xenbits.xen.org/people/konradwilk/xen.git xsplice.v1
>
> I've create
On Fri, 2015-10-09 at 13:29 +0100, Andrew Cooper wrote:
> On 09/10/15 09:25, Jan Beulich wrote:
> > > > > On 09.10.15 at 04:56, wrote:
> > > All existing commands ignore the parameter so this does
> > > not break the ABI.
> > Does it not? What about the debug mode clobbering of hypercall
> > argum
On Thu, Oct 08, 2015 at 03:07:19PM -0600, Tamas K Lengyel wrote:
> In case you miss it, there is now soft-reset support which dumps all
> > memory plus various states from one domain to another, and toolstack
> > will take care of QEMU and various userspace bits. This might be useful
> > to you?
>
On Fri, 2015-10-09 at 12:48 +0100, Ian Jackson wrote:
> No functional change with existing invocations.
>
> Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, 2015-10-09 at 12:48 +0100, Ian Jackson wrote:
> No functional change.
>
> Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, 2015-10-09 at 12:48 +0100, Ian Jackson wrote:
> Build results done with one version of osstest are not necessarily
> reuseable with a different version of osstest. For example, the suite
> may have changed. The smoke tests try to reuse builds from
> xen-unstable but if osstest changes inc
On 09/10/15 09:25, Jan Beulich wrote:
On 09.10.15 at 04:56, wrote:
>> All existing commands ignore the parameter so this does
>> not break the ABI.
> Does it not? What about the debug mode clobbering of hypercall
> argument registers?
That is an implementation detail of the hypervisor. It i
On 09/10/15 03:56, Konrad Rzeszutek Wilk wrote:
> The XENVER_[compile_info|changeset|commandline] are now
> guarded by an XSM check.
>
> The rest: XENVER_[version|extraversion|capabilities|
> parameters|get_features|page_size|guest_handle] behave
> as before (no XSM check).
>
> We allow the initial
Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is only
one usage in the Xen source tree: pygrub is using xc.xeninfo().
I wrote a patch to remove all libxc Python bindings but xc.xeninfo() and
got some feedback re
On 09/10/15 09:17, Jan Beulich wrote:
On 09.10.15 at 04:56, wrote:
>> However they also change the behavior of the existing hypercall
>> for XENVER_[compile_info|changeset|commandline] and make them
>> dom0 accessible. This is if XSM is built in or not (though with
>> XSM one can expose it to
Build results done with one version of osstest are not necessarily
reuseable with a different version of osstest. For example, the suite
may have changed. The smoke tests try to reuse builds from
xen-unstable but if osstest changes incompatibly, the smoke tests
might repeatedly fail until a xen-u
No functional change with existing invocations.
Signed-off-by: Ian Jackson
---
sg-check-tested |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sg-check-tested b/sg-check-tested
index 1a3afa3..43f2854 100755
--- a/sg-check-tested
+++ b/sg-check-tested
@@ -80,8 +80,9 @@
No functional change.
Signed-off-by: Ian Jackson
---
Osstest.pm | 17 +
Osstest/Executive.pm | 18 +-
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/Osstest.pm b/Osstest.pm
index 4a763c6..969a2d0 100644
--- a/Osstest.pm
+++ b/Osstes
On 09.10.2015 04:56, Konrad Rzeszutek Wilk wrote:
> @@ -367,6 +368,35 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg,
> if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
> return -EFAULT;
> return 0;
> +
> +case XENVER_build_id:
On Fri, 2015-10-09 at 12:24 +0100, Julien Grall wrote:
> I plan to fix it in patch #1 and request a backport for Xen 4.6 and Xen
> 4.5. I can do a separate patch if we don't want the cleanup.
I'm not quite sure what you are proposing but please put logical changes
and cleanups into separate patch
On 08/10/15 19:36, Julien Grall wrote:
> On 08/10/15 15:25, Ian Campbell wrote:
>>> If the concern is the behavior is changed, I'm happy to rework this code
>>> to keep exactly the same behavior. I.e any 32-bit write containing
>>> a 0 byte will be ignored. This is not optimal but at least I'm not
This run is configured for baseline tests only.
flight 38140 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 19 guest-start.2
On Thu, Oct 08, 2015 at 05:42:56PM +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST v3 3/3] Create a flight to test
> OpenStack with xen-unstable and libvirt"):
> > On Tue, 2015-09-29 at 17:52 +0100, Ian Jackson wrote:
> > > All these revision_FOO=master are rather odd.
> >
>
On 09/10/15 10:22, Ian Campbell wrote:
> On Thu, 2015-10-08 at 20:22 +0100, Julien Grall wrote:
>> When restoring the system register state for an AArch32 guest at EL2,
>> writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
>> which can lead to the guest effectively running into u
On Fri, 2015-10-09 at 10:33 +, osstest service owner wrote:
> flight 62725 qemu-mainline real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/62725/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
flight 62725 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62725/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 3 host-install(3)broken REGR. vs. 62649
On Thu, Oct 08, 2015 at 10:25:42AM -0700, Mark Pryor wrote:
> Signed-off-by: Mark Pryor
There is already a fix in tree for 4.6. You can request backporting
commit 6596412d59bcde3d1a2473f341851f4c476fc9df
Author: Konrad Rzeszutek Wilk
Date: Mon Aug 24 15:48:58 2015 -0400
etherboot: Build
FTR:
09:12 <@ijc> Diziet: elbling0 seems to have stopped pxe booting and is
always booting from it's disk:
09:12 <@ijc>
http://logs.test-lab.xenproject.org/osstest/results/host/elbling0.html
09:12 <@ijc>
http://logs.test-lab.xenproject.org/osstest/logs/62716/test-amd64-amd64-xl-qemu
> On 9 Oct 2015, at 11:08, Ian Campbell wrote:
>
> On Fri, 2015-10-09 at 10:57 +0100, Lars Kurth wrote:
>>
>>
I could also include qemu-traditional into (3), which I have not
counted
in the past. So I was thinking I'd not do this.
>>>
>>> qemu-traditional doesn't get much traf
On 10/09/2015 11:43 AM, Ian Campbell wrote:
On Fri, 2015-10-09 at 06:42 +0200, Juergen Gross wrote:
Is it okay to remove all of the unused bindings?
Please can you remind me what your motivation is here, just cleaning up
detritus or are some of these bindings actively hindering work you are
d
1 - 100 of 129 matches
Mail list logo