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 xentrace, I will do it. But will anyone
give me some
flight 31854 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31854/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-rumpuserxen-amd64 8 guest-start fail baseline untested
test-amd64-i386-xl-credit29
flight 31853 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31853/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 31835
Tests which did not succeed,
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:
> CC'ing Paolo.
>
>
> Wen,
> tha
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() evaluates to 0 for tail
pages the assertion fails. The code alrea
> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Wednesday, November 26, 2014 12:31 AM
> To: Xu, Quan; qemu-de...@nongnu.org
> Cc: xen-devel@lists.xen.org; arm...@redhat.com; lcapitul...@redhat.com
> Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: S
Jan Beulich wrote on 2014-11-25:
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
On 10/27/2014 02:02 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Oct 27, 2014 at 01:38:20PM -0400, Waiman Long wrote:
My concern is that spin_unlock() can be called in many places, including
loadable kernel modules. Can the paravirt_patch_ident_32() function able to
patch all of them in reasonable
flight 31850 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31850/
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
flight 31852 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31852/
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. 31680
Tests which did not succe
On 25/11/2014 22:16, M A Young wrote:
>
>
> On Tue, 25 Nov 2014, Wei Liu wrote:
>
>> 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
On Tue, 25 Nov 2014, Wei Liu wrote:
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 avo
flight 31849 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31849/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64 5 xen-boot fail pass in 31830
test-amd64-i386-xl-qemut-winxpsp3 5 xe
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 time. This doesn't appear to be dependent on Xen version
--- I saw
Hello,
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.
Migration v2 is in exclusive use in XenServer 6.5. We primarily
developed migr
flight 31848 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31848/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-multivcpu 5 xen-bootfail pass in 31820
test-amd64-amd64-xl-qemu
On 11/25/2014 01:19 PM, Andrew Cooper wrote:
On 25/11/14 16:57, Daniel De Graaf wrote:
Reported-by: Michael Young
Signed-off-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
CC'd Konrad, as this should be accepted into Xen-4.5. Without it,
migration/suspend fails with -EPERM in the default
flight 31851 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31851/
Perfect :-)
All tests in this flight passed
version targeted for testing:
rumpuserxen a2fc4f9dbc9851cbb97ced7b8eec313d07a19ab0
baseline version:
rumpuserxen cdb4bff22f578ceb0731db509274
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 construction time.
>
> This patch fixes an abort() when assi
On Tue, Nov 25, 2014 at 06:19:05PM +, Andrew Cooper wrote:
> On 25/11/14 16:57, Daniel De Graaf wrote:
> > Reported-by: Michael Young
> > Signed-off-by: Daniel De Graaf
>
> Reviewed-by: Andrew Cooper
>
> CC'd Konrad, as this should be accepted into Xen-4.5. Without it,
> migration/suspend
On 25/11/14 16:57, Daniel De Graaf wrote:
> Reported-by: Michael Young
> Signed-off-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
CC'd Konrad, as this should be accepted into Xen-4.5. Without it,
migration/suspend fails with -EPERM in the default case when XSM is
compiled into Xen.
Daniel:
On Tue, Nov 25, 2014 at 01:03:34PM -0500, Daniel De Graaf wrote:
> On 11/25/2014 05:07 AM, George Dunlap wrote:
> >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 mod
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. However, I am not sure we want to make any
In libxl_set_memory_target when setting the new maxmem, retain the same
offset on top of the current target. The offset includes memory
allocated by QEMU for rom files.
Signed-off-by: Stefano Stabellini
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..8381c3e 100644
--- a/to
When an unknown domctl, sysctl, or other operation is encountered in the
FLASK security server, use the allow_unknown bit in the security policy
(set by running checkpolicy -U allow) to decide if the permission should
be allowed or denied. This allows new operations to be tested without
needing to
Reported-by: Michael Young
Signed-off-by: Daniel De Graaf
---
xen/xsm/flask/hooks.c | 2 ++
xen/xsm/flask/policy/access_vectors | 2 ++
2 files changed, 4 insertions(+)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0ba2ce9..d48463f 100644
--- a/xen/xsm/flask/hoo
On 11/25/2014 05:07 AM, George Dunlap wrote:
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 s
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 construction time.
This patch fixes an abort() when assigning more than 4 NICs to a VM.
Signed-off-by: Stefan
On Tue, Nov 25, 2014 at 04:39:54PM +, Jan Beulich wrote:
> >>> 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
On Tue, Nov 25, 2014 at 05:27:53PM +0100, Olaf Hering 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 i
ARMv8 model may not disable correctly the timer interrupt when Xen
context switch to an idle vCPU. Therefore Xen may receive a spurious
timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
when trying to inject the interrupt with the following stack trace.
(XEN)[<00228
On Tue, Nov 25, 2014 at 04:56:02PM +, 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:
> > > > Account for the extra memory needed for the rom files
>>> 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. However, I am not sure we want to make any vmentry failure
> quite, as any vmentry failur
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:
> > > Account for the extra memory needed for the rom files of any emulated
> > > nics:
> > > QEMU uses xc_domain_populate_physma
On Tue, Nov 25, 2014 at 04:28:32PM +0100, Fabio Fantoni wrote:
> 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
"Jan Beulich" writes:
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 ( unlik
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:
> > > > Account for the extra memory needed for the rom files of any emulated
> >
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 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
>
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 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
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 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 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 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 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 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 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 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, 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 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 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 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 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/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
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
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
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
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 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, 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 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, 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..
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, 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
"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
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
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
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
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, 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 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 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 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
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.
>
>
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
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]
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 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 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 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
> -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
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 +++-
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 |
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
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
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
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 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 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 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 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 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 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
> -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
> -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
>>> 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) !=
>>> 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
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
1 - 100 of 137 matches
Mail list logo
