Re: [Xen-devel] [V9 2/3] Refactor rangeset structure for better performance.

On 12/21/2015 10:38 PM, Jan Beulich wrote: On 15.12.15 at 03:05, wrote: This patch refactors struct rangeset to base it on the red-black tree structure, instead of on the current doubly linked list. By now, ioreq leverages rangeset to keep track of the IO/memory

Re: [Xen-devel] [V9 0/3] Refactor ioreq server for better performance.

Shuai, thank you very much for helping me push these patches! And sorry for the delay due to my illness. Now I'm back and will pick this up. :) B.R. Yu On 12/15/2015 10:05 AM, Shuai Ruan wrote: From: Yu Zhang ng the XenGT leverages ioreq server to track and forward

Re: [Xen-devel] [V9 3/3] Differentiate IO/mem resources tracked by ioreq server

On 12/21/2015 10:45 PM, Jan Beulich wrote: On 15.12.15 at 03:05, wrote: --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -935,6 +935,9 @@ static void hvm_ioreq_server_free_rangesets(struct hvm_ioreq_server *s, rangeset_destroy(s->range[i]);

Re: [Xen-devel] [PATCH v3 40/62] arm/acpi: Estimate memory required for acpi/efi tables

On 2015/11/27 0:39, Stefano Stabellini wrote: > On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote: >> From: Shannon Zhao >> >> Estimate the memory required for loading acpi/efi tables in Dom0. Alloc >> the pages to store the new created EFI and ACPI tables and free

[Xen-devel] [PATCH 1/1] Improved RTDS scheduler

Budget replenishment is now handled by a dedicated timer which is triggered at the most imminent release time of all runnable vcpus. Signed-off-by: Tianyang Chen Signed-off-by: Meng Xu Signed-off-by: Dagaen Golomb ---

[Xen-devel] [PATCH V2 1/1] Improved RTDS scheduler

Budget replenishment is now handled by a dedicated timer which is triggered at the most imminent release time of all runnable vcpus. Changes since V1: None Signed-off-by: Tianyang Chen Signed-off-by: Meng Xu Signed-off-by: Dagaen Golomb

[Xen-devel] [PATCH 0/1] Improved RTDS scheduler

Current RTDS scheduler is time driven and is called every 1ms. During each scheduler call, the repl_update() scans both runq and depeletedq, which might not be necessary every 1ms. Since each vcpu is implemented as a deferable server, budget is preserved during its period and refilled in the

Re: [Xen-devel] [PATCH V2 1/1] Improved RTDS scheduler

On Thu, Dec 31, 2015 at 6:20 PM, Tianyang Chen wrote: > > Budget replenishment is now handled by a dedicated timer which is > triggered at the most imminent release time of all runnable vcpus. > > Changes since V1: > None > > Signed-off-by: Tianyang Chen

[Xen-devel] [PATCH V2 0/1] Improved RTDS scheduler

Changes since V1: Removed redundant cover letter Removed redundant patch file that was added with the last commit Please dis-regard V1 because it was in wrong format. Sorry about that. Current RTDS scheduler is time driven and is called every 1ms. During each scheduler call, the

[Xen-devel] [distros-debian-wheezy test] 38576: all pass

flight 38576 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38576/ Perfect :-) All tests in this flight passed baseline version: flight 38557 jobs: build-amd64 pass build-armhf

[Xen-devel] [PATCH v2 31/32] sh: support a 2-byte smp_store_mb

At the moment, xchg on sh only supports 4 and 1 byte values, so using it from smp_store_mb means attempts to store a 2 byte value using this macro fail. And happens to be exactly what virtio drivers want to do. Check size and fall back to a slower, but safe, WRITE_ONCE+smp_mb. Signed-off-by:

[Xen-devel] [PATCH v2 32/32] virtio_ring: use virt_store_mb

