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
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
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
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
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
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 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: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: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 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
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: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
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
. 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 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
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
> >
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
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
> 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
>>> 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
"git clean -fdx" doesn't change the error result with gcc 4.4.7. Gcc version is
"gcc-4.4.?" in Debian Jessie of yours?
Additional, gcc 4.8.5 in RHEL7.2 works for build ovmf.
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Wednesday, November 4, 2015 12:19 AM
>
Hi everyone,
may I ask you to prioritise this vote, such that 4.7 release planning can
start? Right now, it is holding up the release planning process, which normally
starts around a month after a release (the release was on the 13th of Oct, well
a little earlier of we count branching).
Lars
>
flight 63528 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63528/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340
Tests which did not succe
On Wed, 2015-11-04 at 08:27 +, Hao, Xudong wrote:
Please don't top post.
> "git clean -fdx" doesn't change the error result with gcc 4.4.7. Gcc
> version is "gcc-4.4.?" in Debian Jessie of yours?
"git clean -fdx" won't clean recursively into any sub git trees (some extra
number of -f and/or
On Wed, 2015-10-28 at 07:56 +0530, Harmandeep Kaur wrote:
All seems to be acked by Wei and Reviewed by Dario => applied, thanks
everyone.
> *Its my "bite size contribution" that is required for applying to the
> Outreachy program.
>
> *main_foo() is treated somewhat as a regular main(), it is ch
On Wed, 2015-11-04 at 09:40 +, Ian Campbell wrote:
> On Wed, 2015-10-28 at 07:56 +0530, Harmandeep Kaur wrote:
>
> All seems to be acked by Wei and Reviewed by Dario => applied, thanks
> everyone.
BTW, Harmandeep, I think I have now applied everything you have submitted.
There were a couple o
flight 38246 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38246/
Perfect :-)
All tests in this flight passed
baseline version:
flight 38217
jobs:
build-amd64 pass
build-armhf
On Mon, Nov 2, 2015 at 1:47 PM, Wei Liu wrote:
> - 6 months release cycle from unstable branch.
> - 4 months development.
> - 2 months freeze.
> - Eat into next cycle if doesn't release on time.
...
> - Stable branch maintained for 18 months full support plus 18 months
> security support.
On Wed, Nov 4, 2015 at 9:38 AM, Ian Campbell wrote:
> On Wed, 2015-11-04 at 08:27 +, Hao, Xudong wrote:
>
> Please don't top post.
>
>> "git clean -fdx" doesn't change the error result with gcc 4.4.7. Gcc
>> version is "gcc-4.4.?" in Debian Jessie of yours?
>
> "git clean -fdx" won't clean rec
On Wed, 2015-11-04 at 10:04 +, George Dunlap wrote:
> On Wed, Nov 4, 2015 at 9:38 AM, Ian Campbell
> wrote:
> > On Wed, 2015-11-04 at 08:27 +, Hao, Xudong wrote:
> >
> > Please don't top post.
> >
> > > "git clean -fdx" doesn't change the error result with gcc 4.4.7. Gcc
> > > version is
flight 63527 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 63466
Regressions which a
On Tue, 2015-11-03 at 17:50 +, Anthony PERARD wrote:
> On Tue, Nov 03, 2015 at 05:30:32PM +, Ian Campbell wrote:
> > On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> > > Hi all,
> > >
> > > I've start to look at loading the BIOS and the ACPI tables via the
> > > toolstack instead
On Wed, Nov 04, 2015 at 08:27:56AM +, Hao, Xudong wrote:
> "git clean -fdx" doesn't change the error result with gcc 4.4.7. Gcc version
> is "gcc-4.4.?" in Debian Jessie of yours?
>
Debian Jessie's gcc-4.4 has the same version 4.4.7.
As the other sub-thread suggests, can you try passing mor
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> Those paths are to be used by libxl, in order to load the firmware in
> memory. If a system path is not define, then this default to the Xen
> firmware directory.
AIUI these are both existing variables which are right now exposed only to
t
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> ... into the firmware directory, along with hvmloader.
>
> Signed-off-by: Anthony PERARD
> ---
> .gitignore | 1 +
> tools/firmware/Makefile| 15 +++
> tools/firmware/hvmloader/acp
On 26/10/15 16:03, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
> ---
> tools/firmware/hvmloader/hvmloader.c | 69
> +++-
> 1 file changed, 68 insertions(+), 1 deletion(-)
As part of using the DMLite infrastructure, hvmloader should gain
appropriate elfn
>>> On 02.11.15 at 14:47, wrote:
> So I propose we use the following scheme:
>
> - 6 months release cycle from unstable branch.
> - 4 months development.
> - 2 months freeze.
> - Eat into next cycle if doesn't release on time.
> - Fixed cut-off date: the Fridays of the week in which the las
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
Acked-by: Wei Liu
---
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ia
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> The path to the BIOS blob can be override by the xl's bios_override
> option,
> or provided by u.hvm.bios_filename in the domain_build_info struct by
> other
> libxl user.
>
> Signed-off-by: Anthony PERARD
> ---
> tools/libxl/libxl_dom.c
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> The path to the ACPI tables blob can be override by xl's option
"overridden"
> acpi_table_override or by acpi_tables_filename in the domain_build_info
> struct for libxl user.
This needs the same libxl.h #define and xl.cfg update I ment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.4-rc0-tag
xen: features for 4.4-rc0
- - Improve balloon driver memory hotplug placement.
- - Use unpopulated hotplugged memory for fore
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
> ---
> tools/firmware/hvmloader/hvmloader.c | 69
> +++-
> 1 file changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/tools/firmware/hvmloader/hvmloader.c
> b/tools/fir
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> The BIOS can be found in one of the entry of the modlist of the
> hvm_start_info struct. The order of the modules are define by the command
> line option "modules".
>
> The found BIOS blob is not loaded by this patch, but only passed as
>
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> ... and do not include the SeaBIOS ROM into hvmloader anymore.
... but don't yet stop including it in rom.inc (I suppose that comes later)
Can we add a new hook to chose an address for the bios which the common
code which handles the no-b
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.
While it is trivial to reinstate the original implementation, xl's
caller has no idea what a libxl error c
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> ... and do not include the OVMF ROM into hvmloader anymore.
>
> Signed-off-by: Anthony PERARD
> ---
> tools/firmware/hvmloader/ovmf.c | 22 +++---
> 1 file changed, 7 insertions(+), 15 deletions(-)
>
> diff --git a/tools
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
This might invalidate some of my earlier comments about reusing bios_addr,
in which case that other commit ought to make reference to the eventual
goal.
But...
> @@ -432,9 +424,9 @@ int main(void)
> if ( SCRATCH_PHYSICAL_ADDRESS != scr
Hi,
On 03/11/15 14:34, Ian Campbell wrote:
> On Tue, 2015-11-03 at 14:01 +, Julien Grall wrote:
>> On 03/11/15 12:35, Ian Campbell wrote:
>>> On Mon, 2015-11-02 at 15:55 +, Stefano Stabellini wrote:
> +/*
> + * Macro to set a guest pointer in the handle.
> + *
> + * N
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> ... and use it with both SeaBIOS and OVMF.
>
> This may change the behavior of guest using OVMF as the ACPI tables
> currently loaded are the one for qemu-xen-traditionnal.
"traditional".
I'm a bit surprised using the trad ones works, gi
On Wed, 2015-11-04 at 11:15 +, 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.
>
> While it is trivial to reinstate the original
On Wed, Nov 04, 2015 at 11:23:29AM +, Ian Campbell wrote:
> On Wed, 2015-11-04 at 11:15 +, 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 fprint
On Wed, 2015-11-04 at 11:17 +, Julien Grall wrote:
> Hi,
>
>
> On 03/11/15 14:34, Ian Campbell wrote:
> > On Tue, 2015-11-03 at 14:01 +, Julien Grall wrote:
> > > On 03/11/15 12:35, Ian Campbell wrote:
> > > > On Mon, 2015-11-02 at 15:55 +, Stefano Stabellini wrote:
> > > > >
> > > >
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
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
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
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,
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
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 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
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 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
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
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
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
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
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
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 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
>>> 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
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 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 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 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 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 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
>
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
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
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:
>>
>>
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
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:
>>> 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
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
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, 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(
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 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 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
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
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
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
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
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
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 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'
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
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 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
>>> 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
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 {
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
1 - 100 of 132 matches
Mail list logo
