On 11/10/2014 05:23 PM, Andrew Cooper wrote:
On 10/11/2014 05:28, Wen Congyang wrote:
I disable xen-platform-pci in the config file, but when I start the guest, I
found
the following kernel message:
[0.00] Booting paravirtualized kernel on Xen HVM
[0.00] xen:events: Xen HVM
On Sun, 2014-11-09 at 09:22 +0800, Anh Dinh wrote:
Thanks,
I've found out the reason it page-faulting is because I used malloc()
to allocate the output buffer, which turns out to allocate lazily.
Therefore the hypervisor page-fault because the memory is still
waiting to be mapped by the
On 10.11.14 at 11:51, dario.faggi...@citrix.com wrote:
I'm 100% ok to re-start that discussion here and now... however, how
stable should this interface be? Can't we deal with this when actually
implementing NUMA aware ballooning and add stuff at than point, if
necessary?
Wei's desire to
On Mon, Nov 10, 2014 at 11:51:28AM +0100, Dario Faggioli wrote:
On Mon, 2014-11-10 at 10:00 +, Wei Liu wrote:
On Mon, Nov 10, 2014 at 09:21:24AM +, Jan Beulich wrote:
On 08.11.14 at 20:43, wei.l...@citrix.com wrote:
This information is passed in in domctl hypercall but the guest
On Thu, 2014-11-06 at 16:11 +0100, Atom2 wrote:
It's probably also worth mentioning that gcc is (and also was with the
older gcc-4.7.3) the hardened gcc version of gentoo which forces
position-independent executables (PIE), stack smashing protection (SPP)
and compile time buffer checks
flight 31397 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31397/
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-amd64-xl
On Thu, 2014-11-06 at 12:48 +, Julien Grall wrote:
Hello all,
I've been working on updating our aarch64 bootwrapper
to support new feature such as PSCI and GICv3.
Rather than porting the feature from the Linux bootwrapper [1].
I've added support of Xen on top of the Linux repo.
On Mon, 2014-11-10 at 11:09 +, Wei Liu wrote:
On Mon, Nov 10, 2014 at 11:51:28AM +0100, Dario Faggioli wrote:
I'm 100% ok to re-start that discussion here and now... however, how
stable should this interface be? Can't we deal with this when actually
implementing NUMA aware ballooning
Wen Congyang writes ([Patch v2 0/3] Some bugfix patches):
These bugs are found when we implement COLO, or rebase
COLO to upstream xen. They are independent patches, so
post them in separate series.
Thanks. I can't seem to see any discussion of these bugfixes. They
seem to have been dropped.
Ian,
Thanks again for your reply.
Am 10.11.14 um 12:16 schrieb Ian Campbell:
On Thu, 2014-11-06 at 16:11 +0100, Atom2 wrote:
Is it at all possible to recompile at least the Xen toolstack bits with
these extra gcc features disabled? Either by using the old compiler or
somehow (CFLAGS?)
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 the gzip one) just use plain malloc/realloc and therefore the buffer ends
up leaked.
The memory pool currently supports mmap'd buffers
On Wed, 2014-11-05 at 14:43 +, Ian Jackson wrote:
+If it is not feasible to conform fully to the style while patching old
+code, without doing substantial style reengineering first, we may
+accept patches which contain nonconformant elements, provided that
+they don't make the coding style
On Mon, 10 Nov 2014, Catalin Marinas wrote:
On Fri, Nov 07, 2014 at 06:45:22PM +, Stefano Stabellini wrote:
On Fri, 7 Nov 2014, Catalin Marinas wrote:
On Fri, Nov 07, 2014 at 05:35:41PM +, Stefano Stabellini wrote:
On Fri, 7 Nov 2014, Stefano Stabellini wrote:
On Fri, 7 Nov
On Fri, Nov 07, 2014 at 11:34:33AM -0500, Zhigang Wang wrote:
On 11/07/2014 05:47 AM, Wei Liu wrote:
On Thu, Nov 06, 2014 at 02:14:42PM -0500, Zhigang Wang wrote:
Hi,
While doing VM migration, in the destination side:
# xl list -l
libxl: error:
On Mon, 2014-11-10 at 12:37 +, Wei Liu wrote:
Ian and Ian, any thought how this bug came into being? I think we should
fix this for 4.5, but I don't think I know enough of how memory target
is expected to behave.
I'm confused by the description of what's going on, in particular the
flight 31409 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31409/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl 9 guest-start fail like 31358
test-amd64-i386-pair
On Mon, 2014-11-10 at 14:00 +, Ian Jackson wrote:
Ian Campbell writes (Re: [Xen-devel] [xen-4.2-testing test] 31385:
regressions - FAIL):
On Fri, 2014-11-07 at 11:31 +, Ian Jackson wrote:
Hrm. I have added the relevant host property to the moths too. My
osstest change got a
On Mon, Nov 10, 2014 at 02:05:49PM +, Ian Campbell wrote:
On Mon, 2014-11-10 at 13:54 +, Wei Liu wrote:
Can we write a stub json file at the beginning of migrate receive, a bit
like we do on create?
No, we don't generate stub for normal domain at the moment.
Oh, I
On Mon, Nov 10, 2014 at 01:37:44AM -0700, Chun Yan Liu wrote:
Is there any progress on this work? I didn't see new version after this.
Anyone knows the status?
I believe Olaf and Juergen were looking at this for Xen 4.6?
CC-ing them.
Thanks,
Chunyan
On 8/11/2014 at 04:23 AM, in message
On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
On 11/10/2014 07:35 AM, Wei Liu wrote:
I see. At that point the configuration was not available, yet. After the
domain is successfully migrated, the configuration should be available.
I think a domain under construction
I'm not sure if I should resend the patch just to change the commit log and
add the reason of why doing this.
I want to first add the reason. If I should resend the patch set, please
let me know.
2014-11-10 7:53 GMT-05:00 George Dunlap george.dun...@eu.citrix.com:
On 10/25/2014 03:16 PM, Meng
On Mon, 2014-11-10 at 10:29 -0500, Zhigang Wang wrote:
On 11/10/2014 07:44 AM, Ian Campbell wrote:
On Mon, 2014-11-10 at 12:37 +, Wei Liu wrote:
Ian and Ian, any thought how this bug came into being? I think we should
fix this for 4.5, but I don't think I know enough of how memory
On Mon, 2014-11-10 at 10:29 -0500, Meng Xu wrote:
I'm not sure if I should resend the patch just to change the commit
log and add the reason of why doing this.
Yes, that is usually quite a good reason, as changelogs are really
important (for the reasons George pointed out already).
Hi all,
this patch series introduces support for GNTTABOP_cache_flush to perform
cache maintenance operation on foreign pages and reverts the current
code based on XENFEAT_grant_map_identity.
It also provides a very slow fallback by bouncing on the swiotlb buffer,
in case the hypercall is not
Introduce an arch specific function to find out whether a particular dma
mapping operation needs to bounce on the swiotlb buffer.
On ARM and ARM64, if the page involved is a foreign page and the device
is not coherent, we need to bounce because at unmap time we cannot
execute any required cache
Merge xen/mm32.c into xen/mm.c.
As a consequence the code gets compiled on arm64 too.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
arch/arm/xen/Makefile |2 +-
arch/arm/xen/mm.c | 86 +
On 11/10/2014 12:24 PM, Wei Liu wrote:
On Mon, Nov 10, 2014 at 12:08:18PM -0500, Zhigang Wang wrote:
On 11/10/2014 10:25 AM, Wei Liu wrote:
On Mon, Nov 10, 2014 at 10:01:22AM -0500, Zhigang Wang wrote:
On 11/10/2014 07:35 AM, Wei Liu wrote:
I see. At that point the configuration was not
On Mon, Nov 10, 2014 at 04:14:00PM +, Stefano Stabellini wrote:
In xen_dma_map_page, if the page is a local page, call the native
map_page dma_ops. If the page is foreign, call __xen_dma_map_page that
issues any required cache maintenane operations via hypercall.
The reason for doing
On Mon, Nov 10, 2014 at 04:14:01PM +, Stefano Stabellini wrote:
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -1,6 +1,10 @@
+#include linux/cpu.h
+#include linux/dma-mapping.h
#include linux/bootmem.h
#include linux/gfp.h
+#include linux/highmem.h
#include linux/export.h
flight 31468 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31468/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 9 guest-start fail REGR. vs. 30603
On 11/10/2014 0:51, Jan Beulich wrote:
On 10.11.14 at 09:03, sfl...@ihonk.com wrote:
Sorry for the delay, took some debugging on another computer to get
serial logging working. Due to its size, I've posted the entire log of a
crashed session here: http://pastebin.com/AiPHUZRH In this case I
The solution is summarized by Dario Faggioli at
http://lists.xen.org/archives/html/xen-devel/2014-09/msg03603.html.
Here is the solution:
- sanity checking input params in rt_dom_cntl()
- serialize rt_dom_cntl() itself against the global lock
- move the call to
On 11/10/2014 07:01 AM, Ian Campbell wrote:
On Thu, 2014-11-06 at 17:01 -0500, Daniel De Graaf wrote:
On 11/04/2014 05:15 AM, Ian Campbell wrote:
On Thu, 2014-10-30 at 15:48 +0200, Emil Condrea wrote:
Of course we can use max, but I thought that it might be useful to
have a prink to inform
Two patches to fix 'xl pci-detach'/do_pci_remove() behavior.
* Prevent libxl from resetting device (and removing it from xenstore)
before QEMU responded to the guest's 'eject' write
* Remove unnecessary calls to xc_physdev_unmap_pirq() and
xc_domain_irq_permission()
If patches are acceptable
34 matches
Mail list logo
