>>> On 04.11.15 at 22:09, wrote:
> On 04/11/2015 17:13, Jan Beulich wrote:
> On 04.11.15 at 16:15, wrote:
>>> Hi,
>>> i just build the latest 4.3.0 kernel and ran it on qubes-os with xen
>>> 4.4.3. I get this error just before the reboot:
>>>
>>> [(XEN) APIC error on CPU0: 40(00)
>>
>> And
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, November 03, 2015 6:04 PM
>
> >>> On 03.11.15 at 10:58, wrote:
> > On 02/11/15 14:10, Jan Beulich wrote:
> > On 02.11.15 at 09:03, wrote:
> >>> Based on above information, we propose to continue spin-timeout
> >>> model w/ some
flight 63570 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 60684
build-amd6
flight 63543 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63543/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR. vs. 63369
test-amd64-i386-xl-qem
Hi Dario,
Thank you very much for the explanation! I got it. To be specific,
2015-11-04 10:52 GMT-05:00 Dario Faggioli :
> On Wed, 2015-11-04 at 10:01 -0500, Meng Xu wrote:
> > 2015-11-04 9:12 GMT-05:00 Dario Faggioli :
> > > Just FTR (and for next time :-D), is the above something that can
> >
On November 4, 2015 10:02:26 PM EST, Bob Liu wrote:
>
>On 11/05/2015 10:30 AM, Konrad Rzeszutek Wilk wrote:
>> On Mon, Nov 02, 2015 at 12:21:43PM +0800, Bob Liu wrote:
>>> Preparatory patch for multiple hardware queues (rings). The number
>of
>>> rings is unconditionally set to 1, larger number wi
. snip..
> +void do_xsplice(void)
> +{
.. snip..
> +
> +xsplice_work.do_work = 0;
= false
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Tue, Nov 03, 2015 at 06:16:05PM +, Ross Lagerwall wrote:
> Implement support for the apply, revert and replace actions.
>
> To perform and action on a payload, the hypercall sets up a data
> structure to schedule the work. A hook is added in all the
> return-to-guest paths to check for wor
On 11/05/2015 10:30 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:43PM +0800, Bob Liu wrote:
>> Preparatory patch for multiple hardware queues (rings). The number of
>> rings is unconditionally set to 1, larger number will be enabled in next
>> patch so as to make every single p
flight 63540 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63540/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail REGR. vs. 63475
Regressions which ar
On 11/05/2015 10:43 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:46PM +0800, Bob Liu wrote:
>> Make pool of persistent grants and free pages per-queue/ring instead of
>> per-device to get better scalability.
>
> How much better scalability do we get?
>
Which already showed i
On Mon, Nov 02, 2015 at 12:21:46PM +0800, Bob Liu wrote:
> Make pool of persistent grants and free pages per-queue/ring instead of
> per-device to get better scalability.
How much better scalability do we get?
.. snip ..
>
>
> /*
> - * pers_gnts_lock must be used around all the persistent g
On Mon, Nov 02, 2015 at 12:21:45PM +0800, Bob Liu wrote:
> Make persistent grants per-queue/ring instead of per-device, so that we can
> drop the 'dev_lock' and get better scalability.
And what is the performance value for this? How much better
scalability do you get with this?
.. snip..
> @@ -101
On Mon, Nov 02, 2015 at 12:21:44PM +0800, Bob Liu wrote:
> Backend advertises "multi-queue-max-queues" to front, then get the negotiated
s/then/so/
> number from "multi-queue-num-queues" wrote by blkfront.
s/wrote/written/
>
> Signed-off-by: Bob Liu
> ---
> drivers/block/xen-blkback/blkback.c
On Mon, Nov 02, 2015 at 12:21:43PM +0800, Bob Liu wrote:
> Preparatory patch for multiple hardware queues (rings). The number of
> rings is unconditionally set to 1, larger number will be enabled in next
> patch so as to make every single patch small and readable.
Instead of saying 'next patch' -
On Wed, Nov 04, 2015 at 10:04:33AM -0700, Jan Beulich wrote:
> >>> On 03.11.15 at 07:27, wrote:
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index fe3be30..108d4f8 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -883,7 +883,12 @@ int arch_set_inf
This run is configured for baseline tests only.
flight 38248 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38248/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 6 xen-boot
flight 63536 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63536/
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 15 guest-localmigrate.2
fail REGR. vs. 59254
t
18.459943] IP: []
ptdump_walk_pgd_level_core+0x20e/0x440
[ 18.465847] PGD 2212067 PUD 0
[ 18.471564] Oops: [#1] SMP
[ 18.477248] Modules linked in:
[ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
4.3.0-mw-20151104-linus-doflr+ #1
[ 18.488804] Hardware name: MSI MS-7640/890FXA-GD7
On Wed, 2015-11-04 at 16:06 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 04, 2015 at 02:49:11AM +0200, M. Ivanov wrote:
> > Hello,
> >
> > I've experimented with my X10SAE and I think the problem with being
> > unable to resume after suspending to RAM has something to do with the
> > PCI Brid
On Tue, Nov 03, 2015 at 06:16:04PM +, Ross Lagerwall wrote:
> Add support for loading xsplice payloads. This is somewhat similar to
> the Linux kernel module loader, implementing the following steps:
> - Verify the elf file.
> - Parse the elf file.
> - Allocate a region of memory mapped within
On Tue, Nov 03, 2015 at 06:16:03PM +, Ross Lagerwall wrote:
> Add some elf routines and data structures in preparation for loading an
> xsplice payload.
>
> Signed-off-by: Ross Lagerwall
> ---
> xen/common/Makefile | 1 +
> xen/common/xsplice_elf.c | 122
> +
..snip..
Probably need this:
/* This value was choosen adhoc. It could be 42 too. */
> +#define MAX_LEN 11
> +static int list_func(int argc, char *argv[])
> +{
..snip..
> +
May be worth having an comment:
/* These MUST match to the 'action_options[]' array.
> +enum {
> +ACTION_APPLY = 0,
On Tue, Nov 03, 2015 at 06:15:59PM +, Ross Lagerwall wrote:
> From: Konrad Rzeszutek Wilk
It is very hard for me to review my own code, but mostly
what I see are some quite simple things (really really simple)
> diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> new file mode 100644
On Tue, Nov 03, 2015 at 06:15:58PM +, Ross Lagerwall wrote:
> From: Konrad Rzeszutek Wilk
>
> A mechanism is required to binarily patch the running hypervisor with new
> opcodes that have come about due to primarily security updates.
>
> This document describes the design of the API that wou
On 04/11/2015 17:13, Jan Beulich wrote:
On 04.11.15 at 16:15, wrote:
>> Hi,
>> i just build the latest 4.3.0 kernel and ran it on qubes-os with xen
>> 4.4.3. I get this error just before the reboot:
>>
>> [(XEN) APIC error on CPU0: 40(00)
>
> And this appeared with the switch to kernel 4.3?
On Wed, Nov 04, 2015 at 02:49:11AM +0200, M. Ivanov wrote:
> Hello,
>
> I've experimented with my X10SAE and I think the problem with being
> unable to resume after suspending to RAM has something to do with the
> PCI Bridge violating the spec by trying to DMA from another address,
> since I got a
x20e/0x440
[ 18.465847] PGD 2212067 PUD 0
[ 18.471564] Oops: [#1] SMP
[ 18.477248] Modules linked in:
[ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
4.3.0-mw-20151104-linus-doflr+ #1
[ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) ,
BIOS
V1.8B1 09/13/2010
[ 18.49
x20e/0x440
[ 18.465847] PGD 2212067 PUD 0
[ 18.471564] Oops: [#1] SMP
[ 18.477248] Modules linked in:
[ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
4.3.0-mw-20151104-linus-doflr+ #1
[ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) ,
BIOS
V1.8B1 09/13/2010
[ 18.49
flight 63533 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63533/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 62648
Regressions which are
flight 63624 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63624/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
Oops: [#1] SMP
[ 18.477248] Modules linked in:
[ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
4.3.0-mw-20151104-linus-doflr+ #1
[ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
V1.8B1 09/13/2010
[ 18.494778] task: 880059b9 ti: 880059b980
linked in:
[ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
4.3.0-mw-20151104-linus-doflr+ #1
[ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) ,
BIOS
V1.8B1 09/13/2010
[ 18.494778] task: 880059b9 ti: 880059b98000 task.ti:
880059b98000
[ 18.500852]
40
>[ 18.465847] PGD 2212067 PUD 0
>[ 18.471564] Oops: [#1] SMP
>[ 18.477248] Modules linked in:
>[ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
>4.3.0-mw-20151104-linus-doflr+ #1
>[ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
&
43] IP: []
> >ptdump_walk_pgd_level_core+0x20e/0x440
> >[ 18.465847] PGD 2212067 PUD 0
> >[ 18.471564] Oops: [#1] SMP
> >[ 18.477248] Modules linked in:
> >[ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
> >4.3.0-mw-20151104-linus-doflr+ #1
flight 63615 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63615/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
On 04/11/15 17:17, Dario Faggioli wrote:
> In fact, csched_vcpu_remove() (i.e., the credit1
> implementation of remove_vcpu()) manipulates runqueues,
> so holding the runqueue lock is necessary.
>
> However, the vCPU just can't be on the runqueue, when
> the function is called. We can therefore AS
In fact, csched_vcpu_remove() (i.e., the credit1
implementation of remove_vcpu()) manipulates runqueues,
so holding the runqueue lock is necessary.
However, the vCPU just can't be on the runqueue, when
the function is called. We can therefore ASSERT() that,
and avoid doing any runqueue manipulatio
Idle vCPUs are set to run immediately, as a part of their
own initialization, so we shouldn't even try to put them
in a runqueue. In fact, no scheduler does that, even when
asked to (that is rather explicit in Credit2 and RTDS, a
bit less evident in Credit1).
Let's make things look as follows:
-
As, curently, there is no reason for bothering having
it and keeping it updated.
In fact, it is only used for dumping and changing
vCPUs parameters, but that can be achieved easily with
for_each_vcpu.
While there, take care of the case when
XEN_DOMCTL_SCHEDOP_getinfo is called but no vCPUs have
b
The insert_vcpu() hook is handled with inconsistent locking.
In fact, schedule_cpu_switch() calls the hook with runqueue
lock held, while sched_move_domain() relies on the hook
implementations to take the lock themselves (and, since that
is not done in Credit1 and RTDS, such operation is not safe
i
schedule_cpu_switch() is meant to be only used for moving
pCPUs from a cpupool to no cpupool, and from there back
to a cpupool, *not* to move them directly from one cpupool
to another.
This is something inherent to the way the function is
implemented and called, but is not that clear, just by the
As, curently, there is no reason for bothering having
it and keeping it updated.
In fact, it is only used for dumping and changing
vCPUs parameters, but that can be achieved easily with
for_each_vcpu.
While there, improve alignment of comments, ad
add a const qualifier to a pointer, making things
Hi,
This series, improves how inserting vCPUs in schedulers runqueues is done,
including fixing a couple of bugs, and paving the way for more improvement in
Credit2 runqueue handling (will be submitted as a separate series).
v3 is here:
http://lists.xenproject.org/archives/html/xen-devel/2015-10
Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
set_xen_guest_handle_raw"):
> On 04.11.15 at 17:50, wrote:
> > If we don't provide a get_xen_guest_handle, a kernel developer will be
> > sorely tempted to make one.
>
> What use would it be to them? Kernels only write handle
>>> On 04.11.15 at 17:50, wrote:
> Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
> set_xen_guest_handle_raw"):
>> All quite interesting, but pretty moot with there not being any
>> get_xen_guest_handle() anymore.
>
> If we don't provide a get_xen_guest_handle, a kernel d
>>> On 03.11.15 at 07:27, wrote:
> This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor
> to perform the xsave_area switching so that xen itself
> can benefit from them when available.
>
> For xsaves/xrstors/xsavec only use compact format. Add format conversion
> support when perform
On 04/11/15 16:50, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
> set_xen_guest_handle_raw"):
>> All quite interesting, but pretty moot with there not being any
>> get_xen_guest_handle() anymore.
>
> If we don't provide a get_xen_guest_handle, a kern
Ian Jackson writes ("[OSSTEST PATCH v14 PART 1 0/9] Nested HVM preparation
patches"):
> This is the first part of Robert Hu's osstest patch series to support
> nested HVM tests. (v13 was passed to me as a git branch `under the
> table' by Robert.) I have rewritten the commit messages, refactored
Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
set_xen_guest_handle_raw"):
> All quite interesting, but pretty moot with there not being any
> get_xen_guest_handle() anymore.
If we don't provide a get_xen_guest_handle, a kernel developer will be
sorely tempted to make one.
>>> On 04.11.15 at 17:22, wrote:
> Julien Grall writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
> set_xen_guest_handle_raw"):
>> On 03/11/15 14:18, Stefano Stabellini wrote:
>> >> +#define set_xen_guest_handle_raw(hnd, val) \
>> >> +do {
flight 63532 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63532/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 63437
test-amd64-i386-xl-qemuu-w
Ian Jackson writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
set_xen_guest_handle_raw"):
> void *copy = (val);
> struct xen_guest_handle__pointer *src = &(hnd);
> struct xen_guest_handle__pointer *dst = &(xen_xgh_copy);
I have my src and dst the wrong way round, and have
Julien Grall writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
set_xen_guest_handle_raw"):
> On 03/11/15 14:18, Stefano Stabellini wrote:
> >> +#define set_xen_guest_handle_raw(hnd, val) \
> >> +do {
>>> On 04.11.15 at 17:05, wrote:
> El 03/11/15 a les 13.41, Jan Beulich ha escrit:
> On 03.11.15 at 11:57, wrote:
>>> On 03/11/15 07:21, Jan Beulich wrote:
>>> On 30.10.15 at 16:36, wrote:
> On 30/10/15 13:16, Jan Beulich wrote:
> On 30.10.15 at 13:50, wrote:
>>> El 14/1
>>> On 04.11.15 at 16:15, wrote:
> Hi,
> i just build the latest 4.3.0 kernel and ran it on qubes-os with xen
> 4.4.3. I get this error just before the reboot:
>
> [(XEN) APIC error on CPU0: 40(00)
And this appeared with the switch to kernel 4.3? No other variable
(e.g. all config options new i
pper/0 Not tainted
4.3.0-mw-20151104-linus-doflr+ #1
[ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
V1.8B1 09/13/2010
[ 18.494778] task: 880059b9 ti: 880059b98000 task.ti:
880059b98000
[ 18.500852] RIP: e030:[] []
ptdump_walk_pgd_level_core+0x20e/0x440
[
On Thu, 2015-10-29 at 16:28 +, Wei Liu wrote:
> On Wed, Oct 21, 2015 at 04:23:14PM +0100, Ian Campbell wrote:
> > libxengnttab will provide a stable API and ABI for accessing the
> > grant table devices.
> >
> > The functions are moved into the xengnt{tab,shr} namespace to make a
> > clean bre
On Tue, Nov 3, 2015 at 6:36 PM, Ian Campbell wrote:
> On Tue, 2015-10-27 at 10:40 -0600, Jan Beulich wrote:
>> > > > On 27.10.15 at 17:32, wrote:
>> > And what are you suggesting about the patch? Create a separate OMAP
>> > specific header?
>>
>> For #define-s used by only a single source file I'
El 03/11/15 a les 13.41, Jan Beulich ha escrit:
On 03.11.15 at 11:57, wrote:
>> On 03/11/15 07:21, Jan Beulich wrote:
>> On 30.10.15 at 16:36, wrote:
On 30/10/15 13:16, Jan Beulich wrote:
On 30.10.15 at 13:50, wrote:
>> El 14/10/15 a les 16.37, Jan Beulich ha escrit:
>
On Wed, 2015-11-04 at 15:46 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework
> the macro set_xen_guest_handle_raw"):
> > The writer via one is the guest and reader via the other is the
> > hypervisor,
> > so no matter what they are certainly diff
On Wed, 2015-11-04 at 10:01 -0500, Meng Xu wrote:
> 2015-11-04 9:12 GMT-05:00 Dario Faggioli :
> > Just FTR (and for next time :-D), is the above something that can
> > be
> > interpreted as a 'Reviewed-by: Meng Xu ' ? If no (e.g.,
> > because
> > you haven't looking thoroughly enough to feel conf
Ian Campbell writes ("Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the
macro set_xen_guest_handle_raw"):
> The writer via one is the guest and reader via the other is the hypervisor,
> so no matter what they are certainly different compilation units, even in
> the face of whole program opti
Ian Jackson writes ("Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the
macro set_xen_guest_handle_raw"):
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 4/4] xen/public: arm:
> rework the macro set_xen_guest_handle_raw"):
> > Finally, based on the defect report #283 [2], the behavior o
The next Xen technical call will be at:
Wed 11 Nov 17:00:00 GMT 2015
`date -d @1447261200`
See http://lists.xen.org/archives/html/xen-devel/2015-01/msg00414.html
for more information on the call.
Please let me know (CC-ing the list) any topics which you would like to
discuss. It might be
On Wed, 2015-11-04 at 11:48 +0100, Dario Faggioli wrote:
> In fact, right now, failing at destroying a cpupool is just
> not reported to the user in any explicit way.
>
> Let's log an error, as it is customary for xl in these cases.
>
> Signed-off-by: Dario Faggioli
> Reviewed-by: Juergen Gross
On Wed, 2015-11-04 at 13:03 +0100, Dario Faggioli wrote:
> Rearange the case when we check the new number of vCPUs
> against the number of host pCPUs not to use rc for internal
> error reporting. In fact:
> - rc was at risk of being used uninitialised;
> - rc should only be used for holding libxl
On Tue, 2015-11-03 at 17:20 +, Wei Liu wrote:
> Acked-by: Wei Liu
Applied w/ this + Ian J's ack.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, 2015-11-04 at 15:19 +, Stefano Stabellini wrote:
> On Wed, 4 Nov 2015, Julien Grall wrote:
> > On 04/11/15 11:27, Ian Campbell wrote:
> > > On Wed, 2015-11-04 at 11:17 +, Julien Grall wrote:
> > > > >
> > > > > we could:
> > > > > #ifdef(__XEN__)
> > > > > #define XEN_BUILD_BUG_ON(
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework
the macro set_xen_guest_handle_raw"):
> Finally, based on the defect report #283 [2], the behavior of writing
> from one member and reading from another is not clear.
Because the hypervisor is compiled with -fno-stric
On Wed, 4 Nov 2015, Julien Grall wrote:
> On 04/11/15 11:27, Ian Campbell wrote:
> > On Wed, 2015-11-04 at 11:17 +, Julien Grall wrote:
> >>>
> >>> we could:
> >>> #ifdef(__XEN__)
> >>> #define XEN_BUILD_BUG_ON(x) BUILD_BUG_ON(x)
> >>> #elif !defined(XEN_BUILD_BUG_ON)
> >>> #define XEN_BUILD_BU
>>> On 04.11.15 at 16:07, wrote:
> On 04/11/15 14:45, Jan Beulich wrote:
> On 30.10.15 at 20:59, wrote:
>>> Using local labels causes the stack trace to use the last non-local
>>> label emitted by the compiler in the translation unit, which is almost
>>> always unrelated.
>>>
>>> e.g. A (cont
Hi,
i just build the latest 4.3.0 kernel and ran it on qubes-os with xen
4.4.3. I get this error just before the reboot:
[(XEN) APIC error on CPU0: 40(00)
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
I can also see some weird acpi-related messages on the log i attached, like:
(XEN) ACPI:
All,
I am pleased to announce the release of Xen 4.5.2. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.5
(tag RELEASE-4.5.2) or from the XenProject download page
http://www.xenproject.org/downloads/xen-archives/xen-4
On 04/11/15 14:45, Jan Beulich wrote:
On 30.10.15 at 20:59, wrote:
>> Using local labels causes the stack trace to use the last non-local
>> label emitted by the compiler in the translation unit, which is almost
>> always unrelated.
>>
>> e.g. A (contrived debug) example switches from:
>>
>>
Hi Dario,
2015-11-04 9:12 GMT-05:00 Dario Faggioli :
> On Mon, 2015-11-02 at 09:45 -0500, Meng Xu wrote:
> > > > I guess maybe you forgot to change it in this commit but change
> > > > it
> > > > the
> > > > following commit?
> > > >
> > > No, this is one of the few thing that changed between v2
This run is configured for baseline tests only.
flight 38247 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38247/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf fad21b7c57336bbf0ae363d56e35cbccca67ff3b
baseline version:
ovm
On Wed, 2015-11-04 at 14:42 +, Julien Grall wrote:
> On 04/11/15 14:29, Ian Campbell wrote:
> > > > > > This looses out on the arm32 hypervisor sanity checking that
> > > > > > the
> > > > > > padding
> > > > > > bytes are 0 (as required by the ABI) but TBH I haven't checked
> > > > > > that
>
>>> On 30.10.15 at 20:59, wrote:
> Using local labels causes the stack trace to use the last non-local
> label emitted by the compiler in the translation unit, which is almost
> always unrelated.
>
> e.g. A (contrived debug) example switches from:
>
> (XEN) [ Xen-4.7-unstable x86_64 debu
On 04/11/15 14:29, Ian Campbell wrote:
> This looses out on the arm32 hypervisor sanity checking that the
> padding
> bytes are 0 (as required by the ABI) but TBH I haven't checked that
> the
> current version has that property either.
It's done during the assignation
On Wed, 2015-11-04 at 11:40 +, Julien Grall wrote:
> > Not sure I follow. If hnd isn't a suitable struct xen guest handle then
> > other things will fail. If a user is passing a non struct
> > xen_guest_handle
> > to this which happens to contain the same fields then more fool them,
> > and
> >
On Wed, 2015-11-04 at 13:39 +0200, Riku Voipio wrote:
Not to do with this patch (and this suggestion wouldn't have helped in this
case) but IIRC Linaro tests the xen.git#staging branch.
We recently introduced a new "smoke test" phase which is a quick[0] test
which runs on staging before the regul
On Mon, 2015-11-02 at 09:45 -0500, Meng Xu wrote:
> > > I guess maybe you forgot to change it in this commit but change
> > > it
> > > the
> > > following commit?
> > >
> > No, this is one of the few thing that changed between v2 and v3.
> >
> > Regards,
> > Dario
>
> Thanks for the explanation!
>>> On 04.11.15 at 12:39, wrote:
> In commit:
>
> d37d63d symbols: prefix static symbols with their source file names
>
> An unchecked fgets was added. This causes a compile error:
>
> symbols.c: In function 'read_symbol':
> symbols.c:181:3: error: ignoring return value of 'fgets', declared wit
flight 63594 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63594/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
flight 63529 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63529/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 62642
Tests which are failin
flight 63530 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63530/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf fad21b7c57336bbf0ae363d56e35cbccca67ff3b
baseline version:
ovmf 8aa6ebe83f91fcd5e1a67d316e444f4ac8b
Wei Liu writes ("[VOTE] Release cycle scheme"):
> There are comments made by individuals that couldn't be clearly
> represent in tally. The most acceptable option to stable tree
> maintainers is #1.
>
> So I propose we use the following scheme:
+1
Following Ian Campbell's lead, I want to commen
Le 12 août 2015 11:04 AM, "Ian Campbell" a écrit :
>
>
> (Having written the below I see too late that this is a grub patch not a
> Xen one, a tag in the subject for such cross posted patches would be
useful
> please. Anyway, my opinion counts for very little in this context but I
> leave it below
Rearange the case when we check the new number of vCPUs
against the number of host pCPUs not to use rc for internal
error reporting. In fact:
- rc was at risk of being used uninitialised;
- rc should only be used for holding libxl error codes.
Signed-off-by: Dario Faggioli
---
Cc: Ian Campbell
to handle kernel paging request at
88055c883000
[ 18.459943] IP: []
ptdump_walk_pgd_level_core+0x20e/0x440
[ 18.465847] PGD 2212067 PUD 0
[ 18.471564] Oops: [#1] SMP
[ 18.477248] Modules linked in:
[ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
4.3.0-mw-20151104-linus
On Wed, 2015-11-04 at 11:47 +, Ian Campbell wrote:
> On Wed, 2015-11-04 at 12:38 +0100, Dario Faggioli wrote:
> > On Wed, 2015-11-04 at 11:32 +, Wei Liu wrote:
> >
> > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > > index 2756d2f..9b6b42c 100644
> > > --- a/tools/l
On Wed, 2015-11-04 at 12:38 +0100, Dario Faggioli wrote:
> On Wed, 2015-11-04 at 11:32 +, Wei Liu wrote:
>
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 2756d2f..9b6b42c 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -5473,7
On 04/11/15 11:27, Ian Campbell wrote:
> On Wed, 2015-11-04 at 11:17 +, Julien Grall wrote:
>>>
>>> we could:
>>> #ifdef(__XEN__)
>>> #define XEN_BUILD_BUG_ON(x) BUILD_BUG_ON(x)
>>> #elif !defined(XEN_BUILD_BUG_ON)
>>> #define XEN_BUILD_BUG_ON(x)
>>> #endif
>>> and using XEN_BUILD_BUG_ON in the
In commit:
d37d63d symbols: prefix static symbols with their source file names
An unchecked fgets was added. This causes a compile error:
symbols.c: In function 'read_symbol':
symbols.c:181:3: error: ignoring return value of 'fgets', declared with
attribute warn_unused_result [-Werror=unused-res
On Wed, 2015-11-04 at 11:32 +, Wei Liu wrote:
> In 5b725e56 (xl: improve return and exit codes of vcpu related
> functions), the return value of libxl_cpu_bitmap_alloc was not stored in
> rc anymore. Yet the subsequent fprintf still used that.
>
> Reinstate the original implementation, that is
On Wed, 2015-11-04 at 11:32 +, Wei Liu wrote:
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 2756d2f..9b6b42c 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -5473,7 +5473,8 @@ static int vcpuset(uint32_t domid, const char*
> nr_vcpus,
flight 63584 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63584/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
In 5b725e56 (xl: improve return and exit codes of vcpu related
functions), the return value of libxl_cpu_bitmap_alloc was not stored in
rc anymore. Yet the subsequent fprintf still used that.
Reinstate the original implementation, that is, to store return value of
libxl_cpu_bitmap_alloc in rc befo
On Mon, 2015-11-02 at 13:47 +, Wei Liu wrote:
>
> So I propose we use the following scheme:
>
> - 6 months release cycle from unstable branch.
> - 4 months development.
> - 2 months freeze.
+1
> - Eat into next cycle if doesn't release on time.
+2
> - Fixed cut-off date: the Fridays
1 - 100 of 132 matches
Mail list logo
