We have compiled a new linux kernel for a guest VM with
CONFIG_VIRTIO_BLK=y. But it doesn't boot and kernel panics. To kernel
command line I tried passing root=/dev/vda and root=/dev/vda1 but same
kernel panic comes every time. VIRTIO_NET worked fine.
But with VIRTIO_BLK we see the below kernel
On Wed, 04/02 11:32, saurabh agarwal wrote:
We have compiled a new linux kernel for a guest VM with
CONFIG_VIRTIO_BLK=y. But it doesn't boot and kernel panics. To kernel
command line I tried passing root=/dev/vda and root=/dev/vda1 but same
kernel panic comes every time. VIRTIO_NET worked
On 01/04/14 16:47, Christian Borntraeger wrote:
We want to configure several things in KVM that go beyond what
ENABLE_CAP (we need payload) or ONE_REG (we need it for the VM
and we need to do more complex actions) can provide. Instead of
adding several s390 specific ioctls, lets provide a
On 02.04.14 10:31, Christian Borntraeger wrote:
On 01/04/14 16:47, Christian Borntraeger wrote:
We want to configure several things in KVM that go beyond what
ENABLE_CAP (we need payload) or ONE_REG (we need it for the VM
and we need to do more complex actions) can provide. Instead of
adding
On 02/04/14 10:39, Alexander Graf wrote:
On 02.04.14 10:31, Christian Borntraeger wrote:
On 01/04/14 16:47, Christian Borntraeger wrote:
We want to configure several things in KVM that go beyond what
ENABLE_CAP (we need payload) or ONE_REG (we need it for the VM
and we need to do more
From: Dominik Dingel din...@linux.vnet.ibm.com
For lazy storage key handling, we need a mechanism to track if the
process ever issued a storage key operation.
This patch adds the basic infrastructure for making the storage
key handling optional, but still leaves it enabled for now by default.
From: Dominik Dingel din...@linux.vnet.ibm.com
Introduce a new function s390_enable_skey(), which enables storage key
handling via setting the use_skey flag in the mmu context.
This function is only useful within the context of kvm.
Note that enabling storage keys will cause a one-time hickup
From: Dominik Dingel din...@linux.vnet.ibm.com
page_table_reset_pgste() already does a complete page table walk to
reset the pgste. Enhance it to initialize the storage keys to
PAGE_DEFAULT_KEY if requested by the caller.
The current caller, the config device will not make use of this right
now,
From: Dominik Dingel din...@linux.vnet.ibm.com
The first invocation of storage key operations on a given cpu will be
intercepted.
On these intercepts we will enable storage keys for the guest and remove the
previously added intercepts.
Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com
From: Dominik Dingel din...@linux.vnet.ibm.com
Old userspace versions could reset the guest, without notifying kvm,
which could result in a cmma state unknow to the guest, resulting
in data corruption. Lets only enable CMMA if userspace understands
when it needs to reset the usage state.
CMMA
Martin,
shall we send out patch 1 via your tree or kvm? Should be still in for 3.15
Can you ACK patches 2-5?
Dominik Dingel (5):
KVM: s390: make cmma usage conditionally
KVM: s390: Adding skey bit to mmu context
KVM: s390: Clear storage keys
KVM: s390: Allow skeys to be enabled for the
On 31/03/14 11:43, Paolo Bonzini wrote:
Il 31/03/2014 10:30, Paolo Bonzini ha scritto:
Linus,
The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2:
Linux 3.14-rc3 (2014-02-16 13:30:25 -0800)
are available in the git repository at:
The simple unfair queue lock cannot completely solve the lock waiter
preemption problem as a preempted CPU at the front of the queue will
block forward progress in all the other CPUs behind it in the queue.
To allow those CPUs to move forward, it is necessary to enable lock
stealing for those lock
This patch introduces a new generic queue spinlock implementation that
can serve as an alternative to the default ticket spinlock. Compared
with the ticket spinlock, this queue spinlock should be almost as fair
as the ticket spinlock. It has about the same speed in single-thread
and it can be much
A major problem with the queue spinlock patch is its performance at
low contention level (2-4 contending tasks) where it is slower than
the corresponding ticket spinlock code. The following table shows
the execution time (in ms) of a micro-benchmark where 5M iterations
of the lock/unlock cycles
This patch renames the paravirt_ticketlocks_enabled static key to a
more generic paravirt_spinlocks_enabled name.
Signed-off-by: Waiman Long waiman.l...@hp.com
---
arch/x86/include/asm/spinlock.h |4 ++--
arch/x86/kernel/kvm.c|2 +-
This patch adds the necessary KVM specific code to allow XEN to support
the sleeping and CPU kicking operations needed by the queue spinlock PV
code.
Signed-off-by: Waiman Long waiman.l...@hp.com
---
arch/x86/xen/spinlock.c | 119 +--
This patch adds the necessary KVM specific code to allow KVM to support
the sleeping and CPU kicking operations needed by the queue spinlock PV
code.
Two KVM guests of 20 CPU cores (2 nodes) were created for performance
testing in one of the following three configurations:
1) Only 1 VM is active
This patch adds para-virtualization support to the queue spinlock in
the same way as was done in the PV ticket lock code. In essence, the
lock waiters will spin for a specified number of times (QSPIN_THRESHOLD
= 2^14) and then halted itself. The queue head waiter, unlike the
other waiter, will
For architectures that support atomic operations on smaller 8 or
16 bits data types. It is possible to simplify the code and produce
slightly better optimized code at the expense of smaller number of
supported CPUs.
The qspinlock code can support up to a maximum of 4M-1 CPUs. With
less than 16K
This patch makes the necessary changes at the x86 architecture
specific layer to enable the use of queue spinlock for x86-64. As
x86-32 machines are typically not multi-socket. The benefit of queue
spinlock may not be apparent. So queue spinlock is not enabled.
Currently, there is some
N.B. Sorry for the duplicate. This patch series were resent as the
original one was rejected by the vger.kernel.org list server
due to long header. There is no change in content.
v7-v8:
- Remove one unneeded atomic operation from the slowpath, thus
improving performance.
-
Locking is always an issue in a virtualized environment because of 2
different types of problems:
1) Lock holder preemption
2) Lock waiter preemption
One solution to the lock waiter preemption problem is to allow unfair
lock in a para-virtualized environment. In this case, a new lock
acquirer
On Wed, 2 Apr 2014 11:24:43 +0200
Christian Borntraeger borntrae...@de.ibm.com wrote:
shall we send out patch 1 via your tree or kvm? Should be still in for 3.15
Can you ACK patches 2-5?
Dominik Dingel (5):
KVM: s390: make cmma usage conditionally
KVM: s390: Adding skey bit to mmu
On Wed, Apr 02, 2014 at 09:27:29AM -0400, Waiman Long wrote:
N.B. Sorry for the duplicate. This patch series were resent as the
original one was rejected by the vger.kernel.org list server
due to long header. There is no change in content.
v7-v8:
- Remove one unneeded atomic
diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks
index a70fdeb..451e392 100644
--- a/kernel/Kconfig.locks
+++ b/kernel/Kconfig.locks
@@ -229,4 +229,4 @@ config ARCH_USE_QUEUE_SPINLOCK
config QUEUE_SPINLOCK
def_bool y if ARCH_USE_QUEUE_SPINLOCK
- depends on SMP
Would KVM have any scalability issues in comparison to a real system,
e.g. if a KVM emulated 16 cores all of which get assign tasks 100% of
the time. Would KVM scale just as well as a real system ?
Trent
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 04/02/2014 10:32 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Apr 02, 2014 at 09:27:29AM -0400, Waiman Long wrote:
N.B. Sorry for the duplicate. This patch series were resent as the
original one was rejected by the vger.kernel.org list server
due to long header. There is no change in
On 04/02/2014 10:39 AM, Konrad Rzeszutek Wilk wrote:
diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks
index a70fdeb..451e392 100644
--- a/kernel/Kconfig.locks
+++ b/kernel/Kconfig.locks
@@ -229,4 +229,4 @@ config ARCH_USE_QUEUE_SPINLOCK
config QUEUE_SPINLOCK
def_bool y if
On Tue, Apr 01, 2014 at 05:46:34PM -0700, Andy Lutomirski wrote:
On Tue, Apr 1, 2014 at 5:29 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Apr 01, 2014 at 12:17:16PM -0700, Andy Lutomirski wrote:
On Tue, Apr 1, 2014 at 11:01 AM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On
On Tue, 1 Apr 2014 17:23:24 -0700
Greg KH gre...@linuxfoundation.org wrote:
On Tue, Apr 01, 2014 at 06:52:12PM -0500, Kim Phillips wrote:
On Tue, 01 Apr 2014 10:28:54 -0600
Alex Williamson alex.william...@redhat.com wrote:
The driver_override field allows us to specify the driver for a
On Wed, Apr 2, 2014 at 3:05 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Apr 01, 2014 at 05:46:34PM -0700, Andy Lutomirski wrote:
On Tue, Apr 1, 2014 at 5:29 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Apr 01, 2014 at 12:17:16PM -0700, Andy Lutomirski wrote:
On Tue, Apr
On Wed, 2014-04-02 at 17:06 -0500, Kim Phillips wrote:
On Tue, 1 Apr 2014 17:23:24 -0700
Greg KH gre...@linuxfoundation.org wrote:
On Tue, Apr 01, 2014 at 06:52:12PM -0500, Kim Phillips wrote:
On Tue, 01 Apr 2014 10:28:54 -0600
Alex Williamson alex.william...@redhat.com wrote:
and where is their gpg key?
I code, therefore I am
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/02/2014 04:35 PM, Waiman Long wrote:
On 04/02/2014 10:32 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Apr 02, 2014 at 09:27:29AM -0400, Waiman Long wrote:
N.B. Sorry for the duplicate. This patch series were resent as the
original one was rejected by the vger.kernel.org list server
Hi Alex, could you help to pick up this patch? since v3.14 kernel can
enable numa fault for powerpc.
Thx,
Fan
On Mon, Jan 27, 2014 at 5:11 PM, Alexander Graf ag...@suse.de wrote:
On 21.01.2014, at 10:42, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
wrote:
Liu Ping Fan
36 matches
Mail list logo