We need a full barrier after writing out event index, using virt_store_mb there seems better than open-coding. As usual, we need a wrapper to account for strong barriers. It's tempting to use this in vhost as well, for that, we'll need a variant of smp_store_mb that works on __user pointers.

[Xen-devel] [PATCH v2 24/32] sparc: define __smp_xxx

This defines __smp_xxx barriers for sparc, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Signed-off-by: Michael S. Tsirkin Acked-by: Arnd Bergmann --- arch/sparc/include/asm/barrier_64.h | 8

[Xen-devel] [PATCH v2 21/32] mips: define __smp_xxx

This defines __smp_xxx barriers for mips, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Note: the only exception is smp_mb__before_llsc which is mips-specific. We define both the __smp_mb__before_llsc variant (for use in

[Xen-devel] [PATCH v2 22/32] s390: define __smp_xxx

This defines __smp_xxx barriers for s390, for use by virtualization. Some smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Note: smp_mb, smp_rmb and smp_wmb are defined as full barriers unconditionally on this architecture. Signed-off-by: Michael S. Tsirkin

[Xen-devel] [PATCH v2 28/32] asm-generic: implement virt_xxx memory barriers

Guests running within virtual machines might be affected by SMP effects even if the guest itself is compiled without SMP support. This is an artifact of interfacing with an SMP host while running an UP kernel. Using mandatory barriers for this use-case would be possible but is often suboptimal.

[Xen-devel] [PATCH v2 29/32] Revert "virtio_ring: Update weak barriers to use dma_wmb/rmb"

This reverts commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9. While that commit optimizes !CONFIG_SMP, it mixes up DMA and SMP concepts, making the code hard to figure out. A better way to optimize this is with the new __smp_XXX barriers. As a first step, go back to full rmb/wmb barriers for

[Xen-devel] [PATCH v2 30/32] virtio_ring: update weak barriers to use __smp_XXX

virtio ring uses smp_wmb on SMP and wmb on !SMP, the reason for the later being that it might be talking to another kernel on the same SMP machine. This is exactly what __smp_XXX barriers do, so switch to these instead of homegrown ifdef hacks. Cc: Peter Zijlstra Cc:

[Xen-devel] [PATCH v2 27/32] x86: define __smp_xxx

This defines __smp_xxx barriers for x86, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Signed-off-by: Michael S. Tsirkin Acked-by: Arnd Bergmann --- arch/x86/include/asm/barrier.h | 31

[Xen-devel] [PATCH v2 26/32] xtensa: define __smp_xxx

This defines __smp_xxx barriers for xtensa, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Signed-off-by: Michael S. Tsirkin Acked-by: Arnd Bergmann --- arch/xtensa/include/asm/barrier.h | 4 ++--

[Xen-devel] [PATCH v2 13/32] x86: reuse asm-generic/barrier.h

As on most architectures, on x86 read_barrier_depends and smp_read_barrier_depends are empty. Drop the local definitions and pull the generic ones from asm-generic/barrier.h instead: they are identical. This is in preparation to refactoring this code area. Signed-off-by: Michael S. Tsirkin

[Xen-devel] [PATCH v2 12/32] x86/um: reuse asm-generic/barrier.h

On x86/um CONFIG_SMP is never defined. As a result, several macros match the asm-generic variant exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. This is in preparation to refactoring this code area. Signed-off-by: Michael S. Tsirkin Acked-by:

[Xen-devel] [PATCH v2 17/32] arm: define __smp_xxx

This defines __smp_xxx barriers for arm, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h This reduces the amount of arch-specific boiler-plate code. Signed-off-by: Michael S. Tsirkin Acked-by: Arnd Bergmann

[Xen-devel] [PATCH v2 10/32] metag: reuse asm-generic/barrier.h

On metag dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, smp_read_barrier_depends, smp_store_release and smp_load_acquire match the asm-generic variants exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. This is in preparation to refactoring this code area.

[Xen-devel] [PATCH v2 18/32] blackfin: define __smp_xxx

This defines __smp_xxx barriers for blackfin, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Signed-off-by: Michael S. Tsirkin Acked-by: Arnd Bergmann --- arch/blackfin/include/asm/barrier.h | 4

[Xen-devel] [PATCH v2 19/32] ia64: define __smp_xxx

This defines __smp_xxx barriers for ia64, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h This reduces the amount of arch-specific boiler-plate code. Signed-off-by: Michael S. Tsirkin Acked-by: Tony Luck

[Xen-devel] [PATCH v2 20/32] metag: define __smp_xxx

This defines __smp_xxx barriers for metag, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Note: as __smp_XX macros should not depend on CONFIG_SMP, they can not use the existing fence() macro since that is defined differently

[Xen-devel] [PATCH v2 23/32] sh: define __smp_xxx, fix smp_store_mb for !SMP

sh variant of smp_store_mb() calls xchg() on !SMP which is stronger than implied by both the name and the documentation. define __smp_store_mb instead: code in asm-generic/barrier.h will then define smp_store_mb correctly depending on CONFIG_SMP. Signed-off-by: Michael S. Tsirkin

[Xen-devel] [PATCH v2 25/32] tile: define __smp_xxx

This defines __smp_xxx barriers for tile, for use by virtualization. Some smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Note: for 32 bit, keep smp_mb__after_atomic around since it's faster than the generic implementation. Signed-off-by: Michael S. Tsirkin

[Xen-devel] [PATCH v2 08/32] arm: reuse asm-generic/barrier.h

On arm smp_store_mb, read_barrier_depends, smp_read_barrier_depends, smp_store_release, smp_load_acquire, smp_mb__before_atomic and smp_mb__after_atomic match the asm-generic variants exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. This is in preparation to

[Xen-devel] [PATCH v2 11/32] mips: reuse asm-generic/barrier.h

On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, smp_read_barrier_depends, smp_store_release and smp_load_acquire match the asm-generic variants exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. This is in preparation to refactoring this code area.

[Xen-devel] [PATCH v2 06/32] s390: reuse asm-generic/barrier.h

On s390 read_barrier_depends, smp_read_barrier_depends smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the asm-generic variants exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. This is in preparation to refactoring this code area. Signed-off-by:

[Xen-devel] [PATCH v2 01/32] lcoking/barriers, arch: Use smp barriers in smp_store_release()

From: Davidlohr Bueso With commit b92b8b35a2e ("locking/arch: Rename set_mb() to smp_store_mb()") it was made clear that the context of this call (and thus set_mb) is strictly for CPU ordering, as opposed to IO. As such all archs should use the smp variant of mb(), respecting

[Xen-devel] [PATCH v2 14/32] asm-generic: add __smp_xxx wrappers

On !SMP, most architectures define their barriers as compiler barriers. On SMP, most need an actual barrier. Make it possible to remove the code duplication for !SMP by defining low-level __smp_xxx barriers which do not depend on the value of SMP, then use them from asm-generic conditionally.

[Xen-devel] [PATCH v2 16/32] arm64: define __smp_xxx

This defines __smp_xxx barriers for arm64, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Note: arm64 does not support !SMP config, so smp_xxx and __smp_xxx are always equivalent. Signed-off-by: Michael S. Tsirkin

[Xen-devel] [PATCH v2 07/32] sparc: reuse asm-generic/barrier.h

On sparc 64 bit dma_rmb, dma_wmb, smp_store_mb, smp_mb, smp_rmb, smp_wmb, read_barrier_depends and smp_read_barrier_depends match the asm-generic variants exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. nop uses __asm__ __volatile but is otherwise identical to the

[Xen-devel] [PATCH v2 09/32] arm64: reuse asm-generic/barrier.h

On arm64 nop, read_barrier_depends, smp_read_barrier_depends smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the asm-generic variants exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. This is in preparation to refactoring this code area.

[Xen-devel] [PATCH v2 05/32] powerpc: reuse asm-generic/barrier.h

On powerpc read_barrier_depends, smp_read_barrier_depends smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the asm-generic variants exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. This is in preparation to refactoring this code area.

[Xen-devel] [PATCH v2 15/32] powerpc: define __smp_xxx

This defines __smp_xxx barriers for powerpc for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h This reduces the amount of arch-specific boiler-plate code. Signed-off-by: Michael S. Tsirkin Acked-by: Arnd Bergmann

Re: [Xen-devel] [PATCH v2 07/32] sparc: reuse asm-generic/barrier.h

From: "Michael S. Tsirkin" Date: Thu, 31 Dec 2015 21:06:38 +0200 > On sparc 64 bit dma_rmb, dma_wmb, smp_store_mb, smp_mb, smp_rmb, > smp_wmb, read_barrier_depends and smp_read_barrier_depends match the > asm-generic variants exactly. Drop the local definitions and pull in >

[Xen-devel] [PATCH v2 33/34] xenbus: use virt_xxx barriers

drivers/xen/xenbus/xenbus_comms.c uses full memory barriers to communicate with the other side. For guests compiled with CONFIG_SMP, smp_wmb and smp_mb would be sufficient, so mb() and wmb() here are only needed if a non-SMP guest runs on an SMP host. Switch to virt_xxx barriers which serve this

[Xen-devel] [PATCH v2 34/34] xen/io: use virt_xxx barriers

include/xen/interface/io/ring.h uses full memory barriers to communicate with the other side. For guests compiled with CONFIG_SMP, smp_wmb and smp_mb would be sufficient, so mb() and wmb() here are only needed if a non-SMP guest runs on an SMP host. Switch to virt_xxx barriers which serve this

Re: [Xen-devel] [PATCH v2 24/32] sparc: define __smp_xxx

From: "Michael S. Tsirkin" Date: Thu, 31 Dec 2015 21:08:53 +0200 > This defines __smp_xxx barriers for sparc, > for use by virtualization. > > smp_xxx barriers are removed as they are > defined correctly by asm-generic/barriers.h > > Signed-off-by: Michael S. Tsirkin

[Xen-devel] [PATCH v2 03/32] ia64: rename nop->iosapic_nop

asm-generic/barrier.h defines a nop() macro. To be able to use this header on ia64, we shouldn't call local functions/variables nop(). There's one instance where this breaks on ia64: rename the function to iosapic_nop to avoid the conflict. Signed-off-by: Michael S. Tsirkin

[Xen-devel] [PATCH v2 02/32] asm-generic: guard smp_store_release/load_acquire

Allow architectures to override smp_store_release and smp_load_acquire by guarding the defines in asm-generic/barrier.h with ifndef directives. This is in preparation to reusing asm-generic/barrier.h on architectures which have their own definition of these macros. Signed-off-by: Michael S.

[Xen-devel] [PATCH v2 04/32] ia64: reuse asm-generic/barrier.h

On ia64 smp_rmb, smp_wmb, read_barrier_depends, smp_read_barrier_depends and smp_store_mb() match the asm-generic variants exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. This is in preparation to refactoring this code area. Signed-off-by: Michael S. Tsirkin

[Xen-devel] [PATCH v2 00/34] arch: barrier cleanup + barriers for virt

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant

[Xen-devel] What is Ganeti?

Hello. Can anyone tell me about "Ganeti" ? Is it a replacement for Xen? Cheers. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] svm: rephrase local variable use for Coverity.

Coverity CID 1343310 No functional changes. Signed-off-by: Joshua Otto --- On Mon, Dec 28, 2015 at 09:34:28AM +, Andrew Cooper wrote: > The error message isn't fantastic, but the complaint that Coverity > has is that we store intr here, then unilaterally store it again