On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez"
Some folks had reported that some xen hypercalls take a long time
to complete when issued from the userspace private ioctl mechanism,
this can happen for instance with some hypercalls that have many
sub-operations, this
On 11/27/2014 01:19 AM, Daniel Kiper wrote:
On Wed, Nov 26, 2014 at 03:49:54PM +0100, Juergen Gross wrote:
On 11/26/2014 03:30 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
On 11/26/2014 01:41 PM, Andrew Cooper wrote:
On 26/11/14 12:15, Juerge
On 11/25/2014 03:00 AM, Jan Beulich wrote:
Okay, so it's not really the mwait-idle driver causing the regression,
but it is C-state related. Hence we're now down to seeing whether all
or just the deeper C states are affected, i.e. I now need to ask you
to play with "max_cstate=". For that you'll
On 11/26/2014 06:53 PM, Stefano Stabellini wrote:
On Wed, 26 Nov 2014, Jason Wang wrote:
>On 11/25/2014 09:53 PM, Stefano Stabellini wrote:
> >On Tue, 25 Nov 2014, Jason Wang wrote:
> >>On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
> >>>On Mon, 24 Nov 2014, Stefano Stabellini wrote:
>
On Wed, Nov 26, 2014 at 12:28:12PM -0500, David Miller wrote:
> From: Seth Forshee
> Date: Tue, 25 Nov 2014 20:28:24 -0600
>
> > These BUGs can be erroneously triggered by frags which refer to
> > tail pages within a compound page. The data in these pages may
> > overrun the hardware page while s
flight 31862 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31862/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl 11 guest-saverestore fail baseline untested
test-amd64-i386-xl-credit23
On 11/26/14 13:17, Stefano Stabellini wrote:
On Tue, 25 Nov 2014, Andrew Cooper wrote:
On 25/11/14 17:45, Stefano Stabellini wrote:
Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
the risk of running out of guest memory. This way we can also avoid
complex memory calcul
flight 31861 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31861/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail REGR. vs.
31853
test-amd64-amd
On Wed, Nov 26, 2014 at 03:49:54PM +0100, Juergen Gross wrote:
> On 11/26/2014 03:30 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
> >>On 11/26/2014 01:41 PM, Andrew Cooper wrote:
> >>>On 26/11/14 12:15, Juergen Gross wrote:
> Hi,
>
> >>
From: "Luis R. Rodriguez"
Some folks had reported that some xen hypercalls take a long time
to complete when issued from the userspace private ioctl mechanism,
this can happen for instance with some hypercalls that have many
sub-operations, this can happen for instance on hypercalls that use
mult
On 26/11/2014 19:54, M A Young wrote:
> If differences are found during the verification phase of xl migrate
> --debug then it is likely to crash with a segfault because the bogus
> pagebuf->pfn_types[pfn] is used in a print statement instead of
> pfn_type[pfn] .
>
> Signed-off-by: Michael Young
>
On 26/11/2014 20:51, M A Young wrote:
> Migrations with xl migrate --debug will fail because debugging
> information from the receiving process is written to the stdout
> channel. This channel is also used for status messages so the
> migration will fail as the sending process receives an unexpecte
On Wed, Nov 26, 2014 at 08:44:41PM +, Dave Scott wrote:
>
> > On 26 Nov 2014, at 18:41, Konrad Rzeszutek Wilk
> > wrote:
> >
> > On Wed, Nov 26, 2014 at 06:24:11PM +, Dave Scott wrote:
> >>
> >>> On 26 Nov 2014, at 15:38, Zheng Li wrote:
> >>>
> >>> On 26/11/2014 15:09, Andrew Cooper
Migrations with xl migrate --debug will fail because debugging information
from the receiving process is written to the stdout channel. This channel
is also used for status messages so the migration will fail as the sending
process receives an unexpected message. This patch moves the debugging
> On 26 Nov 2014, at 18:41, Konrad Rzeszutek Wilk
> wrote:
>
> On Wed, Nov 26, 2014 at 06:24:11PM +, Dave Scott wrote:
>>
>>> On 26 Nov 2014, at 15:38, Zheng Li wrote:
>>>
>>> On 26/11/2014 15:09, Andrew Cooper wrote:
This makes fields 0 and 1 true more often than they should be, re
flight 31858 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31858/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 8 guest-start fail REGR. vs. 31241
test-amd64-amd64-rump
On 11/25/14 07:43, Stefano Stabellini wrote:
Account for the extra memory needed for the rom files of any emulated nics:
QEMU uses xc_domain_populate_physmap_exact to allocate the memory for
each them. Assume 256K each.
I have seen that this is no longer planned for 4.5, but I do think that
li
On 26/11/2014 19:03, Andrew Cooper wrote:
Strictly speaking Zheng, not being a maintainer, can't ack the patch,
given what I believe to be Xens current rules for these things.
However, as the author of the code and comment in this thread, his ack
can reasonably be considered equivalent to a Revi
On 11/26/14 09:40, Konrad Rzeszutek Wilk wrote:
On Wed, Nov 26, 2014 at 01:04:00PM +, Ian Campbell wrote:
On Wed, 2014-11-26 at 12:39 +, Stefano Stabellini wrote:
On Wed, 26 Nov 2014, Ian Campbell wrote:
On Tue, 2014-11-25 at 17:05 +, Stefano Stabellini wrote:
On Tue, 25 Nov 2014,
Hi,
While testing a patch for Konrad i was wondering why "libxl_pci.c:
libxl__device_pci_reset()"
doesn't get called on guest shutdown of a HVM guest (qemu-xen) with pci
passthrough.
xl didn't show any problems on the commandline so i never drawed much attention
to it, but /var/log/xen/xl-guest
If differences are found during the verification phase of xl migrate
--debug then it is likely to crash with a segfault because the bogus
pagebuf->pfn_types[pfn] is used in a print statement instead of
pfn_type[pfn] .
Signed-off-by: Michael Young xl migrate --debug can segfault because pagebuf-
flight 31860 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31860/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-amd64-amd64-libvirt 9 guest-start
On 26/11/14 18:41, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 26, 2014 at 06:24:11PM +, Dave Scott wrote:
>>> On 26 Nov 2014, at 15:38, Zheng Li wrote:
>>>
>>> On 26/11/2014 15:09, Andrew Cooper wrote:
This makes fields 0 and 1 true more often than they should be, resulting
problems
On Wed, Nov 26, 2014 at 06:24:11PM +, Dave Scott wrote:
>
> > On 26 Nov 2014, at 15:38, Zheng Li wrote:
> >
> > On 26/11/2014 15:09, Andrew Cooper wrote:
> >> This makes fields 0 and 1 true more often than they should be, resulting
> >> problems when handling events.
> >
> > Indeed, looks l
> On 26 Nov 2014, at 15:38, Zheng Li wrote:
>
> On 26/11/2014 15:09, Andrew Cooper wrote:
>> This makes fields 0 and 1 true more often than they should be, resulting
>> problems when handling events.
>
> Indeed, looks like a mistake I made when rewriting the logic terms lately.
> The result is
On Tue, 25 Nov 2014, Andrew Cooper wrote:
> On 25/11/14 17:45, Stefano Stabellini wrote:
> > Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
> > the risk of running out of guest memory. This way we can also avoid
> > complex memory calculations in libxl at domain constructi
On Wed, Nov 26, 2014 at 06:32:21PM +0100, Roger Pau Monné wrote:
> El 26/11/14 a les 17.55, Wei Liu ha escrit:
> > Modify libxl and hotplug script to allow raw format file to use phy
> > backend.
> >
> > The block script now tests the path and determine the actual type of
> > file (block device or
On 26/11/14 16:53, Jan Beulich wrote:
Andrew Cooper 11/25/14 7:14 PM >>>
>> On 25/11/14 17:25, Jan Beulich wrote:
>> On 25.11.14 at 17:54, wrote:
This is RFC as there is still a niggle. I tested this via a partial
revert of
the XSA-110 fix but the result is quite chatty
On 26/11/14 16:50, Ian Campbell wrote:
> On Tue, 2014-11-25 at 19:54 +, Andrew Cooper wrote:
>> 3) Libxl and xl support
>>
>> Libxl and xl have as many problems as the libxc code did when it comes
>> to incompatible wire formats and layering violations. In particular, it
>> is not possible to
Ian Campbell writes ("Re: [Xen-devel] segv in osevent_release_nexus with libxl
backend to libvirt"):
> I don't know if this helps but on the 3 occasions I've just looked at
> the ev passed to libxl__ev_fd_deregister contains an fd which
> corresponds to a still open handle on /dev/xen/evtchn.
I s
El 26/11/14 a les 17.55, Wei Liu ha escrit:
> Modify libxl and hotplug script to allow raw format file to use phy
> backend.
>
> The block script now tests the path and determine the actual type of
> file (block device or regular file) then use the actual type to
> determine which branch to run.
>
From: Seth Forshee
Date: Tue, 25 Nov 2014 20:28:24 -0600
> These BUGs can be erroneously triggered by frags which refer to
> tail pages within a compound page. The data in these pages may
> overrun the hardware page while still being contained within the
> compound page, but since compound_order(
On 26/11/14 16:44, Ian Campbell wrote:
> On Tue, 2014-11-25 at 19:54 +, Andrew Cooper wrote:
>> There is an xl/libxl part of the migration v2 series which attempts to
>> rectify this all in one go, as there is no alternative way of doing so.
>> The libxl section of the series is certainly not
On Nov 26, 2014 11:39 AM, "Luis R. Rodriguez" wrote:
>
> On Wed, Aug 20, 2014 at 1:26 PM, Ian Campbell
> wrote:
> > On Wed, 2014-08-20 at 13:20 -0400, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Aug 20, 2014 at 06:18:52PM +0100, Ian Campbell wrote:
> >> > On Wed, 2014-08-20 at 12:40 -0400, Kon
Modify libxl and hotplug script to allow raw format file to use phy
backend.
The block script now tests the path and determine the actual type of
file (block device or regular file) then use the actual type to
determine which branch to run.
With these changes, plus the current ordering of backend
>>> Andrew Cooper 11/25/14 7:14 PM >>>
>On 25/11/14 17:25, Jan Beulich wrote:
> On 25.11.14 at 17:54, wrote:
>>> This is RFC as there is still a niggle. I tested this via a partial revert
>>> of
>>> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
>>> domain crash
On Tue, 2014-11-25 at 19:54 +, Andrew Cooper wrote:
> 3) Libxl and xl support
>
> Libxl and xl have as many problems as the libxc code did when it comes
> to incompatible wire formats and layering violations. In particular, it
> is not possible to determine the bitness of the sending
> libxl-
On Tue, 2014-11-25 at 19:54 +, Andrew Cooper wrote:
> There is an xl/libxl part of the migration v2 series which attempts to
> rectify this all in one go, as there is no alternative way of doing so.
> The libxl section of the series is certainly not yet complete, but
> specific queries to the
On Wed, Aug 20, 2014 at 1:26 PM, Ian Campbell wrote:
> On Wed, 2014-08-20 at 13:20 -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, Aug 20, 2014 at 06:18:52PM +0100, Ian Campbell wrote:
>> > On Wed, 2014-08-20 at 12:40 -0400, Konrad Rzeszutek Wilk wrote:
>> > > The rest of the Xen device drivers use
On Wed, 2014-11-26 at 15:40 +, Ian Campbell wrote:
> (adding xen-devel which I forgot first time around)
>
> On Wed, 2014-11-26 at 15:21 +, Ian Jackson wrote:
> > Ian Campbell writes ("segv in osevent_release_nexus with libxl backend to
> > libvirt"):
> > > I'm seeing quite a few of these
(adding xen-devel which I forgot first time around)
On Wed, 2014-11-26 at 15:21 +, Ian Jackson wrote:
> Ian Campbell writes ("segv in osevent_release_nexus with libxl backend to
> libvirt"):
> > I'm seeing quite a few of these when shutting down domains:
> ...
> > This is on ARM but I don't t
flight 31857 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31857/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 7 xen-boot/src_host fail REGR. vs. 31849
Regressions which are reg
On 26/11/2014 15:09, Andrew Cooper wrote:
This makes fields 0 and 1 true more often than they should be, resulting
problems when handling events.
Indeed, looks like a mistake I made when rewriting the logic terms lately. The
result is POLLUP or POLLERR events being returned in more categories
Hi,
I'm seeing quite a few of these when shutting down domains:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb47f9420 (LWP 3322)]
0xb16d2f20 in osevent_release_nexus (gc=0xb47f88bc,
nexi_idle=0x2a0968fc, nexus=0x0) at libxl_event.c:119
This makes fields 0 and 1 true more often than they should be, resulting
problems when handling events.
Signed-off-by: Andrew Cooper
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
CC: Dave Scott
CC: Zheng Li
CC: Konrad Rzeszutek Wilk
---
This was discovered with XenServers internal Coverity
On Wed, Nov 26, Andrew Cooper wrote:
> It is certainly my hope going forward that different knobs can be
> exposed. One thing I think would be interesting is some proper
> calculations of the delta in the dirty set, and offering a threshold
> which chooses between "pause and complete" or "abort t
On 11/26/2014 03:30 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
On 11/26/2014 01:41 PM, Andrew Cooper wrote:
On 26/11/14 12:15, Juergen Gross wrote:
Hi,
I tried to enable kdump on my test-machine with actual xen-unstable
booting via EFI.
Th
On Wed, Nov 26, 2014 at 01:04:00PM +, Ian Campbell wrote:
> On Wed, 2014-11-26 at 12:39 +, Stefano Stabellini wrote:
> > On Wed, 26 Nov 2014, Ian Campbell wrote:
> > > On Tue, 2014-11-25 at 17:05 +, Stefano Stabellini wrote:
> > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > On
On 11/25/2014 09:28 AM, Jan Beulich wrote:
+else
+{
+struct segment_register seg;
+
+hvm_get_segment_register(sampled, x86_seg_cs, &seg);
+r->cs = seg.sel;
+hvm_get_segment_register(sampled, x86_seg_ss, &se
On 11/25/2014 08:49 AM, Jan Beulich wrote:
On 17.11.14 at 00:07, wrote:
@@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
switch ( vendor )
{
case X86_VENDOR_AMD:
-if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-opt_vpmu_enabled = 0;
+
On Wed, Nov 26, 2014 at 03:01:51PM +0100, Juergen Gross wrote:
> On 11/26/2014 01:41 PM, Andrew Cooper wrote:
> >On 26/11/14 12:15, Juergen Gross wrote:
> >>Hi,
> >>
> >>I tried to enable kdump on my test-machine with actual xen-unstable
> >>booting via EFI.
> >>
> >>The kdump kernel is not being l
On 11/25/2014 08:36 AM, Jan Beulich wrote:
+static long vpmu_sched_checkin(void *arg)
+{
+int cpu = cpumask_next(smp_processor_id(), &cpu_online_map);
unsigned int.
+int ret;
+
+/* Mode change shouldn't take more than a few (say, 5) seconds. */
+if ( NOW() > vpmu_start_ctxt_
On 26/11/14 14:01, Juergen Gross wrote:
> On 11/26/2014 01:41 PM, Andrew Cooper wrote:
>> On 26/11/14 12:15, Juergen Gross wrote:
>>> Hi,
>>>
>>> I tried to enable kdump on my test-machine with actual xen-unstable
>>> booting via EFI.
>>>
>>> The kdump kernel is not being loaded.
>>>
>>> I'm seeing
On 11/26/2014 01:41 PM, Andrew Cooper wrote:
On 26/11/14 12:15, Juergen Gross wrote:
Hi,
I tried to enable kdump on my test-machine with actual xen-unstable
booting via EFI.
The kdump kernel is not being loaded.
I'm seeing the memory being reserved:
(XEN) EFI RAM map:
(XEN)
On 26/11/14 08:09, Olaf Hering wrote:
> On Tue, Nov 25, Andrew Cooper wrote:
>
>> The purpose of this email is to plan how to progress the migrationv2
>> series through to being merged. I believe I have CC'd everyone with a
>> specific interest in this area, but apologies if I have missed anyone.
On Wed, 2014-11-26 at 12:39 +, Stefano Stabellini wrote:
> On Wed, 26 Nov 2014, Ian Campbell wrote:
> > On Tue, 2014-11-25 at 17:05 +, Stefano Stabellini wrote:
> > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > On Tue, 2014-11-25 at 16:49 +, Stefano Stabellini wrote:
> > > > > On T
On Wed, 26 Nov 2014, Ian Campbell wrote:
> On Tue, 2014-11-25 at 17:05 +, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > On Tue, 2014-11-25 at 16:49 +, Stefano Stabellini wrote:
> > > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > > On Tue, 2014-11-25 at 12
On Tue, 2014-11-25 at 11:15 +, Wei Liu wrote:
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> since the destination bitmap is created for maximum number of CPUs.
FYI I'm also seeing this with libvirt (on ARM, but I don't think that
matters) when the guest XML
On 26/11/14 12:15, Juergen Gross wrote:
> Hi,
>
> I tried to enable kdump on my test-machine with actual xen-unstable
> booting via EFI.
>
> The kdump kernel is not being loaded.
>
> I'm seeing the memory being reserved:
>
> (XEN) EFI RAM map:
> (XEN) - 000a (usable)
>
Hi,
I tried to enable kdump on my test-machine with actual xen-unstable
booting via EFI.
The kdump kernel is not being loaded.
I'm seeing the memory being reserved:
(XEN) EFI RAM map:
(XEN) - 000a (usable)
(XEN) 0010 - 4bc0 (usable)
(XEN)
No, this happens before guests are started.
On November 26, 2014 4:45:22 AM EST, Ian Campbell
wrote:
>On Tue, 2014-11-25 at 15:23 -0500, Boris Ostrovsky wrote:
>> We have a regression due to (5195c14c8: netfilter: conntrack: fix
>race
>> in __nf_conntrack_confirm against get_next_corpse). I h
Olaf Hering writes ("[PATCH v2] xen: use more fixed strings to build the
hypervisor"):
> It should be possible to repeatedly build identical sources and get
> identical binaries, even on different hosts at different build times.
> This fails for xen.gz and xen.efi because current time and buildhos
flight 31856 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31856/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303
Tests which are failin
On Wed, 26 Nov 2014, Jason Wang wrote:
> On 11/25/2014 09:53 PM, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Jason Wang wrote:
> >> On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
> >>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> >
On 26/11/14 07:21, hanyandong wrote:
> hi all,
> I found xentrace will lost record if there are too many event to trace.
> But every event is important to me, so I want to trace all of them,
> not lost one.
> what could I do to achieve this goal ?
>
> If it need to modify the source code of xentr
flight 31855 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31855/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 31801
Tests which did not succeed,
On Tue, 2014-11-25 at 15:23 -0500, Boris Ostrovsky wrote:
> We have a regression due to (5195c14c8: netfilter: conntrack: fix race
> in __nf_conntrack_confirm against get_next_corpse). I have not been able
> to reproduce this on baremetal but dom0 crashes reliably after a few
> seconds of idle t
On 11/26/2014 07:21 AM, Linus Torvalds wrote:
On Tue, Nov 25, 2014 at 9:52 PM, Linus Torvalds
wrote:
And leave it running for a while, and see if the trace is always the
same, or if there are variations on it...
Amusing.
Lookie here:
http://lists.xenproject.org/archives/html/xen-chang
On Tue, 2014-11-25 at 17:05 +, Stefano Stabellini wrote:
> On Tue, 25 Nov 2014, Ian Campbell wrote:
> > On Tue, 2014-11-25 at 16:49 +, Stefano Stabellini wrote:
> > > On Tue, 25 Nov 2014, Ian Campbell wrote:
> > > > On Tue, 2014-11-25 at 12:43 +, Stefano Stabellini wrote:
> > > > > Acco
On Fri, 2014-11-14 at 09:42 +, Ian Campbell wrote:
> I've not seen an individual thread on this one, so replying here.
>
> On Wed, 2014-11-12 at 10:59 +0100, Fabio Fantoni wrote:
>
> > > 6. Networking is unavailable after save&restore Windows guest
> > >http://bugzilla-archived.xenproject
On Tue, Nov 25, Andrew Cooper wrote:
> The purpose of this email is to plan how to progress the migrationv2
> series through to being merged. I believe I have CC'd everyone with a
> specific interest in this area, but apologies if I have missed anyone.
While you mow that lawn, did you guys think
71 matches
Mail list logo
