flight 99664 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99664/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
96211
test-amd64-i386-xl
On 25/07/16 23:14, Boris Ostrovsky wrote:
> xen_smp_intr_init() and xen_smp_intr_free() are now called from
> enlighten.c and therefore not guaranteed to have CONFIG_SMP.
>
> Instead of adding multiple ifdefs there provide stubs in smp.h
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen G
blk_mq_update_nr_hw_queues() reset all queue limits to default which it's not
as xen-blkfront expected, introducing blkif_set_queue_limits() to reset limits
with initial correct values.
Signed-off-by: Bob Liu
---
v2: Move blkif_set_queue_limits() after blkfront_gather_backend_features.
---
drive
Two places didn't get updated when 64KB page granularity was introduced, this
patch fix them.
Signed-off-by: Bob Liu
Acked-by: Roger Pau Monné
---
drivers/block/xen-blkfront.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block
The current VBD layer reserves buffer space for each attached device based on
three statically configured settings which are read at boot time.
* max_indirect_segs: Maximum amount of segments.
* max_ring_page_order: Maximum order of pages to be used for the shared ring.
* max_queues: Maximum of
flight 99656 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99656/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
96188
test-amd64-i386-x
Hi Boris,
On Mon, 25 Jul 2016 18:25:00 -0400 Boris Ostrovsky
wrote:
>
> > Jeremy Fitzhardinge
>
> Jeremy is no longer involved with Xen. However,
>
> Juergen Gross
>
> is also Linux Xen/x86 maintainer.
I have replaced Jeremy with Juergen.
--
Cheers,
Stephen Rothwell
__
flight 99681 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99681/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf daea123d247aebb01f6c54e10ed1e0b10dfae957
baseline version:
ovmf 227a1ac2d04504eee4c624f
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/xen/smp.c
between commit:
4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()")
from the tip tree and commit:
ad5475f9faf5 ("x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op")
from
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/xen/enlighten.c
between commit:
4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()")
from the tip tree and commit:
88e957d6e47f ("xen: introduce xen_vcpu_id mapping")
from the xen-tip tre
On 07/25/2016 07:40 PM, Stefano Stabellini wrote:
On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
On Mon, 25 Jul 2016, George Dunlap wrote:
On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
wrote:
You are assuming that the guest will map the
flight 99605 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99605/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-build fail REGR. vs. 97664
build-i386-prev
This run is configured for baseline tests only.
flight 66808 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66808/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 14 guest-saverestor
On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
> On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
> > On Mon, 25 Jul 2016, George Dunlap wrote:
> >> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
> >> wrote:
> You are assuming that the guest will map the ACPI blob with the same
> att
On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
> On Mon, 25 Jul 2016, George Dunlap wrote:
>> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
>> wrote:
You are assuming that the guest will map the ACPI blob with the same
attributes as the rest of the superpage.
IHMO, a
On 07/25/2016 06:19 PM, Stephen Rothwell wrote:
> Hi Stefano,
>
> On Mon, 25 Jul 2016 10:29:11 -0700 (PDT) Stefano Stabellini
> wrote:
>> The To and CC list for these emails is a bit outdated. I want to make
>> sure they reach the right people. Could you please add:
>>
>> boris.ostrov...@oracle.c
On Tue, 26 Jul 2016, Stephen Rothwell wrote:
> Hi Stefano,
>
> On Mon, 25 Jul 2016 10:29:11 -0700 (PDT) Stefano Stabellini
> wrote:
> >
> > The To and CC list for these emails is a bit outdated. I want to make
> > sure they reach the right people. Could you please add:
> >
> > boris.ostrov...@o
Hi Stefano,
On Mon, 25 Jul 2016 10:29:11 -0700 (PDT) Stefano Stabellini
wrote:
>
> The To and CC list for these emails is a bit outdated. I want to make
> sure they reach the right people. Could you please add:
>
> boris.ostrov...@oracle.com
> david.vra...@citrix.com
OK, I have added them as c
On Mon, 25 Jul 2016, George Dunlap wrote:
> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
> wrote:
> >> You are assuming that the guest will map the ACPI blob with the same
> >> attributes as the rest of the superpage.
> >>
> >> IHMO, a sane operating system will want to map the ACPI blob r
On Mon, 25 Jul 2016, Julien Grall wrote:
> On 25/07/16 14:39, Vitaly Kuznetsov wrote:
> > Julien Grall writes:
> >
> > > Hi David,
> > >
> > > On 25/07/16 13:38, David Vrabel wrote:
> > > > On 30/06/16 16:56, Vitaly Kuznetsov wrote:
> > > > > It may happen that Xen's and Linux's ideas of vCPU id
flight 99607 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99607/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-build fail REGR. vs. 97740
build-amd64
On Mon, 25 Jul 2016, David Vrabel wrote:
> On 25/07/16 14:17, Julien Grall wrote:
> > Hi David,
> >
> > On 25/07/16 13:38, David Vrabel wrote:
> >> On 30/06/16 16:56, Vitaly Kuznetsov wrote:
> >>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> >>> particular, when we crash on
xen_smp_intr_init() and xen_smp_intr_free() are now called from
enlighten.c and therefore not guaranteed to have CONFIG_SMP.
Instead of adding multiple ifdefs there provide stubs in smp.h
Signed-off-by: Boris Ostrovsky
---
The patch is against tip:smp/hotplug which is broken by
https://lists.x
flight 99649 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99649/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 227a1ac2d04504eee4c624f534ea3fcbb8140029
baseline version:
ovmf dc99315b8732b6e3032d013
flight 99604 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99604/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-build fail REGR. vs. 96211
build-amd64
flight 99654 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99654/
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
On Mon, 25 Jul 2016, Vitaly Kuznetsov wrote:
> Julien Grall writes:
>
> > Hello,
> >
> > On 25/07/16 14:39, Vitaly Kuznetsov wrote:
> >> Julien Grall writes:
> >>
> >>> Hi David,
> >>>
> >>> On 25/07/16 13:38, David Vrabel wrote:
> On 30/06/16 16:56, Vitaly Kuznetsov wrote:
> > It may h
Move sharing locks above altp2m to avoid locking order violation and crashing
the hypervisor during unsharing operations when altp2m is active.
Applying mem_access settings or remapping gfns in altp2m views will
automatically unshare the page if it was shared previously and for this we use
get_ent
flight 99603 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99603/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 96188
build-amd64
On Mon, Jul 25, 2016 at 9:58 AM, George Dunlap wrote:
> On Wed, Jul 20, 2016 at 7:55 PM, Tamas K Lengyel
> wrote:
>> Move sharing locks above altp2m to avoid locking order violation and crashing
>> the hypervisor during unsharing operations when altp2m is active.
>>
>> Applying mem_access setting
On 07/25/2016 11:22 AM, Wei Liu wrote:
Starting from 08cffe66 ("xsm: add a default policy to .init.data") we
can attach a xsm policy blob to hypervisor. To build that policy blob
now hypervisor build system needs to enter tools directory.
The expectation for hypervisor and tools build systems is
On Wed, Jul 20, 2016 at 7:55 PM, Tamas K Lengyel
wrote:
> Move sharing locks above altp2m to avoid locking order violation and crashing
> the hypervisor during unsharing operations when altp2m is active.
>
> Applying mem_access settings or remapping gfns in altp2m views will
> automatically unshar
On Mon, Jul 25, 2016 at 11:28 AM, George Dunlap
wrote:
> The generic domain creation logic in
> xen/common/domctl.c:default_vcpu0_location() attempts to try to do
> initial placement load-balancing by placing vcpu 0 on the least-busy
> non-primary hyperthread available. Unfortunately, the logic c
osstest service owner writes ("[xen-unstable-smoke test] 99610: regressions -
FAIL"):
> flight 99610 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/99610/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be
For sched_credit2, move the vcpu insert / remove / free functions near the
domain
insert / remove / alloc / free functions (and after cpu_pick).
For sched_rt, move rt_cpu_pick() further up.
This is pure code motion; no functional change.
Signed-off-by: George Dunlap
Reviewed-by: Meng Xu
---
Starting from 08cffe66 ("xsm: add a default policy to .init.data") we
can attach a xsm policy blob to hypervisor. To build that policy blob
now hypervisor build system needs to enter tools directory.
The expectation for hypervisor and tools build systems is different. We
don't want xen build syste
On Sun, 24 Jul 2016, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen-tip tree got a conflict in:
>
> drivers/block/xen-blkfront.c
>
> between commit:
>
> a418090aa88b ("block: do not use REQ_FLUSH for tracking flush support")
>
> from the block tree and commit:
>
The initial placement algorithm sometimes picks cpus outside of the
mask it's given, does a lot of unnecessary bitmasking, does its own
separate load calculation, and completely ignores vcpu hard and soft
affinities. Just get rid of it and rely on the schedulers to do
initial placement.
Signed-of
The generic domain creation logic in
xen/common/domctl.c:default_vcpu0_location() attempts to try to do
initial placement load-balancing by placing vcpu 0 on the least-busy
non-primary hyperthread available. Unfortunately, the logic can end
up picking a pcpu that's not in the online mask. When th
The GNU coding standards expect $(DESTDIR) to be the root of everything
installed, and for $(PREFIX) to then be added to the path. This is not how
XTF previously behaved.
XTF is not a typical package, and doesn't meet the usual semantics; it expects
to arrange all files in a single directory. Dr
On Sun, Jul 10, 2016 at 02:47:46PM +0300, Emil Condrea wrote:
> This patch adds infrastructure for xen front drivers living in qemu,
> so drivers don't need to implement common stuff on their own. It's
> mostly xenbus management stuff: some functions to access XenStore,
> setting up XenStore watch
It introduces context-switch rate-limiting. The patch enables the VM to batch
its work and prevents the system from spending most of its time in context
switches because of a VM that is waking/sleeping at high rate.
ratelimit can be disabled by setting it to 0.
Signed-off-by: Anshul Makkar
---
Andrew Cooper writes ("Re: [PATCH XTF 3/3] xtf-runner: regularise runner exit
code"):
> On 25/07/16 12:25, Ian Jackson wrote:
> > In particular, Error might mask a failure.
>
> Indeed it could. Either should cause a prompt investigation and effort
> to resolve the issues, but one must be more se
David Vrabel writes ("Re: [Xen-devel] [PATCH 3/4] tools/libxc: Avoid generating
inappropriate zero-length records"):
> On 21/07/16 18:17, Andrew Cooper wrote:
> > It was never intended for records such as these to be sent with zero
> > content.
>
> As the original author of the specification I'm
flight 99642 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99642/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 97725
Tests which di
On Mon, Jul 25, 2016 at 10:01 AM, George Dunlap
wrote:
> On Wed, Jul 20, 2016 at 7:55 PM, Tamas K Lengyel
> wrote:
>> Move sharing locks above altp2m to avoid locking order violation and crashing
>> the hypervisor during unsharing operations when altp2m is active.
>>
>> Applying mem_access settin
flight 99643 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99643/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 94748
build-i386
On Wed, Jul 20, 2016 at 7:55 PM, Tamas K Lengyel
wrote:
> Move sharing locks above altp2m to avoid locking order violation and crashing
> the hypervisor during unsharing operations when altp2m is active.
>
> Applying mem_access settings or remapping gfns in altp2m views will
> automatically unshar
On Fri, 22 Jul 2016 14:24:41 -0700
"Luis R. Rodriguez" wrote:
> +/**
> + * LINKTABLE_RUN_ALL - iterate and run through all entries on a linker table
> + *
> + * @tbl: linker table
> + * @func: structure name for the function name we want to call.
> + * @args...: arguments to pass to func
> + *
>
On Fri, 22 Jul 2016 14:24:47 -0700
"Luis R. Rodriguez" wrote:
> kprobe makes use of two sections, the one dealing with the actual
> kprobes was recently ported using the standard section range API.
> The blacklist functionality of kprobes is still using a custom
> section and declaring its custom
On Fri, 22 Jul 2016 14:24:46 -0700
"Luis R. Rodriguez" wrote:
> kprobe makes use of two custom sections, each custom section
> is folded into one of the standard Linux sections types as follows,
> it currently relies on the linker script to fold the custom section
> onto the respective Linux sect
flight 99630 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99630/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 94748
build-i386
On 22/07/16 11:36, Dario Faggioli wrote:
On Mon, 2016-07-18 at 13:22 +0100, Anshul Makkar wrote:
Hey, Anshul.
Thanks, and sorry for the delay in reviewing.
This version is an improvement, but it looks to me that you've missed a
few of the review comments to v1.
Sorry about that. !!
It intr
On Mon, Jul 25, 2016 at 7:17 AM, George Dunlap wrote:
> On 18/07/16 11:28, Dario Faggioli wrote:
>> On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote:
>>> The generic domain creation logic in
>>> xen/common/domctl.c:default_vcpu0_location() attempts to try to do
>>> initial placement load-bal
flight 99610 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 97725
Tests which di
On Fri, Jul 15, 2016 at 2:02 PM, George Dunlap wrote:
>
> The generic domain creation logic in
> xen/common/domctl.c:default_vcpu0_location() attempts to try to do
> initial placement load-balancing by placing vcpu 0 on the least-busy
> non-primary hyperthread available. Unfortunately, the logic
On Mon, Jul 25, 2016 at 04:06:11PM +0200, Juergen Gross wrote:
> On 25/07/16 16:01, Wei Liu wrote:
> > On Mon, Jul 25, 2016 at 03:56:17PM +0200, Juergen Gross wrote:
> >> On 25/07/16 15:43, Wei Liu wrote:
> >>> On Fri, Jul 22, 2016 at 05:09:31PM +0200, Juergen Gross wrote:
> >>> [...]
> diff -
On Mon, Jul 25, 2016 at 04:16:51PM +0200, Juergen Gross wrote:
> On 25/07/16 16:11, Wei Liu wrote:
> > On Mon, Jul 25, 2016 at 04:06:11PM +0200, Juergen Gross wrote:
> >> On 25/07/16 16:01, Wei Liu wrote:
> >>> On Mon, Jul 25, 2016 at 03:56:17PM +0200, Juergen Gross wrote:
> On 25/07/16 15:43,
Julien Grall writes:
> Hello,
>
> On 25/07/16 14:39, Vitaly Kuznetsov wrote:
>> Julien Grall writes:
>>
>>> Hi David,
>>>
>>> On 25/07/16 13:38, David Vrabel wrote:
On 30/06/16 16:56, Vitaly Kuznetsov wrote:
> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> parti
On 25/07/16 16:11, Wei Liu wrote:
> On Mon, Jul 25, 2016 at 04:06:11PM +0200, Juergen Gross wrote:
>> On 25/07/16 16:01, Wei Liu wrote:
>>> On Mon, Jul 25, 2016 at 03:56:17PM +0200, Juergen Gross wrote:
On 25/07/16 15:43, Wei Liu wrote:
> On Fri, Jul 22, 2016 at 05:09:31PM +0200, Juergen G
On Sun, Jul 10, 2016 at 02:47:31PM +0300, Emil Condrea wrote:
> Emil Condrea (19):
> xen: Create a new file xen_pvdev.c
> xen: Create a new file xen_frontend.c
> xen: Move xenstore_update to xen_pvdev.c
> xen: Move evtchn functions to xen_pvdev.c
> xen: Prepare xendev qtail to be shared w
On 25/07/16 15:01, Julien Grall wrote:
> Hello,
>
> On 25/07/16 14:39, Vitaly Kuznetsov wrote:
>> Julien Grall writes:
>>
>>> Hi David,
>>>
>>> On 25/07/16 13:38, David Vrabel wrote:
On 30/06/16 16:56, Vitaly Kuznetsov wrote:
> It may happen that Xen's and Linux's ideas of vCPU id diverg
On Sun, Jul 10, 2016 at 02:47:35PM +0300, Emil Condrea wrote:
> The name of the functions moved:
> * xen_be_evtchn_event
> * xen_be_unbind_evtchn
> * xen_be_send_notify
>
> Signed-off-by: Emil Condrea
> ---
> hw/xen/xen_backend.c | 37 +
> hw/xen/xe
Series:
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 25/07/16 16:01, Wei Liu wrote:
> On Mon, Jul 25, 2016 at 03:56:17PM +0200, Juergen Gross wrote:
>> On 25/07/16 15:43, Wei Liu wrote:
>>> On Fri, Jul 22, 2016 at 05:09:31PM +0200, Juergen Gross wrote:
>>> [...]
diff --git a/tools/hotplug/Linux/launch-xenstore.in
b/tools/hotplug/Linux/l
On Mon, Jul 25, 2016 at 03:56:17PM +0200, Juergen Gross wrote:
> On 25/07/16 15:43, Wei Liu wrote:
> > On Fri, Jul 22, 2016 at 05:09:31PM +0200, Juergen Gross wrote:
> > [...]
> >> diff --git a/tools/hotplug/Linux/launch-xenstore.in
> >> b/tools/hotplug/Linux/launch-xenstore.in
> >> index 2bd9f64.
Hello,
On 25/07/16 14:39, Vitaly Kuznetsov wrote:
Julien Grall writes:
Hi David,
On 25/07/16 13:38, David Vrabel wrote:
On 30/06/16 16:56, Vitaly Kuznetsov wrote:
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to
I went back to the long thread in v1. I don't think I can figure out
if all the comments are addressed.
Ian asked for something to be rectified, but I'm not sure if this series
satisfies him. I will let him comment on that.
Wei.
___
Xen-devel mailing l
On Sun, Jul 10, 2016 at 02:47:39PM +0300, Emil Condrea wrote:
> Prepare xen_be_send_notify to be shared with frontends:
> * xen_be_send_notify -> xen_pv_send_notify
>
> Signed-off-by: Emil Condrea
> ---
> hw/block/xen_disk.c| 4 ++--
> hw/char/xen_console.c | 4 ++--
> hw/display/x
On Sun, Jul 10, 2016 at 02:47:33PM +0300, Emil Condrea wrote:
> Its purpose is to store frontend related functions.
>
> Signed-off-by: Quan Xu
> Signed-off-by: Emil Condrea
> ---
> hw/block/xen_disk.c | 1 +
> hw/display/xenfb.c| 1 +
> hw/net/xen_nic.c | 1
On 07/25/2016 09:32 AM, Masami Hiramatsu wrote:
> I'm not a lawyer, so I don't know really it is compatible with GPLv2,
> and if it is, I'm not sure the reason why we need another license.
> AFAICS the license terms, most of parts looks reasonable. I just concern
> clause 8, after fifteen years, i
On 25/07/16 14:17, Julien Grall wrote:
> Hi David,
>
> On 25/07/16 13:38, David Vrabel wrote:
>> On 30/06/16 16:56, Vitaly Kuznetsov wrote:
>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>> and unlike
On Fri, Jul 22, 2016 at 05:09:29PM +0200, Juergen Gross wrote:
> In order to prepare starting a xenstore domain split out the starting
> of the xenstore daemon from the xencommons script into a dedicated
> launch-xenstore script.
>
> Correct one error: don't remove old tdb files in background, as
On Sun, Jul 10, 2016 at 02:47:38PM +0300, Emil Condrea wrote:
> Prepare xen_be_unbind_evtchn to be shared with frontends:
> * xen_be_unbind_evtchn -> xen_pv_unbind_evtchn
>
> Signed-off-by: Emil Condrea
> ---
> hw/block/xen_disk.c| 2 +-
> hw/char/xen_console.c | 2 +-
> hw/display
On 25/07/16 15:43, Wei Liu wrote:
> On Fri, Jul 22, 2016 at 05:09:31PM +0200, Juergen Gross wrote:
> [...]
>> diff --git a/tools/hotplug/Linux/launch-xenstore.in
>> b/tools/hotplug/Linux/launch-xenstore.in
>> index 2bd9f64..fdfa33a 100644
>> --- a/tools/hotplug/Linux/launch-xenstore.in
>> +++ b/to
On Fri, Jul 22, 2016 at 05:09:31PM +0200, Juergen Gross wrote:
[...]
> diff --git a/tools/hotplug/Linux/launch-xenstore.in
> b/tools/hotplug/Linux/launch-xenstore.in
> index 2bd9f64..fdfa33a 100644
> --- a/tools/hotplug/Linux/launch-xenstore.in
> +++ b/tools/hotplug/Linux/launch-xenstore.in
> @@ -
On Sun, Jul 10, 2016 at 02:47:32PM +0300, Emil Condrea wrote:
> The purpose of the new file is to store generic functions shared by frontend
> and backends such as xenstore operations, xendevs.
>
> Signed-off-by: Quan Xu
> Signed-off-by: Emil Condrea
> ---
> hw/xen/Makefile.objs | 2 +
Julien Grall writes:
> Hi David,
>
> On 25/07/16 13:38, David Vrabel wrote:
>> On 30/06/16 16:56, Vitaly Kuznetsov wrote:
>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>> and unlike plain kexec wher
Hi Luis,
On Fri, 22 Jul 2016 14:24:34 -0700
"Luis R. Rodriguez" wrote:
> This RFC v3 builds off the last RFC v2 series [0] for adding linker tables.
> The largest amount of work here was to take Russell King's feedback on
> using linker table for kprobes text not being appropriate -- and providi
On Mon, Jul 25, 2016 at 12:33:37PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH] tools/libxc: Properly increment ApicIdCoreSize
> field on AMD"):
> > On Fri, Jul 22, 2016 at 01:45:05PM -0400, Boris Ostrovsky wrote:
> > > On 07/22/2016 01:38 PM, Wei Liu wrote:
> > > But this actually fix
On Mon, Jul 25, 2016 at 10:17:44AM +0100, Wei Liu wrote:
> On Sun, Jul 24, 2016 at 09:26:57PM +0200, Marek Marczykowski-Górecki wrote:
> > Having DefaultDependencies=no means it can be started before / is
> > remounted read-write, which will result in various failures (to start
> > with opening the
Hi David,
On 25/07/16 13:38, David Vrabel wrote:
On 30/06/16 16:56, Vitaly Kuznetsov wrote:
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try b
On Mon, Jul 25, 2016 at 01:41:41PM +0200, Ingo Jürgensmann wrote:
> On 25.07.2016 12:23, Wei Liu wrote:
>
> First, thank you for replying! Very much appreciated! :)
>
> >I did skim your emails. But the oops was happening in memcpy+0x6 which
> >indicated it came back to the origin question why wou
On 25/07/16 13:46, Andrew Cooper wrote:
> On 25/07/16 13:21, David Vrabel wrote:
>> On 21/07/16 18:17, Andrew Cooper wrote:
>>> Under some circumstances, the migration v2 save code would generate valid
>>> records with zero content, when the intended behaviour was to omit the
>>> record
>>
flight 99608 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99608/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 94748
build-i386-xsm
On 25/07/16 13:21, David Vrabel wrote:
> On 21/07/16 18:17, Andrew Cooper wrote:
>> Under some circumstances, the migration v2 save code would generate valid
>> records with zero content, when the intended behaviour was to omit the record
>
> As explai
On 30/06/16 16:56, Vitaly Kuznetsov wrote:
> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> particular, when we crash on a secondary vCPU we may want to do kdump
> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
> on the vCPU which crashed. This doesn'
Monday, July 25, 2016, 1:27:20 PM, you wrote:
> On 25.07.2016 12:51, Wei Liu wrote:
>>> [...]
>>> > Your report and the debian report suggested that Dom0 kernel is less
>>> > likely to be the culprit because you've tried different Dom0 kernels.
>>> yes we did. but nothing newer than 3.16 so far,
On 07/25/2016 08:11 PM, Roger Pau Monné wrote:
> On Mon, Jul 25, 2016 at 07:08:36PM +0800, Bob Liu wrote:
>>
>> On 07/25/2016 06:53 PM, Roger Pau Monné wrote:
>> ..[snip..]
>> * We get the device lock and blk_mq_freeze_queue() in
>> dynamic_reconfig_device(),
>>and then have to r
On 25/07/16 13:05, Wei Liu wrote:
> On Mon, Jul 25, 2016 at 06:33:35AM +0200, Juergen Gross wrote:
>> On 22/07/16 20:51, Wei Liu wrote:
>>> On Fri, Jul 22, 2016 at 08:49:17PM +0200, Juergen Gross wrote:
On 22/07/16 18:31, Wei Liu wrote:
> Only skim-read this patch, will do proper review la
On 21/07/16 18:17, Andrew Cooper wrote:
> Under some circumstances, the migration v2 save code would generate valid
> records with zero content, when the intended behaviour was to omit the record
As explained, this is not the intended behaviour. I wou
On Mon, Jul 25, 2016 at 07:08:36PM +0800, Bob Liu wrote:
>
> On 07/25/2016 06:53 PM, Roger Pau Monné wrote:
> ..[snip..]
> * We get the device lock and blk_mq_freeze_queue() in
> dynamic_reconfig_device(),
> and then have to release in blkif_recover() asynchronously which
> >>
On 25/07/16 12:25, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH XTF 3/3] xtf-runner: regularise runner exit
> code"):
>> On 22/07/16 10:29, Wei Liu wrote:
>>> This would cause a FAILURE to overwrite previous ERROR result. Is that
>>> what you want?
>> When running more than one test, the
On Mon, Jul 25, 2016 at 12:34:53PM +0100, Julien Grall wrote:
>
>
> On 25/07/16 12:11, Wei Liu wrote:
> >Thanks for investigating.
> >
> >There are only two arm related changes in the range being tested:
> >
> >* a43cc8f - (origin/smoke) arm/traps: fix bug in dump_guest_s1_walk handling
> >of le
David Vrabel writes ("Re: [Xen-devel] [PATCH 3/4] tools/libxc: Avoid generating
inappropriate zero-length records"):
> For records such as HVM_PARAMS which consist of a set of N items, the
> intention was to most definitely send a record with 0 items.
>
> For records that fetch an opaque blob fro
On 25.07.2016 12:23, Wei Liu wrote:
First, thank you for replying! Very much appreciated! :)
I did skim your emails. But the oops was happening in memcpy+0x6 which
indicated it came back to the origin question why would it got an
exception there.
Just by staring at the code doesn't get me anyw
On Mon, Jul 25, 2016 at 01:26:29PM +0200, Sergej Proskurin wrote:
>
> On 07/25/2016 12:08 PM, Wei Liu wrote:
> > On Mon, Jul 25, 2016 at 10:49:41AM +0100, Julien Grall wrote:
> >> Hello,
> >>
> >> On 25/07/16 10:04, Sergej Proskurin wrote:
> >>> On 07/25/2016 10:32 AM, Wei Liu wrote:
> On Sun
On 25/07/16 12:11, Wei Liu wrote:
Thanks for investigating.
There are only two arm related changes in the range being tested:
* a43cc8f - (origin/smoke) arm/traps: fix bug in dump_guest_s1_walk handling of level
2 page tables (5 days ago)
* 60e06f2 - arm/traps: fix bug in dump_guest_s1_walk
Wei Liu writes ("Re: [PATCH] tools/libxc: Properly increment ApicIdCoreSize
field on AMD"):
> On Fri, Jul 22, 2016 at 01:45:05PM -0400, Boris Ostrovsky wrote:
> > On 07/22/2016 01:38 PM, Wei Liu wrote:
> > But this actually fixes a regression that was triggered by recent
> > hvmloader change on on
On 25.07.2016 12:51, Wei Liu wrote:
[...]
> Your report and the debian report suggested that Dom0 kernel is less
> likely to be the culprit because you've tried different Dom0 kernels.
yes we did. but nothing newer than 3.16 so far, we could try that,
too.
There is a 4.5 backport kernel for Je
1 - 100 of 164 matches
Mail list logo
