>>> On 24.11.14 at 23:17, wrote:
> I'm combining this action with your patch, see below. Please let me know
> if this was incorrect.
Thanks, that's perfectly fine.
> (XEN) 'c' pressed -> printing ACPI Cx structures
> (XEN) ==cpu0==
> (XEN) active state:C0
> (XEN) max_cstate:C7
>
>>> On 25.11.14 at 02:47, wrote:
> Tim Deegan wrote on 2014-11-19:
>> At 01:29 + on 19 Nov (1416356943), Zhang, Yang Z wrote:
>>> Tim Deegan wrote on 2014-11-18:
In this case, the guest is entitled to _expect_ pagefaults on 1GB
mappings if CPUID claims they are not supported. That s
>>> On 24.11.14 at 20:49, wrote:
> Currently when VPMU is enabled on a system both HVM and PVH VPCUs will
> initialize their VPMUs, including setting up vpmu_ops. As result even
> though VPMU will not work for PVH guests (APIC is not supported there),
> the guest may decide to perform a write to a
On Mon, 24 Nov 2014, Wei Liu wrote:
On Mon, Nov 24, 2014 at 01:13:25PM +, Andrew Cooper wrote:
On 24/11/14 11:50, George Dunlap wrote:
On Mon, Nov 24, 2014 at 12:07 AM, M A Young wrote:
On Sat, 22 Nov 2014, M A Young wrote:
While investigating a bug reported on Red Hat Bugzilla
https
>>> On 25.11.14 at 08:44, wrote:
> Hi,
>
> make clean in xen-unstable is failing:
>
> make[2]: Entering directory '/home/gross/xen/tools'
> set -e; if test -d qemu-xen-traditional-dir/.; then \
> make -C qemu-xen-traditional-dir clean; \
> fi
> make[3]: Entering directory
> '/home/gros
Hi, Ian,
According to previous discussion, snapshot delete and revert are
inclined to be done by high level application itself, won't supply a
libxl API. I'm wondering snapshot create need a new common API?
In fact its main work is save domain and take disk snapshot, xl can
do it too.
I just wri
On Tue, Nov 25, 2014 at 08:52:00AM +, M A Young wrote:
[...]
> >
> >And the said patch has been applied (3460eeb3fc2) so we're fine.
>
> However that doesn't fix my crash. I tried with it applied and still saw the
> crash. I also tried 4.5-rc1 (without XSM to avoid my other issue) and that
> c
On 11/25/2014 10:01 AM, Jan Beulich wrote:
On 25.11.14 at 08:44, wrote:
Hi,
make clean in xen-unstable is failing:
make[2]: Entering directory '/home/gross/xen/tools'
set -e; if test -d qemu-xen-traditional-dir/.; then \
make -C qemu-xen-traditional-dir clean; \
fi
make[3]: Entering
On 11/25/2014 12:16 AM, Jan Beulich wrote:
(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:C0
(XEN) max_cstate:C7
(XEN) states:
(XEN) C1:type[C1] latency[001] usage[5664] method[ FFH]
duration[4042540627]
(XEN) C2:type[C3] l
flight 31838 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31838/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-rumpuserxen-amd64 5 xen-boot fail pass in 31784
test-amd64-i386-xl-qemuu-ovmf-amd64
On Mon, 2014-11-24 at 10:48 -0500, Boris Ostrovsky wrote:
> On 11/24/2014 05:47 AM, Wei Liu wrote:
> >>
> >> The partial copy function should explicitly zero-out all remaining bits.
>
> I actually thought that partial copy function should do just that ---
> copy bits that it has and leave others
On Tue, Nov 25, 2014 at 10:42:58AM +0100, Dario Faggioli wrote:
> On Mon, 2014-11-24 at 10:48 -0500, Boris Ostrovsky wrote:
> > On 11/24/2014 05:47 AM, Wei Liu wrote:
>
> > >>
> > >> The partial copy function should explicitly zero-out all remaining bits.
> >
> > I actually thought that partial c
On Mon, 2014-11-24 at 09:21 -0700, Eric Blake wrote:
> On 11/24/2014 02:43 AM, Ian Campbell wrote:
>
>
> I think this change breaks build on FreeBSD:
>
> CC util/libvirt_util_la-virdbus.lo
> util/virdbus.c:956:13: error: cast from 'bool *' to 'dbus_bool_t *' (aka
On Mon, Nov 24, 2014 at 10:05 PM, Daniel De Graaf wrote:
>> I do. The error is
>> (XEN) flask_domctl: Unknown op 72
>>
>> Incidentally, Flask is running in permissive mode.
>>
>> Michael Young
>>
>
> This means that the new domctl needs to be added to the switch statement
> in flask/hooks.c.
This is going to be dropped in v2, please ignore this one.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
This patch can be ignored because it's going to be dropped in v2.
Wei
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
As a result, injecting a fault and retrying the the vmentry is likely to fail
in the same way.
While crashing a guest because userspace tickled a hypervisor bug to get up
invalid VMCS state is bad (and usually warrants a
On Mon, Nov 24, 2014 at 10:48:19AM -0500, Boris Ostrovsky wrote:
> On 11/24/2014 05:47 AM, Wei Liu wrote:
> >CC'ing Dario...
> >
> >On Mon, Nov 24, 2014 at 10:41:27AM +, Wei Liu wrote:
> >>On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
> >>>When parsing bitmap objects JSON par
>>> On 25.11.14 at 11:08, wrote:
> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
> As a result, injecting a fault and retrying the the vmentry is likely to
> fail
> in the same way.
That's not all that unlikely - remember that the change was prompted
by the XSA-11
At 10:08 + on 25 Nov (1416906538), Andrew Cooper wrote:
> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
> As a result, injecting a fault and retrying the the vmentry is likely to fail
> in the same way.
In particular, the guest's privilege level won't change unt
On 25/11/14 10:42, Jan Beulich wrote:
On 25.11.14 at 11:08, wrote:
>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
>> As a result, injecting a fault and retrying the the vmentry is likely to
>> fail
>> in the same way.
> That's not all that unlikely - remembe
>>> On 25.11.14 at 10:38, wrote:
> On 11/25/2014 12:16 AM, Jan Beulich wrote:
>> Interesting, so other than for me (perhaps due to other patches
>> I have in my tree) the change resulted in C states now being used
>> again despite mwait-idle=0, which is good. Question now is - with
>> this being t
>>> On 25.11.14 at 11:46, wrote:
> On 25/11/14 10:42, Jan Beulich wrote:
> On 25.11.14 at 11:08, wrote:
>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS
> state.
>>> As a result, injecting a fault and retrying the the vmentry is likely to
>>> fail
>>> in the same w
On 25/11/14 10:46, Andrew Cooper wrote:
> On 25/11/14 10:42, Jan Beulich wrote:
> On 25.11.14 at 11:08, wrote:
>>> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS
>>> state.
>>> As a result, injecting a fault and retrying the the vmentry is likely to
>>> fail
>>> in th
And here it is.
Boris, can you give it a shot?
---8<---
>From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
From: Wei Liu
Date: Tue, 25 Nov 2014 10:59:47 +
Subject: [PATCH] libxl: allow copying between bitmaps of different sizes
When parsing bitmap objects JSON parser wi
>>> On 25.11.14 at 11:58, wrote:
> On 25/11/14 10:46, Andrew Cooper wrote:
>> On 25/11/14 10:42, Jan Beulich wrote:
>> On 25.11.14 at 11:08, wrote:
A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS
> state.
As a result, injecting a fault and retrying the the vm
On Tue, 2014-11-25 at 11:15 +, Wei Liu wrote:
> And here it is.
>
> Boris, can you give it a shot?
>
> ---8<---
> From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
> From: Wei Liu
> Date: Tue, 25 Nov 2014 10:59:47 +
> Subject: [PATCH] libxl: allow copying between bit
On 25/11/14 11:31, Jan Beulich wrote:
On 25.11.14 at 11:58, wrote:
>> On 25/11/14 10:46, Andrew Cooper wrote:
>>> On 25/11/14 10:42, Jan Beulich wrote:
>>> On 25.11.14 at 11:08, wrote:
> A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS
>> state.
> As a resu
On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
> When hardware supports APIC/x2APIC virtualization we don't need to use pirqs
> for MSI handling and instead use APIC since most APIC accesses (MMIO or MSR)
> will now be processed without VMEXITs.
>
> As an example, netperf on the original code produce
On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
> If the hardware supports APIC virtualization we may decide not to use pirqs
> and instead use APIC/x2APIC directly, meaning that we don't want to set
> x86_msi.setup_msi_irqs and x86_msi.teardown_msi_irq to Xen-specific routines.
> However, x2APIC is no
>>> On 25.11.14 at 13:10, wrote:
> On 25/11/14 11:31, Jan Beulich wrote:
> On 25.11.14 at 11:58, wrote:
>>> On 25/11/14 10:46, Andrew Cooper wrote:
On 25/11/14 10:42, Jan Beulich wrote:
On 25.11.14 at 11:08, wrote:
>> A failed vmentry is overwhelmingly likely to be caused b
On Mon, 24 Nov 2014, Don Slutz wrote:
> On 11/24/14 12:07, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Don Slutz wrote:
> > > On 11/24/14 10:26, Stefano Stabellini wrote:
> > > > On Mon, 24 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > On Mon, Nov 24, 2014 at 12:17:12PM +, Stefano Sta
No-one (including me) paid attention during review that these
structures don't adhere to the naming requirements of the public
interface: Consistently use xen_ prefixes at least for all new
additions.
Signed-off-by: Jan Beulich
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctr
>>> On 17.11.14 at 00:07, wrote:
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -103,6 +103,10 @@
> !vcpu_set_singleshot_timer vcpu.h
> ?xenoprof_init xenoprof.h
> ?xenoprof_passivexenoprof.h
> +?pmu_intel_ctxt
On 25/11/14 12:36, Jan Beulich wrote:
> No-one (including me) paid attention during review that these
> structures don't adhere to the naming requirements of the public
> interface: Consistently use xen_ prefixes at least for all new
> additions.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew
On Tue, 2014-11-25 at 12:36 +, Jan Beulich wrote:
> No-one (including me) paid attention during review that these
> structures don't adhere to the naming requirements of the public
> interface: Consistently use xen_ prefixes at least for all new
> additions.
>
> Signed-off-by: Jan Beulich
Ac
flight 31841 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31841/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken REGR. vs. 31801
test-amd64-i386-pai
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.
This patch fixes a QEMU abort() when more than 4 emulated nics are
assigned to a VM.
Signed-off-by: Stefano Stabellini
CC
>>> On 17.11.14 at 00:07, wrote:
> @@ -278,3 +290,139 @@ void vpmu_dump(struct vcpu *v)
> vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
> }
>
> +static s_time_t vpmu_start_ctxt_switch;
Blank line here please.
> +static long vpmu_sched_checkin(void *arg)
> +{
> +int cpu = cpumask_next(s
>>> 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;
> +if ( svm_vpmu_initialise(v) !=
> -Original Message-
> From: xen-devel-boun...@lists.xen.org
> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Eric Blake
> Sent: Tuesday, November 25, 2014 1:31 AM
> To: Xu, Quan; qemu-de...@nongnu.org
> Cc: xen-devel@lists.xen.org; arm...@redhat.com; lcapitul...@redhat.com
> Subje
> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Tuesday, November 25, 2014 1:19 AM
> To: Xu, Quan; qemu-de...@nongnu.org
> Cc: xen-devel@lists.xen.org; lcapitul...@redhat.com; arm...@redhat.com
> Subject: Re: [v2 1/4] Qemu-Xen-vTPM: Support for Xen stubdom vTPM
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:
> >>> CC'ing Paolo.
> >>>
> >>>
> >>> Wen,
> >>> thanks for the logs.
> >>>
> >>> I investigated a little
>>> On 17.11.14 at 00:07, wrote:
> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> @@ -362,24 +362,34 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
> struct xen_pmu_intel_ctxt *core2_vpmu_cxt = NULL;
> uint64_t *p = NULL;
>
> -if ( !acq
>>> On 25.11.14 at 13:36, wrote:
> No-one (including me) paid attention during review that these
> structures don't adhere to the naming requirements of the public
> interface: Consistently use xen_ prefixes at least for all new
> additions.
>
> Signed-off-by: Jan Beulich
Sorry, again forgot to
On Fri, 2014-11-21 at 13:32 +, Andrew Cooper wrote:
> On 20/11/14 16:45, Boris Ostrovsky wrote:
> > On 11/20/2014 11:15 AM, Ian Campbell wrote:
> >> On Thu, 2014-11-20 at 16:08 +, Andrew Cooper wrote:
> >>> On 20/11/14 16:00, Ian Campbell wrote:
> On Mon, 2014-11-17 at 15:19 +, And
On Fri, 2014-11-21 at 12:01 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 20, 2014 at 03:28:30PM +, Ian Campbell wrote:
> > On Wed, 2014-11-19 at 16:25 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 19, 2014 at 11:26:32AM +, Ian Jackson wrote:
> > > > Hi Konrad, I have another re
>>> On 17.11.14 at 00:07, wrote:
> +if ( (vpmu_mode & XENPMU_MODE_SELF) )
> +cur_regs = guest_cpu_user_regs();
> +else if ( !guest_mode(regs) &&
> is_hardware_domain(sampling->domain) )
> +{
> +cur_regs = regs;
> +
On 11/25/2014 03:45 AM, Jan Beulich wrote:
@@ -1429,6 +1429,12 @@ int vlapic_init(struct vcpu *v)
HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "%d", v->vcpu_id);
+if ( is_pvh_vcpu(v) )
+{
+vlapic->hw.disabled = VLAPIC_HW_DISABLED;
I did consider doing that but I thought that this
On Tue, 2014-11-25 at 12: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 suppose this will have to do for 4.5. Can we do someth
Hi all,
this patch series fixes a cpu mapping leak in virtio-net.
The bug is caused by virtio_net_handle_ctrl: it maps the entire out_sg
iov, but then modifies it and reduces it (iov_discard_front), and only
unmap the reduced version of the iov.
This causes a crash when running on Xen, but the be
Use virtqueue_unmap_sg to unmap in_sg and out_sg in virtqueue_fill.
No functional changes.
Signed-off-by: Stefano Stabellini
CC: jasow...@redhat.com
CC: we...@cn.fujitsu.com
CC: m...@redhat.com
CC: pbonz...@redhat.com
---
hw/virtio/virtio.c | 20 ++--
1 file changed, 2 inserti
Introduce a function to unmap an sg previously mapped with
virtqueue_map_sg.
Signed-off-by: Stefano Stabellini
CC: jasow...@redhat.com
CC: we...@cn.fujitsu.com
CC: m...@redhat.com
CC: pbonz...@redhat.com
---
hw/virtio/virtio.c | 22 ++
include/hw/virtio/virtio.h |
In virtio_net_handle_ctrl unmap the previously mapped out_sg, not a
subset of it.
This patch fixes an abort() when running on Xen.
Signed-off-by: Stefano Stabellini
CC: jasow...@redhat.com
CC: we...@cn.fujitsu.com
CC: m...@redhat.com
CC: pbonz...@redhat.com
---
hw/net/virtio-net.c |4 +++-
> -Original Message-
> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> Sent: Tuesday, November 25, 2014 12:16 AM
> To: Xu, Quan
> Cc: qemu-de...@nongnu.org; xen-devel@lists.xen.org;
> stefano.stabell...@eu.citrix.com
> Subject: Re: [v2 2/4] Qemu-Xen-vTPM: Register Xen
>>> On 07.10.14 at 15:10, wrote:
> New operation sets the 'recipient' domain which will recieve all
> memory pages from a particular domain when these pages are freed.
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1152,6 +1152,33 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domc
>>> On 25.11.14 at 15:38, wrote:
> On 11/25/2014 03:45 AM, Jan Beulich wrote:
>> @@ -1429,6 +1429,12 @@ int vlapic_init(struct vcpu *v)
>>
>> HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "%d", v->vcpu_id);
>>
>> +if ( is_pvh_vcpu(v) )
>> +{
>> +vlapic->hw.disabled = VLAPIC_HW_DISABLED
On Thu, 2014-11-20 at 15:23 -0500, Konrad Rzeszutek Wilk wrote:
> > ---
> > Changes in v2:
> > - Rework the commit message to explain the problem and the
> > solution more clearly
> >
> > I would like to see this patch in Xen 4.5 and backported to Xen 4.4
> > (first
> >
On Fri, 2014-11-21 at 14:31 +, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everything gets
On 11/25/2014 06:41 AM, Dario Faggioli wrote:
On Tue, 2014-11-25 at 11:15 +, Wei Liu wrote:
And here it is.
Boris, can you give it a shot?
---8<---
From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
From: Wei Liu
Date: Tue, 25 Nov 2014 10:59:47 +
Subject: [PATCH]
Move the two virtqueue_unmap_sg calls from virtqueue_fill to
virtqueue_push: most virtio drivers simply call virtqueue_push so they
are unaffected. virtio-net calls virtqueue_fill directly, so we need to
make the two virtqueue_unmap_sg calls explicitely there.
Also replace the virtqueue_push call
Hi Ian,
On 19 November 2014 at 20:58, Ian Campbell wrote:
> Currently we only establish specific mappings for pcie0, which is
> used on the Mustang platform. However at least McDivitt uses pcie3.
> So wire up all the others, based on whether the corresponding DT node
> is marked as available.
>
>
On 25 November 2014 at 14:43, Stefano Stabellini
wrote:
> Introduce a function to unmap an sg previously mapped with
> virtqueue_map_sg.
>
> Signed-off-by: Stefano Stabellini
> CC: jasow...@redhat.com
> CC: we...@cn.fujitsu.com
> CC: m...@redhat.com
> CC: pbonz...@redhat.com
> ---
> hw/virtio/vi
On 11/25/2014 07:06 AM, Stefano Stabellini wrote:
On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
If the hardware supports APIC virtualization we may decide not to use pirqs
and instead use APIC/x2APIC directly, meaning that we don't want to set
x86_msi.setup_msi_irqs and x86_msi.teardown_msi_irq to
On Thu, 2014-11-20 at 16:06 +, George Dunlap wrote:
> On Wed, Nov 12, 2014 at 5:31 PM, George Dunlap
> wrote:
> > Return proper error codes on failure so that scripts can tell whether
> > the command completed properly or not.
>
> How about changing this to something like:
>
> ---
> Return p
On Tue, 25 Nov 2014, Boris Ostrovsky wrote:
> On 11/25/2014 07:06 AM, Stefano Stabellini wrote:
> > On Mon, 24 Nov 2014, Boris Ostrovsky wrote:
> > > If the hardware supports APIC virtualization we may decide not to use
> > > pirqs
> > > and instead use APIC/x2APIC directly, meaning that we don't w
On 11/25/2014 07:48 AM, Jan Beulich wrote:
On 17.11.14 at 00:07, wrote:
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -103,6 +103,10 @@
! vcpu_set_singleshot_timer vcpu.h
? xenoprof_init xenoprof.h
? xenoprof_passivexenoprof.h
On Tue, 2014-11-25 at 20:31 +0530, Pranavkumar Sawargaonkar wrote:
> Patch looks good.
> Acked-by: Pranavkumar Sawargaonkar
Thanks to Julien and you for the review.
Konrad already indicated that he was OK with this for 4.5, so committed.
Ian
___
Xe
Il 25/11/2014 15:42, Stefano Stabellini ha scritto:
Hi all,
this patch series fixes a cpu mapping leak in virtio-net.
The bug is caused by virtio_net_handle_ctrl: it maps the entire out_sg
iov, but then modifies it and reduces it (iov_discard_front), and only
unmap the reduced version of the iov
When parsing bitmap objects JSON parser will create libxl_bitmap map of the
smallest size needed.
This can cause problems when saved image file specifies CPU affinity. For
example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
specified, just a single byte will be allocated an
"Jan Beulich" writes:
Thanks for the review!
On 07.10.14 at 15:10, wrote:
>> New operation sets the 'recipient' domain which will recieve all
>> memory pages from a particular domain when these pages are freed.
>
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -1152,6 +1152
On Tue, 2014-11-25 at 15:13 +, Wei Liu wrote:
> When parsing bitmap objects JSON parser will create libxl_bitmap map of the
> smallest size needed.
>
> This can cause problems when saved image file specifies CPU affinity. For
> example, if 'vcpu_hard_affinity' in the saved image has only the
flight 31844 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31844/
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 Tue, 25 Nov 2014, Peter Maydell wrote:
> On 25 November 2014 at 14:43, Stefano Stabellini
> wrote:
> > Introduce a function to unmap an sg previously mapped with
> > virtqueue_map_sg.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: jasow...@redhat.com
> > CC: we...@cn.fujitsu.com
> > CC: m..
On Tue, Nov 25, 2014 at 02:11:39PM +, Jan Beulich wrote:
> >>> On 25.11.14 at 13:36, wrote:
> > No-one (including me) paid attention during review that these
> > structures don't adhere to the naming requirements of the public
> > interface: Consistently use xen_ prefixes at least for all new
On Tue, Nov 25, 2014 at 02:13:01PM +, Ian Campbell wrote:
> On Fri, 2014-11-21 at 12:01 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 20, 2014 at 03:28:30PM +, Ian Campbell wrote:
> > > On Wed, 2014-11-19 at 16:25 -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Nov 19, 2014 at 11:
On Tue, Nov 25, 2014 at 09:57:54AM -0500, Boris Ostrovsky wrote:
> On 11/25/2014 06:41 AM, Dario Faggioli wrote:
> >On Tue, 2014-11-25 at 11:15 +, Wei Liu wrote:
> >>And here it is.
> >>
> >>Boris, can you give it a shot?
> >>
> >>---8<---
> >> From 77531e31d239887b9f36c03e434300bc30683092 Mon
On Tue, 2014-11-25 at 10:51 -0500, Konrad Rzeszutek Wilk wrote:
> Right, so with the reassurance text added on:
> Release-Acked-by: Konrad Rzeszutek Wilk
Thanks.
Chunyan, I propose to commit adding the following to the commit text of
"[PATCH 1/2 V3] remove domain field in xenstore backend dir":
On Tue, Nov 25, 2014 at 03:58:33PM +, Ian Campbell wrote:
> On Tue, 2014-11-25 at 10:51 -0500, Konrad Rzeszutek Wilk wrote:
> > Right, so with the reassurance text added on:
> > Release-Acked-by: Konrad Rzeszutek Wilk
>
> Thanks.
>
> Chunyan, I propose to commit adding the following to the c
c/s d1b93ea causes substantial functional regressions in pygrub's ability to
parse bootloader configuration files.
c/s d1b93ea itself changed an an interface which previously used exclusively
integers, to using strings in the case of a grub configuration with explicit
default set, along with chang
The already documented configure patch was not applied.
Adjust documentation to describe existing behaviour.
Signed-off-by: Olaf Hering
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
---
resend due to lack of Cc: tags
INSTALL | 19 +--
1 f
On 11/24/2014 11:02 AM, Ian Campbell wrote:
On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
Hi,
while testing my "linear p2m list" patches I saw the following
problem (e
On Tue, Nov 25, 2014 at 05:04:09PM +0100, Olaf Hering wrote:
> The already documented configure patch was not applied.
> Adjust documentation to describe existing behaviour.
>
> Signed-off-by: Olaf Hering
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Keir Fraser
> Cc: Tim Deega
On 11/25/2014 09:55 AM, Jan Beulich wrote:
Regardless, do you think that disabling VPMU for PVH is worth anyway?
That depends on what (bad) consequences not doing so has.
I haven't seen anything (besides VAPIC accesses) but I think it would be
prudent to prevent any VPMU activity from happe
On Mon, Nov 24, 2014 at 06:06:16PM -0500, Boris Ostrovsky wrote:
> Changes in v3:
> * Explicitly include asm/apic.h in arch/x86/pci/xen.c for !CONFIG_SMP.
>
> Changes in v2:
> * New version of cpuid.h file from Xen tree (with a couple of style
> adjustments)
> * Whitespace cleanup
>
> Currently
On 25/11/14 14:14, Ian Campbell wrote:
> On Fri, 2014-11-21 at 13:32 +, Andrew Cooper wrote:
>> On 20/11/14 16:45, Boris Ostrovsky wrote:
>>> On 11/20/2014 11:15 AM, Ian Campbell wrote:
On Thu, 2014-11-20 at 16:08 +, Andrew Cooper wrote:
> On 20/11/14 16:00, Ian Campbell wrote:
>>>
On Tue, Nov 25, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 25, 2014 at 05:04:09PM +0100, Olaf Hering wrote:
> > +Using additional CFLAGS to build tools running in dom0 is required when
> Why the mention of 'buld tools running in dom0'? It sounds like it is
> required to use dom0 to build tools?
D
On Fri, 2014-11-21 at 16:30 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v3 04/15] make-flight: Run a basic test
> on each arm platform"):
> > Unlike x86 there is enough variation in the ARM platforms that it is
> > worth having a basic test on each as part of a standard run. T
On Tue, 2014-11-25 at 16:24 +, Ian Campbell wrote:
> On Thu, 2014-11-20 at 16:03 +, Wei Liu wrote:
> > On Thu, Nov 20, 2014 at 03:48:47PM +, Ian Campbell wrote:
> > > The libxc xc_dom_* infrastructure uses a very simple malloc memory pool
> > > which
> > > is freed by xc_dom_release. H
On 11/25/2014 06:51 AM, Xu, Quan wrote:
>>
>> Also, this message was not threaded properly; it appeared as a top-level
>> thread along with three other threads for its siblings, instead of all four
>> patches being in-reply-to the 0/4 cover letter.
>>
> Thanks Eric.
>
> Should I:
>
> V2 is versi
>>> On 25.11.14 at 16:41, wrote:
> "Jan Beulich" writes:
> On 07.10.14 at 15:10, wrote:
>>> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg,
>>> unsigned int order)
>>> scrub = 1;
>>> }
>>>
>>> -if ( unlikely(scrub) )
>>> -for
>>> On 25.11.14 at 17:19, wrote:
> On 11/25/2014 09:55 AM, Jan Beulich wrote:
>>
>>> Regardless, do you think that disabling VPMU for PVH is worth anyway?
>> That depends on what (bad) consequences not doing so has.
>
> I haven't seen anything (besides VAPIC accesses) but I think it would be
> p
On Tue, 2014-11-25 at 17:10 +0100, Juergen Gross wrote:
> On 11/24/2014 11:02 AM, Ian Campbell wrote:
> > On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
> >> On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
> Hi,
On Tue, 25 Nov 2014, Ian Campbell wrote:
> On Tue, 2014-11-25 at 12: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 s
On 11/25/2014 05:18 PM, Ian Campbell wrote:
On Tue, 2014-11-25 at 17:10 +0100, Juergen Gross wrote:
On 11/24/2014 11:02 AM, Ian Campbell wrote:
On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Nov 21, 2014 at 09:42:11AM +0100
On Thu, 2014-11-20 at 16:03 +, Wei Liu wrote:
> On Thu, Nov 20, 2014 at 03:48:47PM +, Ian Campbell wrote:
> > The libxc xc_dom_* infrastructure uses a very simple malloc memory pool
> > which
> > is freed by xc_dom_release. However the various xc_try_*_decode routines
> > (other
> > than
On Thu, 2014-11-20 at 17:37 +, Ian Campbell wrote:
> The major blocker right now is that rerunning
> mg-debian-installer-update pulls in a newer kernel from backports.org
> which doesn't boot on the existing midway platform. I'm investigating
> that at the moment.
This investigation resulted i
A failed vmentry is overwhelmingly likely to be caused by corrupt VMC[SB]
state. As a result, injecting a fault and retrying the the vmentry is likely
to fail in the same way.
With this new logic, a guest will unconditionally be crashed if it has
suffered two repeated vmentry failures, even if it
On 25/11/14 16:54, Andrew Cooper wrote:
> A failed vmentry is overwhelmingly likely to be caused by corrupt VMC[SB]
> state. As a result, injecting a fault and retrying the the vmentry is likely
> to fail in the same way.
>
> With this new logic, a guest will unconditionally be crashed if it has
>
On 11/24/2014 11:02 AM, Ian Campbell wrote:
On Mon, 2014-11-24 at 10:55 +0100, Juergen Gross wrote:
On 11/21/2014 02:57 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
Hi,
while testing my "linear p2m list" patches I saw the following
problem (e
1 - 100 of 137 matches
Mail list logo
