On 11/27/2014 01:27 AM, Jan Beulich wrote:
This was precisely the reason why I told you that the numbering
differs (and is confusing and has nothing to do with actual C state
numbers): What max_cstate refers to in the mwait-idle driver is
what above is listed as type[Cx], i.e. the state at index
On Fri, 2014-11-28 at 00:28 +, 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 rece
XenGT (Intel Graphics Virtualization technology, please refer to
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-
xengt) driver runs inside Dom0 as a virtual graphics device model,
and needs to trap and emulate the guest's write operations to some
specific memory pages, like memory p
On Fri, 28 Nov 2014, Ian Campbell wrote:
On Fri, 2014-11-28 at 00:28 +, 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 wil
>>> On 28.11.14 at 09:24, wrote:
>> And with 6 errata
>> documented it's not all that unlikely that there's a 7th one with
>> MONITOR/MWAIT behavior. The commit you bisected to (and
>> which you had verified to be the culprit by just forcing
>> arch_skip_send_event_check() to always return false)
flight 31882 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31882/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 31781
Regressions which
>>> On 28.11.14 at 04:28, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4287,7 +4287,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
> unsigned int *ebx,
> !host_tsc_is_safe() )
> *edx &= ~cpufeat_mask(X86_FEATURE_RDTSCP);
>
>>> On 28.11.14 at 10:07, wrote:
> flight 31882 xen-4.4-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31882/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-pair 17 guest-migrate/src_ho
On Nov 28, 2014, at 00:50, Jan Beulich wrote:
On 28.11.14 at 09:24, wrote:
>>> And with 6 errata
>>> documented it's not all that unlikely that there's a 7th one with
>>> MONITOR/MWAIT behavior. The commit you bisected to (and
>>> which you had verified to be the culprit by just forcing
>>
>>> On 28.11.14 at 08:59, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2838,7 +2838,8 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
> long gla,
> * to the mmio handler.
> */
> if ( (p2mt == p2m_mmio_dm) ||
> - (npfec.write_access &&
On Thu, 2014-11-27 at 12:51 +0200, Razvan Cojocaru wrote:
It's a good idea to CC the relevant maintainers if you want their input.
> Hello,
>
> I know that xc_interface_open() can be safely called several times from
> the same process, and that several processes can each have a bunch of
> xc_int
On 11/28/2014 11:58 AM, Ian Campbell wrote:
> On Thu, 2014-11-27 at 12:51 +0200, Razvan Cojocaru wrote:
>
> It's a good idea to CC the relevant maintainers if you want their input.
>
>> Hello,
>>
>> I know that xc_interface_open() can be safely called several times from
>> the same process, and t
On Fri, 28 Nov 2014, Chunyan Liu wrote:
> Found by Stefano, this chunk of the patch was never applied to
> xen-unstable (commit 11dffa2359e8a2629490c14c029c7c7c777b3e47),
> see http://marc.info/?l=qemu-devel&m=140471493425353&w=2.
>
> Signed-off-by: Chunyan Liu
I think it should be in 4.5: at th
Hi,
I would check whether GRO is enabled under Dom0 or not (ethtool -k
ethX). Comparing top during test (especially that which context use how
many percentage), and the number of interrupts per second (grep eth
/proc/interrupts) would be interesting too.
Regards,
Zoltan
On 28/11/14 02:29,
>> -if (!hvm_pse1gb_supported(d))
>> +if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
>> *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);
>
>With
>
>#define hvm_pse1gb_supported(d) \
>(cpu_has_page1gb && paging_mode_hap(d))
>the change above is pointless. While,
On 28/11/14 10:29, Li, Liang Z wrote:
>>> -if (!hvm_pse1gb_supported(d))
>>> +if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
>>> *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);
>> With
>>
>> #define hvm_pse1gb_supported(d) \
>>(cpu_has_page1gb && paging_mode_hap
>>>(cpu_has_page1gb && paging_mode_hap(d)) the change above is
>>> pointless. While, considering this, comments on
>>> v2 may have been misleading, you should have simply updated the patch
>>> description instead to clarify why the v2 change was okay even for the
>>> shadow mode case.
>> I c
>>> On 28.11.14 at 11:29, wrote:
>> > -if (!hvm_pse1gb_supported(d))
>>> +if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
>>> *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB);
>>
>>With
>>
>>#define hvm_pse1gb_supported(d) \
>>(cpu_has_page1gb && paging_mode_hap(d
Today get_phys_to_machine() is always called when the mfn for a pfn
is to be obtained. Add a wrapper __pfn_to_mfn() as inline function
to be able to avoid calling get_phys_to_machine() when possible as
soon as the switch to a linear mapped p2m list has been done.
Signed-off-by: Juergen Gross
Revi
Paravirtualized kernels running on Xen use a three level tree for
translation of guest specific physical addresses to machine global
addresses. This p2m tree is used for construction of page table
entries, so the p2m tree walk is performance critical.
By using a linear virtual mapped p2m list acce
In arch/x86/xen/p2m.c three different allocation functions for
obtaining a memory page are used: extend_brk(), alloc_bootmem_align()
or __get_free_page(). Which of those functions is used depends on the
progress of the boot process of the system.
Introduce a common allocation routine selecting th
The m2p overrides are used to be able to find the local pfn for a
foreign mfn mapped into the domain. They are used by driver backends
having to access frontend data.
As this functionality isn't used in early boot it makes no sense to
initialize the m2p override functions very early. It can be don
Some functions in arch/x86/xen/p2m.c are used locally only. Make them
static. Rearrange the functions in p2m.c to avoid forward declarations.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/xen/page.h | 6 -
arch/x86/xen/p2m.c | 346
The source arch/x86/xen/p2m.c has some coding style issues. Fix them.
Signed-off-by: Juergen Gross
---
arch/x86/xen/p2m.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 9201a38..73d354a 100644
--- a/arch/x86/xen/p
At start of the day the Xen hypervisor presents a contiguous mfn list
to a pv-domain. In order to support sparse memory this mfn list is
accessed via a three level p2m tree built early in the boot process.
Whenever the system needs the mfn associated with a pfn this tree is
used to find the mfn.
I
Early in the boot process the memory layout of a pv-domain is changed
to match the E820 map (either the host one for Dom0 or the Xen one)
regarding placement of RAM and PCI holes. This requires removing memory
pages initially located at positions not suitable for RAM and adding
them later at higher
Introduces lookup_pmd_address() to get the address of the pmd entry
related to a virtual address in the current address space. This
function is needed for support of a virtual mapped sparse p2m list
in xen pv domains, as we need the address of the pmd entry, not the
one of the pte in that case.
Si
When the physical memory configuration is initialized the p2m entries
for not pouplated memory pages are set to "invalid". As those pages
are beyond the hypervisor built p2m list the p2m tree has to be
extended.
This patch delays processing the extra memory related p2m entries
during the boot proc
Instead of checking at each call of set_phys_to_machine() whether a
new p2m page has to be allocated due to writing an entry in a large
invalid or identity area, just map those areas read only and react
to a page fault on write by allocating the new page.
This change will make the common path with
If hardware support the 1GB pages, expose the feature to guest by
default. Users don't have to use a 'cpuid= ' option in config fil
e to turn it on.
If guest use shadow mode, the 1GB pages feature will be hidden from
guest, this is done in the function hvm_cpuid(). So the change is
okay for shadow
On Wed, 2014-09-24 at 10:14 +0100, Ian Campbell wrote:
> On Tue, 2014-09-23 at 16:40 -0400, Daniel De Graaf wrote:
> > On 09/23/2014 11:30 AM, Ian Campbell wrote:
> > > On Tue, 2014-09-23 at 10:37 +0100, Wei Liu wrote:
> > >> On Tue, Sep 23, 2014 at 10:01:48AM +0100, Wei Liu wrote:
> > >>> On Mon,
On Tue, 2014-11-25 at 11:11 -0500, Boris Ostrovsky wrote:
> 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
>>> On 28.11.14 at 11:52, wrote:
> If hardware support the 1GB pages, expose the feature to guest by
> default. Users don't have to use a 'cpuid= ' option in config fil
> e to turn it on.
>
> If guest use shadow mode, the 1GB pages feature will be hidden from
> guest, this is done in the function
On Thu, 2014-11-27 at 12:34 +, Andrew Cooper wrote:
> The code now now matches its comment, and will actually catch the case of a
> bad xs handle.
>
> Signed-off-by: Andrew Cooper
> Coverity-ID: 1055948
> CC: Ian Campbell
> CC: Ian Jackson
> CC: Wei Liu
> CC: Xen Coverity Team
Acked-by:
Hi,
I have finally worked out why XenServer is having issues with its legacy
windows drivers and Xen-4.5.
XenServer needs to support hvm ops with an indicies of 0x102 and 0x103
to prevent our legacy windows drivers from BSODing on boot. (These
problems will disappear when we can drop Windows XP/
Ian Campbell writes ("Re: [Xen-devel] Xenstore.h clarifications"):
> I think there's a pretty good chance that the same applies to xenstore
> connections made over the device/shared-ring interface.
Yes.
> I'm not really sure about the semantics of a Unix domain socket after a
> fork, but I don't
On Thu, 2014-11-27 at 12:34 +, Andrew Cooper wrote:
> The error handling from a failed memory allocation should return
> PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and continuing
> to the memcpy() below, with the dest pointer being NULL.
>
> Furthermore, the context string
On Thu, 2014-11-27 at 12:34 +, Andrew Cooper wrote:
> Don't leak a 16k allocation if PyArg_ParseTupleAndKeywords() or the first
> xc_readconsolering() fail. It is trivial to run throught the processes memory
> by repeatedly passing junk parameters to this function.
>
> In the case that the ca
On 28/11/14 11:37, Ian Campbell wrote:
> On Thu, 2014-11-27 at 12:34 +, Andrew Cooper wrote:
>> The error handling from a failed memory allocation should return
>> PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and
>> continuing
>> to the memcpy() below, with the dest pointer
On Thu, 2014-11-27 at 18:02 +, Julien Grall wrote:
> state at the GIC level. This would also avoid masking the output signal
> and requires specific handling in the guest OS.
"which requires"?
It doesn't seem quite right to me otherwise, since context switching the
virq state *removes* the ne
On Fri, 2014-11-28 at 08:32 +, M A Young wrote:
> On Fri, 28 Nov 2014, Ian Campbell wrote:
>
> > On Fri, 2014-11-28 at 00:28 +, M A Young wrote:
> >> Migrations with xl migrate --debug will fail because debugging information
> >> from the receiving process is written to the stdout channel.
On Fri, 2014-11-28 at 18:52 +0800, Liang Li wrote:
> If hardware support the 1GB pages, expose the feature to guest by
> default. Users don't have to use a 'cpuid= ' option in config fil
> e to turn it on.
>
> If guest use shadow mode, the 1GB pages feature will be hidden from
> guest, this is don
Jan Beulich writes ("Re: [Xen-devel] [xen-4.4-testing test] 31882: regressions
- trouble: blocked/broken/fail/pass"):
> On 28.11.14 at 10:07, wrote:
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > test-amd64-i386-pair 17 guest-migrate/src_host/
Ian Campbell writes ("Re: [PATCH v2] fix migration failure with xl migrate
--debug"):
> Acked-by: Ian Campbell
Thanks for reviewing it :-).
> It's pretty big but a large chunk is pretty mechanical. Were you
> intending this for 4.5? (Konrad CCd).
I think (based on reading the thread but not th
On Fri, 2014-11-28 at 13:55 +0800, Chunyan Liu wrote:
> Found by Stefano, this chunk of the patch was never applied to
> xen-unstable (commit 11dffa2359e8a2629490c14c029c7c7c777b3e47),
> see http://marc.info/?l=qemu-devel&m=140471493425353&w=2.
How strange, "git am" usually makes it pretty difficu
On Thu, 2014-11-27 at 12:34 +, Andrew Cooper wrote:
> While Xend is certainly dead and gone, XenServer at the very least still has
> consumers of these python libraries.
AIUI XS mainly uses the xs.c stuff, with the xc.c stuff being mainly
debug utilities.
This is important because while the
On Wed, 2014-11-26 at 21:19 +, Andrew Cooper wrote:
> 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 st
On Tue, 2014-11-25 at 10:54 -0500, Konrad Rzeszutek Wilk wrote:
> > >>Reported-by: Boris Ostrovsky
> > >>Signed-off-by: Wei Liu
> > >>Cc: Ian Campbell
> > >>Cc: Ian Jackson
> > >>Cc: Dario Faggioli
> > >>
> > >If this end up being the approach, it can have the following:
> > >
> > >Reviewed-by
On Thu, 2014-11-27 at 10:17 -0500, Konrad Rzeszutek Wilk wrote:
> On November 27, 2014 4:26:26 AM EST, 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
On Wed, 2014-11-26 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
> 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
On Tue, 2014-11-25 at 11:03 -0500, Konrad Rzeszutek Wilk wrote:
> 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
> >
On Thu, 2014-11-20 at 14:44 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 20, 2014 at 03:48:17PM +, Wei Liu wrote:
> > On Thu, Nov 20, 2014 at 03:29:51PM +, Ian Campbell wrote:
> > > On Wed, 2014-11-19 at 21:24 +, Wei Liu wrote:
> > > > On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konr
On Fri, 2014-11-28 at 11:47 +, Andrew Cooper wrote:
> On 28/11/14 11:37, Ian Campbell wrote:
> > On Thu, 2014-11-27 at 12:34 +, Andrew Cooper wrote:
> >> The error handling from a failed memory allocation should return
> >> PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and
Added to the xs_open() comments in xenstore.h. The text has been
taken almost verbatim from a xen-devel email by Ian Campbell,
and confirmed as accurate by Ian Jackson.
Signed-off-by: Razvan Cojocaru
Suggested-off-by: Ian Campbell
---
tools/xenstore/include/xenstore.h | 12 +++-
1 fil
longtao.pang writes ("[OSSTEST PATCH 0/4] Introduction of the patches."):
> We updated these patchs about adding Nested test job into OSSTest.
Thanks for your contribution.
Having some testing of nested HVM would be good.
But I'm not convinced that these patches take the right approach to
achiev
Razvan Cojocaru writes ("[PATCH] xenstore: Clarify xs_open() semantics"):
> Added to the xs_open() comments in xenstore.h. The text has been
> taken almost verbatim from a xen-devel email by Ian Campbell,
> and confirmed as accurate by Ian Jackson.
>
> Signed-off-by: Razvan Cojocaru
> Suggested-o
On Thu, 2014-11-27 at 18:02 +, Julien Grall wrote:
> I propose to reword the commit message into:
You'll want to change the code comment too I think.
>
> xen/arm: Handle platforms with edge-triggered virtual timer
>
> Some platforms (such as the ARMv8 model) uses edge-triggered interrupt
>
On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> No-one in their right mind would do this, and if they did everything
> would definitely collapse. Arrange that if this happens, we crash
> ASAP.
>
> Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
> ---
> tools/libxl/libxl.c |2 ++
flight 31885 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31885/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-sedf-pin 7 debian-install fail pass in 31857
test-amd64-amd64-xl-pcipt-intel 5 xen-
On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> We want to have no fd events registered when we are idle. This
> implies that we must be able to deregister our interest in the sigchld
> self-pipe fd, not just modify to request no events.
>
> Signed-off-by: Ian Jackson
Acked-by: Ian Camp
Hi Ian,
On 28/11/14 12:32, Ian Campbell wrote:
> On Thu, 2014-11-27 at 18:02 +, Julien Grall wrote:
>> I propose to reword the commit message into:
>
> You'll want to change the code comment too I think.
It was my plan. I will send a new version during the day.
Regards,
--
Julien Grall
_
Hi Ian,
On 28/11/14 11:47, Ian Campbell wrote:
> On Thu, 2014-11-27 at 18:02 +, Julien Grall wrote:
>> state at the GIC level. This would also avoid masking the output signal
>> and requires specific handling in the guest OS.
>
> "which requires"?
>
> It doesn't seem quite right to me otherw
On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> We want to have no fd events registered when we are idle.
> Also, we should put back the default SIGCHLD handler. So:
>
> * In libxl_ctx_free, use libxl_childproc_setmode to set the mode to
>the default, which is libxl_sigchld_owner_lib
On 11/12/2014 05:31 PM, Tamas K Lengyel wrote:
> The spin-lock implementation in the xen-access test program is implemented
> in a fashion that is actually incomplete. The x86 assembly that guarantees
> that
> the lock is held by only one thread lacks the "lock;" instruction.
>
> However, the spi
On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> libxl_event_register_callbacks cannot reasonably be called while libxl
> is busy (has outstanding operations and/or enabled events).
>
> This is because the previous spec implied (although not entirely
> clearly) that event hooks would not be
On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> We want to have no fd events registered when we are idle.
> In this patch, deal with the evtchn fd:
>
> * Defer setup of the evtchn handle to the first use.
> * Defer registration of the evtchn fd; register as needed on use.
> * When cance
On Thu, 2014-11-27 at 18:30 +, Ian Jackson wrote:
> Konrad: here is a set of fixes for libxl which ought IMO to be in 4.5.
> See below, or the rest of the thread, for details. It's broken up
> into 6 tiny patches for ease of review.
I tested an identical version of this series, just without t
On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> * On libxl teardown, the watch fd should therefore be unregistered.
> assert that this is the case.
A bunch of the patches in this series basically assume that the ctx is
idle when it is freed, i.e. it requires everything to be explicitly
c
>>> On 28.11.14 at 12:36, wrote:
> However, it occurs to me that HVMOP_op_mask absolutely must live in the
> public header files, as it is guest visible, and forms part of the ABI.
>
> Consider a userspace task which falls into a continuation, is preempted
> and paused by the guest kernel, the en
On Fri, 2014-11-28 at 12:48 +, Julien Grall wrote:
> Hi Ian,
>
> On 28/11/14 11:47, Ian Campbell wrote:
> > On Thu, 2014-11-27 at 18:02 +, Julien Grall wrote:
> >> state at the GIC level. This would also avoid masking the output signal
> >> and requires specific handling in the guest OS.
>
On Fri, 2014-11-28 at 13:07 +, Jan Beulich wrote:
> I suppose a stubdom gets re-created on the target host (rather
> than migrated) when its client migrates.
Correct.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen
On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> We want to have no fd events registered when we are idle.
> In this patch, deal with the xenstore watch fd:
>
> * Track the total number of active watches.
> * When deregistering a watch, or when watch registration fails, check
> whether th
On 28/11/14 13:07, Jan Beulich wrote:
On 28.11.14 at 12:36, wrote:
>> However, it occurs to me that HVMOP_op_mask absolutely must live in the
>> public header files, as it is guest visible, and forms part of the ABI.
>>
>> Consider a userspace task which falls into a continuation, is preempte
On Sun, 23 Nov 2014 22:35:36 +
Julien Grall wrote:
> Hello all,
>
> At the beginning of the year, I have sent a first RFC to add support
> for FreeBSD on Xen ARM [1].
...
> Major changes in this new version:
> * Add Device Tree support via Linux Boot ABI
> * Add zImage support
>
Ian Campbell writes ("Re: [PATCH 3/6] libxl: events: Deregister, don't just
modify, sigchld pipe fd"):
> On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> > We want to have no fd events registered when we are idle. This
> > implies that we must be able to deregister our interest in the sigc
On Fri, 2014-11-28 at 14:42 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 3/6] libxl: events: Deregister, don't just
> modify, sigchld pipe fd"):
> > On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> > > We want to have no fd events registered when we are idle. This
> > > imp
Ian Campbell writes ("Re: [PATCH 5/6] libxl: events: Deregister evtchn fd when
not needed"):
> On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> > We want to have no fd events registered when we are idle.
> > In this patch, deal with the evtchn fd:
> >
> > * Defer setup of the evtchn handl
On Fri, 2014-11-28 at 14:47 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 5/6] libxl: events: Deregister evtchn fd
> when not needed"):
> > On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> > > We want to have no fd events registered when we are idle.
> > > In this patch, deal
Ian Campbell writes ("Re: [PATCH 2/6] libxl: events: Deregister xenstore watch
fd when not needed"):
> On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> > * On libxl teardown, the watch fd should therefore be unregistered.
> > assert that this is the case.
>
> A bunch of the patches in th
On Fri, 2014-11-28 at 14:56 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 2/6] libxl: events: Deregister xenstore
> watch fd when not needed"):
> > On Thu, 2014-11-27 at 18:27 +, Ian Jackson wrote:
> > > * On libxl teardown, the watch fd should therefore be unregistered.
> > >
create ^
title it QMP connection problems prevent libxl from calling
libxl__device_pci_reset on domain shutdown
thanks
On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> Hi,
>
> While testing a patch for Konrad i was wondering why "libxl_pci.c:
> libxl__device_pci_reset()"
> doesn't get called on
Some platforms (such as Xgene and ARMv8 models) use an edge-triggered interrupt
for the virtual timer. Even if the timer output signal is masked in the
context switch, the GIC will keep track that of any interrupts raised
while IRQs are disabled. As soon as IRQs are re-enabled, the virtual
interrup
>>> On 28.11.14 at 14:55, wrote:
> The problem is with continuations which reuse the upper bits of the
> input register, not with this HVMOP_op_mask specifically; the
> HVMOP_op_mask simply adds to an existing problem. This is something
> which needs considering urgently because, as you identify
We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
3.17.3 running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.
Shortly after the upgrade we started to lose network connectivity to the
DomU a few times a day that required a reboot to fix. We see nothing in
the xen logs or xl dmesg, b
On Fri, 2014-11-28 at 15:19 +, Anthony Wright wrote:
> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
> 3.17.3
Is this a Debian kernel? In which case you might be seeing
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767261 , this will be
fixed in the next upload of
I forgot to add "for 4.5" in the commit title.
On 28/11/14 15:17, Julien Grall wrote:
> This patch is a bug fix candidate for Xen 4.5 and backport for Xen 4.4.
> It affects at least Xgene platform and ARMv8 models where Xen may
> randomly crash.
Thinking a bit more to this. I believe it's possib
On Tue, 2014-11-25 at 02:08 -0700, Chun Yan Liu wrote:
> 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 thought you had explained a scenario where the toolstack needed to be
at lea
On 28/11/14 15:18, Jan Beulich wrote:
On 28.11.14 at 14:55, wrote:
>> The problem is with continuations which reuse the upper bits of the
>> input register, not with this HVMOP_op_mask specifically; the
>> HVMOP_op_mask simply adds to an existing problem. This is something
>> which needs con
Xen does a shutdown of the emulated PCI network device in
pci_unplug_nics. But this just disables the PCI device. The tap device
for a given emulated card remains active because nothing closes the
file descriptor.
The cmdline for qemu contains something like "-device
rtl8139,id=nic0,netdev=net0,
On 28/11/2014 15:23, Ian Campbell wrote:
> On Fri, 2014-11-28 at 15:19 +, Anthony Wright wrote:
>> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
>> 3.17.3
> Is this a Debian kernel? In which case you might be seeing
It's a stock kernel from kernel.org, we have a custom
On Fri, Nov 28, 2014 at 03:08:51PM +, Stefano Stabellini wrote:
> create ^
> title it QMP connection problems prevent libxl from calling
> libxl__device_pci_reset on domain shutdown
> thanks
>
> On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
> > Hi,
> >
> > While testing a patch for Konrad i
On do_pci_remove when QEMU returns error, we just bail out early without
resetting the device. On domain shutdown we are racing with QEMU exiting
and most often QEMU closes the QMP connection before executing the
requested command.
In these cases if force=1, it makes sense to go ahead with rest of
On Fri, 28 Nov 2014, Wei Liu wrote:
> On Fri, Nov 28, 2014 at 03:08:51PM +, Stefano Stabellini wrote:
> > create ^
> > title it QMP connection problems prevent libxl from calling
> > libxl__device_pci_reset on domain shutdown
> > thanks
> >
> > On Wed, 26 Nov 2014, Sander Eikelenboom wrote:
>
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-credit2
test guest-saverestore
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-
On Fri, Nov 28, 2014 at 04:54:19PM +, Stefano Stabellini wrote:
> On Fri, 28 Nov 2014, Wei Liu wrote:
> > On Fri, Nov 28, 2014 at 03:08:51PM +, Stefano Stabellini wrote:
> > > create ^
> > > title it QMP connection problems prevent libxl from calling
> > > libxl__device_pci_reset on domain
On Fri, 28 Nov 2014, Wei Liu wrote:
> On Fri, Nov 28, 2014 at 04:54:19PM +, Stefano Stabellini wrote:
> > On Fri, 28 Nov 2014, Wei Liu wrote:
> > > On Fri, Nov 28, 2014 at 03:08:51PM +, Stefano Stabellini wrote:
> > > > create ^
> > > > title it QMP connection problems prevent libxl from ca
Friday, November 28, 2014, 6:09:52 PM, you wrote:
> On Fri, 28 Nov 2014, Wei Liu wrote:
>> On Fri, Nov 28, 2014 at 04:54:19PM +, Stefano Stabellini wrote:
>> > On Fri, 28 Nov 2014, Wei Liu wrote:
>> > > On Fri, Nov 28, 2014 at 03:08:51PM +, Stefano Stabellini wrote:
>> > > > create ^
>> >
flight 31886 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31886/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 5 xen-boot fail REGR. vs. 31855
Regressions which a
On Fri, 28 Nov 2014, Sander Eikelenboom wrote:
> Friday, November 28, 2014, 6:09:52 PM, you wrote:
>
> > On Fri, 28 Nov 2014, Wei Liu wrote:
> >> On Fri, Nov 28, 2014 at 04:54:19PM +, Stefano Stabellini wrote:
> >> > On Fri, 28 Nov 2014, Wei Liu wrote:
> >> > > On Fri, Nov 28, 2014 at 03:08:51
On Thu, Nov 27, 2014 at 06:50:31PM +, Andrew Cooper wrote:
> On 27/11/14 18:36, Luis R. Rodriguez wrote:
> > On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
> >> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
> >>> From: "Luis R. Rodriguez"
> >>>
> >>> Some folks had reported
1 - 100 of 104 matches
Mail list logo
